¿Qué son las direcciones IP bogon?

Las direcciones IP bogon (o bogons) son direcciones IP que nunca deberían aparecer como origen o destino en el enrutamiento legítimo de internet, porque caen en rangos que la IANA no ha asignado, están reservados para propósitos especiales, o están designados para uso privado bajo RFC 1918, RFC 5735 y RFC 6890. El tráfico que porta una dirección de origen bogon es una señal fuerte de spoofing IP o de mala configuración, lo que convierte al filtrado de bogons en un control fundamental y de bajo costo dentro de las arquitecturas de defensa anti-spoofing y anti-DDoS.

Resumen rápido — Los bogons son rangos de direcciones IP que no tienen ninguna razón legítima para aparecer en el internet público: espacio no asignado, bloques reservados, rangos de uso privado, rangos de documentación, multicast y otras asignaciones de propósito especial definidas por la IANA y codificadas en RFC como 1918, 5735 y 6890. Como estos rangos no pueden representar hosts reales de internet, cualquier paquete que llegue desde o vaya hacia una dirección bogon es casi con certeza producto de spoofing, enrutamiento incorrecto o mala configuración. Las redes filtran bogons a nivel de BGP y ACL de firewall usando listas mantenidas como la de Team Cymru, reduciendo la superficie de ataque disponible para tráfico DDoS con origen falsificado y complementando controles de validación de origen como BCP38 y uRPF.

Última actualización: 2026-08-08

Cómo funciona el filtrado de bogons

Qué hace que una dirección sea un bogon

El Registro IANA de Direcciones IPv4 de Propósito Especial y su contraparte IPv6 rastrean formalmente cada bloque reservado, privado u otro de propósito especial. Un bogon es cualquier dirección dentro de un bloque que:

1. No ha sido asignado por la IANA a un Registro Regional de Internet (espacio no asignado, o “dark”), o
2. Ha sido reservado para un propósito específico no enrutable (uso privado, documentación, loopback, link-local, multicast o uso futuro).

Como estos rangos no están asignados a ninguna organización o están reservados explícitamente para propósitos no enrutables en internet, un paquete con una dirección de origen bogon no puede representar un host real y alcanzable de internet: está falsificado, mal configurado, o se está filtrando desde una red interna.

Categorías y rangos de bogons de ejemplo:

0.0.0.0/8          Red "esta" — reservada (RFC 791 / RFC 1122)
10.0.0.0/8         Uso privado (RFC 1918)
100.64.0.0/10      Espacio de direcciones compartido, NAT de operador (RFC 6598)
127.0.0.0/8        Loopback (RFC 1122)
169.254.0.0/16     Link-local (RFC 3927)
172.16.0.0/12      Uso privado (RFC 1918)
192.0.0.0/24       Asignaciones de protocolo IETF (RFC 6890)
192.0.2.0/24       Documentación — TEST-NET-1 (RFC 5737)
192.168.0.0/16     Uso privado (RFC 1918)
198.18.0.0/15      Benchmarking (RFC 2544)
198.51.100.0/24    Documentación — TEST-NET-2 (RFC 5737)
203.0.113.0/24     Documentación — TEST-NET-3 (RFC 5737)
224.0.0.0/4        Multicast (RFC 5771)
240.0.0.0/4        Reservado para uso futuro (RFC 1112 / RFC 6890)

Por qué el tráfico bogon indica spoofing o mala configuración

El tráfico legítimo de internet nunca debería portar una dirección de origen de un rango de uso privado, reservado, de documentación o no asignado, porque ningún host real en el internet público tiene asignada una de esas direcciones. Cuando aparece una dirección bogon:

Paquete con origen bogon llegando desde internet público:

Internet ──paquete, src=192.0.2.55 (TEST-NET-1, solo documentación)──▶ Tu red

