Linux Server Beveiligen: De Praktische Checklist voor je Bedrijf

Waarom Linux hardening geen luxe is

Een nieuwe Linux-server die je online zet, wordt binnen enkele minuten voor het eerst benaderd door geautomatiseerde scanners. Die zoeken naar open SSH-poorten, standaardwachtwoorden en verouderde software. Het gaat zelden om een gerichte aanval op jouw bedrijf. Het gaat om een bot die massaal probeert of er ergens een deur openstaat.

Linux hardening betekent dat je het aanvalsoppervlak van een server zo klein mogelijk maakt en de overgebleven toegangswegen goed afschermt. Een standaardinstallatie is gericht op gebruiksgemak, niet op veiligheid. Jij maakt het verschil met een paar gerichte aanpassingen.

Het goede nieuws: het merendeel van de incidenten dat wij zien had voorkomen kunnen worden met basismaatregelen. Een gelekt wachtwoord op SSH, een niet-gepatchte webapplicatie, een database die open op internet stond. Geen exotische zero-days, maar vermijdbare fouten. Is het al misgegaan? Lees dan onze aanpak voor een gehackte Linux-server.

Stap 1: SSH beveiligen met keys en strakke instellingen

SSH is meestal de belangrijkste toegangspoort tot je server en dus het eerste doelwit. SSH beveiligen doe je in drie lagen: sterke authenticatie, beperkte toegang en minder ruimte voor gokpogingen.

SSH-key aanmaken en installeren

Maak op je eigen computer een moderne key aan en kopieer die naar de server:

ssh-keygen -t ed25519 -C "naam@bedrijf.nl"
ssh-copy-id gebruiker@jouw-server

sshd_config aanpassen

Pas in /etc/ssh/sshd_config (of in een bestand onder /etc/ssh/sshd_config.d/) de volgende regels aan:

PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
MaxAuthTries 3
AllowUsers beheerder1 beheerder2

Controleer de configuratie met sudo sshd -t en laad hem daarna in met sudo systemctl reload ssh (op RHEL-varianten heet de service sshd). Belangrijk: houd je huidige sessie open en test eerst in een tweede terminal of inloggen met je key werkt. Zo sluit je jezelf niet buiten.

Je SSH-poort verplaatsen naar bijvoorbeeld 2222 vermindert de logruis, maar is geen beveiliging. Een scanner vindt de nieuwe poort net zo makkelijk. Doe het als je wilt, maar reken er niet op.

Stap 2: UFW firewall op Linux inrichten

Een firewall zorgt dat alleen verkeer binnenkomt dat je bewust toestaat. Op Ubuntu en Debian is UFW (Uncomplicated Firewall) de makkelijkste route. Het uitgangspunt is eenvoudig: alles dicht, tenzij je het nodig hebt.

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow from 203.0.113.10 to any port 22 proto tcp
sudo ufw allow 443/tcp
sudo ufw enable
sudo ufw status verbose

In dit voorbeeld mag alleen het kantoor-IP (203.0.113.10, vervang dit door je eigen adres) via SSH binnenkomen, en is HTTPS voor iedereen open. Voeg je SSH-regel toe vóórdat je ufw enable draait, anders zit je er zelf uit.

Let op met Docker: gepubliceerde containerpoorten (-p 8080:80) omzeilen standaard je UFW-regels, omdat Docker zelf iptables-regels toevoegt. Een poort die je denkt te hebben geblokkeerd, kan dus toch openstaan. Bind containerpoorten aan 127.0.0.1 of beheer de regels via de DOCKER-USER-chain.

Welke poorten moeten dicht?

Controleer wat er daadwerkelijk luistert met sudo ss -tulpn. Gebruik onderstaande tabel als vuistregel:

Databases en caches die open op internet staan, zijn een klassieke oorzaak van datalekken. Laat ze luisteren op 127.0.0.1 of op een privénetwerk, en regel externe toegang via een VPN of SSH-tunnel.

Stap 3: Fail2ban instellen tegen brute force

