¿Cómo configurar ACLs?

: problema/ejercicio completo ACLs estándar Hace algún rato escribí una serie de entradas sobre ACLs -Access Control Lists o listas de control de acceso en español. 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 más práctica con video incluido (en la próxima de la serie) que estimule la lectura de las otras entradas. Disfrútenlo. ¿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 estándar y qué son acls extendidas, partiendo de eso vamos a configurar en la topología de ejemplo una política de seguridad arbitraria con listas estándar y listas extendidas y veremos la diferencia. Topología de ejemplo Como base para el ejercicio vamos a tomar la misma topología 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 topología 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) están 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 dirección 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 están asignadas a un sólo 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 topología 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 sólo funciona si se puede acceder al servidor dns para convertir el nombre de dominio en dirección IP y si el servidor DNS tiene una entrada para example.com que se traduce a una dirección IP, en nuestro caso la 172.18.0.2. Recomendaciones previas Como lo que vamos a hacer es un ejercicio un poco más realista, lo primero que deberíamos tener en cuenta antes de comenzar es tomar precauciones. Lo primero es guardar todas las configuraciones actuales, para que en caso de catástrofe (p.e.: se pierda totalmente la conectividad) se pueda recuperar rápidamente la configuración. Eso se puede hacer guardando

es decir.1.1.1. el resto no. Los PCs internos (excepto los invitados) pueden acceder a sus recursos y a los enrutadores. es decir. 5. Los PCs de la red del enrutador Router1 son invitados. No perdamos el tiempo tratando de arreglar lo que esté malo (a menos que sea nuestra responsabilidad directa). Cualquier tráfico no contemplado debe ser bloqueado.una copia del archivo de configuración en un archivo de texto o en un tftp.0. Hay que tener muy en cuenta que cuando se configuran ACLs usualmente uno se conecta por Telnet. 1.255.1. El servidor tiene la dirección IP 10. no al servidor ni a las redes internas (las de Router4. en qué posición de la ACL poner esta condición (dirección origen o destino) ya es cuestión de si usamos ACLs extendidas o estándar y en qué dirección de tráfico: de entrada o salida de la interfaz. por lo tanto si no guardamos la configuración que estamos haciendo y perdemos la conectividad hay garantía de que el enrutador/switch se reinicie y arranque con la configuración original (antes del cambio).0. Una regla de ACL que coincida con el servidor sería host 10. El servidor es de la intranet. que consiste en establecer un timer de reinicio. El tráfico proveniente de los PCs de la red de Router1 tiene el patrón 172. por lo tanto sólo pueden acceder a Internet. por lo tanto el tráfico proveniente o destinado al servidor cumple la condición de que su dirección (origen o destino) debe ser exactamente 10. En una entrada anterior describo un comando para evitar catástrofes de éste tipo (cuando el IOS lo soporta). Política de seguridad de ejemplo Ya descrita la topología. que si el daño hace perder la conectividad del enrutador que se está configurando con el PC en el que estamos trabajando… ¡Despedidos!. 2. Lo otro que hay que verificar Y DOCUMENTAR es el estado de la conectividad previa a la configuración. es decir que de las redes del Router4 y Router2 deben poder acceder a la web interna.1.1.0 0. 4.1. 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 configuración correcta de las lineas de vty en el equipo al que apuntamos).16. sólo documentemos cómo está.1.255. Lo anterior hay que ponerlo en términos de filtrado de tráfico con ACLs. El PC 5 no puede acceder a ningún enrutador por ningún medio. creemos una política de seguridad impuesta por un “superior” administrativo. sólo quienes tengan direcciones IP impar pueden acceder a Internet. haciendo unos pings selectos y unos telnets que muestren qué se podía hacer antes de la instalación de las ACLs.1. 6. De los PCs de las redes internas. todos tienen en alguna de sus . Router2 ni a los enrutadores mismos) 3.

