Isto é provavelmente algo na linha, essas 2 portas (554/7070) são para RealServers realplayers.
Eu tenho um servidor que hospeda vários sites para mim. Os dois serviços que são acessíveis fora são o SSH e o 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.
Notei que uma varredura do host usando o nmap produziu resultados diferentes de PCs 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
Considerando que a varredura de um servidor com base nos EUA com nmap 5.00 e uma caixa Linux na Noruega executando o nmap 5.21 eu recebo o seguinte:
Not shown: 998 filtered ports
PORT STATE SERVICE
80/tcp open http
9000/tcp open cslistener
então espero que minha rede interna ou ISP esteja funcionando, mas não tenho certeza.
A execução de um netstat -l | grep 7070 não produz nada. Similarmente para a porta 554.
Alguém pode explicar as peculiaridades que estou vendo?
Isto é provavelmente algo na linha, essas 2 portas (554/7070) são para RealServers realplayers.
Eu estaria inclinado a culpar seu ISP ou algo entre você e seu servidor por isso. Se você quer apenas se assegurar de que essas portas estão realmente fechadas, você pode tentar escutar essas portas 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 tem 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, telnet para ele de outra caixa e verifique se netcat está recebendo o que você envia (provavelmente você vai querer aumentar o --wait timeout). / p>
Seu roteador provavelmente é o culpado. Eu estava apenas me perguntando se isso era um problema em estar em um host OpenVZ e encontrei este artigo: Os portos 21, 554 e 7070 estão abertos ou fechados? A resposta é sim.
Isso faz sentido para mim, como eu estou atualmente em um roteador de baixa qualidade FiOS Actiontec. Qualquer combinação de testes nmap e netcat no container e no nó do host confirma que essas portas não estão realmente abertas.
Vários roteadores diferentes (Verizon FiOS, Hub Principal da BT, Apple Airport Extreme, ...) mostram as portas 554 e 7070 como abertas para todos os IPs por algum motivo.
Eu concordo com o nickgrim. Além disso, você pode querer tentar verificações 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 é seu ip público
Isso pode ser um ALG RTSP (Application Layer Gateway) no seu hub inicial interceptando o tráfego e fornecendo uma resposta.
Você está usando uma VM no ESXi Guest? Comecei a ter resultados falsos 554/7070 quando movi minha VM Kali linux da Workstation para o ESXi. Você pode verificar a latência:
nmap yourip --razões -p7070 --traceroute
Verifique o número diferente de saltos das portas 554 e 7070 com portas normais ...