De rust is voorbij
Fabien Potencier, de maker van Symfony (een populair PHP-framework), vatte het onlangs samen met een cijfer dat kort door de bocht is, maar veelzeggend: waar Symfony jarenlang ongeveer één security-melding per kwartaal kreeg, staat de teller nu op ten minste één per dag.
Zijn verklaring: het scannen van codebases op kwetsbaarheden was jarenlang duur, tijdrovend en voer voor specialisten. Dat is niet meer zo. Iedereen kan een AI-agent op een verse release loslaten, en die kamt de hele codebase uit in minuten. Als één onderzoeker een gat vindt, moet je aannemen dat anderen hetzelfde gat al hebben - en dat een deel daarvan het niet komt melden.
De klassieke embargo-aanpak - waarbij een fout stilletjes wordt voorbereid en gecoördineerd uitgerold voordat aanvallers weten waar ze moeten kijken - werkt daardoor niet meer zoals bedoeld. Potencier verwoordt het scherp: "The quiet window is gone for good." Zijn conclusie: gewoon zo snel mogelijk patchen, weekend of niet.
Wat Symfony overkomt, overkomt zo ongeveer alles wat je host: Linux zelf, de kernel, alle libraries en talen daaronder. En dat is niet alleen een technisch probleem. Onderschat niet wat het trekt aan mensen aan de frontlinie: developers, engineers, security-teams. Feitelijk is er nooit rust, want op ieder moment kan er weer een kwetsbaarheid zijn waar je urgent mee aan de slag moet. Eigenlijk was dat altijd al zo. Alleen zijn de kans, de urgentie en de veelheid inmiddels serieus toegenomen.
Onze klanten zijn bureaus, SaaS-bedrijven, webshops en grote platforms. Vaak met veel persoonsgegevens. Precies daarom zijn we scherp op security. Wat er bij ons gebeurt van het moment dat er een kritieke kwetsbaarheid binnenkomt tot het moment dat elke node bij elke klant gepatcht is - daar gaat de rest van dit stuk over.
Stap 1: de melding komt binnen
We houden via meerdere kanalen bij welke kwetsbaarheden er verschijnen. Een van de betere bronnen is het Digital Trust Center van het Ministerie van Economische Zaken en Klimaatbeleid: gerichte, nuchtere meldingen, geschreven voor mensen die de context kennen. Daarnaast leunen we op vendor-advisories, upstream security-lijsten en de bronnen die je verwacht.
Als onderdeel van onze ISO 27001-certificering evalueren we jaarlijks welke bronnen we volgen, hoe ze binnenkomen en of we iets missen. Niet als vinkje, maar omdat het een van de plekken is waar een blinde vlek écht duur kan uitpakken.
Stap 2: triage door minstens twee engineers
Elke melding wordt door ten minste twee engineers beoordeeld. Van toepassing op onze infrastructuur? Op klantomgevingen? Wat is de reële impact? Dat één persoon een kwetsbaarheid verkeerd inschat - te licht, of juist te zwaar - is menselijk. Dat twee mensen onafhankelijk van elkaar dezelfde fout maken, is een stuk minder waarschijnlijk.
Het klinkt simpel, en dat is het ook. Maar het scheelt in de praktijk het verschil tussen "we hebben het gemist" en "we hebben het aangepakt voor iemand er last van kreeg".
Stap 3: wie is er precies geraakt?
Zodra we weten dat een melding relevant is, moeten we weten waar het speelt. Welke klanten? Welke servers? Welke versies?
Dat lukt alleen als je goed weet wat er draait. Wij installeren daarom zo veel mogelijk als Debian-package. Compilen we software zelf, dan is dat een uitzondering, en geen regel. De reden is inzicht: via LibreNMS zien we precies welke software voor welke klanten op welke node draait, in welke versie.
Voor handmatig geïnstalleerde software zou dit niet werken: die valt buiten de package-database, en dus buiten het overzicht. En omdat we alles wat we kunnen via packages leveren, zien we ook direct welke OS-en en kernelversies waar draaien. Bij een kernel-kwetsbaarheid weten we binnen enkele minuten welke servers geraakt zijn.
Stap 4: de patch voorbereiden
Als de scope duidelijk is, maken we een Ansible-playbook dat het probleem verhelpt: een sysctl aanpassen, een package updaten, een configuratie hardenen. Wat er nodig is.
Die playbook belandt eerst in een merge request. Die wordt gereviewd door een collega vóórdat er iets naar productie gaat, ook als het snel moet. Snelheid en dubbelchecken sluiten elkaar niet uit - twee paar ogen op één diff duurt minuten, terwijl een verkeerde playbook uitrollen op honderden nodes dagen kan kosten om weer recht te trekken.
Voor het uitrollen gebruiken we Ansible in bulk. We hebben een eigen inventory-plugin geschreven die alle Core-nodes automatisch kent, via de Core API die klanten ook zelf gebruiken. Zodra een nieuwe node wordt aangemaakt, verschijnt hij vanzelf in de inventory. Geen lijstjes bijhouden, geen vergeten servers.
Stap 5: automatische security-updates - en de prijs die je daarvoor betaalt
Core-klanten kunnen zelf automatische security-updates aanzetten. Verschijnt er een security-update voor een package waar een service op leunt, dan wordt die update geïnstalleerd en - waar nodig - de service herstart. Ook overdag.
De impact is meestal nihil: een korte restart van een daemon, een graceful reload van nginx, klaar. Voor een echt druk platform met strikte piekbelasting kan dat wél problematisch zijn. Dan is het een afweging: automatisch snel gepatcht en geaccepteerde restarts, óf gepland patchen buiten kantooruren met een groter tijdsvenster voor aanvallers. Er is geen goede default - er is alleen de goede default voor jouw situatie.
Voor de kernel: KernelCare
Kernel-kwetsbaarheden zijn de vervelendste van allemaal. Traditioneel betekent een kernel-patch een reboot. Op een node met honderden klantprojecten voelt dat als een keuze tussen "nu onbereikbaar" en "straks gehackt".
Op Core ondersteunen we KernelCare: kernel-security-issues worden live gepatcht, terwijl de kernel draait. Geen reboot, geen downtime. De kans dat een node een langlopende kernel-kwetsbaarheid heeft doordat een reboot niet lekker uitkomt, dalen daarmee dicht bij nul.
Snel patchen is niet genoeg
Als iets ons de laatste jaren geleerd heeft, dan is het dat "snel patchen" wel noodzakelijk is, maar niet voldoende. Er komt altijd een moment dat een kwetsbaarheid al misbruikt wordt voordat de patch er is. Dat moment mag geen incident worden.
Daarom stapelen we lagen. ASLR staat aan waar dat kan. We hebben een eigen namespacing-implementatie ontwikkeld die klant-omgevingen strak van elkaar scheidt: als er iets lek is bij één klant, hoeft dat niet automatisch een probleem te zijn voor de rest. Meer daarover staat op onze security-pagina.
Voorbeeld: Copy Fail
Een van de ernstigere kwetsbaarheden van het afgelopen jaar - intern gedoopt "Copy Fail" - liet zien hoe dit in de praktijk werkt.
- 15:00 - we begonnen te testen op interne staging-nodes.
- 17:39 - alle klanten waren geïnformeerd. Klanten die extra aandacht nodig hadden, werden apart gebeld.
- 18:00 - de patch, uitvoerig getest, werd automatisch uitgerold via de Ansible-playbook.
- 22:00 - álle servers van álle klanten waren gepatcht.
Zeven uur, van test tot volledig uitgerold. Zonder dat er iemand naar een klant hoefde te bellen om te vragen of het schikte.
De frontlinie
Terug naar het begin. De golf Linux-kwetsbaarheden vlakt weer af. De volgende komt eraan - iemand ergens laat een agent los op een codebase, en over een paar weken zitten we in de volgende cyclus.
Dit is waarom "truly managed hosting" niet gewoon een marketingzin is. Dit is het werk dat erachter zit. Iemand moet die meldingen bijhouden, triëren, playbooks schrijven, patches reviewen, klanten bellen. Iemand moet 's ochtends kijken wat er 's nachts binnenkwam. En iemand moet 's nachts kunnen doorwerken als het er echt op aankomt.
Bij ons is dat de plek waar de meeste zorg naartoe gaat. Niet omdat het glamorous is. Maar omdat het het verschil maakt tussen een klant die morgen ontspannen achter zijn eigen laptop zit, en een klant die dat niet meer doet.
← Terug naar Insights