nmap en mi servidor web muestra los puertos TCP 554 y 7070 abiertos

Tengo un servidor web que aloja varios sitios web para mí. Los dos servicios a los que se puede acceder fuera son SSH y Apache2. Estos se ejecutan en un puerto no estándar y estándar, respectivamente. Todos los demás puertos se cierran explícitamente a través de arno-iptables-firewall. El host está ejecutando las pruebas de Debian.

Noté que un escaneo del host usando nmap produjo diferentes resultados de diferentes PC. Desde mi computadora portátil en mi red doméstica (detrás de un BT Homehub), obtengo lo siguiente:

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

mientras que escaneo desde un servidor con base en EE. UU. con nmap 5.00 y un cuadro de Linux en Noruega que ejecuta nmap 5.21 obtengo lo siguiente:

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

así que espero que sea mi red interna o ISP lo que esté jugando, pero no puedo estar seguro.

Ejecutar a netstat -l | grep 7070no produce nada. Del mismo modo para el puerto 554.

¿Alguien puede explicar las peculiaridades que estoy viendo?

Es muy probable que esto esté en la línea, esos 2 puertos (554/7070) son para jugadores reales RealServers.

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

Me inclinaría a culpar a su ISP o algo entre usted y su servidor por esto. Si solo quiere asegurarse de que esos puertos realmente están cerrados, puede intentar escuchar en esos puertos y si tiene éxito, entonces es seguro asumir que ya no hay nada escuchando. Esto es lo que estoy haciendo en mi máquina (que tiene Apache en el puerto 80 y nada en el puerto 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)

EDITAR: Y para asegurarse de que esto realmente ha funcionado, haga lo telnetmismo desde otra casilla y compruebe que netcatestá recibiendo lo que envía (probablemente querrá aumentar el --waittiempo de espera).

Su enrutador es probablemente el culpable. Me preguntaba si esto era un problema con estar en un host OpenVZ, y encontré este artículo: ¿Están abiertos o cerrados los puertos 21, 554 y 7070? La respuesta es sí.

Esto tiene sentido para mí, ya que actualmente estoy en un enrutador FiOS Actiontec de mala calidad. Cualquier combinación de pruebas de nmap y netcat en el contenedor y el nodo host confirma que esos puertos no están realmente abiertos.

Varios enrutadores diferentes (Verizon FiOS, BT Home Hub, Apple Airport Extreme, ...) muestran puertos 554y están 7070abiertos para todas las IP por algún motivo.

Hackerific »¡Puertos TCP falsos positivos!

Estoy de acuerdo con nickgrim. También es posible que desee probar escaneos nmap locales desde el cuadro en sí

Compare la salida de estos:

nmap 127.0.0.1

nmap 1.2.3.4

Donde 1.2.3.4 es su ip pública

Esto puede ser un RTSP ALG (Application Layer Gateway) en su centro de origen que intercepta el tráfico y proporciona una respuesta.

¿Está utilizando una VM en ESXi Guest? Comencé a tener resultados falsos de 554/7070 cuando trasladé mi VM Kali linux de la estación de trabajo a ESXi. Puedes verificar la latencia:

nmap yourip --razón -p 7070 --traceroute

Verifique el número diferente de saltos de los puertos 554 y 7070 con puertos normales ...