Buenas prácticas de listas blancas de IP para bloques IPv4 arrendados

Las listas blancas de IP (IP whitelisting) son una de las ideas de control de acceso más antiguas de Internet, y una de las peor entendidas cuando las direcciones implicadas son arrendadas y no propias. La mecánica es la misma. La realidad operativa, no.

Esta guía recoge las buenas prácticas de listas blancas de IP específicas para bloques IPv4 arrendados: qué cambia cuando el espacio de direcciones que hay detrás de su lista de permitidos se alquila por un plazo determinado, por qué el historial de reputación importa más de lo que esperan la mayoría de los operadores y cómo configurar correctamente las listas blancas de IP arrendadas en sus propios firewalls y en AWS, GCP y Azure. El objetivo en todo momento es el operador de red en activo, no el buscador: al terminar, debería saber qué hacer en la práctica, no solo qué significan los términos.

¿Qué es una lista blanca de IP?

Las listas blancas de IP (cada vez más denominadas listas de permitidos o allowlists) son un modelo de seguridad basado en un único principio: denegar todo por defecto y permitir solo las direcciones IP de origen que se hayan aprobado expresamente. Todo lo que no figure en la lista se bloquea. Es lo contrario de las listas de bloqueo, que permiten todo salvo las direcciones conocidas como maliciosas.

En la práctica, una lista de permitidos se aplica en una o varias capas: un firewall perimetral, un grupo de seguridad en la nube, un balanceador de carga, la configuración de una aplicación o un API gateway. Una regla dice, en esencia: «el tráfico procedente de estos rangos CIDR puede llegar a este recurso por estos puertos; el resto se descarta».

Conviene ser honesto sobre lo que hacen y lo que no hacen las listas blancas, porque esa honestidad condiciona todas las buenas prácticas que siguen. Una dirección IP demuestra de dónde parece proceder un paquete. No demuestra quién lo envió ni qué dispositivo utiliza. Las direcciones pueden falsificarse, compartirse tras un NAT, secuestrarse o, sencillamente, reasignarse a otra persona el mes siguiente. Por eso, las listas blancas de IP son un buen control perimetral y un mal control de identidad. La primera buena práctica, antes de entrar en los detalles de las IP arrendadas, es esta: trate la lista de permitidos como una capa más de una estrategia de defensa en profundidad, combinada con una autenticación real, y no como un sustituto de esta.

Este enfoque es doblemente importante en los bloques arrendados, porque una IP arrendada arrastra un historial que usted no creó y un plazo que no controla por completo.

Retos de las IP arrendadas

Cuando incluye IPv4 arrendado en listas blancas, trabaja con dos elementos variables que el espacio propio no tiene: una reputación heredada y un reloj que corre contra el plazo del arrendamiento. Ambos generan fallos que ninguna guía genérica sobre listas blancas mencionará.

También conviene reconocer que las listas blancas de IP arrendadas funcionan en dos direcciones, y la mayoría de los operadores solo planifican una de ellas:

• Entrante: usted mantiene una lista de orígenes de confianza autorizados a acceder a los servicios alojados en su bloque arrendado.

• Ser incluido en listas blancas: sus IP arrendadas tienen que entrar en la lista de permitidos de otros: el firewall de un cliente, una pasarela de pago, la API de un socio, un relay SMTP. Aquí lo que se evalúa es el bloque arrendado, y su historial decide si se acepta.

Teniendo esto en cuenta, los retos específicos del arrendamiento son:

Reputación heredada o «residuos de abuso». Un bloque arrendado suele llegar con un historial de uso previo. Si un cliente anterior envió spam, realizó escaneos o acabó en Spamhaus, AbuseIPDB o bases de datos similares, esa reputación puede seguir asociada a las direcciones cuando llegan a usted. La consecuencia para las listas blancas es directa: los sistemas automáticos de reputación del otro lado pueden negarse a añadir un rango marcado a su lista de permitidos, limitarlo o enviarlo discretamente a una verificación adicional. Puede tener una lista de permitidos perfectamente configurada en su lado y, aun así, no conseguir que le incluyan en la del otro. Esta es la principal razón para partir de un bloque limpio y verificado en lugar del más barato disponible.

