Lösung 1:
Linux-Auditing kann helfen. Es wird zumindest Benutzer und Prozesse lokalisieren, die Datagramm-Netzwerkverbindungen herstellen. UDP-Pakete sind Datagramme.
Installieren Sie zuerst auditd Framework auf Ihrer Plattform und stellen Sie sicher, dass auditctl -l gibt etwas zurück, auch wenn es sagt, dass keine Regeln definiert sind.
Fügen Sie dann eine Regel hinzu, um den Systemaufruf socket() zu überwachen und markieren Sie es, um es später leichter wiederzufinden (-k ). Ich muss davon ausgehen, dass Sie sich auf einer 64-Bit-Architektur befinden, aber Sie können b32 ersetzen anstelle von b64 wenn nicht.
auditctl -a exit,always -F arch=b64 -F a0=2 -F a1\&=2 -S socket -k SOCKET
Sie müssen Manpages und Header-Dateien durchsuchen, 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, aber häufig Null ist. PF_INET ist 2 und SOCK_DGRAM ist 2. TCP-Verbindungen würden SOCK_STREAM verwenden was a1=1 setzen würde . (SOCK_DGRAM im zweiten Parameter kann mit SOCK_NONBLOCK ODER-verknüpft werden oder SOCK_CLOEXEC , daher der &= Vergleich.) Der -k SOCKET ist unser Schlüsselwort, das wir verwenden möchten, wenn wir später Audit-Trails suchen. Es kann alles sein, aber ich halte es gerne einfach.
Lassen Sie einen Moment verstreichen und sehen Sie sich die Audit-Trails an. Optional könnten Sie ein paar Pakete erzwingen, indem Sie einen Host im Netz anpingen, wodurch eine DNS-Suche erfolgt, die UDP verwendet, was unseren Audit-Alarm auslösen sollte.
ausearch -i -ts today -k SOCKET
Und eine Ausgabe ähnlich der im folgenden Abschnitt wird 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 ping Befehl bewirkte, dass der Socket geöffnet wurde. Ich könnte dann strace -p 14510 ausführen auf den Prozess, falls er noch lief. Die ppid (Elternprozess-ID) wird ebenfalls aufgelistet, falls es sich um ein Skript handelt, das das problematische Kind häufig erzeugt.
Nun, wenn Sie viel UDP-Verkehr haben, wird dies nicht gut genug sein und Sie müssen auf OProfile oder SystemTap zurückgreifen, die beide derzeit außerhalb meines Fachwissens liegen.
Dies sollte helfen, die Dinge im allgemeinen Fall einzugrenzen.
Wenn Sie fertig sind, entfernen Sie die Überwachungsregel, indem Sie dieselbe Zeile verwenden, mit der Sie sie erstellt haben, ersetzen Sie nur -a mit -d .
auditctl -d exit,always -F arch=b64 -F a0=2 -F a1\&=2 -S socket -k SOCKET
Lösung 2:
Sie können netstat verwenden, aber Sie benötigen die richtigen Flags, und es funktioniert nur, wenn der Prozess, der die Daten sendet, noch aktiv ist. Es wird keine Spuren von etwas finden, das kurzzeitig zum Leben erwacht ist, UDP-Verkehr gesendet hat und dann verschwunden ist. Es erfordert auch lokale Root-Rechte. Das heißt:
Hier starte ich ein ncat auf meinem lokalen Host und sende UDP-Datenverkehr an Port 2345 auf einer (nicht vorhandenen) Maschine 10.11.12.13:
[[email protected]]$ ncat -u 10.11.12.13 2345 < /dev/urandom
Hier ist eine tcpdump-Ausgabe, die beweist, dass der Datenverkehr läuft:
[[email protected] ~]# 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 der nützliche Teil , verwenden Sie netstat mit dem Flag -a (um Portdetails anzuzeigen) und dem Flag -p, um Prozess-ID-Details anzuzeigen. Es ist das Flag -p, das Root-Rechte erfordert:
[[email protected] ~]# 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, wird PID 9152 so gefingert, dass eine Verbindung zu Port 2345 auf dem angegebenen Remote-Host offen ist. Netstat führt das hilfreicherweise auch durch ps und teilt mir mit, dass der Prozessname ncat ist .
Hoffentlich ist das von Nutzen.
Lösung 3:
Ich hatte genau das gleiche Problem und leider auditd hat mir nicht viel gebracht.
Ich hatte Datenverkehr von einigen meiner Server, der zu den Google-DNS-Adressen 8.8.8.8 ging und 8.8.4.4 . Jetzt hat mein Netzwerkadministrator eine leichte Zwangsstörung und wollte den gesamten unnötigen Datenverkehr bereinigen, 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 in systemtap . Ich komme mit dem folgenden 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 ausführen:
stap -v udp_detect_domain.stp
Dies ist die Ausgabe, die ich erhalten 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 von resolv.conf diese PIDs haben die Änderungen nicht übernommen.
Hoffe das hilft :)
Lösung 4:
Hier ist eine Systemtap-Option, die die Netfilter-Sonden verwendet, die in Stap-Version 1.8 und höher verfügbar sind. 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
Lösung 5:
Ich würde einen Net-Sniffer wie tcpdump oder Wireshark verwenden, um die DNS-Anfragen anzuzeigen. Der Inhalt der Abfrage kann Aufschluss darüber geben, welches Programm sie ausgibt.