¿Cómo funcionan las ACL en Cisco? I: Conceptos
Introducción
Antes que nada, y en caso de que algún lector no sepa (o no recuerde) qué significa ACL, éste es una sigla que traduce lista de control de acceso -Access Control Lists en inglés- y es un método popular en redes para controlar qué nodos de la red tienen qué permisos sobre el sistema que implementa las ACLs. En Cisco, las ACLs son un mecanismo genérico para clasificar conjuntos de direcciones o flujos de datos, en éso yo siempre hago mucho énfasis, porque las ACLs en CCNA se ven como un mecanismo de seguridad, pero se dan visos de lo que realmente son: un mecanismo para clasificar direcciones y flujos de datos.
Un sistema de red, como Squid por ejemplo, es un sistema que hace algo con el tráfico que entra y sale de él. Las ACLs interceptan el tráfico y, para cada paquete, se comparan sus valores particulares con valores predefinidos por el administrador en la Lista y, con base en ese condicionamiento, se le aplica a los paquetes alguna acción según lo que quiera el administrador que suceda.
La dinámica compleja de las ACLs es el hecho de imaginar un sólo paquete y llevarlo a una secuencia de paquetes mezclada. El hecho es que cuando en una ACL especificamos los valores que queremos comparar, realmente estamos aplicando eso a cada paquete dentro de un flujo particular de paquetes, así para diseñarla nos imaginemos sólo un paquete.
¿Para qué sirven las ACLs en Cisco?
En el currículo de CCNA, las ACLs se usan para aplicar una política de seguridad que permite o niega el acceso de cierta parte de la red a otra. La granularidad de las ACLs permite que estas partes sean o bien PC específicos o partes de una subred arbitrariamente, es decir, permite que se conceda o niegue el acceso desde un único PC hasta otro, de un segmento de red a otro o cualquier combinación que se quiera.
En Cisco en general, las ACLs sirven para clasificar conjuntos de direcciones, por ejemplo una subred o una parte de una subred. Pero más allá de eso la palabra importante es arbitrariamente, porque las reglas de ACLs permiten cosas tan particulares como seleccionar los PCs que tengan direcciones IP con el último octeto en número impar (sin importar a qué subredes pertenecen). Ésta característica hace que Cisco utilice ACLs en cualquier parte en la que se deba especificar un conjunto de direcciones o un flujo de datos, por ejemplo, en NAT se especifican las direcciones privadas o internas creando una ACL que permite las direcciones a traducir. Si se quiere filtrar o alterar la forma en que un protocolo de enrutamiento arma sus actualizaciones se usan listas de acceso (route-map) , si se quiere alterar la forma en que trabaja la tabla de enrutamiento se usan listas de acceso (policy-based routing), si se quiere especificar qué direcciones pasan por una VPN se usan ACLs, etc. (IPSec). Como se ve, las ACLs son mucho más que un mecanismo de seguridad y por eso es un tema muy importante si se quiere hacer carrera en las certificaciones de Cisco o tener un buen desempeño en enrutamiento y conmutación Cisco.
¿Cómo es una ACL?
Las ACLs, como ya comenté, son la especificación de una acción a realizar sobre paquetes que cumplan ciertas condiciones. Una ACL es un conjunto de reglas identificadas con un número o un nombre y cada regla especifica una acción y una condición, las acciones a aplicar son permitir o denegar todos los paquetes que cumplan la condición asociada a la regla. Una ACL se identifica con un número o un nombre y todas las reglas que tengan el mismo número/nombre hacen parte de la ACL, éstos identificadores suelen indicar también qué tanta expresividad tendrá la ACL, es decir, qué tan específicas pueden ser las reglas.
Un ejemplo de cómo es conceptualmente una ACL es así
Lista-de-acceso X ACCION1 CONDICION1
Lista-de-acceso X ACCION2 CONDICION2
Lista-de-acceso X ACCION3 CONDICION3
La X es el nombre o número que identifica la ACL, por lo tanto todas las reglas anteriores componen la ACL X, una sola ACL. Si cierto paquete cumple la condición1 se le aplica la Acción1, si un paquete cumple la condición 2 se le aplica la acción 2 y así sucesivamente. Las acciones son sólo permitir o denegar y las condiciones dependen del tipo de ACL, las más simples, las estándar especifican valores para comparar con la dirección IP origen de cada paquete, en las más expresivas, llamadas extendidas, las condiciones permiten especificar valores para comparar tanto con la dirección IP origen como con la IP destino e incluso protocolos de capa 4 y parámetros de capa 4 como puertos y banderas de la conexión TCP.
La lógica de funcionamiento de las ACLs es que una vez que se cumpla una condición, se aplica su acción correspondiente y no se examinan más reglas de la ACL. Ésto para disminuír la cantidad de procesamiento del enrutador, pero también tiene una consecuencia, si una regla abarca un conjunto de direcciones y otra un subconjunto del primero, la regla de subconjunto debe estar antes de la regla del conjunto completo. Por ejemplo, si yo especifico en una regla denegar el acceso a un host de cierta subred y en otra permitir toda la subred, la ACL diría permita el acceso a todos los hosts de la subred X menos al host Y. Si la ACL se escribe con la regla de la subred antes que la regla del host, la ACL permitiría incluso al host, porque la regla de host cumpliría también la regla de la subred y la regla del host nunca se examinaría. En otras palabras, las reglas más específicas deben estar al principio de la ACL para evitar que las reglas genererales se apliquen siempre y nunca se examinen las específicas. Finalmente todas las ACLs terminan, implícitamente, con una regla No permitir nada más.
Condición = ValorDeReferencia BitsAComparar, donde ValorDeReferencia tiene el formato de dirección IP y BitsAComparar es una máscara wildcard.
La condición entonces es un valor que el administrador va a escribir arbitrariamente con el fin de aplicar la acción a los paquetes que la cumplan. La condición en ACLs estándar consiste en una dirección de referencia y una máscara wildcard que indica qué bits de la dirección origen de los paquetes comparar con la dirección de referencia que indicó el administrador. Por ejemplo: si yo en mi red tengo una subred de dirección 192.168.1.0/26, para indicar el tráfico que provenga de todos los hosts de esa subred se escribiría la condición 192.168.1.0 0.0.0.63, la dirección es una dirección de referencia y no se puede entender sin la wildcard porque ésta dice qué bits se van a comparar. Cada bit en cero en la WC hace comparar el bit correspondiente en la dir. IP origen de los paquetes interceptados con la dirección de referencia escrita por el administrador.
Si yo quisiera aplicar una acción sólo a los hosts de dirección impar de esta misma subred escribiría la condición 192.168.1.1 0.0.0.62, note que traduciendo el último octeto de la WC a binario 62 = 01111110, el cero al final le indica al enrutador que compare el último bit de la dirección de referencia con el último bit de cada paquete interceptado, por lo tanto, como sabemos que todo número impar en binario tiene que tener el último bit en 1, la condición se cumple para cada paquete que tenga los primeros 3 octetos y el último bit iguales a la dirección de referencia, es decir, toda dirección IP de la forma 192.168.1.[impar], con el último octeto en binario así 0 X X X X X X 1, donde X es un bit cualquiera, porque un 1 en la WC significa no comparar el bit con la dirección de referencia. Si no lo comprende, traduzca los números impares menores que 63 a binario y verá el patrón. Por ejemplo 9 = 00001001, una dirección 192.168.1.9 cumple la condición pero 192.168.1.8 no la cumple, porque 8 = 00001000 y el último bit no es 1, no todos los bits de la dirección IP origen de éste paquete particular coinciden con la dirección de referencia, el último no coincide. Note también que si yo pusiera una condición 0.0.0.1 255.255.255.254, eso significaría que sin importar la red de la que provenga el paquete (la WC indica no comparar los primeros 31 bits, o en otras palabras, no importa qué tenga ni la dirección de referencia ni la dirección origen de los paquetes en los primeros 31 bits), la acción se aplicaría a los paquetes cuyo origen sea una dirección impar (las que tienen el último bit en 1). ¿Será que con eso puede usted deducir qué condición se aplicaría a los paquetes que provengan de direcciones IP con el último octeto en valor par? (Por favor no lo deje en un comentario).
¿Cómo aplicar las ACL?
Finalmente, dado que entendemos la lógica fundamental de las ACLs, debemos mirar un último aspecto conceptual: ¿cómo se aplican?. La idea es que el tráfico de red circula en dos sentidos y en ambos sentidos los patrones de dirección IP origen y destino se intercambian, por lo tanto y como las ACLs se aplican a una interfaz en particular, es necesario tener en cuenta en qué sentido se aplica, porque en un sentido las reglas aplican y en otro sentido no aplicarán porque las direcciones origen no serán las mimas. Es decir, si dos PCs están transfiriendo un archivo, hay dos flujos de datos, uno del PC1 al PC2 en el que la dirección IP origen de todos los paquetes en ese sentido tienen la dirección Ip del PC1 pero el tráfico de retorno tendrá como dirección IP origen la del PC2. Lo anterior nos indica que si diseñamos una ACL que en una de sus reglas aplica una acción a la dirección del PC1, hay que aplicarla en una interfaz en el sentido en el que ese flujo de datos provenga del PC1. El sentido del flujo se entiende como de entrada o salida del enrutador por la interfaz, es decir, si el tráfico sale del enrutador por la interfaz específica o el tráfico entra al enrutador por esa interfaz.
Supongamos que el PC1 tiene la dirección 172.17.20.20/24, el PC2 tiene la dirección 192.168.200.200/24 y nuestro enrutador es el Gateway del PC1 por la interfaz Fastethernet 0/0. Si el flujo de datos hacia el PC2, sale por una interfaz serial digamos la serial 0/0, ¿en qué interfaz y en qué sentido los paquetes de este flujo tienen como dirección IP origen la dirección IP del PC1? Si la ACL va a ser aplicada en la Fa 0/0, el flujo de datos de PC1 a PC2 entrando a Fa 0/0 tiene como dirección origen PC1, en la dirección de salida el origen es PC2 y la regla no aplicaría. En la interfaz serial, el flujo de datos entrante tendría como origen PC2 y de salida tendría como origen PC1. Dado lo anterior, si yo diseño una ACL con una regla que diga permitir 172.17.20.20 0.0.0.0, ésta regla sólo encontraría paquetes coincidentes en la interfaz fa 0/0 si la aplico de entrada y en la interfaz serial 0/0 si la aplico de salida.
