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


ma machine fait continuellement des demandes de trafic udp dns. Ce que j'ai besoin de savoir, c'est le PID du processus générant ce trafic.

La méthode normale dans une connexion TCP consiste à utiliser netstat / lsof et à associer le processus au pid.

UDP est-il la connexion est-elle stateles, donc, quand j'appelle netastat / lsof, je ne peux le 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 ne peux pas trouver le processus qui fait cette demande car je dois appeler lsof / netstat exactement quand le trafic udp est envoyé, si j'appelle lsof / netstat avant / Après l'envoi du datagramme UDP, il est impossible de visualiser le socket UDP ouvert.

appeler netstat / lsof exactement quand 3/4 paquet udp est envoyé 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.

Est-ce que quelqu'un peut 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 7 Juillet 04:49:59 UTC 2010 x86_64 x86_64 x86_64 GNU / Linux


40
2017-10-20 10:41


origine




Réponses:


L'audit Linux peut aider. Il permettra au moins de localiser les utilisateurs et les processus établissant des connexions réseau datagrammes. Les paquets UDP sont des datagrammes.

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

Ensuite, ajoutez une règle pour regarder l'appel système socket() et marquez-le pour trouver plus tard (-k). Je dois supposer que vous utilisez une architecture 64 bits, mais vous pouvez remplacer 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 choisir parmi les pages de manuel et les fichiers d'en-tête pour construire ceci, mais ce qu'il capture est essentiellement cet appel système: socket(PF_INET, SOCK_DGRAM|X, Y), où le troisième paramètre est non spécifié mais souvent égal à zéro. PF_INET est 2 et SOCK_DGRAM est 2. Les connexions TCP utiliseraient SOCK_STREAM qui définirait a1=1. (SOCK_DGRAM dans le deuxième paramètre peut être ORed avec SOCK_NONBLOCK ou SOCK_CLOEXEC, d'où le &= comparaison.) Le -k SOCKET est notre mot clé que nous souhaitons utiliser lors de la recherche ultérieure de pistes d'audit. Cela peut être n'importe quoi, mais j'aime rester simple.

Laissez passer quelques instants et passez en revue les pistes d'audit. Vous pouvez éventuellement forcer deux ou trois paquets en envoyant une requête ping à un hôte sur le réseau, ce qui provoquera une recherche DNS, qui utilise UDP, ce qui devrait déclencher notre alerte d'audit.

ausearch -i -ts today -k SOCKET

Et une sortie similaire à la section ci-dessous apparaîtra. Je l'abrévie 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 la sortie ci-dessus, nous pouvons voir que le ping La commande a provoqué l’ouverture du socket. Je pourrais alors courir strace -p 14510 sur le processus, s'il était toujours en cours d'exécution. le ppid (ID de processus parent) est également répertorié dans le cas où il s’agit d’un script qui engendre beaucoup l’enfant à problème.

Maintenant, si vous avez beaucoup de trafic UDP, cela ne suffira pas et vous devrez recourir à OProfile ou SystemTap, les deux sont actuellement au-delà de mon expertise.

Cela devrait aider à préciser les choses dans le cas général.

Lorsque vous avez terminé, supprimez la règle d’audit en utilisant la même ligne que celle utilisée pour la créer. Remplacez uniquement la règle. -a avec -d.

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

44
2017-10-20 18:41



Je vais l'essayer, mais je pense que c'est la bonne réponse. - boos
Cela ne capte pas le trafic laissé par iptables, du moins pour moi. - 2rs2ts
+1 pour la simplicité par rapport à la méthode systemtap (qui est plus analytique, mais nécessite des paquetages de développement du noyau) - basos


Vous pouvez utiliser netstat, mais vous avez besoin des bons indicateurs et cela ne fonctionne que si le processus qui envoie les données est toujours actif. Il ne trouvera pas les traces de quelque chose qui est brièvement apparu, qui a envoyé du trafic UDP, puis est parti. Il nécessite également des privilèges root locaux. Cela dit:

