Vanaf het moment dat het ‘mijn server’ wordt, is alles mijn verantwoordelijkheid
De vorige keer ben ik over de muur van de Linux CLI en rechten (Permissions) heen geklommen. chmod, chown, en de absolute no-go chmod 777. Toegangscontrole op bestandsniveau had ik redelijk onder de knie.
Maar in die tijd leefde ik in een grote illusie. Ik dacht dat mijn server veilig was zolang ik de ‘bestandsrechten’ goed beheerde.
“Serverbeveiliging? Is dat niet iets voor het security-team?”
Bij een groot bedrijf misschien. Maar ik ben een solo-ontwikkelaar. Serverbeheerder, beveiligingsverantwoordelijke, netwerkengineer — dat was allemaal ‘ik’. Alle verantwoordelijkheid voor security lag op mijn schouders.
En wat me dat pas echt deed inzien, was het serverlogboek dat ik op een maandagochtend ontdekte.
De crisis: iemand klopte op de deur van mijn server
Op een maandagochtend loggde ik zoals gewoonlijk via SSH in op de server om de logs te bekijken, en ik zag iets vreemds.
# Recente mislukte SSH-aanmeldpogingen bekijken
$ grep "Failed password" /var/log/auth.log | tail -20
De logs die op het scherm verschenen, bezorgden me kippenvel.
Feb 10 03:14:22 sshd: Failed password for root from 185.220.xx.xx
Feb 10 03:14:25 sshd: Failed password for root from 185.220.xx.xx
Feb 10 03:14:27 sshd: Failed password for admin from 185.220.xx.xx
Feb 10 03:14:30 sshd: Failed password for ubuntu from 185.220.xx.xx
...
Honderden loginpogingen vanaf 3 uur ’s nachts. Het IP-adres was uit het buitenland. De accountnamen rouleerden tussen root, admin en ubuntu. Dit was iemand die een ‘geautomatiseerd programma (bot)’ gebruikte om wachtwoorden met brute force (Brute Force) te kraken.
“Eh? Ik ben toch nog niet gehackt, hè…?”
Gelukkig waren ze niet binnengekomen. Maar kun je echt zeggen “ik ben veilig, ze zijn er niet doorheen” terwijl er een inbreker voor je deur staat die sleutel na sleutel uitprobeert? Ik begon meteen de beveiligingsstatus van de server te controleren.
Stap 1: Vergrendel de voordeur — SSH harden
De voordeur van de server is SSH (Secure Shell). Precies datgene wat ik gebruik om met de server te verbinden. Het probleem is dat hackers diezelfde deur proberen binnen te komen. Het eerste wat moet gebeuren, is deze voordeur versterken.
SSH-poort wijzigen (standaard 22 → een ander nummer)
De standaard SSH-poort is 22. De geautomatiseerde scanners van hackers kloppen als eerste op poort 22. Alleen al door het poortnummer te wijzigen, filter je meer dan 90% van de brute-force-aanvallen eruit.
# Open het SSH-configuratiebestand
$ sudo vi /etc/ssh/sshd_config
# Wijzig het poortnummer (standaard 22 → bv. 2222)
Port 2222
# Start de SSH-service opnieuw
$ sudo systemctl restart sshd
Ter vergelijking: een inbreker viseert meestal de hoofdingang op de begane grond (poort 22). Verplaats je de ingang naar een dakdeur op de derde verdieping (poort 2222), dan vinden de meeste inbrekers niet eens waar de deur zit.
Directe root-login blokkeren
In de logs is het eerste account dat hackers proberen ‘root’. root is het hoogste beheerdersaccount van Linux, dus als dat wordt gekraakt, heeft de aanvaller de hele server in handen.
# Directe root-login uitschakelen in het SSH-configuratiebestand
$ sudo vi /etc/ssh/sshd_config
PermitRootLogin no
Nu is inloggen via SSH als root überhaupt niet meer mogelijk. Log in met een gewoon account en verhoog rechten alleen indien nodig met sudo.
SSH-sleutelauthenticatie in plaats van wachtwoorden
Hoe complex een wachtwoord ook is, als een geautomatiseerd programma tienduizenden combinaties probeert, lukt het ze ooit. De veiligste methode is wachtwoordlogin volledig uitschakelen en alleen verbinden via een ‘SSH-sleutel (Key)’.
# Genereer een SSH-sleutelpaar op je eigen computer (lokaal)
$ ssh-keygen -t rsa -b 4096
# Kopieer de publieke sleutel naar de server
$ ssh-copy-id -p 2222 user@my-server-ip
# Schakel wachtwoordlogin uit op de server
$ sudo vi /etc/ssh/sshd_config
PasswordAuthentication no
SSH-sleutelauthenticatie is geen ‘sleutel’, maar ‘vingerafdrukherkenning’. Een wachtwoord (sleutel) is te kopiëren, maar de privésleutel (vingerafdruk) die alleen op mijn eigen computer staat, is praktisch onmogelijk te dupliceren.
Stap 2: Zet een muur op — de firewall
Zodra de voordeur (SSH) is versterkt, is het tijd om een muur rond het gebouw te zetten en de in- en uitgang te controleren. Dit is de ‘firewall (Firewall)’.
Een server heeft in totaal 65.535 poorten (doorgangen). Zonder firewall staan al die 60.000+ deuren wagenwijd open. Je moet alleen de deuren openen die je nodig hebt en de rest allemaal dichthouden.
Het eenvoudigst te gebruiken firewall-tool op Linux is ‘UFW (Uncomplicated Firewall)’.
# UFW activeren
$ sudo ufw enable
# Standaardbeleid: alle inkomend verkeer blokkeren, uitgaand toestaan
$ sudo ufw default deny incoming
$ sudo ufw default allow outgoing
# Alleen de benodigde poorten openen
$ sudo ufw allow 2222/tcp # SSH (gewijzigde poort)
$ sudo ufw allow 80/tcp # HTTP
$ sudo ufw allow 443/tcp # HTTPS
# Huidige firewall-status controleren
$ sudo ufw status
| Poort | Doel | Open? |
|---|---|---|
| 2222 | SSH (gewijzigde poort) | ✅ Toegestaan |
| 80 | HTTP (web) | ✅ Toegestaan |
| 443 | HTTPS (beveiligde web) | ✅ Toegestaan |
| 22 | SSH (standaard, niet meer in gebruik) | ❌ Geblokkeerd |
| Overige | Alles | ❌ Geblokkeerd |
Van de 60.000+ deuren zijn er nog maar 3 open en de rest heb ik dichtgemetseld. De deur waarop een inbreker wil kloppen, bestaat simpelweg niet meer.
Stap 3: Versleutel de communicatie — HTTPS
Als een server een webdienst aanbiedt, moet ook het verkeer tussen gebruiker en server beschermd worden. Dat is ‘HTTPS’.
HTTP verstuurt gegevens als een ‘briefkaart’ die zomaar verstuurd wordt. Iedereen onderweg kan de inhoud lezen. HTTPS stopt de gegevens in een ‘verzegelde envelop’ en verstuurt die. Zelfs als iemand de envelop onderschept, kan die de inhoud niet lezen.
Wat als een gebruikersnaam/wachtwoord dat een gebruiker invult op een loginformulier via HTTP wordt verstuurd? Iemand die dezelfde café-wifi deelt, kan die gegevens letterlijk meelezen.
In de praktijk is de eenvoudigste manier om HTTPS toe te passen, het aanvragen van een gratis SSL-certificaat via ‘Let’s Encrypt’.
# Certbot installeren (automatiseringstool voor Let's Encrypt)
$ sudo apt install certbot python3-certbot-nginx
# Certificaat aanvragen en automatisch toepassen op Nginx
$ sudo certbot --nginx -d mydomain.com
# Automatische vernieuwing testen (certificaten moeten elke 90 dagen worden vernieuwd)
$ sudo certbot renew --dry-run
Met slechts een paar commandoregels verandert het adres van mijn dienst van http:// in https://, en verschijnt er een slotje in de adresbalk van de browser. Zo geef je gebruikers het vertrouwen: “Deze site is veilig.”
Stap 4: Geautomatiseerd verdedigingssysteem — Fail2Ban
Zelfs als je de SSH-poort hebt gewijzigd en sleutelauthenticatie hebt ingesteld, bestaan er nog steeds hardnekkige bots. Er zijn er altijd die de gewijzigde poort weten te vinden en toch proberen verbinding te maken.
Op zo’n moment is ‘Fail2Ban’ handig. Het is een tool die IP-adressen die een bepaald aantal keer verkeerd inloggen, automatisch blokkeert.
# Fail2Ban installeren
$ sudo apt install fail2ban
# SSH-bescherming instellen
$ sudo vi /etc/fail2ban/jail.local
[sshd]
enabled = true
port = 2222
maxretry = 5
bantime = 3600
findtime = 600
| Instelling | Betekenis |
|---|---|
| maxretry = 5 | Na 5 foute pogingen |
| bantime = 3600 | wordt dat IP 1 uur geblokkeerd |
| findtime = 600 | van toepassing bij 5 mislukkingen binnen 10 minuten |
# Fail2Ban starten
$ sudo systemctl enable fail2ban
$ sudo systemctl start fail2ban
# Momenteel geblokkeerde IP's bekijken
$ sudo fail2ban-client status sshd
Fail2Ban is als een ‘bewakingscamera + automatisch slot’ voor de voordeur. Voert een verdacht persoon het wachtwoord meerdere keren fout in, dan wordt hij of zij automatisch de toegang ontzegd.
Praktisch advies: de beveiligingschecklist
Alles wat tot nu toe is ingesteld, vat ik samen in een checklist. Loop je deze lijst door telkens als je een nieuwe server opzet, dan heb je een basisverdediging op orde.
| # | Onderdeel | Commando/instelling |
|---|---|---|
| 1 | SSH-poort wijzigen | Port 2222 in sshd_config |
| 2 | root-login blokkeren | PermitRootLogin no |
| 3 | Overstappen op SSH-sleutelauthenticatie | PasswordAuthentication no |
| 4 | Firewall activeren | ufw enable, alleen noodzakelijke poorten toestaan |
| 5 | HTTPS toepassen | Let’s Encrypt + Certbot |
| 6 | Fail2Ban installeren | automatisch IP-blokkade bij mislukte logins |
| 7 | Regelmatige updates | sudo apt update && sudo apt upgrade |
Punt 7 is verrassend belangrijk. Er worden elke dag weer beveiligingslekken ontdekt. Hoe sterk je firewall ook is, als het OS of de software zelf een gat heeft, baat dat allemaal niets. Regelmatige updates zijn de meest basale, maar tegelijk ook de meest effectieve beveiligingsmaatregel.
Tot slot: beveiliging is geen uitzondering, maar een gewoonte
In het begin voelde het woord ‘beveiliging’ groots. Hackafweer, intrusiedetectie, encryptie… ik zag het als iets uit de films.
Maar toen ik het daadwerkelijk deed, bleek het geen hoogstaande techniek nodig te hebben. SSH-poort wijzigen, firewall aanzetten, sleutelauthenticatie instellen, Fail2Ban installeren. Een paar regels commando’s, en klaar. Het belangrijkste bleek niet ‘kennis’ te zijn, maar ‘uitvoering’.
Beveiligingsincidenten zijn geen gevolg van geavanceerde hacktechnieken, maar gebeuren op servers waarop de basismaatregelen niet zijn genomen.
Sinds die dag voer ik voor elke nieuwe serveropstelling deze beveiligingschecklist altijd eerst uit voordat ik ook maar één regel code upload. Het slot controleren voordat je de deur opent. Dat is de meest basale houding om een server te beschermen.
Tot nu toe hebben we de basisconditie (CLI, rechten, beveiliging) opgebouwd om te overleven in de wildernis van Linux. Maar er blijft een fundamenteel probleem: de omgeving op mijn laptop (Windows) verschilt van de Linux-server. De Java-versie is anders, de libraries zijn anders.
Er bestaat een technologie die voorgoed een einde maakt aan de smoes “bij mij op de computer werkt het toch?”. Volgende keer duiken we in ‘virtualisatie en containers’ — een manier om omgevingsverschillen volledig te elimineren.