Por qué una política de firewall siempre se degrada
Ninguna base de reglas se mantiene limpia. Cada regla se añadió por una buena razón, por alguien que tenía que resolver un problema ese día. Lo que casi nunca ocurre es su eliminación: el proyecto termina, el servidor se da de baja, el subcontratista se marcha y la regla se queda. Al cabo de unos años, la política describe la historia de la organización más que sus necesidades actuales.
Estos son los defectos que aparecen en casi todas las auditorías, y cómo detectarlos sin leer miles de líneas a mano.
Seis defectos recurrentes
1. Reglas ensombrecidas
Una regla situada más arriba en la lista intercepta todo el tráfico que debía gestionar otra regla inferior. Esta segunda nunca se aplicará. Es el defecto más engañoso: la regla existe, está documentada, tranquiliza, y está muerta. Encontrar reglas ensombrecidas exige analizar el orden y el solapamiento de los objetos, no leer las líneas por separado.
2. Duplicados
El mismo permiso expresado dos veces, a menudo con objetos de nombres distintos. En sí mismo es inofensivo, pero cada duplicado duplica el trabajo de revisión y crea el riesgo de un cambio parcial: se restringe uno, se olvida el otro y el flujo sigue abierto.
3. Reglas demasiado permisivas
any/any es el caso más visible, pero rara vez el más frecuente. Las variantes más discretas hacen el mismo daño: un destino «any» en un puerto concreto, un grupo de objetos que ha crecido hasta cubrir una red entera, un servicio «any» en un par origen-destino por lo demás legítimo. El tráfico realmente permitido es mucho más amplio que la intención original.
4. Reglas sin uso
Una regla que no ha coincidido con ningún paquete en meses protege un flujo que ya no existe o permite uno que nadie vigila. Es la mejor candidata a la eliminación, pero la decisión requiere datos que la configuración por sí sola no contiene: los contadores de coincidencias.
5. Servicios inseguros
Telnet, FTP, SNMP v1 o v2c, gestión por HTTP sin cifrar: protocolos que siguen permitidos porque un equipo antiguo los necesitaba. La regla suele sobrevivir al equipo que la justificó.
6. Falta de registro
Una regla sin registro es invisible durante una investigación. Uno descubre que existe en el momento en que intenta explicar un incidente, es decir, demasiado tarde.
Por qué falla la revisión manual
Ninguno de estos defectos es visible leyendo las reglas una por una, porque todos son relacionales: surgen de la interacción entre varias reglas, el orden de evaluación y el contenido real de los grupos de objetos. Quien lee la línea 400 ya ha olvidado la línea 12. Es una tarea de análisis, no de lectura.
El problema multifabricante lo agrava: la misma intención se expresa de forma distinta en cada firewall, lo que impide comparar sedes sin normalizar antes.
Qué hacer con los hallazgos
Una auditoría que produce ochocientos hallazgos no se llevará a la práctica. Lo que hace útil el ejercicio es la priorización: primero, las reglas permisivas expuestas desde una zona no confiable; después, los servicios inseguros; luego, las reglas muertas cuya eliminación no conlleva riesgo. Los duplicados y los aspectos estéticos van al final.
El segundo hábito útil es medir la tendencia en lugar del estado: una política que mejora unos puntos cada trimestre vale más que una auditoría perfecta que nunca se aplica. Nuestra página de auditoría de reglas de firewall describe el análisis automatizado de estos defectos, y el módulo de firewall muestra cómo se atribuye el riesgo regla a regla.
