Zabezpieczanie serwera SSH przed brutalnym atakiem

Mam mały serwer SVN, stary Dell Optiplex z uruchomionym debianem. Nie mam tak wysokich wymagań na moim serwerze, ponieważ to tylko mały serwer SVN ... ale chcę, aby był bezpieczny.

Właśnie odnowiłem mój serwer do nowszego i lepszego optiplex i zacząłem trochę patrzeć na stary serwer. Zdjąłem go po wystąpieniu problemów. Kiedy sprawdzam dzienniki, są pełne brutalnych prób i jakoś ktoś zdołał dostać się do mojej maszyny. Ta osoba stworzyła dodatkowy tom o nazwie „knarkgosse” z dwoma katalogami „root” i „swap1” lub coś takiego. Naprawdę nie wiem, dlaczego i co robią, ale na pewno chcesz temu zapobiec. Uważam to za nieco dziwne, ponieważ zmieniam hasło co kilka miesięcy, a hasła to zawsze losowe litery i cyfry złożone razem ... niełatwe do użycia przy użyciu siły.

Wiem, że mogę zapobiec logowaniu się użytkownika root i korzystać z sudoers ... i zmienić port SSH, ale co więcej mogę zrobić?

Mam więc kilka pytań:

1. Jak mogę zapobiec logowaniu przez 5 minut po X nieprawidłowych próbach. Lub powolne próby po każdej nieprawidłowej próbie?

2. Czy istnieje jakaś centralna czarna lista, z którą serwer może się połączyć? Czarna lista, która śledzi adresy IP, które są „niebezpieczne” i nigdy nie powinny mieć dostępu?

3. Co jeszcze mogę zrobić, aby zapewnić bezpieczeństwo mojemu serwerowi?

Jak powiedziałem wcześniej, używam Debiana 5 z Apache (problem z użytkownikami danych www?), Svn, mysql, php, phpmyadmin, hudson. Jest w sieci domowej z przekierowaniem portów na 80, 443, 8080, 8180, 23 i 22.

Fail2ban i Port Knocking powinny zaspokoić większość twoich potrzeb.

Zalecana jest również zmiana portu SSH i zezwolenie tylko na uwierzytelnianie oparte na kluczach.

Można argumentować, że dodanie dodatkowych środków bezpieczeństwa może doprowadzić do malejących zwrotów, ale z drugiej strony to Ty decydujesz, kiedy będziesz „wystarczająco bezpieczny”.

Dobrym pomysłem jest również zabronienie logowania do roota.

Nie ma substytutu dla bezpiecznych haseł ORAZ uwierzytelniania klucza. Biorąc to pod uwagę, Fail2Ban jest doskonałym narzędziem do blokowania adresów IP użytkowników, którzy próbują uwierzytelnić się zbyt wiele razy. Jest również dostępny jako gotowy pakiet dla większości dystrybucji. Ostrzegamy, że możesz zostać przypadkowo zbanowany, więc upewnij się, że masz również adres IP na białej liście lub łatwy dostęp do konsoli ...

Fail2Ban ma kilka dobrych przykładów jak skonfigurować wszystko, o co prosiłeś ... nie ma jednak uniwersalnego repozytorium złych adresów. Nie sądzę, aby takie repozytorium istniało w dowolnym miejscu ze względu na łatwość zdobycia kolejnego adresu IP (dhcp odnowienie / ataki bot-net / etc ...). Wyłączyłbym także logowanie przez ssh przy użyciu wspólnych nazw użytkownika typu „administrator” (root / admin / administrator / sysop / etc ..), ponieważ są one najczęściej wymieniane.

Zatrzymałem ataki siłowe za pomocą:

• fail2ban
• sshd.config:
  • Hasło Autoryzacja nr
  • PermitRootLogin No
