Jak chronić WordPressa za pomocą Fail2Ban

English version: How to protect WordPress with Fail2Ban

WP Cerber i Fail2Ban mogą wspólnie powstrzymać ataki siłowe, zanim dotrą do WordPressa. WP Cerber wykrywa nieudane logowania na poziomie aplikacji; Fail2Ban działa na nie na poziomie systemu operacyjnego, blokując przestępców za pomocą iptables . Ta kombinacja powstrzymuje ataki siłowe i DoS przy minimalnym obciążeniu.

Czym jest Fail2Ban

Fail2Ban to usługa monitorowania logów działająca na Twoim serwerze. Monitoruje pliki logów pod kątem wzorców sygnalizujących atak, takich jak powtarzające się błędy uwierzytelniania z tego samego adresu, a gdy host przekroczy ustalony próg, blokuje dostęp do tego adresu na zaporze systemowej na wybrany okres. Sama usługa nie wie nic o WordPressie; działa wyłącznie na podstawie informacji znalezionych w logach. Właśnie tutaj pojawia się WP Cerber: monitoruje i rejestruje nieudane logowania w formacie, który Fail2Ban może przeanalizować, dostarczając usłudze zdarzenia niezbędne do podjęcia działań.

Dowiedz się więcej o atakach: Ataki siłowe, DoS i DDoS – na czym polega różnica?

Uwaga: aby skonfigurować Fail2Ban, musisz mieć dostęp do roota na swoim serwerze Linux.

Dzięki WP Cerber masz trzy możliwości wykorzystania Fail2Ban

1. Korzystanie z nagłówków odpowiedzi HTTP 403, jeśli chcesz monitorować dziennik dostępu Apache
2. Monitorowanie nieudanych prób logowania za pomocą plików syslog
3. Korzystanie z niestandardowego pliku dziennika w celu monitorowania nieudanych prób logowania

Monitoruj dziennik dostępu Apache pod kątem odpowiedzi HTTP 403

Gdy próba logowania się nie powiedzie, WP Cerber zwraca status 403 w nagłówku HTTP. Apache rejestruje tę odpowiedź w swoim dzienniku dostępu, gdzie Fail2Ban może ją odczytać. To zachowanie jest domyślnie włączone. Wadą jest to, że Fail2Ban musi przeanalizować cały plik access.log, aby znaleźć te próby, co jest nieefektywne w przypadku obciążonej witryny.

Monitorowanie nieudanych prób logowania za pomocą syslogu

Domyślnie WP Cerber rejestruje nieudane próby logowania do sysloga w ramach funkcji LOG_AUTH . Aby użyć własnej funkcji, zdefiniuj stałą CERBER_LOG_FACILITY z wartością całkowitą. W obu przypadkach zapis do sysloga lub do pliku niestandardowego (patrz poniżej) następuje dopiero po włączeniu opcji „Zapisz nieudane logowania do pliku dziennika” w głównych ustawieniach wtyczki.

 zdefiniuj('CERBER_LOG_FACILITY', LOG_AUTHPRIV);

Korzystanie z pliku niestandardowego do monitorowania nieudanych prób logowania

Aby wysyłać każdą nieudaną próbę do wybranego pliku dziennika, ustaw jego ścieżkę bezwzględną za pomocą stałej CERBER_FAIL_LOG . Nie zapomnij nadać serwerowi WWW uprawnień do zapisu do folderu lub pliku oraz włączyć opcję „Zapisuj nieudane logowania do pliku dziennika” . WP Cerber utworzy plik dziennika, jeśli nie istnieje. Po zdefiniowaniu parametru CERBER_FAIL_LOG , WP Cerber przestanie zapisywać do domyślnego pliku syslog. Warto zauważyć, że niestandardowy plik CERBER_FAIL_LOG zachowuje kontrolę nad danymi, w przeciwieństwie do pliku syslog, gdzie magazyn danych podlega zasadom serwera lub środowiska hostingowego.

 zdefiniuj('CERBER_FAIL_LOG','/var/log/wp-cerber-auth.log');

Upewnij się, że proces PHP Twojego serwera WWW ma dostęp do zapisu określonego pliku.

Wyrównywanie znaczników czasu z zegarem serwera