El plazo de arrendamiento provoca el deterioro de las listas de permitidos. Las direcciones propias son suyas indefinidamente; un bloque arrendado lo es durante un periodo determinado. Cualquier entrada de larga duración que haga referencia a espacio arrendado (el suyo en el firewall de un socio, o el rango arrendado de un socio en el suyo) puede quedar obsoleta sin que nadie lo advierta cuando ese arrendamiento termina y el bloque se reasigna a otra organización. Una entrada que sobrevive al arrendamiento que la respalda no es solo un lastre: puede convertirse en una puerta abierta para quien tenga el bloque después. La higiene de las listas de permitidos al término de los arrendamientos es una tarea operativa real, no algo secundario.

Debe saber exactamente qué direcciones controla. A veces los arrendamientos cubren solo parte de un bloque, con derechos de subasignación que pueden extenderse o no al tamaño de prefijo que quiere incluir en la lista. Antes de escribir una sola regla, confirme los rangos exactos que está autorizado a anunciar y utilizar. Incluir en la lista una dirección que en realidad no controla es, en el mejor de los casos, una regla que nunca coincide.

La legitimidad del enrutamiento se sitúa antes del firewall. Una lista de permitidos del firewall filtra el tráfico que ya ha llegado. No garantiza en absoluto que el prefijo arrendado se enrute válidamente hacia usted. Si la Route Origin Authorization (ROA) falta o es incorrecta, las redes que aplican la validación del origen de rutas pueden descartar su anuncio por completo, y entonces no hay tráfico que filtrar. Que RPKI/ROA estén correctos es un requisito previo de las listas blancas de IP arrendadas, no una alternativa. Para la parte de enrutamiento, nuestra guía sobre RPKI y el secuestro de BGP explica en detalle la configuración del ROA y la trampa de la longitud máxima.

Un bloque arrendado limpio y bien documentado elimina la mayoría de estas fricciones antes de que aparezcan. Si busca espacio precisamente para que socios o clientes lo incluyan en sus listas blancas, conviene elegir dónde arrendar bloques IPv4 en función de la reputación documentada y la higiene de enrutamiento, no solo del precio.

Cómo incluir IP arrendadas en listas blancas

El flujo de trabajo recomendado para las listas blancas de IP arrendadas es, en su mayor parte, la disciplina estándar de las listas de permitidos, con tres controles específicos del arrendamiento incorporados (señalados a continuación).

1. Confirme los rangos exactos que controla (específico del arrendamiento). Verifique con su arrendador qué bloques CIDR cubre el arrendamiento, si se permite la subasignación y que el ROA autoriza el ASN correcto. Obténgalo por escrito antes de configurar nada. Para los pasos de configuración de la propia subred, la guía de nuestro Centro de ayuda sobre cómo configurar una subred arrendada es el punto de partida.

2. Deniegue por defecto. La política base debe bloquear todo el tráfico entrante, y la lista de permitidos debe ser un conjunto de excepciones explícitas. Si su plataforma permite por defecto, corrija eso primero: de lo contrario, todo lo demás es cosmético.

3. Incluya rangos, no direcciones sueltas, y escríbalos en notación CIDR. Utilice el CIDR más pequeño que cubra un origen de confianza en lugar de una maraña de entradas /32 individuales. Es más fácil de leer, más fácil de auditar y mucho más fácil de revocar limpiamente.

4. Mantenga una única fuente de verdad. Mantenga un registro de referencia de qué está en la lista de permitidos, dónde y por qué, con un responsable y una fecha de revisión para cada entrada. Una lista que nadie sabe explicar es una lista de la que nadie se atreverá a eliminar nada.

5. Combínela con autenticación. Como una IP no es una identidad, combine la lista de permitidos con certificados, TLS mutuo, claves de API o un proveedor de identidad. La lista blanca estrecha la puerta de entrada; la autenticación comprueba quién la cruza.

6. Planifique el final del arrendamiento (específico del arrendamiento). Para cada entrada que haga referencia a espacio arrendado, suyo o de un socio, registre cuándo termina el arrendamiento correspondiente y revise o elimine la entrada en ese momento. Este es el paso que impide que un bloque reasignado herede un acceso que nunca debió tener.

