czy fail2ban jest bezpieczny? Lepiej używać kluczy SSH?


11

Mam wątpliwości, czy powinienem użyć uwierzytelniania klucza podczas logowania do SSH, czy po prostu przejść do fail2ban + ssh (logowanie root wyłączone).

Czy fail2ban jest bezpieczny, czy naprawdę lepiej jest po prostu generować klucze i konfigurować je na wszystkich moich komputerach klienckich, które muszą połączyć się z ssh?

Odpowiedzi:


12

Uważam to za produkt stabilny i uważam za bezpieczny. Jako dodatkowy środek ostrożności dodałbym twój źródłowy adres IP do ignoreipdyrektywy, jails.confaby upewnić się, że się nie zablokujesz.

Ponieważ analizuje dzienniki ssh, sesja TCP musi zostać ustanowiona, więc fałszowanie źródłowych adresów IP i poprawianie numerów sekwencji TCP w celu stworzenia pewnego rodzaju wariantu rozpraszania wstecznego wydaje się mało prawdopodobne.

Używanie klawiszy również nie jest złym pomysłem. Inne opcje, które pomagają przenieść ssh do niestandardowego adresu IP, używając „najnowszego” modułu iptables lub po prostu zdecydować, że nie obchodzi cię, czy ludzie próbują wymusić hasła. Zobacz ten post o błędzie serwera, aby uzyskać więcej informacji na ich temat.


4
Instrukcje Fail2Ban mówią, aby nie edytować żadnego z .confplików, a zamiast tego umieszczać konfiguracje w .localplikach. Ułatwia to również aktualizację, ponieważ żaden z plików lokalnych nie jest zastępowany.
Chris S

Chris S: Dzięki za tę wskazówkę ... Spróbuję zanotować :-)
Kyle Brandt

3

Za każdym razem, gdy wdrażam denyhosts lub fail2ban w środowisku produkcyjnym, tworzony jest gwarantowany strumień zgłoszeń żądań odblokowania, żądań resetowania hasła, żądań zmiany ustawień lub zarządzania białą listą i ogólnie tylko osób, które rezygnują z logowania do patrzeć na rzeczy i opierać się bardziej na administratorach rzeczy, które mogliby zrobić sami.

Nie jest to problem techniczny z żadnym narzędziem jako takim, ale jeśli twoi użytkownicy liczą w dziesiątkach lub więcej, będzie to zauważalny wzrost obciążenia wsparcia i sfrustrowanych użytkowników.

Problem, który rozwiązują, polega na tym, że zmniejszają ryzyko ataków logowania ssh brute force. Szczerze mówiąc, ryzyko tego jest niewiarygodnie małe, o ile masz nawet dość przyzwoitą politykę haseł.


1
Na ostatnim serwerze, który umieściłem w sieci, miałem 30k nieudane żądanie logowania do moich logów ... tylko za trzy dni! Nawet przy dobrej polityce haseł, to tylko dobre narzędzie do unikania dużych dzienników i całego hałasu i ryzyka. Używam denyhosts i poprawiam pliki konfiguracyjne, więc ...
Andor

1
Ustawiłem próg na 10 nieudanych prób logowania w ciągu 10 minut (dla SSH, IMAP itp.) I nigdy nie zablokowałem autoryzowanego użytkownika. ustawienia domyślne są nieco ciasne, a użytkownicy czasami je uderzają; wyższe limity zazwyczaj łapią tylko brutalne próby; co zgadzam się, jest mało prawdopodobne, ale zgadzam się również z Andorem, że pomaga to w wielkości dziennika.
Chris S

o nie 10 MB zmarnowanego miejsca na dysku
cagenut

2

Używam od kilku lat i przynajmniej stanowi dobrą ochronę przed dzieciakami ze skryptów.
Brak logowania do roota, a także dość długie i losowe hasła oraz fail2ban i być może inny port jest dla większości z nas wystarczająco bezpieczny.
Oczywiście klucze ssh są znacznie lepsze niż bezpieczeństwo.


0

Używam denyhosts na kilku moich serwerach produkcyjnych i nieprodukcyjnych i działa naprawdę dobrze (miałem problemy z synchronizacją demona, więc nie używam go teraz, ale może znowu działa dobrze).

Nie tylko sprawia, że ​​twój system jest bezpieczniejszy, ale pomaga zachować czystsze logi i po prostu powstrzymać niepożądane osoby przed ekranami logowania ...


0

Od jakiegoś czasu uruchamiam Fail2Ban, a ostatnio widziałem rozproszone próby włamania się na mój serwer SSH. Nigdy nie osiągną sukcesu w takim tempie, w jakim idą, ale pilnowałem tego.

Przeglądali słownik, każde IP próbuje dwa razy, po tych niepowodzeniach kolejne IP robi to samo, itp. Rozważałem zakazanie adresów IP, które próbują x nieznanych nazw użytkowników. Ale do tej pory dostałem kilka tysięcy różnych adresów IP próbujących się dostać; i obawiam się, że nawet jeśli je zablokuję, nadal będzie ich więcej.

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.