Cmo configurar ACLs?

:
problema/ejercicio completo ACLs
estndar
Hace algn rato escrib una serie de entradas sobre ACLs -Access Control Lists o listas
de control de acceso en espaol. Infortunadamente, no han sido muy exitosas: nadie las
lee, bueno exagero, las leen poco respecto a lo que me esperaba (comparando con la
serie sobre Packet Tracer). La idea es hacer una nueva entrada ms prctica con video
incluido (en la prxima de la serie) que estimule la lectura de las otras entradas.
Disfrtenlo.

Topologa de ejemplo

Como base para el ejercicio vamos a tomar la misma topologa de la ltima entrada
sobre ACLs, en ella se conectan 5 enrutadores por cables seriales, a cada uno se le
conecta una subred con la posibilidad de agregar varios equipos. La topologa ya est
configurada y hay conectividad perfecta de punta a punta, es decir, se puede hacer ping
entre los PCs y se puede acceder por Telnet desde cualquier PC a cualquier enrutador.

Las subredes de los PCs (usuarios) estn todas dentro del prefijo 172.16.0.0/12, usando
las subredes 172.16.0.0/16, 172.17.0.0/16 y 172.19.0.0/16, la 172.18.0.0/16 es la
direccin que simular la salida a Internet. Los enlaces y el servidor pertenecen al
prefijo 10.0.0.0/8, es decir, los enlaces son 10.1.1.0/30, 10.1.1.4/30, 10.1.1.8/30,
10.1.1.12/30, 10.1.1.16/30 y el servidor es 10.0.0.5/8. ste esquema de direcciones se
llama direccionamiento no contiguo, es decir, las subredes consecutivas de una misma
clase (A, B o C) no estn asignadas a un slo enrutador (por ejemplo las subredes de los
enlaces pertenecen a la red 10.0.0.0/8 de clase A pero sus subredes se distribuyen por
todos los enrutadores). Cuando en una topologa se da el direccionamiento no contiguo,
hay que deshabilitar el auto resumen en el protocolo de enrutamiento que se est
usando.

El servidor corre http, tftp y dns (hay que activarlo), de hecho, vamos a usar
example.com para hacer pings y telnets, lo anterior slo funciona si se puede acceder al
servidor dns para convertir el nombre de dominio en direccin IP y si el servidor DNS
tiene una entrada para example.com que se traduce a una direccin IP, en nuestro caso la
172.18.0.2.

Recomendaciones previas

Como lo que vamos a hacer es un ejercicio un poco ms realista, lo primero que

deberamos tener en cuenta antes de comenzar es tomar precauciones. Lo primero es
guardar todas las configuraciones actuales, para que en caso de catstrofe (p.e.: se
pierda totalmente la conectividad) se pueda recuperar rpidamente la configuracin. Eso
se puede hacer guardando una copia del archivo de configuracin en un archivo de texto
o en un tftp. Hay que tener muy en cuenta que cuando se configuran ACLs usualmente
uno se conecta por Telnet, es decir, que si el dao hace perder la conectividad del
enrutador que se est configurando con el PC en el que estamos trabajando
Despedidos!. En una entrada anterior describo un comando para evitar catstrofes de
ste tipo (cuando el IOS lo soporta), que consiste en establecer un timer de reinicio, por
lo tanto si no guardamos la configuracin que estamos haciendo y perdemos la
conectividad hay garanta de que el enrutador/switch se reinicie y arranque con la
configuracin original (antes del cambio).

Lo otro que hay que verificar Y DOCUMENTAR es el estado de la conectividad previa

a la configuracin. No perdamos el tiempo tratando de arreglar lo que est malo (a
menos que sea nuestra responsabilidad directa), slo documentemos cmo est,
haciendo unos pings selectos y unos telnets que muestren qu se poda hacer antes de la
instalacin de las ACLs. Recuerden que una forma de verificar conectividad de capa 4 y
superior es usar un telnet al enrutador al que queremos verificar la conectividad (previa
configuracin correcta de las lineas de vty en el equipo al que apuntamos).

Poltica de seguridad de ejemplo

Ya descrita la topologa, creemos una poltica de seguridad impuesta por un superior

administrativo.

