Als het misgaat

Module 10: Veilig blijven · Leestijd: 11 minuten

Leerdoel: Na deze les herken je de signalen van een gehackte server, zet je de eerste stappen zonder bewijs of back-ups te vernielen, kies je tussen schoonmaken en opnieuw installeren, en weet je wanneer je een datalek moet melden.

Kernbegrippen: incident, signalen, isoleren, snapshot als bewijs, logboek van het incident, opnieuw installeren, sleutels en wachtwoorden vervangen, schone back-up, meldplicht datalekken (72 uur), Autoriteit Persoonsgegevens, noodplan

Een incident herkennen

Een inbraak kondigt zich zelden aan. Meestal zie je iets wat "raar" is. Signalen om serieus te nemen:

• Hoge belasting zonder reden: de processor staat continu op 100%, bijvoorbeeld door een cryptominer. Kijk met top of htop welk proces het is, en onder welke gebruiker.
• Onbekende processen of diensten: een programma met een vreemde naam, vaak in /tmp, /dev/shm of /var/tmp, of een systemd-dienst of timer die je niet zelf hebt gemaakt.
• Uitgaand verkeer dat niet klopt: je aanbieder meldt dat je server spam verstuurt of andere servers aanvalt, of de grafieken van het netwerk in het paneel tonen pieken.
• Nieuwe gebruikers of sleutels: een regel in ~/.ssh/authorized_keys die je niet kent, een gebruiker in /etc/passwd met UID 0, een nieuwe regel in /etc/sudoers.d/.
• Gewijzigde bestanden: onbekende PHP-bestanden in je website, een gewijzigde crontab.
• Logs die verdwenen of leeg zijn: aanvallers wissen graag hun sporen.

Een paar commando's om snel rond te kijken:

anna@web1:~$ top -o %CPU
anna@web1:~$ sudo ss -tunap | grep ESTAB
anna@web1:~$ sudo last -n 20
anna@web1:~$ awk -F: '$3 == 0 {print $1}' /etc/passwd
anna@web1:~$ sudo find /etc/systemd/system /etc/cron* -newer /etc/hostname -type f
anna@web1:~$ for u in /root /home/*; do sudo cat $u/.ssh/authorized_keys 2>/dev/null; done

last toont wie wanneer inlogde, de awk-regel laat alle accounts met UID 0 zien (dat hoort alleen root te zijn), en de find-regel zoekt units en cronbestanden die nieuwer zijn dan een bestand dat bij de installatie is gemaakt.

Let op: op een server die echt gehackt is, kunnen ook deze commando's vervalst zijn. Ze helpen je om iets te vermoeden, niet om te bewijzen dat alles schoon is.

De eerste stappen: rust, isoleren, vastleggen

Het belangrijkste in de eerste minuten is niet in paniek dingen weggooien. Werk in deze volgorde.

1. Begin een logboek. Schrijf op papier of op je laptop (niet op de server) wat je ziet, wanneer, en wat je doet. Dat heb je later nodig om de oorzaak te vinden, voor een melding, aangifte of je verzekering. Het NCSC raadt dit ook aan.

2. Isoleer de server. Voorkom dat hij verder schade doet (spam, aanvallen, gegevens wegsturen) zonder hem uit te zetten:

• zet in de firewall van je aanbieder (als die er is) alles dicht behalve SSH vanaf jouw eigen adres; of
• doe hetzelfde op de server zelf, via de console;
• als het niet anders kan: zet de server uit via het paneel. Dan ben je wel de inhoud van het geheugen kwijt.

3. Maak een snapshot. Een snapshot in het paneel legt de toestand vast zoals hij nu is. Dat is je bewijs en je bron om later uit te zoeken hoe de aanvaller binnenkwam, ook als je de server daarna opnieuw installeert.

4. Stel je back-ups veilig. Controleer of je back-ups buiten de server nog intact zijn, en zorg dat de gehackte server er niet meer bij kan (bijvoorbeeld de toegangssleutel van de server tot de back-upopslag intrekken). Aanvallers proberen ook back-ups te wissen of te versleutelen.

Schoonmaken of opnieuw installeren?

Het verleidelijke antwoord is: het verdachte bestand weghalen, de cryptominer stoppen, klaar. Maar je weet niet wat een aanvaller nog meer heeft gedaan: een tweede achterdeur, een gewijzigd programma, een extra sleutel, een timer die het allemaal terugzet. Een server waar iemand root heeft gehad, kun je niet meer vertrouwen.

Het advies van beheerders en ook van het NCSC is daarom: installeer getroffen systemen opnieuw en herstel je gegevens uit een back-up die zelf niet besmet is. Concreet:

1. Een nieuwe installatie (opnieuw installeren in het paneel, of een nieuwe server).
2. Meteen de basis uit deze cursus: updates, gewone gebruiker met sudo, SSH met nieuwe sleutels, firewall (module 2 tot en met 5).
3. Je applicaties opnieuw installeren uit officiële bronnen, liefst met je compose-bestanden of notities (les 10.4).
4. Gegevens (database, uploads) terugzetten uit een back-up van vóór het incident. Zet geen code of configuratie blind terug: die kan de achterdeur bevatten. Bekijk ook teruggezette gegevens kritisch; een aanvaller kan al langer binnen zijn geweest dan je denkt.
5. Het lek dichten waardoor de aanvaller binnenkwam. Anders gebeurt het opnieuw. Het snapshot uit stap 3 helpt bij het uitzoeken.

Alles vervangen wat gelekt kan zijn

Ga ervan uit dat alles wat op de server stond, in handen van de aanvaller is:

• SSH-sleutels: haal de publieke sleutels die op de server stonden overal weg, maak nieuwe sleutelparen als er privésleutels op de server stonden.
• Wachtwoorden van databases, beheerpanelen en gebruikers van je applicatie.
• API-sleutels en tokens (mail, betalingen, cloudopslag, back-upopslag) uit .env-bestanden en configuratie: intrekken bij de dienst en vervangen.
• Certificaten: de privésleutel van je certificaat lag op de server. Laat het certificaat intrekken en vraag een nieuw aan (met Let's Encrypt gaat dat snel, les 7.3).

Melden: de AVG en anderen

Stonden er persoonsgegevens op de server (klantgegevens, accounts, mailadressen), dan is er mogelijk een datalek. De AVG (artikel 33) zegt dat de verwerkingsverantwoordelijke een datalek zonder onredelijke vertraging en zo mogelijk binnen 72 uur nadat hij er kennis van kreeg, meldt bij de toezichthouder. In Nederland is dat de Autoriteit Persoonsgegevens (AP). Een paar punten uit de uitleg van de AP:

• melden hoeft niet als het lek waarschijnlijk geen risico oplevert voor de betrokkenen; twijfel je, dan meld je;
• heb je nog niet alle informatie, meld dan toch binnen 72 uur en vul later aan;
• de mensen van wie gegevens gelekt zijn, informeer je als er een hoog risico voor hen is;
• elk datalek leg je vast in een eigen register, ook als je niet hoeft te melden.

Beheer je de server voor een klant, dan ben je meestal verwerker: dan moet je de klant (de verwerkingsverantwoordelijke) zonder onredelijke vertraging informeren, zodat die kan melden. Deze les is geen juridisch advies; kijk bij twijfel op de site van de AP.

Verder: meld misbruik dat vanaf je server is gedaan bij je aanbieder (die heeft het vaak al gezien), en doe bij een ernstige aanval aangifte bij de politie. Valt je organisatie onder de Cyberbeveiligingswet (NIS2), dan gelden aparte, kortere meldtermijnen.

Voorbereiden: het noodplan

Een incident gebeurt altijd op een slecht moment. Wat je vooraf hebt geregeld, scheelt uren:

• Weet hoe je de console en de snapshotknop van je aanbieder bereikt, en heb je inloggegevens van het paneel (met tweestapsverificatie) ergens buiten de server.
• Weet waar je back-ups staan, hoe je ze terugzet en dat ze werken (les 8.2).
• Houd een lijst van alle geheimen die op de server staan, zodat je weet wat je moet vervangen.
• Houd een bellijst: je aanbieder, wie er verder iets van de server moet weten (klant, collega), en de contactgegevens voor een datalekmelding.

In de praktijk

In het VPS-scherm van WebOké vind je de console, snapshots, back-ups en de knop om opnieuw te installeren; bij andere aanbieders heten die ongeveer hetzelfde (console of VNC, snapshot, rescue, reinstall). Deze cursus is zelfhulp: niemand kijkt mee op je server en niemand ruimt een incident voor je op. Juist daarom is een noodplan dat je zelf kunt uitvoeren zo belangrijk.

Samenvatting

• Signalen: onverklaarde belasting, onbekende processen, diensten of sleutels, vreemd uitgaand verkeer, gewijzigde of verdwenen bestanden en logs.
• Eerste stappen: logboek bijhouden, de server isoleren, een snapshot als bewijs maken, back-ups veiligstellen.
• Een server waar iemand root had, maak je niet schoon maar installeer je opnieuw; gegevens terug uit een schone back-up, en het lek dichten.
• Vervang alle sleutels, wachtwoorden, tokens en certificaten die op de server stonden.
• Persoonsgegevens geraakt? Een datalek meld je zo mogelijk binnen 72 uur bij de AP, en je legt elk lek vast.

Quiz

Opdracht

Opdracht O10.3: Je noodplan op één kantje. Schrijf voor je eigen server een noodplan van hoogstens één A4: hoe kom je in het paneel, de console en de snapshots; waar staan je back-ups en hoe zet je ze terug; welke geheimen staan op de server; wie moet je informeren (en moet je bij een datalek melden); en welke eerste vijf stappen zet je bij een vermoeden van een inbraak. Bewaar het plan buiten de server.

Verder lezen

• Geen toegang meer tot je VPS: wat nu?
• Snapshots en backups van je VPS
• Een eigen ISO koppelen of je VPS opnieuw installeren
• NCSC, Gehackt, wat nu?: https://www.ncsc.nl/incidenten-en-herstellen/gehackt-wat-nu
• Autoriteit Persoonsgegevens, Meldplicht datalekken: https://www.autoriteitpersoonsgegevens.nl/nl/onderwerpen/beveiliging/meldplicht-datalekken