...

Jak skonfigurować Fail2Ban w Plesk - bezpieczeństwo za pomocą kilku kliknięć

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.

Artykuły bieżące

Dwie programistki wspólnie sprawdzają lokalne środowisko testowe WordPressa na jednym stanowisku pracy.
Wordpress

SQLite jako baza danych WordPressa: stan rozwoju, ograniczenia i zastosowania

SQLite może ułatwić działanie WordPressa w ściśle określonych sytuacjach, ale nie jest standardową platformą bazodanową rdzenia. Kluczowe znaczenie mają obciążenie zapisem, praca na jednym serwerze, kompatybilność wtyczek, ochrona ścieżek oraz sprawdzona koncepcja tworzenia kopii zapasowych.

Administrator sprawdza planowaną aktualizację panelu hostingowego w jasnym biurze operacyjnym.
Plesk

Wersja cPanel & WHM: nowe funkcje i bezpieczne strategie aktualizacji

Wersja cPanel & WHM 138 wprowadza Meridian oraz nowe wymagania dotyczące automatyzacji. W tym artykule pokazano, w jaki sposób administratorzy wybierają poziomy wydania, sprawdzają zależności i w sposób kontrolowany wdrażają aktualizacje.