Czy warto blokować nieudane próby logowania?

Czy warto uruchamiać fail2ban , sshdfilter lub podobne narzędzia, które na czarnej liście adresów IP próbują się nie udać?

Widziałem, jak argumentuje, że jest to teatr bezpieczeństwa na „odpowiednio zabezpieczonym” serwerze. Wydaje mi się jednak, że prawdopodobnie powoduje to, że dzieciaki ze skryptów przechodzą na następny serwer na liście.

Powiedzmy, że mój serwer jest „odpowiednio zabezpieczony” i nie martwię się, że atak z użyciem siły brutalnej rzeczywiście się powiedzie - czy te narzędzia po prostu utrzymują moje pliki dziennika w czystości, czy też czerpię jakąś korzyść z blokowania prób ataku z użyciem siły brutalnej?

Aktualizacja : Wiele komentarzy na temat odgadywania haseł przez brutalną siłę - wspomniałem, że nie martwiłem się tym. Być może powinienem był sprecyzować i zapytać, czy fail2ban ma jakieś zalety dla serwera, który pozwala tylko na logowanie ssh oparte na kluczach.

Próby logowania ograniczające szybkość to łatwy sposób, aby zapobiec niektórym szybkim atakom polegającym na zgadywaniu hasła. Jednak trudno jest ograniczyć rozproszone ataki i wiele z nich działa w wolnym tempie przez tygodnie lub miesiące. Osobiście wolę unikać używania narzędzi do automatycznej odpowiedzi, takich jak fail2ban. A to z dwóch powodów:

1. Uprawnieni użytkownicy czasami zapominają hasła. Nie chcę banować legalnych użytkowników z mojego serwera, zmuszając mnie do ręcznego włączenia ich kont (lub, co gorsza, spróbuj dowiedzieć się, który z 100/1000 zablokowanych adresów IP należy do nich).
2. Adres IP nie jest dobrym identyfikatorem dla użytkownika. Jeśli masz wielu użytkowników za jednym adresem IP (na przykład szkołą, w której działa NAT na 500 maszynach studenckich), jeden użytkownik, który zgadnie kilka zgadnięć, może wprawić cię w ból. Jednocześnie większość prób odgadnięcia hasła, które widzę, są dystrybuowane.

Dlatego nie uważam, że fail2ban (i podobne narzędzia do automatycznej reakcji) to bardzo dobre podejście do zabezpieczenia serwera przed atakami siłowymi. Proste reguły IPTables ustawione na ograniczenie spamu w dzienniku (który mam na większości moich serwerów Linux) jest mniej więcej takie:

iptables -I INPUT -p tcp --dport 22 -i eth0 -m state --state NEW -m recent --set
iptables -I INPUT -p tcp --dport 22 -i eth0 -m state --state NEW -m recent --update --seconds 60 --hitcount 4 -j DROP

Zapobiega ponad 4 próbom połączenia z jednego adresu IP do ssh w dowolnym okresie 60 sekund. Resztę można rozwiązać, upewniając się, że hasła są wystarczająco silne. Na serwerach o wysokim poziomie bezpieczeństwa zmuszanie użytkowników do korzystania z uwierzytelniania za pomocą klucza publicznego to kolejny sposób na zatrzymanie zgadywania.

Narzędzia takie jak fail2ban pomagają zmniejszyć niepotrzebny ruch w sieci i utrzymać pliki dzienników nieco mniejsze i czystsze. To nie jest duże uzdrowienie bezpieczeństwa, ale sprawia, że ​​życie sysadmin jest trochę łatwiejsze; dlatego polecam korzystanie z fail2ban w systemach, na które możesz sobie pozwolić.

Nie chodzi tylko o ograniczenie hałasu - większość ataków ssh próbuje odgadnąć hasła przy użyciu siły. Więc chociaż zobaczysz wiele nieudanych prób ssh, być może do 2034. próby dostaną prawidłową nazwę użytkownika / hasło.

Zaletą fail2ban w porównaniu z innymi podejściami jest to, że ma minimalny wpływ na prawidłowe próby połączeń.

Cóż, to nieco chroni twoją sieć przed atakami typu „odmowa” i oszczędza na kosztach przetwarzania awarii.

Bycie najsłabszym serwerem na liście skryptu dla dzieci jest zawsze dobrą rzeczą.

Przykro mi, ale powiedziałbym, że twój serwer jest odpowiednio zabezpieczony, jeśli sshd odmówi próby uwierzytelnienia za pomocą haseł.

PasswordAuthentication no