Esto no puede ser una ruta de retorno real. Dos explicaciones:
1. Spoofing — un atacante fabricó deliberadamente una dirección de
   origen de un rango bogon, a menudo como parte de un DDoS o de una
   configuración de reflexión/amplificación
2. Mala configuración — un dispositivo mal configurado, un límite de
   NAT, o un entorno de laboratorio/pruebas está filtrando
   direcciones no enrutables hacia el internet público

El tráfico con destino bogon (paquetes enviados hacia una dirección bogon desde dentro de tu red) usualmente indica enrutamiento mal configurado, rutas estáticas obsoletas, o hosts comprometidos intentando alcanzar espacio no enrutable o no asignado, a veces como parte de un comportamiento de malware que sondea servicios internos.

Categorías de rangos bogon

Bogons vs. Fullbogons

Las listas clásicas de “bogon” cubren el espacio que la IANA nunca ha asignado a ningún Registro Regional de Internet, más los rangos reservados de propósito especial mencionados arriba. Las listas “fullbogon” extienden esto para incluir espacio asignado por la IANA que aún no ha sido asignado por un Registro Regional de Internet a un operador de red real: espacio que técnicamente está asignado a nivel superior pero que todavía no es legítimamente enrutable en ningún lugar. Como las asignaciones de la IANA cambian con el tiempo, las listas fullbogon requieren actualizaciones más frecuentes que la lista de rangos reservados, que es mayormente estática.

Señales de detección y telemetría

# Verifica si una ruta o prefijo coincide con espacio bogon conocido (ejemplo usando
# una lista local de prefijos bogon cargada en un filtro de rutas)
grep -F "192.0.2." /etc/bogon-bn-agg.txt

# Filtrado de rutas BGP — rechaza anuncios de prefijos bogon (ejemplo de ACL estilo Cisco)
ip prefix-list BOGONS seq 5 deny 0.0.0.0/8 le 32
ip prefix-list BOGONS seq 10 deny 10.0.0.0/8 le 32
ip prefix-list BOGONS seq 15 deny 127.0.0.0/8 le 32

# iptables — descarta paquetes entrantes con direcciones de origen bogon en el firewall
iptables -A INPUT -s 10.0.0.0/8 -i eth0 -j DROP
iptables -A INPUT -s 192.0.2.0/24 -i eth0 -j DROP
iptables -A INPUT -s 240.0.0.0/4 -i eth0 -j DROP

# Análisis de flujo — correlaciona tráfico con origen bogon con posible spoofing
# usando herramientas NetFlow/sFlow filtradas contra una lista de bogons mantenida

Mitigación e implementación

Mantener y suscribirse a listas de bogons

Dos fuentes autoritativas anclan la mayoría de los programas de filtrado de bogons:

• La referencia de bogons de Team Cymru ofrece listas de bogons y fullbogons actualizadas regularmente en múltiples formatos consumibles, incluyendo listas de texto estáticas y un feed BGP con el que las redes pueden hacer peering para recibir actualizaciones en vivo.
• El Registro IANA de Direcciones IPv4 de Propósito Especial (y su equivalente IPv6) es el registro autoritativo de cada bloque reservado o de propósito especial, y es la fuente de la que derivan proyectos como la lista de Team Cymru.

Automatizar actualizaciones de ACL de bogons

Como la IANA asigna periódicamente espacio previamente no asignado a los Registros Regionales de Internet, las listas de bogons estáticas envejecen y pueden volverse inexactas: un bloque que era bogon el año pasado puede estar enrutado legítimamente hoy. Automatizar las actualizaciones es esencial:

El filtrado de bogons como una capa anti-spoofing

El filtrado de bogons aborda un problema más acotado pero complementario a los controles de validación de dirección de origen:

