Dziennik aktywności w WordPressie: jak sprawdzić, kto i kiedy zmienił stronę

Na stronie pojawił się administrator, którego nikt nie dodawał, albo zniknęła wtyczka, o której usunięciu nikt nie wie. Pytanie brzmi: kto to zrobił i kiedy. WordPress zna tylko część odpowiedzi. Zapisuje historię zmian treści wpisów, ale nie zapisuje logowań, instalacji wtyczek ani zmian ustawień. Do tego potrzebny jest dziennik aktywności, czyli wtyczka, która notuje takie zdarzenia, a w razie poważniejszej sprawy także logi serwera od hostingu.

Poniżej: co widać bez dodatkowych narzędzi, co powinien zapisywać dobry dziennik, dlaczego zwykły dziennik w bazie danych można po cichu wyczyścić i jak to wykryć.

Co WordPress zapisuje sam

• Wersje wpisów i stron. Przy każdym zapisie WordPress zachowuje wersję treści z autorem i czasem, o ile hosting albo programista nie wyłączył wersji. Dwie wersje można porównać, a starszą przywrócić.
• Datę ostatniej modyfikacji wpisu albo strony.
• Datę rejestracji każdego konta na liście użytkowników.

Tego WordPress nie zapisuje: kto i kiedy się logował, kto zainstalował, zaktualizował albo usunął wtyczkę lub motyw, kto zmienił rolę konta i kto przestawił ustawienia.

Logi serwera: gdzie szukać, gdy dziennika nie ma

Hosting prowadzi własne logi: każde żądanie do strony z adresem IP, czasem i adresem podstrony. Przewodnik WordPress.org o zabezpieczaniu strony (Hardening WordPress, stan z 14 października 2026) zwraca uwagę, że takie logi nie podają nazwy użytkownika, który się zalogował, ale pokazują adres IP, czas i działania, które ktoś wykonał.

W praktyce to dużo pracy: tysiące wierszy, a nazwy konta w nich nie ma. Hosting trzyma je też przez ograniczony czas, więc zapytaj, jak długo, zanim będą potrzebne. Dziennik w WordPressie mówi to samo prostszym językiem: konto, zdarzenie, czas, adres.

Co powinien zapisywać dobry dziennik

• logowania udane i nieudane oraz blokady po zbyt wielu próbach,
• nowe konta, zmiany ról i usunięte konta,
• instalacje, aktualizacje, wyłączenia i usunięcia wtyczek oraz motywów,
• zmianę motywu i aktualizacje WordPressa,
• zmiany ustawień, zwłaszcza tych dotyczących bezpieczeństwa,
• wyniki skanów, jeśli dziennik jest częścią wtyczki bezpieczeństwa.

Każdy wpis powinien mówić, co się stało, kiedy, z którego konta i z jakiego adresu.

Słaby punkt każdego dziennika: ta sama baza danych

Większość dzienników trzyma wpisy w bazie danych strony. Ktoś, kto dostał się do bazy, na przykład przez lukę w nieaktualnej wtyczce albo hasłem z kopii zapasowej leżącej na serwerze, może usunąć wpisy o sobie. Zwykły dziennik nie zauważy, że czegoś brakuje. Pokaże po prostu krótszą historię.

Są na to dwa sposoby:

1. Kopia dziennika poza serwerem. Wpisy trafiają na bieżąco do zewnętrznej usługi albo na inny serwer. To wymaga konfiguracji i często płatnej usługi.
2. Dziennik, w którym zmiana jest widoczna. Po angielsku nazywa się to „tamper-evident”. Każdy wpis dostaje podpis liczony z jego treści i z podpisu wpisu poprzedniego, z użyciem tajnego klucza, którego nie ma w bazie danych. Zmiana jednego wpisu albo usunięcie go ze środka psuje podpisy od tego miejsca. Sprawdzenie wskazuje wtedy, który wpis się nie zgadza.

Drugi sposób nie zapobiega usunięciu wpisów. Daje dowód, że do niego doszło. Ma też granicę: kto zdobędzie zarówno bazę danych, jak i plik z kluczem, może przeliczyć podpisy od nowa. Dlatego przy poważnym incydencie warto mieć też logi hostingu.

Jak ocenić wtyczkę z dziennikiem

