Frage Laufen DNS-Abfragen immer über UDP?


Ich habe ein bisschen Zeit damit verbracht, dieses Thema zu recherchieren, und ich kann keine genaue Antwort finden. Daher bin ich mir ziemlich sicher, dass es kein Duplikat ist, und obwohl meine Frage auf einem Sicherheitsbedürfnis beruht, denke ich, dass es immer noch sicher ist Fragen Sie hier, aber lassen Sie mich wissen, wenn ich es die Sicherheitsgemeinschaft bewegen muss.

Im Wesentlichen verwenden DNS-Abfragen jemals TCP (wenn ja, welches Szenario könnte dies auftreten)? Auch hier spreche ich nur von Abfragen. Ist es möglich, dass sie über TCP reisen? Wenn Domänen maximal 253 Byte lang sein dürfen und UDP-Pakete bis zu 512 Byte groß sein können, werden Abfragen nicht immer als UDP ausgeführt? Ich dachte nicht, dass eine auflösbare Abfrage groß genug sein könnte, um die Verwendung von TCP zu erfordern. Wenn ein DNS-Server jemals eine Anfrage für eine Domäne mit mehr als 253 Byte erhalten würde, würde der Server die Anfrage fallen lassen und nicht versuchen, sie zu lösen? Ich bin mir sicher, dass ich hier einige falsche Annahmen gemacht habe.

In einigen Kontexten arbeite ich mit der Sicherheitsgruppe zusammen, um DNS-Abfragen in ihr Sicherheitsüberwachungstool einzubinden. Aus verschiedenen Gründen haben wir beschlossen, diesen Datenverkehr über die Standardpaketerfassung auf DNS-Servern und Domänencontrollern zu erfassen. Die Hauptanforderung besteht darin, alle DNS-Abfragen zu erfassen, damit sie feststellen können, welcher Client versucht hat, eine bestimmte Domäne aufzulösen. Basierend auf dieser Anforderung geht es nicht um die Erfassung von DNS-Antworten oder anderen Datenverkehr wie z. B. Zonenübertragungen. Dies ist auch darauf zurückzuführen, dass das Protokollvolumen so weit wie möglich begrenzt werden muss. Daher planen wir, nur DNS-Abfragen zu erfassen, die für den DNS-Server bestimmt sind und über UDP gesendet werden. Für einen größeren Kontext (hier wird der Frageumfang angesprochen) wurde nun aufgezeigt, dass wir möglicherweise die Sichtbarkeit der Sicherheit erweitern müssen, um Aktivitäten wie verdeckte Kanäle überwachen zu können, die über DNS laufen (was auch die Erfassung von DNS-Antworten erforderlich machen würde). und anschließend TCP-Verkehr). Aber selbst in diesem Szenario dachte ich, dass jeder ausgehende DNS-Datenverkehr in Form von Suchvorgängen / Abfragen erfolgen würde, und dass diese immer über UDP verfügten, selbst wenn sie aus einer bösartigen Quelle stammten (wegen meiner Argumentation im ersten Absatz). Das wirft einige zusätzliche Fragen auf:

  • Würden wir zumindest die Hälfte des Gesprächs mit dem von mir skizzierten Ansatz einfangen? Oder würde ein Client jemals DNS-Datenverkehr senden, der nicht in Form einer Abfrage vorliegt? (vielleicht wie eine Art Antwort auf die Antwort eines DNS-Servers, und endet vielleicht über TCP)

  • Können DNS-Abfragen zur Verwendung von TCP geändert werden? Würde ein DNS-Server eine über TCP eingehende DNS-Abfrage annehmen und beantworten?

Nicht sicher, ob es relevant ist, aber wir beschränken DNS-Anfragen auf autorisierte DNS-Server und blockieren alle anderen Datenverkehr über Port 53. Ich bin definitiv ein Anfänger, also tut mir leid, wenn meine Frage nicht konform ist, und lass es mich wissen wie ich modifizieren soll.


31
2018-03-23 18:18


Ursprung


Paging @ Alnitak, wir diskutieren Ihr Baby. :) - Andrew B
Wie kann ich erzwingen, dass die Standard-DNS-Abfrage im TCP-Modus funktioniert?. Obwohl ein OS X / Mac OS mit einigen Mods auch für Linux / Windows funktioniert. - klanomath


Antworten:


Normale DNS-Abfragen verwenden UDP-Port 53, aber längere Abfragen (> 512 Oktette) erhalten eine "abgeschnittene" Antwort, die zu einer TCP 53-Konversation führt, um das Senden / Empfangen der gesamten Abfrage zu erleichtern. Außerdem bindet der DNS-Server an Port 53, aber die Abfrage selbst stammt von einem zufälligen Port mit hoher Nummer (49152 oder höher), der an Port 53 gesendet wird. Die Antwort wird von Port 53 an diesen Port zurückgegeben.