• BCP38 / RFC 2827 exige que las redes filtren el tráfico saliente de modo que los paquetes que salen de una red de cliente porten únicamente direcciones de origen legítimamente asignadas a esa red; esto detiene el spoofing en la red de origen.
• uRPF (Unicast Reverse Path Forwarding), según RFC 3704, verifica que la dirección de origen del tráfico entrante tenga una ruta de retorno válida a través de la interfaz receptora; esto detiene parte del spoofing en puntos de tránsito y peering.
• El filtrado de bogons rechaza tráfico con direcciones de origen o destino que nunca podrían ser legítimas en ningún lugar de internet, sin importar la topología de la ruta de retorno; esto detiene el caso específico y común de direcciones obviamente fabricadas, incluyendo muchas usadas en configuraciones de reflexión y amplificación.

Ninguno de estos tres controles es suficiente por sí solo. BCP38 depende de la adopción por parte de la red de origen, que sigue siendo desigual a nivel global; el modo estricto de uRPF puede romper el enrutamiento asimétrico legítimo; el filtrado de bogons solo detecta direcciones en rangos no enrutables conocidos y no hace nada contra el spoofing que usa una dirección IP real, legítimamente asignada pero no relacionada. Combinar los tres cierra más superficie de spoofing que cualquier control individual.

Errores comunes

Cómo implementarlo con Azion

El filtrado de bogons es una capa dentro de una postura de defensa anti-spoofing y anti-DDoS más amplia. Azion aplica filtrado a nivel de red en puntos de presencia distribuidos antes de que el tráfico llegue a la infraestructura de origen:

• Network Shield soporta reglas programables a nivel de red usando listas basadas en IP, CIDR y ASN, que se pueden configurar para reflejar políticas de filtrado de bogons y de orígenes conocidos como maliciosos.
• DDoS Protection brinda detección y mitigación siempre activa para patrones de tráfico con origen falsificado o de estilo reflexión en el edge.
• Firewall permite reglas personalizadas para validación de dirección de origen y bloqueo de rangos no enrutables conocidos.
• WAAP combina protecciones de red y de capa de aplicación para organizaciones que enfrentan campañas de ataque mixtas impulsadas por spoofing.

Como Azion se ubica en el edge de la red a través de puntos de presencia distribuidos, el tráfico con origen falsificado o bogon dirigido a técnicas de reflexión o amplificación puede filtrarse antes de que consuma ancho de banda o recursos de cómputo del origen. La adopción de bogon filtering, BCP38 por parte de proveedores upstream, y uRPF en puntos de tránsito siguen siendo controles complementarios que operan fuera de la plataforma de cualquier proveedor y deben verificarse como parte de una estrategia anti-spoofing completa.

Recursos relacionados

• ¿Qué es un ataque DDoS?
• Tipos de ataques DDoS
• ¿Qué es un ataque SYN flood?
• ¿Qué es la protección y mitigación DDoS?
• Azion DDoS Protection

Preguntas frecuentes

¿Qué son las direcciones IP bogon? Las direcciones IP bogon son rangos que nunca deberían aparecer en el enrutamiento legítimo de internet porque no están asignados por la IANA o están reservados para propósitos especiales no enrutables, como redes privadas, documentación, loopback o uso futuro. Cualquier tráfico que porte una dirección bogon como origen o destino indica spoofing o mala configuración.

¿Cuál es la diferencia entre bogons y fullbogons? Los bogons son los rangos permanentemente reservados de propósito especial definidos por RFC como 1918, 5735 y 6890, más el espacio que la IANA nunca ha asignado. Los fullbogons además incluyen espacio asignado por la IANA que aún no ha sido asignado por un Registro Regional de Internet a un operador; espacio que cambia conforme ocurren nuevas asignaciones, requiriendo actualizaciones de lista más frecuentes.

¿Los rangos IP privados como 10.0.0.0/8 son siempre bogons? Sí, cuando se ven en el internet público. Los rangos de uso privado de RFC 1918 (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) son legítimos dentro de redes privadas, pero nunca deberían aparecer como dirección de origen o destino en interfaces orientadas al internet público. Su aparición ahí indica una mala configuración de NAT o un intento de spoofing.

