Jak sprawdzić logi bezpieczeństwa WordPress?

Logi bezpieczeństwa WordPressa dzielą się na dwa główne rodzaje: debug.log, który pokazuje błędy PHP i WordPressa, oraz logi serwera, takie jak access.log i error_log. To właśnie logi dostępu pomagają wykryć próby brute-force, nietypowe adresy IP i nieautoryzowane żądania. Żadnego pliku .log nie należy udostępniać publicznie.

Jakie logi sprawdzić w WordPressie?

Logi działają jak zapis zdarzeń na stronie. Dzięki nim możesz ustalić, czy problem wynika z błędu wtyczki lub motywu, awarii PHP, konfiguracji serwera, czy podejrzanego ruchu.

debug.log zapisuje błędy generowane przez WordPressa i PHP. Przydaje się, gdy strona wyświetla biały ekran, pojawia się błąd krytyczny albo konkretna funkcja przestaje działać. Logi serwera pokazują natomiast żądania kierowane do witryny, adresy IP, kody odpowiedzi HTTP i błędy Apache lub Nginx. To w nich najczęściej widać ślady skanowania strony i ataków na formularz logowania.

Jak włączyć i znaleźć plik debug.log?

Do włączenia zapisu potrzebujesz dostępu do pliku wp-config.php. Możesz użyć FTP, SFTP albo menedżera plików w panelu hostingu. Przed zmianą wykonaj kopię zapasową pliku, ponieważ błąd składni może spowodować niedostępność strony.

Wykonaj następujące czynności:

Otwórz plik wp-config.php znajdujący się zwykle w głównym katalogu instalacji WordPressa.
Znajdź ustawienia debugowania albo dodaj je przed komentarzem kończącym konfigurację WordPressa.
Ustaw wartości stałych w taki sposób, aby błędy były zapisywane do pliku, ale nie wyświetlały się odwiedzającym.
Zapisz plik i odtwórz problem, na przykład otwierając podstronę, na której pojawia się błąd.
Przejdź przez FTP do katalogu /wp-content/ i odszukaj utworzony plik debug.log.

Przykładowa konfiguracja wygląda tak:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

WP_DEBUG włącza tryb debugowania, a WP_DEBUG_LOG zapisuje komunikaty w dzienniku. WP_DEBUG_DISPLAY ustawione na false ukrywa błędy przed użytkownikami. Na stronie produkcyjnej nie należy wyświetlać komunikatów PHP, ponieważ mogą ujawnić ścieżki plików, nazwy funkcji lub inne informacje techniczne.

Standardowo plik pojawia się w katalogu wp-content dopiero po zapisaniu pierwszego błędu. Jeśli go nie widzisz, sprawdź, czy stałe nie zostały zdefiniowane wcześniej z innymi wartościami, a następnie wywołaj problem ponownie. Po zakończeniu diagnostyki pobierz log na komputer, usuń go lub wyczyść i wyłącz debugowanie na stronie produkcyjnej.

Gdzie znaleźć logi serwera?

Logi serwera nie muszą znajdować się w katalogu instalacji WordPressa. Ich lokalizacja zależy od hostingu i używanego panelu. Najczęściej znajdziesz je w sekcji nazwanej „Logi”, „Logi błędów”, „Statystyki” albo „Serwer WWW”.

Panel hostingu pozwala zwykle podejrzeć bieżący access.log i error_log bezpośrednio w przeglądarce.
W DirectAdmin szukaj sekcji „Site Summary & Statistics & Logs” oraz opcji „Error Log”.
W cPanel logi błędów są dostępne najczęściej w sekcji „Metryki” pod pozycją „Błędy”.
Przez FTP lub SFTP możesz otrzymać dostęp do katalogów z archiwalnymi logami, jeśli hosting udostępnia taką funkcję.
Przez SSH administrator może odczytać logi z katalogu wskazanego przez dostawcę serwera.

Nie istnieje jedna uniwersalna ścieżka dla wszystkich usług. Jeśli panel nie pokazuje logów, sprawdź dokumentację hostingu albo poproś administratora o dostęp do logów domeny. Błąd 500 może być zapisany wyłącznie w logu serwera, a nie w debug.log.

