Linux server gehackt: wat moet je meteen doen?

Stappenplan: de eerste 60 minuten na een hack

Bij een incident response op Linux telt de volgorde. Wie meteen gaat opruimen, wist bewijs en laat de aanvaller vaak ongemerkt achter. Wie te lang wacht, laat data weglekken. Werk daarom deze stappen af:

1. Bewaar je kalmte en noteer de tijd. Schrijf op wat je zag, wanneer, en wat je al hebt gedaan. Dit tijdlijntje is later goud waard.
2. Isoleer de server. Beperk het netwerkverkeer, zonder de machine uit te zetten.
3. Zet bewijs veilig. Logs, procesoverzicht en netwerkverbindingen kopieer je naar een andere machine.
4. Bepaal de omvang. Welke accounts, servers en data zijn geraakt? Kijk ook naar andere systemen met dezelfde sleutels of wachtwoorden.
5. Vervang alle inloggegevens vanaf een schone computer.
6. Kies tussen opschonen en herinstalleren en dicht het lek dat de aanvaller gebruikte.
7. Meld, informeer en evalueer waar dat nodig is.

Stap 1: isoleer de server, maar zet hem niet uit

Een harde uitschakeling lijkt logisch, maar je verliest daarmee alles wat in het werkgeheugen staat: lopende processen, actieve verbindingen en soms de enige sporen van de malware. Beperk liever het verkeer. De snelste manier is vaak de firewall of het netwerkpaneel van je hoster (security group, VLAN of "rescue network"). Lukt dat niet, dan kan dit op de server zelf:

# Sta alleen jouw eigen IP nog toe op SSH (vervang 203.0.113.10)
sudo ufw default deny incoming
sudo ufw default deny outgoing
sudo ufw allow from 203.0.113.10 to any port 22 proto tcp
sudo ufw enable

Let op: een aanvaller met root-rechten kan deze regels weer opheffen. Een firewall bij de hoster is dus betrouwbaarder. Draait er een productiedienst op die niet mag stoppen? Overleg dan eerst wat de afweging is, want soms is korte downtime goedkoper dan doorlopend datalekken.

Linux server hack herkennen: dit zijn de signalen

Veel hacks blijven weken onopgemerkt. Aanvallers hebben er geen belang bij dat je het merkt. Toch laten ze bijna altijd sporen na. Dit zijn de indicatoren van compromittering waar je als eerste op let:

Eerste controles in de terminal

Deze opdrachten zijn alleen-lezen en veilig om uit te voeren. Houd er rekening mee dat een rootkit de uitvoer van tools als ps en ls kan vervalsen. Zie je niets verdachts, dan is de server dus nog niet automatisch schoon.

# Debian/Ubuntu
sudo grep "Accepted" /var/log/auth.log | tail -50
sudo grep "Failed password" /var/log/auth.log | tail -50
# RHEL/AlmaLinux/Rocky
sudo grep "Accepted" /var/log/secure | tail -50

# Extra gebruikers met UID 0 (naast root)
awk -F: '$3==0 {print $1}' /etc/passwd
# Onbekende SSH-sleutels
sudo cat /root/.ssh/authorized_keys
# Cronjobs
sudo crontab -l; ls -la /etc/cron.*
# Recent gewijzigde SUID-bestanden
sudo find / -xdev -perm -4000 -type f -mtime -14
# Integriteit van geïnstalleerde pakketten
sudo debsums -c        # Debian/Ubuntu
sudo rpm -Va           # RHEL-familie

Een tweede gebruiker met UID 0, een onbekende SSH-sleutel van recent of een SUID-bestand dat vorige week is aangemaakt: dit zijn serieuze aanwijzingen. Samen met afwijkend netwerkverkeer kun je ervan uitgaan dat de server is overgenomen.

Logs veiligstellen: zo bewaar je het bewijs

De logs vertellen hoe de aanvaller binnenkwam, wat hij deed en hoe lang hij toegang had. Dat is de basis voor elke vervolgstap, ook voor je verzekeraar en voor een eventuele melding bij de Autoriteit Persoonsgegevens. Op Debian en Ubuntu staan de inlogpogingen in /var/log/auth.log, op RHEL, AlmaLinux en Rocky Linux in /var/log/secure.

sudo tar czf /root/logs-$(date +%F).tar.gz /var/log
last -aiF > /root/last.txt
sudo lastb -aiF > /root/lastb.txt
ps auxfww > /root/processen.txt
sudo ss -tulpna > /root/netwerk.txt
# Kopieer daarna alles naar een andere machine, bijvoorbeeld met scp

Bewaar daarnaast de logs van je webserver (/var/log/nginx of /var/log/apache2), de journal-logs (journalctl) en de firewalllogs van je hoster. Staat er centrale logging op een andere server? Dan zijn die logs betrouwbaarder, want de aanvaller kan ze niet zomaar aanpassen.

Heb je een virtuele machine? Maak dan ook een snapshot of disk-image. Daarmee kan een specialist later forensisch onderzoek doen zonder dat de oorspronkelijke staat verandert.

Waar zoek je in de logs naar?

• Het eerste succesvolle onbekende login-moment. Dit is meestal het begin van de inbraak.
• Brute-force-patronen gevolgd door een geslaagde login vanaf hetzelfde IP-adres.
• Gebruik van sudo of su kort na een nieuwe login, wat wijst op privilege escalation.
• Verdachte verzoeken in de webserverlog, zoals uploads van .php-bestanden, wget- of curl-commando's in parameters, of verzoeken naar bekende exploit-paden.

