O que são as visitas da porta 45702?

4

Estive procurando em meus logs do iptables e há centenas de IPs diferentes tentando acessar a porta 45702, o Google parece não saber muito.

Eles sempre chegam em blocos por ip

 Jun 3 00:59:49 76.108.181.238  32253   in  130.88.149.86   45702   UDP
 Jun 3 00:59:42 76.108.181.238  32253   in  130.88.149.86   45702   UDP
 Jun 3 00:59:39 76.108.181.238  32253   in  130.88.149.86   45702   UDP
 Jun 3 00:59:38 76.108.181.238  32253   in  130.88.149.86   45702   UDP
 Jun 3 00:54:35 76.108.181.238  32253   in  130.88.149.86   45702   UDP
 Jun 3 00:54:33 76.108.181.238  32253   in  130.88.149.86   45702   UDP
 Jun 3 00:54:31 76.108.181.238  32253   in  130.88.149.86   45702   UDP
 Jun 3 00:52:39 76.108.181.238  32253   in  130.88.149.86   45702   UDP
 Jun 3 00:52:33 76.108.181.238  32253   in  130.88.149.86   45702   UDP
 Jun 3 00:52:30 76.108.181.238  32253   in  130.88.149.86   45702   UDP
 Jun 3 00:52:29 76.108.181.238  32253   in  130.88.149.86   45702   UDP

Alguém sabe o que é isso / tem algum conselho além de garantir que está fechado?

Se é uma porta inútil, por que todos esses IPs a visitam?

Editar:

Agora, de repente, ele é alterado para outra porta, ainda vários IP's diferentes

Jun 3 02:02:19  157.157.153.131 62411   in  130.88.149.86   47515   TCP
 Jun 3 02:02:11 157.157.153.131 62411   in  130.88.149.86   47515   TCP
 Jun 3 02:02:07 157.157.153.131 62411   in  130.88.149.86   47515   TCP
 Jun 3 02:02:05 157.157.153.131 62411   in  130.88.149.86   47515   TCP
 Jun 3 02:02:04 157.157.153.131 62411   in  130.88.149.86   47515   TCP
 Jun 3 02:02:02 157.157.153.131 62411   in  130.88.149.86   47515   TCP
 Jun 3 02:02:03 157.157.153.131 62411   in  130.88.149.86   47515   TCP
 Jun 3 02:02:01 157.157.153.131 62411   in  130.88.149.86   47515   TCP
 Jun 3 02:02:00 157.157.153.131 62411   in  130.88.149.86   47515   TCP
 Jun 3 01:52:52 194.144.100.212 50879   in  130.88.149.86   47515   TCP
 Jun 3 01:52:44 194.144.100.212 50879   in  130.88.149.86   47515   TCP
 Jun 3 01:52:38 194.144.100.212 50879   in  130.88.149.86   47515   TCP
 Jun 3 01:52:40 194.144.100.212 50879   in  130.88.149.86   47515   TCP
Jun 3 02:27:06  157.157.153.131 53228   in  130.88.149.86   47515   TCP
 Jun 3 02:27:05 157.157.153.131 53228   in  130.88.149.86   47515   TCP
 Jun 3 02:27:04 157.157.153.131 53228   in  130.88.149.86   47515   TCP
 Jun 3 02:27:03 157.157.153.131 53228   in  130.88.149.86   47515   TCP
 Jun 3 02:17:05 194.144.100.212 60288   in  130.88.149.86   47515   TCP
 Jun 3 02:16:57 194.144.100.212 60288   in  130.88.149.86   47515   TCP
 Jun 3 02:16:53 194.144.100.212 60288   in  130.88.149.86   47515   TCP
 Jun 3 02:16:51 194.144.100.212 60288   in  130.88.149.86   47515   TCP

Estou confuso, mas acho que está sendo pego, então não importa,

A coisa que eu não entendo é por que existem muitos ip's diferentes tentando a mesma coisa, eu acho que alguém está usando proxies para mudar o IP a cada poucos minutos e realmente ama portas acima de 45000 (porque muitos serviços críticos são executados lá ?!?).

    
por Pez Cuckow 03.06.2011 / 02:02

1 resposta

3

É comum que clientes bittorrent usem portas tão altas. Se alguém na rede estiver usando um cliente desse tipo configurado dessa maneira, as tentativas de conexão de entrada poderão ser outros clientes tentando falar com ele. Também pode ser que haja um bug explorável remotamente em um cliente comum (eu não ouvi falar de um, mas isso não significa que vários não existem), então o tráfego poderia ser um pouco tentando caçar cópias de esse cliente para tentar explorar.

No meu entender, parece estranho que tais conexões viessem em blocos da mesma fonte na mesma porta via TCP se as conexões são relacionadas a bittorrent, embora seja menos estranho para UDP (vários pacotes iniciais podem ser enviados no caso os anteriores foram perdidos devido a uma falha temporária se o firewall silenciosamente descartar pacotes em vez de enviar uma resposta de erro).

Em qualquer caso, usar netcat para ver o que aparece como sugere Xerxes dará algumas dicas, a menos que o trafegue para um protocolo devidamente criptografado (mesmo assim, pode haver pistas na tentativa de abertura do handshake).

    
por 03.06.2011 / 03:45