Zapobieganie brutalnym atakom na ssh?

Jakiego narzędzia lub techniki używasz, aby zapobiec atakom siłowym na twój port ssh. Zauważyłem w moich dziennikach bezpieczeństwa, że ​​mam miliony prób zalogowania się za pomocą ssh jako różni użytkownicy.

To jest na pudełku FreeBSD, ale wyobrażam sobie, że miałoby to zastosowanie wszędzie.

Oto dobry post na ten temat autorstwa Rainera Wichmanna.

Wyjaśnia zalety i wady tych metod, aby to zrobić:

• Silne hasła
• Uwierzytelnianie RSA
• Użycie „iptables” do zablokowania ataku
• Używanie dziennika sshd do blokowania ataków
• Używanie tcp_wrappers do blokowania ataków
• Pukanie do portu

Używam fail2ban, który zablokuje IP po kilku nieudanych próbach przez konfigurowalny okres czasu.

Połącz to z testowaniem siły hasła (używając Johna (Rozpruwacza)), aby upewnić się, że ataki siłowe nie powiodą się.

Jedyną rzeczą, którą możesz zrobić, to użyć czegoś takiego jak DenyHosts:

http://denyhosts.sourceforge.net/

Wykorzystuje wbudowane hosts.allow / hosts.deny do blokowania nadużyć SSH.

• Zmień używany port (jak wspomniano w Trydencie )
• Wymagaj kluczy szyfrowania zamiast haseł. http://novosial.org/openssh/publickey-auth/
• IPS atakujący z czarnej listy
• Dodaj znanych użytkowników do białej listy, aby zapobiec przypadkowej czarnej liście. (jak wspomniała Samiuela)

Jednym z najprostszych sposobów uniknięcia tych ataków jest zmiana portu, na którym nasłuchuje sshd

Jak podkreśla Chris, używaj kluczy szyfrujących zamiast haseł.

Dodaj do tego:

• w miarę możliwości użyj białej listy.

Ile osób lub lokalizacji (z ruchomymi publicznymi adresami IP) naprawdę potrzebujesz dostępu do swoich publicznych połączeń ssh?

W zależności od liczby utrzymywanych publicznych hostów ssh i od tego, czy można zawęzić ogólne kryteria połączenia, może być prostsza konfigurowalna konfiguracja, aby ograniczyć dostęp do kilku hostów zewnętrznych.

Jeśli to działa, może naprawdę uprościć narzuty administracyjne.

Oprócz innych dobrych sugestii, jedną naprawdę łatwą rzeczą jest ograniczenie połączeń przychodzących. Ogranicz do 3 połączeń na minutę na IP:

iptables -A INPUT -p tcp --dport 22 -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m limit --limit 3/min --limit-burst 3 -j ACCEPT
iptables -A INPUT -p tcp --dport 22 -j DROP

Użyj opcji „AllowUsers” w sshd_config, aby mieć pewność, że tylko niewielka grupa użytkowników może się w ogóle zalogować. Wszystkie pozostałe zostaną odrzucone, nawet jeśli ich nazwa użytkownika i hasło są prawidłowe.

Można nawet ograniczyć dostęp użytkowników do logowania z danego hosta.

na przykład,

AllowUsers user1 [email protected]

Spowoduje to zmniejszenie przestrzeni wyszukiwania i uniknie tych starych użytkowników, którzy przypadkowo zostali pozostawieni lub zostali włączeni (chociaż ci i tak powinni zostać wyłączeni, jest to łatwy sposób, aby powstrzymać ich przed wykorzystywaniem do wpisu opartego na SSH).

To nie całkowicie powstrzymuje ataki brutalnej siły, ale pomaga zmniejszyć ryzyko.

Użyj czegoś takiego z PF:

tabela <ssh-brute>
trwa blok w szybkim dzienniku z etykiety ssh_brute
przekazać proto $ ext_if proto tcp do ($ ext_if) port ssh modulować stan \
(max-src-conn-rate 3/10, przeciążenie globalne)

Pukanie portów jest dość solidnym sposobem na uniknięcie tego rodzaju problemów. Nieco skrzypiące, czasem irytujące, ale zdecydowanie to rozwiązuje problem.

Kontekst jest ważny, ale poleciłbym coś takiego:

• Ponieważ korzystasz z FreeBSD, rozważ uruchomienie zapory ogniowej PF i skorzystanie z jej funkcji ograniczających szybkość stałego połączenia. Umożliwi to wysyłanie brutalnych siłowników na czarną listę, jeśli często się łączą
• Jeśli do tego pola trzeba uzyskać dostęp ze świata zewnętrznego, rozważ użycie reguły rdr PF, aby nie zezwalać na ruch do portu 22, ale przekierować do niego jakiś niejasny port. Oznacza to, że musisz połączyć się z portem 9122 zamiast 22. Jest to niejasne, ale nie pozwala na dostęp do kołatek
• rozważ przejście tylko na uwierzytelnianie oparte na kluczach, dzięki czemu ataki słownikowe będą bezużyteczne

Oprócz sugestii ograniczającej szybkość Sherbanga ważna jest długość opóźnienia. Zwiększając opóźnienie między grupami 3 prób logowania z 2 minut do 20 minut, liczba różnych adresów IP, które spowodowały więcej niż trzy próby logowania, spadła, porównując dwa tygodniowe okresy na jednym komputerze, z 44 prób do 3 Żaden z tych trzech adresów nie próbował przez dłużej niż 11 godzin.

Bardzo niepotwierdzona, ale auth.log stał się dla mnie o wiele bardziej czytelny ...

Po prostu mnie to nie obchodzi. Pozwólcie im odpłynąć do portu, nie będą brutalnie naciskać klucza.

zainstaluj OSSEC. nie tylko monitoruje powtarzające się logowanie, ale również wprowadzi tymczasowy blok z iptables dla niepoprawnego adresu IP. A na koniec wyśle ​​ci raport z podaniem szczegółów. rejestruje wszystko, co jest miłe. Ktoś kiedyś próbował ponad 8000 nazw logowania, aby się zalogować. przeanalizowałem dzienniki i nie znalazłem fajnej listy użytkowników;)