Netzwerkports, die von DNS | verwendet werden Microsoft Text & Tabellen

Wenn Sie Sicherheitsabfragen für DNS-Abfragen in Ihrem Netzwerk durchführen möchten, müssen Sie dies berücksichtigen.

Beachten Sie, dass DNS auch für Zonentransfers (Abfragetyp AXFR) verwendet wird, um andere DNS-Server mit neuen Datensätzen zu aktualisieren. Ein Mann im mittleren Angriff kann mit einer solchen Übertragung beginnen, indem er einen primären Nameserver mit DDOS versorgt, so dass er zu beschäftigt ist, um auf eine sekundäre Anfrage nach aktualisierten Datensätzen zu antworten. Der Hacker parodiert dann dieselbe Primärseite, um "vergiftete" Datensätze an die Sekundärseite zu senden, die gängige DNS-Domänen an kompromittierte Hosts umleiten.

Ihre Sicherheitsüberprüfung sollte also genau auf den Abfragetyp AXFR achten, und Ihre DNS-Systeme sollten nur AXFR-Austausch von bestimmten IP-Adressen akzeptieren.

SANS Institut InfoSec Lesesaal | sans.org


36
2018-03-23 18:40



Danke George, wirklich hilfreiches Zeug! Also, um schnell auf Ihren ersten Satz zu klären - ein UDP-Paket kann nur 512 Bytes passen, oder? Wenn also eine DNS-Abfrage größer als 512 wäre, würde sie dann nicht direkt über das TCP hinaus starten? Ich habe versucht, dies selbst zu testen, indem wir wireshark ausführen und nslookup verwenden, um große Domains aufzulösen, aber es scheint mich zu hindern, Domänen mit mehr als 200 Zeichen auszuprobieren (nicht die genaue Anzahl, aber der Punkt ist, dass ich dieses Szenario nicht vollständig testen konnte) . - Caderade
Es ist nicht die "Abfrage", sondern die "Antwort", die mehr als 512 Bytes betragen würde und der Client würde nicht wissen, was die "Antwort" wäre. - AbraCadaver
@Cadarade Ja, Sie haben Recht, dass sie TCP oder UDP sein können, aber nur Zonenübertragungen werden als TCP beginnen. Clientabfragen sind UDP, es sei denn, sie erhalten eine Antwort von dem Server, auf dem das Abschneidebit gesetzt ist. Dann kann dann TCP verwenden. - AbraCadaver
Können Clients TCP für kleine Antworten trotzdem verwenden? - Mehrdad
"Ein UDP-Paket kann nur 512 Bytes enthalten" Nein, es ist die Annahme, dass der Puffer des Clients nur 512 Bytes aufnehmen kann, was dazu führt, dass Server sich so verhalten. Server können mithilfe von EDNS über einen längeren Puffer informiert werden. - Bryan


Das begann als Kommentar zu Georges Antwort, aber es dauerte lange. Das größere Bild ist etwas kompliziert, da es etwas Geschichte zu verstehen braucht.

  • RFC 1035 Ursprünglich wurde ein Limit von 512 Bytes angegeben, um eine UDP-Fragmentierung zu vermeiden. Fragmentierte UDP-Datagramme und TCP wurden als Optionen des letzten Ausweges gewählt, um den Overhead von DNS-Transaktionen zu minimieren. Zonenübertragungen verwenden immer TCP, da Zonentransfers naturgemäß> 512 Byte beanspruchen. (es wäre eine Verschwendung von Bandbreite, überhaupt mit UDP zu beginnen)

  • TCP-Wiederholungsversuche beim Abschneiden werden weitgehend unterstützt, wie es in angegeben wurde RFC 1123 seit 1989.

  • EDNS (0) ist definiert durch RFC 6891 (2013), und davor gab es einen vorgeschlagenen Standard aus dem Jahr 1999. Es definiert einen Mechanismus, bei dem Clients und Server UDP-Größen größer als 512 aushandeln können. Aufgrund der Neuheit von EDNS (0) machen viele Hardware-Appliances Annahmen über die Struktur von DNS-Paketen, die dazu führen, dass konforme Pakete verworfen werden. Der häufigste Grund ist eine Annahme, dass DNS-Nachrichten von mehr als 512 Bytes ungültig sind, aber dies ist einer unter mehreren.

