Bagaimana saya bisa mengidentifikasi proses mana yang membuat lalu lintas UDP di Linux?

Mesin saya terus membuat permintaan lalu lintas udp dns. apa yang perlu saya ketahui adalah PID dari proses menghasilkan lalu lintas ini.

Cara normal dalam koneksi TCP adalah menggunakan netstat / lsof dan mendapatkan proses yang terkait di pid.

Apakah UDP koneksi adalah stateles, jadi, ketika saya menelepon netastat / lsof, saya bisa melihatnya hanya jika soket UDP dibuka dan mengirimkan lalu lintas.

Saya telah mencoba dengan lsof -i UDPdan dengan nestat -anpue, tetapi saya tidak dapat menemukan proses yang melakukan permintaan itu karena saya perlu memanggil lsof / netstat tepat ketika lalu lintas udp dikirim, jika saya memanggil lsof / netstat sebelum / setelah datagram udp yang dikirim adalah mustahil untuk melihat soket UDP yang terbuka.

Panggil netstat / lsof persis ketika paket 3/4 udp dikirim adalah MUNGKIN.

Bagaimana saya bisa mengidentifikasi proses yang terkenal? Saya telah memeriksa lalu lintas untuk mencoba mengidentifikasi PID yang dikirim dari konten paket, tetapi tidak mungkin untuk mengidentifikasinya dari konteks lalu lintas.

Adakah yang bisa membantu saya?

Saya melakukan root pada mesin ini FEDORA 12 Linux noise.company.lan 2.6.32.16-141.fc12.x86_64 # 1 SMP Rabu 7 Jul 04:49:59 UTC 2010 x86_64 x86_64 x86_64 x86_64 GNU / Linux

Audit Linux dapat membantu. Setidaknya akan menemukan pengguna dan proses membuat koneksi jaringan datagram. Paket UDP adalah datagram.

Pertama, instal auditdkerangka kerja pada platform Anda dan pastikan itu auditctl -lmengembalikan sesuatu, bahkan jika dikatakan tidak ada aturan yang ditetapkan.

Kemudian, tambahkan aturan untuk menonton system call socket()dan menandainya agar mudah ditemukan nanti ( -k). Saya harus berasumsi bahwa Anda berada di arsitektur 64-bit, tetapi Anda dapat mengganti b32di tempat b64jika Anda tidak.

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

Anda harus memilih halaman manual dan file header untuk membangun ini, tetapi apa yang ditangkap pada dasarnya adalah panggilan sistem ini:, di socket(PF_INET, SOCK_DGRAM|X, Y)mana parameter ketiga tidak ditentukan tetapi sering nol. PF_INETadalah 2 dan SOCK_DGRAM2. Koneksi TCP akan digunakan SOCK_STREAMyang akan ditetapkan a1=1. ( SOCK_DGRAMpada parameter kedua dapat ORed dengan SOCK_NONBLOCKatau SOCK_CLOEXEC, karenanya &=perbandingan.) -k SOCKETAdalah kata kunci kami yang ingin kami gunakan saat mencari jejak audit nanti. Itu bisa apa saja, tapi saya suka membuatnya tetap sederhana.

Biarkan beberapa saat berlalu dan tinjau jejak audit. Secara opsional, Anda dapat memaksa beberapa paket dengan melakukan ping host keluar di internet, yang akan menyebabkan pencarian DNS terjadi, yang menggunakan UDP, yang seharusnya membuat trip 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 pingperintah menyebabkan soket dibuka. Saya kemudian bisa menjalankan strace -p 14510proses, jika masih berjalan. The ppid(induk proses ID) juga tercantum dalam kasus itu adalah script yang menumbuhkan masalah anak banyak.

Sekarang, jika Anda memiliki banyak lalu lintas UDP, ini tidak akan cukup baik dan Anda harus menggunakan OProfile atau SystemTap , yang keduanya saat ini di luar keahlian saya.

Ini harus membantu mempersempit hal-hal dalam kasus umum.

Setelah selesai, hapus aturan audit dengan menggunakan baris yang sama dengan yang Anda gunakan untuk membuatnya, ganti saja -adengan -d.

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

Anda dapat menggunakan netstat, tetapi Anda memerlukan flag yang tepat, dan itu hanya berfungsi jika proses yang mengirim data masih hidup. Ia tidak akan menemukan jejak sesuatu yang hidup sebentar, mengirimkan lalu lintas UDP, lalu pergi. Ini juga membutuhkan hak akses root lokal. Yang mengatakan:

Inilah saya memulai ncat pada host lokal saya, mengirimkan lalu lintas UDP ke port 2345 pada mesin (tidak ada) 10.11.12.13:

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

Berikut ini beberapa output tcpdump yang membuktikan bahwa traffic berjalan:

[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

Inilah bit yang bermanfaat , 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:

[root@risby ~]# netstat -apn|grep -w 2345
udp        0      0 192.168.3.11:57550          10.11.12.13:2345            ESTABLISHED 9152/ncat     

Seperti yang dapat Anda lihat, pid 9152 dianggap memiliki koneksi terbuka ke port 2345 pada host jarak jauh yang ditentukan. Netstat juga membantu menjalankannya melalui ps dan memberi tahu saya nama prosesnya ncat.

Semoga itu berguna.

Saya memiliki masalah yang persis sama dan sayangnya auditdtidak banyak membantu saya.

Saya memiliki lalu lintas dari beberapa server saya menuju alamat Google DNS, 8.8.8.8dan 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 intern kami. Dia ingin menonaktifkan port keluar 53 untuk semua orang kecuali server cache itu.

Jadi, setelah gagal 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 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.confPID tersebut tidak mengambil perubahan.

Semoga ini membantu :)

Inilah opsi systemtap, menggunakan probe netfilter yang tersedia di stap verson 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

Saya akan menggunakan net-sniffer seperti tcpdump atau wireshark untuk melihat permintaan DNS. Isi kueri dapat memberikan gambaran tentang program apa yang mengeluarkannya.

Perlu diketahui bahwa saat menggunakan autitctl, nscd misalnya menggunakan parameter yang sedikit berbeda dalam panggilan sistem soket, saat melakukan permintaan DNS:

socket(AF_INET, SOCK_DGRAM|SOCK_NONBLOCK, IPPROTO_IP)

Jadi untuk memastikan Anda menangkap kueri itu selain dari yang disebutkan di atas, Anda dapat menambahkan filter tambahan, dengan nama yang sama jika Anda mau:

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

Di sini 2050 adalah bitwise OR dari SOCK_DGRAM (2) dan SOCK_NONBLOCK (2048).

Maka pencarian akan menemukan baik yang filter dengan tombol yang sama, SOCKET:

ausearch -i -ts today -k SOCKET

Nilai hex untuk konstanta soket yang saya temukan di sini: https://golang.org/pkg/syscall/#pkg-constants

Karena saya tidak punya poin reputasi untuk berkomentar saya menambahkan ini.