Het eerste uur op een nieuwe Linux dedicated server: een hardeningschecklist

Eerst het antwoord: de checklist

Acht stappen, ruwweg in de volgorde waarin je ze zou moeten uitvoeren. Elke stap kost een paar minuten; de hele lijst past ruim in je eerste uur op de machine:

1. Maak een non-root beheerder aan met sudo-rechten; stop met inloggen als root.
2. Schakel SSH over op alleen keys en pas hardening toe op sshd_config.
3. Pas een default-deny firewallbaseline toe: sta SSH en je services toe, drop de rest.
4. Schakel automatische beveiligingsupdates in.
5. Installeer fail2ban om adressen te blokkeren die de authenticatie niet doorstaan.
6. Controleer of tijdsynchronisatie actief is.
7. Controleer wat er luistert en verwijder of bind intern alles wat niet publiek hoeft te zijn.
8. Maak logs persistent en loop ze één keer door.

Alles op deze lijst verdedigt tegen het daadwerkelijke day-one dreigingsmodel van een server die met het internet is verbonden: geautomatiseerd, ongericht scannen en credential stuffing. Onderzoek van Unit 42 naar honeypots toonde aan dat blootgestelde services binnen enkele minuten na live gaan werden aangevallen en dat 80% van de honeypots binnen 24 uur was gecompromitteerd: de scanners kan het niet schelen wie je bent, alleen dat je antwoordde. Hierna volgen de details, per distro.

Stap 1: een non-root gebruiker met sudo

Voortdurend als root werken betekent dat elke typefout met volledige rechten wordt uitgevoerd en dat elke service die je verkeerd configureert standaard de maximale blast radius heeft. Twee minuten:

adduser deploy
usermod -aG sudo deploy      # Debian/Ubuntu
usermod -aG wheel deploy     # RHEL/AlmaLinux/Rocky

Kopieer je SSH-key naar de nieuwe gebruiker (ssh-copy-id [email protected], of plak hem in ~/.ssh/authorized_keys), bevestig dat je kunt inloggen en sudo -i kunt uitvoeren, en ga dan pas verder met het afsluiten van SSH. Volgorde is belangrijk: schakel nooit een deur uit voordat de nieuwe aantoonbaar opengaat.

Stap 2: SSH (alleen keys, root vergrendeld)

Wachtwoordauthenticatie is waar de scannende botnets op gokken. Zet het uit:

# /etc/ssh/sshd_config.d/10-hardening.conf
PasswordAuthentication no
KbdInteractiveAuthentication no
PermitRootLogin no

Valideer en herlaad daarna. sshd -t controleert de syntax van de configuratie, zodat een typefout SSH niet kan platleggen:

sshd -t && systemctl reload ssh    # 'sshd' on the RHEL family

Houd je huidige sessie open en bevestig dat een verse verbinding werkt voordat je uitlogt. Die gewoonte (de nieuwe deur testen terwijl de oude nog openstaat) is het verschil tussen hardening en jezelf buitensluiten. (Gaat het toch een keer mis, dan redt out-of-band consoletoegang je; daarover meer aan het eind.)

Wetenswaardigheden:

• Moderne distro's leveren redelijke standaard SSH-crypto; je hoeft cipherlijsten niet meer handmatig samen te stellen.
• PermitRootLogin prohibit-password (alleen key-based root) is een verdedigbaar alternatief voor no als je tooling daadwerkelijk root-logins nodig heeft; geef de voorkeur aan no plus sudo als je de keuze hebt.
• Op recente Ubuntu-releases is sshd socket-activated (ssh.socket), wat meestal niet uitmaakt, totdat je de poort wijzigt: dan maakt het opeens heel veel uit. Dat brengt ons bij:
• De SSH-poort wijzigen is ruisreductie, geen beveiliging. Het vermindert logspam van de domste scanners; het vertraagt geen aanvaller met een portscanner. Doe het voor rustigere logs als je wilt, nooit in plaats van keys.

Stap 3: de firewallbaseline

Debian en Ubuntu worden geleverd zonder enige firewallregel. Elke listener is wereldwijd bereikbaar zodra hij start. De baseline kost vijf minuten: default-deny voor inkomend verkeer, established verkeer toestaan, SSH en je daadwerkelijke services op de allowlist zetten, en ICMP goed instellen (blokkeer het niet volledig; dat breekt path-MTU discovery en IPv6).

We hebben de complete, geannoteerde ruleset uitgewerkt in een eigen gids, verstandige standaard firewallregels voor een Linux-server, met hetzelfde beleid in native nftables, ufw en firewalld, plus de mechanica om jezelf niet buiten te sluiten. Als je maar één link uit deze checklist volgt, laat het die zijn. (Twijfel je tussen regelsyntaxen? iptables vs nftables.)