¿Por qué el filtrado de bogons importa específicamente para la defensa DDoS? Muchas técnicas DDoS, especialmente los ataques de reflexión y amplificación, dependen de direcciones de origen falsificadas, y una porción de ese tráfico falsificado usa rangos bogon porque son fáciles de fabricar y, de otro modo, no se monitorean. Filtrar el tráfico con origen bogon elimina una porción significativa de esa superficie de spoofing a bajo costo operativo.

¿Qué es la lista de bogons de Team Cymru? Team Cymru mantiene y publica listas de bogons y fullbogons actualizadas regularmente, derivadas de los registros de asignación de la IANA, disponibles como feeds de texto estáticos y como un feed BGP en vivo con el que las redes pueden hacer peering para recibir actualizaciones continuas sin mantenimiento manual de listas.

¿El filtrado de bogons reemplaza a BCP38 o uRPF? No. El filtrado de bogons solo detecta tráfico que usa direcciones de rangos no enrutables conocidos. BCP38 (RFC 2827) filtra en la red de origen para asegurar que el tráfico saliente use solo direcciones legítimamente asignadas, y uRPF verifica que las direcciones de origen entrantes tengan una ruta de retorno válida. Un atacante que falsifique una dirección IP real, legítimamente asignada, que no sea un bogon, evadirá por completo el filtrado de bogons, por lo que los tres controles son complementarios, no sustitutos entre sí.

¿Qué pasa si una lista de bogons no se actualiza regularmente? Una lista de bogons obsoleta puede bloquear tráfico de espacio que la IANA ya asignó legítimamente a un operador, causando falsos positivos que descartan tráfico real, o puede fallar en filtrar rangos recién reservados, dejando un hueco de filtrado. Las actualizaciones automatizadas vía un feed mantenido o una sesión de peering BGP resuelven esto.

¿El tráfico con destino bogon desde dentro de mi red puede indicar un problema? Sí. El tráfico saliente con destino a rangos bogon usualmente apunta a rutas estáticas obsoletas o mal configuradas, o en algunos casos a malware que sondea servicios internos. Vale la pena monitorear ambas direcciones, no solo el tráfico entrante con origen bogon.

¿El filtrado de bogons es efectivo contra botnets que usan direcciones IP reales de dispositivos comprometidos? No. El filtrado de bogons solo aborda tráfico que usa direcciones fabricadas de rangos no enrutables. Una botnet de dispositivos comprometidos que use sus propias direcciones IP legítimamente asignadas no aparecerá como tráfico bogon y requiere enfoques de detección distintos, como análisis conductual y volumétrico.

¿Dónde debería aplicarse el filtrado de bogons en una red? Idealmente en cada punto de entrada: routers de edge orientados a internet vía filtrado de prefijos BGP, firewalls vía ACL, y tablas de rutas de cloud o VPC donde aplique. Aplicarlo solo en un único punto de control puede dejar huecos en VPN, conexiones de peering o interconexiones de cloud que evaden el filtro principal.

Fuentes:

• IETF. “Address Allocation for Private Internets.” RFC 1918. 1996.
• IETF. “Special Use IPv4 Addresses.” RFC 5735. 2010.
• IETF. “Special-Purpose IP Address Registries.” RFC 6890. 2013.
• IETF. “IPv4 Address Blocks Reserved for Documentation.” RFC 5737. 2010.
• IETF. “IANA-Reserved IPv4 Prefix for Shared Address Space.” RFC 6598. 2012.
• IETF. “Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing.” RFC 2827 (BCP 38). 2000.
• IETF. “Network Ingress Filtering: Unicast Reverse Path Forwarding.” RFC 3704 (BCP 84). 2004.
• IANA. “IPv4 Special-Purpose Address Registry.”
• Team Cymru. “The Bogon Reference.”
• CISA. “Understanding and Responding to Distributed Denial-of-Service Attacks.”