1. El servidor es de la intranet, es decir que de las redes del Router4 y Router2

deben poder acceder a la web interna.

2. Los PCs de la red del enrutador Router1 son invitados, por lo tanto slo pueden
acceder a Internet, no al servidor ni a las redes internas (las de Router4, Router2
ni a los enrutadores mismos)

3. De los PCs de las redes internas, slo quienes tengan direcciones IP impar
pueden acceder a Internet, el resto no.

4. Los PCs internos (excepto los invitados) pueden acceder a sus recursos y a los
enrutadores.

5. El PC 5 no puede acceder a ningn enrutador por ningn medio.

6. Cualquier trfico no contemplado debe ser bloqueado.

Lo anterior hay que ponerlo en trminos de filtrado de trfico con ACLs. El servidor
tiene la direccin IP 10.1.1.1, por lo tanto el trfico proveniente o destinado al servidor
cumple la condicin de que su direccin (origen o destino) debe ser exactamente
10.1.1.1. Una regla de ACL que coincida con el servidor sera host 10.1.1.1, en qu
posicin de la ACL poner esta condicin (direccin origen o destino) ya es cuestin de
si usamos ACLs extendidas o estndar y en qu direccin de trfico: de entrada o salida
de la interfaz. El trfico proveniente de los PCs de la red de Router1 tiene el patrn
172.16.0.0 0.0.255.255, es decir, todos tienen en alguna de sus direcciones IP (origen o
destino) los primeros 16 bits iguales a 172.16. La mscara wilcard dice que lo que est
en 1 lo ignore, no lo compare con la direccin de referencia, en otras palabras, la mezcla
de direccin de referencia con mscara wildcard se podra escribir 172.16.X.X, ya que
el trfico de la red slo se mirar en los bits que diga la mscara wildcard (los 0s
solamente) y cualquier otro bit se ignorar (los 1s). El patrn de trfico que identifica
las direcciones impares es el siguiente 0.0.0.1 255.255.255.254, que significa compare
slo el ltimo bit del paquete y quienes tengan ah un 1 cumplen la condicin sealada
(todo nmero impar tiene en binario un 1 en su bit menos significativo y todo nmero
par tiene un 0 en su ltimo bit). Como ejemplo adicional, si quisiramos condicionar el
trfico de cualquier red pero slo para las direcciones pares slo habra que poner
0.0.0.0 255.255.255.254, regla que se cumplira slo para los paquetes que tengan un 0
en su ltimo bit. El trfico de los PCs internos es el mismo ejemplo que para la red del
Router1 y el trfico del PC5 es el mismo ejemplo del servidor: PCs del Router2 =
172.19.0.0 0.0.255.255 y PC5 host 172.19.0.3

Los ejemplos anteriores son complejos y todava no hemos decidido en qu interfaces

de qu enrutadores y en qu direccin de trfico (entrada/salida) vamos a ubicar las
listas. Si hacemos la configuracin slo con listas estndar (por evitar sobrecarga del
enrutador o porque el enrutador no soporta -por alguna extraa razn- listas extendidas),
todas las condiciones que mencion en el prrafo anterior se deben aplicar a las
direcciones origen de los paquetes, porque las acls estndar slo permiten filtrar por
direccin IP origen.

Configuracin con listas estndar

Una de las cosas interesantes a notar es que la configuracin se puede hacer con listas
estndar o extendidas, el problema es qu tan difcil sea configurar todo sto. Primero
intentaremos con listas estndar. El orden de las listas afecta el resultado, por lo tanto
hay que poner las ms restrictivas primero y luego las ms generales, adems hay que
seleccionar dnde ponerlas. Para las listas estndar, la ubicacin debe ser lo ms
cercano posible del destino, por lo tanto para el trfico que se dirige al servidor lo ms
cercano al destino es su enrutador, en la interfaz que da hacia el servidor y en la
direccin de entrada (recuerden que las ACLs estndar slo pueden filtrar con base en la
dir. origen). Esa es la mejor opcin, otras opciones seran en las otras interfaces de
salida, pero probablemente sea necesario ponerlas en todas las interfaces.

Me alargara demasiado si explico cada regla, pero yo creo que queda claro con la
eleccin de la lista del servidor, as que voy a escribir el listado y la ubicacin:

Poltica 1:
Router0, fa 0/0 out
access-list 1 permit 172.16.0.0 0.0.255.255
access-list 1 permit 172.19.0.0 0.0.255.255

Poltica 2:
Router4, ser 0/0/0, in
access-list 1 deny 172.17.0.0 0.0.255.255
access-list 1 permit any

Router2, ser 0/0/0, in

access-list 1 deny 172.17.0.0 0.0.255.255
access-list 1 permit any

Router3, ser 0/0/0, in

access-list 1 permit 172.17.0.0 0.0.255.255
Poltica 3:
Router3, ser 0/0/0, in
access-list 1 permit 172.17.0.0 0.0.255.255
access-list 1 permit 0.0.0.1 255.255.255.254

Poltica 4:
Router4, ser 0/0/0, in
access-list 1 deny 172.17.0.0 0.0.255.255
access-list 1 permit 172.19.0.0 0.0.255.255

Router2, ser 0/0/0, in

access-list 1 deny 172.17.0.0 0.0.255.255
access-list 1 permit 172.16.0.0 0.0.255.255

Router0, Router1, Router2, Router3 y Router4 en las vty.

access-list 2 permit 172.19.0.0 0.0.255.255
access-list 2 permit 172.16.0.0 0.0.255.255
access-list 2 permit 10.0.0.0 0.255.255.255

Poltica 5:
Router0, Router1, Router2, Router3 y Router4 en las vty.
access-list 2 deny host 172.19.0.3
access-list 2 permit 172.19.0.0 0.0.255.255
access-list 2 permit 172.16.0.0 0.0.255.255
access-list 2 permit 10.0.0.0 0.255.255.255

Poltica 6:
Todas las listas de acceso terminan en un deny implcito, es recomendable usar un deny
any explcito para poder llevar control de cuntos paquetes son filtrados por sta ltima
regla.

Adicionales:
1) Dado que las listas escritas tambin bloquean el protocolo de enrutamiento, una
vez instaladas las listas anteriores, las tablas de enrutamiento se empiezan a daar
(faltan rutas), se pierde la conectividad y la convergencia de la red. Por lo anterior, hay
que permitir el trfico que provenga de los enrutadores, en las interfaces habra que
poner una regla como sta
access-list 1 permit 10.1.1.0 0.0.0.255

y en las vty, una como sta para incluir el servidor en la posibilidad de hacer telnets
access-list 1 permit 10.0.0.0 0.255.255.255

2) Con las listas propuestas, el trfico de Internet de las estaciones impares puede
salir de la red, pero pasa las listas en los enrutadores finales? No, y el problema es
que el trfico proveniente de internet no tiene un patrn de direcciones IP origen, por lo
tanto la nica regla que permitira el trfico de internet sera permit any, lo cual violara
la poltica de bloquear cualquier otro trfico.

3) No hay forma de permitir el trfico desde la red de invitados hacia el servidor

slo para web, dns y tftp. Si slo hubiera la opcin de usar listas estndar, habra que
ubicar un servidor por fuera de la zona protegida o no protegerlo de la red de invitados,
algo que es inaceptable en las redes modernas.

Segn las consideraciones anteriores, las listas de acceso seran:

Router0, fa 0/0 out

access-list 1 permit 172.16.0.0 0.0.255.255
access-list 1 permit 172.19.0.0 0.0.255.255

Router3, ser 0/0/0, in

access-list 1 permit 172.17.0.0 0.0.255.255
access-list 1 permit 0.0.0.1 255.255.255.254
access-list 1 permit 10.0.0.0 0.255.255.255
access-list 1 deny any

Router4, ser 0/0/0, in

access-list 1 deny 172.17.0.0 0.0.255.255
access-list 1 permit any

Router2, ser 0/0/0, in

access-list 1 deny 172.17.0.0 0.0.255.255
access-list 1 permit any

Router0, Router1, Router2, Router3 y Router4 en las vty.

access-list 2 permit 172.19.0.0 0.0.255.255
access-list 2 permit 172.16.0.0 0.0.255.255
access-list 2 permit 10.0.0.0 0.255.255.255