Zelfs met sleutelauthenticatie blijven bots proberen in te loggen. Dat vult je logs en kost resources. Fail2ban instellen lost dat op: de tool leest je logbestanden en blokkeert IP-adressen die te vaak mislukken.

sudo apt install fail2ban
sudo nano /etc/fail2ban/jail.local

Een nuchtere basisconfiguratie voor SSH:

[DEFAULT]
bantime  = 1h
findtime = 10m
maxretry = 5

[sshd]
enabled = true

Start de service met sudo systemctl enable --now fail2ban en bekijk de status met sudo fail2ban-client status sshd. Zet je eigen kantoor-IP in ignoreip, zodat je jezelf niet per ongeluk blokkeert.

Fail2ban is een aanvulling, geen vervanging. Als je wachtwoordlogin al hebt uitgezet, haalt het vooral ruis weg. Het wordt pas echt waardevol voor andere diensten, zoals je webserver, mailserver of een admin-login.

Stap 4: Automatische updates en patchbeleid

Verouderde software is een van de meest voorkomende redenen waarom servers worden overgenomen. Zodra een kwetsbaarheid bekend is, duurt het vaak niet lang voor er misbruik van wordt gemaakt. Wachten met patchen is dus een risico dat je zelf kiest.

Op Debian en Ubuntu zet je automatische beveiligingsupdates aan met:

sudo apt install unattended-upgrades
sudo dpkg-reconfigure -plow unattended-upgrades

Op RHEL, AlmaLinux en Rocky Linux gebruik je dnf-automatic met de instelling upgrade_type = security.

Hoe vaak moet je een Linux-server updaten?

• Beveiligingsupdates: automatisch en dagelijks.
• Overige updates: minimaal maandelijks, in een vast onderhoudsvenster.
• Kernel-updates: na installatie is een herstart nodig. Plan die in, of gebruik livepatch-oplossingen waar dat past.
• Kritieke kwetsbaarheden: buiten de planning om, zo snel mogelijk.

Test updates bij kritieke systemen eerst op een testomgeving of een snapshot. Automatisch patchen is veilig voor de meeste beveiligingsupdates, maar een geplande herstart midden in kantooruren wil niemand.

Stap 5: Minimale rechten en minder aanvalsoppervlak

Het principe van least privilege betekent dat elk account, proces en elke dienst precies de rechten krijgt die nodig zijn, en niets meer. Gaat er iets mis, dan blijft de schade beperkt.

1. Persoonlijke accounts: geef elke beheerder een eigen account met sudo, en deel nooit een gezamenlijk account. Zo is achteraf zichtbaar wie wat deed.
2. Diensten onder eigen gebruiker: laat webservers, applicaties en cronjobs draaien onder een dedicated gebruiker zonder shell en zonder sudo.
3. Ongebruikte software verwijderen: elke geïnstalleerde dienst is potentieel een kwetsbaarheid. Controleer met systemctl list-unit-files --state=enabled en zet uit wat je niet gebruikt.
4. Bestandsrechten nalopen: zoek bestanden die voor iedereen schrijfbaar zijn met find / -xdev -type f -perm -0002.
5. Mandatory access control: laat AppArmor (Ubuntu/Debian) of SELinux (RHEL-familie) aan staan. Het is verleidelijk om het uit te zetten als iets niet werkt, maar los dan liever het profiel op.

Stap 6: Back-ups die je echt kunt terugzetten

Back-ups zijn je laatste verdedigingslinie bij ransomware, een fout van een beheerder of een defecte schijf. Een back-up die je nooit hebt teruggezet, is een aanname en geen back-up.

• Volg de 3-2-1-regel: drie kopieën, op twee verschillende media, waarvan één op een andere locatie.
• Maak ze onaanpasbaar: zorg dat een aanvaller met toegang tot je server ook je back-ups niet kan verwijderen. Gebruik pull-back-ups of opslag met immutability.
• Versleutel ze: back-ups bevatten dezelfde persoonsgegevens als je productiedata.
• Test het terugzetten: doe dit minimaal ieder kwartaal en leg vast hoe lang het duurt.

Stap 7: Monitoring, logging en auditing

