como eu posso identificar qual processo está fazendo tráfego UDP no linux?

Question

minha máquina está fazendo continuamente o pedido de tráfego do udp dns. o que preciso saber é o PID do processo que gera esse tráfego.

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

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

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

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

como eu posso identificar o processo infame? Já inspecionei o tráfego para tentar identificar o PID enviado do conteúdo do pacote, mas não é possível identificá-lo do conteto do tráfego.

alguém pode me ajudar?

Eu sou o usuário root nesta máquina FEDORA 12 Linux noise.company.lan 2.6.32.16-141.fc12.x86_64 # 1 SMP Wed 07 de julho 04:49:59 UTC 2010 x86_64 x86_64 x86_64 GNU / Linux

    

Answer 1

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 estrutura auditd em sua plataforma e assegure-se de que auditctl -l retorne alguma coisa, mesmo que diga que nenhuma regra foi definida.

Em seguida, adicione uma regra para assistir à chamada do sistema socket() e marque-a para encontrar mais tarde ( -k ). Eu preciso assumir que você está em uma arquitetura de 64 bits, mas você pode substituir b32 no lugar do b64 se você não estiver.

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

Você tem que escolher através de páginas man e arquivos de cabeçalho para construir isto, mas o que captura é essencialmente esta chamada de sistema: socket(PF_INET, SOCK_DGRAM|X, Y) , onde o terceiro parâmetro não é especificado, mas freqüentemente zero. PF_INET é 2 e SOCK_DGRAM é 2. As conexões TCP usariam SOCK_STREAM , o que definiria a1=1 . ( SOCK_DGRAM no segundo parâmetro pode ser ORed com SOCK_NONBLOCK ou SOCK_CLOEXEC , daí a comparação &= .) O -k SOCKET é nossa palavra-chave que queremos usar ao pesquisar as trilhas de auditoria posteriormente. Pode ser qualquer coisa, mas eu gosto de simplificar.

Aguarde alguns instantes e analise as trilhas de auditoria. Opcionalmente, você pode forçar alguns pacotes fazendo ping em um host na rede, o que fará com que ocorra uma pesquisa de DNS, que usa UDP, o que deve atrapalhar nosso alerta de auditoria.

ausearch -i -ts today -k SOCKET

A 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 comando ping fez com que o soquete fosse aberto. Eu poderia então executar strace -p 14510 no processo, se ainda estivesse em execução. O ppid (ID do processo pai) também é listado, caso seja um script que gera muito a criança problemática.

Agora, se você tem muito tráfego UDP, isso não será bom o suficiente e você terá que recorrer ao OProfile ou SystemTap , ambas atualmente além do meu especialização.

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, apenas substitua -a por -d .

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

    

Answer 2

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

Aqui está eu começando 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á uma saída do tcpdump provando 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á o bit útil , usando netstat com o sinalizador -a (para ver os 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 é digitado como tendo uma conexão aberta à porta 2345 no host remoto especificado. O Netstat também executa isso através do ps e me informa que o nome do processo é ncat .

Espero que isso seja útil.

    

Answer 3

Eu tive 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.8 e 8.8.4.4 . Agora, meu administrador de rede tem OCD moderado e ele queria limpar todo o tráfego desnecessário, já que temos nossos caches DNS internos. Ele queria desativar a porta de saída 53 para todos, exceto os servidores de cache.

Então, depois de falhar com auditctl , eu me deparo com 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 recebi:

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! Depois de alterar resolv.conf , esses PIDs não selecionaram as alterações.

Espero que isso ajude:)

    

Answer 4

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

    

Answer 5

Aqui está uma opção systemtap, usando os testes 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

    

Answer 6

Lembre-se 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)

Então, para ter certeza de pegar essas consultas, além das que foram mencionadas acima, você pode adicionar um filtro adicional, com o mesmo nome, se quiser:

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: link

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