Begin op dag 1: serverhardening voor beheerders, 3 acties

Begin met sterke authenticatie en e-mailbeveiliging: verplicht MFA op elk beheeraccount en verwijder gedeelde wachtwoorden. Sluit daarna direct de bekende kwetsbaarheden via urgente patches, dicht je firewall met deny-by-default regels en segmentatie, en zorg dat logging en back-ups centraal en onwijzigbaar staan. Deze volgorde volgt de normen van CIS Benchmarks, NIST SP 800 en BSI IT-Grundschutz. Begin met een baseline-scan, bijvoorbeeld via CIS-CAT, voordat je verder gaat.

Kort samengevat:

• Het direct patchen van kritieke kwetsbaarheden en het afsluiten van overbodige poorten maximaliseert de beveiliging zonder uitgebreide audit.
• Gebruik rolgebaseerde toegang en multi-factor authenticatie om accountmisbruik en onnodige rechten snel te beperken.
• Automatisering van patchmanagement en logcentralisatie vermindert de menselijke fout en beschermt tegen laterale bewegingen.
• Segmentatie van het netwerk en deny-by-default firewallregels voorkomen dat een aanval zich gemakkelijk verspreidt.
• Regelmatige, geautomatiseerde controles en gestandaardiseerd beheer houden de hardening blijvend effectief zonder handmatig werk.

Inhoudsopgave

• Samenvattende checklist voor server hardening
• Hoe regel je gebruikersaccounts en toegangsbeheer?
• Hoe organiseer je patchmanagement zonder productie te breken?
• Netwerkconfiguratie en firewallregels die aanvallers tegenhouden
• Welke services en rollen moet je uitschakelen?
• Wat zijn de belangrijkste OS-specifieke aanbevelingen?
• Hoe zet je logging, monitoring en auditing goed op?
• Back-up, herstel en veilige uitfasering
• Hoe verifieer en automatiseer je hardening structureel?
• NLXS in de praktijk: van scan naar structureel beheer
• Waar begin je als je tijd en mensen beperkt zijn?
• Hoe NLXS jouw servers hardened en houdt
• Belangrijke standaarden voor server hardening
• Bronnen

Samenvattende checklist voor server hardening

Een goede server hardening checklist werkt als triage: je behandelt eerst wat het meeste risico wegneemt, niet wat het snelst is afgevinkt. Onderstaande indeling geeft per categorie het prioriteitsniveau en waar automatisering realistisch is.

1. Accountbeheer (kritiek): MFA voor alle beheeraccounts, verwijder standaardaccounts, pas least privilege toe. Automatiseerbaar via groepsbeleid (GPO) of Ansible-rollen.
2. Patchmanagement (kritiek): sluit bekende CVE’s binnen dagen, niet weken. WSUS, SCCM of unattended-upgrades dekken het meeste routinewerk.
3. Netwerksegmentatie en firewall (kritiek): deny-by-default, aparte VLAN’s voor beheer en productie. Scripts of Ansible-playbooks houden regels consistent tussen servers.
4. Servicereductie (hoog): schakel ongebruikte rollen en poorten uit. Eenmalig grondig werk, daarna periodieke controle.
5. Logging en monitoring (hoog): centrale logaggregatie met alerts op afwijkend gedrag. Managed SIEM-oplossingen schelen veel handmatig werk.
6. Back-up en herstel (hoog): versleutelde, immutable back-ups met periodieke restore-tests.
7. Verificatie en compliance (medium): herhaal scans tegen CIS-baselines, documenteer afwijkingen.

Binnen de eerste dag richt je je realistisch op het activeren van MFA voor beheeraccounts, het patchen van de meest kritieke openstaande kwetsbaarheden, en het sluiten van overbodige inkomende poorten op de firewall. Dat zijn de drie ingrepen die de meeste aanvalspaden meteen blokkeren, zonder dat je eerst een volledige audit hoeft af te ronden. De rest van deze checklist werk je systematisch af, categorie voor categorie.

Hoe regel je gebruikersaccounts en toegangsbeheer?

Accountmisbruik is nog steeds de meest voorkomende ingang voor aanvallers, en toch is dit precies het onderdeel waar organisaties het snelst versloffen. Begin met een simpel uitgangspunt: niemand krijgt meer rechten dan strikt nodig voor zijn taak.