• Ograniczanie stawek SSH Connect za pomocą iptables ( http://www.debian-administration.org/articles/187 )

Istnieje wiele dobrych propozycji tutaj. Z szacunkiem sugeruję, że trzy rzeczy powinny uczynić to względnie bezpiecznym:

1. Uruchom sshd na losowo wysokim porcie. Boty zwykle wychodzą tylko za port 22 i odmiany na porcie 22, takie jak 2222.
2. Wyłącz uwierzytelnianie oparte na haśle w konfiguracji sshd:

UsePAM nr

3. Uwierzytelnianie w tej witrynie odbywa się tylko za pomocą wstępnie udostępnionych par kluczy SSH. Man on ssh-keygen, aby rozpocząć uwierzytelnianie oparte na PKI.

Mam nadzieję że to pomoże.

Zawsze byłem wielkim fanem CSF / LFD, który może blokować adresy IP osób próbujących brutalizować, portcan i kilka innych opcji. Jest to po prostu ogromne opakowanie perla dla tabel IP, ale plik konfiguracyjny nie jest trudny do odczytania, a dokumentacja nie jest zła.

Możesz także zajrzeć do sshguard. Nie korzystałem z niego, ale słyszałem dobre rzeczy.

Źródła:
http://isc.sans.edu/diary.html?storyid=9370

http://www.sshguard.net/

http://www.sshguard.net/docs/faqs/

„Sshguard monitoruje serwery pod kątem ich aktywności rejestrowania. Gdy dzienniki informują, że ktoś robi Złą Rzecz, sshguard reaguje, blokując go przez chwilę. Sshguard ma drażliwą osobowość: gdy niegrzeczny tyke nalega, by przeszkadzać Twojemu gospodarzowi, reaguje mocniej i mocniej ”.

Mam serwer SSH podłączony do Internetu na domyślnym porcie i nigdy nie miałem problemów.

• tcp_wrappers (tj. hosts.allow hosts.deny) dla SSH .. Nie sądzę, że istnieje tam SSH, który nie ma w nim skompilowanej obsługi
• iptables to w połączeniu z tcp_wrappers wyeliminowało około 99% moich przypadkowych skanowań portów / prób bruteforce. Jedynym problemem jest to, że musisz wiedzieć, skąd będziesz się łączyć, aby umożliwić te zakresy IP / IP ... Po prostu zrobiłem przegląd popularnych dostawców w mojej okolicy, aby zobaczyć ich zakresy adresów IP i pozwolić tym .. większość skanów wydaje się pochodzić z dalekich krajów :)
• PermitRootLogin bez hasła (tj. Tylko pary kluczy RSA / DSA, które są zaszyfrowane hasłem) działa wspaniale dla zautomatyzowanych zadań .. kiedy loguję się do interakcji, oczywiście używam mojego konta (zwykłego), które jest skonfigurowane z dostępem sudo
• sudoers
• ciągłe aktualizacje. Aktualizuję to pole często ze wszystkimi aktualizacjami bezpieczeństwa / krytycznymi
• zmiany hasła / hasła
• uruchom chkrootkit co jakiś czas, aby sprawdzić, czy mam jakieś problemy .. (istnieje kilka, które wykonują tę funkcję)

mam nadzieję, że to pomoże!

Jest na to lepszy sposób, użycie fail2ban oznacza, że ​​musisz dodać aplikację i działa ona w warstwie aplikacji.

Jeśli używasz iptables, jest to bardziej wydajne, ponieważ działa w warstwie sieci i nie musisz instalować dodatkowej aplikacji.

Użyj najnowszego modułu iptables http://www.snowman.net/projects/ipt_recent/

iptables -N SSHSCAN
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -j SSHSCAN
iptables -A SSHSCAN -m recent --set --name SSH
iptables -A SSHSCAN -m recent --update --seconds 300 --hitcount 3 --name SSH -j LOG --log-level info --log-prefix "SSH SCAN blocked: "
iptables -A SSHSCAN -m recent --update --seconds 300 --hitcount 3 --name SSH -j DROP
iptables -A SSHSCAN -j ACCEPT