ya que el tráfico de la red sólo se mirará en los bits que diga la máscara wildcard (los 0′s solamente) y cualquier otro bit se ignorará (los 1′s). otras opciones serían en las otras interfaces de salida.0. in .0. por lo tanto para el tráfico que se dirige al servidor lo más cercano al destino es su enrutador. El tráfico de los PCs internos es el mismo ejemplo que para la red del Router1 y el tráfico del PC5 es el mismo ejemplo del servidor: PCs del Router2 = 172.0 255.16.255.255. ser 0/0/0. origen). la ubicación debe ser lo más cercano posible del destino.254. todas las condiciones que mencioné en el párrafo anterior se deben aplicar a las direcciones origen de los paquetes.254.255.0 0.0. pero probablemente sea necesario ponerlas en todas las interfaces. La máscara wilcard dice que lo que esté en 1 lo ignore.255 Política 2: Router4.listas extendidas).0. Me alargaría demasiado si explico cada regla.0. así que voy a escribir el listado y la ubicación: Política 1: Router0.0 0. El patrón de tráfico que identifica las direcciones impares es el siguiente 0. en la interfaz que da hacia el servidor y en la dirección de entrada (recuerden que las ACLs estándar sólo pueden filtrar con base en la dir. Para las listas estándar.255 access-list 1 permit 172. Si hacemos la configuración sólo con listas estándar (por evitar sobrecarga del enrutador o porque el enrutador no soporta -por alguna extraña razón. El orden de las listas afecta el resultado.255.direcciones IP (origen o destino) los primeros 16 bits iguales a 172.0 0. que significa compare sólo el último bit del paquete y quienes tengan ahí un 1 cumplen la condición señalada (todo número impar tiene en binario un 1 en su bit menos significativo y todo número par tiene un 0 en su último bit).19.3 Los ejemplos anteriores son complejos y todavía no hemos decidido en qué interfaces de qué enrutadores y en qué dirección de tráfico (entrada/salida) vamos a ubicar las listas. regla que se cumpliría sólo para los paquetes que tengan un 0 en su último bit.1 255. Configuración con listas estándar Una de las cosas interesantes a notar es que la configuración se puede hacer con listas estándar o extendidas.19.255.19. si quisiéramos condicionar el tráfico de cualquier red pero sólo para las direcciones pares sólo habría que poner 0. la mezcla de dirección de referencia con máscara wildcard se podría escribir 172. no lo compare con la dirección de referencia.0. el problema es qué tan difícil sea configurar todo ésto. porque las acls estándar sólo permiten filtrar por dirección IP origen.255 y PC5 host 172.255.0.255.0. pero yo creo que queda claro con la elección de la lista del servidor.X.0.16. además hay que seleccionar dónde ponerlas. Como ejemplo adicional.16. Esa es la mejor opción. Primero intentaremos con listas estándar. en otras palabras. fa 0/0 out access-list 1 permit 172.0. por lo tanto hay que poner las más restrictivas primero y luego las más generales.X.0.

255 access-list 2 permit 172.0 0. las tablas de enrutamiento se empiezan a dañar (faltan rutas). Router2.access-list 1 deny 172.19.0 0.255 Política 6: Todas las listas de acceso terminan en un deny implícito.0.0.0 0. ser 0/0/0.17.255 Router0.0.0.1 255.255 access-list 1 permit any Router3.255 access-list 2 permit 10.255.255. ser 0/0/0.255.255.0.255 access-list 1 permit 0. Adicionales: 1) Dado que las listas escritas también bloquean el protocolo de enrutamiento. ser 0/0/0.255. ser 0/0/0.17.0.0.19.255.0 0.0 0.0.0.0.0.255 access-list 1 permit 172. Router3 y Router4 en las vty.17.255 Política 3: Router3.0.16. hay que permitir el tráfico que provenga .17.0.0 0. access-list 2 permit 172.0 0.0 0. una vez instaladas las listas anteriores.255 Router2.0.0 0. Router1.0 0.0.0.0.19.0 0.16.255.255 access-list 2 permit 10.0.254 Política 4: Router4. in access-list 1 permit 172.0. in access-list 1 deny 172. access-list 2 deny host 172.0 0.0 0.0.0.16. se pierde la conectividad y la convergencia de la red.255.255.255.255.19.255.255.0. in access-list 1 deny 172.0.255.255 Política 5: Router0.17.0. Router2.255 access-list 2 permit 172. Router3 y Router4 en las vty. in access-list 1 deny 172.0.255.255.255.0.0. Por lo anterior.0. Router1.255. es recomendable usar un deny any explícito para poder llevar control de cuántos paquetes son filtrados por ésta última regla. ser 0/0/0.0 0.255 access-list 1 permit any Router2.17.0.0.3 access-list 2 permit 172.255 access-list 1 permit 172. in access-list 1 permit 172.0.

Según las consideraciones anteriores. in access-list 1 deny 172.16.0 0.255.19.0.255. in access-list 1 permit 172.0.255.255 access-list 1 deny any Router4. y el problema es que el tráfico proveniente de internet no tiene un patrón de direcciones IP origen.0. Router3 y Router4 en las vty.255 access-list 2 permit 10.de los enrutadores.0.17. Router2.0. lo cual violaría la política de bloquear cualquier otro tráfico. ser 0/0/0. fa 0/0 out access-list 1 permit 172.0. una como ésta para incluir el servidor en la posibilidad de hacer telnets access-list 1 permit 10.0 0. algo que es inaceptable en las redes modernas.255 access-list 1 permit 0.0.1 255.255.255 y en las vty.255.0.16.0.0. dns y tftp.0 0.0 0.255 2) Con las listas propuestas. pero ¿pasa las listas en los enrutadores finales? No.0 0.255.0. .255 access-list 2 permit 172. Router1.0.255.0.255 access-list 1 permit any Router2.0 0. las listas de acceso serían: Router0.255. in access-list 1 deny 172. 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 líneas vty se usa el comando access-class N in/out.0 0.17. habría que ubicar un servidor por fuera de la zona protegida o no protegerlo de la red de invitados.255 Para terminar.0.0. access-list 2 permit 172.19.0.255 access-list 1 permit 172.255.255.0.255.255.0.0 0. ser 0/0/0.0 0.0.1.255.0.255 Router3.0. Si sólo hubiera la opción de usar listas estándar.0 0.0 0.17.1.0.255.254 access-list 1 permit 10. ser 0/0/0. por lo tanto la única regla que permitiría el tráfico de internet sería permit any.0.255. en las interfaces habría que poner una regla como ésta access-list 1 permit 10.0.255 access-list 1 permit any Router0. el tráfico de Internet de las estaciones impares puede salir de la red. 3) No hay forma de permitir el tráfico desde la red de invitados hacia el servidor sólo para web.