• Werk met rolgebaseerde toegang (RBAC) in plaats van individuele rechten per gebruiker.
• Verplicht multi-factor authenticatie voor elk account met beheerrechten, zonder uitzondering.
• Schakel standaard ingebouwde beheeraccounts uit of hernoem ze, en verwijder testaccounts na oplevering.
• Beheer service-accounts apart: gebruik managed service accounts waar het platform dat ondersteunt, zodat wachtwoorden automatisch roteren.
• Geef tijdelijke verhoogde rechten via Just Enough Administration (JEA) in plaats van permanente beheerrol.
• Controleer maandelijks wie welke rechten heeft en verwijder wat niet meer nodig is.

Just Enough Administration verdient extra aandacht, want veel beheerders kennen het principe wel maar passen het zelden toe. In plaats van een collega volledig beheerder te maken voor één herstelklus, geef je alleen de specifieke rechten die die taak vereist, tijdelijk en gelogd.

Pro-tip: Koppel elke JEA-sessie aan een ticketnummer. Zo kun je achteraf altijd herleiden wie welke verhoogde actie uitvoerde en waarom, zonder dat je hele auditlog een chaos wordt.

Hoe organiseer je patchmanagement zonder productie te breken?

Patchen is een balans tussen snelheid en stabiliteit. Te snel patchen zonder testen breekt productieomgevingen, te traag patchen laat bekende kwetsbaarheden open staan. NIST SP 800-123 beschrijft dit als een doorlopend onderdeel van de levenscyclus van een server, niet als eenmalige actie.

De praktische aanpak werkt in drie stappen:

• Testomgeving: installeer patches eerst geïsoleerd en controleer kritieke applicaties.
• Staging: rol uit naar een beperkte groep productieservers en monitor 24 tot 48 uur.
• Volledige productie: pas toe op de rest, bij voorkeur buiten piekuren.

Voor kritieke kwetsbaarheden met actief misbruik in het wild volg je een verkort noodproces: direct testen op één representatieve machine, dan meteen breed uitrollen, met monitoring achteraf in plaats van vooraf. Prioriteer op basis van exposure (staat de dienst open naar internet) en exploitability (bestaat er al een werkend exploit).

Voor automatisering zijn WSUS of SCCM standaard voor Windows-omgevingen, terwijl pakketmanagers zoals apt of yum met unattended-upgrades hetzelfde werk doen op Linux. Orchestratietools als Ansible kunnen patchrondes over honderden servers tegelijk plannen en rapporteren, wat handmatig vrijwel onmogelijk is bij grotere infrastructuren.

Netwerkconfiguratie en firewallregels die aanvallers tegenhouden

Een netwerk zonder segmentatie is als een kantoorgebouw zonder binnendeuren: eenmaal binnen, overal toegang. Dat is precies wat je met firewallbeleid en segmentatie voorkomt.

• Stel firewalls in op deny-by-default en open alleen expliciet de poorten die een dienst nodig heeft.
• Splits het netwerk in aparte zones voor beheer, applicaties, DMZ en internetverkeer.
• Sta beheerverkeer nooit rechtstreeks vanaf internet toe; werk met een jump host of bastion server.
• Beperk RDP en SSH tot die jump host, met MFA en volledige sessielogging.
• Controleer firewallregels periodiek op verouderde of te brede uitzonderingen.

Segmentatie voorkomt vooral laterale beweging: als een aanvaller één webserver in de DMZ compromitteert, mag dat nooit automatisch toegang geven tot je databaseserver in een ander segment.

Pro-tip: Log elke sessie via de jump host apart van de reguliere serverlogs. Bij een incident wil je in seconden kunnen zien wie via welke route binnenkwam, niet dat door duizenden regels heen zoeken.

Voor teams die servers op afstand beheren is een aparte procedure voor veilig remote beheer van servers een logische volgende stap na deze basis.

Welke services en rollen moet je uitschakelen?

Elke draaiende service is een potentiële ingang. Servers die met standaardinstallaties in productie gaan, hebben vaak tien tot vijftien services actief die niemand ooit gebruikt.

