ModSecurity (WAF) w DirectAdmin: diagnostyka błędów 403 i wyłączanie reguł
Przy diagnozie błędów — szczególnie 403 Forbidden — warto mieć na uwadze działanie ModSecurity, czyli zapory WAF (Web Application Firewall). WAF zwiększa bezpieczeństwo stron WWW, ale czasem potrafi zablokować poprawne żądanie (tzw. false positive), dlatego w uzasadnionych sytuacjach można wyłączyć konkretną regułę albo tymczasowo wyłączyć ochronę dla danego hosta (niezalecane jako stałe rozwiązanie).
- Kiedy 403 jest wynikiem działania ModSecurity?
- Krok 1: sprawdź pełny błąd w Error Log
- Krok 2: przejdź do „Zapora sieciowa aplikacji internetowych” (WAF) dla domeny
W nowszych wersjach DirectAdmin (także w SEOHOST) funkcja ta w panelu może być widoczna jako „Zapora sieciowa aplikacji internetowych” (zamiast „ModSecurity”), a zasada działania i diagnostyka pozostają takie same: najpierw ustalasz, która reguła blokuje ruch, a dopiero potem dodajesz wyjątek.
Kiedy 403 jest wynikiem działania ModSecurity?
Jeśli błąd 403 pojawia się tylko dla wybranych akcji (np. zapisywanie wpisu w CMS, wysyłka formularza, wejście na konkretny URL), a w logach widzisz komunikat „ModSecurity: Access denied with code 403” oraz ID reguły, to masz potwierdzenie, że blokada pochodzi z WAF.
Przykład: wpis zawiera kluczowy fragment: Access denied with code 403 oraz [id "350001"] — to właśnie numer reguły, który wykorzystasz później do dodania wyjątku.
Krok 1: sprawdź pełny błąd w Error Log
Zanim cokolwiek wyłączysz, zacznij od logów domeny — są bardziej szczegółowe niż podgląd w module WAF i najczęściej pokazują pełny kontekst żądania.
Ścieżka w DirectAdmin: Informacje o systemie i pliki → Podsumowanie witryny / Statystyki / Logi → Dziennik błędów (error log) przy danej domenie.
Przykładowy wpis, który jest powodowany przez Modsecurity wygląda tak: [Wed Mar 13 11:22:38.473140 2024] [error] [client 1.2.3.4] ModSecurity: Access denied with code 403, [Rule: 'REQUEST_HEADERS:User-Agent' '@pmFromFile /etc/modsecurity.d/badbots.txt'] [id "350001"] [rev "1"] [msg "BAD BOT - Detected and Blocked. "] [severity "CRITICAL"] [hostname "www.nazwadomeny.pl"] [uri "/sklep"] [unique_id "LTzX-3bYtdk-NwCUGchwaFLp"], referer: https://www.tiktok.com/
Z logu spisz:
- Datę i godzinę zdarzenia.
- URL / URI, który wywołuje 403.
- IP klienta (jeśli istotne).
- ID reguły (np. 350001).
- Krótką wiadomość reguły (msg), jeśli jest.
Krok 2: przejdź do „Zapora sieciowa aplikacji internetowych” (WAF) dla domeny
W DirectAdmin ModSecurity jest dostępny jako Zapora sieciowa aplikacji internetowych (WAF).
Po wejściu do WAF zobaczysz przegląd konfiguracji dla domeny/hosta oraz typowe akcje:
- Zmień (edycja konfiguracji dla hosta).
- Dziennik audytu (lista zablokowanych żądań + reguły, które je zablokowały).
Na tym etapie najważniejsze jest jedno: wyjątki zapisujesz dla konkretnej domeny / nazwy hosta, więc zawsze upewnij się, że edytujesz właściwy host (DirectAdmin pokazuje go u góry ekranu i na liście). Jeśli masz kilka domen na jednym koncie, operację trzeba powtórzyć tam, gdzie problem faktycznie występuje.
Następnie kliknij Zmień i przejdź do sekcji Wykluczone reguły. W polu „ID reguły” wpisz numer reguły, którą odczytałeś z logów (np. 350001) i kliknij Dodaj wyjątek, a potem Zapisz konfigurację. Jeśli w logach pojawia się kilka różnych reguł powodujących blokady, dodaj je po kolei — najlepiej z krótkim komentarzem, żeby po miesiącu było jasne, dlaczego dana reguła została wykluczona (np. „blokada /robots.txt”, „blokada zapisu w panelu WP”).
W tym samym miejscu zobaczysz też przełącznik Włączone / Wyłączone dla zapory. Traktuj go jako narzędzie testowe: możesz na chwilę wyłączyć WAF, sprawdzić czy błąd 403 znika, i od razu wrócić do trybu „Włączone”.
Długotrwałe wyłączenie ochrony obniża bezpieczeństwo strony, więc jeśli test potwierdzi, że winna jest zapora, docelowo lepiej zostawić WAF włączony i wykluczyć wyłącznie tę regułę (lub reguły), która blokuje poprawne żądania.
Na koniec zrób prostą weryfikację: odśwież stronę, powtórz akcję, która wcześniej kończyła się 403 (np. wejście na konkretny URL, zapis w CMS, wysłanie formularza). Jeśli błąd ustąpił — masz potwierdzenie, że blokadę powodowała konkretna reguła WAF i wyjątek zadziałał. Jeśli 403 nadal występuje, wróć do logów (Error Log lub Dziennik audytu), sprawdź czy pojawia się inne ID reguły i dopiero wtedy podejmij kolejną decyzję.