De samenvatting in één regel per familie: ufw op Ubuntu, firewall-cmd op RHEL/Alma/Rocky, native nftables op Debian. Schakel het in, sta 22 plus je service-poorten toe, weiger de rest, voor beide adresfamilies.

Stap 4: automatische beveiligingsupdates

De meerderheid van compromittering in de praktijk maakt misbruik van kwetsbaarheden waarvoor al patches beschikbaar waren. Een server die zichzelf patcht sluit dat venster zonder dat jij daarvoor bij het ontbijt advisories hoeft te lezen:

# Debian/Ubuntu — installed and on by default on Ubuntu Server; verify:
apt install unattended-upgrades
dpkg-reconfigure -plow unattended-upgrades

# RHEL/AlmaLinux/Rocky — security-only automatic updates:
dnf install dnf-automatic
# set upgrade_type = security in /etc/dnf/automatic.conf, then:
systemctl enable --now dnf-automatic.timer

Beperk het tot beveiligingsupdates (beide standaardinstellingen hierboven doen dat al), zodat onbeheerde runs je niet verrassen met grote versiesprongen. Kernelupdates hebben nog steeds een reboot nodig om van kracht te worden. Kijk af en toe even mee of plan reboots in; unattended-upgrades kan gecontroleerde automatische reboots uitvoeren als je workload dat toelaat.

Stap 5: fail2ban (blokkeren op bewijs)

De rate limit van je firewall beperkt verbindingspogingen blindelings; fail2ban leest het authenticatielog en blokkeert adressen die daadwerkelijk falen, bewijsgebaseerd blokkeren dat zowel de firewall als key-only authenticatie aanvult:

apt install fail2ban    # dnf install fail2ban (needs the EPEL repository on RHEL-family)

De standaardinstellingen van het pakket schakelen de SSH-jail in, en dat is degene die ertoe doet. Eén aanpassing die de moeite waard is in /etc/fail2ban/jail.local: voeg je eigen beheer-IP's toe aan ignoreip, zodat een verkeerd getypte key aan jouw kant je niet kan blokkeren.

Is fail2ban noodzakelijk zodra wachtwoorden uitstaan? Strikt genomen niet: key-only authenticatie bezwijkt niet voor brute force. Het verdient zijn plek toch: het vermindert lognoise flink, dekt de andere services die je later toevoegt (mail, panels, databases met authenticatielogs), en verzacht de CPU-kosten van agressieve scanners.

Stap 6: tijdsynchronisatie

Onopvallend en essentieel: TLS-certificaatvalidatie, databasereplicatie, logcorrelatie tijdens een incident en geplande taken hangen allemaal stilletjes af van de juiste tijd. Elke moderne distro levert een NTP-client; controleer alleen of die daadwerkelijk gesynchroniseerd is:

timedatectl    # look for "System clock synchronized: yes" and "NTP service: active"

Debian/Ubuntu gebruiken standaard systemd-timesyncd; de RHEL-familie gebruikt chrony. Beide zijn prima voor een server; er valt op dag één niets te tunen behalve het bevestigen van de yes.

Stap 7: controleer je listeners

Maak de allowlist van de firewall nu eerlijk door uit te zoeken wat er daadwerkelijk luistert:

ss -tlnp    # TCP listeners; add -u for UDP

Lees de output met drie vragen: Weet ik wat dit is? Moet het bereikbaar zijn vanaf het internet? Staat het bewust op mijn firewall-allowlist? Typische bevindingen op een verse machine zijn onschuldig (sshd, systemd-resolved op 127.0.0.53), maar dit is de gewoonte die de database gebonden aan 0.0.0.0 na de deploy van volgende maand opvangt. Alles wat alleen intern hoeft te zijn, moet gebonden zijn aan 127.0.0.1 of een privénetwerkadres, niet alleen firewalled: twee lagen verslaan er één.

Draai je Docker, weet dan dat gepubliceerde containerpoorten ufw volledig omzeilen: -p 8080:80 is met het internet verbonden, ongeacht je regels. Bind aan localhost (-p 127.0.0.1:8080:80) of gebruik de DOCKER-USER-chain; details in de firewallgids.

Stap 8: persistente logs, één keer doorlopen

Op sommige distro's is het systemd journal alleen in geheugen en verdwijnt het bij een reboot, precies wanneer je het nodig zou hebben. Maak het persistent:

mkdir -p /var/log/journal && systemctl restart systemd-journald

Besteed daarna twee minuten aan het doornemen van journalctl -p warning -b, zodat je weet hoe "normaal" er op deze machine uitziet; incident response begint bij een baseline. Sluit de machine aan op welke monitoring je ook al draait (zelfs een simpele uptime-/schijfalert); het eerste uur hoeft alleen te zorgen dat de logs bewaard blijven en dat iemand een seintje krijgt als de machine zich misdraagt.

