La conexión a los puertos 2000 y 5060 se realizó correctamente a pesar del filtrado

Question

La conexión a los puertos 2000 y 5060 se realizó correctamente a pesar del filtrado

#1 de bonsaiviking (3 votos)

7

Ejecuto mi propio enrutador (basado en Ubuntu) y tengo iptables configurado para eliminar todos los paquetes entrantes de forma predeterminada. Para mi sorpresa, ejecutar un escaneo de nmap (desde el lado de la WAN) muestra dos puertos abiertos relacionados con el VOIP:

nmap -Pn -v --reason XXX.net

Starting Nmap 7.60 ( https://nmap.org ) at 2018-03-28 09:52 CEST
Initiating Parallel DNS resolution of 1 host. at 09:52
Completed Parallel DNS resolution of 1 host. at 09:52, 0.09s elapsed
Initiating Connect Scan at 09:52
Scanning XXX.net (XXX.XXX.XXX.XXX) [1000 ports]
Discovered open port 21/tcp on XXX.XXX.XXX.XXX
Discovered open port 22/tcp on XXX.XXX.XXX.XXX
Discovered open port 5060/tcp on XXX.XXX.XXX.XXX
Discovered open port 2000/tcp on XXX.XXX.XXX.XXX
Completed Connect Scan at 09:52, 5.17s elapsed (1000 total ports)
Nmap scan report for XXX.net (XXX.XXX.XXX.XXX)
Host is up, received user-set (0.035s latency).
Not shown: 995 filtered ports
Reason: 995 no-responses
PORT     STATE  SERVICE    REASON
21/tcp   open   ftp        syn-ack ttl 52
22/tcp   open   ssh        syn-ack ttl 54
113/tcp  closed ident      reset ttl 254
2000/tcp open   cisco-sccp syn-ack ttl 61
5060/tcp open   sip        syn-ack ttl 61

Read data files from: /usr/local/bin/../share/nmap
Nmap done: 1 IP address (1 host up) scanned in 5.33 seconds

ftp y ssh son correctos, ya que estos dos servicios están configurados en el enrutador. Pero abrir cisco-sccp y sip es una novedad para mí.

De hecho, una conexión telnet a ambos puertos es exitosa:

telnet XXX.net 2000
Trying XXX.XXX.XXX.XXX...
Connected to XXX.net.
Escape character is '^]'.

telnet XXX.net 5060
Trying XXX.XXX.XXX.XXX...
Connected to XXX.net.
Escape character is '^]'.

Pero la ejecución de netstat -talpn en el enrutador mientras la sesión telnet está activa no muestra una conexión establecida para ninguno de los puertos. Y el registro muestra que iptables descarta los paquetes:

Mar 27 20:52:16 router DROP INPUT  IN=ppp0 OUT= MAC=MM:MM:MM:M SRC=YYY.YYY.YYY.YYY DST=XXX.XXX.XXX.XXX LEN=60 TOS=00 PREC=0x00 TTL=51 ID=39215 DF PROTO=TCP SPT=52200 DPT=2000 SEQ=106277563 ACK=0 WINDOW=42340 SYN URGP=0 MARK=0

donde YYY.YYY.YYY.YYY es la IP desde la que telnet se conecta.

¿Mi diagnóstico es correcto?

En caso afirmativo, ¿cómo puede telnet establecer una conexión, aunque los paquetes se caigan en el enrutador? ¿Quién está escuchando en los puertos 2000 y 5060?

ports nmap voip iptables

pregunta Christian David 27.03.2018 - 21:13

fuente

1 respuesta

Lea otras preguntas en las etiquetas ports nmap voip iptables

¿Cómo pueden IoT y otros dispositivos de red acceder a Internet si mi enrutador funciona como un cortafuegos? Nessus Port scan Vs NMAP Port scan

score 3 · Accepted Answer

Hay algo entre el escáner y el destino que responde en nombre del objetivo, falsificando su dirección de origen para que parezca ser el objetivo en sí mismo. Cuando ejecutó la exploración de Nmap como raíz con --reason -v , mostró los valores de Tiempo de vida de IP (TTL) de los paquetes de respuesta para cada puerto:

PORT     STATE  SERVICE    REASON
21/tcp   open   ftp        syn-ack ttl 52
22/tcp   open   ssh        syn-ack ttl 54
113/tcp  closed ident      reset ttl 254
2000/tcp open   cisco-sccp syn-ack ttl 61
5060/tcp open   sip        syn-ack ttl 61

El campo TTL comienza en algún número (generalmente 128 o 64) y disminuye con cada salto o enrutador IP que interviene. Si alguno de los campos TTL recibidos es inesperadamente alto, puede significar que el paquete se originó más cerca del escáner de lo esperado, es decir, desde uno de los saltos.

Dijiste que se esperaba que 21 y 22 estuvieran abiertos. Tienen diferentes valores de TTL, lo que podría significar que uno de ellos (FTP) se reenvía a un sistema dentro de su red, o podría significar que hay algún enrutamiento asimétrico en marcha que resulta en una ruta diferente cada vez. Pero la pregunta real es más de 2000 y 5060, que son 7 saltos más cerca que la distancia esperada más cercana. Estos casi seguramente están siendo interceptados.

Debería poder determinar qué salto está interceptando el tráfico realizando un traceroute. Se puede usar Nmap para hacer esto, si limita su tráfico al puerto en cuestión:

nmap --traceroute -Pn -p 2000 example.com

Esto mostrará una serie de saltos que culminan en el "de" tu objetivo. En realidad, es más probable que sea el salto más allá del último salto en esta lista. Compárelo con el traceroute para un puerto que funciona como se espera. Por ejemplo, si su escaneo se ve así:

# nmap --traceroute -Pn -p 2000 example.com
TRACEROUTE (using port 2000/tcp)
1   2.04 ms  gateway (192.168.1.1)
2   14.37 ms 10.100.96.1
3   15.60 ms example.com (192.0.2.5)

# nmap --traceroute -Pn -p 22 example.com
TRACEROUTE (using port 22/tcp)
1   2.04 ms  gateway (192.168.1.1)
2   14.37 ms 10.100.96.1
3   15.60 ms 182.23.16.88
4   10.11 ms 182.23.16.82
5   44.73 ms example.com (192.0.2.5)

El último salto común es 10.100.96.1. El siguiente salto en la secuencia es 182.23.16.88, que es probablemente el que está falsificando la respuesta.

En cuanto a por qué estos puertos pueden estar siendo falsificados, observo que SCCP (puerto 2000) y SIP (puerto 5060) son servicios de VoIP. ¿Tal vez su ISP no quiere que ejecute un servidor, cliente o retransmisión de VoIP, y está utilizando este método para evitarlo?