我想有一个类似tcpdump的程序,它显示哪个程序发送了一个特定的数据包,而不是只获取端口号.这是一个常见的问题,有时当你有旧的tcpdump文件在你身边,你无法找到什么程序发送该数据时,我已经开关.
how i can identify which process is making UDP traffic on linux ?中的解决方案表明我可以使用auditd,dTrace,OProfile或SystemTap解决此问题,但未显示如何执行此操作.即它不显示调用bind()的程序的源端口..
我遇到的问题是奇怪的UDP数据包,由于这些端口很短暂,我花了一段时间来解决这个问题.我通过运行类似于以下的丑陋黑客来解决这个问题：
while true; date +%s.%N;netstat -panut;done
所以要么是比这个hack更好的方法,替换tcpdump,要么从内核获取此信息,以便我可以修补tcpdump.
用auditd解决这个问题
sudo auditctl -a exit,always -F arch=b64 -S bind -k BIND
这将使用以下行填充/var/log/audit/audit.log：
type=SYSCALL msg=audit(1292929028.845:3377): arch=c000003e syscall=49 success=yes exit=0 a0=3 a1=808710 a2=10 a3=7fffab28ea10 items=0 ppid=1564 pid=24442 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts1 ses=4294967295 comm="nc" exe="/bin/nc.openbsd" key="BIND" type=SOCKADDR msg=audit(1292929028.845:3377): saddr=0200FFFF000000000000000000000000
然后解析saddr = 0200xxxx00,其中xxxx是端口号,0001是最低值,FFFF是最高值.
编辑：这是超级用户“tracking what programs sends to net”问的,虽然没有好的解决方案.
解决方法
有关发送数据包的过程的信息(即使它来自本地机器)对tcpdump不可用,因为它不是由内核的数据包捕获接口提供的……
在 http://www.tcpdump.org/pcap3_man.html上搜索“DLT_LINUX_SLL”
在 http://www.tcpdump.org/pcap3_man.html上搜索“DLT_LINUX_SLL”
改变这肯定是一个相当复杂的内核黑客任务……
最接近解决方案似乎是iptable的“所有者”匹配模块,它支持通过user-id匹配数据包(在某些Linux版本中也是process-id,后来删除了该功能的iirc),以及–log-uid(遗憾地) LOG目标没有–log-pid)选项.
所以,当你添加一个iptables规则时：
iptables -I OUTPUT -p tcp –syn -j LOG –log-prefix“new tcp connection：” – log-uid
你得到一个日志(在你的内核日志中,又名dmesg)所有新建立的连接及其源端口和用户ID,这样你就可以得到一个连接用户的地图,而无需轮询netstat ……
