Cómo funcionan las acl en cisco

¿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


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 =
00111110, 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.

¿Cómo funcionan las ACLs? II: ACLs estándar

¿Qué son ACLs?

Las ACLs son un mecanismo que usan diversos dispositivos y aplicaciones para filtrar o clasificar el
tráfico que interceptan. En Cisco las ACLs se usan en muchos contextos, en CCNA se usan como
mecanismo de seguridad para filtrar selectivamente tráfico que cruza por el enrutador.

Una ACL es un conjunto de reglas contra las que se compara cada paquete que cruce una interfaz
en la que se instaló la lista de acceso. Cada paquete se compara contra las reglas una por una
empezando por la primera y continuando con las siguientes. Sólo si el paquete no corresponde a lo
que indica una regla se continúa con las siguientes, una vez que el paquete se corresponde con
una de las reglas de la ACL, se le aplica la acción asociada a la regla y no se compara el paquete con
ninguna otra regla. Las ACLs entonces son reglas, una por línea, que se identifican con un número
o una palabra y que identifican flujos de datos o conjuntos de direcciones. Cada regla hace uso de
una dirección de referencia y una máscara wildcard que condicionan la acción a ejecutar sobre un
paquete en cuestión. La condición consiste en que los paquetes coincidan con la dirección de
referencia en los bits que la máscara wildcard tenga en cero, por lo tanto si una wildcard es 0.0.0.0
significa que todos los bits de la dirección origen o destino de un paquete que cruce la interfaz por
la que está instalada la ACL se comparará bit a bit con la dirección de referencia, de esa manera yo
especifico una dirección completa de host. La dificultad de diseñar e instalar ACLs radica en la
dificultad de concebir los patrones de tráfico como un conjunto de paquetes heterogéneos que
pasan por una interfaz en una dirección en particular.

¿Qué es una ACL estándar (Standard ACLs)?

Dentro de las ACL más comunes están las ACL estándar y las ACL extendidas, diferenciadas entre sí
por su granularidad: las extendidas permiten más detalles de filtrado, ambos tipos de listas se
pueden numerar o nombrar. Dentro de las menos comunes están las que CCNA Exploration llama
complejas: ligadas a rangos de tiempo, reflexivas y dinámicas. Las más simples en todo sentido son
las ACLs estándar, que permiten defnir tráfico con base en las direcciones IP de origen de los
paquetes que correspondan con las reglas de la ACL.

Las ACL estándar entonces especifican un sólo par dirección de referencia/wildcard contra el que
se comparan todos los paquetes que entren o salgan de la interfaz en la que se instale la ACL, en
otras palabras, una ACL estándar filtra tráfico con base en la dirección IP origen de los paquetes.
Estas ACL se crean en modo de configuración global con el comando access-list seguido de un
número de 1 a 99 o de 1300 a 1999, éstos rangos identifican que el tipo de ACL es estándar, otros
rangos identifican ACLs extendidas (100 a 199 y 2000 a 2699). Cada regla debe tener el mismo
número para pertenecer a la misma ACL, si el número cambia, la regla en particular pertenecerá a
otra ACL. Luego de Access-list <número> sigue la acción a ejecutar (permit o deny) y finalmente la
condición que deben cumplir los paquetes para aplicarles la acción o continuar examinando más
reglas. Las ACL estándar usan un sólo par dirección/wildcard para especificar la condición que
deben cumplir los paquetes para que se les aplique la acción permit o deny. La condición examina
la dirección IP origen de cada paquete y la compara con el par dirección/wildcard pero sólo en los
bits en los que la wildcard tenga ceros.

¿Cómo se configuran ACL estándar?

Los pasos generales para configurar ACLs son 3:

1. Crear la ACL en modo de configuración global
2. Aplicar la ACL en una interfaz indicando la dirección del tráfico al que se le va a aplicar

3. Verificar su funcionamiento

La creación de la ACL consiste en crear una secuencia de reglas con un mismo identificador, cuyo
orden filtre el tráfico según los objetivos. Cada regla tiene la forma access-list <n> [ permit | deny ]
<referencia1> <wildcard1>, donde n es el número que identifica la ACL (0 a 99 ó 1300 a 1999 para
ACLs estándar) y referenciaN/wildcardN son los pares con los que se compararán los paquetes
para aplicarles la acción . Entonces una ACL tiene la forma:

• access-list <n> permit <referencia1> <wildcard1>
• access-list <n> deny <referencia2> <wildcard2>

