
Die Verwendung von bind9 auf einem Laptop zeigt bei unterbrochener Netzwerkverbindung viele unsinnige Domänen an:
Oct 18 19:56:18 lap3 named[1536]: error (network unreachable) resolving './NS/IN': 128.63.2.53#53
Oct 18 19:56:18 lap3 named[1536]: error (network unreachable) resolving 'drgvlofubl/A/IN': 128.63.2.53#53
Oct 18 19:56:18 lap3 named[1536]: error (network unreachable) resolving 'gjpszynvcz/A/IN': 128.63.2.53#53
Oct 18 19:56:19 lap3 named[1536]: error (network unreachable) resolving 'iqgwbuxrbt/A/IN': 192.5.5.241#53
Wie finde ich heraus, welches Programm diese Abfragen stellt?
Das Hinzufügen von „Debug“ zu /etc/resolv.conf scheint nichts zu bewirken (auf dem Laptop läuft Arch Linux und er scheint nicht mit Debug-Unterstützung kompiliert zu sein?).
Der nächste Schritt besteht darin, Libresolv mit aktiviertem Debug zu kompilieren, es sei denn, es gibt etwas Besseres zu tun.
Antwort1
Ich glaube nicht, dass dies angesichts der Funktionsweise von DNS möglich ist. DNS weiß nicht, welche Anwendungen es abfragen, sondern nur, dass ein Dienst einen Port bei der Hostverbindung zu ihm geöffnet hat (TCP vorausgesetzt) oder ein UDP-Paket an den Bind-Server gesendet hat und der Bind-Server über dieselbe Verbindung mit einer Antwort an diese mysteriöse Anwendung geantwortet hat.
Netzwerk-Sniffer
In Situationen wie dieser verwenden Sie im Allgemeinen eine Anwendung, um den Netzwerkverkehr beim Hin- und Hertransport zu überwachen, und Sie können den Fokus so einschränken, dass Sie nur Nachrichten sehen, die sich in Ihrem Fall auf ein bestimmtes Protokoll (DNS) beziehen, oder den Verkehr zwischen zwei Endpunkten (Ihrem PC und dem Bind-Server), normalerweise unter Verwendung von IP-Adressen.
Da Ihre Frage mein Interesse geweckt hat, habe ich die Gelegenheit genutzt, diese Frage auf der Wireshark SE-Site zu stellen.
AuszugWie kann ich feststellen, welche Anwendung DNS-Abfragen an meinen Bind-Server sendet?
Ich versuche herauszufinden, wie man feststellen kann, welche Anwendung auf meiner Linux-Box eine bestimmte DNS-Abfrage an meinen Bind-Server sendet. Ich habe mit dem folgenden Befehl herumgespielt:
$ tshark -i wlan0 -nn -e ip.src -e dns.qry.name -E separator=";" -T fields port 53 192.168.1.20;ajax.googleapis.com 192.168.1.101;ajax.googleapis.com 192.168.1.20;pop.bizmail.yahoo.com
Wie kann ich erreichen, dass mir die eigentliche Anwendung (Port und ggf. PID) angezeigt wird? Wiresharkist ein solches Tool, das Sie hierfür verwenden würden, es gibt natürlich auch andere.
Darauf erhielt ich diese Antwort:
Bei der normalen Paketerfassung gibt es keine Möglichkeit, die Anwendung oder PID anhand der Pakete zu identifizieren, da man nur sehen kann, von welchem Port das Paket gesendet wurde.
Wenn Sie auf einem Host erfassen, der die Kommunikation durchführt, können Sie versuchen, denHone-Projektum diese Art von Informationen zu erhalten. Unter WindowsNetzwerkmonitorkann das Gleiche tun.
Andernfalls könnten Sie versuchen, netstat auf der Box auszuführen, die die Namensauflösung durchführt, und es den Portnummern zuzuordnen, die die DNS-Abfrage verwendet. Da es sich jedoch um eine UDP-Kommunikation handelt, wird der Port fast augenblicklich geöffnet und geschlossen. Daher ist die Chance, netstat genau in der Millisekunde auszuführen, in der er geöffnet ist, so groß wie der Versuch, im Lotto zu gewinnen.
Hone-Projekt
Dieser Ansatz schien ein sehr vielversprechender Ansatz zu sein. Dies ist das erste Projekt, das mir je untergekommen ist, das die Verknüpfung zwischen Netzwerkpaketen und Prozess-IDs herzustellen scheint.
Hone ist ein einzigartiges Tool zum Korrelieren von Paketen mit Prozessen, um die Kluft zwischen Host und Netzwerk zu überbrücken.
Verweise
Antwort2
wenn Sie eine wahrscheinlicheverdächtigProgramm, strace es für recvfrom
und sendto
Systemaufrufe. Beispielsweise erhielt ich Tausende von Suchvorgängen für radheengineering.info und obwohl dieser Name in den Protokollen von exim4 nicht angezeigt wurde, war er mit der primären PID von 1813 der wahrscheinlichste Übeltäter.
also strace -f -p1813 -erecvfrom,sendto
habe ich mithilfe von herausgefunden, dass es tatsächlich exim4 war, das die Abfragen durchführte. Dann habe ich das /24-Netzwerk, das den Server erreichte, in ein Blackhole verwandelt, und das hat das Problem gelöst.