Het spiekbriefje, per distrofamilie

Welke familie je sowieso draait is een eigen beslissing; onze gids over Linux-distributies behandelt die.

Waar je in het eerste uur GEEN moeite in hoeft te steken

Een eerlijke hardeninggids zegt ook waar de afnemende meeropbrengsten beginnen:

• Port knocking en single-packet authorisation. Leuk, obscuur en operationeel fragiel; keys + fail2ban hebben dit gevecht al gewonnen.
• SELinux of AppArmor uitschakelen om een app te "fixen". Het tegenovergestelde van hardening. Laat SELinux op enforcing staan / AppArmor ingeschakeld; gaat er iets stuk, fix dan het beleid (of de labels van de app), niet het framework.
• Diepgaande kernel/sysctl-hardeningrondes. Buiten SYN cookies (standaard al aan) en wat je firewallgids instelt, is sysctl-tuning op dag één cargocultgedrag. Doe het later, met een benchmark en een reden.
• Antivirus- en rootkitscanners. Op een verse Linux-server met één doel verbruiken deze vooral RAM en produceren ze false positives. Compliance-regimes daargelaten, sla ze vandaag over.
• CIS-benchmarkruns. Waardevol voor fleets en audits, overkill voor het eerste uur. De checklist hierboven dekt het snijvlak van "hoge impact" en "lage moeite"; formele benchmarks kunnen later komen, met meer volwassenheid.

Het patroon: hardening in het eerste uur draait om het sluiten van de deuren die bots daadwerkelijk proberen, en dan verdergaan met het werk waarvoor je de server hebt gekocht.

Veelgestelde vragen

Is het de moeite waard om de SSH-poort te wijzigen?

Als reductie van lognoise: enigszins; als beveiliging: nee. Ongerichte botnets rammen vooral op poort 22, dus het verplaatsen van sshd maakt je logs rustiger, maar elke aanvaller die het iets kan schelen draait een portscan en vindt het binnen seconden, en niet-standaard poorten compliceren tooling en firewalls. Verplaats je hem toch, behandel het dan als een gemaksaanpassing bovenop key-only authenticatie en fail2ban, nooit als vervanging ervoor.

Heb ik fail2ban nog nodig als wachtwoordauthenticatie is uitgeschakeld?

Nodig: nee, brute force kan een key die het niet kan raden niet verslaan. Wenselijk: waarschijnlijk wel. Fail2ban houdt authenticatielogs leesbaar door de eindeloze achtergrondruis van scanners te blokkeren, breidt datzelfde bewijsgebaseerde blokkeren uit naar services die je later toevoegt, en verlaagt de resourcekosten van gescand worden. Het is vijf minuten installatiewerk voor een permanent rustigere server; de meeste beheerders vinden dat een goede ruil.

Moet ik root-inloggen volledig uitschakelen?

Stel PermitRootLogin no in en gebruik sudo vanuit een benoemde gebruiker: dat is de juiste standaard, en het geeft je attributie (welke key deed wat) plus een tweede horde voor aanvallers. De uitzondering is automatisering die daadwerkelijk direct root nodig heeft; daar is PermitRootLogin prohibit-password (alleen keys, nooit wachtwoorden) acceptabel. Wat op een server die met het internet is verbonden nooit te verdedigen is, is root met wachtwoordinlog.

Hoe verschilt een dedicated server van een VPS als het op hardening aankomt?

De checklist is identiek; de verschillen zitten aan de randen. Op een dedicated server bezit je de hele stack, dus is er geen provideragent in je OS en geen buren met wie je de kernel deelt; de keerzijde is dat herstel jouw verantwoordelijkheid is, wat twee dingen belangrijker maakt: out-of-band consoletoegang (voor wanneer een firewall- of sshd-wijziging misgaat) en de netwerkrand-bescherming vóór je poort. Controleer of je provider beide biedt voordat je een van beide nodig hebt.

Uitrollen op Serverside

Hardening begint vóór je eerste SSH-login: op onze dedicated servers staan altijd-actieve DDoS-mitigatie en een self-service edge-firewall upstream van je poort (zodat niet-service-verkeer kan worden gedropt voordat het ooit de machine bereikt die je aan het hardenen bent), en inbegrepen KVM-over-IP-consoletoegang betekent dat een mislukte sshd- of firewallwijziging een fix van twee minuten is in plaats van een lockout. Provision Ubuntu, Debian, AlmaLinux/Rocky of RHEL in minder dan een minuut op ASN 55285 en doorloop deze checklist van boven naar beneden.

Ga dieper met de bijbehorende gidsen: verstandige standaard firewallregels, iptables vs nftables, en (voor de dag dat de scanners vrienden meebrengen) DDoS-aanvallen uitgelegd.