Para terminar, los comandos con los cuales se instalan las listas son ip access-group N
in/out si se va a instalar en las interfaces (serial o fastethernet) pero si se van a instalar
en las lneas vty se usa el comando access-class N in/out.

Conclusiones

Las ACLs estndar tienen una potencia limitada, pero en ciertos casos puede ser
necesario usarlas. Las ACLs estndar se usan en otros contextos en los que las
limitaciones no son tan importantes, como definir un conjunto de direcciones para
usarse en NAT o en otro proceso que parta de un bloque de direcciones IP, en ste caso,
la idea de direccin destino pierde sentido y las ACLs estndar son perfectas para una
aplicacin como stas. En el ejemplo propuesto se ilustra mucho de lo que se puede
hacer con las ACLs estndar y tambin lo que no se puede hacer: filtrado por puertos.
La prxima entrada ser la misma poltica, pero implementada con listas extendidas. Si
ya comprenden el tema, vayan trabajandolo a ver si coincide con mi propuesta (o es
mejor).
P.D.: Esta entrada la empec a escribir, la dej programada pero se me olvid y se
public incompleta. Me toc terminarla rpidamente porque ya me ha pasado antes y
me da pena que aparezcan y desaparezcan entradas, as que si hay muchos errores me
perdonarn. Ah la iremos corrigiendo.
Cmo configurar ACLs?:
problema/ejercicio completo con ACLs
extendidas
Para retomar el ejercicio, recordemos la topologa de ejemplo. Tenemos una topologa
en la cual los hosts pertenecen a subredes dentro del espacio 172.16.0.0/12, los enlaces
dentro del espacio 10.1.1.0/24 y un servidor de Intranet en la ip 10.0.0.5. En el servidor
funcionan los servicios usuales: www, dns y tftp. Hay que configurar el dns para que
resuelva las peticiones a example.com a la direccin 172.18.0.1 que provengan de
cualquier host de la red (incluso de los invitados). Existen dos redes LAN que son las
redes de los extremos, una red de invitados que es la segunda red de izquierda a derecha
del diagrama, una red de servidores (slo uno) y finalmente simulamos el acceso a
internet con la red del extremo derecho superior. Hay pequeos cambios respecto a la
topologa anterior: agregu un switch y un pc a la red del router2, cambi el PC que
simula internet por un servidor y agregu a la configuracin unas entradas de DNS, una
para resolver example.com a la ip 172.18.0.1, www.example.com a la 172.18.0.2 e
intranet.com a la direccin del servidor mismo.

Poltica de seguridad de ejemplo

La poltica que vamos a usar es la misma del ejercicio anterior, impuesta por un
superior administrativo.

1. El servidor es de la intranet, es decir que de las redes del Router4 y Router2

deben poder acceder a la web interna.

2. Los PCs de la red del enrutador Router1 son invitados, por lo tanto slo
pueden acceder a Internet, no al servidor ni a las redes internas (las de
Router4, Router2 ni a los enrutadores mismos).

3. De los PCs de las redes internas, slo quienes tengan direcciones IP impar
pueden acceder a Internet, el resto no.
 4. Los PCs internos (excepto los invitados) pueden acceder mutuamente a sus
recursos y a los enrutadores.

5. El PC 5 no puede acceder a ningn enrutador por ningn medio.

6. Cualquier trfico no contemplado debe ser bloqueado.

Ahora vamos a intentar poner sta poltica en trminos de ACLs extendidas,

recuerden que ste es un ejercicio y la ACL final va a tener defectos que uds. deben
detectar y corregir. De la entrada anterior deducimos que hay ciertos objetivos que no
se pueden lograr con ACLs estndar, por ejemplo, no se puede permitir slo el trfico de
DNS la red de invitados hacia el servidor, lo cual es un requerimiento implcito: el
servidor tambin es responsable por DNS, por lo tanto para poder hacer operaciones con
dominios (como ping example.com), antes de hacer ping entre la estacin y
example.com se debe resolver el dominio a una direccin IP y eso es un trfico
intermedio de DNS desde la estacin al servidor (quien resuelve la peticin con la
direccin 172.18.0.1). Ya con la experiencia de la entrada anterior, sabemos que hay
otros requerimientos implcitos que hay que considerar antes de implementar, por
ejemplo, como las listas de acceso terminan por defecto con un deny any, es probable
que trfico necesario, como las actualizaciones de enrutamiento entre los enrutadores,
sea bloqueado por defecto y, como nuestro foco de atencin son las polticas de
seguridad, nos resulte difcil deducir ese resultado inesperado o peor an, que
verifiquemos que se haya bloqueado el trfico que queramos bloquear y quedemos
convencidos de que s se logr el objetivo (por no verificar el trfico permitido), pero la
razn del bloqueo es que el enrutamiento se cay totalmente, por lo tanto el trfico
que queramos bloquear ya no pasa pero tampoco pasar ningn otro. Eso hay que verlo
haciendo el ejercicio de la entrada anterior.

