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. Qu son ACL -Access Control Lists o listas de control de acceso-? Pues si no sabe lea la primera entrada sobre ACLs. En sta entrada vamos a partir de que se sabe qu es una acl estndar y qu son acls extendidas, partiendo de eso vamos a configurar en la topologa de ejemplo una poltica de seguridad arbitraria con listas estndar y listas extendidas y veremos la diferencia. 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).

Cmo configurar ACLs?: problema/ejercicio completo con ACLs extendidas En sta entrada, contino con el ejemplo de uso de ACLs en un ejercicio completo con visos de realismo, la vez pasada configuramos una red con ciertas polticas de seguridad usando slo ACLs estndar, ahora vamos a hacer el mismo ejercicio usando listas extendidas. Disfrtenlo.

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, losenlaces 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. Para hacer ste ejercicio use la topologa sugerida en esta entrada. Si algo de lo mencionado no est claro, por favor consulte entradas anteriores que he escrito sobre subredes, enrutamiento y la serie sobre ACLs.

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 yexample.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 derouter2 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).