Solusi 1:
Audit Linux dapat membantu. Setidaknya akan menemukan pengguna dan proses membuat koneksi jaringan datagram. Paket UDP adalah datagram.
Pertama, instal auditd framework pada platform Anda dan pastikan bahwa auditctl -l mengembalikan sesuatu, bahkan jika dikatakan bahwa tidak ada aturan yang ditetapkan.
Kemudian, tambahkan aturan untuk mengawasi pemanggilan sistem socket() dan beri tag agar mudah ditemukan nanti (-k ). Saya perlu berasumsi bahwa Anda menggunakan arsitektur 64-bit, tetapi Anda dapat mengganti b32 di tempat b64 jika tidak.
auditctl -a exit,always -F arch=b64 -F a0=2 -F a1\&=2 -S socket -k SOCKET
Anda harus memilih melalui halaman manual dan file header untuk membuat ini, tetapi yang ditangkapnya pada dasarnya adalah panggilan sistem ini:socket(PF_INET, SOCK_DGRAM|X, Y) , di mana parameter ketiga tidak ditentukan tetapi seringkali nol. PF_INET adalah 2 dan SOCK_DGRAM adalah 2. Koneksi TCP akan menggunakan SOCK_STREAM yang akan menetapkan a1=1 . (SOCK_DGRAM pada parameter kedua dapat di-OR dengan SOCK_NONBLOCK atau SOCK_CLOEXEC , maka &= perbandingan.) -k SOCKET adalah kata kunci kami yang ingin kami gunakan saat mencari jejak audit nanti. Itu bisa apa saja, tapi saya ingin tetap sederhana.
Biarkan beberapa saat berlalu dan tinjau jejak audit. Secara opsional, Anda dapat memaksa beberapa paket dengan melakukan ping ke host di internet, yang akan menyebabkan pencarian DNS terjadi, yang menggunakan UDP, yang seharusnya menghentikan peringatan audit kami.
ausearch -i -ts today -k SOCKET
Dan output yang mirip dengan bagian di bawah ini akan muncul. Saya menyingkatnya untuk menyoroti bagian-bagian penting
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
Pada output di atas, kita dapat melihat bahwa ping perintah menyebabkan soket dibuka. Saya kemudian dapat menjalankan strace -p 14510 pada proses, jika masih berjalan. ppid (ID proses induk) juga dicantumkan jika itu adalah skrip yang sering memunculkan masalah anak.
Sekarang, jika Anda memiliki banyak lalu lintas UDP, ini tidak akan cukup baik dan Anda harus menggunakan OProfile atau SystemTap, keduanya saat ini berada di luar keahlian saya.
Ini akan membantu mempersempit segalanya dalam kasus umum.
Setelah selesai, hapus aturan audit dengan menggunakan baris yang sama dengan yang Anda gunakan untuk membuatnya, hanya ganti -a dengan -d .
auditctl -d exit,always -F arch=b64 -F a0=2 -F a1\&=2 -S socket -k SOCKET
Solusi 2:
Anda dapat menggunakan netstat, tetapi Anda memerlukan flag yang tepat, dan ini hanya berfungsi jika proses pengiriman data masih hidup. Itu tidak akan menemukan jejak sesuatu yang hidup sebentar, mengirim lalu lintas UDP, lalu pergi. Itu juga membutuhkan hak akses root lokal. Yang mengatakan:
Inilah saya memulai ncat di host lokal saya, mengirimkan lalu lintas UDP ke port 2345 pada mesin (tidak ada) 10.11.12.13:
[[email protected]]$ ncat -u 10.11.12.13 2345 < /dev/urandom
Inilah beberapa keluaran tcpdump yang membuktikan bahwa lalu lintas berjalan lancar:
[[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
Ini sedikit berguna , menggunakan netstat dengan flag -a (untuk melihat detail port) dan flag -p untuk melihat detail ID proses. Ini adalah flag -p yang membutuhkan hak akses root:
[[email protected] ~]# netstat -apn|grep -w 2345
udp 0 0 192.168.3.11:57550 10.11.12.13:2345 ESTABLISHED 9152/ncat
Seperti yang Anda lihat, pid 9152 dianggap memiliki koneksi terbuka ke port 2345 pada host jarak jauh yang ditentukan. Netstat dengan senang hati juga menjalankannya melalui ps dan memberi tahu saya bahwa nama prosesnya adalah ncat .
Semoga bermanfaat.
Solusi 3:
Saya memiliki masalah yang persis sama dan sayangnya auditd tidak berbuat banyak untukku.
Saya mendapat lalu lintas dari beberapa server saya menuju alamat Google DNS, 8.8.8.8 dan 8.8.4.4 . Sekarang, admin jaringan saya memiliki OCD ringan dan dia ingin membersihkan semua lalu lintas yang tidak perlu karena kami memiliki cache DNS internal kami. Dia ingin menonaktifkan port keluar 53 untuk semua orang kecuali server cache tersebut.
Jadi, setelah gagal dengan auditctl , saya menggali systemtap . Saya datang dengan skrip berikut:
# 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
Kemudian cukup jalankan:
stap -v udp_detect_domain.stp
Ini adalah output yang saya dapatkan:
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
Itu dia! Setelah mengubah resolv.conf PID tersebut tidak menerima perubahan.
Semoga ini membantu :)
Solusi 4:
Inilah opsi systemtap, menggunakan probe netfilter yang tersedia di stap versi 1.8 dan yang lebih baru. Lihat juga 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
Solusi 5:
Saya akan menggunakan net-sniffer seperti tcpdump atau wireshark untuk melihat permintaan DNS. Isi kueri dapat memberikan gambaran tentang program apa yang mengeluarkannya.