1. Inventariseer welke rollen, features en services daadwerkelijk actief zijn op elke server.
2. Beoordeel per service of hij functioneel noodzakelijk is, en documenteer de reden als je iets laat staan.
3. Deactiveer of verwijder wat niet nodig is, in plaats van het alleen uit te schakelen. Verwijderde software kan niet per ongeluk weer opstarten na een update.
4. Hard je firmware en BIOS met een wachtwoord en schakel opstarten vanaf USB uit, tenzij dat expliciet nodig is.
5. Beperk fysieke en USB-toegang tot serverruimtes en poorten, ook binnen het eigen kantoor.

Documentatie is hier geen bureaucratische bijzaak. BSI IT-Grundschutz benadrukt dat hardening reproduceerbaar en aantoonbaar gedocumenteerd moet zijn, juist omdat een volgende beheerder anders per ongeluk een uitgeschakelde dienst weer aanzet zonder te weten waarom die uitstond.

Wat zijn de belangrijkste OS-specifieke aanbevelingen?

Windows Server en Linux vragen elk hun eigen aandacht, en juist de details die generieke checklists overslaan maken hier het verschil.

Voor Windows Server:

• Installeer waar mogelijk Server Core in plaats van de volledige desktopervaring, dat verkleint het aanvalsvlak aanzienlijk.
• Configureer groepsbeleid op basis van een erkende baseline, zoals de CIS Benchmark voor Windows Server.
• Schakel PowerShell-logging in (module logging en script block logging), want dit is vaak het eerste dat forensisch onderzoek nodig heeft.
• Minimaliseer telemetrie en verwijder overbodige Windows-features via Server Manager.

Voor Linux:

• Sta alleen SSH-authenticatie via sleutels toe, nooit via wachtwoord.
• Schakel directe root-login via SSH volledig uit.
• Beheer updates via de pakketmanager van de distributie en houd kernel hardening actief, waaronder ASLR en DEP.
• Activeer AppArmor of SELinux, afhankelijk van de distributie, en draai ze in enforcing-modus, niet alleen ter observatie.

De checklists van UT Austin vertalen deze CIS-aanbevelingen naar concrete, afvinkbare stappen per platform, wat handig is als startpunt voor je eigen interne standaard.

Hoe zet je logging, monitoring en auditing goed op?

Een server zonder betrouwbare logs is een server waarvan je bij een incident nooit zult weten wat er precies gebeurde. Centraliseer logs daarom altijd buiten de server zelf, zodat een aanvaller die inbreekt zijn sporen niet lokaal kan wissen.

• Verzamel logs centraal via een SIEM-oplossing, ELK-stack of een beheerde monitoringdienst.
• Beveilig de logopslag zelf met beperkte toegang en een vastgestelde retentietermijn.
• Zet file integrity monitoring op voor kritieke systeembestanden en configuraties.
• Log alle bevoorrechte commando’s, waaronder PowerShell-sessies en sudo-gebruik.
• Definieer vooraf welke afwijkingen een alert triggeren en welk responsplaybook daarbij hoort.

Meerdere praktijkgidsen van security-leveranciers wijzen op dezelfde kernonderdelen: accounts, netwerk, patching, services, logging en back-ups vormen samen de terugkerende basis van vrijwel elke hardening checklist die in de praktijk wordt gebruikt.

Een alert zonder playbook is bijna waardeloos. Als je team niet vooraf weet wat “verdachte PowerShell-activiteit om 3 uur ’s nachts” precies betekent voor de te nemen stappen, verlies je kostbare tijd tijdens het incident zelf, precies het moment waarop tijd het meest telt.

Back-up, herstel en veilige uitfasering

Een back-up die je nooit hebt teruggezet, is een aanname, geen garantie. Datzelfde geldt voor servers die je uit dienst neemt: zonder een vast proces blijven er vaak sporen van bedrijfsdata achter op oude schijven.

1. Versleutel back-ups zowel onderweg als in opslag, en gebruik waar mogelijk immutable opslag zodat ransomware ze niet kan overschrijven.
2. Test restores regelmatig, niet alleen bij de installatie van het back-upsysteem. Definieer vooraf een concrete RTO (hersteltijd) en RPO (maximaal dataverlies).
3. Documenteer een vast uitfaseringsproces: secure wipe van alle schijven, verwijdering uit monitoring en DNS, en intrekking van certificaten en accounts die aan die server gekoppeld waren.

Deze drie stappen kosten weinig tijd in verhouding tot wat een mislukte restore of een niet-gewiste oude server aan schade kan veroorzaken.

Hoe verifieer en automatiseer je hardening structureel?

