Cuando trabajas con servidores VoIP, especialmente con Asterisk, FreeSWITCH, SBCs, troncales SIP o cualquier cosa que huela a llamadas, tarde o temprano llega una pregunta incómoda:

¿Qué estoy exponiendo realmente a internet?

Porque sí, todos amamos que el servidor conteste llamadas. Lo que no amamos tanto es que también le conteste a bots remotos, scanners SIP, intentos de fraude, registros falsos etc.

En este artículo veremos cómo hacer una revisión básica de exposición en servidores orientados a VoIP, usando nmap, interpretando resultados TCP/UDP y poniendo especial atención en servicios como SIP, RTP, NFS, SNMP y otros puertos que no deberían andar saludando al mundo.

Las IPs usadas aquí son de prueba:
Origen: 201.207.200.100
Destino: 55.55.55.55
No representan servidores reales de producción.

---

¿Qué es UDP y por qué importa tanto en VoIP?

Antes de escanear como si estuviéramos audicionando para una película de hackers, vale la pena entender algo básico. UDP, o User Datagram Protocol, es un protocolo de transporte que se usa cuando importa más la velocidad que la confirmación perfecta de entrega.

A diferencia de TCP, UDP no establece una conexión formal antes de enviar datos. No hay handshake, no hay “¿me recibiste?”, no hay drama. Simplemente manda paquetes. Eso lo vuelve ideal para aplicaciones en tiempo real como:

• VoIP
• RTP
• SIP sobre UDP
• streaming
• videojuegos
• DNS
• NTP

En telefonía IP esto tiene mucho sentido. Si se pierde un paquete de audio, no quieres que llegue tres segundos después diciendo “perdón, aquí está”. Ya no sirve. En una llamada, el tiempo importa más que la perfección. Por eso en VoIP encontramos mucho tráfico UDP:

Servicio	Puerto común	Protocolo
SIP	5060	UDP/TCP
SIP TLS	5061	TCP/UDP
RTP Asterisk	10000-20000	UDP
RTP FreeSWITCH	16384-32768	UDP
STUN	3478	UDP
NFS	2049	TCP/UDP
rpcbind	111	TCP/UDP
SNMP	161	UDP
SNMP Trap	162	UDP

Y aquí viene el detalle: UDP es más difícil de escanear e interpretar que TCP. Muchas veces Nmap mostrará resultados como open|filtered, que básicamente significa: “No sé si está abierto o si un firewall me está ignorando.”

Paso 1: Escaneo TCP básico

Primero revisamos puertos TCP. Aunque VoIP suele apoyarse mucho en UDP, TCP sigue siendo importante porque puede haber servicios administrativos, bases de datos, paneles web, SSH, APIs, etc.

Desde el servidor de pruebas 201.207.200.100 hacia el servidor destino 55.55.55.55:

sudo nmap -Pn -sS -T4 55.55.55.55

Explicación rápida:

-Pn	No hacer ping previo; asumir que el host está activo
-sS	SYN scan, escaneo TCP común
-T4	Velocidad agresiva pero razonable

Un resultado sano podría verse así, aquí no hay puertos open, lo cual es buena señal.:

Nmap scan report for 55.55.55.55
Host is up.

Not shown: 997 closed tcp ports
PORT     STATE     SERVICE
25/tcp   filtered  smtp
161/tcp  filtered  snmp
3306/tcp filtered  mysql

Diferencia entre closed, filtered y open

Estado	Qué significa
open	Hay un servicio escuchando y responde
closed	No hay servicio escuchando, pero el host responde
filtered	Algo bloquea o filtra el tráfico
open	filtered

En seguridad, open merece atención inmediata. filtered no siempre es malo; muchas veces significa que el firewall está haciendo su trabajo.

Paso 2: Escaneo completo de todos los puertos TCP

El escaneo básico revisa solo los puertos más comunes. Para buscar cualquier servicio raro escuchando en TCP:

sudo nmap -Pn -sS -p- --min-rate 5000 55.55.55.55

Esto escanea del puerto 1 al 65535.

PORT      STATE     SERVICE
25/tcp    filtered  smtp
3306/tcp  filtered  mysql
17777/tcp filtered  unknown
56473/tcp filtered  unknown

No necesariamente significa que haya servicios abiertos, pero sí vale la pena comparar contra lo que el servidor realmente debería exponer. En un servidor VoIP típico, desde internet normalmente solo deberían estar abiertos los puertos estrictamente necesarios, por ejemplo:

• SIP hacia IPs de carriers autorizadas
• RTP hacia IPs de carriers autorizadas
• algún puerto administrativo solo vía VPN
• nada de MySQL público.

Paso 3: Escaneo UDP orientado a VoIP