No sobra repetirlo: asegrese que tiene copia de seguridad de la configuracin

inicial para evitar que si se cae todo y los nervios nos limitan la capacidad de respuesta,
se pueda restaurar el estado de operacin inicial de la red con slo restaurar la
configuracin y reiniciar algn equipo. As podemos resolver sin presiones el problema
o, mejor an, simularlo.

Configuracin con listas extendidas

Una ventaja de las listas extendidas es que, aparte de permitir ms granularidad a la hora
de definir los criterios de seleccin de trfico, son mucho ms flexibles para su
implementacin, por ejemplo, usualmente podemos configurar con listas extendidas
todo en un slo enrutador, mientras que con listas estndar esa opcin no suele estar
disponible. De todos modos, configurar todo en un solo enrutador no es eficiente por
varias razones, una es que la carga de procesamiento queda en un solo dispositivo y otra
razn es que una distribucin eficiente de las listas de acceso ayuda a evitar trfico
innecesario. Recuerde que las listas de acceso extendidas se instalan de entrada en el
enrutador ms cercano al origen del trfico, eso evita que el enrutador haga bsquedas
en la tabla de enrutamiento para los paquetes bloqueados y evita que el trfico no
permitido cruce la red innecesariamente, recuerde tambin que sto ltimo no se puede
hacer con listas estndar porque ellas se tienen que instalar lo ms cerca al destino, es
decir, despus de que ocuparon ancho de banda en la red y procesamiento en los
enrutadores y dispositivos intermedios.
La lista inicial quedara as:

Router2

access-list 101 permit ip 172.19.0.1 0.0.255.254 any

access-list 101 deny tcp host 172.19.0.3 any eq 23

access-list 101 permit ip 172.19.0.0 0.0.255.255 172.16.0.0 0.0.255.255

access-list 101 permit tcp 172.19.0.0 0.0.255.255 host 10.0.0.5 eq www

access-list 102 deny host 172.19.0.3 any

Router4

access-list 101 permit ip 172.16.0.1 0.0.255.254 any

access-list 101 permit ip 172.16.0.0 0.0.255.255 172.19.0.0 0.0.255.255

access-list 101 permit tcp 172.16.0.0 0.0.255.255 host 10.0.0.5 eq www

Router1

access-list 101 deny ip 172.17.0.0 0.0.255.255 172.16.0.0 0.0.255.255

access-list 101 deny ip 172.17.0.0 0.0.255.255 172.19.0.0 0.0.255.255

access-list 101 deny ip 172.17.0.0 0.0.255.255 10.1.1.0 0.0.0.255

access-list 101 permit udp 172.17.0.0 0.0.255.255 10.1.1.0 0.0.0.255 eq 53

access-list 101 permit ip 172.17.0.0 0.0.255.255 any

Router0

No hay ACLs porque las polticas se cumplen en cada enrutador.

La lista estndar que se ve en router2, es una lista especial que usaremos para bloquear
el acceso por telnet a este enrutador y en ste mismo bloqueamos el acceso por telnet a
los otros. Para que las listas de acceso extendidas sean eficientes, se deben instalar de
entrada lo ms cerca posible del origen del trfico a bloquear, por lo tanto, la lista de
router2 la instalara en la interfaz fa0/0 de entrada, de tal manera que el trfico
bloqueado ni siquiera implique enrutar esos paquetes en ese enrutador. De esta
instalacin se deduce que todas las listas estarn en las interfaces de lan de los
enrutadores correspondientes en la direccin de entrada. Finalmente, la lista estndar se
instala en la vty (acceso por telnet/ssh) del enrutador correspondiente con el comando
access-class <N> in, diferente del comando access-group <N> in de las interfaces
ordinarias. Tambin hay que tener en cuenta que el orden de la lista tiene un efecto
importantsimo en el filtrado de trfico, si una regla corresponde con cierto trfico que
se incluye en otra regla, la ms especfica debera ir primero, por ejemplo la regla

