Solución 1:
La auditoría de Linux puede ayudar. Al menos localizará a los usuarios y procesos que realizan conexiones de red de datagramas. Los paquetes UDP son datagramas.
Primero, instala el auditd framework en su plataforma y asegúrese de que auditctl -l devuelve algo, incluso si dice que no hay reglas definidas.
Luego, agregue una regla para ver la llamada del sistema socket() y etiquételo para encontrarlo fácilmente más tarde (-k ). Debo asumir que está en una arquitectura de 64 bits, pero puede sustituir b32 en lugar del b64 si no lo eres.
auditctl -a exit,always -F arch=b64 -F a0=2 -F a1\&=2 -S socket -k SOCKET
Tienes que elegir entre las páginas de manual y los archivos de encabezado para construir esto, pero lo que captura es esencialmente esta llamada al sistema:socket(PF_INET, SOCK_DGRAM|X, Y) , donde el tercer parámetro no se especifica pero con frecuencia es cero. PF_INET es 2 y SOCK_DGRAM es 2. Las conexiones TCP usarían SOCK_STREAM que establecería a1=1 . (SOCK_DGRAM en el segundo parámetro puede ser ORed con SOCK_NONBLOCK o SOCK_CLOEXEC , de ahí el &= comparación). El -k SOCKET es nuestra palabra clave que queremos usar cuando busquemos pistas de auditoría más adelante. Puede ser cualquier cosa, pero me gusta mantenerlo simple.
Deje pasar unos momentos y revise los registros de auditoría. Opcionalmente, puede forzar un par de paquetes haciendo ping a un host en la red, lo que provocará que se produzca una búsqueda de DNS, que utiliza UDP, lo que debería activar nuestra alerta de auditoría.
ausearch -i -ts today -k SOCKET
Y aparecerá una salida similar a la siguiente sección. Lo estoy abreviando para resaltar las partes 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
En el resultado anterior, podemos ver que ping El comando hizo que se abriera el zócalo. Entonces podría ejecutar strace -p 14510 en el proceso, si aún se estaba ejecutando. El ppid (ID del proceso principal) también se incluye en caso de que sea un script que genere mucho el problema secundario.
Ahora, si tiene mucho tráfico UDP, esto no será lo suficientemente bueno y tendrá que recurrir a OProfile o SystemTap, los cuales actualmente están más allá de mi experiencia.
Esto debería ayudar a reducir las cosas en el caso general.
Cuando haya terminado, elimine la regla de auditoría usando la misma línea que usó para crearla, solo sustituya -a con -d .
auditctl -d exit,always -F arch=b64 -F a0=2 -F a1\&=2 -S socket -k SOCKET
Solución 2:
Puede usar netstat, pero necesita las banderas correctas, y solo funciona si el proceso que envía los datos todavía está activo. No encontrará los rastros de algo que cobró vida brevemente, envió tráfico UDP y luego desapareció. También requiere privilegios de raíz local. Dicho esto:
Aquí estoy iniciando un ncat en mi host local, enviando tráfico UDP al puerto 2345 en una máquina (inexistente) 10.11.12.13:
[[email protected]]$ ncat -u 10.11.12.13 2345 < /dev/urandom
Aquí hay algunos resultados de tcpdump que prueban que el tráfico va:
[[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
Aquí está la parte útil , utilizando netstat con el indicador -a (para ver los detalles del puerto) y el indicador -p para ver los detalles del ID del proceso. Es el indicador -p que requiere privilegios de root:
[[email protected] ~]# netstat -apn|grep -w 2345
udp 0 0 192.168.3.11:57550 10.11.12.13:2345 ESTABLISHED 9152/ncat
Como puede ver, se indica que el pid 9152 tiene una conexión abierta al puerto 2345 en el host remoto especificado. Netstat también lo ejecuta a través de ps y me dice que el nombre del proceso es ncat .
Esperemos que sea de alguna utilidad.
Solución 3:
Tuve exactamente el mismo problema y desafortunadamente auditd no hizo mucho por mí.
Tenía tráfico de algunos de mis servidores que se dirigía a las direcciones DNS de Google, 8.8.8.8 y 8.8.4.4 . Ahora, mi administrador de red tiene TOC leve y quería limpiar todo el tráfico innecesario ya que tenemos nuestras cachés de DNS internas. Quería deshabilitar el puerto de salida 53 para todos excepto para los servidores de caché.
Entonces, después de fallar con auditctl , profundizo en systemtap . Se me ocurre el siguiente script:
# 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
Luego simplemente ejecuta:
stap -v udp_detect_domain.stp
Este es el resultado que obtuve:
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
¡Eso es todo! Después de cambiar resolv.conf esos PID no detectaron los cambios.
Espero que esto ayude :)
Solución 4:
Aquí hay una opción systemtap, usando las sondas netfilter disponibles en stap versión 1.8 y posteriores. Ver también 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
Solución 5:
Usaría un rastreador de red como tcpdump o wireshark para ver las solicitudes de DNS. El contenido de la consulta puede dar una idea de qué programa los está emitiendo.