como definir un conjunto de direcciones para usarse en NAT o en otro proceso que parta de un bloque de direcciones IP. La próxima entrada será la misma política. en éste caso. . la idea de dirección destino pierde sentido y las ACLs estándar son perfectas para una aplicación como éstas. En el ejemplo propuesto se ilustra mucho de lo que se puede hacer con las ACLs estándar y también lo que no se puede hacer: filtrado por puertos.Conclusiones Las ACLs estándar tienen una potencia limitada. pero en ciertos casos puede ser necesario usarlas. pero implementada con listas extendidas. Las ACLs estándar se usan en otros contextos en los que las limitaciones no son tan importantes. vayan trabajandolo a ver si coincide con mi propuesta (o es mejor). Si ya comprenden el tema.

0.0. Política de seguridad de ejemplo La política que vamos a usar es la misma del ejercicio anterior.example. Hay pequeños cambios respecto a la topología anterior: agregué un switch y un pc a la red del router2. ahora vamos a hacer el mismo ejercicio usando listas extendidas.5.0.¿Cómo configurar ACLs?: problema/ejercicio completo con ACLs extendidas En ésta entrada.0. Router2 ni a los enrutadores mismos). Si algo de lo mencionado no está claro. Disfrútenlo. una red de servidores (sólo uno) y finalmente simulamos el acceso a internet con la red del extremo derecho superior.2 e intranet. Hay que configurar el dns para que resuelva las peticiones a example. continúo con el ejemplo de uso de ACLs en un ejercicio completo con visos de realismo.1. impuesta por un “superior” administrativo. Los PCs de la red del enrutador Router1 son invitados. cambié el PC que simula internet por un servidor y agregué a la configuración unas entradas de DNS.16. por favor consulte entradas anteriores que he escrito sobre subredes.com a la ip 172. Para hacer éste ejercicio use la topología sugerida en esta entrada. 1.com a la dirección del servidor mismo. una red de invitados que es la segunda red de izquierda a derecha del diagrama. una para resolver example.0. . En el servidor funcionan los servicios usuales: www. losenlaces dentro del espacio 10.1 que provengan de cualquier host de la red (incluso de los invitados). es decir que de las redes del Router4 y Router2 deben poder acceder a la web interna.0/24 y un servidor de Intranet en la ip 10.0/12. Existen dos redes LAN que son las redes de los extremos. por lo tanto sólo pueden acceder a Internet.1. www. 2. recordemos la topología de ejemplo. la vez pasada configuramos una red con ciertas políticas de seguridad usando sólo ACLs estándar.com a la 172. dns y tftp. no al servidor ni a las redes internas (las de Router4.18. Para retomar el ejercicio.18.1. enrutamiento y la serie sobre ACLs.0.18. Tenemos una topología en la cual los hosts pertenecen a subredes dentro del espacio 172.com a la dirección 172. El servidor es de la intranet.

sea bloqueado por defecto y. 6. Cualquier tráfico no contemplado debe ser bloqueado. por lo tanto para poder hacer operaciones con dominios (como ping example. se pueda restaurar el estado de operación inicial de la red con sólo restaurar la configuración y reiniciar algún equipo. Ya con la experiencia de la entrada anterior. recuerden que éste es un ejercicio y la ACL final va a tener defectos que uds. como nuestro foco de atención son las políticas de seguridad. aparte de permitir más granularidad a la hora de definir los criterios de selección de tráfico. por lo tanto el tráfico que queríamos bloquear ya no pasa pero tampoco pasará ningún otro.com se debe resolver el dominio a una dirección IP y eso es un tráfico intermedio de DNS desde la estación al servidor (quien resuelve la petición con la dirección 172.com). 5. configurar todo en un solo enrutador no es eficiente por varias razones.18. mientras que con listas estándar esa opción no suele estar disponible. por ejemplo. Así podemos resolver sin presiones el problema o. No sobra repetirlo: asegúrese que tiene copia de seguridad de la configuración inicial para evitar que si se cae todo y los nervios nos limitan la capacidad de respuesta. Recuerde que las listas de acceso extendidas se instalan de entrada en el enrutador más cercano al origen del tráfico. nos resulte difícil deducir ese resultado inesperado o peor aún. lo cual es un requerimiento implícito: el servidor también es responsable por DNS.1). por ejemplo. antes de hacer ping entre la estación yexample. De la entrada anterior deducimos que hay ciertos objetivos que no se pueden lograr con ACLs estándar. eso evita que el enrutador haga búsquedas en la tabla de enrutamiento para los paquetes bloqueados y evita que el tráfico . Ahora vamos a intentar poner ésta política en términos de ACLs extendidas. deben detectar y corregir. De todos modos. Eso hay que verlo haciendo el ejercicio de la entrada anterior. son mucho más flexibles para su implementación. De los PCs de las redes internas. simularlo. El PC 5 no puede acceder a ningún enrutador por ningún medio. que verifiquemos que se haya bloqueado el tráfico que queríamos bloquear y quedemos convencidos de que sí se logró el objetivo (por no verificar el tráfico permitido).3. como las listas de acceso terminan por defecto con un deny any. Configuración con listas extendidas Una ventaja de las listas extendidas es que. una es que la carga de procesamiento queda en un solo dispositivo y otra razón es que una distribución eficiente de las listas de acceso ayuda a evitar tráfico innecesario. mejor aún. 4. por ejemplo. usualmente podemos configurar con listas extendidas todo en un sólo enrutador. es probable que tráfico necesario. no se puede permitir sólo el tráfico de DNS la red de invitados hacia el servidor. como las actualizaciones de enrutamiento entre los enrutadores. el resto no.0. sólo quienes tengan direcciones IP impar pueden acceder a Internet. Los PCs internos (excepto los invitados) pueden acceder mutuamente a sus recursos y a los enrutadores. sabemos que hay otros requerimientos implícitos que hay que considerar antes de implementar. pero la razón del “bloqueo” es que el enrutamiento se cayó totalmente.

255 172.255 access-list 101 permit tcp 172.0.0.255.255 host 10.255.1.255 any Router0  No hay ACLs porque las políticas se cumplen en cada enrutador.0.255 10. por lo tanto.0 0.255.1.1.0.0 0.255.1 0.5 eq www Router1      access-list 101 deny ip 172.17.19.0.255 host 10.0.0 0.0. después de que ocuparon ancho de banda en la red y procesamiento en los enrutadores y dispositivos intermedios. 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. de tal manera que el tráfico bloqueado ni siquiera implique enrutar esos paquetes en ese enrutador.255. es decir.0 0.19.255.0.0.0.0 0.1 0. De esta instalación se deduce que todas las listas estarán en las interfaces de lan de los .0.17.0 0.255.0 0.17.0.255 access-list 101 deny ip 172.0.0 0.0 0.255 172.1.0.0 0.16. la lista derouter2 la instalaría en la interfaz fa0/0 de entrada. se deben instalar de entrada lo más cerca posible del origen del tráfico a bloquear.0.3 any eq 23 access-list 101 permit ip 172.255.16.16.0.0.255 access-list 101 permit tcp 172.255.0.19.0.255 10.0.3 any Router4    access-list 101 permit ip 172.0 0.255 172.0.255.0.0.16.0.17.255.0.19.no permitido cruce la red innecesariamente.0 0.255.19.0.255.0.0. Para que las listas de acceso extendidas sean eficientes.16.0.19.255 access-list 101 deny ip 172.255. recuerde también que ésto último no se puede hacer con listas estándar porque ellas se tienen que instalar lo más cerca al destino.0.19.0 0.0.0.0.0.0.254 any access-list 101 deny tcp host 172.255 access-list 101 permit udp 172.0.0.255 eq 53 access-list 101 permit ip 172. La lista inicial quedaría así: Router2      access-list 101 permit ip 172.0.0.0 0.17.0.5 eq www access-list 102 deny host 172.0 0.255.254 any access-list 101 permit ip 172. La lista estándar que se ve en router2.255 172.

en otras palabras.0.0.0 0.17.0 que va hacia el servidor por UDP en el puerto 53. ¿cierto? Pues no.1. lo cual comprueba el resto de la ACL. Así que también falta una regla que permita el tráfico de DNS en ésta lista. Un buen ejemplo de lista de acceso bien aplicada es la que se aplica en el router2: sólo permite lo que debe permitir y bloquea cualquier otra cosa.3 que pensamos que ibamos a bloquear pasa por la primera regla (permitir IP impar concualquier destino). porque una regla permite cualquier tráfico desde ese PC hacia cualquier destino.1.255 10. no se examinan más cláusulas). Instalando la ACL del router2 vemos el primer problema: el tráfico de telnet desde la IP 172. Bueno.0.0. diferente del comando access-group <N> in de las interfaces ordinarias.255. . ya creo que queda claro lo que hay que hacer: comprobar exhaustivamente qué tráfico quedó permitido y qué tráfico bloqueado.0. Hacer el ejercicio Obviamente el ejercicio ya está resuelto.0. porque después de ejecutar la regla general de denegación (puesta antes de la específica) terminaría la ejecución de la lista de acceso (cuando se encuentra una correspondencia se aplica la acción y se deja de ejecutar la lista. la lista estándar se instala en la vty (acceso por telnet/ssh) del enrutador correspondiente con el comando access-class <N> in.0 incluso el tráfico de DNS.0 0.255 eq 53 Que se instala en el router1 corresponde con el tráfico proveniente de la red 172.17.0. Si yo incluyo una regla para denegar el resto del tráfico proveniente de la red de invitados hacia el servidor de esta manera:  access-list 101 deny ip 172.17.3 sí pasará. el tráfico de DNS proveniente de la red de invitados entra al servidor. una vez que se instalen las listas de acceso en las interfaces correctas.com pero para observar los detalles que nos pueden engañar. sin embargo habría que agregarle una regla que permita el acceso por telnet al enrutador.255 Esta regla incluye el tráfico permitido con la regla anterior.0 0. la más específica debería ir primero.0. por lo tanto debe ir antes en el listado.0 0. el archivo que dejo a disposición es un archivo de Packet Tracer con la topología propuesta y está configurada con conectividad total entre todas las estaciones.19.17.1.19. la lista no permite dns y por lo tanto nunca se sabrá la IP de example. la primera regla es más específica que la segunda.1. la política de seguridad estará en uso.0.com desde cualquiera de los PCs de la red de router2 hacia cualquier destino el ping es exitoso. por ejemplo la regla  access-list 101 permit udp 172.0. si una regla corresponde con cierto tráfico que se incluye en otra regla. Ponerlas en el orden inverso implicaría que siempre se denegaría el tráfico de la red 172.255 10.255. si probamos la lista en el PC 172. También hay que tener en cuenta que el orden de la lista tiene un efecto importantísimo en el filtrado de tráfico. si se dió cuenta del problema pasó la primera prueba.enrutadores correspondientes en la dirección de entrada. Si hacemos ping example. Finalmente.0.0. 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 también dejaré adjunta a la entrada. el permit deja pasar ese tráfico.

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 más difícil).Recuerde: las listas extendidas se deben instalar (excepto cuando definitivamente no es posible) de entrada en las interfaces más cercanas al origen del tráfico con el comando de modo de interfaz ip access-group <N> in. Lo anterior es una de las razones por las que el currículo de Cisco insiste en la documentación: hay que planificar concienzudamente lo que se desea y verificar exhaustivamente su cumplimiento. para bloquear el tráfico de una vty se usa el comando access-class <N> in. Conclusiones Las ACLs son complicadas porque no estamos acostumbrados a pensar en términos de clasificación de tráfico y a veces la comprobación debe ser muy minuciosa para poder determinar que todos los objetivos quedaron incluidos. .

Sign up to vote on this title
UsefulNot useful