Een bedrijfswebsite hardenen die door een DNS-filter werd geblokkeerd

Wat het echt in gang zette

Geen incident. Een commerciële blokkade. Het bedrijfs-DNS-filter van een van zijn eigen afnemers weigerde het domein van onze klant, en een leverancier van wie de website binnen het netwerk van de afnemer niet resolvet, heeft een bedrijfsprobleem en geen IT-probleem.

De opdracht kwam binnen als "ze denken dat wij gehackt zijn". Dat waren ze niet.

De diagnose, in één week

Wij leverden een technisch rapport over beveiliging, SSL en reputatie, gebouwd op openbare referentiescanners: SSL-analyse, HTTP-headerscan, domeinreputatie, safe browsing en multi-engine antivirus. Iedereen kan ze allemaal opnieuw draaien, en dat is precies de bedoeling.

De conclusie was duidelijk. De site was niet gehackt en stond op geen enkele blacklist. Dit was een hardening- en configuratieprobleem, geen besmetting.

TLS was al in orde voordat wij begonnen: geldig certificaat, TLS 1.3 actief, geen zwakke ciphers, geldige keten en forward secrecy. SSL kreeg bij de eerste diagnose een A, voordat wij iets aanraakten. Drie andere zaken zorgden voor de automatische classificatie "lage beveiligingshouding" waar bedrijfsfilters op afgaan:

• Geen enkele HTTP-beveiligingsheader. Headercijfer: F.
• Een verlopen en niet-passend reservecertificaat, zichtbaar gemaakt door de gedeelde hosting.
• Zichtbare servervingerafdrukken: interpreterversie, handtekening van het controlepaneel en technologieheader.

De beperking die de architectuur bepaalde

De enige beschikbare toegang was het beheerpaneel van het CMS. Zonder hostingtoegang is hardening op serverniveau niet toepasbaar op de oorspronkelijke infrastructuur, dus migreren was geen esthetische voorkeur. Het was de enige route.

Het alternatief was de site opnieuw bouwen in code: naar schatting drie tot zes weken, met het domein al die tijd geblokkeerd. De migratie was omkeerbaar en deblokkeerde eerder. De statische herbouw bleef op de plank liggen als uitgestelde fase.

Wat er precies is veranderd

Het werk liep in drie fasen: migratie met functionele verificatie en een ronde langs URL's en permalinks, beveiligings- en configuratiehardening, en reputatieopschoning.

Headers die na de hardening daadwerkelijk worden geserveerd

HSTS met includeSubdomains, een Content-Security-Policy, de legacy XSS-beschermingsheader, nosniff, X-Frame-Options op SAMEORIGIN, een strikte Referrer-Policy, een Permissions-Policy met de volledige lijst gevoelige API's uitgezet, en een serverheader zonder versienummer.

De CMS-laag

Interne paden opnieuw toegewezen, gebruikelijke paden en bestanden verborgen, het loginpad verplaatst met een beheerde nood-URL, bruteforcebeveiliging, een applicatiefirewall die IP's automatisch blokkeert, XML-RPC uitgezet, discovery-endpoints uit en themadetectoren geblokkeerd. AI-crawlers zijn bewust toegelaten, omdat vindbaarheid onderdeel van de opdracht was.

Wat wij niet hebben gedaan, en dus ook niet beweren

In dit project zat geen netwerk-WAF en geen CDN. De enige firewall was die in de hardeningplugin van het CMS. Over cookies: de site hield zijn bestaande consentplugin en van werk aan cookievlaggen hebben wij geen registratie, dus claimen wij dat niet. Over dependencies: de eindinventaris was rond de twintig plugins, drie daarvan door ons toegevoegd; er is geen CVE-lijst of telling van kwetsbaarheden vastgelegd, dus publiceren wij geen aantal gesloten kwetsbaarheden.

De DNS-omzetting

TTL 24 tot 48 uur van tevoren omlaag, A-record gewijzigd, en de mailrecords (MX, SPF, DKIM en DMARC) ongemoeid gelaten, zodat de zakelijke e-mail op het domein geen minuut stillag.

Hoe het is gemeten, en wat die meting waard is

Vooraf: headers F, SSL A. Na de hardening: A+ op de headers, bij een geforceerde scan zonder cache en zonder waarschuwingen.

Die A+ is afgelezen op de migratiehost, in 2026, vóór de omzetting van het live domein. Van een herscan van het echte domein na de omzetting hebben wij geen registratie, dus presenteren wij de A+ niet als productieresultaat.

Dat telt verder dan dit ene project. Een headercijfer is een gedateerde foto van één host, geen eigenschap die de site vanaf dat moment bezit. Eén nieuwe embed, één nieuwe plugin of één standaardinstelling van een provider en het cijfer schuift. Wil je weten wat een site vandaag scoort, scan hem dan vandaag.

De linkcontrole, en waarom die bestaat

Na de DNS-wijziging hebben we 24 pagina's gecontroleerd, 12 per taal, link voor link. Daar bleek dat de eerste massale URL-vervanging onvolledig was geweest. Verwijzingen naar de stagingomgeving stonden nog in de globale footer, in de CTA's van de paginabouwer, in de consentlinks in formulieren, in meerdere PDF's, in juridische teksten en in een icoonfont van het thema dat een foutmelding gaf.

De herbruikbare les: een massale vervanging kan in simulatiemodus draaien en voor voltooid worden versleten. Een wijziging is pas klaar als een echt verzoek aan de live site dat aantoont.

Afronding, en wat wij niet beweren

Het project werd afgerond met een opleverrapport als PDF, het technische werk compleet, een schone linkcontrole en 30 dagen technische garantie. Vier dagen van gunning tot technische afronding. Vier maanden vanaf het oorspronkelijke incident, waarvan er ongeveer drie verloren gingen aan onderhandelen met de vorige provider.

Twee dingen die wij bewust niet beweren. Wij hebben geen registratie dat die afnemer de DNS-blokkade heeft opgeheven. En de reputatieverzoeken die aan het eind zijn ingediend, stonden bij afronding nog open, zonder vastgelegde uitkomst.

De methode, op volgorde

De volgorde is de methode, en de volgorde is het deel dat bruikbaar blijft bij de volgende site. Meten met openbare tools die iedereen kan overdoen. De configuratie herstellen, niet het verhaal. Opnieuw meten, met vermelding van de host en de datum van de scan. En daarna controleren tegen de live site in plaats van tegen het plan.