El conjunto de reglas de un firewall —su policy set— es uno de los documentos vivos más maltratados de la infraestructura. Empieza limpio y con sentido, y con los años se convierte en un cajón de sastre: reglas "temporales" que nunca se quitaron, permisos amplios que alguien puso "para probar", y una capa geológica de decisiones que nadie recuerda. Y como nadie se atreve a borrar nada "por si algo se rompe", solo crece. Auditarlo no es burocracia: es higiene de seguridad.
Cómo envejece mal un policy set
Las patologías se repiten en casi todos los firewalls con años encima:
- Reglas obsoletas: permiten tráfico hacia servidores que se dieron de baja hace años. Ya no sirven a nadie, pero siguen abriendo camino.
- Reglas demasiado permisivas: ese "permitir cualquier origen a cualquier destino" que alguien puso para destrabar algo un viernes por la tarde, y que se quedó para siempre. Un boquete disfrazado de regla.
- Reglas sombreadas (shadowed): una regla más arriba en el orden hace que otra, más abajo, nunca llegue a evaluarse. Existe, ocupa espacio mental, y no hace nada —o peor, oculta la intención real—.
- Reglas duplicadas y sin dueño: la misma intención escrita tres veces, ninguna con un comentario que explique por qué existe ni quién la pidió.
Cada una de estas es, a la vez, superficie de ataque (permisos que no deberían existir) y deuda técnica (nadie entiende el conjunto, así que nadie se atreve a tocarlo).
Cómo se audita, en concreto
Una auditoría de reglas no es un arte oscuro; es una revisión metódica con preguntas accionables:
- ¿Qué reglas no se han usado? Un firewall serio lleva la cuenta de cuántas veces se "golpea" cada regla. Las que llevan meses en cero son las primeras candidatas a eliminar —con cuidado, verificando antes—.
- ¿Qué reglas son 'any-any'? Toda regla demasiado amplia se cuestiona: ¿de verdad necesita ser tan abierta, o puede acotarse a lo que realmente usa?
- ¿Qué reglas están sombreadas o duplicadas? Se detectan por análisis de orden y se limpian.
- ¿Cada regla tiene dueño, justificación y fecha de revisión? La que no los tenga, es sospechosa por definición.
La disciplina que lo previene
El antídoto no es una limpieza heroica cada cinco años, sino una higiene continua: cada regla nueva nace con un comentario que dice quién la pidió, por qué y hasta cuándo; los cambios temporales llevan fecha de caducidad; y el policy set se revisa periódicamente como el organismo vivo que es. Un conjunto de reglas podado y documentado no solo es más seguro —menos permisos de más—, también es más fácil de operar: cuando algo falla, sabes qué hace cada regla en lugar de temer tocarla. Herramientas de gestión como FortiManager ayudan a ver el uso real y a mantener el orden a escala.
La idea que se queda
Un policy set envejece mal por acumulación: reglas obsoletas, demasiado permisivas, sombreadas y sin dueño, que inflan la superficie de ataque y la confusión. Auditarlo —reglas sin uso, 'any-any', sombreadas, sin justificación— y sostener una higiene continua es lo que mantiene un firewall como una defensa y no como un misterio que nadie se atreve a tocar. La parte menos glamorosa y más rentable del perímetro moderno.