Qué hace un firewall de red
Un firewall aplica una política de seguridad al tráfico que cruza un punto de control. Examina información del flujo y decide permitir, rechazar o descartar según reglas. Puede implementarse como appliance físico, función virtual, software de host o servicio cloud. Su ubicación y política importan más que la forma del dispositivo.
La función básica es reducir comunicaciones no autorizadas entre zonas o redes con distinto nivel de confianza. Un firewall no sustituye segmentación, hardening de sistemas o autenticación; forma parte de una estrategia de defensa en profundidad.
Filtrado stateless frente a inspección stateful
Una ACL tradicional evalúa paquetes según campos como IP, protocolo y puerto sin mantener necesariamente el contexto completo de una sesión. Un firewall stateful mantiene una tabla de estado y puede permitir automáticamente paquetes de retorno que pertenecen a una conexión ya aceptada. Cisco describe stateful inspection como una tecnología que decide considerando estado, puerto, protocolo y contexto de la conexión.
El estado reduce la necesidad de escribir reglas simétricas para cada paquete de retorno, pero consume recursos y exige entender timeouts. Protocolos complejos, NAT o tráfico asimétrico pueden requerir consideraciones adicionales.
Zonas, interfaces y matriz de comunicaciones
Un diseño útil empieza agrupando interfaces o segmentos por función: usuarios, servidores, gestión, invitados, Internet, DMZ, etc. Después se define una matriz de qué origen puede hablar con qué destino y en qué servicios. Esa matriz se transforma en reglas ordenadas y observables.
“Inside permite todo hacia outside” puede ser un punto de partida histórico, pero no una política universal. En una red moderna también importa el tráfico lateral y de salida. El principio de mínimo privilegio recomienda habilitar sólo lo necesario y revisar excepciones.
Cómo diseñar reglas mantenibles
Una regla debería tener una intención identificable: origen, destino, servicio, acción, logging y comentario o ticket que explique por qué existe. Evita objetos ambiguos y reglas demasiado amplias que oculten requisitos diferentes. Ordena la política de forma que reglas específicas no queden eclipsadas por otras generales.
Las ACL comparten parte de esta lógica, pero un firewall puede añadir estado, objetos de aplicación, usuarios, inspección y otras capacidades. La documentación debe distinguir qué control vive en cada capa.
Firewall y NAT: relacionados pero no equivalentes
Muchos firewalls también realizan NAT/PAT, especialmente en el borde. Traducir una dirección no es una decisión de seguridad por sí misma. Una política puede permitir tráfico que además se traduce, o bloquearlo antes de que la traducción importe. Mantén separadas mentalmente “qué flujo se permite” y “qué direcciones se presentan en cada lado”.
La guía de NAT/PAT explica traducción, overload y troubleshooting. Cuando depures un firewall con NAT, identifica direcciones pre-NAT y post-NAT para no buscar el objeto equivocado en logs o capturas.
Inspección de aplicaciones y NGFW
Los firewalls de nueva generación pueden clasificar aplicaciones, inspeccionar contenido, integrar prevención de intrusiones, reputación o identidad. Estas funciones permiten políticas más expresivas que “TCP 443 permitido”, porque muchas aplicaciones comparten HTTPS. Sin embargo, inspección profunda puede introducir coste de CPU, latencia y requisitos de privacidad/certificados.
No habilites funciones únicamente porque existen. Define qué riesgo resuelven, mide capacidad y establece qué ocurre si el motor de inspección no puede clasificar un flujo.
DMZ y segmentación este-oeste
Una DMZ separa servicios expuestos de redes internas para limitar impacto si un sistema público se compromete. El mismo principio puede aplicarse internamente: usuarios, servidores, administración, backups y sistemas críticos pueden vivir en segmentos con políticas explícitas entre ellos.
VLAN y VRF ayudan a construir dominios separados; el firewall aporta el punto de política cuando esos dominios deben comunicarse. La arquitectura debe evitar caminos alternativos que salten el control.
Alta disponibilidad y estado de sesiones
Un firewall puede ser un punto crítico del camino. Los pares HA permiten que otro nodo asuma servicio ante fallo, pero la experiencia durante el cambio depende de si se sincroniza estado, cómo convergen las rutas y cómo se actualizan vecinos de Capa 2. Una pareja encendida no garantiza alta disponibilidad si ambos dependen del mismo enlace o alimentación.
Prueba fallos reales y parciales: pérdida de uplink, proceso de inspección, nodo, enlace de sincronización y recuperación. Documenta qué sesiones sobreviven y cuáles deben restablecerse.
Logs y observabilidad del firewall
Un “deny” sin contexto puede ser tan poco útil como no registrar nada. Los logs deberían permitir responder quién originó el flujo, a qué destino, qué regla tomó la decisión, cuándo y con qué traducción o aplicación. Centralizarlos mediante syslog/SIEM facilita correlacionar eventos con DNS, autenticación y cambios.
Evita registrar cada paquete de alto volumen sin estrategia: puede saturar almacenamiento o CPU. Define niveles y retención según valor operativo. Revisa SNMP y Syslog para la capa de observabilidad.
Troubleshooting de políticas de firewall
Cuando una aplicación falla, identifica primero el flujo exacto: origen, destino, protocolo, puertos y dirección de inicio. Comprueba routing antes y después del firewall, la regla que hace match, estado de sesión y NAT. Si hay tráfico asimétrico, un firewall stateful puede ver sólo una mitad y descartarla.
- Busca el rule ID que toma la decisión.
- Comprueba contadores y logs de deny/allow.
- Valida objetos y resolución DNS si la política usa nombres.
- Confirma ruta de retorno y simetría cuando sea requerida.
- Captura en ambas interfaces para distinguir entrada, decisión y salida.
Ejemplo de política: usuarios, DNS y aplicación interna
Supón que una VLAN de usuarios sólo debe consultar los resolvers corporativos y acceder por HTTPS a una aplicación interna. La política puede permitir UDP/TCP 53 únicamente hacia los DNS autorizados, HTTPS hacia el frontend concreto y bloquear el resto de accesos al segmento de servidores. Los logs de cada regla permiten comprobar si una incidencia es DNS, reachability o aplicación. Este modelo es más mantenible que permitir toda la red de usuarios hacia toda la red de servidores y confiar en que cada host se proteja solo.