Ahora viene lo bueno. UDP es donde muchos servidores VoIP viven, respiran y, si los dejas, también se meten en problemas. Comando recomendado:

sudo nmap -Pn -sU -p 5060,5061,5080,5081,111,2049,123,161,162,69 55.55.55.55

Estamos revisando:

Puerto	Servicio	Por qué importa
5060/udp	SIP	Punto clásico de ataques VoIP
5061/udp	SIP TLS	SIP cifrado
5080/udp	FreeSWITCH external profile	Puede recibir tráfico externo
5081/udp	Variante TLS/external	Revisar si aplica
111/udp	rpcbind	Relacionado con NFS
2049/udp	NFS	No debería estar público
123/udp	NTP	Puede usarse en abuso/amplificación
161/udp	SNMP	Información sensible si está abierto
162/udp	SNMP trap	Monitoreo
69/udp	TFTP	Frecuente en provisioning, peligroso público

Un resultado deseable sería algo así:

PORT     STATE         SERVICE
69/udp   closed        tftp
111/udp  closed        rpcbind
123/udp  closed        ntp
161/udp  open|filtered snmp
162/udp  open|filtered snmptrap
2049/udp closed        nfs
5060/udp closed        sip
5061/udp closed        sip-tls
5080/udp closed        unknown
5081/udp closed        sdl-ets

La parte que esperamos:

5060/udp closed sip
111/udp closed rpcbind
2049/udp closed nfs

Eso indica que SIP UDP 5060 no está expuesto públicamente y que NFS tampoco está visible desde internet. Y sí, en VoIP eso es motivo para servirse un café con menos ansiedad.

¿Por qué es peligroso dejar SIP 5060 abierto a todo internet?

El puerto 5060/udp es el clásico puerto SIP. Si está abierto públicamente, puede recibir:

• escaneos automáticos
• intentos de registro SIP
• INVITEs falsos
• enumeración de extensiones
• ataques de fuerza bruta
• intentos de fraude telefónico
• tráfico basura que ensucia logs y consume recursos

Un servidor VoIP expuesto sin filtros es como dejar la puerta abierta con un letrero que dice:

“Pase usted, pruebe extensiones, tal vez una tenga clave 1234.”

Paso 4: Validar si SIP responde a INVITE

Una prueba útil es enviar un INVITE SIP o cadena de registros en un softphone desde la IP origen de pruebas 201.207.200.100 al destino 55.55.55.55:5060. Si no hay respuesta, verás retransmisiones del INVITE:

201.207.200.100:1260  →  55.55.55.55:5060
INVITE
INVITE retransmitido
INVITE retransmitido
INVITE retransmitido

Si el servidor no responde nada, puede significar:

1. El paquete no llega al servidor.
2. El firewall lo bloquea.
3. La aplicación SIP no está escuchando.
4. El servidor descarta tráfico no autorizado.
5. Hay una ACL previa al stack SIP.

Para confirmar, en el servidor destino se puede usar:

sudo tcpdump -ni any udp port 5060 and host 201.207.200.100

• Si el INVITE no aparece en tcpdump, no llega al servidor.
• Si aparece en tcpdump, pero no aparece en Asterisk o FreeSWITCH, probablemente lo bloquea el sistema local o la aplicación no está escuchando correctamente.
• Si aparece y responde, pero el cliente no recibe respuesta, entonces el problema puede estar en el camino de regreso.

Paso 5: Revisar qué servicios escuchan en el servidor

En el servidor destino:

sudo ss -tulpn

Para filtrar puertos importantes:

sudo ss -tulpn | egrep ':5060|:5061|:5080|:5081|:111|:2049|:161|:162'

Comando para revisar SIP:

sudo ss -lunp | grep ':5060'

Para revisar NFS/rpcbind:

sudo rpcinfo -p

Para revisar exports de NFS:

cat /etc/exports

Recomendaciones y Conclusión

Revisar exposición en servidores VoIP no es opcional. SIP, RTP, NFS, SNMP y otros servicios pueden quedar abiertos por accidente, por una regla vieja, por una prueba rápida o por ese clásico “luego lo cierro”. Spoiler administrativo: nadie lo cierra luego.

Un buen punto de partida es:

1. Escanear TCP.
2. Escanear UDP orientado a VoIP.
3. Revisar si SIP responde públicamente.
4. Confirmar que NFS, SNMP u otros servicios no estés expuestos.
5. Limitar SIP/RTP solo a carriers, SBCs o VPN.
6. Revisar la configuración interna de Asterisk o FreeSWITCH.

En VoIP, que algo “funcione” no significa que esté seguro. A veces solo significa que también le funciona al atacante. Y si tu 5060/udp está abierto a todo internet, no es un servidor VoIP: es una piñata SIP esperando turno.