Konfiguruję serwer LAMP i muszę zapobiec SSH / FTP / itp. Brute-Force Logon próbuje odnieść sukces. Widziałem wiele rekomendacji zarówno dla denyhosts, jak i fail2ban, ale niewiele porównań tych dwóch. Przeczytałem również, że reguła IPTables może pełnić tę samą funkcję.
Dlaczego miałbym wybrać jedną z tych metod zamiast innej? Jak ludzie po awarii serwera radzą sobie z tym problemem?
Odpowiedzi:
IIRC, DenyHosts będą oglądać tylko Twoją usługę SSH. Jeśli potrzebujesz go również do ochrony innych usług, Fail2ban jest zdecydowanie lepszym wyborem. Można dostosować prawie każdą usługę, jeśli chcesz dostosować jej konfigurację, ale nie powinno to być konieczne, ponieważ nowsze wersje Fail2ban zawierają zestawy reguł, które są odpowiednie dla wielu popularnych demonów serwerów. Używanie fail2ban w stosunku do zwykłego limitu prędkości iptables ma tę zaletę, że całkowicie blokuje atakującego na określony czas, zamiast po prostu zmniejszać szybkość, z jaką może on wbić twój serwer. Użyłem fail2ban z doskonałymi wynikami na wielu serwerach produkcyjnych i nigdy nie widziałem żadnego z tych serwerów, który został naruszony przez atak siłowy, odkąd zacząłem go używać.
Nie pozwól im dostać się na twoją maszynę! Istnieje wiele sposobów na powstrzymanie prób użycia siły, zanim dotrą do twojego hosta, a nawet na poziomie SSH.
To powiedziawszy, ochrona systemu operacyjnego czymś w rodzaju fail2ban to świetny pomysł. Fail2ban różni się nieco od DenyHosts, choć grają w tym samym miejscu. Fail2ban używa iptables.
http://en.wikipedia.org/wiki/Fail2ban
Fail2ban jest podobny do DenyHosts ... ale w przeciwieństwie do DenyHosts, który koncentruje się na SSH, fail2ban może być skonfigurowany do monitorowania dowolnej usługi zapisującej próby logowania do pliku dziennika i zamiast używać /etc/hosts.deny tylko do blokowania adresów IP / hostów , fail2ban może używać Netfilter / iptables i TCP Wrappers /etc/hosts.deny.
Istnieje wiele ważnych technik bezpieczeństwa, które należy wziąć pod uwagę, aby zapobiec logowaniu przy użyciu siły brute:
SSH:
Podanie:
Używam reguł iptables, aby ograniczać szybkość nowych połączeń z tego samego adresu IP (głównie SSH, ale zadziałałoby to również w przypadku FTP). Zaletą, jak widzę, w porównaniu z „fail2ban” i innymi tego typu narzędziami jest to, że trasa iptables odbywa się całkowicie w trybie jądra i nie polega na narzędziach trybu użytkownika do ogłaszania / analizowania plików dziennika.
Jeśli możesz to zrobić, ograniczenie adresów źródłowych, które mają dostęp do danych protokołów, również oczywiście pomoże.
Dzięki SSH naprawdę powinieneś używać uwierzytelniania certyfikatów i nie akceptować haseł.
KOLEJNY WIELKI SPOSÓB ZABEZPIECZENIA SSH (korzystam z niego od dekady lub lepiej) to korzystanie z najnowszych bibliotek w iptables natywnie (w zależności od dystrybucji).
Zasadniczo może być używany jako pukanie portów wbudowane w iptables. Pozwoli ci to zaoszczędzić mnóstwo bólu głowy. Tak długo, jak można połączyć się z tcp (telnet jest jednym ze sposobów. Użyłem również klientów ssh i wskazałem im port. Wszystko, co wykona połączenie tcp z określonym numerem portu. Patrzę na ciebie Putty!) Z klient inicjujący połączenie ssh możesz tego użyć.
Poniżej znajduje się przykład, w którym iptables otworzy port 22 na twoim hoście, kiedy telnet z twojego hosta na serwer na porcie 4103. Następnie możesz użyć telnetu do portu 4102 lub 4104, aby zamknąć otwarcie. Powodem zarówno dla 4102, jak i 4104 jest powstrzymanie prostego skanowania tcp od otwarcia 22. Tylko połączenie tcp (telnet) z portem 4103 pozwoli ci wejść.
Cieszyć się!
Och i ja faworyzuję Fail2Ban. Większa elastyczność i podoba mi się to, że zakaz występuje w iptables, a nie w tcpwrappers.
iptables -A INPUT -m state --state NEW -m tcp -p tcp --dport 22 -m recent --rcheck --name SSH -j ACCEPT
iptables -A INPUT -m state --state NEW -m tcp -p tcp --dport 4102 -m recent --name SSH --remove -j DROP
iptables -A INPUT -m state --state NEW -m tcp -p tcp --dport 4103 -m recent --name SSH --set -j DROP
iptables -A INPUT -m state --state NEW -m tcp -p tcp --dport 4104 -m recent --name SSH --remove -j DROP
Inną różnicą między Fail2ban a Denyhosts jest to, że Denyhosts może współdzielić listę bloków z innymi użytkownikami Denyhosts. Dzięki Fail2ban możesz blokować tylko adresy IP, które wcześniej widział twój serwer - w przypadku Denyhosts próba brutalnej siły może nigdy nie dostać się na twój serwer, jeśli ktoś go widział, a lista bloków jest pobierana na Twój serwer przed atakującym dostaje się do twojego komputera.
Jeszcze inna różnica polega na tym, że Fail2ban używa iptables, podczas gdy Denyhosts używa tcpwrappers. Inni wspominali już o tej różnicy, ale warto wspomnieć o kilku dodatkowych notatkach.
iptables ma ograniczoną liczbę adresów IP, które można skutecznie blokować. To prawdopodobnie jeden z powodów, dla których Fail2ban nie ma mechanizmu udostępniania list bloków.
Innym efektem jest to, że po zastąpieniu iptables przez nftables, Fail2ban prawdopodobnie przestanie działać lub będzie musiał zostać przepisany. Denyhosts prawdopodobnie nadal będzie działać.
Oba mają więc zalety i wady. Lubię oba; dla siebie używam Denyhosts, ponieważ zazwyczaj chcę tylko chronić SSH i lubię udostępniać listę bloków.
Jedną z rzeczy, o których należy pamiętać w przypadku Fail2Ban, jest to, że wydaje się, że zużywa około 10 MB więcej pamięci niż DenyHosts. Więc jeśli korzystasz z VPS o pojemności 128 MB, możesz chcieć to sprawdzić. Poza tym domyślny fail2ban jest instalowany tylko na SSH, co oznacza, że bez zmian w konfiguracji - DenyHosts robi to samo w mniejszej ilości pamięci.
denyhosts jest dla ssh. fail2ban jest bardziej wszechstronny (HTTP, FTP itp.). Oba używają iptables za kulisami.
Zamiast zadzierać z żmudną konfiguracją iptables lub fail2ban, dlaczego otwarta społeczność nie wykona za ciebie całej pracy i zamiast tego używa CSF / LFD? Mogę gorąco polecić to przede wszystkim inne wspomniane opcje. Zobacz http://configserver.com/cp/csf.html, aby dowiedzieć się, co może zrobić dla twoich serwerów. CSF nie wymaga panelu sterowania, oferuje prosty interfejs użytkownika dla tych, którzy nie chcą tego robić za pomocą powłoki. I to jest dużo stabilnych i niezawodnych nierezydentnych skryptów perlowych.
wydaje się, że fail2ban nie ma mechanizmu rozpoznawania udanego logowania ssh i resetowania liczby błędów.
Standardowy filtr dla sshd (przynajmniej w mojej instalacji Debiana), rejestruje liczbę błędów dla każdego klucza ssh, który klient przedstawia, który serwer odrzuca. Niektórzy użytkownicy przedstawiają wiele kluczy przy każdym logowaniu i regularnie się blokują, mimo że ich logowanie powiodło się po przejściu kilku kluczy.
W związku z powyższym obecnie myślę o odejściu od fail2ban. Przynajmniej pod tym względem lepsze jest denyhosts. Jednak najwyraźniej nie jest to już dobra opcja i nie jest już obsługiwana w nowszych wersjach debiana (niektóre dyskusje na https://www.chrissearle.org/2015/06/16/replacing-denyhosts-w-fail2ban-for- debian / )
Nie mam tutaj dobrego rozwiązania.
Właściwie myślę, że denyHost jest w stanie zapobiec wielu innym usługom oprócz usługi sshd. W jego pliku konfiguracyjnym /etc/denyhosts.confznajduje się kilka wierszy kodu:
# BLOCK_SERVICE: the service name that should be blocked in HOSTS_DENY
#
# man 5 hosts_access for details
#
# eg. sshd: 127.0.0.1 # will block sshd logins from 127.0.0.1
#
# To block all services for the offending host:
BLOCK_SERVICE = ALL
# To block only sshd:
# BLOCK_SERVICE = sshd
więc jeśli ustawimy BLOCK_SERVICEzmienną na ALLpowyżej, możemy oglądać naszą usługę ssh.
Denyhosts wersja 3.0: Za każdym razem, gdy adres IP pojawia się w pliku dziennika, Denyhosts otwiera plik hosts.deny i odczytuje całą treść odpowiadającą adresowi. Każdego razu. Nic nie jest buforowane w pamięci. Jeśli masz ogromny plik hosts.deny i podlegasz wielu sondom (wiele wpisów w pliku dziennika), Denyhosts staje się procesorem, który czyta i ponownie odczytuje plik hosts.deny dla każdego wyświetlanego adresu IP. Niedobrze.
Jeśli włączysz obsługę iptables, Denyhosts utworzy ogromne, wolne listy zablokowanych adresów IP. Denyhosts nie używa ipset ani nftables do tworzenia wydajnych map IP.