Opcją (do zastosowania oprócz innych środków bezpieczeństwa) jest to, że sshd nasłuchuje na porcie innym niż 22. Nie próbowałem tego sam, ale słyszałem, że zmniejsza liczbę ataków typu „brute force” przez boty.

Muszę podkreślić, że to nie jest prawdziwe bezpieczeństwo, po prostu zmniejsza liczbę automatycznych ataków siłowych. Myślę, że za dużo pracy, by sprawdzić każdy port.

Coś, co nie zostało tutaj wymienione i naprawdę powinno ograniczać dostęp przez zaporę ogniową. Nie pasuje to do każdej sytuacji, ale jeśli łączysz się z hostem ze stałej lokalizacji ze statycznym adresem IP, możesz po prostu całkowicie zablokować SSH, z wyjątkiem tego adresu IP. Zapewni to, że intruzi nie będą mogli wejść. Jak już wspomniałem, nie zawsze pasuje to do każdej sytuacji, szczególnie jeśli twoje IP jest dynamiczne i często się zmienia.

DenyHosts, http://denyhosts.sourceforge.net/ , to dobry projekt, z którym miałem szczęście. Jeśli skonfigurujesz denyhosts do synchronizacji, pobierze nowe adresy IP, aby dodać do listy banów, które musiały brutalizować inne systemy za pomocą denyhosts. Wygasa również adresy IP, które przez jakiś czas nie próbowały brutalnie używać siły.

Korzystanie z uwierzytelniania za pomocą klucza publicznego i wyłączanie rejestrowania haseł jest prawdopodobnie najlepszą rzeczą, jaką możesz zrobić. Pokonuje wszelkie ataki brutalnej siły.

Co było dla mnie skuteczne:

1. Jak powiedzieli inni, brak logowania roota, PasswordAuthentication ustawione na no (tylko login w / keys) w sshd_config

2. Tylko jeden lub dwóch użytkowników może logować się przez ssh i mają oni quasi-niejasne nazwy, których nie ma na zwykłych listach nazw użytkowników narzędzi brute-force (tj. Nie „admin”, „apache”, „web” lub „ johnny ")

3. Restrykcyjne reguły zapory (w zasadzie wszystko jest zablokowane, ale mój port usługi i ssh). Ograniczam nawet ping, aby odpędzić bardziej prymitywne skany (ku rozczarowaniu mojego partnera).

4. Na moim serwerze internetowym ograniczam dostęp do kilku wybranych adresów IP - ale wygląda na to, że nie jest to dla ciebie opcja. Z pewnością nie mogę tego zrobić samemu na wszystkich naszych hostach. Możesz także przyjrzeć się „pukaniu portów”.

5. I mój ulubiony: moduł aktywnej reakcji OSSEC, aby zablokować szereg warunków brutalnej siły i alarmuje również o innych błędach. Wykrywa x niepoprawne logowanie w określonym czasie, a następnie blokuje (za pomocą komendy iptables firewall-drop) na określony czas. Blokuję od około 12 godzin dla zabawy. :)

Jedną z rzeczy, które robię tutaj, aby upewnić się, że nie blokuję zbyt wiele niewłaściwych rzeczy, jest to, że w /etc/ossec.conf ustawiłem aktywną odpowiedź na wysoki poziom (który nie istnieje w domyślnej konfiguracji), a następnie przejrzyj plik sshd_rules.xml i ustaw reguły, które chcę zablokować, na tym poziomie i zmodyfikuj progi blokowania względem alertu w razie potrzeby.

Jeśli korzystasz z Apache, możesz również blokować treści, które naruszają reguły apache. Nie blokuję ich tylko z powodu problemu z NAT, chcę pomyśleć o zablokowaniu całego uniwersytetu czy coś w tym rodzaju. :) Ponadto możesz pisać niestandardowe reguły, aby blokować określone warunki w plikach dziennika, co może być naprawdę pomocne.