Qué es una IP bogon y por qué importa
Una dirección IP bogon es una dirección de espacio privado, reservado o sin asignar que nunca debería aparecer como origen de tráfico en internet público. El nombre viene de «bogus» (falso), y los rangos implicados los fijan IANA y un conjunto de RFC, de modo que comprobar si una dirección es bogon es una consulta contra una lista publicada y basada en estándares, no una conjetura.
Los principales rangos bogon
Hay dos grupos que conviene separar. Los rangos reservados de propósito especial están definidos por estándares y nunca se encaminarán públicamente. El espacio sin asignar, a veces llamado «bogons completos», es espacio de direcciones que ningún registro ha entregado todavía. Los rangos reservados siguientes son los que encontrarás con más frecuencia.
0.0.0.0/8: «esta red»; aparece como origen cuando un host todavía no tiene dirección.10.0.0.0/8,172.16.0.0/12,192.168.0.0/16: redes privadas de la RFC 1918.100.64.0.0/10: espacio de direcciones compartido para NAT de nivel de operador (RFC 6598).127.0.0.0/8: bucle local.169.254.0.0/16: enlace local, asignado automáticamente cuando falla DHCP.192.0.0.0/24: asignaciones de protocolo de la IETF.192.0.2.0/24,198.51.100.0/24,203.0.113.0/24: bloques de documentación (RFC 5737) que verás en ejemplos y tutoriales.198.18.0.0/15: pruebas de rendimiento de red (RFC 2544).224.0.0.0/4: multidifusión.240.0.0.0/4: reservado para uso futuro, más255.255.255.255, la dirección de difusión limitada.
En IPv6, los equivalentes incluyen ::/128 (no especificada), ::1/128 (bucle local), fc00::/7 (direcciones locales únicas), fe80::/10 (enlace local), ff00::/8 (multidifusión) y 2001:db8::/32 (documentación). Las direcciones IPv4 mapeadas, como ::ffff:0:0/96, y el prefijo NAT64 64:ff9b::/96 también merecen atención, porque son mecanismos de traducción que tampoco deberían aparecer como direcciones de cliente. Algunos textos más antiguos incluyen además 192.88.99.0/24 (anycast de retransmisión 6to4), que ha quedado obsoleto.
Por qué importa un bogon en tus registros
Si un bogon aparece como cliente aparente de una solicitud que llegó a través de internet público, ocurre una de varias cosas, y no siempre es malicioso. A menudo la causa es de fontanería: un proxy inverso o un balanceador de carga no pasa la dirección real del cliente, por lo que tu aplicación ve la dirección privada del proxy; una entrada de X-Forwarded-For se ha tomado de la posición equivocada; o una configuración de NAT ha filtrado una dirección interna a un campo público. Son errores de configuración y conviene corregirlos porque rompen la limitación de frecuencia, la geolocalización y los informes de abuso.
La otra causa es deliberada. Las direcciones de origen se pueden falsificar en los paquetes y en las cabeceras, y los atacantes usan orígenes bogon para inundaciones falsificadas o para sondear el filtrado. Como el tráfico legítimo no puede originarse en estos rangos, los operadores ascendentes los filtran en el borde de la red (la idea detrás del filtrado de entrada de la BCP 38), y tu propio cortafuegos debería descartar los orígenes bogon que lleguen por interfaces públicas. Ojo al matiz: dentro de tu red, las direcciones privadas son normales, así que aplica la regla solo en el límite público.
Espacio reservado frente a espacio sin asignar
La distinción importa cuando construyes tu propio filtro. Los rangos reservados los fijan los estándares y cambian pocas veces, por lo que una tabla estática de ellos sigue siendo correcta durante años. El espacio sin asignar es distinto, porque los registros entregan bloques con el tiempo y una dirección que era bogon el año pasado puede pertenecer hoy a una red real. Los filtros que codifican de forma fija bloques sin asignar han bloqueado históricamente a nuevos clientes de rangos recién asignados, y por eso la lista de reservados es lo más seguro de incrustar en el código de una aplicación, y por eso las cuestiones de titularidad de direcciones públicas corresponden a los datos del registro y no a una lista de bogons.
Comprobar una dirección
Puedes probar cualquier dirección en el verificador de IP bogon, que la compara con los rangos reservados publicados de IPv4 e IPv6 y muestra el bloque coincidente con una tabla de referencia. En la API, la respuesta de consulta de IP incluye bogon y bogon_type, de modo que una canalización de registros puede marcar estas direcciones sin tablas de rangos propias. La documentación de la API enumera la respuesta completa.
Conviene conocer un límite. El verificador usa una lista de reservados basada en estándares, no una vista en vivo de lo que se encamina. Una dirección fuera de los rangos reservados no tiene garantizado estar asignada ni ser alcanzable. Para saber si una dirección pública tiene realmente un propietario, usa la búsqueda WHOIS de IP para ver el registro, o la búsqueda de ASN para ver la red que la anuncia.
Gestión práctica
- Normaliza y valida las direcciones pronto; rechaza los bogons en campos que esperan una IP de cliente pública.
- Descarta los orígenes bogon en tu borde público con reglas de cortafuegos, pero no los apliques al tráfico interno.
- Cuando aparezca un bogon inesperadamente, revisa primero la configuración del proxy y del balanceador de carga, ya que la mala configuración es más común que el ataque.
- Recuerda que las direcciones bogon no tienen geolocalización, así que omite las consultas de geolocalización y reputación para ellas y ahórrate la solicitud.