Servidor enviando pacotes a cada 5 minutos para 3 IPs

1

Percebemos em nossos logs de firewall que três conexões estão sendo constantemente estabelecidas a cada 5 minutos do nosso servidor web e tentando enviar um pacote para a porta de destino 43 (whois port) percorrendo todas as portas de origem (por exemplo, 59466, 59467, 59468, depois 5 minutos depois as próximas 3 portas) para 3 endereços IP diferentes ...:

193.0.6.135, 200.3.14.10, 196.216.2.130
Maduro, Lacnic e Africho

Eu entendo que todas as 3 empresas são registradores ip da internet, mas como ele está passando por todas as nossas portas de origem a cada 5 minutos, o envio de pacotes parece estranho. Parece uma varredura de porta reversa para mim. Isso é normal?

EDITAR:

Saída TCPDUMP, esta foi de apenas 2 minutos de intervalo. Percebeu que existem patches onde ele será executado 20 vezes seguidas no mesmo minuto. A velocidade e a frequência variam, mas não viram uma lacuna maior que 5 minutos.

[user@xxxxxxx xxxxxxx]# tcpdump -v -s 5000 -i eth0 port 35921 or port 35920 or port 35919 or port 35916 or port 35917 or port 35918 
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 5000 bytes 
08:56:33.517976 IP (tos 0x0, ttl  64, id 8127, offset 0, flags [DF], proto 6, length: 60) 192.168.xxx.xxx.35916 > whois.ripe.net.nicname: S [tcp sum ok] 2154741398:2154741398(0) win 5840 <mss 1460,sackOK,timestamp 67215657 0,nop,wscale 9> 
08:56:33.520288 IP (tos 0x0, ttl  64, id 59697, offset 0, flags [DF], proto 6, length: 60) 192.168.xxx.xxx.35917 > registro.lacnic.net.nicname: S [tcp sum ok] 2139834394:2139834394(0) win 5840 <mss 1460,sackOK,timestamp 67215659 0,nop,wscale 9> 
08:56:33.522705 IP (tos 0x0, ttl  64, id 33392, offset 0, flags [DF], proto 6, length: 60) 192.168.xxx.xxx.35918 > whois.afrinic.net.nicname: S [tcp sum ok] 2140808030:2140808030(0) win 5840 <mss 1460,sackOK,timestamp 67215662 0,nop,wscale 9> 
08:58:32.773110 IP (tos 0x0, ttl  64, id 28764, offset 0, flags [DF], proto 6, length: 60) 192.168.xxx.xxx.35919 > whois.ripe.net.nicname: S [tcp sum ok] 2259878735:2259878735(0) win 5840 <mss 1460,sackOK,timestamp 67334931 0,nop,wscale 9> 
08:58:32.776580 IP (tos 0x0, ttl  64, id 44263, offset 0, flags [DF], proto 6, length: 60) 192.168.xxx.xxx.35920 > registro.lacnic.net.nicname: S [tcp sum ok] 2259083248:2259083248(0) win 5840 <mss 1460,sackOK,timestamp 67334935 0,nop,wscale 9> 
08:58:32.778395 IP (tos 0x0, ttl  64, id 39072, offset 0, flags [DF], proto 6, length: 60) 192.168.xxx.xxx.35921 > whois.afrinic.net.nicname: S [tcp sum ok] 2267212728:2267212728(0) win 5840 <mss 1460,sackOK,timestamp 67334936 0,nop,wscale 9>
    
por Mechaflash 10.12.2013 / 16:16

2 respostas

0

O tráfego em si é provavelmente legítimo, embora a execução a cada cinco minutos provavelmente não seja.

Isso se parece com o tráfego whois padrão; está sendo enviado na porta whois e está sendo enviado para servidores whois oficiais.

No entanto, o fato de estar acontecendo em intervalos exatos de cinco minutos sugere que um processo automatizado está executando as consultas. Os registros não vão gostar muito disso, e eles podem acabar com você se ficar excessivo.

Você pode achar útil capturar o conteúdo do tráfego e inspecioná-lo para ver quais registros whois estão sendo pesquisados. Isso pode dar uma pista do que pode estar originando as consultas.

Se o servidor estiver executando o Linux, você poderá escrever um script de systemtap para encontrar o processo que originou as consultas.

(As portas de origem são irrelevantes; é uma opção do sistema operacional. Vá para ler TCP / IP Illustrated ou outra referência IP boa se desejar mais detalhes sobre esse problema que não existe.)

    
por 10.12.2013 / 18:39
0

Descobri no meu servidor que o script /usr/local/cpanel/scripts/update_spamassassin_config acessa esses servidores whois para atualizar sua configuração. Talvez isso tenha a ver com spamassassin e, nesse caso, é muito provavelmente legítimo.

Se isso estiver sendo executado em um servidor com spamassassin , verifique seu intervalo de atualização.

    
por 18.06.2016 / 02:40