Je kunt een aanval alleen stoppen als je hem opmerkt. Veel inbraken blijven weken onopgemerkt, omdat niemand naar de logs kijkt. Zorg dat je minimaal de volgende zaken in de gaten houdt:

• Mislukte en succesvolle SSH-logins, vooral vanaf onbekende IP-adressen of op ongebruikelijke tijden.
• Nieuwe gebruikers, wijzigingen in sudoers en aanpassingen aan SSH-keys.
• Ongebruikelijk hoog CPU-, netwerk- of schijfgebruik, vaak een teken van cryptominers of datadiefstal.
• Beschikbaarheid van je diensten en het verloop van je TLS-certificaten.

Stuur logs bij voorkeur naar een externe plek, zodat een aanvaller ze niet achteraf kan wissen. Voor diepere controle kun je auditd inzetten. Met sudo lynis audit system draai je bovendien een gratis, open-source audit die je configuratie beoordeelt en concrete verbeterpunten oplevert. Een prima startpunt voor je eigen Linux server security checklist.

Wil je dit niet zelf bewaken? Met SLA as a Service controleren en beheren wij je Linux-omgeving periodiek en reageren we binnen een uur als er iets misgaat.

NIS2 en AVG: wat betekent dit voor je Linux-server?

Voor bedrijven zijn er naast technische ook juridische redenen om je server te beveiligen. De AVG (artikel 32) verplicht je om "passende technische en organisatorische maatregelen" te nemen om persoonsgegevens te beschermen. Wat passend is, hangt af van het risico en de stand van de techniek. Een open database of een jarenlang ongepatchte server is zelden te verdedigen.

De Europese NIS2-richtlijn stelt daarnaast eisen aan cyberbeveiliging van organisaties in sectoren die als essentieel of belangrijk gelden, en aan de bedrijven in hun toeleveringsketen. In Nederland wordt dit vormgegeven in de Cyberbeveiligingswet. Of jouw organisatie eronder valt, hangt af van sector en omvang. Controleer dit bij de officiële bronnen, of laat je adviseren.

In de praktijk komen de verwachtingen neer op: risicobeheer, patchbeleid, toegangsbeheer, back-ups, incidentafhandeling en het kunnen aantonen dat je dit doet. Deze checklist raakt de technische kant daarvan. Documenteer ook wat je doet en wanneer: wat je niet kunt aantonen, telt in een audit vaak niet mee.

De volledige Linux server security checklist

Gebruik dit overzicht als vaste controle bij elke nieuwe server en als kwartaalcheck voor bestaande machines:

1. SSH-keys in gebruik, wachtwoordlogin en root-login uitgezet.
2. Firewall actief met default deny en alleen noodzakelijke poorten open.
3. Databases en caches niet bereikbaar vanaf internet.
4. Fail2ban draait voor SSH en andere blootgestelde diensten.
5. Automatische beveiligingsupdates staan aan, met een maandelijks onderhoudsmoment.
6. Persoonlijke accounts met sudo, geen gedeelde logins.
7. Ongebruikte diensten en pakketten verwijderd.
8. AppArmor of SELinux actief.
9. Versleutelde, offsite back-ups waarvan het terugzetten is getest.
10. Logging en monitoring ingericht, met alerts bij afwijkend gedrag.
11. Documentatie van configuratie, uitzonderingen en incidentprocedure.

Wanneer is een checklist niet genoeg?

Een checklist dekt de basis. Maar je weet pas zeker of je server standhoudt als iemand hem echt probeert binnen te komen. Een pentest van je Linux-server laat zien welke diensten kwetsbaar zijn, inclusief je webapplicaties. Dat is waardevol na grote wijzigingen, vóór een audit, of als je klanten of toezichthouders om bewijs vragen.

Twijfel je of je de maatregelen zelf kunt of wilt beheren? Bekijk dan wanneer betaalde Linux-support loont. Ook netwerk- en SSH-problemen komen vaak tijdens het hardenen om de hoek kijken. Daarvoor hebben we een aparte gids over DNS-, SSH- en verbindingsfouten.