Como posso identificar qual processo está gerando tráfego UDP no Linux?

Minha máquina está continuamente solicitando tráfego de DNS do udp. o que eu preciso saber é o PID do processo que gera esse tráfego.

A maneira normal na conexão TCP é usar netstat / lsof e obter o processo associado ao pid.

É UDP a conexão é stateles, então, quando eu chamo netastat / lsof, posso vê-lo apenas se o soquete UDP estiver aberto e estiver enviando tráfego.

Eu tentei com lsof -i UDPe com nestat -anpue, mas não consigo encontrar qual processo está fazendo essa solicitação, porque preciso chamar lsof / netstat exatamente quando o tráfego udp é enviado, se eu chamar lsof / netstat antes / depois que o datagrama udp é enviado é impossível visualizar o soquete UDP aberto.

Chamar netstat / lsof exatamente quando o pacote 3/4 udp é enviado é IMPOSSÍVEL.

Como posso identificar o processo infame? Eu já inspecionei o tráfego para tentar identificar o PID enviado a partir do conteúdo do pacote, mas não é possível identificá-lo a partir do conteúdo do tráfego.

Alguém pode me ajudar ?

Eu sou root nesta máquina FEDORA 12 Linux noise.company.lan 2.6.32.16-141.fc12.x86_64 # 1 SMP Wed Jul 7 04:49:59 UTC 2010 x86_64 x86_64 x86_64 GNU / Linux

A auditoria do Linux pode ajudar. Pelo menos, localizará usuários e processos que fazem conexões de rede de datagrama. Pacotes UDP são datagramas.

Primeiro, instale a auditdestrutura em sua plataforma e garanta que auditctl -lretorne algo, mesmo que diga que nenhuma regra foi definida.

Em seguida, adicione uma regra para assistir à chamada do sistema socket()e marque-a para facilitar a localização mais tarde ( -k). Eu preciso assumir que você está em uma arquitetura de 64 bits, mas você pode substituir b32no lugar do b64se você não é.

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

Você precisa escolher entre as páginas de manual e os arquivos de cabeçalho para criar isso, mas o que ele captura é essencialmente essa chamada de sistema:, socket(PF_INET, SOCK_DGRAM|X, Y)onde o terceiro parâmetro não é especificado, mas frequentemente zero. PF_INETé 2 e SOCK_DGRAMé 2. As conexões TCP usariam o SOCK_STREAMque definiria a1=1. ( SOCK_DGRAMno segundo parâmetro pode ser ORed com SOCK_NONBLOCKou SOCK_CLOEXEC, portanto, a &=comparação.) Essa -k SOCKETé a nossa palavra-chave que queremos usar ao pesquisar trilhas de auditoria posteriormente. Pode ser qualquer coisa, mas eu gosto de simplificar.

Deixe alguns momentos para revisar as trilhas de auditoria. Opcionalmente, você pode forçar alguns pacotes executando o ping de um host na rede, o que causará uma pesquisa de DNS, que usa o UDP, que deve disparar nosso alerta de auditoria.

ausearch -i -ts today -k SOCKET

E uma saída semelhante à seção abaixo será exibida. Estou abreviando para destacar as partes importantes

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

Na saída acima, podemos ver que o pingcomando fez com que o soquete fosse aberto. Eu poderia então executar strace -p 14510o processo, se ainda estivesse em execução. O ppid(ID do processo pai) também é listado, caso seja um script que gera muito o filho problemático.

Agora, se você tiver muito tráfego UDP, isso não será bom o suficiente e você precisará recorrer ao OProfile ou SystemTap , ambos atualmente além dos meus conhecimentos.

Isso deve ajudar a restringir as coisas no caso geral.

Quando terminar, remova a regra de auditoria usando a mesma linha usada para criá-la, substitua apenas -apor -d.

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

Você pode usar o netstat, mas precisa dos sinalizadores corretos e só funcionará se o processo que está enviando os dados ainda estiver ativo. Ele não encontra os vestígios de algo que surgiu brevemente, enviou tráfego UDP e desapareceu. Também requer privilégios de root local. Dito isto:

Aqui estou eu iniciando um ncat no meu host local, enviando tráfego UDP para a porta 2345 em uma máquina (inexistente) 10.11.12.13:

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

Aqui estão algumas saídas do tcpdump que provam que o tráfego está indo:

[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

Aqui está a parte útil , usando netstat com o sinalizador -a (para ver detalhes da porta) e o sinalizador -p para ver os detalhes do ID do processo. É o sinalizador -p que requer privilégios de root:

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

Como você pode ver, o pid 9152 é apontado como tendo uma conexão aberta na porta 2345 no host remoto especificado. O Netstat também ajuda isso no ps e me diz o nome do processo ncat.

Espero que seja de alguma utilidade.

Eu tinha exatamente o mesmo problema e, infelizmente auditd, não fez muito por mim.

Eu tive tráfego de alguns dos meus servidores indo para endereços DNS do Google 8.8.8.8e 8.8.4.4. Agora, meu administrador de rede tem TOC moderado e ele queria limpar todo o tráfego desnecessário, pois temos nossos caches DNS internos. Ele queria desativar a porta de saída 53 para todos, exceto para os servidores de cache.

Então, depois de fracassar auditctl, eu apresso systemtap. Eu venho com o seguinte script:

# 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

Em seguida, basta executar:

stap -v udp_detect_domain.stp

Esta é a saída que eu tenho:

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

É isso aí! Depois de alterar resolv.confesses PIDs, não recebemos as alterações.

Espero que isto ajude :)

Aqui está uma opção systemtap, usando as sondas netfilter disponíveis no stap verson 1.8 e posterior. Veja também 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

Eu usaria um sniffer de rede como tcpdump ou wireshark para visualizar as solicitações de DNS. O conteúdo da consulta pode dar uma idéia do programa que está sendo emitido.

Esteja ciente de que, ao usar o autitctl, o nscd, por exemplo, usa um parâmetro ligeiramente diferente na chamada do sistema de soquete, ao fazer uma consulta DNS:

socket(AF_INET, SOCK_DGRAM|SOCK_NONBLOCK, IPPROTO_IP)

Portanto, para ter certeza de capturar essas consultas, além das mencionadas acima, você pode adicionar um filtro adicional, com o mesmo nome, se desejar:

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

Aqui 2050 é um OR bit a bit de SOCK_DGRAM (2) e SOCK_NONBLOCK (2048).

Em seguida, a pesquisa encontrará os dois filtros com a mesma chave SOCKET:

ausearch -i -ts today -k SOCKET

Os valores hexadecimais das constantes de soquete que encontrei aqui: https://golang.org/pkg/syscall/#pkg-constants

Como não tenho pontos de reputação para comentar, adicionei isso.