DNS-resolutie en TCP-poortbeheer vormen twee beveiligingslagen die vaak afzonderlijk worden behandeld in de netwerbeleid van bedrijven. Het scheiden van deze twee onderwerpen creëert echter uitbuitbare blinde vlekken: een firewall kan poort 53 correct filteren terwijl het DNS-verzoeken die zijn ingekapseld in HTTPS-verkeer op poort 443 doorlaat. Begrijpen hoe deze mechanismen interageren, stelt bedrijven in staat om de netwerkconfiguratie te versterken zonder het aantal tools te vermenigvuldigen.
Versleutelde DNS op poort 443: de kwetsbaarheid die traditionele filtering niet ziet
Traditionele DNS-filtering is gebaseerd op het inspecteren van verkeer dat via UDP/53 of TCP/53 loopt. Deze aanpak werkte zolang DNS-verzoeken in het openbaar verkeer op een specifieke kanaal circuleerden.
DNS-over-HTTPS (DoH), dat wordt vervoerd over de TCP-poort 443, verandert de situatie. DNS-verzoeken zijn ingekapseld in standaard HTTPS-verkeer, waardoor ze ononderscheidbaar zijn van de rest van het webverkeer voor een firewall die alleen is geconfigureerd op basis van poortnummers. DNS-over-TLS (DoT), dat doorgaans TCP-poort 853 gebruikt, vormt een vergelijkbaar probleem maar is gemakkelijker te identificeren en te blokkeren.
Volgens aanbevelingen van de CISA en Axio Networks moet een effectieve DNS-filteringbeleid nu de toegestane resolvers op elk apparaat afdwingen, inclusief browsers die DoH standaard inschakelen. Het is niet langer voldoende om alleen poort 53 te monitoren: uitgangen naar poorten 443 en 853 moeten ook worden gecontroleerd om ongeautoriseerde DNS-resoluties te detecteren.
U vindt technische informatie op Open Syd die de mechanismen voor het versterken van deze configuraties in detail beschrijft.
TCP-poort 53 en firewall: waarom het blokkeren van TCP DNS-uitval veroorzaakt
Een veelvoorkomende fout in de configuratie van firewalls is het alleen toestaan van UDP-verkeer op poort 53, terwijl TCP/53 wordt geblokkeerd. De logica lijkt redelijk: de overgrote meerderheid van de gangbare DNS-verzoeken gebruikt UDP.
In de praktijk is TCP/53 echter noodzakelijk voor grote DNS-antwoorden. DNSSEC-records, die cryptografische handtekeningen aan antwoorden toevoegen, overschrijden regelmatig de UDP-pakketgrootte limiet. Zone-overdrachten tussen autoritatieve DNS-servers gebruiken ook uitsluitend TCP. Het blokkeren van dit protocol op poort 53 veroorzaakt intermitterende uitval die moeilijk te diagnosticeren is, omdat deze zich alleen manifesteert voor bepaalde soorten verzoeken of bepaalde domeinen.
De Cisco-documentatie over DNS-vereisten voor Cisco Secure Access onderscheidt drie netwerkrollen, die elk verschillende firewallregels op poort 53 vereisen:
- De clientcomputer, die verzoeken naar de interne recursieve resolver verzendt, kan in de meeste gevallen beperkt blijven tot UDP/53
- De recursieve resolver moet in staat zijn om TCP/53 en UDP/53 naar de autoritatieve servers te verzenden en te ontvangen, anders kan het geen DNSSEC-ondertekende records oplossen
- De autoritatieve server heeft een open TCP/53 nodig voor zone-overdrachten en grote antwoorden
Het toepassen van een uniforme regel op deze drie rollen verzwakt de naamresolutie of opent onnodige kanalen.
Netwerkbeveiligingsbeleid: verder gaan dan filtering op poortnummer
Poort 443 is geen betrouwbare indicator meer voor traditioneel webgebruik. DoH passeert hier, maar ook VPN-tunnels, eigen applicatiestromen en sommige DNS-beveiligingsoplossingen zelf. Een strategie die alleen op poortnummers is gebaseerd, laat ongeïdentificeerd verkeer door.
Een robuustere aanpak combineert verschillende controleparameters:
- Identificatie van de toegestane DNS-resolvers op basis van hun IP-adres, met blokkering van elke andere resolver op poorten 53, 443 en 853
- Inspectie van TLS-certificaten om legitieme DoH van standaard webverkeer op poort 443 te onderscheiden
- Applicatiemonitoring die het werkelijke protocol identificeert, ongeacht de gebruikte poort, waardoor een DNS-tunnel die in HTTPS is ingekapseld kan worden gedetecteerd
- Controle van de configuratieparameters van browsers om automatische activatie van DoH naar externe resolvers te voorkomen
Deze logica van verdiepingsverdediging vereist dat DNS niet als een geïsoleerde dienst wordt behandeld, maar als een transversaal onderdeel van het informatiesysteem. De routeringsregels, het beheer van de op de computers geïnstalleerde applicaties en de configuratie van besturingssystemen dragen allemaal bij aan de DNS-houding van het bedrijf.
DNS-monitoring en detectie van abnormale stromen op het netwerk
Het versterken van firewallregels dekt slechts een deel van het probleem. Een gecompromitteerde interne DNS-resolver, of malware die DNS gebruikt als een kanaal voor gegevensexfiltratie, kan verkeer genereren dat voldoet aan de filterregels terwijl het kwaadwillend is.
Het monitoren van het volume en de frequentie van DNS-verzoeken is een noodzakelijke aanvulling. Een computer die binnen enkele minuten duizenden verzoeken naar hetzelfde domein verzendt, vertoont een atypisch gedrag dat onderzoek verdient. Evenzo wijzen verzoeken naar domeinnamen met hoge entropie (willekeurige tekenreeksen) vaak op een DNS-tunnel of communicatie met een command-and-controlserver.
De ervaringen uit de praktijk verschillen over de drempel waarboven deze waarschuwingen bruikbaar worden zonder te veel valse positieven te genereren. De grootte van het netwerk, het aantal computers en de diversiteit van zakelijke applicaties beïnvloeden direct de afstemming. Een slecht afgesteld DNS-monitoringsysteem genereert ruis die uiteindelijk door de beveiligingsteams wordt genegeerd.
De correlatie tussen DNS-logboeken en firewall-logboeken (open TCP-poorten, ongebruikelijke uitgaande verbindingen) helpt deze ruis te verminderen. Een piek in DNS-verzoeken naar een onbekend domein, gecombineerd met een uitgaande TCP-verbinding op een niet-standaard poort vanaf dezelfde computer, genereert een veel betrouwbaardere waarschuwing dan een geïsoleerde indicator.
Het versterken van DNS en het beheersen van TCP-poorten zijn geen twee afzonderlijke projecten. De beschikbare gegevens tonen aan dat recente aanvallen precies de verbinding tussen deze twee lagen benutten, waar versleutelde DNS door als veilig beschouwde poorten gaat. Deze onderwerpen samen behandelen in een verenigd netwerkbeveiligingsbeleid blijft de enige aanpak die rekening houdt met de realiteit van het huidige verkeer.
