Primeiro, observarei que a invocação de ntop na árvore de processos compartilhada não parece ter o sinalizador -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
mas presumo que, dadas as suas declarações sobre as consultas continuando mesmo com ntop morto, que não é o problema. Além disso, para esclarecer, estou assumindo que a máquina que faz as pesquisas é a mesma máquina que manipula as solicitações na porta 80.
Considerando que, a seguir, algumas ideias de depuração:
ss
Se o programa em questão está mantendo o socket por um tempo, você pode usar ss (ou netstat) com o -p flag para encontrar o dono da porta de origem que você deveria estar vendo em seus tcpdumps .
Strace
O primeiro suspeito deve ser o aplicativo que manipula as solicitações. Estou assumindo que o seguinte processo python em execução na tela é o aplicativo que você está testando?
'- SCREEN -AmdS py-http authbind python server.py ---scr:py-http
| '- python server.py ---scr:py-http
Você pode considerar a execução desse processo sob strace e verificar se está gerando o tráfego DNS. Por exemplo, algo como:
strace -e trace=sendmsg,sendto -f YOUR_PROGRAM_HERE
e, em seguida, analisando cuidadosamente a saída de mensagens que parecem ter sido enviadas para a porta 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)=[{"2while true; do ss -p -n -u | tail -n +2; done
sudo sysdig evt.type=sendmsg or evt.type=sendto | grep ':53'
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 -N LOGGING
iptables -A OUTPUT -p udp --dport 53 -j LOGGING
iptables -A LOGGING -j LOG --log-prefix="DNS Traffic match:" --log-uid
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
/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
'- SCREEN -AmdS py-http authbind python server.py ---scr:py-http
| '- python server.py ---scr:py-http
strace -e trace=sendmsg,sendto -f YOUR_PROGRAM_HERE
[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)=[{"2while true; do ss -p -n -u | tail -n +2; done
sudo sysdig evt.type=sendmsg or evt.type=sendto | grep ':53'
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 -N LOGGING
iptables -A OUTPUT -p udp --dport 53 -j LOGGING
iptables -A LOGGING -j LOG --log-prefix="DNS Traffic match:" --log-uid
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
%pre%%pre%%pre%%pre%14%pre%14%pre%18%pre%18in-addrarp"..., 38}], msg_controllen=0, msg_flags=0}, 0) = 38
14%pre%14%pre%18%pre%18in-addrarp"..., 38}], msg_controllen=0, msg_flags=0}, 0) = 38
ss em um loop
Se o programa em questão estiver fechando rapidamente seu soquete, pode ser difícil obter informações sobre ele a partir do ss ou do netstat.
No entanto, uma possibilidade é escrever um script que pesquisa o comando ss repetidamente. Você estaria apostando em ter a sorte de pegar uma das pesquisas:
Você pode adicionar um filtro ao comando ss para reduzi-lo se vir muitos outros tráfego UDP nessa máquina. Se isso funciona ou não depende de você ter sorte.
Sysdig
Você pode usar o utilitário sysdig relativamente novo para ver todas as chamadas sendmsg ou sendto:
E a saída terá o nome do processo (neste caso, nslookup):
%pre%iptables
iptables permite que você registre o userid do processo que gerou o pacote. Se a maioria de seus serviços estiver sendo executada como o mesmo usuário, isso não será muito útil, mas poderá ser feito se você tiver usuários específicos do serviço. Um conjunto de regras de iptable da seguinte forma:
%pre%registraria todo o tráfego de dns de saída com o UID associado. Dependendo da sua configuração de registro, você pode encontrá-lo via kmesg ou nas mensagens do seu syslog e a saída será algo como:
%pre%A partir dessa saída, posso ver que o processo em questão tinha um UID de 1000, que pelo menos restringe minha pesquisa.