6. Firewalls, ACL y políticas de filtrado de tráfico

6.1 Introducción

Después de definir zonas de confianza y criterios de segmentación, surge una pregunta práctica: ¿cómo se hace cumplir esa separación? La respuesta está en los mecanismos de filtrado. Un diseño de red seguro no depende solo del diagrama arquitectónico; necesita controles que permitan o bloqueen tráfico de forma coherente con las reglas del negocio y del riesgo.

Los firewalls y las ACL cumplen justamente ese rol. No son sinónimos, aunque a veces se combinan. Ambos sirven para controlar comunicaciones, pero operan con distinto nivel de profundidad, contexto y flexibilidad.

En este tema veremos qué hace cada uno, cómo se construyen políticas de filtrado sólidas y cuáles son los errores que suelen volver inefectivo un control que en apariencia estaba bien implementado.

6.2 Qué es una ACL

Una ACL, o Access Control List, es una lista de reglas que permite o deniega tráfico según criterios concretos. Dependiendo del dispositivo y la capa, esos criterios pueden incluir dirección IP de origen, dirección IP de destino, protocolo, puerto o interfaz.

Las ACL suelen utilizarse en routers, switches de capa 3, firewalls y otros equipos de red para establecer decisiones rápidas de filtrado.

Su lógica general es simple:

• Se evalúa el tráfico contra una secuencia ordenada de reglas.
• Cuando una regla coincide, se aplica la acción correspondiente.
• Si no coincide ninguna regla, normalmente se aplica una política implícita final.

6.3 Qué es un firewall

Un firewall es un sistema de control de tráfico que aplica políticas entre redes, zonas o contextos distintos. A diferencia de una ACL básica, un firewall puede incorporar mayor conocimiento sobre el estado de la conexión, el tipo de aplicación, el usuario, la sesión, el contenido o la identidad del entorno.

Su función principal es actuar como punto de control entre segmentos con distintos niveles de confianza, por ejemplo:

• Entre internet y la red interna.
• Entre una DMZ y servidores internos.
• Entre la red de usuarios y la red administrativa.
• Entre cargas de trabajo dentro de un datacenter o nube.

6.4 Diferencias entre ACL y firewall

En muchas arquitecturas se usan ambos: ACL para controles de red más cercanos al enrutamiento y firewalls para políticas más ricas entre dominios.

6.5 Tipos de firewalls

Existen distintos enfoques de firewall según el nivel de análisis y capacidades disponibles.

• Packet filtering: filtra en función de campos básicos del paquete.
• Stateful firewall: tiene en cuenta el estado de las conexiones y distingue mejor entre tráfico legítimo de respuesta y tráfico no solicitado.
• Proxy o application firewall: intermedia la comunicación y puede analizar protocolos de aplicación.
• Next-Generation Firewall: incorpora inspección más profunda, visibilidad por aplicación, integración con identidad y capacidades de detección adicionales.
• Host firewall: corre en un sistema final y controla tráfico entrante o saliente a nivel del propio equipo.

6.6 El principio base: deny by default

Una política madura de filtrado parte del principio de negar por defecto y permitir solo lo necesario. Esto significa que, salvo que exista una justificación explícita, el tráfico no debe circular libremente entre zonas.

Este enfoque tiene varias ventajas:

• Reduce la exposición accidental.
• Obliga a comprender qué flujos realmente se necesitan.
• Evita el crecimiento caótico de excepciones amplias.
• Facilita revisión y auditoría.

Su dificultad es operativa: exige conocer bien la aplicación, sus dependencias y el comportamiento esperado del negocio.

6.7 Cómo construir una política de filtrado

Una buena política no empieza escribiendo reglas. Empieza entendiendo flujos.

1. Identificar origen, destino y propósito del tráfico.
2. Determinar si el flujo es realmente necesario.
3. Limitar protocolo, puerto y dirección a lo mínimo indispensable.
4. Asignar la regla a la zona, interfaz o contexto correcto.
5. Definir logging apropiado para revisión y trazabilidad.
6. Documentar dueño, razón y fecha de revisión.

Las reglas deberían reflejar necesidades concretas del negocio, no comodidades genéricas del tipo "permitir todo temporalmente".

6.8 Campos habituales en una regla

6.9 El problema del orden de reglas

En listas evaluadas secuencialmente, el orden de las reglas es determinante. Una regla general ubicada antes que una regla específica puede abrir más de lo previsto. Una denegación demasiado amplia puede bloquear servicios legítimos sin que resulte evidente a primera vista.

Por eso conviene:

• Colocar reglas más específicas antes que reglas amplias.
• Agrupar por contexto o zona para facilitar lectura.
• Evitar redundancias y solapamientos innecesarios.
• Revisar el impacto de cambios sobre reglas existentes.

6.10 Filtrado de entrada, salida y lateral