7. Supervise y audite periódicamente. Revise las listas de permitidos con regularidad, vigile los registros de conexiones denegadas para detectar tráfico legítimo bloqueado por error y vuelva a comprobar periódicamente la reputación de su propio bloque arrendado: la reputación cambia, y un bloque limpio puede adquirir problemas a causa de sus propias cargas de trabajo.

Guías de los principales proveedores (AWS, GCP, Azure)

Las tres grandes nubes implementan las listas blancas de IP como reglas de firewall con estado asociadas a los recursos. Los conceptos son equivalentes entre proveedores; cambian los nombres y algunos detalles de funcionamiento. Hay un punto que se aplica antes que todo lo demás: si su bloque arrendado llega a la nube mediante BYOIP, el ROA debe autorizar el ASN de ese proveedor o el prefijo no se anunciará en absoluto, así que primero van los requisitos de enrutamiento descritos en nuestra guía sobre BYOIP con IPv4 arrendado en AWS, GCP y Azure, y después las listas blancas.

AWS. Las listas de permitidos de entrada se gestionan principalmente mediante security groups (con estado: el tráfico de retorno se permite automáticamente) y, en el perímetro de la subred, network ACLs (sin estado: ambos sentidos deben definirse explícitamente). La buena práctica que escala es mantener sus rangos de origen de confianza en una customer-managed prefix list y hacer referencia a ella desde sus reglas de security group y de Network Firewall, en lugar de codificar los CIDR en cada regla. Cuando cambia un rango, actualiza la prefix list en un solo lugar y todas las reglas que la referencian se actualizan, lo que además convierte la limpieza al final del arrendamiento en una única edición en lugar de una búsqueda entre decenas de reglas.

GCP. El firewall de Google Cloud (ahora bajo Cloud Next Generation Firewall) tiene estado y se aplica directamente en la interfaz de cada VM. Puede escribir reglas como VPC firewall rules tradicionales (una sola VPC, aplicadas mediante network tags o service accounts) o, en el modelo actual, como network firewall policies (contenedores de reglas reutilizables que se asocian a una o varias VPC) y hierarchical firewall policies aplicadas a nivel de carpeta u organización. Las políticas le permiten aplicar una misma lista de permitidos de forma coherente en una VPC, una carpeta o toda la organización, en lugar de mantener reglas proyecto por proyecto, y las políticas más recientes se dirigen a las cargas de trabajo mediante tags (secure tags) gobernados por IAM en lugar de simples network tags. Para el espacio arrendado incorporado mediante el modelo Public Advertised Prefix / Public Delegated Prefix de GCP, asocie sus reglas de entrada a los recursos que sirven desde el prefijo delegado.

Azure. Azure aplica las listas de permitidos mediante Network Security Groups (NSG), cuyas reglas se procesan por orden de prioridad (primero el número más bajo), y Application Security Groups (ASG), que le permiten agrupar sus propios recursos de backend por función y referenciarlos por nombre de grupo en las reglas de NSG en lugar de por IP individual, de modo que las reglas se mantienen estables aunque se añadan o sustituyan los recursos que hay detrás. Para una política más amplia y centralizada en muchas subredes, Azure Firewall complementa la capa de NSG por recurso.

La buena práctica común a los tres: construir las reglas en torno a objetos reutilizables (prefix lists para los rangos de origen de confianza en AWS, tags y ASG para agrupar recursos en GCP y Azure) en lugar de codificar direcciones en reglas individuales. Con bloques arrendados de plazo limitado, esa indirección es lo que convierte un cambio al final del arrendamiento en una actualización de una sola línea en lugar de una revisión arriesgada.

Reglas de firewall para bloques arrendados

Más allá de los detalles de cada proveedor, dos cuestiones estructurales determinan cómo resisten con el tiempo las listas blancas de IP arrendadas: si las direcciones son estáticas y qué parte de la gestión de reglas se automatiza.

Rotativas frente a estáticas