Como todas las reglas coinciden en el número (n), la ACL está compuesta por todas las reglas
listadas. Para simplificar, puse permit y deny pero en las reglas se puede elegir cualquiera de las
dos según los objetivos perseguidos. Todas las ACLs terminan implícitamente en una regla deny
any, es decir, al final de la lista, cualquier paquete que no haya correspondido con ninguna regla se
va a descartar por defecto.

Para aplicar una ACL, ésta ya debe estar creada. Las listas de acceso se aplican en una interfaz, por
lo tanto hay que ingresar en modo de interfaz y el comando tiene la forma ip access-group <n> [in
| out] donde n es el número común a todas las reglas de la ACL y las palabras in/out indican en qué
sentido se aplicarán las reglas y ésto tiene importantes implicaciones: el tráfico en una dirección
tiene ciertas direcciones IP origen pero en la otra dirección éstas mismas direcciones serán IP
destino.

• interface serial 0/0
• ip access-group <n> [in|out]

Finalmente verificar la ACL se hace con varios comandos, uno es show access-list, que muestra
todas las listas de acceso activas y cuántos paquetes han correspondido (match) con cada regla. El
comando que muestra si una interfaz tiene una ACL aplicada y en qué dirección es show ip
interface, este comando muestra mucha información, por la mitad de toda esa información dice
inbound ACL Outbound ACL.

• show access-list
• show ip interface serial 0/0

¿Qué consideraciones hay que tener para instalar ACLs?

Denegación por defecto y Log

La primera consideración importante es tener en cuenta siempre que las listas de acceso terminan
en denegación por defecto, por lo tanto, si una ACL sólo tiene reglas de denegación lo único que
logra es denegar TODO el tráfico. Una ACL debe tener siempre por lo menos una regla de permitir.
Algunos administradores prefieren poner una regla final, sea deny any o permit any de manera
explícita para poder ver con show access-list cuántos paquetes se han filtrado por la última regla o
mejor, cuántos paquetes no han correspondido con ninguna otra regla. Otros administradores
usan la lista de acceso para recolectar información sobre el tráfico de la red, combinando reglas
que terminan con la palabra log que hace que la ACL genere entradas de registro como si fueran
mensajes del sistema. Combinar reglas permit con log hace que la acl evidencie algún tráfico que
se necesita saber cómo se está comportando.

Orden de verificación: Reglas específicas y generales

Como cada regla se verifica en secuencia comenzando por la primera, si una regla es general, es
decir, abarca más direcciones o flujos de datos que otra, ésta regla debería ir después de las más
específicas. Para ilustrar ésto, observe el siguiente ejemplo: yo quiero bloquear un host de la red
192.168.1.0/24 pero permitir el resto de esta red, necesito dos reglas: permitir la red y denegar el
host, como la regla para la red es más general e incluye el host mismo, ponerla de primera va a
tener como efecto que nunca se mire la regla que dice denegar el host, porque siempre aplicará la
primera y no se verificarán más reglas, permitiendo al host transmitir información cuando el
objetivo era denegar precisamente ese host.

La regla se debería escribir de la siguiente manera:

• access-list 1 deny 192.168.1.1 0.0.0.0
• access-list 1 permit 192.168.1.0 0.0.0.255

La anterior ACL tiene como resultado, cuando se aplica a una interfaz, que sólo el tráfico
perteneciente a la red 192.168.1.0, excepto el host 192.168.1.1, puede salir por la interfaz en la
que se aplique. Lo anterior siempre y cuando, el tráfico tenga como orígenes éstas direcciones.

Tráfico con orígen en el enrutador

Finalmente, cierto tráfico proveniente del enrutador no pasa por las listas de acceso, por ejemplo,
el acceso a VTY (telnet/ssh) al enrutador no es examinado por las ACL, por lo tanto hay que poner
una regla especial para este tráfico. La regla se llama access-group <n> y debe ser ACL estándar.
Una regla de este tipo limita el acceso por telnet al enrutador sólo a los hosts que correspondan a
la lista especificada.

¿Cómo funcionan las ACLs? III: ACLs extendidas

Después de revisar los conceptos de las Listas de Control de Acceso (ACL) y las ACLs estándar, llegó
la hora de examinar el funcionamiento de las ACL extendidas y su configuración.

Características de las ACL estándar: poca granularidad

Antes de comentar las cualidades de las ACL extendidas (extended ACL) debemos recordar las ACL
estándar y ver qué diferencia funcionan tienen las extendidas respecto a las primeras, es decir,
para valorar los beneficios de las extendidas. La idea de las ACLs estándar es filtrar tráfico con
base en las direcciones origen de los paquetes que entran o salen de una interfaz, aquella en la
que se instala la ACL. Lo anterior implica un nivel básico de filtrado: direcciones IP origen de todos
los paquetes interceptados, para ilustrarlo con un ejemplo, digamos que deseamos filtrar el tráfico
proveniente de la red 192.168.1.0/26, pero que de esa red queremos permitir un host en
particular y las demás redes diferentes deberían pasar.

