Analiza logów serwera WWW po ataku: jak prawidłowo czytać access log

Krótko: Kto chce przeanalizować access log po ataku, najpierw zabezpiecza logi w niezmienionej postaci i pracuje potem tylko na kopiach. Szuka się żądań ze statusem 200 do nieznanych plików PHP, podejrzanych żądań POST, dostępów do katalogów uploadu i wzorców czasowych. Dla PHP2Shell nie ma opublikowanych, potwierdzonych wskaźników naruszenia (Indicators of Compromise), dlatego liczy się całościowy obraz z kilku źródeł logów.

Najpierw zabezpieczyć, potem analizować

Pliki logów są na większości serwerów automatycznie rotowane i po ustalonym czasie usuwane. Po ataku pierwszym krokiem jest więc zabezpieczenie istniejących logów, zanim znikną. Dotyczy to także sytuacji, gdy nie są Państwo jeszcze pewni, czy w ogóle coś się stało. W sprawie PHP2Shell prasa branżowa radzi przechowywać logi od 20.10.2026.

# Skopiuj logi ze znacznikami czasu i zapisz sumy kontrolne
ZIEL=/root/sicherung-logs-$(date +%F)
mkdir -p "$ZIEL"
cp -a /var/log/nginx /var/log/apache2 /var/log/php* "$ZIEL"/ 2>/dev/null
cp -a /var/log/auth.log* /var/log/syslog* "$ZIEL"/ 2>/dev/null
find "$ZIEL" -type f -exec sha256sum {} + > "$ZIEL.sha256"

Kopię proszę dodatkowo złożyć w innym systemie. Atakujący z dostępem do serwera mógłby w przeciwnym razie później zmienić logi. Sumy kontrolne pokażą później, że kopia jest niezmieniona. Jeśli potrzebne jest zabezpieczenie nadające się do sądu, na przykład do zawiadomienia lub dla ubezpieczenia, zabezpieczenie powinna przejąć informatyka śledcza.

Gdzie leżą logi i jak zbudowany jest wiersz

Miejsca zapisu zależą od dystrybucji i interfejsu zarządzania. Typowe ścieżki:

W rozpowszechnionym formacie Combined każdy wiersz zawiera adres klienta, datę i godzinę, metodę i ścieżkę żądania, kod statusu, rozmiar odpowiedzi w bajtach, referer i user-agent. Proszę zwrócić uwagę na strefę czasową w znaczniku czasu, zwłaszcza przy porównywaniu logów z komunikatami w UTC. Poprawki PHP2Shell opublikowano na przykład 21.10.2026 o godz. 14:00 UTC, czyli o 16:00 czasu niemieckiego.

Jeśli Państwa strona stoi za proxy, CDN lub load balancerem, w logu może znajdować się tylko jego adres. Prawdziwy adres odwiedzającego znajduje się wtedy w osobnym polu lub w logach usługi wstępnej.

Bez wiersza poleceń: logi w panelu lub u hostingu

Nie każdy operator ma dostęp do powłoki. Na shared hostingu lub serwerach zarządzanych interfejsy zarządzania mają zwykle widok logów i pobieranie logów dostępu i błędów. Proszę pobrać pliki za cały dostępny okres i bezpiecznie je przechowywać. Proszę zapytać hosting na piśmie, jak długo logi są przechowywane i czy starsze stany można zabezpieczyć, zanim wygasną.

Proszę przy tym pamiętać o ochronie danych: logi zawierają adresy IP i często dalsze dane osobowe. Kopie proszę zapisywać z ochroną dostępu, przekazywać je tylko osobom, które potrzebują ich do wyjaśnienia sprawy, i ustalić, kiedy po zakończeniu incydentu zostaną usunięte.

Analiza access logu: najważniejsze zapytania

Poniższe polecenia tylko odczytują i nadają się dla Nginx i Apache w formacie Combined. Rotowane i skompresowane pliki przeszukują Państwo za pomocą zgrep lub zcat.

LOG=/root/sicherung-logs-2026-10-25/nginx/access.log

# Udane żądania do plików PHP, według częstotliwości
awk '$9 == 200 && $7 ~ /\.php/ {split($7,p,"?"); print p[1]}' "$LOG" | sort | uniq -c | sort -rn | head -40