Niezgodność strefy czasowej to najczęstszy powód, dla którego Fail2Ban rejestruje próby, ale nigdy nikogo nie banuje, więc warto to zrozumieć, nawet jeśli wszystko inne jest poprawnie skonfigurowane.

Fail2Ban działa tylko na zdarzenia, które mieszczą się w jego oknie findtime i ustala to, porównując znacznik czasu każdego wiersza logu z czasem lokalnym serwera. WordPress przechowuje swój własny zegar w formacie UTC, niezależnie od strefy czasowej ustawionej na stronie. Zatem na serwerze, powiedzmy, z adresem Europa/Madryt, każdy wiersz zapisany przez WordPressa wygląda na sprzed godziny lub dwóch. Fail2Ban odrzuca te zdarzenia jako nieaktualne i nigdy nie uruchamia blokady, mimo że próby są rejestrowane w logu.

WP Cerber omija ten problem, zapisując znaczniki czasu w strefie czasowej systemu serwera, a nie w zegarze WordPressa, dzięki czemu są one zgodne z oczekiwaniami Fail2Ban. Na większości serwerów odbywa się to automatycznie i nie wymaga od użytkownika żadnych działań.

Jeśli WP Cerber nie może samodzielnie ustalić strefy czasowej systemu, ustaw ją samodzielnie za pomocą stałej CERBER_LOG_TIMEZONE , używając dowolnego prawidłowego identyfikatora strefy czasowej:

 zdefiniuj('CERBER_LOG_TIMEZONE', 'Europa/Madryt');

Ta wartość zastępuje automatyczne wykrywanie, więc jest to niezawodny sposób na ustalenie strefy czasowej w przypadku dryfowania znaczników czasu. Działa dowolny identyfikator ze standardowej bazy danych stref czasowych, na przykład „Ameryka/Nowy_Jork” lub „Azja/Tokio”. Ta stała jest dostępna od wersji 9.7.4 WP Cerber .

Co jest rejestrowane

Ten dziennik rejestruje dane osobowe, więc jeśli Twoja witryna podlega przepisom o ochronie prywatności, takim jak RODO, dotyczy Cię to bezpośrednio. Oto, co się w nim znajduje.

Każde nieudane logowanie zapisuje jeden wiersz: źródłowy adres IP, przesłaną nazwę użytkownika, nazwę hosta serwera, identyfikator procesu i znacznik czasu. Hasła nigdy nie są rejestrowane w żadnej formie, a żadne inne dane konta nie są zapisywane.

Dwa z tych pól stanowią dane osobowe w rozumieniu RODO: adres IP (wyrok Breyer potwierdził, że adres IP ma znaczenie) oraz nazwa użytkownika. Ponieważ WordPress umożliwia logowanie za pomocą adresu e-mail, nazwa użytkownika może być również adresem e-mail użytkownika . Dotyczy to nawet nieudanych prób, które nadal rejestrują, że konkretna osoba była celem ataku.

To czyni Cię administratorem tych danych, co pociąga za sobą kilka praktycznych konsekwencji. Uwzględnij te logi w swojej polityce przechowywania i rotacyjnie je usuwaj, zamiast pozwalać im rosnąć bez ograniczeń. Śledź, gdzie rekordy są przechowywane i przekazywane: niestandardowy plik CERBER_FAIL_LOG zapewnia Ci kontrolę nad danymi, podczas gdy syslog może wysyłać rekordy na scentralizowane lub zewnętrzne serwery, gdzie przechowywanie i przetwarzanie odbywa się zgodnie z zasadami systemowymi, których możesz nie ustawić. Żądania osób, których dane dotyczą, o dostęp lub usunięcie danych, również dotyczą tych logów.

WP Cerber celowo nie obsługuje samodzielnego czyszczenia tych logów, ponieważ nie kontroluje, co syslog robi z rekordami ani jak system operacyjny serwera przetwarza pliki logów. Funkcja czyszczenia wbudowana w WP Cerber obejmowałaby tylko część danych i mogłaby błędnie sugerować, że dane zostały usunięte, mimo że tak nie było.

To praktyczne podsumowanie, a nie porada prawna. Jeśli przetwarzasz dane z UE, Wielkiej Brytanii lub podobnych jurysdykcji, traktuj adres IP i nazwę użytkownika jako dane osobowe i skonsultuj swoje obowiązki z osobą odpowiedzialną za zgodność z przepisami w Twojej firmie.