Jakie są zalety / wady różnych metod blokowania ataków SSH z użyciem siły?

Istnieje wiele różnych pakietów służących do blokowania adresów IP, z których w systemie uruchamiane są ataki SSH typu brute-force. Na przykład:

• DenyHosts
• Sshguard
• fail2ban

Jakie są zalety / wady tych lub innych?

Moje obecne rozwiązanie polega na pobieraniu wiadomości e-mail, które dziennik generuje codziennie, i zrzucaniu rażących adresów IP do pliku tekstowego, który przesyłam do skryptu, który następnie odbudowuje iptables. Jest hacky, czasochłonny i ręczny, i chciałbym lepszy sposób.

(Pamiętaj, że nie zapytałem, jaki był najlepszy sposób rozwiązania problemu, ponieważ nie ma „najlepszego” sposobu na zrobienie czegokolwiek).

Używam DenyHosts, więc mogę przynajmniej odpowiedzieć na to:

Plusy

• Jest to całkowicie automatyczne
• Jest konfigurowalny (ile nieudanych prób przed umieszczeniem na czarnej liście, dla nazw użytkowników, które nie istnieją, nazw użytkowników, które istnieją, oraz specjalnego wpisu dla użytkownika root)
• Może okresowo wysyłać Ci e-mailem listę hostów na czarnej liście i / lub uruchamiać dany program za każdym razem, gdy nowy host jest na czarnej liście
• Po pewnym czasie obsługuje automatycznie cofanie z czarnej listy hostów

Cons

Nie mam żadnych nieodwracalnych wad, o ile użyjesz go poprawnie:

• W swojej domyślnej konfiguracji nie ostrzega cię przed nowymi hostami z czarnej listy, więc jeśli ktoś atakuje twoją sieć z setek różnych adresów, możesz nie zauważyć od razu, tak jak gdybyś monitorował swoje dzienniki ręcznie, ale (jak wspomniano w sekcja plusy) może wysłać Ci wiadomość e-mail lub uruchomić plik wykonywalny, aby powiadomić Cię o dodaniu nowych hostów
• Domyślnie umieści na czarnej liście twoich hostów tak samo jak każdy inny, więc prawdopodobnie chcesz je dodać /etc/hosts.allow. Zablokowałem się raz, gdy nie udało mi się wpisać hasła, a gdy ktoś z pracy próbował się zalogować na moje konto root jako żart i umieścił na czarnej liście adres IP mojej pracy, zajęło mi kilka dni, aby dowiedzieć się, dlaczego nagle nie mogłem się połączyć do mojej sieci z pracy

Kolejnym jest fail2ban , który opiera się na iptables (więc działa z każdą usługą, nie tylko ssh). Z fail2ban możesz:

• Podaj ścieżkę do dowolnego pliku dziennika (apache, ssh, nginx, serwer pocztowy, ...).
• Określ wyrażenie regularne dla wzorców ataku (np. Ponad 10 „błędów 404” według tego samego adresu IP w dzienniku dostępu nginx w ciągu 6 sekund)
• Określ wyrażenie regularne, aby zignorować określone wzorce (bardzo przydatne!)
• Określ czas zablokowania
• Wyślij wiadomość e-mail (lub inny alert ...)
• W pełni konfigurowalny (możesz pisać własne alerty i filtry)

Jedną „wadą” DenyHosts jest to, że wymaga on owijania tcp, więc będzie działać tylko z usługami, które przeglądają plik /etc/hosts.deny. Ale żeby być sprawiedliwym z DenyHosts, sshd jest skompilowany do używania owijarek TCP w większości dystrybucji Linuksa. Uważam również, że DenyHosts jest łatwiejszy do skonfigurowania od razu po awarii niż fail2ban (ale mniej wydajny).

Odniesienie do podobnego pytania SF

Prostą i praktycznie skuteczną ochroną przed atakami opartymi na skanowaniu jest nieużywanie standardowego portu. 443 (port https) naraża cię na różne ataki siłowe, które nie złamią twoich słabych haseł i prawdopodobnie działają przez więcej zapór ogniowych niż domyślny port (22).

Większość metod zapobiegania atakom z użyciem brutalnej siły ssh to świetne sposoby na samodzielne wykonanie (Ups, zepsułem konfigurację! Ups, zrobiłem kilka szybkich rsync i jestem teraz zbanowany na cały dzień!) Lub Assisted-Self-DoS (Ups , atakujący pochodzi z / zniszczył maszynę w tej samej podsieci co ja (dynamiczny zakres adresów IP, sieć uczelni ...), a ja również zostanę zbanowany!).

Jeśli logujesz się tylko z kilku miejsc, możesz po prostu dodać źródłowe adresy IP do białej listy. To oczywiście nie jest dobre, jeśli chcesz ssh z laptopa lub telefonu komórkowego w podróży.

Posiadanie demona ssh, który nasłuchuje tylko połączeń IPv6, jeszcze przez kilka lat chroni cię przed skanowaniem. Jednak wiele zapór ogniowych nie pozwala na transport IPv6 w żaden rozsądny sposób.

Inną metodą, o której nie wspominasz, jest pukanie portów . Nie cierpi z powodu problemów z samo-DoS (innych niż błędna konfiguracja), ale nie przepuszcza dobrze zapór ogniowych i może zwiększyć opóźnienie o kilka sekund podczas nawiązywania połączenia.

Jeśli masz dobre hasła lub możesz żyć bez uwierzytelniania za pomocą hasła, wyłącz uwierzytelnianie za pomocą hasła. (Klucze i hasła jednorazowe są wystarczające w większości przypadków użycia: jeśli nie ufasz komputerowi klienckiemu wystarczającemu do przechowywania klucza ssh, nie ufasz, że nie ma keyloggera). Wtedy ataki siłowe będą kosztować trochę procesora i przepustowości, ale nie narażaj się na włamanie (o ile sprawdziłeś, że żaden z kluczy nie pochodzi z OpenSSL o niskiej entropii ).

Podsumowując, należy pamiętać, że zmiana portu nie zmniejsza znacząco ekspozycji. Będziesz mniej skanować , ale wszystko, co możesz odciąć, to nisko wiszący owoc, który stara się wykorzystać stare luki i słabe hasła. Tak długo, jak dbasz o aktualność swojego demona i wymuszasz rozsądne hasła lub rozsądne limity częstotliwości prób, zmiana portu jest bardziej odpowiedzialna niż środek bezpieczeństwa.