DNS ist ein grundlegendes Protokoll, das es Anwendungen wie Webbrowsern ermöglicht, basierend auf Domänennamen zu arbeiten.
Dabei ist es jedoch nicht vorgesehen, das DNS für Befehlskanäle oder Allzwecktunnelbau verwendet wird. Es wurden jedoch mehrere Hilfsprogramme entwickelt, um Tunneling über DNS zu ermöglichen. Da es allerdings nicht für den allgemeinen Datentransfer gedacht ist, legt DNS weniger Wert auf Sicherheitsüberwachung als andere Protokolle. Dadurch stellt DNS-Tunneling, falls es unentdeckt bleiben sollte, ein erhebliches Sicherheitsrisiko für Unternehmen da.
Dieser Text gibt einen Überblick über DNS-Tunneling-Dienstprogramme und Techniken zur Erkennung von DNS-Tunneling. Zwei Kategorien der Erkennung werden dabei genauer behandelt: Nutzlastanalyse und Verkehrsanalyse. Die Nutzlastanalyse wird dazu verwendet, um bestimmte DNS-Tunneling-Dienstprogramme erfolgreich zu identifizieren. Die Verkehrsanalyse hingegen kann zur universellen Erkennung von DNS-Tunneling verwendet werden. Mithilfe dieser Erkennungstechniken können Unternehmen das damit verbundene Risiko reduzieren.
Das Domain Name System (DNS) ist ein wichtiges Protokoll, das beim Surfen im Internet und bei E-Mails verwendet wird, damit diese Anwendungen anstelle von IP-Adressen Namen wie example.com verwenden können. Da das Protokoll nicht für den Datentransfer bestimmt ist, kann DNS als Bedrohung für böswillige Kommunikation oder für die Datenexfiltration übersehen werden.
Die meisten Unternehmen sind auch heute noch, wenn es um DNS-Angriffe geht, mangelhaft aufgestellt. Viele Unternehmen haben wenig oder keine
Überwachung Ihres DNS-Protokolls. Stattdessen konzentrieren sie Ressourcen auf den Web- oder E-Mail-Verkehr, da diese Ziele häufiger als Angriffsvektor genutzt werden.
Es gibt eine Reihe von Tools für Tunneling über DNS, die in diesem Text besprochen werden. Eine große Motivation für die Benutzung diese Tools ist der kostenlose Wi-Fi-Zugang für Standorte mit einem firmeneigenen Portal für http uns sogenannten „Free Flowing DNS“. Diese Tools können allerdings auch für missbräuchliche Zwecke verwendet werden. Denn ein DNS-Tunnel kann als vollständiger Fernsteuerungskanal für einen kompromittierten internen Host verwendet werden. Damit können dann OS Befehle oder Dateiübertragungen ausgeführt werden und in manchen Fällen kann sogar ein vollständiger IP-Tunnel aufgebaut werden. Die Gefahr dieser Tools besteht darin, dass diese auch missbräuchlich verwendet werden, um über einen verdeckten Kanal Malware in ein System einzuschleusen. Feederbot ist ein solches Tool, um DNS als Kommunikationsmethode zu verwenden.
DNS-Tunneling stellt eine erhebliche Bedrohung dar, aber es gibt Methoden, diese potenziellen Bedrohungen frühzeitig zu erkennen. DNS Tunnel können durch die Analyse einer einzelnen DNS-Nutzlast oder durch Verkehrsanalyse erkannt werden, indem man die Anzahl und Häufigkeit der Anfragen analysiert. Die Nutzlastanalyse wird zur Erkennung bösartiger Aktivität, die auf Grundlage einer einzigen Anfrage basieren, verwendet. Attribute einer Anfrage wie Domänenlänge, Anzahl von Bytes und Inhalten können dabei zur Erstellung von sogenannten Erkennungsregeln verwendet werden. Das Erkennen ungewöhnlicher Datensatz-Typen wie TXT können ebenfalls dazu verwendet werden. Eine weitere Methode zur frühzeitigen Erkennung ist die Verkehrsanalyse.
Dabei arbeitet die Verkehrsanalyse auf Grundlage, mehrere Anfragen und dem gesamten Traffic, um böswillige Aktivitäten zu erkennen. Zu den Attributen, die für die Verkehrsanalyse verwendet werden können, gehört das Volumen des DNS-Verkehrs, die Anzahl der Hostnamen pro Domain, geografischer Standort und Domain-Historie.
Das Domain Name System (DNS) ist ein kritisches Protokoll und Dienst, das im Internet verwendet wird. Die grundlegende Funktion von DNS ist die Zuordnung von Domänennamen zu IP-Adressen. So können Benutzer einen Domänennamen (z. B. example.com) in ihrem Webbrowser eingeben, woraufhin DNS eine Vorwärtssuche durchführt, um eine oder mehrere IP-Adressen für diesen Domänennamen zu finden. Dies wird als “A”-Eintrag bezeichnet. Der Netzwerkstapel des Benutzers kann dann http-Verkehr an die Ziel-IP-Adresse senden. Das DNS-Protokoll wird ständig verbessert, um neue Funktionen bereitzustellen und zu ermöglichen. Obwohl es frühere RFCs gibt, ist die Kernfunktionalität des DNS in den RFCs 1034 und 1035 definiert. Es gibt über 20 weitere RFCs, die zusätzliche Funktionalitäten für DNS beschreiben.
DNS verfügt über mehr als 30 Eintragsarten, wobei viele der üblichen Eintragsarten entscheidend sind, um zentrale Internet-Dienste bereitzustellen. Wie bereits erwähnt, bildet der “A”-Eintragstyp einen Domänennamen auf eine IPv4-Adresse ab. Der “AAAA”-Datensatz wird verwendet, um eine Domäne auf eine IPv6-Adresse abzubilden. Der “CNAME”-Eintragstyp wird verwendet, um einen Domänennamen auf den kanonischen Namen abzubilden. Der „MX”-Datensatztyp wird verwendet, um Mail-Server für eine Domäne zu definieren. Der “NS”-Eintragstyp wird verwendet, um autoritative Nameserver für eine Domäne zu definieren. Der “PTR”- oder Zeigerdatensatz wird häufig verwendet, um eine IP-Adresse ihrem Domänennamen zuzuordnen. Dies wird allgemein als Reverse-Lookup bezeichnet. Der Satztyp “TXT” wird zur Rückgabe von Textdaten verwendet. Dieser Datensatztyp wurde für spezifische Zwecke, wie das Sender Policy Framework (SPF) für Anti-Spam entwickelt.
DNS verwendet für die Kommunikation sowohl den UDP-Server-Port 53 als auch den TCP-Server-Port 53. Standardmäßig wird allerdings UDP verwendet, allerdings wird TCP für Zonentransfers oder bei Nutzlasten über 512 Bytes verwendet. Es gibt auch das sogenannte „Extension Mechanisms for DNS“, kurz EDNS. Wenn EDNS von beiden Hosts in einer DNS-Kommunikation unterstützt wird, dann können UDP-Nutzlasten, die größer sind als 512 Bytes verwendet werden. EDNS ist eine Funktion, die genutzt werden kann, um die Bandbreite für DNS-Tunneling zu verbessern.
DNS ist ein hierarchisches System; jede Ebene in der Hierarchie kann durch einen anderen Server mit anderen Besitzverhältnissen bereitgestellt werden. Für das Internet gibt es 13 Root-DNS-Server, die von „A“ bis „M” gekennzeichnet sind. Diese werden allerdings durch weit mehr als 13 physische Server repräsentiert. Die hierarchische Natur des DNS kann an einem Beispiel erläutert werden. Nehmen wir an, es wird eine Anfrage für die IP-Adresse einer Domäne mit dem Namen my.test.example.com. gestellt. Eine Anfrage wird zunächst zu den Root-Servern weitergeleitet, um herauszufinden, welcher Server die Top-Level-Domain .com kontrolliert. Der .com-Server stellt den Server bereit, der die example.com Domäne steuert. Als Nächstes stellt der example.com-DNS-Server Informationen über den Server, der die Domäne test.example.com steuert, bereit. Schließlich stellt der DNS-Server test.example.com die IP-Adresse für my.test.example.com zur Verfügung.
Mit diesem hierarchischen System kann ein Domänenbesitzer die Server für ihre Domäne definieren. Das bedeutet, dass sie die Kontrolle über das Endziel der Hosts für DNS-Abfragen auf ihre Domäne haben. In einem Unternehmen machen Endpoints niemals direkt DNS-Anfragen an das Internet. Dafür stehen interne DNS-Server bereit, die DNS Dienste für einen Endpoint bereitstellen. Da DNS die Anfragen jedoch weiterleitet, bis ein autoritativer Nameserver kontaktiert wird, kann ein Angreifer, der sich Zugang auf einen internen Endpoint verschafft hat, die unternehmenseigene DNS-Infrastruktur dazu ausnutzen, um einen DNS-Tunnel zu einer vom Unternehmen kontrollierten Domäne aufzubauen.
Dabei muss man bedenken, dass DNS Cashing betreibt. Wenn DNS-Antworten bereitgestellt werden, wird Time to Live (TTL) mit bereitgestellt. Der empfangende Zwischenserver kann für den Wert dieser Zeitspanne das Ergebnis in einem Cash zwischenspeichern. Wenn dann eine identische Anfrage eintrifft, kann das zwischengespeicherte Ergebnis zur Verfügung gestellt werden, und es muss keine erneute Suche durchgeführt werden.
Viele der Werkzeuge zur Erstellung von DNS-Tunneln wurden mit der Absicht entwickelt,
Portale für kostenpflichtige Wi-Fi-Dienste zu umgehen. Wenn eines dieser Systeme ausgehenden DNS-Verkehr erlaubt, kann ein DNS-Tunnel eingerichtet werden, der den IP-Verkehr tunnelt, damit man den Dienst kostenlos nutzen kann.
Einige der DNS-Tunnel-Dienstprogramme erstellen eine Tun- oder Tap-Schnittstelle lokal auf den Endpoint Systemen. Es wird auch ein Tun- oder Tap-Gerät auf dem DNS-Server erstellt, der das DNS-Tunneling-Werkzeug hostet. Dies ermöglicht es dem Benutzer, IP-Verkehr ins Internet zu tunneln. Dieses Technik kann mit der Funktionsweise von VPN-Software wie z. B. OpenVPN verglichen werden. Es gibt sogar kommerzielle Anbieter, die einen serverseitigen Tunnel als Dienstleistung anbieten und diese Dienstleistung als “VPN über DNS“ vermarkten. Der Benutzer kann sich mithilfe solcher Software auf den Server des Dienstleisters verbinden, auf dem dann anschließend das serverseitige Tunneling läuft.
Diese Dienste stehen mittlerweile für verschieden Betriebssysteme z Verfügung, darunter auch z. B. Android. Es ist bekannt, dass in manchen Angriffen solche Tunneling-Sotware (z. B. Iodine) verwendet wurde.
Seit Ende der 90er wurden eine Reihe von DNS-Tunneling-Programme entwickelt. Alle Programme verwenden dabei ähnliche Techniken, haben aber Variationen bei der Codierung und anderen Implementierungsdetails. Die Kerntechniken, die von allen DNS-Tunneling-Dienstprogrammen verwendet werden, umfassen eine kontrollierte Domäne oder Subdomäne, eine serverseitige Komponente, eine clientseitige Komponente und in DNS-Nutzlasten codierte Daten. Die kontrollierte Domäne wird verwendet, um den autorisierenden Nameserver für diese Domäne bzw. Unterdomäne zu definieren. Die serverseitige Komponente wird als DNS-Tunnelserver bezeichnet. Der DNS-Tunnelserver ist der autorisierender Nameserver für die kontrollierte Domäne. Er ist typischerweise ein über das Internet zugänglicher Server, der vom User kontrolliert wird. Die clientseitige Komponente beherbergt das andere Ende des Tunnels. Dies könnte z. B. ein Endpoint in einer sicherheitskontrollierten Unternehmensumgebung sein. Der Tunnel ermöglicht die Kommunikation zwischen dem kontrollierten Endpoint und einem beliebigen Host im Internet. Die clientseitige Komponente initiiert eine DNS-Anfrage, für die der DNS-Tunneling-Server die Rolle des Nameserver übernimmt.
Eine der Kerntechniken der Tunnelingprogramme ist die Codierung von Daten in “DNS-Payloads“. Von einem stark vereinfachten Standpunkt aus betrachtet, möchte ein Client Daten an den Server senden. Dabei werden diese Daten in dem „DNS-Payload“ codieren. Ein Beispiel: Der Kunde könnte eine „A-Datensatzanforderung“ senden, wobei die Daten im Host
MRZGS3TLEBWWW64TFEBXXMYLMO RUW4ZI.t.example.com codiert sind. Der Server
könnte mit einer CNAME-Response antworten: NVWW2IDPOZQWY5DJNZZSQ.t. beispiel.com. Auf diese Weise können beliebige Daten verschlüsselt werden und an den Server gesendet werden. Der Server kann auch mit Daten antworten. Wenn ein Bedarf besteht, für den Server eine Kommunikation zu initiieren, kann dies allerdings nicht direkt erfolgen. Clients haben keine
Dienste, der auf DNS-Anfragen lauscht, außerdem befinden sie sich in der Regel hinter einer Firewall. Eine vom Server initiiert Kommunikation kann jedoch dadurch erreicht werden, dass der Client regelmäßige Anfragen an den Server stellt. Wenn der Server dann Daten für den Client hat, kann er diese als Antwort auf die Anfrage senden. Wie bereits erwähnt, unterscheiden sich die verschiedenen DNS-Tunneling-Dienstprogramme in ihren Implementierungsdetails.
DNS-Dienstprogramme unterscheiden sich in der Implementierungssprache, wobei die Werkzeuge z. B. mit C, Java, Perl und Python, um nur einige zu nennen, implementiert werden. Einige Dienstprogramme verwenden einen „Tun oder Tap“, um eine lokale Schnittstelle und IP-Adresse für den Tunnel auf den Hosts zu erstellen. Andere tunneln nur die binären Daten, die ähnlich wie Netcat verwendet werden können, um Betriebssystembefehle zu erteilen und Dateien zu übertragen. Die Codierungsmethode – einschließlich des DNS-Eintragstyps – ist ein Bereich, in dem sich die verschiedenen Tools grundlegend unterscheiden. Einige Dienstprogramme verwenden gemeinsame Datensatztypen wie z. B. „A“-Datensätze.
Andere verwenden experimentelle Datentypen wie „Null’-Datensätze und EDNS, um die Leistung zu verbessern.
Für Anfragen vom Client wird üblicherweise eine Base32- oder 5-Bit-Codierung verwendet. Obwohl DNS-Namen Groß- und Kleinbuchstaben haben, ist diese zu ignorieren, sodass
26 Buchstaben zur Verfügung stehen. Zusätzlich sind Zahlen und das Zeichen “-“ erlaubt. Dies ergibt insgesamt 37 eindeutigen Zeichen. Daher können wir Daten in 5 Bits Schritten aufnehmen, was uns 32 mögliche Werte liefert. Diese 32 Werte passen in unsere 37 verfügbaren Zeichen. Wir können dann aus den codierten Daten eine Reihe von verschachtelten Unterdomänen aufbauen. Dabei erlaubt uns DNS bis zu 255 Zeichen, wobei jede Unterdomäne (aka Label) 63 Zeichen oder weniger beinhaltet.
Base64- oder 6-Bit-Codierung kann für die Antworten von „TXT“-Datensätzen verwendet werden. Ein “TXT”-Datensatz kann Groß- und Kleinbuchstaben haben, was 52 Zeichen ergibt. Die Ziffern 0-9 bringen uns 10 weitere. Wenn wir zwei zusätzliche Zeichen wie “-” und “+” betrachten, dann kommen wir auf 64 eindeutige Werte, die für die Base64-Codierung verwendet werden können. Ähnlich wie bei der Base32-Codierung können Anfrage mit 6 Bit auf einmal codiert und gesendet werden.
Hex-Codierung ist eine weitere Codierungsmethode. Bei der Hex-Codierung werden die beiden
Hex-Werte der Zeichen verwendet, um jedes Byte darzustellen. Diese Methode wird nur von DNScat-B verwendet.
Die Dienstprogramme für das DNS-Tunneling können verschiedene DNS-Eintragstypen und Codierungsmethoden verwenden. In einigen Fällen, wie z. B. bei Jod erkennt das Dienstprogramm automatisch die bestmögliche Codierung. Es gibt eine Reihe weiterer Implementierungstechniken, die eine Erwähnung verdienen. DNS-Tunneling-Dienstprogramme können EDNS verwenden, das ihnen die Verwendung von Nutzlasten ermöglicht, die die 512 Bytes Grenze überschreiten, wodurch die Leistung verbessert wird. Ein weiteres Dienstprogramm für DNS-Tunneling,
Heyoka fälscht die Quell-IP-Adressen für Anfragen an den Server (Upstream-Daten), um die Sichtbarkeit des Kunden zu verringern.
Es gibt eine Reihe verschiedener Dienstprogramme für das DNS-Tunneling. Im Folgenden findet sich eine Übersicht.
DeNiSe ist ein Proof-of-Concept für das Tunneling von TCP über DNS in Python. Die Github Seite für DeNiSe hat sechs Python-Skripte aus den Jahren 2002 bis 2006.
Viele der DNS-Tunneling-Programme versuchen nicht nicht anzufallen. Sie verlassen sich auf die Tatsache, dass DNS oft nicht überwacht wird. Es gibt verschiedene DNS-Tunnelerkennungstechniken, die als zwei separate Kategorien in diesem Text besprochen (die Payload-Analyse und die Traffic-Analyse). Bei der Payload-Analyse wird die DNS-Nutzlast für Anfragen und Antworten auf Tunnelindikatoren analysiert. Für die Traffic-Analyse wird der Verkehr im Laufe der Zeit analysiert. Die Anzahl Häufigkeit und andere Request-Attribute wird dabei in Betracht gezogen.
Eine Technik besteht darin, die Größe der Anfrage und der Antwort zu analysieren. Dies wird zur Identifizierung von verdächtigem DNS-Tunneling Verkehr basierend auf dem Verhältnis von Quell- und Zielbytes verwendet. DNS-Daten, die in einer MySQL-Datenbank als Teil eines Snort/Squil Intrusion Detecion Systems liegen, werden abgefragt nach Quell- und Ziel-Bytes. Das Verhältnis wird dann mit einem Grenzwert verglichen.
Es ist auch möglich, die Länge der DNS-Abfragen und -Antworten zur Erkennung von Tunneling zu verwenden. Dienstprogramme für DNS-Tunneling versuchen normalerweise so viele Daten in Anfragen und Antworten zu verpacken wie möglich. Daher ist es wahrscheinlich, dass Tunneling Anfragen, lange Etiketten mit bis zu 63 Zeichen und lange Gesamtnamen mit bis zu 255 Zeichen haben. Eine weitere Empfehlung ist es, alle Hostnamen-Anfragen zu prüfen, die eine Länge von 52 Zeichen überschreiten.
Die Betrachtung des spezifischen Zeichenaufbaus von DNS-Namen ist eine weitere Methode, die
verwendet werden kann, um Tunneling zu erkennen. Legitime DNS-Namen haben in der Regel nur wenige Ziffern, während verschlüsselte Namen üblicherweise viele Ziffern beinhalten. Dabei betrachtet man den Prozentsatz der numerischen Zeichen in Domänennamen. Die Betrachtung der Länge der längsten bedeutungsvollen Zeichenfolge (Longest Meaningful Substring, LMS) sowie der Anzahl der eindeutigen Zeichen ist eine weitere Methode. Es wird empfohlen, bei allen Anfragen mit mehr als 27 eindeutigen Zeichen vorsichtig zu sein. Angesichts der Tatsache, dass legitime Domänennamen bis zu einem gewissen Grad gemeinsame Sprachen widerspiegeln, könnte auch die Verwendung der Zeichenhäufigkeitsanalyse zur Ermittlung von Namen verwendet werden. Dabei können wiederholte Konsonanten betrachtet werden, um DNS-Tunneling zu erkennen. So kann ein Tunneling-Programm Domänen mit aufeinanderfolgenden Konsonanten und Zahlen erstellen, das durch einen flüchtigen Blick nicht von einem Original zu unterscheiden ist.
In einigen Fällen haben Forscher Signaturen für bestimmte DNS-Tunneling-Tools bereitgestellt. Eine Signatur kann verwendet werden, um bestimmte Attribute in einem DNS-Header zu überprüfen und auf bestimmte Inhalte in der Nutzdatenbank zu prüfen. Beispielsweise wurde eine Snort-Signatur zur Erkennung von NSTX-DNS-Tunneling entwickelt.
alert udp $EXTERNAL_NET any -> $HOME_NET 53 (msg:”Potential NSTX DNS Tunneling”; content:”|01 00|”; offset:2; within:4; content:”cT”; offset:12; depth:3; content:”|00 10 00 01|”; within:255; classtype:badunknown; sid:1000 2;)
Im obigen Beispiel sind die wesentlichen Teile dieser Regel wie folgt aufgebaut. Diese Unterschrift hat drei inhaltliche Übereinstimmungen. Der Offset 2 überspringt den ID-Teil des DNS-Headers, der die ersten beiden Bytes repräsentiert. Die nächsten zwei Bytes stellen mehrere Header-Attribute dar. Bei der Hexadezimalzahl “01“ sind die Bits 0 bis 6 “0“ und Bit 7 “1“. Dies entspricht einer DNS-Abfrage keiner Antwort. Zusätzlich sind die 4 Opcode-Bits 0, was bedeutet, dass es sich um eine Standardabfrage handelt. Die 1 in Bit 7 zeigt an, dass eine Rekursion erwünscht ist. Die nächste inhaltliche Übereinstimmung beginnt mit “Offset 12“. Dieser ist der Anfang des Fragenabschnitts bzw. Des QNAME Feldes. Daher sucht dieser “Content Match“ nach “cT“ als Teil der ersten 3 Bytes des Domainnamens. Bei der letzten Inhaltsübereinstimmung wird nach den Hex-Werten „00 10 00 01“ innerhalb der ersten 255 Bytes gesucht. Dies entspricht den zwei Bytes der QTYPE- und QLASS-Teile des Fragenabschnitts, wenn der QTYPE hexadezimal 10 (dezimal 16) und die QCLASS 1 ist, was dem IN für das Internet entspricht. IN ist die einzige gebräuchliche QCLASS, daher wird es immer mit der „00 01“ übereinstimmen. Ein QTYPE von dezimal 16 entspricht dem TXT-Datensatztyp. Zusammenfassend lässt sich sagen, dass diese Signatur nach einer Standard-DNS-Abfrage für einen TXT-Ressourceneintrag mit dem Text „cT” am Anfang der Domäne sucht.
Mithilfe einer Visualisierung können DNS-Tunneln erkannt werden, allerdings erfordert diese Methode die interaktive Arbeit eines Analytikers. Mithilfe dieser Methode sticht der getunnelte Verkehr aber dramatisch hervor.
Während die meisten Erkennungsmethoden auf das schauen, was wir einsehen können, ist ein anderer Ansatz der Blick für das, was wir erwarten, ohne das es bis jetzt eingetroffen ist. Bei Berechnungen wird eine DNS-Anfrage nach der anderen ausgeführt, zum Beispiel bei einer Webseitenanfrage über http. Eine andere Erkennungsmethode ist es, nach DNS-Anfragen zu suchen, die keine entsprechende Anfrage durch eine Anwendung wie http haben. Hierbei wird es Ausnahmen geben, die allerdings leicht herausgefiltert werden können. Sicherheitsvorrichtungen können Reverse-Lookups von IP-Adressen durchführen. Anti-Spam-Lösungen verwenden DNS-Abfragen, um zu prüfen, ob eine bestimmte IP-Adresse auf einer Black List steht. Eine
Endgerätesicherheitsprodukt verwendet DNS-Abfragen mit einem verschlüsselten Dateien-Hash, der in die FQDN verankert ist, um verdächtige Dateien zu überprüfen.
Bei der Umsetzung von Nachweismechanismen müssen die Methoden auf Kosten und Wirksamkeit abgewogen werden. Die Kosten beinhaltet vor allem harte Kosten, wie die Beschaffung von Erkennungssystemen, Zeit für die Entwicklung von Unterschriften und Computer-Ressourcen. Dieses Systeme werden allgemein als CAP (Capture And Parse) bezeichnet. Das System erfasst den Netzwerkverkehr durch die Verwendung eines TAP oder Span-Port.
Der erfasste Datenverkehr wird für mehrere Protokolle einschließlich DNS geparst. Die geparsten Metadaten können dann interaktiv mit einer einfachen Regelsprache abgefragt werden. Eine Berichtsfunktion steht dabei ebenfalls zur Verfügung, die in der Regel für die tägliche Berichterstattung über den Traffic verwendet wird, der bestimmten Regeln entspricht. Zusätzlich zu den integrierten Funktionen ist eine Anwendungsprogramm-Schnittstelle (API) verfügbar für direkten Zugriff auf die Daten.
Defense in Depth ist eine Sicherheitsstrategie, bei der es mehrere Sicherheitsebenen gibt. Wenn es einer Schicht nicht gelingt, böswillige Aktivitäten zu erkennen, ist eine andere Schicht vorhanden, die diese ebenfalls erkennt. Durch Umsetzung von Regeln unter Verwendung der Nutzlastanalyse und der Verkehrsanalyse wird ein gewisser Schutz in der Tiefe gewährt.
DNScat-P verwendet die Basis-64-Codierung, dabei verwendet es sowohl Großbuchstaben als auch Kleinbuchstaben und sowie das “-” und “_” im FQDN. Ein Blick auf den Quellcode
“SixBitDNSEncoder.java” zeigt an, dass “längere Namen durch Punkte getrennt werden. Die Klasse fügt auch die codierte Rahmenlänge hinzu (die erste Zeichen) und auch “NAMELEN = 30“. Dies wurde im DNScat-P-Verkehr beobachtet. Das erste Label ist 31 Zeichen lang, die folgenden sind 30 Zeichen lang. Es befinden sich je nach Datengröße bis zu sieben Label dort. Zur Anpassung des DNScat-P-Datenverkehrs wird die folgende Regel wird angewendet:
alias.host regex ‚^[a-zA-Z-]{31,31}[[.period.]][a-zA-Z]{30,30}[[.period.]]’
Das Schlüsselwort “alias.host” ist der Name, den das CAP-System für den FQDN verwendet. Das Zeichen “^” ist ein Indikator, der mit dem Anfang des FQDN übereinstimmen muss. Das Zeichen „[a-zA-Z-]{31,31}” passt auf eine Zeichenfolge, die eines der Zeichen a bis z oder A bis Z oder “-” verwendet und 31 Zeichen lang ist. Das “[[.period.]]” stimmt mit dem Zeichen “.-” überein. Das „[a-zA-Z-]{30,30}” passt auf eine Zeichenfolge, die eines der Zeichen a bis z oder A bis Z oder “-” verwendet und 31 Zeichen lang ist. Diese Signatur entspricht einem FQDN, wobei das erste Label 31 Zeichen lang und das zweite Label 30 Zeichen lang
Viele der DNS-Tunneling-Tools führen eine Abfrage durch. Normalerweise kann der Server nicht den Kunden direkt kontaktieren. Der Client fragt daher den Server regelmäßig ab. Wenn der Server Daten an den Client zu senden hat, können diese als Antwort auf die Abfrage gesendet werden. Basierend auf Beobachtung beginnt die DNScat-P-Abfrage mit einem Buchstabenzeichen, gefolgt von einem Bindestrich “-“, gefolgt von sechs Buchstabenzeichen. Die Zeichen können Groß- oder Kleinbuchstaben sein. Daher wird mit DNScat-P die folgende Regel verwendet:
alias.host regex ‘^a-[a-zA-Z0-9]{6,6}[[.period.]]’
Das Schlüsselwort “alias.host” ist der Name, den das CAP-System für den FQDN verwendet.
Das Zeichen “^” ist ein Indikator, das mit dem Anfang des FQDN übereinstimmen muss. Die restlichen Teile “a-[a-zA-Z]{6,6}[[[.period.]” wird verwendet, um dem Buchstaben “a gefolgt von einem Bindestrich” zu entsprechen, daraufhin von sechs Buchstaben, dann ein „.”.
Es gibt Variationen im Aufbau des FQDN in Abhängigkeit von den Modus (Datagramm oder Stream) und ob eine Sitzung verwendet wird oder nicht. Das Make-up für eine der Datagramm-Modus ohne eine Sitzung sieht folgendermaßen aus:
“…..”
Für diese Regel werden wir uns auf das Signatur-Element konzentrieren. Dieses Element ist in allen FQDNs vorhanden, die von DNScat-B generiert werden. Standardmäßig ist er auf “dnscat“ eingestellt, obwohl er leicht mit dem Befehl“signature“ geändert werden kann.. Um FQDNs abzugleichen, die mit dnscat beginnen, müssen die folgenden Regel verwendet wird:
alias.host begins’dnscat’
Das Schlüsselwort “alias.host” ist der Name, den das CAP-System für den FQDN verwendet. Das Schlüsselwort “begins” bedeutet, dass wir nach jedem alias.host suchen wollen, der mit der darauffolgende Zeichenfolge beginnt. Der “dnscat”-Teil der Regel zeigt an, dass der alias.host mit der Zeichenfolge “dnscat“ beginnen muss.
Das Dienstprogramm DNScat-B verwendet standardmäßig die NetBIOS-Kodierung. Mit dieser Codierung wird “jedes Zeichen im Bereich von “A” bis “O” liegen”. Wenn DNScatB Daten überträgt, gibt es standardmäßig Domain-Labels der Länge 63, die geändert werden können,
unter Verwendung der Befehlszeilenoption -chunksize. Standardmäßig werden 3 Labels für Daten verwendet, die mithilfe der Befehlszeilenoption -sections geändert werden kann. Mit der folgenden Regel erkennt NetBIOS codierten Datenverkehr, der nach dem Datenteil des FQDN sucht:
alias.host regex ‚[[.period.]][a-o]{50,63}[[.period.]][a-o]{50,63}[[.period.]]’
Das Schlüsselwort “alias.host” ist der Name, den das CAP-System für den FQDN verwendet. Der Teil “[[.period.]]” entspricht dem Zeichen “.“ .Der Teil “[a-o]{50,63}” sucht nach einer Zeichenkette mit einem der Zeichen a bis o, die 50 bis 63 Zeichen lang ist.
Das Dienstprogramm DNScat-B verwendet standardmäßig die NetBIOS-Kodierung. Mit dieser Codierung wird “jedes Zeichen im Bereich von “A” bis “O” liegen”. Wenn DNScatB Daten überträgt, gibt es standardmäßig Domain-Labels der Länge 63, die geändert werden können,
unter Verwendung der Befehlszeilenoption -chunksize. Standardmäßig werden 3 Labels für Daten verwendet, die mithilfe der Befehlszeilenoption -sections geändert werden kann. Mit der folgenden Regel erkennt NetBIOS codierten Datenverkehr, der nach dem Datenteil des FQDN sucht:
alias.host regex ‚[[.period.]][a-o]{50,63}[[.period.]][a-o]{50,63}[[.period.]]’
Das Schlüsselwort “alias.host” ist der Name, den das CAP-System für den FQDN verwendet. Der Teil “[[.period.]]” entspricht dem Zeichen “.“ .Der Teil “[a-o]{50,63}” sucht nach einer Zeichenkette mit einem der Zeichen a bis o, die 50 bis 63 Zeichen lang ist.
Das Dienstprogramm DNScat-B verwendet standardmäßig die NetBIOS-Kodierung. Mit dieser Codierung wird “jedes Zeichen im Bereich von “A” bis “O” liegen”. Wenn DNScatB Daten überträgt, gibt es standardmäßig Domain-Labels der Länge 63, die geändert werden können,
unter Verwendung der Befehlszeilenoption -chunksize. Standardmäßig werden 3 Labels für Daten verwendet, die mithilfe der Befehlszeilenoption -sections geändert werden kann. Mit der folgenden Regel erkennt NetBIOS codierten Datenverkehr, der nach dem Datenteil des FQDN sucht:
alias.host regex ‚[[.period.]][a-o]{50,63}[[.period.]][a-o]{50,63}[[.period.]]’
Das Schlüsselwort “alias.host” ist der Name, den das CAP-System für den FQDN verwendet. Der Teil “[[.period.]]” entspricht dem Zeichen “.“ .Der Teil “[a-o]{50,63}” sucht nach einer Zeichenkette mit einem der Zeichen a bis o, die 50 bis 63 Zeichen lang ist.
Einige der spezifischen Regeln zur Nutzlastanalyse können durch eine sachkundigen Angreifer umgangen werden. Sie könnten die verwendeten Labels kürzen, um die Anzahl der Labels in einem FQDN zu verringern. Sie müssen jedoch immer eine große Anzahl von eindeutigen FQDNs, die normalerweise aus einer bestimmten Root-Domäne stammen, erstellen. Die Root-Domäne sind die beiden rechtesten Label, nämlich die “Second Layer Domain“ und die “Top Level Domain. Für die FQDN “www.example.com“ ist die Root Domäne “example.com”. Es ist auch möglich, mehrere Root Domänen für das Tunneln zu verwenden, allerdings führt dies noch zu einer großen Anzahl von FQDNs pro Root Domäne.
Daher ist die Erkennung der Anzahl der FQDNs pro Root-Domain eine sehr wichtig. Das verwendete CAP-System bietet keine Methode zum Berichten über die Anzahl der FQDNs pro Root-Domain. Es hat jedoch eine
Anwendungsprogramm-Schnittstelle oder API, die für den Zugriff auf die gespeicherten Daten verwendet werden kann und die gewünschte Regel erstellen kann.
Die mit der API entwickelte Verkehrsanalyseregel ist ein mehrstufiger Prozess.
Diese Schritte sind alle in einem Python-Skript enthalten, das DNS-Daten sammelt und analysiert.
Zuerst wird über die API auf DNS-Daten für ein bestimmtes Zeitfenster zugegriffen und als xml-Datei gespeichert. Zweitens wird die Xml-Datei bereinigt, um den Import vorzubereiten. Drittens wird die Xml-Datei in MySQL importiert. Viertens werden die Daten mit Python und MySQL analysiert, um die Top-Zahlen der eindeutigen FQDNs pro Root-Domain zu finden.
Schritt 1: Die wichtigsten Teile dieses Schrittes sind die Abfrage zur Datenauswahl und der Ausgabetyp. Diese Zeile (Hinweis: Zeile wird umgebrochen) zeigt die Datenauswahl:
qstring = “select time, ip.src, ip.dst, alias.host where service=’53’ && monitor=’external’ && time=’” + texttimestart + “‘-‘” + texttimeend+”‘ && tld != ‚arpa’”
Zeit, Quell-IP-Adresse, Ziel-IP-Adresse und FQDN werden für DNS-Verkehr über eine bestimmte Zeitspanne ausgewählt. Nur externe DNS-Abfragen werden berücksichtigt, um den
Umfang der Verarbeitung zu verringern. Domains, die auf “.arpa“ enden, werden ausgeschlossen, um Reverse Lookups zu verhindern.
Die nächsten beiden Zeilen zeigen den Abfrage- und Ausgabetyp.
ctype=„text/xml”
nwquery = nwmodule.nwQuery(0, 0, qstring, ctype, 1000000)
Das Ausgabeformat xml. Der nächste Schritt ist der Cleanup der Xml.
Schritt 2: Die Xml-Ausgabe ist nicht für den Import in Xml bereit. Eines der Felder verwendet
der Name “group“, welches in MySQL ein reserviertes Wort ist. “group“ für eine Spaltenüberschrift zu benutzen ist daher problematisch, weshalb wir sie in “session“ ändern müssen. Das zweite Problem ist, dass die letzten Daten nicht mit einem “Attribute Name” versehen sind. Der Cleanup wird am besten an einem Beispiel gezeigt. Für das Beispiel wird nur eine Zeile gezeigt. Eine Sitzung hat normalerweise zusätzliche Zeilen für Quell-IP, Ziel-IP und Zeit.
Zeile vor dem Cleanup:
Zeile nach dem Cleanup
Schritt 3: Sobald die Datei bereinigt ist, ist der Import in mysql relativ einfach. Die folgende Zeile wird verwendet:
LOAD XML INFILE ‘CAPexport.xml’ INTO TABLE dnsx rows identified by ‚’;
Nachdem der Import abgeschlossen ist, ist die Tabelle in mysql verfügbar. Beachten Sie, dass eine Sitzung mehrere Zeilen in der Tabelle hat und dass die Datenspalte verschiedene Arten von
Werte besitzt, wie Zeit, Quell-IP-Adresse, Ziel-IP-Adresse oder FQDN. Dabei sind oft mehrere FQDN-Zeilen vorhanden, wobei der FQDN immer wiederholt wird. Die Daten werden reorganisiert. wenn sie analysiert werden.
Schritt 4: Die Daten werden mit dem Python-Skript analysiert, um schließlich einen Bericht über Root-Domänen mit der höchsten Anzahl von eindeutigen FQDNs zu liefern. Dieser Schritt hat zwei Unterschritte.
Zum einen muss mit Hilfe einer Schleife, die auf verschiedenen Sitzungs-IDs ausgeführt wird. Für jede eindeutige Session ist eine Zeile in einer neuen Tabelle erstellt worden, die Spalten für jeden Datentyp enthält: Zeit, Quell-IP, Ziel IP und FQDN. Zusätzlich wird die Root-Domäne extrahiert und in einer eigenen Spalte hinzugefügt.
Als nächstes muss, ebenfalls mit der Hilfe einer Schleife die neuen Tabelle zu den verschiedenen Root-Domänen durchlaufen werden. Für jede Domäne wird eine Anzahl von eindeutige FQDNs gemeldet. Dies ist das gewünschte Endergebnis. Durch Betrachten der FQDN Zahlen, können DNS-Tunnel identifiziert werden, wenn eine sehr hohe Anzahl von eindeutigen FQDNs für
eine bestimmte Domäne existiert.
Es gibt eine große Anzahl von DNS-Tunneling-Tools mit einem breiten Spektrum an Fähigkeiten.
Sie bieten einen verborgenen Kanal für bösartige Aktivitäten, die eine erhebliche Bedrohung darstellen. Diese Bedrohungen können durch Nutzlastanalyse und Datenverkehr-Analysen gemildert werden.
Es gibt mehr als ein Dutzend verschiedene DNS-Tunneling-Dienstprogramme, die in diesem Text behandelt wurden. Sie reichen von Tools mit netcat-Ähnlichen Fähigkeiten bis hin zu vollständigem IP-Tunneling über DNS. Einige Tools sind bereits seit mehreren Jahren verfügbar, andere wurden erst kürzlich mit verbesserten Fähigkeiten entwickelt. Heyoka verwendet zum Beispiel Quell-Spoofing, um die Sichtbarkeit des kompromittierten Endpunkts zu verringern. Zusätzlich ist die DNS-Tunneling-Fähigkeit bequem als Teil des Penetrationstest-Tools Metasploit und Squeeza erhältlich.
DNS-Tunneling stellt eine erhebliche Bedrohung für Organisationen dar. Die beiden wichtigsten
Bedrohungen durch DNS-Tunneling sind die Kontrolle und Steuerung von kompromittierten Endpoints und Daten Exfiltration. Dabei können die Befehls- und Kontrollfunktionen auch vollständigen Fernzugriff eines kompromittierten Endpoints umfassen. Dies kann mit netcat-ähnlichen Funktionen erreicht werden, mit einige DNS-Tunneling-Dienstprogramme oder über eine beliebige Fernzugriffsanwendung über einen vollständigen IP-Tunnel.
Die andere Bedrohung ist die Datenexfiltration. DNS-Tunneling bietet einen verborgenen Kanal zur Daten Exfiltration. Obwohl für den Datentransfer ineffizient, kann DNS-Tunneling einfach verwendet werden, um sensible Daten wie Passwort-Hashes oder Dokumente zu exfiltrieren.
Die Bedrohung durch DNS-Tunneling kann durch eine implementierte Nutzlastanalyse und Verkehrsanalysetechnik abgeschwächt werden. Die Nutzlastanalyse kann zur Erkennung von DNS-Tunneling verwendet werden, indem Signaturen verwendet werden, die auf Attributen einzelner DNS-Nutzlasten wie dem FQDN basieren. Die Nutzlastanalyse ist am effektivsten zur Erkennung bekannter DNS-Tunneling-Dienstprogramme. Die Verkehrsanalyse kann verwendet werden, um DNS-Tunneling auf der Grundlage von Merkmalen des Gesamtverkehrs zu erkennen. Mithilfe der Verkehrsanalyse kann ein universeller DNS-Tunneling-Detektor implementiert werden. Dies wird erreicht durch die Überwachung der Anzahl der eindeutigen FQDNs für eine bestimmte Root-Domain. Diese Technik ist unabhängig von DNS-Ressourceneintragstypen, Codierung, DNS-Label-Länge und FQDN-Länge.
