Wat te doen als je server is gecompromitteerd
Kort antwoord
Isoleer de server eerst, voordat je gaat onderzoeken of herstarten. Bewaar zoveel bewijsmateriaal als je kunt, zoek uit hoe de aanvaller binnenkwam, en herbouw daarna vanaf een bekend schoon image in plaats van te proberen een systeem handmatig schoon te maken dat je niet meer volledig kunt vertrouwen. Roteer alle inloggegevens waartoe de server toegang had, niet alleen de gegevens waarvan je vermoedt dat ze zijn gebruikt, en harden daarna voordat je de server weer online brengt.
Ontdekken dat je server is gecompromitteerd is stressvol, maar de reactie erop is een vrij standaard reeks stappen. Rustig en in de juiste volgorde te werk gaan is belangrijker dan snel de verkeerde kant op bewegen.
Stap 1: isoleer eerst
Sluit netwerktoegang af voordat je iets anders doet
De eerste prioriteit is verdere schade stoppen, of dat nu doorlopende data-exfiltratie is, de server die wordt gebruikt om andere systemen aan te vallen, of de aanvaller die simpelweg merkt dat je hem op het spoor bent en zijn sporen begint te wissen. Koppel de server los van het netwerk voordat je begint te graven in wat er is gebeurd.
Hoe je dat doet, hangt af van wat je draait. Op elke server waar je nog bij kunt: blokkeer al het inkomende en uitgaande verkeer in de firewall van het besturingssysteem, en stop de services die de aanvaller gebruikt. Op een Flexible VPS kun je een noodregel toevoegen bij Firewall in Portal, die vóór de machine werkt in plaats van erop. Op een dedicated of bare metal server houdt out-of-band management via het tabblad Remote Access je op de console nadat je het netwerk hebt dichtgezet. Kun je de server helemaal niet bereiken, open dan een supportticket en beschrijf wat je ziet.
Weersta de neiging om de server op dit moment gewoon te herstarten. Een herstart kan precies de dingen wissen die je moet zien: actieve processen, open netwerkverbindingen, bewijs in het geheugen, die je vertellen hoe de aanvaller binnenkwam.
Stap 2: bewaar bewijs waar mogelijk
Kopieer weg wat anders verdwijnt
Logs roteren en worden overschreven, dus kopieer relevante logbestanden van de server voordat dat gebeurt. Heb je nog toegang tot een live shell voordat je besluit volledig te isoleren, noteer dan de actieve processen en huidige netwerkverbindingen. Dat is vaak het duidelijkste signaal van wat er daadwerkelijk gebeurt op een gecompromitteerde server, en het is verdwenen zodra het systeem herstart.
Stap 3: identificeer het toegangspunt
Achterhaal hoe de aanvaller binnenkwam
Controleer de authenticatielogs op het eerste toegangspunt: een onverwachte login, een gekraakt of hergebruikt wachtwoord, een misbruikte service. Zoek naar alles wat achteraf is toegevoegd: nieuwe gebruikersaccounts die jij niet hebt aangemaakt, onverwachte cron-jobs, regels toegevoegd aan authorized_keys die je niet herkent, en processen die draaien zonder duidelijke reden om te bestaan. Weten hoe de aanvaller binnenkwam is net zo belangrijk als opruimen na afloop: zonder die kennis loop je het risico rechtstreeks weer in hetzelfde gat te lopen zodra de server weer online is.
Stap 4: indammen en opschonen
Herbouw in plaats van ter plekke opschonen
Zodra een aanvaller toegang heeft gehad, kun je niets meer op dat systeem volledig vertrouwen, ook niet de tools die je normaal gebruikt om het te inspecteren. Het veiligste pad is bijna altijd opnieuw installeren vanaf een bekend schoon image, of terugzetten vanuit een backup die is gemaakt vóór de compromittering, in plaats van te proberen elk spoor van de inbraak handmatig op te sporen en te verwijderen. Handmatig opschonen van een systeem dat je niet volledig kunt vertrouwen brengt het risico met zich mee dat je iets mist: een backdoor, een aangepaste binary, waarmee de aanvaller er zo weer in kan.
Stap 5: roteer alle inloggegevens
Ga ervan uit dat alles waar de server bij kon is blootgesteld
Roteer SSH-keys, wachtwoorden en API-keys: alles wat plausibel gelezen of gekopieerd kon zijn terwijl de aanvaller toegang had, niet alleen de specifieke inloggegevens waarvan je denkt dat ze daadwerkelijk zijn gebruikt. Had de server toegang tot inloggegevens van andere systemen, zoals databasewachtwoorden of API-keys van derden, dan moeten die ook geroteerd worden. Behandel "kan zijn blootgesteld" hier als "is blootgesteld", dat is een veel veiligere aanname dan het alternatief.
Stap 6: controleer en harden voordat je weer live gaat
Sluit de deur waarvan je nu weet dat hij openstond
Voordat je de herbouwde server weer in productie neemt: patch wat de aanvaller heeft binnengelaten, controleer je firewallregels opnieuw, en zorg dat monitoring deze keer daadwerkelijk meekijkt. Dit is ook een logisch moment om de standaard hardeningsstappen door te lopen als je dat nog niet had gedaan, zie Een nieuwe VPS hardenen en Je SSH-beveiliging verbeteren, plus een regelmatig patchritme aanhouden vanaf nu, zie Patchmanagement: een updatestrategie opzetten voor je server.
Preventie en een werkende backup maken dit behapbaar
Niets van het bovenstaande is prettig om onder druk te doen, en hoe behapbaar het aanvoelt hangt meestal af van werk dat je van tevoren hebt gedaan: een gehardende basisconfiguratie, actuele backups die zijn gemaakt voordat er iets misging, en monitoring die ongebruikelijke activiteit eerder had gesignaleerd. Zie Backups en snapshots: wat is het verschil als je niet zeker weet of je huidige backupopzet daadwerkelijk een schoon herstelpunt zou opleveren. Weet je niet zeker welke hulp beschikbaar is terwijl je hiermee bezig bent, dan is het openen van een supportticket een redelijke stap, zie Een supportticket aanmaken en een prioriteit kiezen.