Solution 1 :
L'audit Linux peut aider. Il localisera au moins les utilisateurs et les processus établissant des connexions réseau datagramme. Les paquets UDP sont des datagrammes.
Tout d'abord, installez le auditd framework sur votre plateforme 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 surveiller l'appel système socket() et étiquetez-le pour le retrouver facilement plus tard (-k ). Je dois supposer que vous êtes sur une architecture 64 bits, mais vous pouvez remplacer b32 à la place du b64 si ce n'est pas le cas.
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 créer cela, 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 indéterminé mais souvent nul. 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 voulons 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. Facultativement, vous pouvez forcer quelques paquets en envoyant un ping à un hôte sur le net, ce qui entraînera 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è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 la sortie ci-dessus, nous pouvons voir que le ping La commande a provoqué l'ouverture du socket. Je pourrais alors exécuter 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é au cas où il s'agirait d'un script qui génère souvent l'enfant problématique.
Maintenant, si vous avez beaucoup de trafic UDP, cela ne suffira pas et vous devrez recourir à OProfile ou SystemTap, qui dépassent actuellement mon expertise.
Cela devrait aider à réduire 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 vous avez utilisée pour la créer, remplacez uniquement -a avec -d .
auditctl -d exit,always -F arch=b64 -F a0=2 -F a1\&=2 -S socket -k SOCKET
Solution 2 :
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 actif. Il ne trouvera pas les traces de quelque chose qui est venu brièvement à la vie, a envoyé du trafic UDP, puis est parti. Il nécessite également des privilèges root locaux. Cela dit :
Me voici en train de démarrer un ncat sur mon hôte local, envoyant le trafic UDP au port 2345 sur une machine (inexistante) 10.11.12.13 :
[[email protected]]$ ncat -u 10.11.12.13 2345 < /dev/urandom
Voici une sortie tcpdump prouvant que le trafic est en cours :
[[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
Voici la partie utile , en utilisant netstat avec l'indicateur -a (pour voir les détails du port) et l'indicateur -p pour voir les détails de l'ID de processus. C'est le drapeau -p qui nécessite les privilèges root :
[[email protected] ~]# 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 signalé comme ayant une connexion ouverte au port 2345 sur l'hôte distant spécifié. Netstat exécute également utilement cela via ps et me dit que le nom du processus est ncat .
J'espère que cela vous sera utile.
Solution 3 :
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 Google, 8.8.8.8 et 8.8.4.4 . Maintenant, mon administrateur réseau a un léger TOC et il voulait nettoyer tout le trafic inutile puisque nous avons nos caches DNS internes. Il voulait désactiver le port sortant 53 pour tout le monde sauf ces serveurs de cache.
Donc, après avoir échoué avec auditctl , je fouille dans systemtap . Je propose 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
Ensuite, lancez simplement :
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 ça! Après avoir changé resolv.conf ces PID n'ont pas pris en compte les modifications.
J'espère que cela vous aidera :)
Solution 4 :
Voici une option systemtap, utilisant les sondes netfilter disponibles dans stap version 1.8 et versions ultérieures. 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
Solution 5 :
J'utiliserais un renifleur de réseau 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 émet.