Tema 7
Las políticas de firewall se vuelven efectivas mediante reglas concretas. Para que esas reglas protejan sin romper la operación, deben ser precisas, ordenadas, documentadas y revisadas de forma periódica.
En el tema anterior vimos cómo diseñar políticas de firewall. Ahora veremos cómo esas políticas se convierten en reglas y listas de control de acceso. Esta parte es muy práctica: una política puede estar bien pensada, pero si se implementa con reglas demasiado amplias o mal ordenadas, la defensa se debilita.
Las reglas son instrucciones que indican al firewall qué hacer cuando un tráfico coincide con ciertas condiciones. Pueden permitir, bloquear, registrar, inspeccionar o aplicar perfiles de seguridad.
El objetivo de este tema es que puedas leer una regla, entender su impacto, detectar problemas comunes y aplicar buenas prácticas para mantener un conjunto de reglas ordenado.
Una regla de firewall define una condición y una acción. Si el tráfico coincide con los criterios de la regla, el firewall aplica la acción configurada.
Una regla típica incluye:
Una ACL significa Access Control List, o lista de control de acceso. Es un conjunto de reglas que permite o deniega tráfico según condiciones definidas.
Las ACL pueden existir en routers, switches, firewalls, sistemas operativos, servicios cloud y otras plataformas. Su complejidad varía: algunas solo filtran por IP y puerto, mientras que otras pueden considerar estado, aplicación, usuario o contexto.
Ejemplo conceptual de ACL:
En muchos firewalls y ACL, las reglas se evalúan de arriba hacia abajo. Cuando el tráfico coincide con una regla, se aplica esa acción y no se siguen evaluando reglas posteriores.
Esto significa que el orden puede cambiar por completo el resultado. Una regla amplia al principio puede dejar sin efecto reglas más específicas ubicadas debajo.
| Orden | Regla | Problema |
|---|---|---|
| 1 | Permitir red de usuarios hacia servidores por cualquier puerto. | Demasiado amplia. Puede permitir tráfico que luego se quería bloquear. |
| 2 | Bloquear usuarios hacia servidores por RDP. | Quizá nunca se aplique porque la regla anterior ya permitió el tráfico. |
Una práctica común es ubicar reglas más específicas antes que reglas generales. Así se evitan coincidencias prematuras que permitan o bloqueen tráfico de forma incorrecta.
Ejemplo más seguro:
La idea no es memorizar un orden universal. La idea es entender que cada regla debe ubicarse donde tenga efecto real.
Las acciones más comunes son permitir, bloquear y rechazar. Aunque parezcan similares, tienen diferencias operativas.
| Acción | Qué hace | Uso común |
|---|---|---|
| Permitir | Autoriza el tráfico que coincide con la regla. | Comunicación necesaria y aprobada. |
| Bloquear o descartar | Elimina el tráfico sin responder al origen. | Tráfico no autorizado o potencialmente hostil. |
| Rechazar | Niega el tráfico y responde al origen. | Casos donde conviene informar que el acceso no está permitido. |
| Registrar | Guarda evidencia del evento. | Monitoreo, auditoría e investigación. |
| Inspeccionar | Aplica perfiles adicionales como IPS, antivirus o control de aplicación. | Tráfico permitido que requiere análisis extra. |
Los objetos son nombres reutilizables que representan direcciones IP, redes, servicios, puertos, usuarios, aplicaciones o grupos. Ayudan a que las reglas sean más legibles y fáciles de mantener.
En lugar de escribir una IP en muchas reglas, se crea un objeto llamado, por ejemplo, SRV-DB-Clientes. Si la IP cambia, se actualiza el objeto y no cada regla individual.
Tipos comunes de objetos:
Los grupos permiten reunir varios objetos para simplificar reglas. Por ejemplo, un grupo llamado SRV-Web-Produccion puede contener varios servidores web.
Son útiles, pero deben usarse con cuidado. Si un grupo crece sin control, una regla que parecía precisa puede terminar permitiendo acceso a muchos activos.
La nomenclatura es parte de la seguridad operativa. Un objeto llamado Server1 o Test aporta poco. Un nombre como SRV-CRM-APP-PROD comunica función, sistema y ambiente.
Un esquema útil puede incluir:
Lo importante no es usar exactamente esas siglas, sino mantener consistencia.
Una política defensiva suele terminar con una regla final de bloqueo. Esta regla captura todo tráfico que no coincidió con permisos anteriores.
Sin una regla final clara, algunos dispositivos pueden aplicar comportamientos por defecto que no siempre son evidentes. Además, registrar esta regla ayuda a descubrir tráfico no documentado, escaneos, errores de configuración o intentos de acceso no autorizados.
Una regla final típica:
Una regla demasiado amplia permite más tráfico del necesario. A veces se crea para resolver rápido un problema, pero queda instalada como deuda de seguridad.
| Regla problemática | Riesgo | Mejora |
|---|---|---|
| Any hacia servidor por any | Expone todos los servicios del servidor. | Definir origen y puertos específicos. |
| Usuarios hacia servidores por any | Facilita movimiento lateral. | Permitir solo aplicaciones necesarias. |
| DMZ hacia red interna por any | Alto impacto si se compromete la DMZ. | Permitir solo flujos puntuales. |
| Internet hacia administración | Exposición directa de interfaces críticas. | Usar VPN, bastión y MFA. |
Una regla duplicada repite el efecto de otra. Una regla solapada cubre parcialmente el mismo tráfico. Ambas complican el análisis y pueden ocultar errores.
Ejemplo de solapamiento:
La segunda regla puede ser innecesaria si la primera ya cubre ese origen. O la primera puede ser demasiado amplia si solo se necesitaba permitir la subred 10.10.20.0/24.
Una regla sombra es una regla que nunca se aplica porque otra regla anterior captura el tráfico antes. Esto ocurre mucho cuando reglas generales están por encima de reglas específicas.
Las reglas sombra generan una falsa sensación de control. En la consola parece existir un bloqueo o permiso, pero en la práctica el tráfico se decide antes.
Para detectarlas conviene revisar:
Muchos firewalls muestran contadores de uso por regla. Estos contadores indican cuántas veces una regla coincidió con tráfico.
Son útiles para detectar reglas sin uso, reglas muy activas, reglas sombra o reglas que reciben tráfico inesperado. Sin embargo, deben interpretarse con cuidado: una regla sin uso durante una semana quizá sea necesaria para un proceso mensual.
Buenas preguntas para revisar contadores:
Muchas políticas se concentran en bloquear tráfico entrante desde internet, pero el filtrado de salida también es importante. Un equipo comprometido puede intentar comunicarse con servidores de comando y control, descargar herramientas o exfiltrar datos.
Buenas prácticas de filtrado de salida:
El filtrado lateral controla comunicaciones entre segmentos internos. Es clave para reducir movimiento lateral después de un compromiso.
Ejemplos de filtrado lateral:
Supongamos una organización con usuarios, DMZ, servidores internos y red de administración. Un orden razonable podría ser:
| Orden | Regla | Motivo |
|---|---|---|
| 1 | Permitir administración desde bastión hacia servidores por SSH/RDP. | Acceso privilegiado controlado. |
| 2 | Permitir internet hacia reverse proxy en DMZ por HTTPS. | Publicación web controlada. |
| 3 | Permitir aplicación en DMZ hacia base de datos interna por puerto específico. | Flujo necesario de aplicación. |
| 4 | Bloquear DMZ hacia red interna por cualquier otro servicio. | Contención si se compromete la DMZ. |
| 5 | Bloquear usuarios hacia puertos administrativos de servidores. | Reducir movimiento lateral. |
| 6 | Bloquear todo lo no permitido. | Cierre por defecto. |
Las reglas envejecen. Cambian aplicaciones, servidores, responsables, direcciones IP, necesidades de negocio y niveles de riesgo. Una regla correcta hoy puede ser innecesaria o peligrosa dentro de seis meses.
Una revisión periódica debería buscar:
El filtrado efectivo depende tanto del contenido de las reglas como de su orden, alcance y mantenimiento. Una regla precisa, bien ubicada y documentada puede reducir riesgo; una regla amplia o mal ordenada puede crear una falsa sensación de seguridad.
En el próximo tema estudiaremos NAT, PAT, port forwarding, publicación segura de servicios y exposición controlada. Allí veremos cómo se modifican direcciones y puertos para publicar o conectar servicios sin abrir más de lo necesario.