Wie arbeitet überprüfen Sie DNS-Doline Funktion

Details

Dieses Dokument soll helfen, zu überprüfen, ob die DNS-Sink Loch-Funktion durch eine Palo Alto Networks-Firewall einwandfrei funktioniert.

Folgende zwei Szenarien sind abgedeckt:

• Client mit externem DNS-Server
• Client mit internem DNS-Server

DNS-Sink Loch Konfiguration

Weitere Informationen zur Konfiguration von DNS-Sinkloch finden Sie unter:

Gewusst wie: Konfigurieren von DNS-Doline

Außerdem haben wir ein Video-Tutorial, wie man DNS-Sink-Loch konfigurieren:

Video-Tutorial: Wie man DNS-Doline konfigurieren

Client mit externem DNS-Server

Hinweis: DNS Sink Hole IP muss sich im Pfad der Firewall und des Clients befinden, damit Sie Protokolle von ihr sehen können. So sitzt die Palo Alto Networks Firewall zwischen einem infizierten Client und dem Rechenzentrum, sieht aber nicht das Internet. In diesem Szenario, wenn DNS sinkhole mit einer Internet-IP konfiguriert ist, dann wird die Firewall nie sehen, wie der infizierte Client versucht, seinen Command & Control-Server zu erreichen.

Wenn die DNS-Sink Loch-Funktion auf der Palo Alto Networks-Firewall konfiguriert ist und das Client-System einen externen DNS-Server nutzt, wird die DNS-Abfrage des Clients über die Palo Alto Networks-Firewall an den externen DNS-Server gehen (Client und DNS-Server befinden sich in verschiedene Subnetze). Wie zu erwarten, sollte der Nutzer in der Lage sein, Bedrohungs Protokolle mit der Client-IP-Adresse als Quelle zu sehen.

1. Der Nutzer versucht, auf eine böswillige Website zuzugreifen. Das Client-System sendet die DNS-Abfrage an einen externen DNS-Server, um die IP-Adresse der bösartigen Website zu erhalten. Die Firewall wird die DNS-Abfrage direkt vom Client-System erhalten.
2. Die Firewall wird die DNS-Abfrage entführen und dem Client eine DNS-sinkloch-IP-Adresse geben und sollte in der Lage sein, die Bedrohungs Protokolle mit der IP-Adresse des Clients als Quelle zu sehen.

Client TCP/IP Properties Konfiguration

Lesen Sie das folgende Konfigurationsbeispiel:

Bedrohung durch Protokolle

Wenn Sie einen externen DNS-Server verwenden, zeigen Bedrohungs Protokolle die IP-Adresse des Clients "192.168.27.192" als eine Quelle an, die versucht, auf eine böswillige Website zuzugreifen:

Client-Ausgabe bei der Nutzung von externem DNS-Server

$ Nslookup 79fe3m5f4nx8c1.PMR.CC
Server: 195.130.131.4
Adresse: 195.130.131.4 # 53

nicht-maßgebliche Antwort:
Name: 79fe3m5f4nx8c1.PMR.CC
Adresse: 72.5.65.111    

Der Screenshot oben zeigt einen Host-Rechner 192.168.27.192 der eine DNS-Anfrage für "79fe3m5f4nx8c1.PMR.CC" (eine verdächtige URL) ausführt und die Antwort 72.5.65.111. So zeigt sich, dass das DNS-Sinkloch wie gewünscht funktioniert.

Client mit internem DNS-Server

Wenn ein Client-System einen internen DNS-Server verwendet (Client und DNS-Server befinden sich im selben Subnetz), wird die DNS-Abfrage des Clients an den internen DNS-Server gehen. Der interne DNS-Server wird diese Abfrage an einen externen DNS-Server weiterleiten, und Bedrohungs Protokolle mit der internen DNS-Server-IP-Adresse werden als Quelle angesehen.

Derzeit kann die Palo Alto Networks Firewall nicht erkennen, welcher Endclient mit Hilfe der Bedrohungs Protokolle auf eine böswillige Website zugreifen will, da alle Bedrohungs Protokolle die interne DNS-Server-IP-Adresse als Quelle haben. Die Firewall sollte jedoch in der Lage sein, die IP-Adresse des Endkunden mit Hilfe von Verkehrs Protokollen zu bestimmen.

Im folgenden finden Sie ein Beispiel, in dem der Benutzer versucht, auf eine böswillige Website zuzugreifen. Das Client-System sendet die DNS-Abfrage an einen internen DNS-Server, um die IP-Adresse der bösartigen Website zu erwerben. Hier wird der interne DNS-Server die DNS-Abfrage an einen externen DNS-Server weiterleiten. Die Firewall erhält eine DNS-Abfrage vom internen DNS-Server.

Die Firewall wird die DNS-Abfrage entführen und die DNS-Sink Loch-IP-Adresse an den internen DNS-Server geben. Der interne DNS-Server wird die Antwort auf das Client-System weiterleiten und der Benutzer sollte in der Lage sein, Bedrohungs Protokolle mit interner DNS-Server-IP-Adresse als Quelle zu sehen. Die Palo Alto Networks Firewall sollte jedoch in der Lage sein, die IP-Adresse des Clients in den Traffic Logs zu sehen, da der Client versuchen wird, auf diese Website mit DNS-Sink-IP-Adresse zuzugreifen, wie im folgenden Screenshot gezeigt wird:

Client TCP/IP Properties Konfiguration

Bedrohung durch Protokolle

In Bedrohungs Protokollen zeigt die Firewall nur die interne DNS-Server-IP-Adresse "10.50.240.101" als Quelle an, da das Client-System die interne DNS-Server-IP nutzt. Hier ist die Firewall nicht in der Lage zu bestimmen, welcher Endclient versucht, auf diese Website zuzugreifen.

VerkehrsProtokolle

Sobald der Client jedoch die IP-Adresse vom DNS-Server erhält, generiert er den Verkehr in Richtung der sinkloch-IP-Adresse (72.5.65.111). Daher wird die Firewall die Endclient-IP-Adresse "192.168.27.192" in Traffic Logs anzeigen, wie unten gezeigt:

Client-Ausgabe bei der Nutzung des internen DNS-Servers

$ Nslookup 4cdf1kuvlgl5zpb9.PMR.CC
Server: 192.168.27.189
Adresse: 192.168.27.189 # 53

nicht-maßgebliche Antwort:
Name: 4cdf1kuvlgl5zpb9.PMR.CC
Adresse: 72.5.65.111    

Der obige Screenshot zeigt eine Host-Maschine 192.168.27.192 die eine DNS-Anfrage für 4cdf1kuvlgl5zpb9.PMR.CC (eine verdächtige URL) mit der Antwort von 72.5.65.111 ausführt. Dies prüft, dass das DNS-Sinkloch wie gewünscht funktioniert.

Siehe auch

Wie man mit Conficker mit DNS-Sink-Loch umgeht

Wo man verdächtige DNS-Abfrage zum Testen von DNS-Sinkloch bekommt

Für Video-Tutorials auf DNS-Sink Loch, siehe:

Video-Tutorial: Wie man DNS-Doline konfigurieren

Video-Tutorial: Wie man DNS-Doline überprüfen

Besitzer: Sbabu