Voici comment démarrer un ncat sur mon hôte local et envoyer du trafic UDP au port 2345 sur une machine (non existante) 10.11.12.13:

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

Voici une sortie de tcpdump prouvant 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 le bit utile, en utilisant netstat avec le drapeau -a (pour voir les détails du port) et le drapeau -p pour voir les détails du processus. C'est l'indicateur -p qui nécessite les privilèges root:

[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 constater, l’identifiant de connexion du pid 9152 est ouvert sur le port 2345 de l’hôte distant spécifié. Netstat fonctionne également de manière utile par le biais de ps et me dit que le nom du processus est ncat.

J'espère que c'est utile.


22
2017-10-20 11:49



vraiment sympa fait! :Pouce en l'air: - ThorstenS
Il y a une prise cependant. Si le problème est causé par un script shell générant un sous-processus qui effectue la recherche DNS et que ce processus se termine rapidement, le port source (57550 ci-dessus) est modifié en permanence. Dans ce cas, la technique ne fonctionnera pas et vous devrez prendre des mesures plus drastiques. En outre, votre netstat aurait dû effectuer une grep -w 57550 parce que plusieurs processus pourraient effectuer des recherches DNS sur le même serveur. Votre méthode ne les distinguerait pas. - zerolagtime
Je suis d’accord avec vos deux objections, zerolagtime (mais merci pour vos aimables paroles, ThorstenS!). - MadHatter


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

Le trafic de certains de mes serveurs me dirigeait vers des adresses DNS Google, 8.8.8.8 et 8.8.4.4. Maintenant, mon administrateur réseau a un OCD léger et il voulait nettoyer tout le trafic inutile depuis que nous avons nos caches DNS internes. Il voulait désactiver le port sortant 53 pour tout le monde, sauf pour les serveurs de cache.

Donc, après avoir échoué avec auditctl, Je creuse dans systemtap. Je viens avec 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

Puis lancez simplement:

stap -v udp_detect_domain.stp

Voici le résultat 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 changé resolv.conf ces PID n'ont pas détecté les modifications.


J'espère que cela t'aides :)


13
2018-04-16 20:39





Je voudrais utiliser un net-sniffer comme tcpdump ou Wireshark pour afficher les requêtes DNS. Le contenu de la requête peut donner une idée du programme qui les publie.


4
2017-10-20 10:46



aucune information dans le trafic reniflé je viens de voir déjà. - boos
Pas d'information? Des paquets vides? Ce que je voulais dire, c’est que si quelque chose tente de résoudre updates.java.sun.com ou rss.cnn.com, vous pouvez en déduire quelque chose. - RedGrittyBrick
Requête DNS à la recherche du proxy interne. En ce moment, je trouve quel processus est, mais la question reste en suspens pour une technique de résolution de problèmes générale - boos
lsof -i | awk '/ UDP /' - c4f4t0r


Voici une option systemap, utilisant les sondes Netfilter disponibles dans les versions 1.8 et supérieures de stap. Voir également 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





Sachez que lorsque vous utilisez autitctl, nscd, par exemple, utilise un paramètre légèrement différent dans l'appel système du socket, lors d'une requête DNS:

socket(AF_INET, SOCK_DGRAM|SOCK_NONBLOCK, IPPROTO_IP)

Vous pouvez donc ajouter un filtre supplémentaire, portant le même nom si vous le souhaitez, pour que ces requêtes puissent s'afficher en plus de celles mentionnées ci-dessus:

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

Ici 2050 est un OU de bitwise SOCK_DGRAM (2) et SOCK_NONBLOCK (2048).

Ensuite, la recherche trouvera ces deux filtres avec la même clé, SOCKET:

ausearch -i -ts today -k SOCKET

Les valeurs hexadécimales pour les constantes de socket que j'ai trouvées ici: https://golang.org/pkg/syscall/#pkg-constants

Comme je n'ai aucun point de réputation à commenter, j'ai ajouté ceci.


3
2017-10-17 12:53