Minimierung der Risiken der Verwendung von DoH und DoT
DoH- und DoT-Schutz
Kontrollieren Sie Ihren DNS-Verkehr? Organisationen investieren viel Zeit, Geld und Mühe in die Sicherung ihrer Netzwerke. Ein Bereich, dem jedoch oft nicht genügend Aufmerksamkeit geschenkt wird, ist DNS.
Ein guter Überblick über die Risiken, die DNS mit sich bringt, ist auf der Infosecurity-Konferenz.
31 % der befragten Ransomware-Klassen nutzten DNS für den Schlüsselaustausch. Studienergebnisse
31 % der befragten Ransomware-Klassen nutzten DNS für den Schlüsselaustausch.
Das Problem ist ernst. Laut dem Palo Alto Networks Unit 42-Forschungslabor nutzen etwa 85 % der Malware DNS, um einen Befehls- und Kontrollkanal einzurichten, der es Angreifern ermöglicht, problemlos Malware in Ihr Netzwerk einzuschleusen und Daten zu stehlen. Seit seiner Einführung ist der DNS-Verkehr weitgehend unverschlüsselt und kann durch die NGFW-Sicherheitsmechanismen problemlos analysiert werden.
Es sind neue Protokolle für DNS entstanden, die darauf abzielen, die Vertraulichkeit von DNS-Verbindungen zu erhöhen. Sie werden von führenden Browser-Anbietern und anderen Softwareanbietern aktiv unterstützt. Der verschlüsselte DNS-Verkehr wird in Unternehmensnetzwerken bald zunehmen. Verschlüsselter DNS-Verkehr, der von Tools nicht ordnungsgemäß analysiert und aufgelöst wird, stellt ein Sicherheitsrisiko für ein Unternehmen dar. Eine solche Bedrohung sind beispielsweise Kryptolocker, die DNS zum Austausch von Verschlüsselungsschlüsseln verwenden. Angreifer fordern nun ein Lösegeld in Höhe von mehreren Millionen Dollar, um den Zugriff auf Ihre Daten wiederherzustellen. Garmin beispielsweise zahlte 10 Millionen Dollar.
Bei richtiger Konfiguration können NGFWs die Verwendung von DNS-over-TLS (DoT) verweigern oder schützen und können dazu verwendet werden, die Verwendung von DNS-over-HTTPS (DoH) zu verweigern, sodass der gesamte DNS-Verkehr in Ihrem Netzwerk analysiert werden kann.
Was ist verschlüsseltes DNS?
Was ist DNS
Das Domain Name System (DNS) löst für Menschen lesbare Domänennamen (z. B. Adresse) auf ) zu IP-Adressen (zum Beispiel 34.107.151.202). Wenn ein Benutzer einen Domänennamen in einen Webbrowser eingibt, sendet der Browser eine DNS-Anfrage an den DNS-Server und fragt nach der IP-Adresse, die diesem Domänennamen zugeordnet ist. Als Antwort gibt der DNS-Server die IP-Adresse zurück, die dieser Browser verwenden wird.
DNS-Anfragen und -Antworten werden im Klartext und unverschlüsselt über das Netzwerk gesendet, was es anfällig für Ausspionieren oder Ändern der Antwort und die Umleitung des Browsers auf bösartige Server macht. Durch die DNS-Verschlüsselung ist es schwierig, DNS-Anfragen während der Übertragung zu verfolgen oder zu ändern. Die Verschlüsselung von DNS-Anfragen und -Antworten schützt Sie vor Man-in-the-Middle-Angriffen und bietet gleichzeitig die gleiche Funktionalität wie das herkömmliche Klartext-DNS-Protokoll (Domain Name System).
In den letzten Jahren wurden zwei DNS-Verschlüsselungsprotokolle eingeführt:
-
DNS über HTTPS (DoH)
-
DNS-über-TLS (DoT)
Eines haben diese Protokolle gemeinsam: Sie verbergen absichtlich DNS-Anfragen vor jedem Abfangen … und auch vor den Sicherheitskräften der Organisation. Die Protokolle verwenden hauptsächlich TLS (Transport Layer Security), um eine verschlüsselte Verbindung zwischen einem Client, der Anfragen stellt, und einem Server, der DNS-Anfragen auflöst, über einen Port herzustellen, der normalerweise nicht für DNS-Verkehr verwendet wird.
Die Vertraulichkeit von DNS-Anfragen ist ein großer Pluspunkt dieser Protokolle. Sie stellen jedoch Sicherheitskräfte vor Probleme, die den Netzwerkverkehr überwachen und bösartige Verbindungen erkennen und blockieren müssen. Da sich die Protokolle in ihrer Implementierung unterscheiden, unterscheiden sich die Analysemethoden zwischen DoH und DoT.
DNS über HTTPS (DoH)
DNS innerhalb von HTTPS
DoH verwendet den bekannten Port 443 für HTTPS, für den der RFC ausdrücklich angibt, dass die Absicht darin besteht, „DoH-Verkehr mit anderem HTTPS-Verkehr auf derselben Verbindung zu mischen“, „die Analyse des DNS-Verkehrs zu erschweren“ und so Unternehmenskontrollen zu umgehen ( ). Das DoH-Protokoll verwendet TLS-Verschlüsselung und die Anforderungssyntax der gängigen HTTPS- und HTTP/2-Standards und fügt DNS-Anfragen und -Antworten zusätzlich zu Standard-HTTP-Anfragen hinzu.
Mit DoH verbundene Risiken
Wenn Sie regulären HTTPS-Verkehr nicht von DoH-Anfragen unterscheiden können, können (und werden) Anwendungen in Ihrer Organisation lokale DNS-Einstellungen umgehen, indem sie Anfragen an Server von Drittanbietern umleiten, die auf DoH-Anfragen reagieren, wodurch jegliche Überwachung umgangen wird, d. h. die Fähigkeit dazu zerstört wird Kontrollieren Sie den DNS-Verkehr. Idealerweise sollten Sie DoH mithilfe von HTTPS-Entschlüsselungsfunktionen steuern.
И in der neuesten Version ihrer Browser und beide Unternehmen arbeiten daran, DoH standardmäßig für alle DNS-Anfragen zu verwenden. über die Integration von DoH in ihre Betriebssysteme. Der Nachteil besteht darin, dass nicht nur seriöse Softwareunternehmen, sondern auch Angreifer begonnen haben, DoH als Mittel zur Umgehung traditioneller Unternehmens-Firewall-Maßnahmen zu nutzen. (Lesen Sie beispielsweise die folgenden Artikel: , и .) In beiden Fällen bleibt sowohl guter als auch bösartiger DoH-Verkehr unentdeckt, sodass das Unternehmen blind für die böswillige Nutzung von DoH als Kanal zur Kontrolle von Malware (C2) und zum Diebstahl sensibler Daten bleibt.
Gewährleistung der Sichtbarkeit und Kontrolle des DoH-Verkehrs
Als beste Lösung für die DoH-Kontrolle empfehlen wir, NGFW so zu konfigurieren, dass HTTPS-Verkehr entschlüsselt und DoH-Verkehr blockiert wird (Anwendungsname: dns-over-https).
Stellen Sie zunächst sicher, dass NGFW für die Entschlüsselung von HTTPS konfiguriert ist .
Zweitens erstellen Sie eine Regel für den Anwendungsverkehr „dns-over-https“, wie unten gezeigt:
NGFW-Regel von Palo Alto Networks zum Blockieren von DNS über HTTPS
Als vorläufige Alternative (wenn Ihre Organisation die HTTPS-Entschlüsselung nicht vollständig implementiert hat) kann NGFW so konfiguriert werden, dass eine „Verweigern“-Aktion auf die Anwendungs-ID „dns-over-https“ angewendet wird. Da DoH-Server anhand ihres Domänennamens bekannt sind, kann der DoH-Verkehr ohne HTTPS-Entschlüsselung nicht vollständig überprüft werden (siehe und suchen Sie nach „dns-over-https“).
DNS über TLS (DoT)
DNS innerhalb von TLS
Während das DoH-Protokoll dazu neigt, sich mit anderem Datenverkehr auf demselben Port zu vermischen, verwendet DoT stattdessen standardmäßig einen speziellen Port, der ausschließlich für diesen Zweck reserviert ist, und verbietet sogar ausdrücklich die Verwendung desselben Ports durch herkömmlichen unverschlüsselten DNS-Datenverkehr ( ).
Das DoT-Protokoll verwendet TLS, um eine Verschlüsselung bereitzustellen, die Standard-DNS-Protokollabfragen kapselt, wobei der Datenverkehr den bekannten Port 853 verwendet ( ). Das DoT-Protokoll wurde entwickelt, um es Organisationen einfacher zu machen, den Datenverkehr auf einem Port zu blockieren oder Datenverkehr zu akzeptieren, aber die Entschlüsselung auf diesem Port zu ermöglichen.
Mit DoT verbundene Risiken
Google hat DoT in seinem Client implementiert , mit der Standardeinstellung, DoT automatisch zu verwenden, falls verfügbar. Wenn Sie die Risiken abgeschätzt haben und bereit sind, DoT auf Organisationsebene einzusetzen, müssen Netzwerkadministratoren den ausgehenden Datenverkehr auf Port 853 über ihren Perimeter für dieses neue Protokoll ausdrücklich zulassen.
Gewährleistung der Sichtbarkeit und Kontrolle des DoT-Verkehrs
Als Best Practice für die DoT-Kontrolle empfehlen wir je nach den Anforderungen Ihres Unternehmens eine der oben genannten Methoden:
-
Konfigurieren Sie NGFW so, dass der gesamte Datenverkehr für den Zielport 853 entschlüsselt wird. Durch die Entschlüsselung des Datenverkehrs wird DoT als DNS-Anwendung angezeigt, auf die Sie beliebige Aktionen anwenden können, z. B. das Aktivieren eines Abonnements um DGA-Domänen oder eine bestehende zu steuern und Anti-Spyware.
-
Eine Alternative besteht darin, dass die App-ID-Engine den „DNS-over-TLS“-Verkehr auf Port 853 vollständig blockiert. Dies ist normalerweise standardmäßig blockiert, es sind keine Maßnahmen erforderlich (es sei denn, Sie erlauben ausdrücklich den „DNS-over-TLS“-Anwendungs- oder Portverkehr 853).
Source: habr.com