Fail2Ban Plesk zapewnia skuteczną ochronę przed atakami typu brute force w środowisku serwera Plesk za pomocą zaledwie kilku kliknięć i automatycznie blokuje podejrzane adresy IP. Pokażę ci krok po kroku, jak zainstalować Fail2Ban, aktywować więzienia, dostosować reguły i skonfigurować powiadomienia, aby twoje Serwer pozostaje trwale czysty.
Punkty centralne
Poniższe kluczowe punkty dadzą ci zwięzły przegląd, zanim przejdę do szczegółów i pokażę, jak wdrożyć je w panelu. Jak ustawić właściwy Priorytety od samego początku.
- Instalacja poprzez Narzędzia i ustawienia i natychmiastową aktywację
- Więzienia Używaj specjalnie dla SSH, poczty, panelu Plesk i WordPress.
- Parametry takie jak czas zakazu, okno wykrywania i nieudane próby
- Whitelist Utrzymywanie zaufanych adresów IP i sprawdzanie bloków
- Monitoring dzienników w celu precyzyjnego dostrojenia i zmniejszenia liczby fałszywych alarmów
Co robi Fail2Ban - krótkie wyjaśnienie
Analizy Fail2Ban Protokoły usług, takich jak SSH, poczta, serwer WWW lub panel Plesk i rozpoznaje powtarzające się nieudane próby. Jeśli adres IP przekracza zdefiniowane progi, automatycznie blokuję go na określony czas. W ten sposób niezawodnie zapobiegam atakom brute force, atakom słownikowym i automatycznym skanom przy minimalnym wysiłku. Wydatki. Plesk zapewnia przejrzysty interfejs, w którym mogę włączać i wyłączać więzienia oraz dostosowywać parametry. W przypadku wydajnych serwerów ochrona ta jest jednym z najszybszych środków o zauważalnym działaniu.
Instalacja w Plesk: Wymagania wstępne i start
Używam aktualnego serwera Plesk na Linuxidealnie Obsidian i najpierw sprawdzam, czy komponent Fail2Ban jest już obecny. Jeśli go brakuje, otwieram Narzędzia i ustawienia w Plesku, przechodzę do Aktualizacje i uaktualnienia i wybieram Dodaj/Usuń komponenty. Tam aktywuję wpis Fail2Ban i uruchamiam aplikację Instalacja. Po zakończeniu pojawia się sekcja Blokuj adresy IP (Fail2Ban), w której włączam i monitoruję funkcję. Aby uzyskać pełną konfigurację, łączę Fail2Ban z dobrze skonfigurowanym firewallem; szczegóły można znaleźć na stronie Konfiguracja zapory sieciowej Plesk.
Konfiguracja podstawowa: wybór rozsądnych wartości domyślnych
Po włączeniu sprawdzam parametry globalne, które określają efekt i fałszywe alarmy. Ze zrównoważonym Czas zakazu Chronię atakujących bez trwałego blokowania legalnych użytkowników. Okno wykrywania kontroluje, jak długo Fail2Ban zbiera nieudane próby, a maksymalna liczba nieudanych prób określa próg blokowania. Wprowadzam również adres e-mail do powiadomień, dzięki czemu mogę natychmiast zobaczyć krytyczne zdarzenia. Poniższa tabela przedstawia typowe wartości początkowe, które sprawdziły się w wielu konfiguracjach i mogą być udoskonalane w dowolnym momencie.
| Parametry | Zalecenie | Efekt |
|---|---|---|
| Czas zakazu | 600-1800 sekund | Zauważalnie blokuje atakujących bez trwałego blokowania użytkowników |
| Okno rozpoznawania | 300-600 sekund | Zbiorcze testy w rozsądnym czasie |
| Max. Nieudane próby | 3-5 | Zmniejsza liczbę fałszywych alarmów i nadal pozostaje rygorystyczna |
| Powiadomienie | Aktywuj e-mail | Ostrzeżenia o blokadach i ważnych wydarzeniach |
Ponadto, na samym początku definiuję plik Lista ignorowanych (biała lista) na poziomie globalnym. W sekcji Narzędzia i ustawienia > Blokuj adresy IP wprowadzam statyczne adresy IP biura, punkty końcowe VPN lub sieci zarządzania. W przypadku IPv6 używam spójnych prefiksów (np. /64) z ostrożnością i utrzymuję listę szczupłą, aby nie osłabiać ochrony. W przypadku powtarzających się problemów, a Przyrostowy czas zakazu udowodnione: Z parametrami takimi jak np. bantime.increment = true, bantime.factor oraz bantime.maxtime Automatycznie przedłużam blokady, jeśli są powtarzane, zapewniając w ten sposób trwały efekt.
Więzienia: ukierunkowana ochrona usług
W zakładce Więzienia aktywuję reguły ochrony dla najważniejszych z nich Usługi: sshd, dovecot, proftpd, plesk-apache, plesk-panel i plesk-wordpress. Każde więzienie monitoruje pasujące pliki dziennika, rozpoznaje wzorce i blokuje rzucające się w oczy adresy IP. W przypadku serwerów z instancjami WordPressa włączam plesk-wordpress, aby zablokować ataki logowania na wp-login i xmlrpc. Jeśli nie jest uruchomiony żaden FTP, dezaktywuję powiązane więzienie, aby serwer nie wykonywał żadnych niepotrzebnych kontroli. Następnie sprawdzam, czy bloki działają niezawodnie i dostosowuję wartości progowe, jeśli jest zbyt wiele fałszywych alarmów.
Dla orientacji: sshd zazwyczaj odczytuje z /var/log/auth.log (Debian/Ubuntu) lub /var/log/secure (RHEL/Alma/Rocky), loginy do poczty trafiają do katalogu /var/log/maillog Odpowiednio /var/log/mail.logpanel loguje się /var/log/plesk/panel.log. W przypadku ataków internetowych więzienia Plesk uzyskują dostęp do dzienników hostów wirtualnych pod adresem /var/www/vhosts/system//logs/ do. Jeśli korzystasz tylko z NGINX lub konfiguracji Apache+NGINX, filtry Plesk będą nadal działać, ponieważ odpowiednie ścieżki są już zapisane.
Czyste tworzenie własnych więzień i filtrów
Czy potrzebuję dodatkowych Ochrona Dla aplikacji tworzę nowe więzienie i odwołuję się do powiązanych dzienników. Definiuję wyraźne okno czasowe, ustawiam limit awarii i określam pożądany czas zakazu. Dla specjalnych aplikacji piszę filtry z wyrażeniami regularnymi, które rozpoznają określone komunikaty o błędach. Po aktywowaniu reguły testuję ją, symulując nieudaną próbę, a następnie sprawdzając dzienniki. Jeśli zauważę wzorzec, który atakujący mogą ominąć, udoskonalam filtr i rejestruję zmianę dla moich potrzeb. Dokumentacja.
Aby zapewnić, że dostosowania pozostaną bezpieczne dla aktualizacji, tworzę Własne konfiguracje w /etc/fail2ban/jail.d/ jako oddzielne pliki (np. custom-wordpress.local) zamiast zmieniać standardowe pliki. W ten sposób aktualizacja Plesk lub pakietu nie nadpisuje moich reguł. Testuję reguły filtrowania za pomocą fail2ban-regex z przykładowymi logami przed przełączeniem więzienia na produktywne. Po wprowadzeniu zmian systemctl reload fail2banaby uaktywnić je bez twardego restartu.
Biała lista, odblokowanie i zrozumienie zablokowanych adresów IP
Jeśli zablokuję siebie lub członka zespołu, otwieram listę zablokowanych adresów IP i ponownie odblokowuję adres. W przypadku stale zaufanych źródeł korzystam z białej listy i w ten sposób zapobiegam przyszłym atakom. Blokady. W przeglądzie mogę zobaczyć, które więzienie zablokowało IP i dla jakiej reguły zostało wykryte. Informacje te pomagają mi rozpoznać źle skonfigurowane aplikacje lub boty. Utrzymuję białą listę szczupłą i utrzymuję wpisy tylko wtedy, gdy istnieje ku temu dobry powód. Powód tam.
Czy pracujesz za Proxy/CDNZwracam szczególną uwagę na białą listę: Jeśli logowania i dostępy webowe są za IP odwrotnego proxy z punktu widzenia serwera, to niedbale skonfigurowany jail w najgorszym wypadku zablokuje proxy zamiast faktycznego atakującego. W takim przypadku upewniam się, że serwer WWW poprawnie zapisuje "prawdziwe" IP klienta w logach (mechanizm X-Forwarded-For/Actual Real-IP) i utrzymuje sieci proxy jako godne zaufania. Zapewnia to, że bloki pozostają dokładne.
Unikanie błędów: rozsądne dostrajanie na podstawie praktyki
Zaczynam od umiarkowanego Progi i zaostrzam wartości tylko wtedy, gdy znam typowe profile obciążenia i użytkowania. W przypadku hostów współdzielonych z wieloma użytkownikami ryzyko fałszywych bloków wzrasta, więc ustawiam MaxRetry na wyższym poziomie i dokładniej monitoruję logi. Jeśli boty docierają do formularzy, warto przyjrzeć się dziennikom serwera WWW i dodatkowym regułom w więzieniu plesk-apache. Skonfigurowałem 2FA dla loginów administratora i w ten sposób odciążyłem Fail2Ban, ponieważ mniej prób logowania dociera do panelu. Regularne przeglądanie listy blokad pokazuje mi, czy dana osoba Źródło jest szczególnie widoczna i wymaga więcej środków.
Połączenie zapory sieciowej i hartowanie WordPressa
Fail2Ban blokuje atakujących po nieudanych próbach, podczas gdy firewall z wyprzedzeniem zmniejsza powierzchnię ataku. Oba rozwiązania razem zapewniają zauważalnie więcej Bezpieczeństwozwłaszcza z odsłoniętymi portami SSH lub poczty. W przypadku WordPressa ograniczam xmlrpc, ustawiam limit szybkości logowania na poziomie aplikacji i pozwalam plesk-wordpress wykonać resztę pracy. Daje to dogłębną obronę zamiast pojedynczej bariery. Bardziej szczegółowe porównanie można znaleźć w tym artykule: Porównanie Fail2Ban i firewallaktóry pomoże w koordynacji działań.
Praktyczna kontrola dla administratorów Plesk
Po skonfigurowaniu sprawdzam, czy blokady występują w oczekiwanym oknie czasowym i czy przychodzą powiadomienia e-mail. Następnie testuję SSH z celowo niepoprawnymi hasłami i sprawdzam logi, aby zweryfikować skuteczność blokady. Więzienia aby potwierdzić. W przypadku panelu Plesk symuluję kilka nieudanych logowań i obserwuję, czy adres IP jest szybko blokowany. Jeśli pojawia się zbyt wiele legalnych blokad, zwiększam MaxRetry krok po kroku i umiarkowanie rozszerzam okno wykrywania. Takie konsekwentne podejście ogranicza fałszywe alarmy do minimum i zapewnia spokój. Działanie.
Integracja hostingu: na co zwracam uwagę
Silna konfiguracja hostingu zapewnia Fail2Ban, firewall, kopie zapasowe i monitorowanie w spójny sposób. Zwracam uwagę na bezpośrednią integrację z Plesk, krótkie czasy reakcji w pomocy technicznej i przejrzystość. Dokumentacja. Dostawcy z izolowanymi kontenerami usług i spójnymi aktualizacjami jądra zapewniają mi dodatkowe bezpieczeństwo. W przypadku produktywnych projektów polegam również na kopiach zapasowych poza siedzibą firmy, dzięki czemu mogę szybko wrócić do trybu online w sytuacji awaryjnej. Tworzy to poziom bezpieczeństwa, który znacznie utrudnia ataki i może być realizowany przy rozsądnym poziomie bezpieczeństwa. Wydatki można utrzymać.
Monitorowanie i rozwiązywanie problemów: jak być na bieżąco?
Regularnie analizuję przegląd Fail2Ban, sprawdzam zablokowane konta Adresy i rozpoznaję powtarzające się źródła. Jeśli znajdę wzorce, dostosowuję reguły filtrowania i dokumentuję zmiany, aby móc je później śledzić. Jeśli dzienniki pokazują duże obciążenia, ustawiam dodatkowe limity na serwerze WWW i zaostrzam zaporę. Jednocześnie dbam o świeżość Plesk, pakietów systemowych i wtyczek, aby zminimalizować powierzchnie ataku; wypróbowane i przetestowane wskazówki można znaleźć w tym przewodniku po Usuwanie luk w zabezpieczeniach Plesk. Dzięki temu ochrona jest aktualna, a Fail2Ban potrzebuje mniej Praca wykonać.
Backendy protokołów i ścieżki w Plesk
Aby zapewnić niezawodne wykrywanie, ważne jest, aby Fail2Ban miał prawidłowe Źródła protokołów czyta. W systemie Linux używam dzienników plików lub zaplecza systemd, w zależności od dystrybucji. Nowoczesne konfiguracje korzystają z backend = systemdponieważ Fail2Ban odczytuje dziennik bezpośrednio i generuje mniej I/O na plikach dziennika. Plesk ma już sensowne ustawienia domyślne w tym zakresie. Niemniej jednak losowo sprawdzam, czy ścieżki dziennika w więzieniach są zgodne z rzeczywistością: SSH w /var/log/auth.log (Debian/Ubuntu) lub /var/log/secure (RHEL/Alma/Rocky), Mail in /var/log/maillog lub /var/log/mail.logPanel Plesk w /var/log/plesk/panel.logWeb w katalogach vhost. Jeśli ścieżki lub nazwy dzienników nie są poprawne, poprawiam wpisy w osobnym pliku .local-plik. W ten sposób unikam martwych punktów, w których ataki pozostają niewykryte.
Zaplecze IPv6, banaction i firewall
Wiele instalacji nie filtruje już tylko IPv4. Upewniam się, że Działania są odpowiednie dla IPv6 (np. warianty wieloportowe dla iptables/firewalld). Jeśli system korzysta z Firewalld, zwracam uwagę na działania takie jak firewallcmd-multiportdla klasycznych konfiguracji iptables do iptables-multiport lub akcje oparte na ipset dla lepszej wydajności. Ważne jest, aby akcja używana w Fail2Ban pasowała do aktywnej zapory Plesk - w przeciwnym razie bloki trafiają do niewłaściwego łańcucha lub w ogóle nie działają. Po zmianach testuję w szczególności: symulowane nieudane próby z testowego adresu IP, zapytanie o stan więzienia, a następnie test połączenia. Jeśli bloki IPv6 działają niezawodnie, wypełniłem istotną lukę, która jest często pomijana w sieciach mieszanych.
Nasilające się blokady i długotrwałe blokady (recydywa)
Z powtarzającymi się napastnikami zwiększam presję: z przyrostowe czasy zakazu (bantime.increment) blokady są automatycznie przedłużane - w przybliżeniu dwukrotnie przez bantime.factor = 2 - do rozsądnego maksimum (bantime.maxtime). Używam również recydywa - więzienie która wykrywa adresy IP pojawiające się kilka razy w różnych więzieniach w dłuższym oknie. Konfiguracja z findtime w przedziale od godzin do dni, a kilkudniowy okres banowania okazał się skuteczny. Poziom ten ma trwały wpływ na boty, które regularnie powracają, bez trwałego wykluczania legalnych użytkowników. Nadal ważne jest korzystanie z godnych zaufania sieci za pośrednictwem ignoreip i mieć oko na efekty za pośrednictwem czarnej listy.
Przepływ pracy CLI: sprawdzenie, przeładowanie, odblokowanie
Mimo że Plesk oferuje wygodny interfejs, rozwiązałem wiele szybki za pośrednictwem konsoli. Z fail2ban-client status Widzę aktywne więzienia, fail2ban-client status zawiera listę zablokowanych adresów IP i liczników. Ładuję nowe reguły za pomocą systemctl reload fail2banW razie potrzeby ponownie uruchamiam usługę. Usuwam poszczególne adresy IP (fail2ban-client set unbanip) bez wpływu na cały system. Do rozwiązywania problemów journalctl -u fail2banaby przeczytać najnowsze wydarzenia, w tym informacje o wadliwych filtrach. Pozwala mi to utrzymać operacje na niskim poziomie, krótko dokumentować interwencje i przekazywać ustalenia z powrotem do reguł.
Działanie za proxy/CDN, ModSecurity i szczegóły WordPressa
Wiele stron internetowych jest dziś zawieszonych Odwrotne proxy lub CDN. Aby upewnić się, że Fail2Ban ocenia prawdziwego klienta, upewniam się, że serwer WWW odnotowuje prawidłowy adres IP w dzienniku i że sieci proxy znajdują się na białej liście. W przeciwnym razie ryzykuję niezamierzone zablokowanie całych sieci brzegowych. W Plesk używam również ModSecurity (WAF): ModSecurity blokuje znane wzorce ataków na poziomie HTTP, podczas gdy Fail2Ban sankcjonuje nieudane próby logowania lub powtarzające się wzorce 4xx/5xx. W przypadku WordPressa stosuję podejście dwutorowe: ograniczam lub zabezpieczam xmlrpc, ustawiam limity szybkości logowania na poziomie aplikacji i używam narzędzia plesk-wordpress-jail active. W ten sposób pozbywam się szumu w dzienniku i pozwalam Fail2Ban celować w trudne przypadki.
Konserwacja, kopie zapasowe i strategia aktualizacji
Aby zapewnić trwałość regulacji w dłuższej perspektywie, przechowuję wszystkie własne zasady w oddzielnych plikach pod /etc/fail2ban/jail.d/ i dokumentuję zmiany wersji. Przed większymi aktualizacjami Plesk lub systemu tworzę migawkę / kopię zapasową, a następnie losowo sprawdzam, czy więzienia są nadal aktywne, a ścieżki są prawidłowe. Biorę również pod uwagę rotacje logów: po uruchomieniu rotacji (nowy plik dziennika) backend powinien nadal niezawodnie odczytywać - dzięki systemd-Journal ta obawa jest w dużej mierze wyeliminowana. Ustalam krótkie procedury SOP dla zespołów: w jaki sposób IP są odbanowane, progi są dostosowywane, a powiadomienia sprawdzane. Zapewnia to, że obsługa pozostaje spójna, nawet gdy zmieniają się obowiązki.
Ocena prawna: protokoły i przechowywanie
Bezpieczeństwo również wymaga Wymiar. Przechowuję tylko te informacje, które są niezbędne do obrony i diagnozy, ustawiam jasne okresy przechowywania i regularnie usuwam stare dane. Sam Fail2Ban nie przechowuje żadnych długoterminowych danych; podstawą są dzienniki systemowe i internetowe. Zmniejszony poziom dziennika w regularnej pracy (np. INFO) utrzymuje ilość danych w zarządzaniu, podczas gdy tymczasowo zwiększam go do DEBUG do analiz, a następnie przełączam się z powrotem. W ten sposób łączę skuteczną ochronę ze szczupłą, identyfikowalną ścieżką danych.
W skrócie: bezpieczne wdrożenie za pomocą kilku kliknięć
Aktywuję Fail2Ban przez Plesk, ustawiam zrównoważone parametry, włączam odpowiednie Więzienia i utrzymuję szczupłą białą listę. Dzięki uzupełniającej zaporze sieciowej, 2FA i czystym aktualizacjom osiągam wysoki poziom ochrony bez balastu. Dostosowane filtry dają mi kontrolę nad szczególnymi przypadkami, a powiadomienia i dzienniki upraszczają moją codzienną pracę. Jeśli weźmiesz sobie te kroki do serca, wyraźnie zmniejszysz liczbę prób siłowych i skutecznie ochronisz loginy administratora, pocztę i SSH. Jak zabezpieczyć serwer Plesk za pomocą Fail2Ban trwale odporny i łatwy w podawaniu.


