Kort gezegd: Voordat u een gecompromitteerde server opnieuw opzet, stelt u het bewijs veilig in de volgorde van vluchtigheid: eerst processen, verbindingen en aangemelde gebruikers, dan logs en configuratie, dan een volledige kopie van het systeem en de gegevens van voorgeschakelde diensten. Elke kopie krijgt een controlesom en wordt buiten de server bewaard. De server wordt daarvoor van het netwerk gehaald, maar niet uitgeschakeld.
De reflex om meteen opnieuw te beginnen
Wie een inbraak ontdekt, wil die zo snel mogelijk beëindigen. Een vers systeem, schoon geïnstalleerd, met nieuwe wachtwoorden: dat voelt als controle. Technisch is een herinstallatie vaak ook de juiste weg, zeker als een aanvaller rootrechten had.
Het probleem is het tijdstip. Met het oude systeem verdwijnen alle antwoorden op de vragen die in de dagen erna komen. Via welke kwetsbaarheid kwam de aanvaller binnen? Sinds wanneer zat hij in het systeem? Had hij toegang tot klantgegevens? Is de databaseserver ernaast ook getroffen? Zonder sporen blijven alleen vermoedens over, en die helpen noch bij gegevensbescherming noch bij de verzekering.
Na PHP2Shell komt er een bijzonder punt bij: er zijn geen gepubliceerde, bevestigde Indicators of Compromise. Of en hoe een server is getroffen, valt alleen af te lezen uit het gedrag, dus uit precies de sporen die een overhaaste herinstallatie wist. De vakpers adviseert serverlogs vanaf 20-10-2026 te bewaren.
Bewijs veiligstellen op de server: de volgorde telt
Sporen zijn verschillend vluchtig. Wat in het werkgeheugen staat, is bij de volgende herstart weg. Logs overleven langer, maar worden geroteerd. Gegevens bij voorgeschakelde diensten verdwijnen na hun eigen termijnen. Daaruit volgt de volgorde:
| Spoor | Vluchtigheid | Hoe veiligstellen |
|---|---|---|
| Processen, netwerkverbindingen, aangemelde gebruikers | verdwijnt bij herstart | uitvoer van systeemopdrachten naar bestanden schrijven |
| Werkgeheugen | verdwijnt bij herstart | alleen met speciaal gereedschap, taak voor forensisch specialisten |
Tijdelijke bestanden in /tmp of /dev/shm |
vaak gewist bij herstart | kopiëren zonder uit te voeren |
| Logs van webserver, PHP, systeem | worden geroteerd | volledig kopiëren, rotatie stoppen |
| Bestandssysteem en database | stabiel tot de herinstallatie | snapshot of schijfkopie, database-export |
| CDN, WAF, firewall, hostingprovider | bewaring volgens termijnen van de aanbieder | export aanvragen, schriftelijk laten bevestigen |
Het werkgeheugen stelt u alleen veilig als iemand met geschikt gereedschap en ervaring klaarstaat. Bij systemen met gevoelige gegevens of een te verwachten rechtsgeschil moet een IT-forensisch onderzoek dat overnemen.
Vluchtige gegevens in enkele minuten vastleggen
De volgende opdrachten veranderen niets aan het systeem. Ze schrijven de actuele toestand naar bestanden die daarna buiten de server worden bewaard. Maak de doelmap bij voorkeur aan op een aangesloten, aparte gegevensdrager:
ZIEL=/mnt/sicherung/fall-$(date -u +%Y%m%dT%H%MZ)
mkdir -p "$ZIEL"
date -u > "$ZIEL/zeitpunkt-utc.txt"
ps auxwwf > "$ZIEL/prozesse.txt"
ss -tunap > "$ZIEL/verbindungen.txt"
who -a > "$ZIEL/angemeldet.txt"
last -F > "$ZIEL/anmeldungen.txt"
ip addr > "$ZIEL/netz.txt"; ip route >> "$ZIEL/netz.txt"
for u in $(cut -d: -f1 /etc/passwd); do crontab -l -u "$u" 2>/dev/null | sed "s/^/$u: /"; done > "$ZIEL/cronjobs.txt"
sha256sum "$ZIEL"/* > "$ZIEL.sha256"
Hoe u daarna de logs volledig veiligstelt en analyseert, beschrijft de gids Webserverlogs na een aanval analyseren. Bij virtuele servers is een snapshot via het beheer van de aanbieder de eenvoudigste weg naar een volledige kopie. Hij legt het systeem vast zonder dat u op de gecompromitteerde server extra gereedschap hoeft te starten.
Zodat de back-up later iets waard is
Een back-up is maar zo goed als haar bewijskracht. Drie regels maken haar bruikbaar:
- Controlesommen: elk veiliggesteld bestand krijgt een SHA-256-controlesom. Daarmee kunt u later aantonen dat de kopie ongewijzigd is.
- Logboek: wie heeft wanneer wat veiliggesteld, met welke opdracht, waarheen? Elke overdracht aan derden wordt vastgelegd. Vakmensen noemen dat de bewijsketen.
- Gescheiden opslag: kopieën horen op een systeem waartoe de aanvaller geen toegang had en worden alleen lezend gebruikt.
Werk daarna alleen nog met kopieën. Elke analyse op het origineel wijzigt tijdstempels en kan sporen overschrijven. Voer verdachte bestanden nooit uit en open ze niet via de browser.
Vraag de logs van CDN, WAF en hostingprovider vroeg op. Deze gegevens staan buiten uw server en zijn voor een aanvaller moeilijk te manipuleren, maar worden vaak maar kort bewaard.
Wat het bewijs vernietigt
Veel sporen gaan niet door toedoen van de aanvaller verloren, maar door goedbedoelde eerste hulp. Deze stappen moeten vóór het veiligstellen achterwege blijven:
- Herstarten of uitschakelen: processen, verbindingen en werkgeheugen zijn daarna weg.
- Virusscanner met automatische verwijdering: hij verwijdert bestanden voordat iemand ze heeft veiliggesteld en wijzigt tijdstempels.
- Logs of tijdelijke mappen opruimen: ook als de ruimte krap wordt, eerst kopiëren, dan wissen.
- Nieuw gereedschap van internet op de server installeren: elke installatie schrijft naar het bestandssysteem en kan sporen overschrijven.
- Zonder noodzaak inloggen met bevoorrechte toegangsgegevens: draait er nog schadelijke code op de server, dan kunnen ingevoerde wachtwoorden worden meegelezen.
Juist verzekeraars vragen later wat wanneer is veiliggesteld. Aanwijzingen over typische verplichtingen vindt u onder Cyberverzekering: wat telt bij schade.
Afwegen: hoeveel tijd is er voor het veiligstellen?
Niet elk incident laat een lange back-up toe. Loopt er op dat moment gegevensuitstroom of worden bezoekers aangevallen, dan heeft beheersing voorrang. Het losmaken van het netwerk bij een draaiend systeem combineert beide: de aanvaller verliest de toegang, de sporen blijven behouden. Voor de meeste webservers volstaat daarna een overzienbare tijdspanne voor de vluchtige gegevens en de snapshot.
Neem de beslissing bewust en leg haar vast: wie heeft besloten wanneer opnieuw wordt opgezet, en wat is daarvóór veiliggesteld? Deze notitie wordt later onderdeel van de tijdlijn van het incident. Of herinstallatie of opschoning de juiste weg is, belicht het artikel Server opnieuw opzetten of opschonen?.
Hoe helpt PHP SOS concreet?
- Wij stellen vluchtige gegevens, logs en systeemkopieën veilig in de juiste volgorde, met controlesommen en logboek.
- Wij vragen de gegevens van voorgeschakelde diensten op voordat hun bewaartermijnen verlopen.
- Zo nodig nemen wij met gespecialiseerde partners het forensisch veiligstellen en analyseren over.
- Pas daarna zetten wij de server opnieuw op, sluiten wij de toegangspoort en documenteren wij het incident, tot het is afgerond.
Veelgestelde vragen
Waarom moet ik vóór het opnieuw opzetten bewijs veiligstellen?
Omdat alleen de sporen laten zien hoe de aanvaller binnenkwam, hoe lang hij in het systeem zat en welke gegevens hij kon bereiken. Deze antwoorden hebt u nodig voor gegevensbescherming, verzekering en de vraag of er andere systemen zijn getroffen. Na de herinstallatie zijn ze verloren.
Wat is bij het veiligstellen het meest urgent?
Vluchtige gegevens zoals lopende processen, netwerkverbindingen en aangemelde gebruikers verdwijnen bij het afsluiten. Die legt u als eerste vast. Daarna volgen logs, een kopie van het systeem en gegevens van voorgeschakelde diensten.
Is een gewone back-up genoeg als bewijsmateriaal?
Meestal niet. Veel back-ups bevatten geen logs, geen systeembestanden en geen metagegevens zoals tijdstempels en eigenaren. Voor het veiligstellen van bewijs hebt u een volledige, ongewijzigde kopie met controlesom nodig, idealiter een snapshot of een schijfkopie.
Mag ik de server vóór het veiligstellen van het netwerk halen?
Ja, zolang hij blijft draaien. Een netwerkscheiding stopt gegevensuitstroom en bediening op afstand zonder vluchtige sporen te vernietigen. Een herstart of uitschakeling wist daarentegen het werkgeheugen en de lopende processen.