Las listas blancas de IP solo funcionan cuando las direcciones de la lista son estables. Precisamente por eso las IP de nube rotativas, efímeras o asignadas dinámicamente encajan mal en las listas de permitidos: cada rotación rompe un acceso legítimo u obliga a actualizar reglas a toda prisa, y los equipos bajo presión suelen «solucionarlo» ampliando el rango hasta que la lista apenas restringe nada.

Un bloque IPv4 arrendado es estático por naturaleza, y esa es una de las principales razones por las que el espacio arrendado se adapta bien a las listas blancas, tanto para sus reglas de entrada como para ser aceptado de forma fiable en las listas de permitidos de sus socios. La salvedad, específica del arrendamiento, es que aquí «estático» significa estable durante el plazo de arrendamiento, no para siempre. Trate la fecha de fin del arrendamiento como un evento planificado en el ciclo de vida de su firewall: la dirección es estable hasta el mismo día en que se reasigna. Lo estático es la opción correcta; solo tiene que anotar la fecha límite en la agenda.

Scripts de automatización: una mirada crítica

La automatización es el consejo habitual para mantener actualizadas las listas de permitidos del firewall y, para la distribución, realmente se gana su lugar: definir los rangos de confianza como código (managed prefix lists, infraestructura como código, políticas jerárquicas) y sincronizarlos desde una única fuente de verdad revisada elimina el trabajo propenso a errores de editar la misma regla en veinte sitios. Hasta ahí, todo correcto.

Pero la automatización merece un examen serio antes de confiarle la lista de permitidos, porque el mismo pipeline que mantiene las reglas al día puede socavar silenciosamente el modelo de seguridad:

• El descubrimiento automático amplía el acceso sin avisar. Un script que añade IP a una lista de permitidos a partir de una fuente en vivo o de un origen detectado automáticamente puede ampliar el conjunto de confianza sin que nadie revise lo añadido. Las listas de permitidos deben denegar por defecto con excepciones revisadas; el descubrimiento automático invierte eso sin que se note.

• El pipeline se convierte en una superficie de ataque. Si un sistema de automatización comprometido o defectuoso puede introducir un CIDR en todas las listas de permitidos a la vez, ha creado un único punto por el que una entrada errónea llega a todas partes. El alcance de un error crece con el alcance de la automatización.

• Las reglas «autorreparables» pueden anular la revocación. Una automatización que vuelve a aplicar un estado deseado añadirá de nuevo, sin problema, una entrada que usted eliminó a propósito, incluido, al final de un arrendamiento, un rango que debería haberse retirado. La revocación tiene que prevalecer sobre la reconciliación; de lo contrario, no es una revocación.

• El exceso de automatización oculta lo que realmente está permitido. Cuando las reglas se generan en lugar de leerse, los equipos pierden la noción intuitiva de quién puede acceder a qué, que es precisamente el conocimiento del que depende una auditoría.

La práctica equilibrada: automatice la distribución de las listas de permitidos desde una única fuente de verdad con control de versiones, pero mantenga una revisión humana sobre lo que entra en esa fuente, sobre todo en el caso de los rangos arrendados, cuya validez está limitada por un arrendamiento del que debe hacer seguimiento. Registre cada cambio, haga que la fuente sea auditable y asegúrese de que lo eliminado sigue eliminado. La automatización debe facilitar la gestión de la lista de permitidos, nunca dificultar su comprensión.

En resumen: las buenas prácticas de listas blancas de IP para IPv4 arrendado son las disciplinas habituales de las listas de permitidos (denegar por defecto, rangos CIDR, una única fuente de verdad, autenticación por capas, auditorías periódicas) más tres aspectos que el espacio propio le permite ignorar: partir de un bloque con reputación limpia, mantener correcto el enrutamiento (RPKI/ROA) antes del firewall y tratar el final del arrendamiento como un evento programado en el ciclo de vida de su lista de permitidos. Si resuelve bien esos tres aspectos, las listas blancas de IP arrendadas funcionan exactamente igual que las de espacio propio, con la ventaja de coste que aporta el arrendamiento.

***

¿Busca IPv4 limpio y listo para BYOIP que pueda incluir con total confianza en una lista de permitidos? Consulte los bloques disponibles para arrendar.