Una revisión de firewall encuentra una regla «origen cualquiera / destino cualquiera / permitir» cerca de la parte superior de la política. ¿Cuál es el problema y la solución?
Respuesta breve
Como los firewalls evalúan las reglas de arriba abajo, una regla any/any amplia cerca de la parte superior cortocircuita todas las reglas inferiores y permite todo el tráfico — el firewall deja en la práctica de aplicar nada. Reemplácela por reglas explícitas de mínimo privilegio para los flujos realmente necesarios, ordenadas para que los permisos y denegaciones específicos surtan efecto, terminando en una denegación por defecto. Llamarla eficiente es erróneo, moverla al final aún puede ocultar la denegación por defecto, y renombrarla no cambia nada de lo que permite.
Encontrar una regla any → any → permitir cerca de la parte superior de una política de firewall es encontrar un firewall que, en la práctica, no filtra nada en absoluto. La solución es eliminarla y reconstruir en torno al mínimo privilegio con un orden correcto.
Por qué una any/any en lo alto rompe todo
Los firewalls evalúan las reglas de arriba abajo, gana el primer match. La primera regla que coincide con un paquete decide su destino, y la evaluación se detiene ahí. Una regla que coincide con cualquier origen hacia cualquier destino coincide con cada paquete — por lo que se dispara antes de que la más mínima regla de denegación o de permiso acotado situada debajo tenga oportunidad. Esas reglas inferiores quedan ocultas (shadowed): presentes en la configuración, pero muertas. El resultado es un «permitir todo» implícito, que anula todo el propósito del dispositivo y suele violar referenciales como NIST SP 800-41 y los CIS Controls.
La solución correcta
Reconstruya sobre los principios de denegación por defecto y mínimo privilegio:
- Inventaríe los flujos genuinamente requeridos (origen, destino, puerto, protocolo) — use registros de conexión / NetFlow para no romper producción.
- Escriba reglas de permiso explícitas y estrechamente acotadas para exactamente esos flujos.
- Ordénelas para que las reglas específicas precedan a las generales, y coloque una denegación por defecto (con registro) al final para atrapar todo lo demás.
- Valide y luego elimine la regla any/any.
Por qué las demás respuestas son incorrectas
- «Es eficiente y está bien» confunde «coincide rápido» con «seguro». Es eficiente permitiendo ataques.
- Moverla al final sigue siendo peligroso: ahora oculta la denegación por defecto, volviendo a permitir todo lo que las reglas explícitas no permitían ya. La regla any/any simplemente debe eliminarse, no reubicarse.
- Renombrarla es cosmético — el comportamiento de coincidencia de paquetes es idéntico.
El entrevistador quiere ver que entiende el orden de evaluación como un control de seguridad, que sabe migrar al mínimo privilegio sin una caída y que una política limpia termina en una denegación por defecto en lugar de un permiso general.
Posibles preguntas de seguimiento
- ¿Por qué la evaluación por primer match, de arriba abajo, convierte el orden de las reglas en un control de seguridad?
- ¿Cómo reemplazaría la regla any/any de forma segura sin una caída — qué telemetría necesita primero?
- ¿Qué debe ir al final de una política bien formada, y por qué registrarlo?