Die DNS-Auflösung und die Verwaltung der TCP-Ports stellen zwei Sicherheitsschichten dar, die in den Netzwerkrichtlinien von Unternehmen oft getrennt behandelt werden. Die Trennung dieser beiden Themen schafft jedoch ausnutzbare blinde Flecken: Eine Firewall kann den Port 53 korrekt filtern und gleichzeitig DNS-Anfragen, die in HTTPS-Traffic auf Port 443 eingekapselt sind, durchlassen. Zu verstehen, wie diese Mechanismen interagieren, ermöglicht es, die Netzwerkkonfiguration zu härten, ohne die Anzahl der Tools zu erhöhen.
Verschlüsseltes DNS über Port 443: die Schwachstelle, die die klassische Filterung nicht sieht
Die traditionelle DNS-Filterung basiert auf der Inspektion des Traffics, der über den Port UDP/53 oder TCP/53 läuft. Dieser Ansatz funktionierte, solange die DNS-Anfragen unverschlüsselt über einen speziellen Kanal übertragen wurden.
DNS-over-HTTPS (DoH), das über den TCP-Port 443 transportiert wird, verändert die Situation. Die DNS-Anfragen sind in standardmäßigen HTTPS-Traffic eingekapselt, was sie für eine Firewall, die nur auf Basis der Portnummern konfiguriert ist, von der restlichen Webnavigation ununterscheidbar macht. DNS-over-TLS (DoT), das in der Regel den TCP-Port 853 verwendet, stellt ein ähnliches Problem dar, ist jedoch leichter zu identifizieren und zu blockieren.
Laut Empfehlungen, die von der CISA und Axio Networks weitergegeben wurden, muss eine effektive DNS-Filterrichtlinie nun die autorisierten Resolver auf jedem Endgerät durchsetzen, einschließlich der Browser, die DoH standardmäßig aktivieren. Es reicht nicht mehr aus, nur den Port 53 zu überwachen: Die Ausgänge zu den Ports 443 und 853 müssen ebenfalls kontrolliert werden, um nicht autorisierte DNS-Auflösungen zu erkennen.
Sie finden technische Informationen auf Open Syd, die die anwendbaren Härtungsmechanismen für diese Konfigurationen im Detail erläutern.
TCP-Port 53 und Firewall: Warum das Blockieren von TCP DNS-Ausfälle verursacht
Ein häufiger Fehler bei der Konfiguration von Firewalls besteht darin, nur den UDP-Traffic auf Port 53 zuzulassen und TCP/53 zu blockieren. Die Logik scheint vernünftig: Die überwiegende Mehrheit der gängigen DNS-Anfragen verwendet UDP.
In der Praxis ist TCP/53 jedoch notwendig für große DNS-Antworten. DNSSEC-Einträge, die kryptographische Signaturen zu den Antworten hinzufügen, überschreiten regelmäßig die Größenbeschränkung der UDP-Pakete. Auch die Zonentransfers zwischen autoritativen DNS-Servern verwenden ausschließlich TCP. Das Blockieren dieses Protokolls auf Port 53 führt zu intermittierenden Ausfällen, die schwer zu diagnostizieren sind, da sie nur bei bestimmten Anfragetypen oder bestimmten Domains auftreten.
Die Cisco-Dokumentation zu den DNS-Voraussetzungen für Cisco Secure Access unterscheidet drei Netzwerkrollen, von denen jede unterschiedliche Firewall-Regeln auf Port 53 benötigt:
- Der Client-Computer, der Anfragen an den internen rekursiven Resolver sendet, kann in den meisten Fällen auf UDP/53 beschränkt werden
- Der rekursive Resolver muss in der Lage sein, über TCP/53 und UDP/53 zu den autoritativen Servern zu senden und zu empfangen, da er sonst die signierten DNSSEC-Einträge nicht auflösen kann
- Der autoritative Server benötigt einen offenen TCP/53 für Zonentransfers und große Antworten
Eine einheitliche Regel auf diese drei Rollen anzuwenden, würde die Namensauflösung gefährden oder unnötige Kanäle öffnen.
Netzwerksicherheitsrichtlinie: Über das Filtern nach Portnummer hinausgehen
Der Port 443 ist kein zuverlässiger Indikator mehr für eine klassische Webnutzung. DoH wird darüber transportiert, aber auch VPN-Tunnel, proprietäre Anwendungsströme und einige DNS-Sicherheitslösungen selbst. Eine Strategie, die sich nur auf die Portnummern stützt, lässt nicht identifizierten Traffic durch.
Ein robusterer Ansatz kombiniert mehrere Kontrollparameter:
- Die Identifizierung der autorisierten DNS-Resolver durch ihre IP-Adresse, mit der Blockierung aller anderen Resolver auf den Ports 53, 443 und 853
- Die Inspektion der TLS-Zertifikate, um legitimes DoH vom standardmäßigen Web-Traffic auf Port 443 zu unterscheiden
- Die anwendungsbasierte Überwachung, die das tatsächliche Protokoll unabhängig vom verwendeten Port identifiziert und es ermöglicht, einen DNS-Tunnel, der in HTTPS eingekapselt ist, zu erkennen
- Die Kontrolle der Konfigurationseinstellungen der Browser, um die automatische Aktivierung von DoH zu externen Resolvern zu verhindern
Diese Logik der Verteidigung in der Tiefe erfordert, dass DNS nicht als isolierter Dienst, sondern als übergreifende Komponente des Informationssystems behandelt wird. Die Routing-Regeln, die Verwaltung der auf den Geräten installierten Anwendungen und die Konfiguration der Betriebssysteme tragen alle zur DNS-Position des Unternehmens bei.
DNS-Überwachung und Erkennung abnormaler Ströme im Netzwerk
Die Verstärkung der Firewall-Regeln deckt nur einen Teil des Problems ab. Ein kompromittierter interner DNS-Resolver oder Malware, die DNS als Datenexfiltrationskanal nutzt, kann Traffic erzeugen, der den Filterregeln entspricht, aber bösartig ist.
Die Überwachung des Volumens und der Häufigkeit von DNS-Anfragen ist eine notwendige Ergänzung. Ein Computer, der innerhalb weniger Minuten mehrere Tausend Anfragen an dieselbe Domain sendet, zeigt ein atypisches Verhalten, das eine Untersuchung verdient. Ebenso signalisieren Anfragen an Domains mit hoher Entropie (zufällige Zeichenfolgen) oft einen DNS-Tunnel oder eine Kommunikation mit einem Command-and-Control-Server.
Die Erfahrungswerte variieren hinsichtlich des Schwellenwerts, ab dem diese Alarme nutzbar werden, ohne zu viele falsch-positive Ergebnisse zu erzeugen. Die Größe des Netzwerks, die Anzahl der Geräte und die Vielfalt der Geschäftsanwendungen beeinflussen direkt die Kalibrierung. Ein schlecht kalibriertes DNS-Überwachungssystem erzeugt Lärm, der schließlich von den Sicherheitsteams ignoriert wird.
Die Korrelation zwischen DNS-Protokollen und Firewall-Protokollen (offene TCP-Ports, ungewöhnliche ausgehende Verbindungen) hilft, diesen Lärm zu reduzieren. Ein Anstieg der DNS-Anfragen an eine unbekannte Domain, kombiniert mit einer ausgehenden TCP-Verbindung über einen nicht standardmäßigen Port von demselben Computer, erzeugt eine viel zuverlässigere Warnung als ein isolierter Indikator.
Die Härtung von DNS und die Kontrolle der TCP-Ports sind keine zwei getrennten Projekte. Die verfügbaren Daten zeigen, dass aktuelle Angriffe genau die Schnittstelle zwischen diesen beiden Schichten ausnutzen, wo verschlüsseltes DNS über als sicher geltende Ports läuft. Diese Themen gemeinsam in einer einheitlichen Netzwerksicherheitsrichtlinie zu behandeln, bleibt der einzige Ansatz, der der Realität des aktuellen Traffics Rechnung trägt.