A éstas alturas tenemos muy claro que las ACLs son conjuntos de reglas con un identificador
común y que las reglas aplican una acción a los paquetes que cumplan una condición que, en el
caso de las ACL estándar, es que tengan la dirección origen coincidente con la dirección de
referencia. La ACL que filtra el tráfico como se solicita (bloquear 192.168.1.0/26, permitir un host
192.168.1.1 y permitir paquetes de cualquier otra subred) creamos la siguiente ACL:

• access-list 1 permit 192.168.1.1 0.0.0.0
• access-list 1 deny 192.168.1.0 0.0.0.63

• access-list 1 permit any

En efecto, cada vez que llegue un paquete se compararán las direcciones IP origen de cada uno
con cada una de las reglas de la lista de acceso, si el paquete corresponde con alguna, se aplica la
acción (permit o deny) y no se compara con ninguna otra regla. En este caso, la regla permite
primero el host, luego niega la red y finalmente permite cualquier otra cosa.

La acl descrita significa que todo el tráfico del host particular se va a permitir, no se puede
bloquear un tráfico específico que provenga del host, se deniega o se permite todo el tráfico y
sería deseable bloquear sólo una porció de su tráfico, algo de lo que hace éste host en caso de ser
necesario. Para la red también sucede lo mismo: si se pudiera bloquear sólo el tráfico que sale de
esa red a un destino específico sin bloquear todo el tráfico con origen en esta red sería mucho
mejor. Ese es el problema que resuelve la ACL extendida.

ACLs extendidas

A diferencia de lo que sucede con la ACL estándar, las extendidas permiten especificar hacia
dónde se dirige el tráfico y con ésta característica, yo puedo bloquear o permitir un tráfico mucho
más específico: sólo tráfico que proviene del host pero se dirige a una red en particular o a otro
host en particular o sólo el tráfico de una red que se dirige a otra red en particular. El truco se

logra con el hecho de permitir comparar las direcciones destino de los paquetes contra la acl, no
sólo las direcciones origen. Dentro de lo que hemos venido manejando, hablamos que una acl está
compuesta por un conjunto de reglas todas con el mismo identificador, que cada regla era una
línea compuesta por una acción y una condición que el paquete debe cumplir para aplicarle la
acción (permitir o denegar). Las condiciones en las acl estandar están compuestas por una
dirección de referencia y una wildcard que dice qué bits de la dirección origen de los paquetes se
deben comparar con la dirección de referencia, en las acls extendidas se especifica dos pares de
direcciones de referencia/wildcard, un par para la dirección origen de los paquetes y otro par para
la dirección destino de los mismos. Vamos a extender el ejemplo que venimos usando y usar ésta
idea de filtrado más granular.

El requisito dado es permitir un host de una red, el resto de la red la vamos a bloquear y cualquier
otra red la vamos a permitir. Para extender el ejemplo digamos que queremos permitir el tráfico
del host, excepto lo que vaya a un host particular, digamos el 172.16.1.1, y que de la red completa
queremos permitir lo que vaya a un servidor en especial de la empresa, digamos el 192.168.2.1.
Las reglas de la acl estandar nos sirven de inicio, como de costumbre lo más específico lo vamos a
poner de primero en la regla para evitar que las reglas más generales incluyan a las particulares.

• access-list 100 deny ip 192.168.1.1 0.0.0.0 172.16.1.1 0.0.0.0
• access-list 100 permit ip 192.168.1.1 0.0.0.0 0.0.0.0 255.255.255.255

• access-list 100 permit ip 192.168.1.0 0.0.0.63 192.168.2.1 0.0.0.0

• access-list 100 deny ip 192.168.1.0 0.0.0.63 0.0.0.0 255.255.255.255

• access-list 100 permit ip any any

En ésta lista observamos varias cosas nuevas: ip, las acl extendidas no sólo permiten especificar las
direcciones origen y destino sino discriminar por protocolos e incluso por parámetros particulares
de cada protocolo pero eso lo veremos luego, por lo pronto lo importante es que ip indica que
todos los protocolos que se encapsulan dentro de ip serán afectados por ésta lista de acceso. En
este caso, la palabra ip para los protocolos es similar a any en las direcciones, casi todo se
encapsula en ip por lo tanto especificar ip es como especificar cualquier protocolo (de capa 4 en
adelante). En vez de ip se puede poner un protocolo equivalente o de capa 4, por ejemplo se
puede filtrar icmp, tcp o udp, cambiando la palabra ip por éstas últimas.