access-list 101 permit udp 172.17.0.0 0.0.255.255 10.1.1.0 0.0.0.255 eq 53

Que se instala en el router1 corresponde con el trfico proveniente de la red 172.17.0.0

que va hacia el servidor por UDP en el puerto 53, el permit deja pasar ese trfico, en
otras palabras, el trfico de DNS proveniente de la red de invitados entra al servidor. Si
yo incluyo una regla para denegar el resto del trfico proveniente de la red de invitados
hacia el servidor de esta manera:

access-list 101 deny ip 172.17.0.0 0.0.255.255 10.1.1.0 0.0.0.255

Esta regla incluye el trfico permitido con la regla anterior, la primera regla es ms
especfica que la segunda, por lo tanto debe ir antes en el listado. Ponerlas en el orden
inverso implicara que siempre se denegara el trfico de la red 172.17.0.0 incluso el
trfico de DNS, porque despus de ejecutar la regla general de denegacin (puesta antes
de la especfica) terminara la ejecucin de la lista de acceso (cuando se encuentra una
correspondencia se aplica la accin y se deja de ejecutar la lista, no se examinan ms
clusulas).

Hacer el ejercicio

Obviamente el ejercicio ya est resuelto, el archivo que dejo a disposicin es un archivo

de Packet Tracer con la topologa propuesta y est configurada con conectividad total
entre todas las estaciones, una vez que se instalen las listas de acceso en las interfaces
correctas, la poltica de seguridad estar en uso. Instalando la ACL del router2 vemos el
primer problema: el trfico de telnet desde la IP 172.19.0.3 que pensamos que ibamos a
bloquear pasa por la primera regla (permitir IP impar concualquier destino), si se di
cuenta del problema pas la primera prueba.

Si hacemos ping example.com desde cualquiera de los PCs de la red de router2 hacia
cualquier destino el ping es exitoso, lo cual comprueba el resto de la ACL, cierto? Pues
no, la lista no permite dns y por lo tanto nunca se sabr la IP de example.com pero para
observar los detalles que nos pueden engaar, si probamos la lista en el PC 172.19.0.3 s
pasar, porque una regla permite cualquier trfico desde ese PC hacia cualquier destino.
As que tambin falta una regla que permita el trfico de DNS en sta lista.

Bueno, ya creo que queda claro lo que hay que hacer: comprobar exhaustivamente
qu trfico qued permitido y qu trfico bloqueado. La tarea que les sugiero es que
intenten instalando la lista actual y encontrar los defectos (tiene muchos) luego usen
la lista de acceso resuelta que tambin dejar adjunta a la entrada. Un buen ejemplo de
lista de acceso bien aplicada es la que se aplica en el router2: slo permite lo que debe
permitir y bloquea cualquier otra cosa, sin embargo habra que agregarle una regla que
permita el acceso por telnet al enrutador.

Recuerde: las listas extendidas se deben instalar (excepto cuando definitivamente no es

posible) de entrada en las interfaces ms cercanas al origen del trfico con el comando
de modo de interfaz ip access-group <N> in, para bloquear el trfico de una vty se usa
el comando access-class <N> in.
Conclusiones

Las ACLs son complicadas porque no estamos acostumbrados a pensar en trminos

de clasificacin de trfico y a veces la comprobacin debe ser muy minuciosa para
poder determinar que todos los objetivos quedaron incluidos. Lo anterior es una de las
razones por las que el currculo de Cisco insiste en la documentacin: hay que
planificar concienzudamente lo que se desea y verificar exhaustivamente su
cumplimiento. Los dejo con los archivos prometidos y les ruego paciencia ya que no he
podido volver a escribir regularmente con ste nivel de detalle (y creo que cada vez va a
ser ms difcil).