Een DNS-server die op alle verzoeken zonder onderscheid reageert, met standaard open poorten die niemand sinds de ingebruikname heeft gecontroleerd: dit schema komt voor in de meeste bedrijfsnetwerken. Netwerkbeveiliging draait vaak om deze twee verwaarloosde aspecten, het beheer van DNS en de controle van TCP-poorten, lang voordat er een next-gen firewall wordt aangeschaft.
Controle van DNS-resolvers: het eerste slot dat op het netwerk moet worden geplaatst
In de praktijk begint het probleem bijna altijd op dezelfde plek. Werkstations en verbonden objecten sturen hun DNS-verzoeken naar om het even welke resolver, inclusief openbare resolvers die de beheerder niet controleert. Zolang de toegestane resolvers niet zijn beperkt, laten we een onzichtbaar uitgangskanaal open.
De eerste actie is om al het DNS-verkeer naar een interne, beheerde resolver te dwingen. We blokkeren uitgaande verzoeken op poort UDP en TCP 53 naar elke bestemming anders dan deze resolver. Dit maakt het mogelijk om elk verzoek te loggen, verdachte domeinen te detecteren en communicatie met command and control (C2) servers te onderbreken.
DNS-encryptie bemoeilijkt deze aanpak. DNS over HTTPS (DoH) gebruikt poort TCP 443, dezelfde als voor normaal webverkeer, waardoor het moeilijk te filteren is met traditionele netwerkregels. DNS over TLS (DoT) gaat via poort TCP 853, wat gemakkelijker te identificeren is.
Om de controle te behouden, kunnen we leren hoe Open Syd werkt en een geschikte strategie kiezen: DoT op poort 853 naar de interne resolver toestaan terwijl DoH op de werkstations wordt geblokkeerd om te voorkomen dat browsers het DNS-beleid van de organisatie omzeilen.
Open TCP-poorten: auditeren voordat je filtert
We zien regelmatig servers met tientallen poorten in luistermodus, waarvan sommige overeenkomen met standaard geïnstalleerde en nooit gebruikte diensten. Elke open poort is een potentiële aanvalsvector. De reflex is om de eigen perimeter te scannen voordat een aanvaller dat doet.
Een audit van actieve TCP- en UDP-poorten, uitgevoerd vanaf buiten het netwerk, onthult vaak vergeten diensten: een beheerdersinterface op een niet-standaard poort, een blootgestelde database-service, een oude mailserver die nog bereikbaar is. Een onnodige poort sluiten vermindert het risico effectiever dan een detectieregel.
Prioriteren van sluiting op basis van risiconiveau
Niet alle open poorten vormen hetzelfde gevaar. Hier is een pragmatische sorteerbenadering:
- De poorten die verband houden met externe administratie (SSH op 22, RDP op 3389, webinterfaces op 8080 of 8443) moeten worden beperkt tot interne IP-bereiken of alleen toegankelijk zijn via VPN. Ze blootstellen aan het internet blijft de belangrijkste oorzaak van compromittering door brute force.
- De poorten voor e-maildiensten (25, 465, 587, 993) verdienen strikte geografische filtering als de activiteit lokaal is, en een controle dat de TLS-encryptieprotocollen zijn ingeschakeld om gegevens tijdens verzending te beschermen.
- De poorten die worden gebruikt door ongecodeerde protocollen (Telnet op 23, FTP op 21, HTTP op 80) zouden moeten worden gedeactiveerd ten gunste van hun beveiligde tegenhangers. Als een legacy-service hun behoud vereist, isoleren we deze service in een speciaal netwerksegment.
DNS-logging en correlatie met TCP-stromen
Blokkeren en filteren is niet genoeg als we nooit kijken naar wat er gebeurt. Het loggen van DNS-verzoeken, gecombineerd met de verbindingslogs op TCP-poorten, vormt een krachtig en onderbenut detectie-instrument.
Een werkstation dat een ongebruikelijke domeinnaam oplost en vervolgens een uitgaande TCP-verbinding opent naar een onbekend IP-adres op een hoge poort, genereert een zwak signaal. Op zichzelf lijkt elk evenement onschuldig. Het is de correlatie tussen het DNS-verzoek en de TCP-stroom die de exfiltratie onthult.
De gids NIST SP 800-81 Revision 3, gepubliceerd op 19 maart 2026, benadrukt dit concept van operationele zichtbaarheid. Het groepeert DoH, DoT en DoQ onder de categorie “encrypted DNS” en beveelt aan om DNS niet langer te behandelen als een eenvoudige infrastructuur op de achtergrond, maar als een volwaardig beveiligingscontrolepunt.
Wat de logging moet vastleggen
Om bruikbaar te zijn, moet een DNS-log minimaal de opgevraagde domeinnaam, het bron-IP-adres, de tijdstempel en het teruggegeven antwoord registreren. Aan de kant van TCP-poorten bewaren we de gevestigde, geweigerde verbindingen en de mislukte verbindingspogingen. De meningen verschillen over de ideale bewaartijd, maar de Europese uitvoeringsverordening 2024/2690, van kracht sinds 7 november 2024, verplicht bepaalde DNS- en infrastructuurdienstverleners tot een doorlopende logging met bewijs van effectiviteit van de controles.
DNSSEC en encryptie: de integriteit van DNS-antwoorden beschermen
Een resolver die correct antwoord geeft, garandeert niet dat het antwoord onderweg niet is gewijzigd. DNS-cachevervuiling leidt gebruikers naar frauduleuze servers zonder dat er een waarschuwing wordt afgegeven aan de netwerkzijde. DNSSEC voegt een cryptografische handtekening toe aan de zone-informatie om de authenticiteit ervan te valideren.
DNSSEC valideert de oorsprong van de antwoorden, DNS-encryptie beschermt hun vertrouwelijkheid tijdens verzending: de twee mechanismen vullen elkaar aan, geen van beide vervangt de ander.
In de praktijk vereist het implementeren van DNSSEC op interne zones dat we het beheer van cryptografische sleutelvernieuwing regelen. Een verlopen sleutel zonder geplande rotatie veroorzaakt een resolutie-uitval die net zo abrupt is als een aanval. We automatiseren de rotatie of we implementeren het niet.
Netwerkbeveiligingsbeleid: DNS en poorten verbinden in een geïntegreerde aanpak
DNS aan de ene kant en poorten aan de andere kant behandelen creëert blinde vlekken. Een service die door de firewall is toegestaan maar die kwaadaardige domeinen oplost, zal onder de radar blijven. Omgekeerd laat een DNS-blokkering zonder controle van de poorten de deur open voor directe verbindingen via IP-adres.
De samenhangende aanpak verbindt de drie lagen:
- De interne DNS-resolver filtert de domeinen en logt de verzoeken.
- De firewall beperkt de TCP- en UDP-poorten tot alleen de gedeclareerde en onderhouden diensten.
- Een correlatietool (SIEM of een eenvoudig loganalyse-script) kruist de DNS-gebeurtenissen en netwerkverbindingen om abnormaal gedrag te identificeren.
Deze articulatie vereist geen aanzienlijk budget. Een filterende resolver, firewallregels die elk kwartaal worden herzien en een logboek dat elke week wordt geraadpleegd, dekken de meeste kwetsbaarheden met betrekking tot DNS en poorten. De zwakste schakel is niet de tool, maar de regelmaat van de beoordeling.