Wenn wir das in das beobachtete Verhalten aufteilen:

  1. DNS-Abfragen meistens Beginnen Sie als UDP, es sei denn, es ist im Voraus bekannt, dass die Antwort zu groß ist, um damit zu beginnen. (Zonenübertragungen)
  2. Die Antwort kann einen TCP-Wiederholungsversuch im Client auslösen, wenn eine abgeschnittene Antwort angezeigt wird. Dies wird ziemlich gut unterstützt.
  3. Eine UDP-Antwort von mehr als 512 Bytes kann gesehen werden, wenn der Client EDNS (0) verwendet, um eine größere Nutzlast anzukündigen, und der empfangende Server unterstützt es. Dies wird nur passieren ob Hardware, die zwischen den beiden sitzt, stört nicht und führt zu einem verlorenen oder beschädigten Paket.
  4. Der Kunde kann Wählen Sie, eine EDNS (0) -Abfrage mit einer kleineren angekündigten Nutzlast erneut zu versuchen, wenn eine Antwort nicht angezeigt wird, aber die Details variieren zwischen den Implementierungen.
    • Es ist wichtig zu beachten, dass die Antwort, die es schließlich durchmacht, möglicherweise zu groß ist, um in die angeforderte Größe zu passen, was zu Verhalten Nr. 2 oben führt. (ye olde TCP wiederholen)
    • Die Client-Seite kann Wählen Sie, um sich an die Größe zu erinnern, die letztendlich zu einem Erfolg führte. Auf diese Weise kann vermieden werden, unnötige Anfragen zu verschwenden, um sie erneut zu untersuchen. Etwas anderes zu tun wäre ziemlich verschwenderisch, insbesondere wenn das Endergebnis einen TCP-Fallback erforderte.

Sie sollten auch bedenken, dass RFC 7766 ermöglicht die Wiederverwendung von Verbindungen über TCPund es ist möglich, quer über TCP auf Abfrage-Pipeline zu stoßen. Einige Werkzeuge unterlassen Sie erkennen DNS-Abfragen über die erste in einer TCP-Sitzung gesehen, dnscap ist ein Beispiel dafür.


26
2018-03-23 23:28



Einer der Gründe, um das abgeschnittene Bit zu setzen, ist Response Rate Limiting (RRL). Als eine Technik zur Verringerung der DNS-Verstärkung kann der Server abgeschnittene Pakete senden, um Clients mit gutem Verhalten zu TCP zu wechseln, was hoffentlich verhindert, dass Pakete von gefälschten Adressen beantwortet werden. - Edheldil
Wiederverwendung von Verbindungen: Bringen Sie Ihrem Resolver also bei, zuerst nach google.com zu fragen, bevor er nach scantycladladies.com fragt. Dann merkt dnscap nichts. ;-) - Lenne


Dort ist  RFC 7766, DNS-Transport über TCP - Implementierungsanforderungen.

  1. Einführung

Meiste DNS [RFC1034] Transaktionen erfolgen über UDP [RFC768].   TCP [RFC793] wird immer für vollständige Zonenübertragungen verwendet (mit AXFR)   und wird oft für Nachrichten verwendet, deren Größe die des DNS-Protokolls übersteigt   ursprüngliche 512-Byte-Grenze. Die wachsende Bereitstellung von DNS-Sicherheit   (DNSSEC) und IPv6 hat die Antwortgrößen und damit die Verwendung erhöht   von TCP. Die Notwendigkeit für eine erhöhte TCP - Nutzung wurde auch von der   Schutz bietet es gegen Adress-Spoofing und daher   Ausnutzung von DNS bei Reflektions- / Amplifikationsangriffen. Ist das jetzt   weit verbreitet in Response Rate Limiting [RRL1] [RRL2].   Neuere Arbeiten zu DNS-Datenschutzlösungen wie   [DNS-über-TLS] ist eine weitere Motivation, DNS-over-TCP erneut zu besuchen   Anforderungen.

Abschnitt 6.1.3.2 von [RFC1123] Zustände:

  DNS resolvers and recursive servers MUST support UDP, and SHOULD
  support TCP, for sending (non-zone-transfer) queries.

Einige Implementierer haben den oben zitierten Text jedoch als wichtig angesehen   Diese TCP-Unterstützung ist eine optionale Funktion des DNS-Protokolls.

Die meisten DNS-Serveroperatoren unterstützen bereits TCP, und die   Standardkonfiguration für die meisten Software-Implementierungen ist zu unterstützen   TCP. Die primäre Zielgruppe für dieses Dokument sind diese Implementierer   deren begrenzte Unterstützung für TCP die Interoperabilität einschränkt und behindert   Bereitstellung neuer DNS-Funktionen.

