WordPress firewall filtruje ruch HTTP i blokuje podejrzane żądania, zanim dotrą do strony. Najlepszą pierwszą warstwą ochrony jest WAF działający na poziomie serwera, ponieważ odrzuca atak jeszcze przed uruchomieniem PHP i WordPressa.
Czym jest firewall w WordPressie?
Firewall działa jak strażnik przy wejściu do budynku. Sprawdza żądania kierowane do witryny i odrzuca te, które pasują do znanych wzorców ataków, prób wykorzystania luk albo automatycznych skanów. Prawidłowy użytkownik może przejść dalej, a podejrzany ruch zostaje zatrzymany na wcześniejszym etapie.
W przypadku WordPressa ma to znaczenie, ponieważ sama aplikacja nie filtruje całego ruchu przed uruchomieniem własnego kodu. Aktualne wtyczki i poprawki są konieczne, ale nie zastępują zapory. Firewall może ograniczyć ryzyko wykorzystania podatności, zanim atakujący dotrze do plików PHP, panelu administracyjnego lub mechanizmów obsługujących formularze.
WAF czy wtyczka – co wybrać?
Najważniejsza różnica dotyczy miejsca, w którym następuje analiza żądania. WAF, czyli Web Application Firewall, działa na poziomie serwera WWW przed uruchomieniem PHP. Firewall dodany do wtyczki działa dopiero wtedy, gdy środowisko PHP załaduje WordPressa i odpowiednią wtyczkę.
| Cecha | Firewall serwerowy (WAF) | Wtyczka działająca w PHP |
|---|---|---|
| Moment blokowania | Przed uruchomieniem PHP i WordPressa | Po załadowaniu środowiska WordPressa |
| Wpływ na wydajność | Niewielki, ponieważ żądanie jest odrzucane wcześniej | Większy, ponieważ każde żądanie zużywa zasoby PHP |
| Obciążenie przy ataku | Nieprawidłowy ruch nie uruchamia aplikacji | Żądanie może obciążyć aplikację przed zablokowaniem |
| Konfiguracja | Zależy od ustawień serwera lub panelu hostingu | Zwykle dostępna bezpośrednio w panelu wtyczki |
Z tego powodu WAF powinien być pierwszą linią obrony. Firewall we wtyczce może pełnić funkcje uzupełniające, takie jak analiza zdarzeń w WordPressie, ale dublowanie tej samej filtracji na poziomie PHP zwykle nie daje korzyści proporcjonalnych do dodatkowego obciążenia. Jeśli hosting udostępnia ochronę serwerową, warto wyłączyć wtyczkowy moduł firewalla albo skonfigurować go tak, aby nie powielał reguł WAF.
Sam WAF nie zabezpiecza przed każdym problemem. Nie zastąpi aktualizacji WordPressa, motywów i wtyczek, kopii zapasowych, silnych haseł ani ograniczenia dostępu do panelu administracyjnego. Jest jedną z warstw ochrony, a nie samodzielnym rozwiązaniem wszystkich zagrożeń.
Jak działają reguły 7G i 8G?
Reguły 7G i 8G są zestawami filtrów serwerowych opracowanymi przez Perishable Press. Analizują parametry żądania HTTP, między innymi adres URL, zapytanie, nagłówki i User-Agenta. Gdy wykryją charakterystyczny, niebezpieczny wzorzec, serwer może zakończyć obsługę żądania bez uruchamiania kodu WordPressa.
8G Firewall jest rozwinięciem 7G, a nie wyłącznie nową nazwą tego samego zestawu. 7G pozostaje starszą, sprawdzoną wersją reguł. 8G wprowadza nowsze dopasowania i jest zwykle wybierany jako ustawienie domyślne, choć przy nietypowej konfiguracji może powodować fałszywe trafienia.
Filtry mogą blokować znane wzorce między innymi takich zagrożeń:
- SQL Injection – próby wstrzyknięcia poleceń do zapytań bazodanowych.
- Cross-Site Scripting (XSS) – próby przemycenia szkodliwego skryptu do treści obsługiwanej przez aplikację.
- Directory Traversal – próby odwołania się do plików poza dozwolonym katalogiem.
- Command Injection – próby przekazania poleceń do systemu lub procesu obsługującego żądanie.
- Skanery podatności i szkodliwe User-Agenty rozpoznawane na podstawie charakterystycznych wzorców.
WAF może korzystać zarówno z czarnych list elementów uznanych za niebezpieczne, jak i z reguł określających dozwolone zachowania. W praktyce zakres ochrony zależy od konfiguracji serwera, aktualności reguł i charakteru aplikacji. Filtrowanie odbywa się poza kodem WordPressa, dlatego nie wymaga modyfikowania jego plików źródłowych.
Co zrobić, gdy firewall zwraca błąd 403?
Najczęstszym sygnałem zablokowania żądania jest status 403 Forbidden. Pojedynczy błąd nie oznacza jeszcze, że reguły są nieprawidłowe. Nietypowy adres URL, własny formularz albo wtyczka korzystająca z charakterystycznych parametrów może zostać omyłkowo uznana za zagrożenie.
Postępuj według kolejnych kroków:
- Sprawdź najważniejsze ścieżki witryny, w tym stronę główną, podstrony, wyszukiwarkę i formularze. W sklepie przetestuj także koszyk oraz składanie zamówienia.
- Zaloguj się do panelu WordPressa i wykonaj typowe czynności, takie jak edycja wpisu, wysłanie pliku oraz zapis ustawień wtyczki.
- Otwórz Access log w logach serwera i wyszukaj żądanie zakończone kodem 403. Zwróć uwagę na adres URL oraz parametry, które uruchomiły regułę.
- Jeżeli problem dotyczy konkretnej funkcji, przełącz 8G na 7G i powtórz te same testy. Starszy zestaw może być lepiej tolerowany przez nietypową wtyczkę.
- Wyłączenie firewalla traktuj jako ostateczność i rozwiązanie diagnostyczne. Jeżeli błąd występuje także po wyłączeniu reguł, przyczyna leży prawdopodobnie w innej konfiguracji serwera, uprawnieniach lub samej aplikacji.
Nie należy od razu wyłączać całej ochrony tylko dlatego, że jedna funkcja nie działa. Najpierw trzeba ustalić, które żądanie zostało odrzucone. Pozwala to skorygować pojedynczą regułę albo zgłosić problem administratorowi serwera bez rezygnowania z filtrowania pozostałego ruchu.
WordPress firewall – jakie ustawienie wybrać?
W typowej instalacji priorytetem powinien być serwerowy WAF, najlepiej z aktualnym zestawem reguł 8G. Działa przed PHP, ogranicza obciążenie podczas automatycznych ataków i nie wymaga uruchamiania WordPressa dla odrzuconych żądań. Reguły 7G pozostają rozsądną opcją awaryjną, gdy starsza konfiguracja lub nietypowa wtyczka powoduje fałszywe blokady.
Wtyczki bezpieczeństwa mogą wspierać ochronę aplikacji, ale nie powinny bez potrzeby dublować filtrowania wykonywanego przez serwer. Po wdrożeniu WAF przetestuj funkcje strony i regularnie sprawdzaj logi, szczególnie po instalacji nowej wtyczki lub zmianie konfiguracji.
