cómo configurar acls

¿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

una copia del archivo de configuración 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 daño 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 catástrofes de éste tipo (cuando el IOS lo soporta), que consiste en establecer un timer de reinicio, 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).

Lo otro que hay que verificar Y DOCUMENTAR es el estado de la conectividad previa a la configuración. No perdamos el tiempo tratando de arreglar lo que esté malo (a menos que sea nuestra responsabilidad directa), sólo documentemos cómo está, haciendo unos pings selectos y unos telnets que muestren qué se podía hacer antes de la instalación 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 configuración correcta de las lineas de vty en el equipo al que apuntamos).

Política de seguridad de ejemplo

Ya descrita la topología, creemos una política 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 sólo 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, sólo 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 ningún enrutador por ningún medio.

6. Cualquier tráfico no contemplado debe ser bloqueado.

Lo anterior hay que ponerlo en términos de filtrado de tráfico con ACLs. El servidor tiene la dirección IP 10.1.1.1, 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.1.1.1. Una regla de ACL que coincida con el servidor sería host 10.1.1.1, 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. El tráfico proveniente de los PCs de la red de Router1 tiene el patrón 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 máscara wilcard dice que lo que esté en 1 lo ignore, no lo compare con la dirección de referencia, en otras palabras, la mezcla de dirección de referencia con máscara wildcard se podría escribir 172.16.X.X, 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). El patrón de tráfico que identifica las direcciones impares es′ el siguiente 0.0.0.1 255.255.255.254, 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). Como ejemplo adicional, si quisiéramos condicionar el tráfico de cualquier red pero sólo para las direcciones pares sólo habría que poner 0.0.0.0 255.255.255.254, regla que se cumpliría sólo para los paquetes que tengan un 0 en su último bit. 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.19.0.0 0.0.255.255 y PC5 host 172.19.0.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. 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- listas extendidas), todas las condiciones que mencioné en el párrafo anterior se deben aplicar a las direcciones origen de los paquetes, porque las acls estándar sólo permiten filtrar por dirección IP origen.

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, el problema es qué tan difícil sea configurar todo ésto. Primero intentaremos con listas estándar. El orden de las listas afecta el resultado, por lo tanto hay que poner las más restrictivas primero y luego las más generales, además hay que seleccionar dónde ponerlas. Para las listas estándar, la ubicación debe ser lo más cercano posible del destino, por lo tanto para el tráfico que se dirige al servidor lo más cercano al destino es su enrutador, 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. origen). Esa es la mejor opción, otras opciones serían en las otras interfaces de salida, pero probablemente sea necesario ponerlas en todas las interfaces.

Me alargaría demasiado si explico cada regla, pero yo creo que queda claro con la elección de la lista del servidor, así que voy a escribir el listado y la ubicación:

Política 1:Router0, fa 0/0 outaccess-list 1 permit 172.16.0.0 0.0.255.255access-list 1 permit 172.19.0.0 0.0.255.255

Política 2:Router4, ser 0/0/0, in

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

Router2, ser 0/0/0, inaccess-list 1 deny 172.17.0.0 0.0.255.255access-list 1 permit any

Router3, ser 0/0/0, inaccess-list 1 permit 172.17.0.0 0.0.255.255

Política 3:Router3, ser 0/0/0, inaccess-list 1 permit 172.17.0.0 0.0.255.255access-list 1 permit 0.0.0.1 255.255.255.254

Política 4:Router4, ser 0/0/0, inaccess-list 1 deny 172.17.0.0 0.0.255.255access-list 1 permit 172.19.0.0 0.0.255.255

Router2, ser 0/0/0, inaccess-list 1 deny 172.17.0.0 0.0.255.255access-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.255access-list 2 permit 172.16.0.0 0.0.255.255access-list 2 permit 10.0.0.0 0.255.255.255

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

Política 6:Todas las listas de acceso terminan en un deny implícito, es recomendable usar un deny any explícito para poder llevar control de cuántos paquetes son filtrados por ésta última regla.

Adicionales:1) Dado que las listas escritas también bloquean el protocolo de enrutamiento, una vez instaladas las listas anteriores, las tablas de enrutamiento se empiezan a dañar (faltan rutas), se pierde la conectividad y la convergencia de la red. Por lo anterior, hay que permitir el tráfico que provenga

de los enrutadores, en las interfaces habría que poner una regla como éstaaccess-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 telnetsaccess-list 1 permit 10.0.0.0 0.255.255.255

2) Con las listas propuestas, el tráfico 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 tráfico proveniente de internet no tiene un patrón de direcciones IP origen, por lo tanto la única regla que permitiría el tráfico de internet sería permit any, lo cual violaría la política de bloquear cualquier otro tráfico.

3) No hay forma de permitir el tráfico desde la red de invitados hacia el servidor sólo para web, dns y tftp. Si sólo hubiera la opción de usar listas estándar, habría 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.

Según las consideraciones anteriores, las listas de acceso serían:

Router0, fa 0/0 outaccess-list 1 permit 172.16.0.0 0.0.255.255access-list 1 permit 172.19.0.0 0.0.255.255

Router3, ser 0/0/0, inaccess-list 1 permit 172.17.0.0 0.0.255.255access-list 1 permit 0.0.0.1 255.255.255.254access-list 1 permit 10.0.0.0 0.255.255.255access-list 1 deny any

Router4, ser 0/0/0, inaccess-list 1 deny 172.17.0.0 0.0.255.255access-list 1 permit any

Router2, ser 0/0/0, inaccess-list 1 deny 172.17.0.0 0.0.255.255access-list 1 permit any