Dieses Dokument aktualisiert daher die Kern-DNS-Protokollspezifikationen   so dass die Unterstützung für TCP fortan ein ERFORDERLICHER Teil eines vollständigen DNS ist   Protokollimplementierung.

Es gibt mehrere Vorteile und Nachteile für die verstärkte Nutzung von   TCP (siehe Anhang A) sowie Details zur Implementierung, die benötigt werden   ist zu berücksichtigen. Dieses Dokument behandelt diese Probleme und präsentiert   TCP als gültige Transportalternative für DNS. Es erweitert den Inhalt   von [RFC5966], mit zusätzlichen Überlegungen und Lektionen gelernt   aus Forschung, Entwicklung und Implementierung von TCP in DNS und in   andere Internetprotokolle.

Während dieses Dokument keine spezifischen Anforderungen an Betreiber von   DNS-Server zu erfüllen, bietet es einige Vorschläge an die Betreiber zu   Hilfe sicherzustellen, dass die Unterstützung für TCP auf ihren Servern und im Netzwerk ist   optimal. Es sollte beachtet werden, dass die Unterstützung von TCP (oder der   Blockierung von DNS über TCP auf der Netzwerkschicht) wird wahrscheinlich führen   Auflösungsfehler und / oder Timeouts auf Anwendungsebene.


6
2018-03-23 18:40



Hey Ron - Ich habe diesen RFC tatsächlich vor dem Posten gelesen, aber wenn du zum Beispiel im ersten Absatz schaust, scheint es zu betonen, dass TCP benötigt wird, um größere Antworten zu unterstützen - "Die wachsende Verbreitung von DNS-Sicherheit (DNSSEC) und IPv6 hat die Antwortgrößen und damit die Verwendung von TCP erhöht ". Auch hier ging es um Fragen, aber trotzdem danke. - Caderade
Der RFC macht absolut klar, dass TCP für DNS unterstützt werden muss, und es diskutiert die Verwendung von TCP durch Clients. Zum Beispiel, "Clients, die TCP für DNS verwenden, müssen immer bereit sein, Verbindungen wiederherzustellen oder ausstehende Abfragen erneut zu versuchen." - Ron Maupin
Guter Punkt. Ich würde sagen, dass der Kommentar in Anbetracht der zusätzlichen Klarheit hilfreich war. Mein Punkt ist, ich habe tatsächlich den RFC gelesen, und es war mir immer noch nicht klar, dass Abfragen mit TCP beginnen könnten. Wenn Sie also einfach den RFC für eine Antwort ausgeben, war das nicht sehr hilfreich. Es liest sich für mich, Abfragen gehen über UDP und wenn die Antwort zu groß ist, würde der DNS-Server den Client wissen lassen, dass es dies alles über TCP starten und ausführen muss. Also dachte ich, ich würde meine ursprüngliche Anforderung immer noch erfüllen, weil ich die ursprüngliche Anfrage erfasst hätte. Egal, ich schätze Ihre Eingabe. - Caderade
Das INTERNET STANDARD RFC ist tools.ietf.org/html/rfc1034. Du zitierst ein PROPOSED STANDARD TCP benötigen. - AbraCadaver
Das ist ein Standards Track RFC, der einen früheren Standards Track RFC über die gleiche Sache aktualisiert hat. Diese Antwort hier weiter Serverfehler erklärt solche Dinge. Sogar in dem Dokument, auf das Sie verweisen, heißt es: "Im Internet werden Abfragen in UDP-Datagrammen oder über TCP-Verbindungen übertragen."RFC 7766 soll klarstellen, dass TCP ein erforderlicher und nicht ein optionaler Bestandteil von DNS ist. - Ron Maupin


Sie sollten TCP / 53 nicht in irgendeine Richtung filtern. Zum Beispiel, nsupdate Abfragen können TCP verwenden, sobald die Anfrage zu groß ist (was schnell passieren kann). Sie sollten also UDP und TCP für Port 53 (in IPv4 & V6!) In alle Richtungen fließen lassen.

Außerdem wird mehr und mehr auf DNS über TLS hingearbeitet, so dass TCP in beiden Richtungen benötigt wird. Siehe RFC7858.


3
2018-03-23 22:46



Frage hat nichts mit Filtern zu tun, und deine Antwort fügt nichts über die anderen Antworten hinzu - Bryan
@ Bryan danke für deinen sehr hilfreichen und nützlichen Kommentar! - Patrick Mevzek
@PatrickMevzek Verstanden - was ich sagen wollte, ist, dass wir nur den Verkehr zu bestimmten IP-Adressen jenseits unseres Umfangs über Port 53 erlauben (TCP und UDP sind jedoch erlaubt). - Caderade