Wachtwoorden, sleutels en tokens vervangen

Ga ervan uit dat alles wat op de server stond, in handen van de aanvaller is. Dat geldt voor wachtwoorden, maar ook voor sleutels en tokens die je minder snel bedenkt. Doe dit werk vanaf een schone computer, niet vanaf de gehackte server en liefst niet vanaf een laptop die met die server is verbonden geweest.

• Alle gebruikers- en rootwachtwoorden op de server en op andere servers waar dezelfde wachtwoorden gebruikt worden
• SSH-sleutelparen (privé-sleutels die op de server stonden of er via agent-forwarding bij konden)
• Database-wachtwoorden en de verbindingsgegevens in je configuratiebestanden of .env-bestanden
• API-sleutels, cloudtokens, SMTP-gegevens en betaalprovider-sleutels
• TLS-certificaten en bijbehorende privésleutels
• CI/CD-secrets en deploy-sleutels die toegang geven tot de server

Vervang ook sleutels in authorized_keys op andere servers die vanaf deze machine bereikbaar waren. Aanvallers gebruiken een gehackte server vaak als springplank (lateral movement) naar de rest van je infrastructuur.

Linux malware verwijderen of de server opnieuw installeren?

Dit is de vraag die iedereen stelt. Het eerlijke antwoord: herinstalleren is bijna altijd de veiligste keuze. Je kunt malware verwijderen als je precies weet wat er is gebeurd, maar je kunt nooit bewijzen dat je alles hebt gevonden. Rootkits passen kernelmodules en systeemtools aan, backdoors verstoppen zich in cronjobs, systemd-units, .bashrc-bestanden, PAM-modules en zelfs in je eigen applicatiecode.

Wanneer is opschonen verdedigbaar?

Alleen als de inbraak aantoonbaar beperkt is gebleven tot één applicatie of één gebruiker zonder root-rechten, en je de oorzaak kunt aanwijzen. Denk aan een gehackt WordPress-account waarbij de aanvaller niet buiten de webroot is gekomen. Ook dan geldt: laat de controle het liefst door iemand uitvoeren die dit dagelijks doet.

Zo installeer je veilig opnieuw

1. Bouw een nieuwe server op vanaf een officiële installatie-image, niet vanuit een kopie van de gehackte machine.
2. Haal data terug uit een back-up van vóór het eerste verdachte moment in je logs. Controleer of de back-up zelf niet besmet is.
3. Zet configuratie en code over vanuit versiebeheer, en vergelijk handmatig wat afwijkt.
4. Dicht eerst het lek (patch, verwijder de kwetsbare dienst, zet MFA aan), anders is de nieuwe server binnen enkele uren weer gehackt.
5. Zet monitoring en alerting aan voordat de server weer live gaat.

Meldplicht en communicatie na een Linux hack

Stonden er persoonsgegevens op de server, zoals klantgegevens, e-mailadressen of medewerkersdata? Dan kan er sprake zijn van een datalek. Onder de AVG meld je een datalek met risico voor betrokkenen binnen 72 uur na ontdekking bij de Autoriteit Persoonsgegevens. Is het risico hoog, dan informeer je ook de getroffen personen.

Leg daarnaast altijd vast wat er is gebeurd, ook als je niet hoeft te melden. Informeer je hoster, je cyberverzekeraar (let op de meldtermijnen in je polis) en zo nodig je klanten. Doe aangifte bij de politie als er sprake is van afpersing of datadiefstal. Open en snelle communicatie schaadt je reputatie minder dan een lek dat later toch uitkomt.

Herhaling voorkomen: server hardening na een incident

Een hack is vervelend, maar ook een kans om je beveiliging structureel op orde te brengen. Dit zijn de maatregelen die in de praktijk het meeste verschil maken:

• SSH hardenen: wachtwoord-login uit, alleen sleutels, root-login uit en toegang beperken tot bekende IP-adressen of een VPN.
• Updates automatiseren: beveiligingspatches voor kernel en pakketten tijdig installeren, met unattended-upgrades of dnf-automatic.
• Minimale aanvalsoppervlakte: alleen de poorten en diensten open die echt nodig zijn.
• Fail2ban of CrowdSec om brute-force-pogingen automatisch te blokkeren.
• Centrale logging en alerting, zodat een aanvaller logs niet ongemerkt kan wissen en jij verdachte logins direct ziet.
• Back-ups buiten de server, die je regelmatig test en die niet beschrijfbaar zijn vanaf de productieserver.
• Least privilege: applicaties draaien onder eigen gebruikers zonder sudo-rechten.
• Een pentest: laat een specialist je server aanvallen voordat een echte aanvaller dat doet. Zo vind je kwetsbare diensten en zwakke web-applicaties vóór ze misbruikt worden.

Wil je dit niet zelf bijhouden? Met SLA as a Service controleren en beheren wij je Linux-omgeving periodiek, en met onze pentesting voor Linux weet je zeker waar de gaten zitten. Bekijk de tarieven voor een indruk van de kosten.

Wat je beter niet kunt doen

• Bestanden verwijderen of de server meteen herstarten zonder eerst bewijs te bewaren
• Nieuwe wachtwoorden instellen vanaf de gehackte server zelf
• Alleen het symptoom bestrijden (de miner stoppen) en niet zoeken naar de oorzaak
• Het incident verzwijgen voor je team, hoster of klanten
• Een back-up terugzetten zonder te controleren of die van vóór de inbraak is