Una política madura no solo controla lo que entra desde internet. También debe considerar tráfico saliente y tráfico lateral entre segmentos internos.

• Entrada: protege frente a acceso no solicitado desde entornos menos confiables.
• Salida: limita exfiltración, conexiones no autorizadas y abuso de canales externos.
• Lateral: controla movimiento entre zonas internas, clave para contención de incidentes.

Ignorar cualquiera de estos tres planos deja huecos importantes. Por ejemplo, una red puede estar bien protegida hacia afuera y aun así permitir libre movimiento interno o conexiones salientes peligrosas.

6.11 Firewalls entre zonas de confianza

Los firewalls son especialmente valiosos cuando se ubican entre dominios con niveles distintos de riesgo. Allí pueden aplicar políticas adaptadas al contexto.

Ejemplos típicos:

• Internet hacia DMZ: permitir solo servicios publicados y monitoreados.
• DMZ hacia red interna: restringir al mínimo indispensable.
• Usuarios hacia servidores: permitir solo aplicaciones necesarias.
• Usuarios hacia administración: idealmente denegar por completo.
• Servidores hacia internet: limitar actualizaciones, APIs o destinos justificados.

6.12 Logging, trazabilidad y revisión

Una política de filtrado no solo debe decidir; también debe dejar evidencia útil. Los registros son esenciales para auditoría, troubleshooting, detección de anomalías y respuesta a incidentes.

Sin embargo, registrar todo sin criterio puede ser tan problemático como no registrar nada. Lo importante es encontrar equilibrio entre visibilidad y volumen.

Suele ser útil registrar:

• Denegaciones relevantes entre zonas sensibles.
• Intentos de acceso administrativo.
• Cambios de política y quién los realizó.
• Flujos poco habituales o que coinciden con reglas críticas.

6.13 Reglas temporales y deuda operativa

En muchos entornos las políticas se degradan no por mala intención, sino por acumulación de excepciones temporales que nunca se revisan. Una apertura hecha "por unas horas" termina viva meses o años después, sin dueño claro ni justificación vigente.

Este problema genera deuda operativa y exposición oculta. Para evitarlo conviene:

• Etiquetar reglas temporales con fecha de expiración.
• Asignar responsable a cada excepción.
• Revisar periódicamente reglas antiguas.
• Eliminar permisos que ya no responden a una necesidad activa.

6.14 Errores frecuentes en ACL y firewalls

• Permitir rangos demasiado amplios por comodidad.
• Usar reglas any-any entre zonas sensibles.
• No diferenciar tráfico de usuarios, servidores y administración.
• Olvidar controlar tráfico saliente.
• Dejar puertos o servicios abiertos sin necesidad actual.
• No documentar la razón de una regla.
• Modificar políticas en incidentes sin revisar luego el impacto residual.

6.15 Filtrado y continuidad operativa

El filtrado no debe pensarse solo como un mecanismo de bloqueo. También ayuda a sostener continuidad. Una regla bien definida puede contener un incidente, aislar un comportamiento anómalo o reducir el impacto de un servicio comprometido sin necesidad de apagar toda una red.

Para que eso funcione, las políticas deben ser comprensibles y mantenibles. Un conjunto de reglas caótico vuelve más difícil actuar con rapidez ante una contingencia.

6.16 Relación con otros controles

Los firewalls y ACL no trabajan solos. Su eficacia depende de estar alineados con arquitectura, segmentación, identidad, monitoreo y endurecimiento.

6.17 Cómo evaluar si una política está madura

Una política de filtrado madura suele mostrar estas características:

• Reglas alineadas con zonas de confianza definidas.
• Documentación clara sobre propósito y responsables.
• Mínimo privilegio aplicado a flujos de red.
• Revisión periódica y eliminación de deuda histórica.
• Logging útil sin exceso de ruido.
• Capacidad de modificar reglas de forma controlada ante incidentes o cambios.

6.18 Qué debes recordar de este tema

• Las ACL y los firewalls convierten la segmentación en controles efectivos sobre el tráfico.
• Una buena política parte de negar por defecto y permitir solo lo necesario.
• El orden, la especificidad y la documentación de las reglas importan tanto como la regla misma.
• Hay que controlar tráfico de entrada, salida y lateral, no solo el perímetro.
• Las excepciones temporales no revisadas son una fuente frecuente de exposición oculta.

6.19 Conclusión

Firewalls, ACL y políticas de filtrado son piezas centrales de la seguridad en redes porque hacen visible una decisión fundamental: qué comunicaciones son aceptables y cuáles no. Bien diseñados, reducen exposición, facilitan la contención y ordenan la operación. Mal gobernados, se convierten en un conjunto opaco de excepciones que ya nadie entiende.

En el próximo tema estudiaremos NAT, proxy, DMZ y control del perímetro, que amplían este enfoque de control sobre cómo la red se relaciona con entornos externos.