Router0, Router1, Router2, Router3 y Router4 en las vty.access-list 2 permit 172.19.0.0 0.0.255.255access-list 2 permit 172.16.0.0 0.0.255.255access-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 líneas vty se usa el comando access-class N in/out.

Conclusiones

Las ACLs estándar tienen una potencia limitada, pero en ciertos casos puede ser necesario usarlas. Las ACLs estándar 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 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. La próxima entrada será la misma política, pero implementada con listas extendidas. Si ya comprenden el tema, vayan trabajandolo a ver si coincide con mi propuesta (o es mejor).

¿Cómo configurar ACLs?: problema/ejercicio completo con ACLs extendidas

En ésta entrada, continúo con el ejemplo de uso de ACLs en un ejercicio completo con visos de realismo, la vez pasada configuramos una red con ciertas políticas de seguridad usando sólo ACLs estándar, ahora vamos a hacer el mismo ejercicio usando listas extendidas. Disfrútenlo.

Para retomar el ejercicio, recordemos la topología de ejemplo. Tenemos una topología 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 dirección 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 (sólo uno) y finalmente simulamos el acceso a internet con la red del extremo derecho superior. Hay pequeños cambios respecto a la topología 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 configuración 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 dirección del servidor mismo. Para hacer éste ejercicio use la topología 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.

Política de seguridad de ejemplo

La política 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 sólo 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, sólo 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 ningún enrutador por ningún medio.

6. Cualquier tráfico no contemplado debe ser bloqueado.

Ahora vamos a intentar poner ésta política en términos 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 estándar, por ejemplo, no se puede permitir sólo el tráfico de DNS la red de invitados hacia el servidor, lo cual es un requerimiento implícito: el servidor también es responsable por DNS, por lo tanto para poder hacer operaciones con dominios (como ping example.com), antes de hacer ping entre la estación yexample.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.18.0.1). Ya con la experiencia de la entrada anterior, sabemos que hay otros requerimientos implícitos que hay que considerar antes de implementar, por ejemplo, como las listas de acceso terminan por defecto con un deny any, es probable que tráfico necesario, como las actualizaciones de enrutamiento entre los enrutadores, sea bloqueado por defecto y, como nuestro foco de atención son las políticas de seguridad, nos resulte difícil deducir ese resultado inesperado o peor aún, 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), pero la razón del “bloqueo” es que el enrutamiento se cayó totalmente, por lo tanto el tráfico que queríamos bloquear ya no pasa pero tampoco pasará ningún otro. Eso hay que verlo haciendo el ejercicio de la entrada anterior.

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, se pueda restaurar el estado de operación inicial de la red con sólo restaurar la configuración y reiniciar algún equipo. Así podemos resolver sin presiones el problema o, mejor aún, simularlo.

Configuración con listas extendidas

Una ventaja de las listas extendidas es que, aparte de permitir más granularidad a la hora de definir los criterios de selección de tráfico, son mucho más flexibles para su implementación, por ejemplo, usualmente podemos configurar con listas extendidas todo en un sólo enrutador, mientras que con listas estándar esa opción 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 razón es que una distribución eficiente de las listas de acceso ayuda a evitar tráfico innecesario. Recuerde que las listas de acceso extendidas se instalan de entrada en el enrutador más cercano al origen del tráfico, eso evita que el enrutador haga búsquedas en la tabla de enrutamiento para los paquetes bloqueados y evita que el tráfico

no permitido cruce la red innecesariamente, 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, es decir, después de que ocuparon ancho de banda en la red y procesamiento en los enrutadores y dispositivos intermedios.

La lista inicial quedaría 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 políticas se cumplen en cada enrutador.

La lista estándar 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 más cerca posible del origen del tráfico a bloquear, por lo tanto, la lista derouter2 la instalaría en la interfaz fa0/0 de entrada, de tal manera que el tráfico bloqueado ni siquiera implique enrutar esos paquetes en ese enrutador. De esta instalación se deduce que todas las listas estarán en las interfaces de lan de los

enrutadores correspondientes en la dirección de entrada. Finalmente, la lista estándar 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. 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 una regla corresponde con cierto tráfico que se incluye en otra regla, la más específica debería 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 tráfico proveniente de la red 172.17.0.0 que va hacia el servidor por UDP en el puerto 53, el permit deja pasar ese tráfico, en otras palabras, el tráfico de DNS proveniente de la red de invitados entra al servidor. 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.0.0 0.0.255.255 10.1.1.0 0.0.0.255

Esta regla incluye el tráfico permitido con la regla anterior, la primera regla es más específica que la segunda, por lo tanto debe ir antes en el listado. Ponerlas en el orden inverso implicaría que siempre se denegaría el tráfico de la red 172.17.0.0 incluso el tráfico de DNS, 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, no se examinan más cláusulas).

Hacer el ejercicio

Obviamente el ejercicio ya está resuelto, 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, una vez que se instalen las listas de acceso en las interfaces correctas, la política de seguridad estará en uso. Instalando la ACL del router2 vemos el primer problema: el tráfico 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 engañar, si probamos la lista en el PC 172.19.0.3 sí pasará, porque una regla permite cualquier tráfico desde ese PC hacia cualquier destino. Así que también falta una regla que permita el tráfico de DNS en ésta lista.

Bueno, ya creo que queda claro lo que hay que hacer: comprobar exhaustivamente qué tráfico quedó permitido y qué tráfico 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 también dejaré adjunta a la entrada. 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, sin embargo habría 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 más cercanas al origen del tráfico con el comando de modo de interfaz ip access-group <N> in, 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. 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. 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).