Een VPS beveilig je in lagen: verkeer filteren voordat het je server bereikt, beheer afschermen, alleen de nodige poorten openzetten, automatisch bijwerken, aanvallen herkennen en blokkeren, de schade beperken als het toch misgaat, en back-ups bewaren die een hack overleven. Hieronder staan de 12 maatregelen die VirtuoLab op elke server toepast, met per maatregel hoe belangrijk hij is.
Waarom heeft een VPS extra beveiliging nodig?
Een VPS (virtual private server) is een eigen server bij een hostingpartij, en bij de meeste VPS-pakketten ben je zelf verantwoordelijk voor de beveiliging. De hostingpartij zorgt dat de machine draait; wat erop staat, welke poorten openstaan en of er updates komen, is jouw zaak. Bij gedeelde hosting regelt de hoster veel van die dingen voor je, maar daar heb je ook minder controle. Dat verschil is belangrijk, want aanvallers zoeken het internet doorlopend automatisch af naar servers met een bekende zwakke plek. Volgens het Data Breach Investigations Report 2025 van Verizon begon 20% van de onderzochte datalekken bij een kwetsbaarheid, en bij 22% bij misbruikte inloggegevens. Een nieuwe server met een open SSH-poort krijgt doorgaans binnen enkele minuten de eerste inlogpogingen. Beveiliging is dus geen extraatje voor later, maar iets wat je regelt vóórdat de server live gaat.
Welke 12 maatregelen horen bij een veilige server?
Deze tabel is de checklist die VirtuoLab gebruikt. De essentiële maatregelen krijgt elke server; welke andere nodig zijn, hangt af van wat er op de server draait en hoe gevoelig de gegevens zijn.
Hoe zet je het beheer van een server veilig op?
Het beheer van een server zet je veilig op door SSH alleen met sleutels toe te laten en de SSH-poort niet publiek bereikbaar te maken. Stap 1: maak een SSH-sleutelpaar aan en zet in de SSH-configuratie PasswordAuthentication no en PermitRootLogin no, zodat raden van wachtwoorden geen zin meer heeft. Stap 2: log in met een gewone gebruiker en gebruik sudo voor beheertaken, zodat elke handeling aan een persoon te koppelen is. Stap 3: zet het beheer achter een privénetwerk zoals Tailscale, dat op WireGuard draait. De SSH-poort staat dan alleen open voor apparaten in dat netwerk, en de rest van het internet ziet hem niet eens. Stap 4: geef elke beheerder een eigen sleutel, zodat je toegang per persoon kunt intrekken als iemand stopt. Volgens Verizon was in 2025 bij 30% van de datalekken een externe partij betrokken. Weten wie toegang heeft tot je server, en die toegang klein houden, is daarom een van de eerste stappen.
Welke firewall-regels heeft een webserver nodig?
Een gewone webserver heeft van buitenaf alleen poort 443 (HTTPS) nodig, en poort 80 alleen om bezoekers door te sturen naar HTTPS en voor het vernieuwen van certificaten. Al het andere gaat dicht: de database, de beheerpanelen en interne diensten zijn alleen bereikbaar vanaf de server zelf of via het privénetwerk. Op Ubuntu en Debian doe je dat met UFW, een eenvoudige laag boven nftables. Let daarbij op één bekende valkuil: Docker zet bij een gepubliceerde poort zijn eigen regels in de firewall, en die gaan langs de UFW-regels heen. Een database-container met -p 5432:5432 is dan van buitenaf bereikbaar, ook al staat poort 5432 in UFW dicht. De oplossing is containers alleen op 127.0.0.1 te publiceren, of ze helemaal niet te publiceren en ze via een intern Docker-netwerk te laten praten. Controleer na elke wijziging van buitenaf welke poorten echt openstaan, bijvoorbeeld met een poortscan vanaf een andere machine.
Hoe houd je een server automatisch up-to-date?
Een server houd je up-to-date door beveiligingsupdates automatisch te laten installeren en de rest gepland bij te werken. Op Ubuntu en Debian regelt het pakket unattended-upgrades dat: het installeert beveiligingspatches voor het besturingssysteem zodra ze verschijnen. Grotere updates, zoals een nieuwe versie van PHP, Node.js of de database, doe je bewust en eerst op een testomgeving, omdat die je applicatie kunnen breken. Zet ook een melding aan als de server na een kernel-update een herstart nodig heeft, want tot die herstart draait de oude kernel door. Hoe snel dit moet kunnen, liet oktober 2026 zien. Toen kwamen twee kritieke PHP-lekken naar buiten voordat er een update was, en gingen onder meer DigiD en MijnOverheid uit voorzorg offline. Wie automatisch bijwerkt, is binnen uren na de release beschermd in plaats van na weken.
Hoe herken en blokkeer je aanvallen?
Aanvallen herken en blokkeer je op twee plekken: vóór de server en op de server. Vóór de server staat een webfirewall (WAF) met DDoS-bescherming, zoals die van Cloudflare. Die filtert bekende aanvalspatronen, kwaadaardige bots en overbelastingsaanvallen voordat ze je server bereiken, en laat de server alleen verkeer van Cloudflare toe. Op de server leest CrowdSec de logbestanden van onder meer SSH en de webserver, herkent patronen zoals herhaalde inlogpogingen of het afzoeken van bekende kwetsbare paden, en blokkeert die IP-adressen. CrowdSec deelt die signalen bovendien met andere gebruikers, zodat een adres dat elders al aanviel ook bij jou geblokkeerd wordt. Samen vangen deze twee lagen het grootste deel van het automatische verkeer op dat elke server krijgt. Ze vervangen geen updates: een gerichte aanval op een ongepatcht lek komt soms gewoon door een filter heen.
Hoe beperk je de schade als er toch iets misgaat?
De schade beperk je door elk onderdeel zo weinig mogelijk rechten te geven, zodat een inbreker in één applicatie niet meteen de hele server heeft. AppArmor legt per programma vast welke bestanden het mag lezen en schrijven en wat het mag uitvoeren; een gehackte webserver kan dan bijvoorbeeld niet bij de SSH-sleutels. Elke applicatie draait onder een eigen gebruiker zonder beheerrechten. Draai je met Docker, dan hoort daar ook bij: containers niet als root laten draaien, alleen de nodige Linux-rechten geven (cap_drop: ALL en dan toevoegen wat echt nodig is), het bestandssysteem waar mogelijk alleen-lezen maken, en nooit de Docker-socket in een container mounten. Wachtwoorden en API-sleutels horen in afgeschermde omgevingsvariabelen of een geheimenkluis, niet in de code. Zo blijft een fout in één onderdeel ook echt beperkt tot dat ene onderdeel.
Hoe controleer je of een server goed beveiligd is?
Of een server goed beveiligd is, controleer je met een audit vooraf en met doorlopend toezicht daarna. Lynis is een open-source auditprogramma dat de server langsloopt op honderden instellingen en een lijst met verbeterpunten en een hardening-score geeft; VirtuoLab draait het na het inrichten en daarna periodiek. Doorlopend toezicht doe je met auditd, dat belangrijke systeemacties vastlegt, zoals wie met beheerrechten iets deed, en met AIDE, dat een vingerafdruk van systeembestanden bewaart en meldt wanneer een bestand onverwacht verandert. Voor grotere omgevingen, of als je aan regels zoals de Cyberbeveiligingswet moet voldoen, die sinds 15 augustus 2026 geldt, verzamelt Wazuh de meldingen van alle servers centraal. Wazuh is een EDR- en SIEM-platform: het legt verbanden tussen meldingen en signaleert verdacht gedrag. Voor één kleine server is Wazuh meestal te zwaar; daar volstaan Lynis, auditd en AIDE.
Hoe regel je back-ups die een hack overleven?
Back-ups die een hack overleven, staan versleuteld op een andere locatie en zijn niet te wissen vanaf de server zelf. Dat laatste is belangrijk: als ransomware of een inbreker beheerrechten krijgt op je server en de back-ups vanaf die server te bereiken zijn, worden ze vaak als eerste gewist. Volgens Verizon speelde ransomware in 2025 een rol bij 44% van de datalekken. Een goede opzet volgt de 3-2-1-regel: drie kopieën, op twee soorten opslag, waarvan één op een andere locatie. Versleutel de back-ups voordat ze de server verlaten, met een sleutel die niet op de server staat. Dat versleutelen gebeurt nog lang niet overal: volgens de Cybersecuritymonitor 2025 van het CBS versleutelt maar 33% van de bedrijven met 2 tot 10 werkzame personen hun data, tegen 91% van de bedrijven met 250 of meer. Test ten slotte het terugzetten minstens elk kwartaal, want een back-up die je nooit hebt teruggezet, is een aanname en geen back-up.
Wat moet je monitoren, en wie reageert er?
Monitoren doe je op drie dingen: beschikbaarheid (is de site bereikbaar en snel), de gezondheid van de server (schijfruimte, geheugen, verlopen certificaten) en beveiligingsmeldingen (geblokkeerde aanvallen, gewijzigde bestanden, onverwachte inlogs). SSL-certificaten van Let's Encrypt zijn 90 dagen geldig en vernieuwen automatisch, maar een melding als dat een keer mislukt voorkomt een site met een waarschuwing in de browser. Minstens zo belangrijk is de vraag wie er reageert. Een melding waar niemand naar kijkt, beschermt niets. Eerlijk over hoe dat bij VirtuoLab gaat: de monitoring meet dag en nacht en stuurt direct meldingen, en opvolging door een mens gebeurt op werkdagen van 09:00 tot 18:00. VirtuoLab is een eenmanszaak en heeft dus geen meldkamer die 24 uur per dag bemand is. Heb je die wel nodig, dan is een gespecialiseerd SOC de betere keuze, en VirtuoLab kan je server daarop aansluiten.
De checklist in het kort
Hulp nodig bij het beveiligen van je server?
Wil je dat iemand je VPS of hosting naloopt, inricht of beheert? Plan een gratis kennismaking met VirtuoLab. Je spreekt direct met de developer zelf, Mustafa Kose: bel +31 6 43913632 of mail naar info@virtuolab.dev. Na de kennismaking krijg je een vaste prijs voor het werk, en je hoort ook eerlijk wat je zelf kunt doen en wat niet nodig is.