Rodzaj logu	Co zawiera?	Do czego służy?	Gdzie go szukać?
`debug.log`	Błędy PHP, WordPressa, motywów i wtyczek	Diagnoza problemów z działaniem strony	`/wp-content/debug.log` po włączeniu `WP_DEBUG_LOG`
`access.log`	Żądania HTTP, adresy IP, ścieżki i kody odpowiedzi	Analiza ruchu, skanowania i prób brute-force	Panel hostingu, katalog logów lub narzędzia serwera
`error_log`	Błędy PHP, Apache, Nginx i serwera	Diagnoza błędów 500, limitów i problemów konfiguracji	Panel hostingu lub logi serwera

Jak czytać logi pod kątem bezpieczeństwa?

Najpierw ustal dokładny czas wystąpienia problemu. Następnie sprawdź wpisy z kilku minut przed i po tym zdarzeniu. W logu dostępu zwróć uwagę na adres IP, żądaną ścieżkę, metodę HTTP, kod odpowiedzi i częstotliwość powtarzania żądań.

Za sygnały wymagające sprawdzenia można uznać:

setki lub tysiące żądań z jednego adresu IP w krótkim czasie,
powtarzające się próby dostępu do /wp-login.php lub /xmlrpc.php,
częste błędy 404 dotyczące plików i katalogów, których nie ma w Twojej instalacji,
żądania do paneli, skryptów lub plików pochodzących z innych systemów CMS,
nieoczekiwane zmiany plików wykonywalnych, motywów, wtyczek albo kont administratorów.

Pojedynczy wpis nie potwierdza włamania. Boty i skanery regularnie odwiedzają publiczne strony, dlatego liczy się wzorzec aktywności: powtarzalność, liczba żądań, skuteczne odpowiedzi serwera oraz zgodność zdarzeń z tym, co działo się na stronie.

Przeanalizuj podejrzany wpis w następującej kolejności:

Sprawdź czas zdarzenia i porównaj go z momentem pojawienia się problemu.
Odczytaj adres IP i żądaną ścieżkę, zwracając uwagę na wp-login.php, pliki administracyjne oraz nieznane skrypty.
Porównaj kod odpowiedzi HTTP – seria kodów 401, 403 lub 404 może oznaczać próby dostępu albo skanowanie, a kod 200 wskazuje, że serwer zwrócił zawartość.
Sprawdź pliki i konta, jeśli logi wskazują na skuteczne żądania lub równolegle pojawiły się przekierowania, spam albo nieznany administrator.

Nie usuwaj od razu podejrzanych wpisów ani plików. Zachowaj kopię logów, aby można było przeanalizować zakres zdarzenia. Jeśli widać skuteczne próby przejęcia konta, nieznane pliki lub oznaki malware, ogranicz dostęp do strony i skontaktuj się z administratorem serwera.

Jak zabezpieczyć pliki logów?

Logi mogą zawierać adresy IP, ścieżki serwera, nazwy użytkowników, komunikaty PHP, fragmenty zapytań i inne dane techniczne. Plik dostępny pod adresem w rodzaju twojadomena.pl/wp-content/debug.log może ujawnić informacje osobom postronnym.

Po zakończeniu diagnostyki sprawdź następujące kwestie:

Logi nie są dostępne przez przeglądarkę – nie umieszczaj ich w publicznym katalogu bez blokady dostępu.
WP_DEBUG_DISPLAY ma wartość false na stronie produkcyjnej.
WP_DEBUG i WP_DEBUG_LOG są wyłączone, gdy nie prowadzisz już diagnostyki.
Stary plik debug.log został pobrany i usunięty albo wyczyszczony po zabezpieczeniu kopii.
Dostęp do FTP, SFTP, SSH i panelu hostingu jest chroniony silnymi, unikalnymi hasłami oraz, gdy to możliwe, uwierzytelnianiem dwuskładnikowym.

Jeżeli podejrzewasz infekcję, sam log nie wystarczy do potwierdzenia, że strona jest bezpieczna. Przydatny może być skaner dostępny w panelu hostingu, ale wynik należy porównać z plikami, bazą danych, listą użytkowników i logami serwera.

Gdy chcesz sprawdzić problem z działaniem funkcji, zacznij od debug.log. Gdy szukasz śladów włamania, prób logowania lub nietypowego ruchu, podstawowym źródłem powinien być access.log wraz z error_log.