¿Cómo configurar ACLs?: problema/ejercicio completo ACLs estándar

¿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 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 Política 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 Política 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 Política 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 Política 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 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 é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 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 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 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). P.D.: Esta entrada la empecé a escribir, la dejé programada pero se me olvidó y se publicó incompleta. Me tocó terminarla rápidamente porque ya me ha pasado antes y me da pena que aparezcan y desaparezcan entradas, así que si hay muchos errores me perdonarán. Ahí la iremos corrigiendo.]]>