Frage Wie kann ich identifizieren, welcher Prozess UDP-Verkehr auf Linux macht?


Mein Gerät macht ständig UDP-DNS-Verkehr Anfrage. Was ich wissen muss, ist die PID des Prozesses, der diesen Verkehr erzeugt.

Der normale Weg in der TCP-Verbindung besteht darin, netstat / lsof zu verwenden und den Prozess in Verbindung mit der pid zu bekommen.

Ist UDP die Verbindung ist stateles, also, wenn ich netastat / lsof anrufe, kann ich es nur sehen, wenn der UDP-Sockel geöffnet ist und es Verkehr sendet.

Ich habe versucht mit lsof -i UDP und mit nestat -anpue, aber ich kann nicht in der Lage zu finden, was Prozess tut diese Anfrage, weil ich lsof / netstat genau aufrufen muss, wenn der UDP-Verkehr gesendet wird, wenn ich lsof / netstat vor / nachdem das udp-Datagramm gesendet wurde, ist es unmöglich, den geöffneten UDP-Socket anzuzeigen.

call netstat / lsof genau dann, wenn 3/4 udp Paket gesendet wird, ist UNMÖGLICH.

Wie kann ich den berüchtigten Prozess identifizieren? Ich habe den Verkehr bereits inspiziert, um zu versuchen, die gesendete PID aus dem Inhalt des Pakets zu identifizieren, aber es ist nicht möglich, sie aus dem Kontext des Verkehrs zu identifizieren.

kann mir jemand helfen?

Ich bin root auf dieser Maschine FEDORA 12 Linux noise.company.lan 2.6.32.16-141.fc12.x86_64 # 1 SMP Mit Jul 7 04:49:59 UTC 2010 x86_64 x86_64 x86_64 GNU / Linux


40
2017-10-20 10:41


Ursprung




Antworten:


Linux-Auditing kann helfen. Es wird zumindest Benutzer und Prozesse finden, die Datagramm-Netzwerkverbindungen herstellen. UDP-Pakete sind Datagramme.

Installieren Sie zuerst die auditd Rahmen auf Ihrer Plattform und stellen Sie sicher, dass auditctl -l gibt etwas zurück, auch wenn es besagt, dass keine Regeln definiert sind.

Fügen Sie dann eine Regel zum Überwachen des Systemaufrufs hinzu socket() und es für späteres Auffinden markieren (-k). Ich muss davon ausgehen, dass Sie auf einer 64-Bit-Architektur sind, aber Sie können ersetzen b32 anstelle der b64 wenn du nicht bist.

auditctl -a exit,always -F arch=b64 -F a0=2 -F a1\&=2 -S socket -k SOCKET

Sie müssen Man-Seiten und Header-Dateien auswählen, um dies zu erstellen, aber was es erfasst, ist im Wesentlichen dieser Systemaufruf: socket(PF_INET, SOCK_DGRAM|X, Y), wobei der dritte Parameter nicht spezifiziert ist, aber häufig Null ist. PF_INET ist 2 und SOCK_DGRAM ist 2. TCP-Verbindungen würden verwenden SOCK_STREAM was würde setzen a1=1. (SOCK_DGRAM im zweiten Parameter kann mit ODER verknüpft werden SOCK_NONBLOCK oder SOCK_CLOEXEC, daher die &= Vergleich.) Die -k SOCKET ist unser Schlüsselwort, das wir später bei der Suche nach Audit-Trails verwenden möchten. Es kann alles sein, aber ich möchte es einfach halten.

Lassen Sie einige Momente verstreichen und überprüfen Sie die Audit-Trails. Optional können Sie einige Pakete erzwingen, indem Sie einen Host im Netzwerk anpingen, wodurch eine DNS-Suche ausgelöst wird, die UDP verwendet, was unsere Überwachungswarnung auslösen sollte.

ausearch -i -ts today -k SOCKET

Es wird eine ähnliche Ausgabe wie im folgenden Abschnitt angezeigt. Ich kürze es ab, um die wichtigen Teile hervorzuheben

type=SYSCALL ... arch=x86_64 syscall=socket success=yes exit=1 a0=2 a1=2 ... pid=14510 ... auid=zlagtime uid=zlagtime ... euid=zlagtime ... comm=ping exe=/usr/bin/ping key=SOCKET

