SS

Question

首先，我会注意到您共享的进程树中对 ntop 的调用似乎没有该-n标志：

/usr/sbin/ntop -d -L -u ntop -P /var/lib/ntop --access-log-file /var/log/ntop/access.log -i venet0:0 -p /etc/ntop/protocol.list -O /var/log/ntop

但我认为鉴于您关于即使 ntop 被杀死查询仍在继续的陈述，这不是问题。此外，为了澄清，我假设执行查找的机器与处理端口 80 上的请求是同一台机器。

鉴于此，以下是一些调试思路：

SS

如果相关程序将套接字保留一段时间，您可能可以使用ss（或 netstat）和该-p标志来查找您应该在 tcpdump 中看到的源端口的所有者。

斯特雷斯

第一个嫌疑人应该是处理请求的应用程序。我假设屏幕下运行的以下 python 进程是您正在测试的应用程序？

 `- SCREEN -AmdS py-http authbind python server.py ---scr:py-http
|  `- python server.py ---scr:py-http

您可以考虑在 strace 下运行此进程并查看它是否正在生成 DNS 流量。例如：

strace -e trace=sendmsg,sendto -f YOUR_PROGRAM_HERE

然后仔细查看输出中是否有看起来像是发送到端口 53 的消息：

[pid  3367] sendmsg(20, {msg_name(16)={sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("192.168.1.254")}, msg_iov(1)=[{"\31\322\1\0\0\1\0\0\0\0\0\0\0014\0014\0018\0018\7in-addr\4arp"..., 38}], msg_controllen=0, msg_flags=0}, 0) = 38

ss 循环

如果相关程序快速关闭其套接字，则可能很难从 ss 或 netstat 获取有关它的信息。

然而，我们的一种可能性是编写一个ss重复轮询命令的脚本。你可以打赌你足够幸运，能够捕获其中一个查找：

while true; do ss -p -n -u | tail -n +2; done

如果您在该计算机上看到大量其他 UDP 流量，可以向 ss 命令添加过滤器来缩小范围。这是否有效取决于你的运气。

系统挖掘

您可以使用相对较新的sysdig查看所有 sendmsg 或 sendto 系统调用的实用程序：

sudo sysdig evt.type=sendmsg or evt.type=sendto | grep ':53'

输出将包含进程名称（在本例中为 nslookup）：

47852 01:15:33.454946732 4 nslookup (3349) > sendmsg fd=20(<4>) size=38 tuple=0.0.0.0:49847->192.168.1.254:53

iptables

iptables 允许您记录生成数据包的进程的用户 ID。如果您的大多数服务都以同一用户身份运行，则这不会有太大帮助，但如果您有特定于服务的用户，则可能会很有帮助。一组iptable规则如下：

iptables -N LOGGING
iptables -A OUTPUT -p udp --dport 53 -j LOGGING
iptables -A LOGGING -j LOG --log-prefix="DNS Traffic match:" --log-uid

将记录具有关联 UID 的所有出站 dns 流量。根据您的日志记录设置，您可以通过 kmesg 或系统日志消息所在的位置找到此信息，输出将类似于：

Oct 24 01:09:53 localhost.localdomain kernel: DNS Traffic match:IN= OUT=enp0s3 SRC=10.0.2.15 DST=192.168.1.254 LEN=66 TOS=0x00 PREC=0x00 TTL=64 ID=35264 PROTO=UDP SPT=51767 DPT=53 LEN=46 UID=1000 GID=1000

从这个输出中我可以看到相关进程的 UID 为 1000，这至少缩小了我的搜索范围。

Answer 1

首先，我会注意到您共享的进程树中对 ntop 的调用似乎没有该-n标志：

/usr/sbin/ntop -d -L -u ntop -P /var/lib/ntop --access-log-file /var/log/ntop/access.log -i venet0:0 -p /etc/ntop/protocol.list -O /var/log/ntop

但我认为鉴于您关于即使 ntop 被杀死查询仍在继续的陈述，这不是问题。此外，为了澄清，我假设执行查找的机器与处理端口 80 上的请求是同一台机器。

鉴于此，以下是一些调试思路：

SS

如果相关程序将套接字保留一段时间，您可能可以使用ss（或 netstat）和该-p标志来查找您应该在 tcpdump 中看到的源端口的所有者。

斯特雷斯

第一个嫌疑人应该是处理请求的应用程序。我假设屏幕下运行的以下 python 进程是您正在测试的应用程序？

 `- SCREEN -AmdS py-http authbind python server.py ---scr:py-http
|  `- python server.py ---scr:py-http

您可以考虑在 strace 下运行此进程并查看它是否正在生成 DNS 流量。例如：

strace -e trace=sendmsg,sendto -f YOUR_PROGRAM_HERE

然后仔细查看输出中是否有看起来像是发送到端口 53 的消息：

[pid  3367] sendmsg(20, {msg_name(16)={sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("192.168.1.254")}, msg_iov(1)=[{"\31\322\1\0\0\1\0\0\0\0\0\0\0014\0014\0018\0018\7in-addr\4arp"..., 38}], msg_controllen=0, msg_flags=0}, 0) = 38

ss 循环

如果相关程序快速关闭其套接字，则可能很难从 ss 或 netstat 获取有关它的信息。

然而，我们的一种可能性是编写一个ss重复轮询命令的脚本。你可以打赌你足够幸运，能够捕获其中一个查找：

while true; do ss -p -n -u | tail -n +2; done

如果您在该计算机上看到大量其他 UDP 流量，可以向 ss 命令添加过滤器来缩小范围。这是否有效取决于你的运气。

系统挖掘

您可以使用相对较新的sysdig查看所有 sendmsg 或 sendto 系统调用的实用程序：

sudo sysdig evt.type=sendmsg or evt.type=sendto | grep ':53'

输出将包含进程名称（在本例中为 nslookup）：

47852 01:15:33.454946732 4 nslookup (3349) > sendmsg fd=20(<4>) size=38 tuple=0.0.0.0:49847->192.168.1.254:53

iptables

iptables 允许您记录生成数据包的进程的用户 ID。如果您的大多数服务都以同一用户身份运行，则这不会有太大帮助，但如果您有特定于服务的用户，则可能会很有帮助。一组iptable规则如下：

iptables -N LOGGING
iptables -A OUTPUT -p udp --dport 53 -j LOGGING
iptables -A LOGGING -j LOG --log-prefix="DNS Traffic match:" --log-uid

将记录具有关联 UID 的所有出站 dns 流量。根据您的日志记录设置，您可以通过 kmesg 或系统日志消息所在的位置找到此信息，输出将类似于：

Oct 24 01:09:53 localhost.localdomain kernel: DNS Traffic match:IN= OUT=enp0s3 SRC=10.0.2.15 DST=192.168.1.254 LEN=66 TOS=0x00 PREC=0x00 TTL=64 ID=35264 PROTO=UDP SPT=51767 DPT=53 LEN=46 UID=1000 GID=1000

从这个输出中我可以看到相关进程的 UID 为 1000，这至少缩小了我的搜索范围。

SS

答案1

SS

斯特雷斯

ss 循环

系统挖掘

iptables

相关内容