Een nieuwe Cloud VPS bestellen is tegenwoordig een kwestie van een paar klikken. De server staat binnen enkele minuten klaar, maar dat is precies het moment waarop de meeste fouten worden gemaakt. Veel beheerders loggen in met het standaard root-wachtwoord, draaien een snelle apt update en gaan vervolgens hun applicatie installeren. De firewall blijft uit, SSH staat open op poort 22 met wachtwoorden en monitoring komt “volgende week wel een keer”. In deze gids lopen we langs een werkbaar 24-uurs draaiboek waarmee je je Cloud VPS structureel veilig oplevert, herhaalbaar inricht en klaarmaakt voor productie.
Waarom de eerste 24 uur op een Cloud VPS bepalend zijn
Op het moment dat je Cloud VPS een publiek IP-adres krijgt, beginnen geautomatiseerde scanners hem binnen enkele minuten te bezoeken. Dat zijn niet altijd gerichte aanvallers, maar wel bots die proberen in te loggen via SSH, kwetsbare CMS-paden te raken en open poorten in kaart te brengen. Wie de eerste uren laat schieten, ziet in de logs van dag twee al duizenden brute-force pogingen langskomen. De vuistregel is simpel: voordat er één applicatie of website naar deze machine wordt verhuisd, moet de basis staan. Dat scheelt later niet alleen incidenten, maar ook tijd, omdat je geen workarounds hoeft te bedenken voor configuraties die anders al in productie staan.
Stap 1: SSH-toegang dichttimmeren
De eerste serieuze actie op een Cloud VPS is het uitschakelen van wachtwoord-gebaseerde SSH-login. Genereer op je werkstation een ed25519-sleutelpaar, kopieer de publieke sleutel naar de server met ssh-copy-id en pas /etc/ssh/sshd_config aan: zet PasswordAuthentication no, PermitRootLogin prohibit-password en bij voorkeur AllowUsers beperkt tot je beheeraccount. Een hardware-token voegt daar nog een extra laag aan toe, en hoe je dat correct instelt staat in onze gids over FIDO2-beveiligingssleutels voor SSH en hostingtoegang. Verplaats de SSH-poort eventueel naar een niet-standaard poort, niet als beveiliging op zich, maar om je logs leesbaar te houden.
Stap 2: Firewall en fail2ban activeren
Op de meeste Cloud VPS-images staat de firewall standaard uit. Activeer UFW of nftables, sluit alles dicht en open expliciet alleen wat je nodig hebt: SSH op de gekozen poort, HTTP en HTTPS als de server een website draait, en eventueel een monitoringpoort beperkt tot je eigen IP-bereik. Installeer daarna fail2ban en zorg dat de jails voor SSH en je webserver actief zijn. Het idee is niet om alle aanvallen tegen te houden, maar om de ruis aan brute-force pogingen te dempen voordat ze je logs onleesbaar maken. Wil je later proactief jagen op afwijkingen op je server, lees dan ook ons artikel over threat hunting op een Linux VPS.
Stap 3: Updates en patch management vanaf dag één
Een Cloud VPS-image die je vandaag krijgt is meestal niet meer dan een paar weken oud, maar in die paar weken zijn er vaak al kernel- en libraryupdates uitgekomen. Voer direct een volledige apt update && apt full-upgrade uit en herstart als de kernel of libssl is bijgewerkt. Configureer vervolgens unattended-upgrades voor security-updates zodat patches automatisch worden geïnstalleerd, ook als je een paar weken niet inlogt. Een doordacht patchbeleid blijft daarbij belangrijk en de aanpak die we beschrijven in onze gids over patch management op je Linux VPS sluit hier naadloos op aan.
Stap 4: Tijdzone, hostname en logging op orde
Veel beheerders slaan deze stap over, terwijl het de basis is voor leesbare logs en correcte monitoring. Stel de hostname in op iets sprekends, koppel de juiste FQDN, zet de tijdzone op Europe/Amsterdam en zorg dat NTP loopt via systemd-timesyncd of chrony. Een Cloud VPS waarvan de klok scheef loopt, geeft scheve timestamps in logs en breekt onder andere TLS-verificaties en TOTP-authenticatie. Configureer rsyslog of journald met retentiebeleid, want zonder logrotatie loopt je rootschijf binnen enkele weken vol op een drukke server.
Stap 5: Monitoring vanaf het eerste uur
Een Cloud VPS die niet wordt gemonitord, is een server die je verrast met downtime. Installeer een lichte agent zoals Node Exporter en koppel deze aan je centrale Prometheus-instance, of stel zelf een complete stack op zoals beschreven in onze gids over server monitoring met Prometheus en Grafana op je VPS. Zorg in elk geval dat CPU, geheugen, schijfvullingsgraad, load en netwerkverkeer worden bijgehouden. Voor zakelijke omgevingen vul je dat aan met blackbox checks die regelmatig de health-endpoints van je applicaties pollen, zodat je een uitval merkt voordat een gebruiker dat doet.
Stap 6: Backups en herstelbaarheid testen
Een Cloud VPS lijkt onverwoestbaar, totdat een misgelopen rm, een corrupte database of een ransomware-incident ervoor zorgt dat je vanaf nul moet herbouwen. Activeer direct snapshots als je provider dit aanbiedt, zet daarnaast een offsite backup op met restic, BorgBackup of een vergelijkbare tool en versleutel die met een sleutel die niet op de server zelf bewaard wordt. Plan een eerste hersteltest in voor week twee. Hoe je een serieuze test inricht zonder met je productie te schuiven, beschrijven we in disaster recovery test voor webhosting uitvoeren.
Stap 7: Automatiseer de inrichting met Ansible
Alles tot nu toe is handwerk en handwerk schaalt slecht. Op het moment dat je een tweede Cloud VPS bestelt, wil je dezelfde hardening, dezelfde firewallregels en dezelfde monitoring toepassen zonder weer twee uur te klikken. Leg je stappen vast in een Ansible-playbook met rollen voor SSH-hardening, UFW, fail2ban, unattended-upgrades, gebruikersbeheer en monitoring. Versie deze playbooks in Git, voeg ze toe aan je CI-pijplijn en draai ze in dry-run mode tegen bestaande servers om configuratiedrift te detecteren. Ga je containers draaien op deze machine, combineer de basis-hardening dan met de aanpak uit onze gids over Docker omgeving beveiligen op VPS met container hardening en image scanning.
Stap 8: Documentatie en runbooks vastleggen
Sluit de eerste 24 uur af met documentatie. Leg vast welke gebruikers er zijn aangemaakt, welke poorten openstaan, waar de backups heen schrijven en wie er gebeld wordt bij een incident. Een Cloud VPS zonder runbook is een Cloud VPS waarvan alleen de oprichter weet hoe hij in elkaar zit, en dat wordt pijnlijk zichtbaar zodra die persoon op vakantie is. Zet de informatie in een wiki, koppel hem aan je monitoringtool en houd de inhoud actueel als je later wijzigingen doorvoert.
Conclusie: een Cloud VPS verdient een professionele oplevering
Een Cloud VPS is geen kant-en-klaar product, het is een blanco Linux-server die je zelf moet opleveren als een productiewaardig systeem. Door de eerste 24 uur te besteden aan SSH-hardening, firewall, patches, monitoring, backups en automatisering, voorkom je dat je later allerlei brandjes blust die nooit hadden hoeven ontstaan. De extra investering verdient zich terug op het moment dat je je tweede, derde of tiende server uitrolt: dezelfde Ansible-playbook draait dan in een paar minuten een gestandaardiseerde, veilige basis op. Wil je hulp bij het opzetten van zo’n standaard, neem dan contact op voor een korte audit of een gezamenlijke playbook-sessie.