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

Redes de Datos / / 27 comentarios / Por
Spread the love

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, 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 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.

topologiaacls2

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 y example.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 de router2 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).

[Topologia acl][ACLs solución]

]]>

27 comentarios en “¿Cómo configurar ACLs?: problema/ejercicio completo con ACLs extendidas”

  2. cesar adrian

    hola muchas gracias por ofrer este tipo de informacion la verdad lo desvara uno de problemas que se presenta en mi caso personal no sabia como poner un servidor como servidor web para las resdes muchas gracias ahora pues yo no he podido hacer lo siguiente

    permitir un que un computar de una lan puede acceder al servidor web con el dns http://www.example.com pero al momento acceder solo con la ip no lo pueda lograr es esto posible ??? con una acl

    Responder
  3. César

    Hola César,

    gracias por el comentario.

    Con lo de CCNA es un poco complicado, sin embargo, yo creo que es posible crear una ACL reflexiva partiendo de DNS pero abriendo también TCP y denegando el resto, eso haría que DNS disparara la ACL pero abriera TCP, siendo ésta la única forma de abrir la conexión (desde adentro de la red).

    Lo que acabo de describir es sólo una especulación, inténtalo a ver si se puede.

    Gracias y hasta pronto.

    P.D.: ¿No será que entendiste mal la pregunta? Que sólo se pueda con la IP pero no con DNS.

    Responder
  4. Luis

    Muy buenas Cesar, antes de nada darte las gracias, con articulos asi es mas facil enterarnos para los que estamos involucrandonos en el tema de redes (mi caso CCNA). Estoy haciendo una practicas de ACL con el packet dandole mil vueltas y no consigo que me la de como completada al 100% (se queda en un 97%).
    Te cuento mas o menos lo que me pide:
    R1——[serial0/0/0] a R2 [serial 0/0/1]——–enlace serial a R3.

    Complete los siguientes requisitos mediante las ACL extendidas en R2:
    Nombre a la ACL block.
    Prohiba que el tráfico que se origina desde las subredes conectadas de
    R1 alcance las subredes conectadas de R3.
    Prohiba que el tráfico que se origina desde las subredes conectadas de
    R3 alcance las subredes conectadas de R1.
    Permita todo el tráfico restante
    Subred R1 10.1.1. 0 /24
    Subred R3 10.3.1. 0 /24

    La configuracion que he ingresado es:

    R2(config)#ip access-list extended block
    R2(config-ext-nacl)#deny ip 10.1.1. 0 0.0.0. 255 10.3.1. 0 0.0.0. 255
    R2(config-ext-nacl)#deny ip 10.1.1. 0 0.0.0. 255 10.3.1. 0 0.0.0. 255
    R2(config-ext-nacl)#permit ip any any
    R2(config-if)#ip access-group block in (serial 0/0/0)
    R2(config-if)#ip access-group bock in (serial 0/0/1)

    Se que hay mas de un fallo xq no es normal asignar la misma acl a dos

    interfaces diferentes , pero no se dar con el problema. Gracias de

    antemano.

    Responder
  7. César

    Hola Andrés,

    por defecto los enrutadores no tienen contraseñas, en los laboratorios de las academias de Cisco las contraseñas siempre son cisco o class

    Espero que te sirva, si no estás en una academia tendrás que preguntarle la contraseña al administrador.

    Gracias y hasta pronto.

    Responder
    1. César

      Hola Byron,

      qué buena pregunta. Una forma fácil de hacerlo es usando acls extendidas y aprovechando que en vez de IP podrías poner ICMP y al final de las direcciones origen/destino puedes poner qué mensajes de icmp quieres bloquear/permitir, por ejemplo echo y echo-reply.

      Gracias por el comentario y hasta pronto.

      Responder
  9. kernel346

    access-list 101 permit ip 172.19.0.1 0.0.255.254 any

    esta regla en el r2 permite que un host de la red 172.129.0.0 impar se conecte a cualquier host ,no especifica que sea a internet , cuando el objetivo es permitir acceso web aolo a los impares,,explicame como se cumple esa condicion

    Responder
    1. César

      Hola Kernel346,

      pues si lees cuidadosamente la entrada, al final propone una especie de reto que consiste precisamente en eso: detectar las fallas que tienen las ACLs y corregirlas. No te puedo contestar las preguntas que haces porque quedaría resuelto el reto, pero ahí te queda 🙂

      Gracias y hasta pronto.

      Responder
  11. noemi

    Tengo una duda sobre ACL’s y quisera ver si me la puedes resolver. Tengo un grupo de ACLs que me bloquean el communicator, que es como el msn. Mi access list dice asi:
    access-list 110 permit tcp any range 3000 5000 any
    access-list 110 permit tcp any any range 3000 5000

    Mi duda es que, con propositos de disminuir eltamaño del codigo, ¿seria valido hacer esto:
    access-list 110 permit tcp any range 3000 5000 any range 3000 5000

    Responder
  12. servitel

    Muy bueno el ejercicio, pero no me sirve, ya que lo que busco es un ejercicio bien hecho para poder encontrar el error que tengo y que packet no me arroja el 100%, por tener mas de una instrucción en la ACL no sé cuál de ellas es correcta y cuál no. Gracias de todas maneras.

    Responder
    1. César

      Ok, Servitel, lamento que no te sirva. Te recomiendo que hagas las pruebas y cotejes el tráfico que generes contra la salida del comando access-list en el enrutador en el cual quieres hacer la verificación. Cada vez que veas un incremento en los matches significa que un paquete sufrió la acción de esa regla particular (permit/deny). Si no pasa nada es porque efectivamente todos los paquetes estarán siendo negados por la ACL, para más claridad agrega una regla explícita deny any a final.

      Gracias y hasta pronto.

      Responder
  13. laura

    hola cesar bueno e estado revisando tu blog y esta muy bien la verdad es k m esta sirviendo mucho ya que en la escuela me estan pidiendo una investigacion sobre este tema de las ACLS cres k m puedas ayudar un poco mas a crear una acl para una pequeña empresa

    Responder
  14. Carlos

    Hola Cesar, Realmente es muy Buen Ejercicio, muy Explicativo y Completo.
    Quisiera Hacerte una pregunta? me dejaron que bloqueara el acceso solo las direcciones pares, que solo permitiera acceso a direcciones impares, me podrías ayudar a como hacer eso?

    Responder
    1. Ricardo

      Carlos, lo unico que tienes que hacer es colocar tu wildcard 0.0.0.254, asi eliminas el primer bit y por ende solo los numero imoares tendran acceso

      Responder
  15. Fátima

    Hola!! primeramente muchas gracias por esta informacion, me há quitado algunas dudas respecto a las acl’s, pero tengo um problema al momento de planificar las reglas de seguridad para mi pequeña red (un trabajo de la universidad) no se como definirlas para posteriormente crear las lista. algun consejo? gracias de antemano

    Responder
    1. César

      Hola Fátima,

      el consejo es que definas primero te asegures de que la red tiene conectividad plena antes de instalar las acls, luego definas en qué dispositivo y sentido (entrada/salida) las vas a poner, luego definas el tráfico que quieres controlar con base en sus direcciones IP origen/destino o incluso protocolo y finalmente las crees en un editor de texto plano. Ve metiendo los comandos por partes (digamos primero la creación de las ACLs, luego la instalación) y verifica cada una de las políticas independientemente. Recuerda que el comando show access-lists muestra la cantidad de paquetes que han sido filtrados o pasados por una regla específica.

      Gracias y hasta pronto.

      Responder
  18. rkm

    oye cual estu secreto para definir tan bien las acls sincermante leo y leo pero no logro tomarle el ritmo … y sinceramente me preocupa :,(

    Responder
    1. César

      Hola Brayan,

      los múltiplos de 4 están fáciles: escribelos en decimal y al lado el binario. Te darás cuenta inmediatamente qué patrón siguen. Los múltiplos de 5 no sé.

      Gracias y hasta pronto.

      Responder

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.