Een checklist die je eenmalig afwerkt, verliest binnen maanden zijn waarde door configuratiedrift. Verificatie en automatisering houden de baseline overeind zonder dat iemand elke server handmatig hoeft te controleren.

• Draai periodieke scans tegen CIS Benchmarks met tools zoals CIS-CAT of het open-source alternatief OpenSCAP.
• Leg configuraties vast in Ansible-playbooks of vergelijkbare configuratiebeheertools, zodat afwijkingen automatisch worden hersteld.
• Werk met policy-as-code, zodat nieuwe servers vanaf provisioning al aan de baseline voldoen.
• Pas CIS-aanbevelingen aan op je eigen risicoprofiel: niet elke regel is direct toepasbaar zonder impactanalyse op bestaande applicaties.
• Rapporteer auditresultaten periodiek aan het management in een vast, herhaalbaar format voor compliance-doeleinden.

Automatisering verandert hardening van een jaarlijks project in een continu proces, wat precies is wat een omgeving met tientallen of honderden servers nodig heeft.

NLXS in de praktijk: van scan naar structureel beheer

NLXS voert deze checklist niet als theorie, maar als vast onderdeel van de ICT-scan die klanten zoals TU Eindhoven en JCI Breda hebben laten uitvoeren op hun infrastructuur. Het proces volgt vier stappen: eerst een technische scan van accounts, netwerk en services, dan een prioriteitenplan op basis van risico, gevolgd door uitvoering van de kritieke hardening-stappen, en tot slot doorlopend beheer met patching en monitoring.

[hier komen praktijkcases en klantreacties]

Voor mkb-organisaties die zelf geen dedicated securityteam hebben, is dit precies het gat dat managed hosting en ICT-beveiliging op maat opvullen: dezelfde normen als CIS en NIST, toegepast zonder dat je zelf elke scan hoeft te interpreteren.

Waar begin je als je tijd en mensen beperkt zijn?

Met een klein team is de verleiding groot om overal een beetje aan te werken. Dat is de verkeerde volgorde. Begin met automatisering van patching en centrale logging, want dat zijn de twee taken die het meeste tijd besparen zodra ze eenmaal draaien, en tegelijk het grootste deel van je restrisico wegnemen.

Overweeg uitbesteding zodra je merkt dat scans blijven liggen door drukte, of wanneer niemand in het team de laatste CVE-meldingen structureel volgt. Kies een partner op basis van reactietijd, transparantie over wat er gecontroleerd wordt, en of ze werken volgens erkende baselines zoals CIS in plaats van een eigen ongedocumenteerde methode.

— Ken

Hoe NLXS jouw servers hardened en houdt

NLXS is het verschil tussen een checklist die op papier blijft staan en een checklist die daadwerkelijk wordt bijgehouden, zonder dat jouw team er wekelijks tijd in hoeft te steken. Waar je zelf tijd kwijt bent aan het bijhouden van CVE’s, het testen van patches en het controleren van firewallregels, neemt NLXS dat werk over met vaste maandtarieven en zonder verrassingen achteraf.

Concreet betekent dat: een ICT-scan die je huidige serverconfiguratie toetst aan erkende baselines, managed hosting waarbij patching en monitoring structureel zijn ingericht, en ondersteuning die problemen binnen één dag oppakt in plaats van na dagen wachten. Klanten zoals TU Eindhoven en JCI Breda laten hun infrastructuur al op deze manier beheren. Wil je weten waar jouw servers nu staan ten opzichte van deze checklist? Plan een gratis ICT-scan en ontdek binnen enkele dagen concreet welke stappen prioriteit hebben.

Belangrijke standaarden voor server hardening

Voor wie dieper wil graven: CIS Benchmarks bieden platformspecifieke configuratieregels, de NIST SP 800-serie onderbouwt patch- en identitybeleid, BSI IT-Grundschutz beschrijft operationele eisen, en de checklists van UT Austin vertalen dit alles naar afvinkbare stappen per besturingssysteem.

Bronnen

• CIS Benchmarks®
• NIST SP 800-series
• Operating System Hardening Checklists (UT Austin)

Aanbevelingen

• Bedrijfsmail veilig configureren zonder gedoe
• Remote beheer servers: veilige checklist voor IT-teams
• Tips voor goede beveiliging van de ICT in jouw bedrijf
• Beste oplossingen voor domeinbeveiliging