Otra cosa importante y nueva es un segundo par de dirección de referencia/máscara wildcard,
éste segundo par compara la dirección destino de los paquetes con la dirección de la regla. Para
las acls extendidas, el paquete debe coincidir tanto en la dirección origen como en la destino.

Finalmente, la dirección de referencia 0.0.0.0 con máscara wildcard 255.255.255.255. Como esta
máscara es todo unos, eso significa que ningún bit del paquete se compara con la dirección de
referencia, es decir, no importa qué escriba en la dirección de referencia cualquier destino
coincide. Esta máscara es lo mismo que any, debido a que la máscara es equivalente a cualquier
dirección y puede usarse tanto para el origen como para el destino.

Explicación de la ACL

La primera regla aplica deny sólo si el paquete tiene como origen la dirección 192.168.1.1 y
dirección destino 172.16.1.1, por lo tanto sólo el tráfico específico de entre esos host se deniega,
la segunda regla permite el resto del tráfico del host hacia cualquier destino. La tercera regla
permite el tráfico de la red 192.168.1.0/26 hacia el host 192.168.2.1. La 4a regla complementa a la
anterior y niega todo el tráfico de la red, como ésta regla general esta después de la específica, el
tráfico comparado con ésta regla ya no coincidió con el tráfico dirigido al servidor, que es una
condición más específica dentro de la misma red. Finalmente cualquier tráfico que no coincida con
las reglas anteriores se permite sin importar de dónde provenga y hacia dónde vaya.

¿Qué más?

Finalmente y para no dejar incompleto el ejemplo, hay que instalarla en una interfaz por la que
pase el tráfico que se quiere interceptar y recordar que el sentido en el que se instala la acl, indica
cuáles serán las direcciones origen y destino (que se invierten si se invierte el sentido del tráfico).

• interface serial 0/0
• ip access-group 100 in

Las listas de acceso extendidas no difieren de las estándar más que en las características
mencionadas, por lo tanto los comandos usados para verificar las estándar siguen siendo válidos.

• show ip interface serial 0/0
• show ip access-list

¿Cómo funcionan las ACLs? IV: ACLs complejas

Un tema nuevo en el currículo de CCNA Exploration son las ACLs complejas, que no son
necesariamente complejas en el sentido de la dificultad sino en lo sofisticado de su
funcionamiento, también menciono las acl nombradas. Vamos a explorar algunas de ellas
superficialmente y dejar pendiente la última entrada sobre ACLs: Ejemplos.

¿Qué son ACL complejas?

CCNA Exploration varios tipos de ACLs no vistos en las versiones anteriores del currículo, las
denomina ACLs complejas. La idea de las ACLs complejas es complementar lo que ya sabemos
sobre ACLs estándar y extendidas con comportamientos que las hacen útiles en contextos más
interesantes. Para comprender correctamente el tema de las ACL complejas debe entender bien
todo lo relacionado con ACLs. Si usted no entiende perfectamente el tema del filtrado de tráfico
con ACLs le recomiendo que lea las entradas anteriores de esta serie, en su orden:

• ¿Cómo funcionan las ACL en Cisco? I: Conceptos
• ¿Cómo funcionan las ACLs? II: ACLs estándar

• ¿Cómo funcionan las ACLs? III: ACLs extendidas

Dentro de las ACLs complejas tenemos 3 tipos: dinámicas, reflexivas y basadas en tiempo pero en
el currículo oficial no se ven muy a fondo ni se dan mayores ejemplos. A continuación les describo

cada una de ellas y al final de la entrada describo las acl nombradas son un tipo de acl que facilita
la configuración y administración de ACLs.

ACLs dinámicas

Éstas usan un mecanismo básico de autenticación, generalmente Telnet, para activar la ACL, lo
que permite usar una ACL como mecanismo de autenticación o vincular una ACL con la
autenticación de los usuarios con medios reconocidos. La idea consiste en crear una regla en la
ACL que sólo se activará si es disparada por algún evento, en éste caso un acceso por telnet al
enrutador. La regla en cuestión agrega antes de la acción (permit/deny) las palabras reservadas
dynamic testlist timeout <n>, donde n es la cantidad de minutos que la regla será activa una vez
que es disparada, luego de estos parámetros va la regla ordinaria que se hará activa, por ejemplo
permit ip host 10.1.1.1 any. Como esta última regla está asociada con un acceso por telnet como
disparador, en las líneas de vty se debe poner un comando especial autocommand access-enable
host timeout 5, que establece el acceso permitido al telnet como disparador de la acl dinámica.

