Soluzione 1:
Il controllo di Linux può essere d'aiuto. Individuerà almeno utenti e processi che effettuano connessioni di rete di datagrammi. I pacchetti UDP sono datagrammi.
Innanzitutto, installa auditd framework sulla tua piattaforma e assicurati che auditctl -l restituisce qualcosa, anche se dice che non sono definite regole.
Quindi, aggiungi una regola per controllare la chiamata di sistema socket() e contrassegnalo per trovarlo facilmente in seguito (-k ). Devo presumere che tu sia su un'architettura a 64 bit, ma puoi sostituire b32 al posto del b64 se non lo sei.
auditctl -a exit,always -F arch=b64 -F a0=2 -F a1\&=2 -S socket -k SOCKET
Devi selezionare le pagine man e i file di intestazione per crearlo, ma ciò che cattura è essenzialmente questa chiamata di sistema:socket(PF_INET, SOCK_DGRAM|X, Y) , dove il terzo parametro non è specificato ma spesso zero. PF_INET è 2 e SOCK_DGRAM è 2. Le connessioni TCP userebbero SOCK_STREAM che imposterebbe a1=1 . (SOCK_DGRAM nel secondo parametro può essere messo in OR con SOCK_NONBLOCK o SOCK_CLOEXEC , da cui il &= confronto.) Il -k SOCKET è la nostra parola chiave che vogliamo utilizzare durante la ricerca degli audit trail in un secondo momento. Può essere qualsiasi cosa, ma mi piace mantenere le cose semplici.
Lascia passare qualche momento e rivedi gli audit trail. Facoltativamente, puoi forzare un paio di pacchetti eseguendo il ping di un host in rete, che causerà una ricerca DNS, che utilizza UDP, che dovrebbe far scattare il nostro avviso di controllo.
ausearch -i -ts today -k SOCKET
E apparirà un output simile alla sezione sottostante. Lo sto abbreviando per evidenziare le parti importanti
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
Nell'output sopra, possiamo vedere che ping comando ha causato l'apertura del socket. Potrei quindi eseguire strace -p 14510 sul processo, se era ancora in esecuzione. Il ppid (ID processo padre) è elencato anche nel caso in cui si tratti di uno script che genera spesso il figlio problematico.
Ora, se hai molto traffico UDP, questo non sarà abbastanza buono e dovrai ricorrere a OProfile o SystemTap, entrambi attualmente al di fuori delle mie competenze.
Questo dovrebbe aiutare a restringere il campo nel caso generale.
Quando hai finito, rimuovi la regola di controllo usando la stessa riga che hai usato per crearla, sostituisci solo -a con -d .
auditctl -d exit,always -F arch=b64 -F a0=2 -F a1\&=2 -S socket -k SOCKET
Soluzione 2:
Puoi usare netstat, ma hai bisogno dei flag giusti e funziona solo se il processo che sta inviando i dati è ancora attivo. Non troverà le tracce di qualcosa che ha preso vita brevemente, ha inviato traffico UDP e poi è andato via. Richiede anche i privilegi di root locale. Detto questo:
Ecco io che avvio un ncat sul mio host locale, inviando traffico UDP alla porta 2345 su una macchina (inesistente) 10.11.12.13:
[[email protected]]$ ncat -u 10.11.12.13 2345 < /dev/urandom
Ecco un output di tcpdump che dimostra che il traffico sta andando:
[[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
Ecco la parte utile , utilizzando netstat con il flag -a (per vedere i dettagli della porta) e il flag -p per vedere i dettagli dell'ID del processo. È il flag -p che richiede i privilegi di root:
[[email protected] ~]# netstat -apn|grep -w 2345
udp 0 0 192.168.3.11:57550 10.11.12.13:2345 ESTABLISHED 9152/ncat
Come puoi vedere, pid 9152 viene contrassegnato come avente una connessione aperta alla porta 2345 sull'host remoto specificato. Netstat lo esegue anche tramite ps e mi dice che il nome del processo è ncat .
Speriamo che sia di qualche utilità.
Soluzione 3:
Ho avuto esattamente lo stesso problema e sfortunatamente auditd non ha fatto molto per me.
Ho ricevuto traffico da alcuni dei miei server diretto agli indirizzi DNS di Google, 8.8.8.8 e 8.8.4.4 . Ora, il mio amministratore di rete ha un lieve disturbo ossessivo compulsivo e voleva pulire tutto il traffico non necessario poiché abbiamo le nostre cache DNS interne. Voleva disabilitare la porta in uscita 53 per tutti tranne che per quei server di cache.
Quindi, dopo aver fallito con auditctl , approfondisco systemtap . Mi viene in mente il seguente 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
Quindi esegui semplicemente:
stap -v udp_detect_domain.stp
Questo è l'output che ho ottenuto:
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
Questo è tutto! Dopo aver cambiato resolv.conf quei PID non hanno rilevato le modifiche.
Spero che questo aiuti :)
Soluzione 4:
Ecco un'opzione systemtap, che utilizza le sonde netfilter disponibili in stap versione 1.8 e successive. Vedi anche 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
Soluzione 5:
Userei un net-sniffer come tcpdump o wireshark per visualizzare le richieste DNS. Il contenuto della query può dare un'idea di quale programma le sta emettendo.