52 votes

Comment puis-je identifier le processus qui génère du trafic UDP sous Linux ?

Ma machine fait continuellement des demandes de trafic udp dns. ce que j'ai besoin de savoir c'est le PID du processus qui génère ce trafic.

Dans le cas d'une connexion TCP, la méthode normale consiste à utiliser netstat/lsof et à obtenir le processus associé au pid.

Avec UDP, la connexion est statique, de sorte que lorsque j'appelle netastat/lsof, je ne peux la voir que si le socket UDP est ouvert et qu'il envoie du trafic.

J'ai essayé avec lsof -i UDP et avec nestat -anpue mais je n'arrive pas à savoir quel processus effectue cette requête car j'ai besoin d'appeler lsof/netstat exactement au moment où le trafic udp est envoyé, si j'appelle lsof/netstat avant/après l'envoi du datagramme udp, il m'est impossible de voir la socket UDP ouverte.

Appeler netstat/lsof exactement quand 3/4 paquets udp sont envoyés est IMPOSSIBLE.

Comment puis-je identifier le processus infâme ? J'ai déjà inspecté le trafic pour essayer d'identifier le PID envoyé à partir du contenu du paquet, mais il n'est pas possible de l'identifier à partir du contenu du trafic.

Quelqu'un peut-il m'aider ?

Je suis root sur cette machine FEDORA 12 Linux noise.company.lan 2.6.32.16-141.fc12.x86_64 #1 SMP Wed Jul 7 04:49:59 UTC 2010 x86_64 x86_64 x86_64 GNU/Linux

62voto

zerolagtime Points 1418

L'audit Linux peut être utile. Il permettra au moins de localiser les utilisateurs et les processus qui établissent des connexions réseau par datagramme. Les paquets UDP sont des datagrammes.

Tout d'abord, installez le auditd sur votre plateforme et assurez-vous que auditctl -l renvoie quelque chose, même si elle indique qu'aucune règle n'est définie.

Ensuite, ajoutez une règle pour surveiller l'appel système socket() et l'étiqueter pour le retrouver plus facilement par la suite ( -k ). Je dois supposer que vous utilisez une architecture 64 bits, mais vous pouvez substituer b32 à la place du b64 si vous ne l'êtes pas.

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

Vous devez parcourir les pages de manuel et les fichiers d'en-tête pour le construire, mais ce qu'il capture est essentiellement cet appel système : socket(PF_INET, SOCK_DGRAM|X, Y) où le troisième paramètre n'est pas spécifié mais est souvent égal à zéro. PF_INET est de 2 et SOCK_DGRAM Les connexions TCP utilisent SOCK_STREAM qui fixerait a1=1 . ( SOCK_DGRAM dans le deuxième paramètre peut être ORed avec SOCK_NONBLOCK ou SOCK_CLOEXEC , d'où la &= comparaison). Les -k SOCKET est le mot-clé que nous voulons utiliser lors des recherches ultérieures dans les pistes d'audit. Il peut s'agir de n'importe quoi, mais je préfère rester simple.

Laissez passer quelques instants et examinez les pistes d'audit. En option, vous pouvez forcer quelques paquets en envoyant un ping à un hôte sur le net, ce qui provoquera une recherche DNS, qui utilise UDP, ce qui devrait déclencher notre alerte d'audit.

ausearch -i -ts today -k SOCKET

Un résultat similaire à celui de la section ci-dessous s'affiche. Je l'abrège pour mettre en évidence les parties importantes

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

Dans le résultat ci-dessus, nous pouvons voir que la fonction ping a provoqué l'ouverture du socket. Je peux alors exécuter strace -p 14510 sur le processus, s'il est toujours en cours. Le processus ppid (ID du processus parent) est également listé au cas où il s'agirait d'un script qui génère souvent l'enfant à problèmes.

Maintenant, si vous avez beaucoup de trafic UDP, cela ne sera pas suffisant et vous devrez avoir recours à Profil OP ou SystemTap Ces deux aspects dépassent actuellement mes compétences.

Cela devrait permettre de réduire le nombre de cas généraux.

Lorsque vous avez terminé, supprimez la règle d'audit en utilisant la même ligne que celle que vous avez utilisée pour la créer, mais remplacez-la par la suivante -a con -d .

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

25voto

MadHatter Points 77602

Vous pouvez utiliser netstat, mais vous avez besoin des bons drapeaux, et cela ne fonctionne que si le processus qui envoie les données est toujours en vie. Il ne trouvera pas les traces d'un processus qui s'est brièvement réveillé, a envoyé du trafic UDP, puis s'est éteint. Il faut également disposer des privilèges de l'administrateur local. Ceci étant dit :

Voici comment je lance un ncat sur mon hôte local, en envoyant du trafic UDP au port 2345 sur une machine (inexistante) 10.11.12.13 :

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

Voici une sortie tcpdump qui prouve que le trafic est en cours :

[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

Voici la partie utile En utilisant netstat avec l'option -a (pour voir les détails du port) et l'option -p pour voir les détails de l'ID du processus. C'est l'option -p qui nécessite les privilèges de l'administrateur :

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

Comme vous pouvez le voir, le pid 9152 est identifié comme ayant une connexion ouverte au port 2345 sur l'hôte distant spécifié. Netstat passe également par ps et m'indique que le nom du processus est ncat .

J'espère que cela vous sera utile.

23voto

Jakov Sosic Points 5097

J'ai eu exactement le même problème et malheureusement auditd n'a pas fait grand-chose pour moi.

J'ai eu du trafic de certains de mes serveurs vers des adresses DNS de Google, 8.8.8.8 y 8.8.4.4 . Mon administrateur réseau a un léger trouble obsessionnel-compulsif et il voulait nettoyer tout le trafic inutile puisque nous avons nos caches DNS internes. Il voulait désactiver le port 53 sortant pour tout le monde sauf pour ces serveurs de cache.

Ainsi, après avoir échoué avec auditctl Je me plonge dans systemtap . J'obtiens le script suivant :

# 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

Il suffit ensuite de courir :

stap -v udp_detect_domain.stp

Voici le résultat que j'ai obtenu :

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

C'est tout ! Après avoir modifié resolv.conf ces PID n'ont pas pris en compte les changements.

J'espère que cela vous aidera :)

8voto

nikos.t Points 11

Voici une option systemtap, utilisant les sondes netfilter disponibles dans stap verson 1.8 et plus. Voir aussi 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

4voto

RedGrittyBrick Points 3782

J'utiliserais un renifleur de réseau comme tcpdump ou wireshark pour visualiser les requêtes DNS. Le contenu des requêtes peut donner une idée du programme qui les émet.

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X