linux – 如何找出发送数据包(生成网络流量)的进程的PID?

前端之家收集整理的这篇文章主要介绍了linux – 如何找出发送数据包(生成网络流量)的进程的PID?前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。
几个星期前,我遇到了一个问题,我在大约300个节点的大型网络中更改了DNS地址.之后,一些节点仍然继续询问旧的DNS服务器,虽然resolv.conf没问题,而host / nslookup正在查询新的DNS服务器.

看着tcpdump并试图用iptables日志记录来记录请求,我确认确实有些主机仍在向旧的名称服务器发送查询.

我把其中一台主机停止生产,并开始关闭服务/支撑过程,试图找出罪魁祸首.

最后 – 它是lldpd守护进程,它显然在启动时缓存了名称服务器,甚至没有注意到resolv.conf中的更改.

所以,我的问题是 – 是否有更智能的方法来找出哪个PId产生特定类型的流量?我尝试过auditctl,但没有取得多大成功. CentOS 6有问题,但如果有任何Linux发行版的解决方案,我将不胜感激.

解决方法

几天前我和同样的问题搏斗,并提出了一个非常简单的方法.它基于以下事实:发送进程将等待DNS响应来自它发送请求的同一端口:

>使用iptables -j LOG找出传出DNS请求的源端口
>使用lsof -i UDP:< source_port>找出哪个进程正在等待该端口的响应.

当然,当响应在几毫秒内到达时,你不能手动完成;此外,即使在自动化时,也无法保证在DNS响应到来之前您能够查询系统,并且发送过程终止.这就是为什么在执行上述步骤之前,我还配置内核流量控制器来延迟指向特定ip /端口的传出数据包(使用tc模块netem).这允许我在步骤1中获得的源UDP端口上控制我必须查询系统关于哪个PID等待DNS响应的时间窗口.

我已经在一个名为ptrap的小脚本中自动执行了上述步骤,包括tc延迟(这是一种更通用的解决方案,不限于DNS请求,因此有资格使用任何基于TCP / UDP的协议检测进程).在我的帮助下,我发现,在我的情况下,联系旧DNS服务器的服务是sendmail.

猜你在找的Linux相关文章