Analysera webbserverloggar efter ett angrepp: läs åtkomstloggen rätt

Kort sagt: Den som vill analysera åtkomstloggen efter ett angrepp säkrar loggarna först oförändrade och arbetar därefter bara med kopior. Man söker förfrågningar med status 200 mot okända PHP-filer, avvikande POST-förfrågningar, åtkomster till uppladdningskataloger och tidsmönster. För PHP2Shell finns inga publicerade, bekräftade Indicators of Compromise, därför räknas helhetsbilden från flera loggkällor.

Säkra först, analysera sedan

Loggfiler roteras på de flesta servrar automatiskt och raderas efter en fast tid. Efter ett angrepp är därför första steget att säkra de befintliga loggarna innan de försvinner. Det gäller även när ni ännu inte är säkra på om något över huvud taget har hänt. För PHP2Shell rekommenderar fackpressen att spara loggar från och med den 20 oktober 2026.

# Kopiera loggar med tidsstämplar och notera kontrollsummor
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"

Lägg dessutom säkerhetskopian på ett annat system. En angripare med åtkomst till servern kunde annars ändra loggarna i efterhand. Kontrollsummorna visar senare att kopian är oförändrad. Behövs en bevisgill säkring, till exempel för en anmälan eller försäkringen, bör en IT-forensik ta över säkringen.

Var loggarna ligger och hur en rad är uppbyggd

Lagringsplatserna beror på distribution och förvaltningsgränssnitt. Typiska sökvägar:

I det utbredda combined-formatet innehåller varje rad klientadressen, datum och klockslag, förfrågans metod och sökväg, statuskoden, svarsstorleken i byte, referern och user-agenten. Var uppmärksam på tidszonen i tidsstämpeln, särskilt när ni jämför loggar med meddelanden i UTC. PHP2Shell-patcharna publicerades till exempel den 21 oktober 2026 kl. 14.00 UTC, alltså kl. 16.00 tysk tid.

Ligger er webbplats bakom en proxy, ett CDN eller en lastbalanserare står i loggen kanske bara dess adress. Besökarens verkliga adress finns då i ett eget fält eller i loggarna hos den förkopplade tjänsten.

Utan kommandorad: loggar i panelen eller hos webbhotellet

Alla driftansvariga har inte skalåtkomst. Vid delat webbhotell eller förvaltade servrar erbjuder förvaltningsgränssnitten oftast en loggvy och nedladdning av åtkomst- och felloggar. Ladda ned filerna för hela den tillgängliga perioden och förvara dem säkert. Fråga ert webbhotell skriftligen hur länge loggar sparas och om äldre nivåer kan säkras innan de löper ut.

Beakta därvid dataskyddet: Loggar innehåller IP-adresser och ofta fler personuppgifter. Lagra kopiorna åtkomstskyddade, lämna dem bara vidare till personer som behöver dem för utredningen och bestäm när de ska raderas efter att incidenten avslutats.

Analysera åtkomstloggen: de viktigaste frågorna

Följande kommandon läser bara och passar för Nginx och Apache i combined-format. Roterade och komprimerade filer söker ni igenom med zgrep eller zcat.

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

# Lyckade förfrågningar mot PHP-filer, efter frekvens
awk '$9 == 200 && $7 ~ /\.php/ {split($7,p,"?"); print p[1]}' "$LOG" | sort | uniq -c | sort -rn | head -40

# PHP-anrop i uppladdnings-, cache- eller bildkataloger
grep -E '"(GET|POST) /[^ ]*(uploads|cache|images|tmp)/[^ ]*\.php' "$LOG"

# POST-förfrågningar efter mål och adress
awk '$6 == "\"POST" {print $1, $7}' "$LOG" | sort | uniq -c | sort -rn | head -40

# 5xx-fel per timme: ansamlingar kan tyda på kraschande PHP-processer
awk '$9 ~ /^5/ {print substr($4, 2, 14)}' "$LOG" | sort | uniq -c

# Ta med roterade loggar
zgrep -h ' 200 ' /var/log/nginx/access.log.*.gz | grep -c '\.php'

Vid den första frågan är särskilt filnamn intressanta som ni inte känner till eller som inte hör till applikationen. Jämför misstänkta filer med filsystemet: När skapades de, vem äger dem, vad står i dem? Anvisningar om det ger guiden Upptäcka och ta bort webshell.

Särdrag vid PHP2Shell

Vid PHP2Shell finns sårbarheterna i PHP:s hantering av förfrågningar. Vid mod_php visades en exploit innan någon applikationskod ens körs. Det betyder: En förfrågan mot en helt normal sida kan räcka. I åtkomstloggen kan en sådan förfrågan se oansenlig ut, eftersom innehållet i förfrågans kropp inte står där.

Det finns inga publicerade, bekräftade Indicators of Compromise. Var därför uppmärksam på beteende och samband, till exempel från och med den 17 oktober 2026, det enligt mediarapporter första observerade angreppsförsöket:

• Ansamlingar av 500-fel eller avbrutna svar på vanliga sidor.
• Meddelanden om slut på minne eller avslutade workers i fel- och PHP-FPM-loggen.
• Nya PHP-filer eller ändrade filer kort efter sådana ansamlingar.
• Nya cronjobb, processer eller utgående förbindelser under webbserverns användare.

Ingen av dessa signaler är ensam ett bevis. Tillsammans med andra spår ger de dock en bild som besvarar frågan om en komprometterad server eller motiverar en djupare utredning. En översikt över tecknen finns under Är jag redan komprometterad?.

Fler källor: fellogg, PHP-FPM och systemloggar

Åtkomstloggen visar bara en del. För en fullständig bild tar ni med fler källor:

# PHP-FPM och webbserver i journalen från ett datum
journalctl -u 'php*-fpm*' --since "2026-10-17" --no-pager | tail -200

# Inloggningar på servern
last -Fa | head -40
grep -E 'Accepted|Failed' /var/log/auth.log | tail -100

# Kontrollera schemalagda uppgifter för alla användare
for u in $(cut -d: -f1 /etc/passwd); do crontab -l -u "$u" 2>/dev/null | sed "s/^/$u: /"; done

Typiska fel vid analysen är att bara söka igenom den aktuella i stället för även de roterade loggarna, att förbise tidszonen och att ta enskilda träffar från automatiserade skannrar för ett lyckat angrepp. Lika riskabelt är motsatsen: att tolka en oansenlig åtkomstlogg som en avvisning av faran, fast fellogg och filsystem ännu inte är kontrollerade.

Anteckna varje fynd med klockslag, källa och iakttagelse i en tidslinje. Den tidslinjen är senare underlag för beslut, för anmälningar till myndigheter eller försäkringsgivare och för slutrapporten.

Hur hjälper PHP SOS konkret?

• Vi säkrar loggar och relevanta filer så att de förblir spårbara för senare kontroller.
• Vi analyserar åtkomst-, fel-, PHP- och systemloggar tillsammans och upprättar en tidslinje för incidenten.
• Vid tecken på komprometterad server tar vi över incidenthanteringen med begränsning och sanering.
• Vi ställer in loggrotation och lagring så att nödvändiga data finns vid nästa incident.

Vanliga frågor

Källor

• TechTarget: PHP2Shell, 22 miljoner exponerade servrar i riskzonen
• php.net: säkerhetsmeddelanden
• BSI IT-Grundschutz