IPv4, IPv6 y firewalls: revise las rutas hacia su servidor
Un servicio puede ser accesible a través de más de una familia de direcciones y de más de una capa de red. Restringir un puerto IPv4 no demuestra que el mismo servicio esté restringido a través de IPv6. Base la revisión en las rutas que existen realmente, incluidos el DNS, los procesos en escucha, las reglas de host y cualquier control ascendente.
La conclusión práctica
Inventaríe ambas familias de direcciones, exponga solo los servicios previstos, conserve el tráfico de control que necesita la red y pruebe el acceso desde fuera del servidor tras cada cambio relevante.
Empiece por los servicios y las direcciones, no por una lista de reglas
Enumere cada servicio de cara al público, el transporte que utiliza, su puerto de escucha y el público que debe acceder a él. Una aplicación web, una interfaz administrativa y una base de datos suelen necesitar una exposición diferente. Registre las direcciones asignadas realmente al servidor y las interfaces en las que escucha cada proceso. Un proceso vinculado a una dirección de bucle local tiene un límite previsto distinto del de uno que escucha en todas las interfaces disponibles.
Incluya IPv4 y IPv6 en el mismo inventario, manteniendo distintas sus direcciones y el tratamiento de sus políticas. El DNS público puede dirigir a los visitantes a IPv4 mediante un registro A y a IPv6 mediante un registro AAAA. La presencia o ausencia de un registro no sustituye la comprobación del propio servicio. Quien ya conoce una dirección puede acceder a ella sin usar el nombre de host que esperaba.
HM Bastion describe la asignación de IPv6 como dependiente de la disponibilidad del grupo de direcciones. Confirme la asignación y la configuración del servicio real antes de planificar en torno a ello. Las opciones adicionales de IPv4 son independientes del número de puertos de aplicación expuestos: otra dirección no es un firewall ni sustituye la autenticación de la aplicación. Mantenga los requisitos de red en el pedido o en el resumen de soporte en lugar de suponer que una disposición concreta de direcciones se deriva del nombre de un rango.
Siga la política en cada capa que gestiona el tráfico
Una conexión puede atravesar los controles de red del proveedor, un firewall del host, una red de contenedores, un proxy inverso y las propias comprobaciones de acceso de la aplicación. Documente qué capas existen en su despliegue y quién gestiona cada una. Dos controles útiles pueden complementarse, pero también pueden dificultar la localización de un fallo cuando sus reglas no están registradas. Una configuración del host no debería depender de una restricción ascendente que nunca se ha confirmado.
| Capa | Pregunta a responder | Prueba útil |
|---|---|---|
| DNS y direcciones públicas | ¿Qué destinos pueden descubrir los clientes o conocer ya? | Inspeccione las respuestas A y AAAA previstas |
| Proceso en escucha | ¿Qué direcciones y transportes aceptan conexiones? | Compruebe la configuración del servicio y los procesos en escucha activos |
| Política de red y de host | ¿Qué orígenes pueden alcanzar cada servicio? | Pruebe externamente las rutas permitidas y denegadas |
| Aplicación | ¿Quién puede realizar una acción tras conectarse? | Compruebe la autenticación y la autorización con cuentas de prueba |
Si utiliza un gestor de firewall, confirme cómo trata ambas familias de IP en la configuración instalada. Consulte la documentación de la herramienta y de la distribución en lugar de suponer que los valores predeterminados son idénticos en todas partes. Las plataformas de contenedores pueden añadir sus propias reglas de red y filtrado, por lo que un puerto de contenedor publicado merece una revisión explícita. No utilice el estado aparente de un comando conocido como prueba de la ruta completa hasta la carga de trabajo.
Prefiera una política reducida que coincida con el inventario. El tráfico web público puede proceder de muchos orígenes, mientras que el acceso administrativo puede tener una política de orígenes más restringida cuando sea posible. Las bases de datos y los endpoints de gestión interna a menudo no necesitan acceso público directo en absoluto. Mantenga una vía de acceso de recuperación mientras cambia las reglas y verifique una segunda sesión permitida antes de cerrar la única conexión administrativa que funciona.
Evite romper la red al intentar reducir la exposición
IPv6 depende de ICMPv6 para funciones más allá de una simple prueba de eco. Una regla general que descarte todo ICMPv6 puede alterar el comportamiento necesario de la red, incluidos el descubrimiento y la gestión de errores relevantes para la entrega de paquetes. La guía de filtrado del IETF distingue entre tipos de mensajes y las funciones de los distintos límites. Utilice la guía adecuada al entorno en lugar de copiar un conjunto de reglas sin explicación que trata todo mensaje de control como hostil.
Una red que parece funcionar para una solicitud pequeña puede seguir fallando para otros tamaños o rutas de tráfico. Pruebe intercambios reales de la aplicación, no solo si se abre un puerto. Compare el comportamiento desde redes que admitan la familia de direcciones prevista y conserve la hora y el destino exactos al diagnosticar un problema. Una prueba de IPv6 fallida desde un cliente sin una ruta IPv6 utilizable dice poco sobre la configuración de la aplicación del servidor.
La mitigación de DDoS y la exposición de servicios también resuelven problemas distintos. La mitigación puede reducir el tráfico de ataque, mientras que una política de firewall define la accesibilidad de red permitida en su límite. Ninguna sustituye a las cuentas de aplicación seguras, las actualizaciones ni el manejo cuidadoso de los secretos. Un panel administrativo expuesto puede ser un riesgo aunque su consumo de ancho de banda sea mínimo. Revise qué puede hacer una conexión autorizada después de llegar al servicio.
Pruebe el límite previsto y mantenga una vía de reversión
- Registre las reglas actuales, la política prevista y el método de acceso de recuperación.
- Aplique un cambio limitado durante una ventana de mantenimiento adecuada.
- Pruebe las conexiones permitidas y denegadas para cada familia de direcciones relevante.
- Verifique el sitio web normal y las dependencias internas necesarias.
- Registre la política final y elimine las excepciones de diagnóstico temporales.
Por ejemplo, tras mover una interfaz de administración detrás de un acceso restringido, verifique que un operador aprobado aún puede conectarse y que una ruta externa ordinaria no puede. Repita esa comprobación para cada familia pública asignada en la que escuche la interfaz. Realice estas pruebas solo contra sistemas que usted opere o tenga permiso para probar. El objetivo es verificar un límite definido, no generar escaneos amplios contra direcciones no relacionadas.
Vuelva al inventario después de publicar una nueva aplicación, habilitar IPv6, añadir una plataforma de contenedores o cambiar los proxies. Estos cambios pueden introducir un nuevo listener sin alterar de forma evidente la lista de reglas anterior. Un registro breve que vincule servicio, dirección, puerto, propietario y audiencia permitida agiliza las revisiones futuras y reduce la dependencia de quien editó el firewall por última vez.