• access-list 101 permit ip any host 10.1.1.1 eq telnet
• access-list 101 dynamic testlist timeout 10 permit ip 172.16.0.0 0.0.255.255 172.17.0.0
0.0.255.255

• interface fa 0/0


• username cesarcabrera password cecab123

• line vty 0 4

• login local

• autocommand access-enable host timeout 5

El anterior listado de comandos instala una lista de acceso dinámica de entrada en la interfaz fa
0/0 que sólo después que un usuario cesar abre exitosamente una sesión por telnet con la clave
cecab123 con el enrutador se activa, permitiendo acceso de la red 172.16.0.0/16 a la
172.17.0.0/16. Valga la aclaración que el comando autocommand cierra automáticamente la
sesión de telnet pero dispara la acl, es decir, la sesión de telnet es sólo un disparador de la acl y no
tiene que quedar activa para que la acl esté en funcionamiento.

ACLs reflexivas

Las reflexivas son un tipo de firewall primitivo que permite el tráfico sólo si es iniciado en una
dirección, pero sin usar las banderas de conexión de TCP. Ya en las ACLs extendidas habíamos
visto que en vez de ip se pueden poner otros protocolos y al final poner criterios adicionales
particulares al protocolo en cuestión. Específicamente, tcp permite agregar al final del

identificador de origen o destino un identificador de puerto en incluso banderas de conexión
como established, que indica que la conexión ya se abrió. Éste caso particular de tcp es muy útil
cuando se tienen dos redes de las cuales una es confiable y la otra no, entonces es preferible
permitir sólo conexiones cuya solicitud provenga de la red confiable, es decir, que se abran desde
la red interna y no se puedan abrir conexiones desde la externa. Con el truco de la bandera
established (ack activo) se puede permitir de entrada sólo los paquetes con ésta condición, de tal
manera que si llegan paquetes solicitando una conexión desde fuera (todavía no tienen el bit ack
activo) se rechazan, mientras que si las conexiones se abren desde adentro, todos los paquetes
entrantes deberán tener el ack activo y por lo tanto se van a permitir. Pero ¿qué pasa con UDP y
otros protocolo no orientados a la conexión? Pues ahí entran en juego las acl reflexivas. La idea es
hacer lo mismo que el truco de established, pero basandose sólo en los parámetros básicos de
capa 3 y 4.

Las acls reflexivas son un poco complejas en su configuración, ya que se aplican varios comandos
para establecer las entradas temporales, adicionalmente las ACLs reflexivas son un caso
particular de ACL nombrada extendida, por lo tanto no se pueden configurar en acl numeradas ni
en acls nombradas estándar. Primero, en una de las direcciones del tráfico se debe marcar la regla
cuyo tráfico de vuelta se va a permitir con la palabra clave reflect <nombre>, donde nombre es un
identificador arbitrario que le ponemos a esta instancia, luego en la dirección de vuelta del tráfico
(la acl que se va a instalar en la dirección contraria) se agrega la sentencia evaluate <nombre>
donde nombre es el identificador arbitrario que pusimos en la otra dirección. En otras palabras,
se le pone un identificador al tráfico que inicia la acl reflexiva, luego en la otra dirección se le
ordena que evalúe si el tráfico corresponde con la regla marcada para permitirlo si coincide.
Finalmente se instalan las listas, una de entrada y otra de salida en la misma interfaz (el tráfico
entra y sale por la misma interfaz).

• ip access-list extended OUTB
• permit udp 172.16.0.0 0.0.255.255 any reflect UDPTRAFFIC

• permit icmp 172.16.0.0.0.0.255.255 any reflect ICMPTRAFF

• ip access-list extended INB

• evaluate UDPTRAFFIC

• evaluate ICMPTRAFF

• interface ser 0/0

• ip access-group OUTB out

• ip access-group INB in

El listado anterior instala una lista de acceso reflexiva que permite el tráfico de UDP e ICMP sólo si
se originó en la red 172.16.0.0/16.

ACLs basadas en fechas/horarios

Finalmente, las más simples de comprender son las basadas en fechas/horarios. La idea de estas
acls son que se activan en las fechas y horarios que se hayan establecido previamente, la
precondición evidente es que el enrutador debe tener configuradas su hora y fecha
correctamente, para ésto se puede configurar manualmente, confiando que el equipo no se vaya a
reiniciar por ningún motivo y que el administrador va a mantener actualizado el reloj en caso
contrario. Otra alternativa (más confiable) es configurar un servidor ntp para que el enrutador
mantenga su tiempo actualizado.

La configuración de las acls basadas en tiempo consiste en crear un rango de tiempo (time-range)
el cual es después usado en las reglas de la ACL.

• time-range NOCHES
• periodic Monday Tuesday Wednesday Thursday Friday 17:00 to 00:00