In der obigen Ausgabe können wir sehen, dass die ping Befehl führte dazu, dass der Socket geöffnet wurde. Ich könnte dann rennen strace -p 14510 auf dem Prozess, wenn es noch lief. Das ppid (Eltern-Prozess-ID) wird auch aufgelistet, falls es ein Skript ist, das das Problemkind oft hervorbringt.

Nun, wenn Sie viel UDP-Verkehr haben, wird dies nicht gut genug sein und Sie müssen darauf zurückgreifen OProfil oder SystemtabelleBeide sind derzeit jenseits meiner Expertise.

Dies sollte helfen, die Dinge im allgemeinen Fall einzuengen.

Wenn Sie fertig sind, entfernen Sie die Überwachungsregel, indem Sie dieselbe Zeile verwenden, die Sie zum Erstellen verwendet haben. Ersetzen Sie sie nur -a mit -d.

auditctl -d exit,always -F arch=b64 -F a0=2 -F a1\&=2 -S socket -k SOCKET

44
2017-10-20 18:41



Ich werde es versuchen, aber ich denke, es ist die richtige Antwort. - boos
Das zieht nicht den Verkehr auf, der von iptables fallengelassen wird, zumindest für mich. - 2rs2ts
+1 für die Einfachheit im Vergleich zur systemtap-Methode (die analytischer ist, aber Kernel-devel-Pakete benötigt) - basos


Sie können netstat verwenden, aber Sie benötigen die richtigen Flags, und es funktioniert nur, wenn der Prozess, der die Daten sendet, noch am Leben ist. Es wird nicht die Spuren von etwas finden, das kurzzeitig zum Leben erweckt wurde, UDP-Verkehr gesendet und dann weggegangen ist. Es erfordert auch lokale Root-Berechtigungen. Das gesagt:

Hier starte ich einen ncat auf meinem lokalen Host und sende UDP-Verkehr zu Port 2345 auf einem (nicht existierenden) Rechner 10.11.12.13:

[madhatta@risby]$ ncat -u 10.11.12.13 2345 < /dev/urandom

Hier ist eine tcpdump-Ausgabe, die belegt, dass der Traffic geht:

[root@risby ~]# tcpdump -n -n port 2345
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
12:41:32.391750 IP 192.168.3.11.57550 > 10.11.12.13.2345: UDP, length 8192
12:41:32.399723 IP 192.168.3.11.57550 > 10.11.12.13.2345: UDP, length 8192
12:41:32.401817 IP 192.168.3.11.57550 > 10.11.12.13.2345: UDP, length 8192
12:41:32.407051 IP 192.168.3.11.57550 > 10.11.12.13.2345: UDP, length 8192
12:41:32.413492 IP 192.168.3.11.57550 > 10.11.12.13.2345: UDP, length 8192
12:41:32.417417 IP 192.168.3.11.57550 > 10.11.12.13.2345: UDP, length 8192

Hier ist das Nützliche, Verwenden von Netstat mit dem Flag -a (um Port-Details anzuzeigen) und dem Flag -p, um Prozess-ID-Details anzuzeigen. Es ist das Flag -p, das root-Rechte erfordert:

[root@risby ~]# netstat -apn|grep -w 2345
udp        0      0 192.168.3.11:57550          10.11.12.13:2345            ESTABLISHED 9152/ncat     

Wie Sie sehen können, ist pid 9152 so gefingert, als hätte eine Verbindung zu Port 2345 auf dem angegebenen entfernten Host geöffnet. Netstat führt das auch hilfreich durch ps und sagt mir den Prozessnamen ist ncat.

Hoffentlich ist das von Nutzen.


22
2017-10-20 11:49



wirklich schön gemacht! :Daumen hoch: - ThorstenS
Es gibt jedoch einen Haken. Wenn das Problem durch ein Shell-Skript verursacht wird, das einen Subprozess erzeugt, der die DNS-Suche ausführt und dieser Prozess schnell beendet wird, ändert sich der Quellport (57550 oben) ständig. In diesem Fall wird die Technik nicht funktionieren und Sie müssen drastischere Maßnahmen ergreifen. Zusätzlich sollte Ihr Netstat a grep -w 57550 weil mehrere Prozesse DNS-Lookups für denselben Server ausführen könnten. Ihre Methode würde sie nicht unterscheiden. - zerolagtime
Ich stimme Ihren beiden Einwänden, Zerolagtime, zu (aber danke für Ihre freundlichen Worte, ThorstenS!). - MadHatter