# Wywołania PHP w katalogach uploadu, pamięci podręcznej lub obrazów
grep -E '"(GET|POST) /[^ ]*(uploads|cache|images|tmp)/[^ ]*\.php' "$LOG"

# Żądania POST według celu i adresu
awk '$6 == "\"POST" {print $1, $7}' "$LOG" | sort | uniq -c | sort -rn | head -40

# Błędy 5xx na godzinę: nagromadzenia mogą wskazywać na zawieszające się procesy PHP
awk '$9 ~ /^5/ {print substr($4, 2, 14)}' "$LOG" | sort | uniq -c

# Uwzględnij rotowane logi
zgrep -h ' 200 ' /var/log/nginx/access.log.*.gz | grep -c '\.php'

W pierwszym zapytaniu szczególnie interesują nazwy plików, których Państwo nie znają lub które nie należą do aplikacji. Podejrzane pliki proszę porównać z systemem plików: kiedy zostały utworzone, do kogo należą, co zawierają? Wskazówki podaje poradnik Jak wykryć i usunąć webshell.

Osobliwości PHP2Shell

W przypadku PHP2Shell luki leżą w przetwarzaniu żądań w samym PHP. W przypadku mod_php pokazano exploit, zanim w ogóle zacznie działać kod aplikacji. Oznacza to: wystarczyć może żądanie do całkiem zwykłej strony. W access logu takie żądanie może wyglądać niepozornie, ponieważ zawartości ciała żądania tam nie ma.

Nie ma opublikowanych, potwierdzonych wskaźników naruszenia. Proszę więc zwracać uwagę na zachowanie i zależności, na przykład od 17.10.2026, czyli pierwszej według doniesień medialnych zaobserwowanej próby ataku:

• Nagromadzenia błędów 500 lub przerwanych odpowiedzi na zwykłych stronach.
• Komunikaty o wyczerpanej pamięci lub zakończonych procesach roboczych w logu błędów i logu PHP-FPM.
• Nowe pliki PHP lub zmienione pliki krótko po takich nagromadzeniach.
• Nowe zadania cron, procesy lub połączenia wychodzące pod użytkownikiem serwera WWW.

Żaden z tych sygnałów sam nie jest dowodem. Razem z innymi śladami dają jednak obraz, który odpowiada na pytanie o kompromitację albo uzasadnia głębsze badanie. Przegląd oznak znajdą Państwo na stronie Czy już zostałem skompromitowany?.

Dalsze źródła: log błędów, PHP-FPM i protokoły systemowe

Access log pokazuje tylko część. Dla pełnego obrazu proszę dołączyć dalsze źródła:

# PHP-FPM i serwer WWW w dzienniku od daty
journalctl -u 'php*-fpm*' --since "2026-10-17" --no-pager | tail -200

# Logowania na serwerze
last -Fa | head -40
grep -E 'Accepted|Failed' /var/log/auth.log | tail -100

# Sprawdź zaplanowane zadania wszystkich użytkowników
for u in $(cut -d: -f1 /etc/passwd); do crontab -l -u "$u" 2>/dev/null | sed "s/^/$u: /"; done

Typowe błędy w analizie to przeszukiwanie tylko bieżących, a nie także rotowanych logów, przeoczenie strefy czasowej i branie pojedynczych trafień zautomatyzowanych skanerów za udany atak. Równie ryzykowne jest przeciwieństwo: uznanie niepozornego access logu za odwołanie alarmu, choć log błędów i system plików nie zostały jeszcze sprawdzone.

Każde znalezisko proszę zapisywać z godziną, źródłem i obserwacją na osi czasu. Ta oś czasu jest później podstawą decyzji, zgłoszeń do organów lub ubezpieczycieli oraz raportu końcowego.

Jak konkretnie pomaga PHP SOS?

• Zabezpieczamy logi i istotne pliki tak, aby pozostały możliwe do prześledzenia dla późniejszych kontroli.
• Analizujemy razem logi dostępu, błędów, PHP i systemowe i tworzymy oś czasu incydentu.
• Przy wskazówkach na kompromitację przejmujemy reagowanie na incydenty z ograniczeniem i oczyszczeniem.
• Ustawiamy rotację logów i przechowywanie tak, aby przy następnym incydencie potrzebne dane były dostępne.

Częste pytania

Źródła

• TechTarget: PHP2Shell, 22M exposed servers at risk
• php.net: komunikaty o bezpieczeństwie
• BSI IT-Grundschutz