• access-list 101 permit tcp 172.16.0.0 0.0.255.255 any eq www time-range NOCHES

• int fa 0/0

• ip access-group 101 out

El anterior listado crea una lista de acceso que se permite el acceso a Internet para la red
172.16.0.0 sólo después de las 17hrs en días de trabajo (Lunes a Viernes).

ACL nombradas

Finalmente, hay una forma más fácil de editar las listas de acceso llamadas listas de acceso
nombradas. La idea básica de éstas ACLs es permitir una administración mnemónica de las ACL, ya
que en vez de números se usan nombres arbitrarios. Éstas listas pueden ser extendidas o
nombradas con las mismas características que las ACLs numeradas y abren un modo especial de
configuración (nacl) en el que se introducen las reglas una por una empezando por la acción
(permit/deny). Después de la versión 12.3 del IOS, éstas listas de acceso permiten eliminar y crear
reglas particulares entre las reglas existentes, contrario a la edición ordinaria de ACLs en la que
tocaba eliminar completamente una ACL para poder modificarla. En su configuración las palabras
clave son ip access-list, lo que hemos visto hasta este momento, todas las listas de acceso
comienzan con la palabra reservada access-list, éstas comienzan con ip access-list, seguidas del
tipo de lista extended/standard y el nombre (arbitrario). Luego se entra en el modo especial de
configuración.

• ip access-list extended INB
• (config-ext-nacl)#permit 172.16.0.0 0.0.255.255 172.17.0.0 0.0.255.255

• (config-ext-nacl)#deny any any

Éstas listas se aplican como se aplican todas las acls y se verifican con los mismos comandos. show
ip access-list y show ip interface.

¿Cómo funcionan las ACLs?: V Ejemplos

Conceptos básicos

Hay que recordar que las ACLs son fundamentalmente un mecanismo de selección de tráfico,
generalmente, por medio de parámetros de los campos del encabezado IP o los encabezados TCP
y UDP. En algunos casos, el protocolo de capa 4 puede establecer correspondencias con otros
encabezados como los de EIGRP, OSPF, entre otros. Una vez que la selección se establece, se
puede usar para múltiples finalidades, por ejemplo en CCNA se usa como mecanismo básico de
seguridad, es decir, el tráfico seleccionado se puede bloquear o permitir según las necesidades de
la organización. Otros usos son la definición de las direcciones que van a ser traducidas en un
enrutador de borde que usa NAT entre otras muchas tecnologías que usan las ACLs para definir
conjuntos de direcciones o flujos de tráfico seleccionados entre muchos otros.

La selección de tráfico o direcciones en las ACLs consiste en definir un conjunto de reglas bajo un
mismo identificador, sea numérico o alfanumérico, con la forma

• <id> <acción> <condición>
• <id> <acción2> <condición2>

• Comando: access-list <n> [permit|deny] <ref_origen> <wildcard_origen>
[<ref_destino> <wilcard_destino>]

donde id es el nombre/número de la ACL, acción es permitir o denegar y en el comando id se
corresponde con n , acción con permit|deny y la condición sería el resto del comando. La
condición es lo que usualmente nos exige más cuidado, las condiciones se basan en direcciones
origen en las ACLs estándar y origen/destino en las extendidas y nombradas extendidas. Las
direcciones origen o destino se definen cada una mediante una dirección de referencia y una
máscara wildcard y pueden definir arbitrariamente la selección, es decir, la dirección de referencia
no tiene que corresponder exactamente con una subred sino con cualquier conjunto de
direcciones, incluso de varias subredes o un subconjunto de IPs de una subred. Si la explicación
anterior no es clara, por favor lea la entrada inicial de la serie: ¿Cómo funcionan las ACLs?: I
Conceptos.

Topología de ejemplo

La siguiente va a ser nuestra topología de ejemplo. Infortunadamente el Packet Tracer no soporta
las ACLs reflexivas ni dinámicas, así que si usted desea hacer el ejercicio completo debe hacerlo o
bien con enrutadores reales o con GNS3. La topología consiste en 5 enrutadores interconectados
por enlaces seriales, uno de ellos es el enrutador central que conecta con el servidor y el resto
tienen sólo una subred conectada. Las direcciones de las LAN pertenecen al prefijo 172.16.0.0/12,
asignandolas en orden de izquierda a derecha 172.16.0.0/24, 172.17.0.0/24, 172.18.0.0/24 (PC4) y
172.19.0.0/24 (PC5). El servidor tiene la dirección 10.1.1.1 y los enlaces entre enrutadores son
10.0.0.0/30, 10.0.0.4/30, 10.0.0.8/30, 10.0.0.12/30. El enrutamiento se lleva a cabo con eigrp de
AS 1 sin autoresúmen por el hecho de haber redes discontiguas (10.0.0.0). La política
(requerimientos) de seguridad de la organización son los siguientes:

• Estándar: Filtrar el acceso de la red del PC1 al servidor
• Extendidas: Filtrar el acceso del PC2 al servidor

• Dinámicas (No soportadas): Acceder al servidor desde PC5 sólo si se autentica
previamente por telnet.

• Reflexivas (No soportadas): Permitir el tráfico de ICMP que se ogirine en PC4, pero no al
revés

Un aspecto importante, antes de hacer cualquier cosa con ACLs es verificar que exista
conectividad completa en la red objetivo. Si no comprobamos eso previamente, podríamos
ignorar problemas actuales de conectividad en la red y podríamos creer que eso es efecto de la
instalación de las acls. En esos casos el diagnóstico de un problema de esa naturaleza puede
resultar muy difícil de diagnosticar y más dificil aun de solucionar. Otra consideración que hay que
hacer es verificar que la instalación de una ACL afecta la red estrictamente como se espera y no
genera efectos no previstos e indeseados. Lo anterior hay que hacerlo por cada acl y verificando la
conectividad total -o la más importante si la red es muy grande-.

Listas de Control de Acceso Estándar

En el ejemplo, el requerimiento de filtrar la red del PC1 con ACL estándar nos enfrenta a la primera
decisión: ¿dónde instalar la ACL?. La respuesta tiene dos sentidos, en qué enrutador y en qué
interfaz de ese enrutador. Como las ACL estándar sólo filtran el tráfico con base en las direcciones
IP origen, si la acl se instala en Router1, eso filtraría todo el tráfico de la red hacia todos los
destinos, por lo tanto no es viable esa decisión. Una alternativa, si no es posible instalarla en otro
enrutador, sería filtrar el tráfico proveniente del servidor en ese mismo enrutador lo que impidiría
que las respuestas a tráfico que salió de la red de PC1 y PC3 regrese, lo cual sería un cumplimiento
indirecto de la política de impedir conectividad entre esa red y el servidor.

Según lo anterior, la única alternativa es instalar la ACL estándar en Router0, y con eso se cumple
la regla de oro de las acls estándar: instale lo más cerca posible del destino. En éste caso, en el
que podemos configurar el enrutador más cercano al servidor, la instalamos en la interfaz por la
que se conecta el servidor en la dirección de salida, filtrando efectivamente el tráfico cuyo origen
es la red del PC1.

El resto es carpintería como decía un antiguo profesor que tuve:

• access-list 1 deny 172.16.0.0 0.0.0.255
• access-list 1 permit any

• interface FastEthernet0/0

• ip address 10.0.0.1 255.255.0.0

• ip access-group 1 out

Una vez que se instala esta acl, los paquetes originados en cualquier pc de la red del PC1 no
llegarán al servidor pero sí a cualquier otro pc de la red. La conectividad con el resto de las redes
de la topología sigue intacta.

ACL extendidas

El segundo requerimiento es filtrar el tráfico desde el PC2 hasta el Servidor. Evidentemente no se
puede hacer un filtrado así con una sola acl estándar, por ejemplo, si ponemos una ACL estandar
en router0 que filtre el tráfico cuya IP es la de PC2 en la fa 0/0 de salida, éste quedará sin
conectividad con cualquier PC de la red del servidor, no sólo el servidor. Si, por otro lado, la
ponemos de entrada la situación es peor: el servidor no se podrá comunicar. Otra alternativa sería
instalarla en la interfaz LAN que pertenece a la red de PC2 (en Router1) y éste no se podrá
comunicar con ninguna otra red.

La solución es una ACL extendida, que por norma se instala lo más cercano al origen posible. El
razonamiento es que haciendolo de ésta manera evitamos que tráfico innecesario corra por la red
ocupando ancho de banda y procesamiento en los dispositivos.

• access-list 101 deny ip host 172.17.0.3 host 10.0.0.5
• access-list 101 permit ip any any

• interface FastEthernet0/0

• ip address 172.17.0.1 255.255.0.0


Lo anterior en el enrutador Router1, donde se conecta el host que se quiere filtrar. De nuevo, hay
que verificar que otros PCs no quedan afectados por la acl, eso lo verificamos enviando y
recibiendo paquetes exitosamente desde el PC6 al servidor. La conectividad del resto de las redes
de la topología sigue inalterada, eso incluye la conectividad de otras redes al pc2.

ACLs dinámicas y reflexivas