1. Gdzie trzyma wpisy. Osobna tabela w bazie znosi dużą liczbę wpisów. Dziennik zapisany jako jedno ustawienie z limitem kilkuset pozycji szybko gubi starsze zdarzenia.
2. Jak długo je trzyma i czy zmienisz ten okres. Okres powinien obejmować czas, po którym realnie zauważasz problem na stronie. Dłużej trzymasz tylko dane, których nie potrzebujesz.
3. Czy da się go pobrać. Plik CSV otworzysz w arkuszu i dołączysz do zgłoszenia dla programisty albo hostingu.
4. Czy blokady nie wypychają innych zdarzeń. Boty potrafią wygenerować tysiące nieudanych logowań dziennie. Jeśli każde jest osobnym wpisem w tej samej puli, ważniejsze zdarzenia znikają.
5. Co zapisuje o nieudanych logowaniach. Ludzie czasem wpisują hasło w pole nazwy użytkownika. Dziennik, który zapisuje każdą wpisaną nazwę, może więc przechowywać fragmenty haseł. Adresy IP i nazwy kont mogą być danymi osobowymi, więc dobrze, gdy dziennik zapisuje ich tyle, ile trzeba, i usuwa je po ustalonym czasie. Więcej o danych osobowych na stronie piszę w tekście o RODO i bezpieczeństwie strony.
6. Czy wykrywa zmiany we własnych wpisach. Opis wtyczki powinien to mówić wprost.

Kiedy zajrzeć do dziennika

• pojawił się administrator, którego nikt nie pamięta,
• strona główna wygląda inaczej albo przekierowuje gdzie indziej,
• przyszedł mail o blokadzie konta administratora,
• współpraca z agencją się skończyła albo pracownik odszedł i chcesz sprawdzić, co robił na koniec.

Pobierz wtedy dziennik, znajdź pierwsze nietypowe zdarzenie i zapisz jego czas. Z tym czasem łatwiej przeszukać logi hostingu. Zmień hasła administratorów i bazy danych z komputera, któremu ufasz. Co robić w pierwszej godzinie po włamaniu, opisuje tekst o objawach zhakowanej strony.

Jak robi to Ensomedia Security

Ensomedia Security to darmowa wtyczka z katalogu WordPress.org, którą zrobiłem dla ShieldWave. Jej dziennik w panelu nazywa się Historia i działa bez konta. Fakty z opisu i kodu wtyczki:

• zapisuje skanowania, znalezione i naprawione problemy, nowych administratorów, aktualizacje, zmiany ustawień i blokady,
• trzyma wpisy we własnej tabeli w bazie danych,
• każdy wpis ma podpis HMAC-SHA256 liczony z kluczem, którym jest sól logowania z pliku wp-config.php. Tego klucza nie ma w bazie danych, a podpis obejmuje podpis wpisu poprzedniego,
• przycisk Sprawdź integralność historii mówi, czy jakiś wpis został zmieniony albo usunięty poza ShieldWave. Odcięcie najnowszych wpisów też zostaje zauważone,
• ktoś, kto może zapisywać w bazie danych, ale nie może odczytać wp-config.php, nie zmieni ani nie usunie wpisu tak, żeby sprawdzenie tego nie wykazało,
• wpisy o blokadach są łączone w zbiorcze wiersze i trzymane poza łańcuchem podpisów: ich zmiana zostaje zauważona, ich usunięcie nie,
• jeśli zmienisz klucze bezpieczeństwa w wp-config.php, sprawdzenie powie, że starszych wpisów nie da się już zweryfikować. Po wymianie kluczy, na przykład po włamaniu, to normalne,
• wpisy są trzymane od 7 do 730 dni (domyślnie 90) i można je pobrać jako CSV,
• przy nieudanym logowaniu wpisana nazwa użytkownika jest zapisywana tylko wtedy, gdy takie konto istnieje. W innym przypadku zostaje tylko jej skrót liczony z kluczem.

Wtyczka nie jest pełną zaporą aplikacyjną i nie usuwa złośliwego kodu z plików. Zmianę, którą opisuje, wprowadzasz Ty, programista albo hosting. Pozostałe funkcje opisuje strona wtyczki (po angielsku), a jak czytać Historię na co dzień, pokazuje tekst o tej wtyczce.

Co zrobić dziś

1. Sprawdź, czy Twoja strona ma jakikolwiek dziennik aktywności i od kiedy.
2. Zapytaj hosting, jak długo trzyma logi serwera.
3. Ustal, jak długo chcesz przechowywać wpisy, i ustaw to w dzienniku.
4. Raz w miesiącu przejrzyj listę administratorów i porównaj ją z dziennikiem.

Sprawdź swoją stronę z zewnątrz. Wpisz adres na shieldwave.io. Test trwa około 90 sekund i nie wymaga hasła ani wtyczki.