Qué es una ACL
Una Access Control List es un conjunto ordenado de reglas que clasifica tráfico y aplica una acción, normalmente permitir o denegar. Dependiendo de la plataforma puede usarse para filtrado, control de gestión, clasificación QoS u otras funciones.
La idea central es simple; la dificultad está en expresar el requisito sin bloquear tráfico legítimo ni crear huecos demasiado amplios.
Qué puede comparar una regla
Las ACL de red suelen poder comparar origen, destino, protocolo y, en reglas extendidas, puertos TCP/UDP u otros campos. La terminología exacta depende del fabricante. En Cisco IOS, por ejemplo, se habla tradicionalmente de ACL estándar y extendidas.
En IPv6 cambian campos y sintaxis según plataforma, pero el principio sigue siendo clasificar tráfico por cabeceras y aplicar una política.
Orden y primera coincidencia
En muchas implementaciones las reglas se evalúan en orden y la primera coincidencia determina la acción. Por eso colocar una regla general antes que una específica puede hacer que la específica nunca se use.
El comportamiento al final de la lista debe verificarse en cada plataforma. En Cisco IOS, las ACL clásicas incorporan un implicit deny al final, de modo que el tráfico no permitido explícitamente queda descartado.
Entrada, salida y punto de aplicación
Una ACL aplicada inbound se evalúa cuando el tráfico entra en una interfaz; outbound, cuando va a salir. No basta con escribir una regla correcta: debes colocarla donde realmente atraviese el flujo.
Antes de aplicar una ACL, dibuja origen → camino → destino. Identifica interfaces, dirección y posibles caminos alternativos. Esto reduce errores especialmente en redes con routing dinámico o múltiples salidas.
ACL estándar y extendida
En plataformas que distinguen ambos tipos, una ACL estándar suele clasificar principalmente por origen, mientras una extendida puede incluir destino, protocolo y puertos. Esta distinción es propia de familias de productos y no debe asumirse como universal.
La regla de diseño es usar la mínima amplitud necesaria. Si el requisito es permitir HTTPS de una subred a un servidor, una regla que permita todo IP entre ambos es más amplia de lo necesario.
Wildcard masks y prefijos
Algunas ACL de Cisco usan wildcard masks para expresar conjuntos IPv4. Una wildcard no es una máscara de subred: un bit 0 significa «debe coincidir» y un bit 1 «se ignora». Otras plataformas usan notación CIDR directamente.
Conviene calcular y revisar estos rangos con cuidado. Un error en un bit puede ampliar el alcance mucho más de lo esperado.
ACL stateless vs firewall stateful
Una ACL clásica suele ser stateless: evalúa cada paquete según sus campos, sin mantener necesariamente el estado completo de una conexión. Un firewall stateful mantiene información de sesiones y puede permitir automáticamente tráfico de retorno asociado.
Por eso una ACL y un firewall no son intercambiables aunque ambos filtren. Al diagnosticar, identifica qué dispositivo y qué modelo de estado intervienen.
Diseñar desde requisitos
Escribe primero el requisito en lenguaje humano: «usuarios de VLAN 20 pueden consultar DNS interno y acceder por HTTPS al servidor X; no pueden administrar switches». Después tradúcelo a flujos concretos y sólo al final a sintaxis.
Documenta propietario, motivo y caducidad de excepciones. Las reglas sin contexto son difíciles de revisar y tienden a permanecer incluso cuando ya no son necesarias.
Validación y contadores
Después de aplicar, prueba casos permitidos y denegados. Revisa contadores por regla y logs cuando estén habilitados. Un contador en cero puede indicar que el flujo no pasa por esa ACL o que una regla anterior ya lo captura.
No uses logging indiscriminado en reglas de gran volumen sin comprender el impacto. Ajusta la observabilidad al equipo y necesidad.
Troubleshooting de ACL
Si un servicio falla tras un cambio, confirma primero conectividad y ruta. Luego identifica la ACL exacta, interfaz/dirección y regla que debería coincidir. Compara direcciones y puertos reales con lo que creías que usaría la aplicación.
Capturas y contadores ayudan a probar dónde desaparece el flujo. Sigue el método de troubleshooting en vez de retirar toda la ACL como primera prueba.
ACL e IPv6
IPv6 no elimina la necesidad de filtrado. Además del tráfico de aplicación, algunos mensajes ICMPv6 son esenciales para Neighbor Discovery y funciones de la red. Bloquear ICMPv6 de forma indiscriminada puede romper conectividad y Path MTU Discovery.
Diseña políticas IPv6 entendiendo los protocolos necesarios y prueba explícitamente dual-stack.
Errores frecuentes
Errores típicos: invertir origen/destino, aplicar en la interfaz o dirección equivocada, olvidar tráfico de retorno en diseños stateless, colocar una regla genérica antes de una específica, confundir wildcard con máscara de subred y no considerar NAT antes/después del punto de filtrado.
Cuando existe NAT/PAT, verifica qué dirección ve realmente el motor de políticas en ese punto concreto.
Siguiente paso
Después de dominar ACL, estudia VPN/IPsec y seguridad de Capa 2. Vuelve a seguridad de red para encajar el filtrado dentro de una estrategia más amplia.
Ejemplo conceptual de diseño
Supón una VLAN de usuarios que debe consultar dos resolvers internos y acceder por HTTPS a una aplicación, pero no administrar la red. El diseño lógico sería permitir DNS hacia los resolvers, permitir TCP/443 hacia la aplicación y negar acceso a los rangos de gestión, conservando sólo otros flujos explícitamente justificados.
Antes de traducirlo a sintaxis, confirma direcciones reales, si existe NAT y dónde se aplicará la política. Después valida con pruebas positivas y negativas. Este método evita que una regla demasiado amplia sea la solución rápida a un requisito que nunca se escribió con precisión.
Cambios seguros y rollback
Una ACL puede cortar tu propia sesión de administración. En equipos remotos prepara un mecanismo de rollback, una vía de gestión alternativa o una ventana controlada. Aplica cambios pequeños y comprueba contadores inmediatamente.
En plataformas que admiten secuencias o edición atómica, aprovéchalas para reducir el riesgo de reconstruir listas completas. Guarda la configuración anterior y documenta qué regla nueva corresponde a qué necesidad de negocio.
Documentar y revisar una ACL
Una ACL mantenible necesita nombres, comentarios o documentación externa que explique cada bloque. Agrupa reglas por servicio o zona cuando la plataforma lo permita y revisa periódicamente entradas sin hits, objetos obsoletos y excepciones temporales.
Los contadores ayudan a decidir qué investigar, pero una regla con cero coincidencias no debe borrarse automáticamente: quizá protege un flujo de contingencia raro. La revisión combina telemetría con el requisito original y con pruebas documentadas de los servicios que dependen de esa política.