Infortunadamente el PT 5.1 no soporta ninguno de estos tipos de acls. Para poder hacer el
ejercicio habría que usar gns3, netlab o enrutadores reales. De todas formas ilustraré cómo sería
la configuración correspondiente en esta topología.

Recordemos que las dinámicas son, entre otras cosas, un mecanismo de autenticación simple. Lo
primero que haremos será crear un nombre de usuario y contraseña para autenticar al PC 5, luego
crearemos la acl que incluya la palabra reservada dynamic, cuidando que la misma acl permita el
tráfico de telnet desde el pc en cuestión, instalamos la acl y luego en la configuración de las vty
agregamos el comando que vincula estas dos instrucciones.

• username cesarcabrera password cecab123
• access-list 101 permit ip any host 172.19.0.1 eq telnet

• access-list 101 dynamic testlist timeout 15 permit ip host 172.19.0.3 host 10.0.0.5

• interface fa 0/0


Lo anterior, una vez instalado en el enrutador Router2, sólo permitirá el acceso del PC5 al servidor
si primero se intenta hacer un telnet al enrutador y se autentica exitosamente al mismo.

El requerimiento de acl reflexiva se debe instalar en el último enrutador, Router3, usando una acl
nombrada extendida -no numerada- y con dos palabras clave adicionales: reflect/evaluate. En la
dirección de salida se permite el tráfico pero se establece que se creen las acls necesarias para el
tráfico de retorno con reflect y de entrada se le indica a la acl que evalúe las entradas dinámicas
creadas por la acl de salida.

• ip access-list extended SALIDA
• permit icmp 172.18.0.0.0.0.0.255 any reflect TICMP

• ip access-list extended ENTRADA

• evaluate TICMP

• interface ser 0/0/0

• ip access-group SALIDA out

• ip access-group ENTRADA in

Note que una vez que se instalan estos comandos en el último enrutador, lo único que se puede
hacer desde la red 172.18.0.0n es enviar exitosamente pings, pero no serán exitosos si se originan
en otras redes hacia ésta última.

Otros usos de las ACLs

Finalmente, como les he venido mencionando en otras entradas, las acls son un mecanismo de
clasificación de tráfico y por eso son útiles en otros contextos. Voy a citar dos, uno de ccna y otro
de ccnp, particularmente de BSCI. En el último semestre de CCNA se estudia el tema de NAT, NAT
se usa para tener una red con direccionamiento privado arbitrariamente grande conectada a
una red pública usando sólo un pequeño conjunto de direcciones públicas. El mecanismo
consiste en examinar los paquetes provenientes de la red privada y cambiar las direcciones IP y
puertos TCP/UDP del encabezado por las direcciones públicas disponibles. De ese proceso se
guarda en memoria una registro de qué puertos origen han sido asignados a qué dirección
privada, de tal manera que cuando se recibe la respuesta de la red pública con IP destino pública
(o global como dice el currículo), el puerto TCP/UDP destino determina la dirección IP de host local
al que hay que cambiar la dirección IP para enviar el paquete al interior de nuestra red (en otra
ocasión escribo más en detalle el proceso).

NAT debe especificar dos conjuntos de direcciones: las direcciones privadas a traducir a
direcciones públicas y el conjunto de direcciones públicas. El conjunto de direcciones públicas es
un rango de direcciones arbitrarias que dificilmente corresponderán con una regla tipo acl, pero
las direcciones privadas sí deben tener un patrón que se corresponda con una acl estándar, en la
que las direcciones a las que se aplique la acción permit serán las direcciones que hay que traducir
a direcciones públicas (o globales). En otras palabras, para crear una regla de traducción de

direcciones, se especifica por medio de una acl qué direcciones privadas (o locales) deben ser
traducidas.

En BSCI (uno de los exámenes de ccnp) se habla de un mecanismo de manipulación de tráfico
llamado mapas de ruta (route-map). Los mapas de ruta permiten manipular la forma en que se
realiza el enrutamiento por ejemplo yo podría arbitrariamente y sin contar con la tabla de
enrutamiento, decir que el tráfico de cierta red debe usar siempre un enlace en particular de
salida. Ése es el ejemplo más simple de un mapa de ruta, pero los mapas de ruta permiten muchas
cosas más, por ejemplo cambiar parámetros de enrutamiento como métricas o filtrar
actualizaciones de enrutamiento que provengan de otro enrutador. El mecanismo básico por el
que se especifica qué tráfico será afectado por las reglas del mapa de ruta son las acl extendidas.

Cómo funcionan las acl en cisco

Más contenido relacionado

La actualidad más candente (20)

Destacado (20)

Similar a Cómo funcionan las acl en cisco (20)

Cómo funcionan las acl en cisco