Un ataque de amplificación SSDP es una técnica DDoS basada en reflexión que abusa del Simple Service Discovery Protocol, parte de Universal Plug and Play (UPnP), enviando requests de descubrimiento falsificados a dispositivos UPnP expuestos en internet —comúnmente routers domésticos, cámaras IP, smart TVs, y otro hardware IoT— que responden con datos de descripción de dispositivo enviados directamente a una víctima falsificada, generando tráfico de amplificación moderado pero ampliamente disponible.
Resumen rápido — La amplificación SSDP envía un request de descubrimiento M-SEARCH falsificado a dispositivos con UPnP habilitado expuestos en el internet público. Cada dispositivo responde con una respuesta de descripción de dispositivo en XML, logrando un factor de amplificación modesto (aproximadamente 7x-30x) comparado con DNS o NTP, pero el vector sigue siendo atractivo porque decenas de millones de dispositivos IoT están innecesariamente alcanzables en el puerto UDP 1900 a nivel mundial. La mitigación se centra en la segmentación de red —UPnP nunca debería responder a requests del lado WAN— combinada con BCP38 para reducir el spoofing y bloqueo a nivel de consumidor/ISP del tráfico entrante del puerto 1900.
Última actualización: 2026-08-08
La amplificación SSDP se convirtió en un vector DDoS prominente alrededor de 2014, coincidiendo con la ola más amplia de ataques de reflexión basados en UDP (NTP, DNS) que dominaron ese periodo. A diferencia de la amplificación NTP, que se resolvió en gran medida parcheando el software de servidor, la amplificación SSDP ha probado ser más persistente porque la población vulnerable no es un conjunto relativamente pequeño de operadores de servidor sino una base vasta y descentralizada de dispositivos IoT de consumidor —routers domésticos, almacenamiento en red, smart TVs, impresoras, y servidores multimedia— muchos de los cuales nunca se parchan, monitorean, o siquiera se reconocen como servicios orientados a red por sus propietarios. Los reportes públicos han identificado repetidamente decenas de millones de dispositivos con UPnP habilitado alcanzables en el puerto UDP 1900 desde el internet público, una población que ha probado ser difícil de reducir significativamente en la última década.
¿Qué son SSDP y UPnP?
Universal Plug and Play (UPnP) es un conjunto de protocolos de red que le permiten a los dispositivos en una red local descubrirse automáticamente y negociar servicios; por ejemplo, un smart TV descubriendo un servidor multimedia, o una consola de juegos abriendo automáticamente un puerto en un router para juego peer-to-peer. El Simple Service Discovery Protocol (SSDP) es el componente de descubrimiento de UPnP, y opera sobre el puerto UDP 1900, usando mensajes de request y respuesta estilo HTTP sobre UDP en lugar de TCP.
SSDP está diseñado para uso en red local: un dispositivo envía un request M-SEARCH a la dirección multicast 239.255.255.250:1900, y otros dispositivos UPnP en la misma LAN responden describiendo los servicios que ofrecen. El protocolo nunca fue diseñado para exponerse al internet público; su abuso como vector DDoS proviene enteramente de dispositivos y routers que responden incorrectamente a requests SSDP que llegan del lado WAN.
Cómo funciona la amplificación SSDP
Paso 1: El atacante envía un request M-SEARCH falsificado a un dispositivo UPnP expuesto en internet, con la IP de origen forjada como la dirección de la víctima
Atacante → Dispositivo UPnP Expuesto: M-SEARCH * HTTP/1.1 HOST: 239.255.255.250:1900 MAN: "ssdp:discover" ST: ssdp:all (origen=192.0.2.10 [víctima], ~110 bytes)
Paso 2: El dispositivo responde con una descripción estilo HTTP de sus servicios, enviada a la dirección de origen falsificada
Dispositivo UPnP → Víctima: HTTP/1.1 200 OK CACHE-CONTROL: max-age=1800 LOCATION: http://192.168.1.1:5000/rootDesc.xml ... (múltiples headers y descriptores de servicio, hasta ~750 bytes, posiblemente múltiples paquetes de respuesta por M-SEARCH dependiendo del dispositivo y valor ST)
Paso 3: El atacante repite esto vía miles de dispositivos UPnP expuestos encontrados mediante escaneos a nivel de internet (ej. Shodan, masscan)
10,000 dispositivos × tasa de consulta sostenida × ~750 bytes de respuesta = inundación volumétrica agregada convergiendo en la víctimaAlgunos dispositivos responden a un solo M-SEARCH con múltiples paquetes de respuesta SSDP, uno por cada tipo de servicio que anuncian, lo que puede empujar la amplificación efectiva para un dispositivo dado algo más alto de lo que sugeriría una proporción simple de un-request-una-respuesta, aunque todavía modesta en relación con NTP o DNS.
Por qué los dispositivos IoT están desproporcionadamente expuestos
Varios factores estructurales específicos del hardware de consumidor e IoT hacen que la amplificación SSDP esté persistentemente disponible incluso cuando ha crecido la conciencia sobre el vector:
- Configuración de UPnP habilitada por defecto. La mayoría de los routers de consumidor y dispositivos IoT vienen con UPnP habilitado por defecto, y muchos nunca le solicitan al propietario revisar o deshabilitarlo.
- Sin cultura de parcheo para hardware de consumidor. A diferencia del software de servidor, los routers, cámaras, y smart TVs de consumidor rara vez son parchados por sus propietarios, y muchos proveedores dejan de publicar actualizaciones de firmware mucho antes de que el dispositivo se retire del servicio.
- Bindings mal configurados orientados a WAN. SSDP solo debería responder a consultas multicast del lado LAN, pero bugs de firmware o mala configuración en algunos dispositivos causan que también respondan a consultas unicast que llegan de la interfaz WAN, exponiéndolos al escaneo a nivel de internet.
- Escala de la población IoT. Las estimaciones de dispositivos IoT conectados a internet cuentan en las decenas de miles de millones, y incluso un pequeño porcentaje mal configurado para exponer SSDP representa un pool absoluto muy grande de reflectores.
Comparación de factores de amplificación
| Protocolo | Tamaño de consulta | Respuesta máxima típica | Factor de amplificación |
|---|---|---|---|
| SSDP | ~110 bytes | ~750 bytes (a veces múltiples paquetes) | ~7x–30x |
| DNS (ANY/EDNS0) | ~60 bytes | ~4,000 bytes | ~28x–70x |
| CLDAP | ~52 bytes | ~1,068 bytes | ~56x–70x |
| NTP (monlist) | ~8 bytes | ~4,460 bytes | ~200x–556x |
| Memcached | ~15 bytes | Hasta ~134 MB | Hasta ~50,000x |
El factor de amplificación de SSDP es el más bajo entre los vectores de reflexión UDP ampliamente abusados, significativamente por debajo de DNS, CLDAP, y NTP. Su relevancia continua no viene de la eficiencia por request sino de la mera cantidad de reflectores disponibles: los servicios de DDoS-por-encargo y los operadores de botnet favorecen SSDP cuando necesitan un pool de reflectores grande y geográficamente diverso que sea poco probable que se parchee o se desconecte, aunque cada request individual contribuye relativamente menos amplificación que otros vectores.
Amplificación SSDP y servicios de DDoS-por-encargo
La amplificación SSDP es un método de ataque comúnmente ofrecido en plataformas de booter e IP stresser precisamente porque el pool de reflectores —routers domésticos e dispositivos IoT mal configurados— se repone continuamente a medida que se fabrican, venden, y conectan nuevos dispositivos con configuraciones UPnP por defecto, a diferencia de las vulnerabilidades del lado del servidor que se parchan y disminuyen con el tiempo.
Señales de detección
| Señal | Qué observar | Herramienta |
|---|---|---|
| Tráfico UDP/1900 entrante sin consulta SSDP saliente coincidente | Paquetes SSDP/HTTP-sobre-UDP con forma de respuesta llegando sin un request de descubrimiento local correspondiente | NetFlow/IPFIX, tcpdump -n udp port 1900 |
| Alta diversidad de IP de origen a través de rangos residenciales/de consumidor | Tráfico de ataque convergiendo desde muchos bloques de dirección de ISP de consumidor distintos, consistente con la población de dispositivos IoT | Análisis de flujo, enriquecimiento de ASN/geolocalización |
Respuestas SSDP que contienen headers LOCATION: apuntando a rangos IP privados | Una señal distintiva de que el paquete es una respuesta de dispositivo SSDP genuina en lugar de otro protocolo UDP reusando el puerto 1900 | Captura de paquetes, DPI |
| Pico de volumen UDP/1900 repentino desproporcionado a cualquier uso legítimo de UPnP local | Volumen de tráfico inconsistente con la pequeña cantidad de tráfico SSDP esperado del descubrimiento de red local | SNMP/RMON, contadores de interfaz |
# Inspecciona el tráfico de respuesta SSDP en la redtcpdump -n 'udp port 1900' -A
# Correlaciona NetFlow para respuestas UDP/1900 sin consultas salientes coincidentesnfdump -r flows.nf 'proto udp and src port 1900' -o extended
# Verifica si un dispositivo en tu propia red responde a consultas SSDP del lado WAN# (ejecuta solo contra infraestructura propia o para la que tengas autorización)python3 -c "import socketmsg = 'M-SEARCH * HTTP/1.1\r\nHOST:239.255.255.250:1900\r\nMAN:\"ssdp:discover\"\r\nST:ssdp:all\r\nMX:2\r\n\r\n's = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)s.sendto(msg.encode(), ('<ip-del-objetivo>', 1900))s.settimeout(3)print(s.recvfrom(4096))"Técnicas de mitigación
Deshabilitar UPnP en interfaces orientadas a WAN
La corrección más directa para propietarios y operadores de dispositivos: asegura que UPnP/SSDP solo escuche y responda en la interfaz de red local, nunca en la interfaz WAN. La mayoría del firmware de router de consumidor incluye una configuración para deshabilitar UPnP por completo, o para restringirlo a operación solo-LAN; habilitar esta configuración elimina al dispositivo del pool de reflectores.
Segmentación de red para dispositivos IoT
Las empresas y proveedores de servicio deberían colocar los dispositivos IoT en VLAN o subredes aisladas con filtrado de egress que bloquee las respuestas SSDP salientes (y otro tráfico UPnP) de llegar al internet público, evitando que los dispositivos en la red gestionada sean reclutados como reflectores incluso si UPnP está habilitado localmente para uso legítimo.
Bloqueo a nivel de ISP del puerto 1900 entrante
Los proveedores de servicio de internet pueden bloquear o limitar la tasa del tráfico UDP/1900 entrante en su edge de red para conexiones residenciales y de pequeñas empresas, ya que el tráfico SSDP legítimo nunca debería necesitar cruzar el límite WAN en primer lugar; es un protocolo solo de red local por diseño.
BCP38 / Filtrado de ingreso (RFC 2827)
Como la amplificación SSDP depende del IP spoofing para redirigir las respuestas del dispositivo hacia la víctima, el filtrado de ingreso BCP38 (RFC 2827) en la red del atacante evitaría que la consulta falsificada saliera de la propia red del atacante en primer lugar. Como con todos los ataques de reflexión que dependen de spoofing, esta defensa debe aplicarse upstream por las redes que originan el tráfico de ataque.
Rate limiting y correlación de respuesta en el objetivo
Las organizaciones que son objetivo de tráfico amplificado por SSDP pueden limitar la tasa de UDP/1900 entrante y correlacionar las respuestas entrantes contra consultas salientes previamente enviadas, descartando respuestas SSDP no solicitadas sin necesitar bloquear el protocolo a nivel de ISP.
Scrubbing upstream y absorción distribuida
Dada la escala del pool de reflectores disponible, los floods amplificados por SSDP todavía pueden alcanzar volúmenes que excedan la propia capacidad de uplink de un objetivo, incluso con un factor de amplificación por request comparativamente modesto. La absorción en un edge distribuido o proveedor de scrubbing sigue siendo la mitigación práctica para el objetivo. Consulta Blackhole Routing vs. Scrubbing para enfoques arquitectónicos.
Errores comunes
| Error | Impacto | Solución correcta |
|---|---|---|
| Asumir que el bajo factor de amplificación de SSDP lo hace de bajo riesgo | El volumen agregado de decenas de miles de reflectores todavía puede saturar el uplink de un objetivo, incluso a amplificación de 7x-30x por request | Trata a SSDP como un riesgo volumétrico basado en la población total de reflectores disponible, no solo en la eficiencia por request |
| Dejar UPnP habilitado en interfaces WAN “por compatibilidad” | Expone al dispositivo al escaneo a nivel de internet y reclutamiento como reflector DDoS, sin esencialmente ningún caso de uso legítimo del lado WAN para SSDP | Deshabilita UPnP en interfaces WAN; UPnP solo debería operar en la red local |
| Tratar la seguridad de dispositivos IoT como fuera de la responsabilidad de la organización | Las redes empresariales con dispositivos IoT no gestionados o BYOD pueden alojar sin saberlo reflectores que dañan la reputación de IP de la organización y consumen ancho de banda | Segmenta los dispositivos IoT en VLAN aisladas con filtrado de egress, sin importar si los dispositivos están gestionados centralmente |
| Bloquear todo el tráfico UDP en el puerto 1900 sin considerar el uso local legítimo | Rompe el descubrimiento de dispositivo UPnP local legítimo para organizaciones que dependen de él internamente (servidores multimedia, pantallas inteligentes, hardware de conferencia) | Filtra solo el tráfico SSDP orientado a WAN/internet; preserva el descubrimiento multicast local dentro de segmentos de red confiables |
| Depender únicamente del filtrado a nivel de ISP para resolver el problema | La adopción por parte del ISP del bloqueo del puerto 1900 entrante es inconsistente, y muchos dispositivos están detrás de NAT de grado carrier o conexiones empresariales con políticas distintas | Combina el refuerzo a nivel de dispositivo, la segmentación de red, y la mitigación del lado del objetivo en lugar de depender de una sola capa |
Cómo implementarlo con Azion
La red distribuida de Azion puede ayudar a absorber y filtrar el tráfico de amplificación SSDP antes de que llegue a un origen, mientras que evitar que tus propios dispositivos sean abusados como reflectores sigue siendo una responsabilidad de configuración de dispositivo y red independiente de cualquier proveedor de edge:
- DDoS Protection brinda detección y mitigación siempre activa para tráfico UDP volumétrico, incluyendo floods amplificados por SSDP, absorbiéndolo a través de la infraestructura distribuida de Azion en lugar de en tu origen.
- Network Shield puede aplicar reglas a nivel de red para identificar y filtrar patrones de tráfico UDP/1900 anómalos consistentes con reflexión SSDP, dependiendo de la configuración.
- Firewall permite reglas personalizadas para rate limiting y filtrado basado en protocolo a nivel de red.
- WAAP combina protecciones de red y de capa de aplicación para organizaciones que enfrentan campañas multi-vector que combinan amplificación volumétrica con abuso a nivel de aplicación.
Si tu organización gestiona dispositivos IoT o hardware de red orientado al consumidor, deshabilitar UPnP orientado a WAN y segmentar el tráfico IoT sigue siendo un paso complementario necesario, ya que aborda si tu propia infraestructura puede usarse como arma contra otros en lugar de si tus aplicaciones están protegidas de ataques entrantes.
Recursos relacionados
- ¿Qué es un ataque DDoS?
- Tipos de ataques DDoS
- ¿Qué es el IP spoofing?
- ¿Qué es la amplificación DNS?
- ¿Qué es una botnet?
- Azion DDoS Protection
Preguntas frecuentes
¿Qué es un ataque de amplificación SSDP? Un ataque de amplificación SSDP envía un request de descubrimiento falsificado (M-SEARCH) a un dispositivo con UPnP habilitado expuesto en el internet público, que responde con una descripción de dispositivo enviada directamente a la dirección de la víctima falsificada. Agregado a través de muchos dispositivos expuestos, esto genera una inundación volumétrica contra la víctima.
¿Qué es SSDP y por qué responden los dispositivos IoT a consultas a nivel de internet? SSDP (Simple Service Discovery Protocol) es el componente de descubrimiento de UPnP, diseñado para que los dispositivos en una red local se encuentren automáticamente. Solo debería responder a requests de la red local, pero la mala configuración de firmware o los ajustes habilitados por defecto en muchos routers y dispositivos IoT de consumidor causan que también respondan a consultas SSDP unicast que llegan del lado WAN, exponiéndolos al abuso a nivel de internet.
¿Cuál es el factor de amplificación para los ataques SSDP? SSDP típicamente produce factores de amplificación en el rango de aproximadamente 7x a 30x, dependiendo del dispositivo y de cuántos tipos de servicio anuncia en respuesta a una sola consulta. Esto es modesto comparado con NTP (hasta ~556x) o DNS (hasta ~70x), pero SSDP sigue siendo ampliamente usado debido al número muy grande de reflectores disponibles.
¿Por qué la amplificación SSDP sigue siendo común si su factor de amplificación es bajo? La persistencia del ataque viene del tamaño del pool de reflectores disponible en lugar de la eficiencia por request. Decenas de millones de routers de consumidor, cámaras, y otros dispositivos IoT siguen alcanzables en el puerto UDP 1900 a nivel mundial, y a diferencia de las vulnerabilidades de software de servidor, esta población no se reduce significativamente por el parcheo ya que la mayoría de los dispositivos de consumidor nunca se actualizan.
¿Un firewall puede detener un ataque de amplificación SSDP contra mí? Un firewall en la red del objetivo puede limitar la tasa o filtrar el tráfico UDP/1900 entrante y correlacionar respuestas contra consultas salientes previamente enviadas, reduciendo el impacto. No puede prevenir que se genere el ataque en primer lugar; eso requiere que los dispositivos IoT expuestos siendo abusados como reflectores tengan UPnP deshabilitado en sus interfaces WAN, lo cual está fuera del control del objetivo a menos que el objetivo también opere esos dispositivos.
¿Cómo verifico si mis propios dispositivos están expuestos al abuso SSDP? Envía un request M-SEARCH a la dirección IP pública del dispositivo en el puerto UDP 1900 desde un host de prueba externo que controles, y verifica si responde. Si lo hace, UPnP está incorrectamente vinculado a la interfaz WAN y debería deshabilitarse o restringirse a operación solo-LAN de inmediato. Solo prueba dispositivos que poseas o para los que tengas autorización explícita.
¿Cómo se relaciona la amplificación SSDP con las botnets IoT como Mirai? Están relacionadas pero son problemas distintos. La amplificación SSDP abusa del servicio de descubrimiento UPnP de un dispositivo para reflejar tráfico sin necesitar comprometer el dispositivo en absoluto; es mal uso de una característica legítima. Las botnets IoT como Mirai requieren infectar realmente el dispositivo con malware, típicamente vía credenciales por defecto, y luego comandarlo para enviar tráfico directamente. Un solo dispositivo mal configurado podría teóricamente ser abusado por ambos métodos de forma independiente.
¿BCP38 detiene los ataques de amplificación SSDP? El filtrado de ingreso BCP38 (RFC 2827), aplicado en la red donde se origina el tráfico de ataque, evitaría que la consulta falsificada llegara jamás a los dispositivos UPnP expuestos, ya que el ataque depende por completo del IP spoofing para redirigir las respuestas a la víctima. La adopción de BCP38 sigue siendo incompleta a nivel global, lo cual es parte de por qué la amplificación SSDP persiste como un vector viable.
¿Qué puertos usa la amplificación SSDP? SSDP opera sobre el puerto UDP 1900. El tráfico de ataque en un incidente de amplificación SSDP consiste en paquetes UDP con puerto de origen 1900, llegando a la víctima desde un gran número de direcciones IP de dispositivo IoT distintas, típicamente sin ningún request de descubrimiento saliente correspondiente de la red de la víctima.
¿La segmentación de red puede prevenir que los dispositivos IoT de mi organización sean usados como reflectores SSDP? Sí. Colocar los dispositivos IoT en VLAN aisladas con filtrado de egress que bloquee las respuestas SSDP salientes de llegar al internet público evita que esos dispositivos sean reclutados como reflectores, incluso si UPnP permanece habilitado para el descubrimiento de red local legítimo dentro del segmento.
Fuentes:
- CISA|US-CERT. “UDP-Based Amplification Attacks.” Alert TA14-017A.
- IETF. “Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing.” RFC 2827 (BCP38). 2000.
- UPnP Forum. “UPnP Device Architecture 2.0” y especificaciones “SSDP”.
- NIST SP 800-94. “Guide to Intrusion Detection and Prevention Systems (IDPS).”