O nmap no meu servidor web mostra as portas TCP 554 e 7070 abertas

Eu tenho um servidor web que hospeda vários sites para mim. Os dois serviços acessíveis externamente são SSH e Apache2. Eles estão sendo executados em uma porta não padrão e padrão, respectivamente. Todas as outras portas são fechadas explicitamente via arno-iptables-firewall. O host está executando o Debian Testing.

Percebi que uma varredura do host usando o nmap produziu resultados diferentes em computadores diferentes. Do meu laptop na minha rede doméstica (atrás de um BT Homehub), recebo o seguinte:

Not shown: 996 filtered ports
PORT     STATE SERVICE
80/tcp   open  http
554/tcp  open  rtsp
7070/tcp open  realserver
9000/tcp open  cslistener

enquanto que a digitalização de um servidor nos EUA com o nmap 5.00 e uma caixa Linux na Noruega executando o nmap 5.21, recebo o seguinte:

Not shown: 998 filtered ports
PORT     STATE SERVICE
80/tcp   open  http
9000/tcp open  cslistener

então, espero que seja minha rede interna ou provedor de serviços de Internet, mas não tenho certeza.

Executar um netstat -l | grep 7070não produz nada. Da mesma forma para a porta 554.

Alguém pode explicar as peculiaridades que estou vendo?

Isso provavelmente é algo da linha, essas duas portas (554/7070) são para RealServers para jogadores reais.

http://service.real.com/firewall/adminfw.html

Eu ficaria inclinado a culpar seu ISP ou algo entre você e seu servidor por isso. Se você apenas quer se assegurar de que essas portas realmente estão fechadas, tente escutá-las e, se for bem-sucedido, é seguro assumir que não há nada que já esteja escutando. Aqui está o que estou fazendo na minha máquina (que possui o Apache na porta 80 e nada na porta 81):

$ sudo netcat -p 80 -l --wait 1    # Apache on port 80
Error: Couldn't setup listening socket (err=-3)
$ sudo netcat -p 81 -l --wait 1    # Nothing on port 81
(Ctrl-C)

EDIT: E para ter certeza de que isso realmente funcionou, remova telnet-o de outra caixa e verifique se netcatestá recebendo o que você envia (você provavelmente desejará aumentar o --waittempo limite).

Seu roteador provavelmente é o culpado. Eu estava pensando se este era um problema em estar em um host OpenVZ e encontrei este artigo: As portas 21, 554 e 7070 estão abertas ou fechadas? A resposta é sim.

Isso faz sentido para mim, pois atualmente estou em um roteador de baixa qualidade do FiOS Actiontec. Qualquer combinação de teste nmap e netcat no contêiner e no nó do host confirma que essas portas não estão realmente abertas.

Vários roteadores diferentes (Verizon FiOS, BT Home Hub, Apple Airport Extreme, ...) mostram portas 554e estão 7070abertas para todos os IPs por algum motivo.

Hackerific »Portas TCP falsas positivas!

Eu concordo com o nickgrim. Você também pode tentar varreduras locais do nmap a partir da própria caixa

Compare a saída destes:

nmap 127.0.0.1

nmap 1.2.3.4

Onde 1.2.3.4 é o seu ip público

Pode ser um RTSP ALG (Gateway de camada de aplicativo) no hub doméstico, interceptando o tráfego e fornecendo uma resposta.

Você está usando uma VM no ESXi Guest? Comecei a ter resultados falsos 554/7070 quando mudei minha VM Kali linux da Workstation para o ESXi. Você pode verificar a latência:

nmap yourip --reason -p 7070 --traceroute

Verifique o número diferente de saltos das portas 554 e 7070 com portas normais ...