Ich hatte genau das selbe Problem und leider auditd hat nicht viel für mich getan.

Ich hatte Traffic von einigen meiner Server google DNS-Adressen, 8.8.8.8 und 8.8.4.4. Jetzt hat mein Netzwerkadministrator milde OCD und er wollte den unnötigen Datenverkehr löschen, da wir unsere internen DNS-Caches haben. Er wollte den ausgehenden Port 53 für alle außer diesen Cache-Servern deaktivieren.

Also, nach dem Scheitern mit auditctl, Grabe ich hinein systemtap. Ich habe folgendes Skript:

# cat >> udp_detect_domain.stp <<EOF
probe udp.sendmsg {
  if ( dport == 53 && daddr == "8.8.8.8" ) {
    printf ("PID %5d (%s) sent UDP to %15s 53\n", pid(), execname(), daddr)
  }
}
EOF

Dann einfach laufen:

stap -v udp_detect_domain.stp

Das ist die Ausgabe, die ich bekommen habe:

PID  3501 (python) sent UDP to  8.8.8.8 53
PID  3501 (python) sent UDP to  8.8.8.8 53
PID  3506 (python) sent UDP to  8.8.8.8 53

Das ist es! Nach dem Ändern resolv.conf Diese PIDs haben die Änderungen nicht übernommen.


Hoffe das hilft :)


13
2018-04-16 20:39





Ich würde einen Net-Sniffer wie tcpdump oder wireshark verwenden, um die DNS-Anfragen zu sehen. Der Inhalt der Abfrage kann eine Vorstellung davon geben, welches Programm sie ausgibt.


4
2017-10-20 10:46



Keine Informationen im Verkehr geschnüffelt habe ich gerade schon gesehen. - boos
Keine Informationen? Leere Pakete? Was ich meinte, war, wenn etwas versucht, updates.java.sun.com oder rss.cnn.com zu lösen, könnten Sie nützlich daraus etwas ableiten. - RedGrittyBrick
dns fragt nach dem internen Proxy ab. Gerade jetzt habe ich festgestellt, welcher Prozess ist, aber die Frage bleibt lebendig für eine allgemeine Problemlösungstechnik - boos
lsof -i | awk '/ UDP /' - c4f4t0r


Hier ist eine Systemtap-Option, die die netfilter-Sonden ab Version 1.8 verwendet. Siehe auch man probe::netfilter.ip.local_out.

# stap -e 'probe netfilter.ip.local_out {
  if (dport == 53) # or parametrize
      printf("%s[%d] %s:%d\n", execname(), pid(), daddr, dport)
}'
ping[24738] 192.168.1.10:53
ping[24738] 192.168.1.10:53
^C

3
2018-04-24 20:03





Beachten Sie, dass nscd bei der Verwendung von autitctl bei einer DNS-Abfrage zum Beispiel einen etwas anderen Parameter im Socket-Systemaufruf verwendet:

socket(AF_INET, SOCK_DGRAM|SOCK_NONBLOCK, IPPROTO_IP)

Um sicherzustellen, dass Sie diese Abfragen zusätzlich zu den oben genannten Abfragen abfangen, können Sie einen zusätzlichen Filter mit demselben Namen hinzufügen, wenn Sie möchten:

auditctl -a exit,always -F arch=b64 -F a0=2  -F a1=2050 -S socket -k SOCKET

Hier ist 2050 ein bitweises ODER von SOCK_DGRAM (2 und SOCK_NONBLOCK (2048).

Dann findet die Suche beide Filter mit demselben Schlüssel, SOCKET:

ausearch -i -ts today -k SOCKET

Die Hex-Werte für die Socket-Konstanten, die ich hier gefunden habe: https://golang.org/pkg/syscall/#pkg-constants

Da ich keine Reputationspunkte zum kommentieren habe habe ich das hinzugefügt.


3
2017-10-17 12:53