Ein DNS-Server, der auf alle Anfragen ohne Unterscheidung reagiert, mit standardmäßig offenen Ports, die seit der Inbetriebnahme niemand überprüft hat: Dieses Schema findet man in der Mehrheit der Unternehmensnetzwerke. Die Netzwerksicherheit spielt sich oft auf diesen beiden vernachlässigten Achsen ab, der Verwaltung von DNS und der Kontrolle von TCP-Ports, lange bevor ein Next-Generation-Firewall gekauft wird.
Kontrolle der DNS-Resolver: das erste Schloss, das im Netzwerk angebracht werden muss
Vor Ort beginnt das Problem fast immer am gleichen Punkt. Die Arbeitsstationen und die vernetzten Geräte senden ihre DNS-Anfragen an beliebige Resolver, einschließlich öffentlicher Resolver, die der Administrator nicht überwacht. Solange die erlaubten Resolver nicht eingeschränkt sind, lässt man einen unsichtbaren Ausgangskanal offen.
Die erste Maßnahme besteht darin, den gesamten DNS-Verkehr zu einem kontrollierten internen Resolver zu zwingen. Man blockiert ausgehende Anfragen auf dem UDP- und TCP-Port 53 zu jedem Ziel außer diesem Resolver. Dadurch kann jede Anfrage protokolliert, verdächtige Domains erkannt und die Kommunikation zu Command-and-Control-Servern (C2) unterbrochen werden.
Die Verschlüsselung von DNS kompliziert diesen Ansatz. DNS over HTTPS (DoH) verwendet den TCP-Port 443, den gleichen wie der klassische Webverkehr, was es schwierig macht, ihn mit traditionellen Netzwerkregeln zu filtern. DNS over TLS (DoT) läuft über den TCP-Port 853, der leichter identifizierbar ist.
Um die Kontrolle zu behalten, kann man das Funktionieren von Open Syd lernen und eine geeignete Strategie wählen: DoT auf Port 853 zum internen Resolver zulassen, während DoH auf den Arbeitsplätzen blockiert wird, um zu verhindern, dass die Browser die DNS-Politik der Organisation umgehen.
Offene TCP-Ports: auditieren, bevor gefiltert wird
Regelmäßig sieht man Server mit Dutzenden von offenen Ports, von denen einige zu standardmäßig installierten und nie genutzten Diensten gehören. Jeder offene Port ist eine potenzielle Angriffsfläche. Der Reflex besteht darin, die eigene Peripherie zu scannen, bevor ein Angreifer dies tut.
Ein Audit der aktiven TCP- und UDP-Ports, durchgeführt von außerhalb des Netzwerks, zeigt oft vergessene Dienste: eine Verwaltungsoberfläche auf einem nicht standardmäßigen Port, einen exponierten Datenbankdienst, einen alten Mailserver, der noch erreichbar ist. Ein unnötiger Port zu schließen, reduziert das Risiko effektiver als eine Erkennungsregel.
Priorisierung der Schließung nach Risikoniveau
Nicht alle offenen Ports stellen die gleiche Gefahr dar. Hier ist ein pragmatischer Sortierungsansatz:
- Die Ports, die mit der Fernadministration verbunden sind (SSH auf 22, RDP auf 3389, Weboberflächen auf 8080 oder 8443), sollten auf interne IP-Bereiche beschränkt oder nur über VPN zugänglich sein. Sie ungeschützt im Internet zu lassen, bleibt die Hauptursache für Kompromittierungen durch Brute-Force-Angriffe.
- Die Ports für E-Mail-Dienste (25, 465, 587, 993) verdienen eine strenge geografische Filterung, wenn die Aktivität lokal ist, und eine Überprüfung, dass die TLS-Verschlüsselungsprotokolle aktiviert sind, um die Daten während der Übertragung zu schützen.
- Die Ports, die von unverschlüsselten Protokollen verwendet werden (Telnet auf 23, FTP auf 21, HTTP auf 80), sollten zugunsten ihrer sicheren Äquivalente deaktiviert werden. Wenn ein Legacy-Dienst deren Beibehaltung erfordert, isoliert man diesen Dienst in einem eigenen Netzwerksegment.
DNS-Protokollierung und Korrelation mit TCP-Flüssen
Blockieren und Filtern reicht nicht aus, wenn man nie schaut, was passiert. Die Protokollierung von DNS-Anfragen, kombiniert mit den Verbindungsprotokollen auf den TCP-Ports, stellt ein mächtiges und untergenutztes Erkennungswerkzeug dar.
Ein Arbeitsplatz, der einen ungewöhnlichen Domainnamen auflöst und dann eine ausgehende TCP-Verbindung zu einer unbekannten IP-Adresse auf einem hohen Port öffnet, erzeugt ein schwaches Signal. Für sich genommen scheint jedes Ereignis harmlos zu sein. Es ist die Korrelation zwischen der DNS-Anfrage und dem TCP-Fluss, die die Exfiltration offenbart.
Der Leitfaden NIST SP 800-81 Revision 3, veröffentlicht am 19. März 2026, betont dieses Konzept der operationellen Sichtbarkeit. Er fasst DoH, DoT und DoQ unter der Kategorie “verschlüsseltes DNS” zusammen und empfiehlt, DNS nicht mehr als einfache Infrastruktur im Hintergrund zu behandeln, sondern als vollwertigen Sicherheitskontrollpunkt.
Was die Protokollierung erfassen muss
Um nutzbar zu sein, muss ein DNS-Protokoll mindestens den angeforderten Domainnamen, die Quell-IP-Adresse, den Zeitstempel und die zurückgegebene Antwort aufzeichnen. Auf der Seite der TCP-Ports werden die etablierten, abgelehnten und fehlgeschlagenen Verbindungsversuche beibehalten. Die Rückmeldungen variieren bezüglich der idealen Aufbewahrungsdauer, aber die europäische Durchführungsverordnung 2024/2690, die seit dem 7. November 2024 gilt, verpflichtet bestimmte Anbieter von DNS- und Infrastrukturdiensten zu einer kontinuierlichen Protokollierung mit Nachweis der Wirksamkeit der Kontrollen.
DNSSEC und Verschlüsselung: den Integrität der DNS-Antworten schützen
Ein Resolver, der korrekt antwortet, garantiert nicht, dass die Antwort auf dem Weg nicht verändert wurde. DNS-Cache-Vergiftung leitet Benutzer zu betrügerischen Servern um, ohne dass eine Warnung im Netzwerk ausgelöst wird. DNSSEC fügt den Zoneneinträgen eine kryptografische Signatur hinzu, um ihre Authentizität zu validieren.
DNSSEC validiert die Herkunft der Antworten, die DNS-Verschlüsselung schützt ihre Vertraulichkeit während der Übertragung: Die beiden Mechanismen ergänzen sich, keiner ersetzt den anderen.
In der Praxis erfordert die Bereitstellung von DNSSEC für die internen Zonen die Verwaltung der Erneuerung der kryptografischen Schlüssel. Ein abgelaufener Schlüssel ohne geplante Rotation führt zu einem Ausfall der Auflösung, der ebenso abrupt ist wie ein Angriff. Man automatisiert die Rotation oder man implementiert sie nicht.
Netzwerksicherheitsrichtlinie: DNS und Ports in einem einheitlichen Ansatz verbinden
Die DNS auf der einen Seite und die Ports auf der anderen Seite zu behandeln, schafft blinde Flecken. Ein vom Firewall erlaubter Dienst, der bösartige Domains auflöst, wird unter dem Radar bleiben. Umgekehrt lässt eine DNS-Blockierung ohne Kontrolle der Ports die Tür für direkte Verbindungen über IP-Adressen offen.
Der kohärente Ansatz verbindet die drei Ebenen:
- Der interne DNS-Resolver filtert die Domains und protokolliert die Anfragen.
- Die Firewall beschränkt die TCP- und UDP-Ports auf die nur deklarierten und gewarteten Dienste.
- Ein Korrelationstool (SIEM oder einfaches Log-Analyse-Skript) kreuzt die DNS-Ereignisse und die Netzwerkverbindungen, um anormale Verhaltensweisen zu identifizieren.
Diese Verknüpfung erfordert kein großes Budget. Ein filternder Resolver, vierteljährlich überarbeitete Firewall-Regeln und ein wöchentlich konsultiertes Log decken die Mehrheit der mit DNS und Ports verbundenen Schwachstellen ab. Das schwächste Glied ist nicht das Werkzeug, sondern die Regelmäßigkeit der Überprüfung.
