¿Cómo funcionan las ACLs? III: ACLs extendidas

Spread the love

Después de revisar los conceptos de las Listas de Control de Acceso (ACL) y las ACLs estándar, llegó la hora de examinar el funcionamiento de las ACL extendidas y su configuración.
NOTA: Finalmente, escribí 5 entradas completas sobre ACLs a manera de Tutorial, se las recomiendo.

Características de las ACL estándar: poca granularidad

Antes de comentar las cualidades de las ACL extendidas (extended ACL) debemos recordar las ACL estándar y ver qué diferencia funcionan tienen las extendidas respecto a las primeras, es decir, para valorar los beneficios de las extendidas. La idea de las ACLs estándar es filtrar tráfico con base en las direcciones origen de los paquetes que entran o salen de una interfaz, aquella en la que se instala la ACL. Lo anterior implica un nivel básico de filtrado: direcciones IP origen de todos los paquetes interceptados, para ilustrarlo con un ejemplo, digamos que deseamos filtrar el tráfico proveniente de la red 192.168.1.0/26, pero que de esa red queremos permitir un host en particular y las demás redes diferentes deberían pasar.

A éstas alturas tenemos muy claro que las ACLs son conjuntos de reglas con un identificador común y que las reglas aplican una acción a los paquetes que cumplan una condición que, en el caso de las ACL estándar, es que tengan la dirección origen coincidente con la dirección de referencia. La ACL que filtra el tráfico como se solicita (bloquear 192.168.1.0/26, permitir un host 192.168.1.1 y permitir paquetes de cualquier otra subred) creamos la siguiente ACL:

  • access-list 1 permit 192.168.1.1 0.0.0.0
  • access-list 1 deny 192.168.1.0 0.0.0.63
  • access-list 1 permit any

En efecto, cada vez que llegue un paquete se compararán las direcciones IP origen de cada uno con cada una de las reglas de la lista de acceso, si el paquete corresponde con alguna, se aplica la acción (permit o deny) y no se compara con ninguna otra regla. En este caso, la regla permite primero el host, luego niega la red y finalmente permite cualquier otra cosa.

La acl descrita significa que todo el tráfico del host particular se va a permitir, no se puede bloquear un tráfico específico que provenga del host, se deniega o se permite todo el tráfico y sería deseable bloquear sólo una porció de su tráfico, algo de lo que hace éste host en caso de ser necesario. Para la red también sucede lo mismo: si se pudiera bloquear sólo el tráfico que sale de esa red a un destino específico sin bloquear todo el tráfico con origen en esta red sería mucho mejor. Ese es el problema que resuelve la ACL extendida.

ACLs extendidas

A diferencia de lo que sucede con la ACL estándar, las extendidas permiten especificar hacia dónde se dirige el tráfico y con ésta característica, yo puedo bloquear o permitir un tráfico mucho más específico: sólo tráfico que proviene del host pero se dirige a una red en particular o a otro host en particular o sólo el tráfico de una red que se dirige a otra red en particular. El truco se logra con el hecho de permitir comparar las direcciones destino de los paquetes contra la acl, no sólo las direcciones origen. Dentro de lo que hemos venido manejando, hablamos que una acl está compuesta por un conjunto de reglas todas con el mismo identificador, que cada regla era una línea compuesta por una acción y una condición que el paquete debe cumplir para aplicarle la acción (permitir o denegar). Las condiciones en las acl estandar están compuestas por una dirección de referencia y una wildcard que dice qué bits de la dirección origen de los paquetes se deben comparar con la dirección de referencia, en las acls extendidas se especifica dos pares de direcciones de referencia/wildcard, un par para la dirección origen de los paquetes y otro par para la dirección destino de los mismos. Vamos a extender el ejemplo que venimos usando y usar ésta idea de filtrado más granular.

El requisito dado es permitir un host de una red, el resto de la red la vamos a bloquear y cualquier otra red la vamos a permitir. Para extender el ejemplo digamos que queremos permitir el tráfico del host, excepto lo que vaya a un host particular, digamos el 172.16.1.1, y que de la red completa queremos permitir lo que vaya a un servidor en especial de la empresa, digamos el 192.168.2.1. Las reglas de la acl estandar nos sirven de inicio, como de costumbre lo más específico lo vamos a poner de primero en la regla para evitar que las reglas más generales incluyan a las particulares.

  • access-list 100 deny ip 192.168.1.1 0.0.0.0 172.16.1.1 0.0.0.0
  • access-list 100 permit ip 192.168.1.1 0.0.0.0 0.0.0.0 255.255.255.255
  • access-list 100 permit ip 192.168.1.0 0.0.0.63 192.168.2.1 0.0.0.0
  • access-list 100 deny ip 192.168.1.0 0.0.0.63 0.0.0.0 255.255.255.255
  • access-list 100 permit ip any any

En ésta lista observamos varias cosas nuevas: ip, las acl extendidas no sólo permiten especificar las direcciones origen y destino sino discriminar por protocolos e incluso por parámetros particulares de cada protocolo pero eso lo veremos luego, por lo pronto lo importante es que ip indica que todos los protocolos que se encapsulan dentro de ip serán afectados por ésta lista de acceso. En este caso, la palabra ip para los protocolos es similar a any en las direcciones, casi todo se encapsula en ip por lo tanto especificar ip es como especificar cualquier protocolo (de capa 4 en adelante). En vez de ip se puede poner un protocolo equivalente o de capa 4, por ejemplo se puede filtrar icmp, tcp o udp, cambiando la palabra ip por éstas últimas.

Otra cosa importante y nueva es un segundo par de dirección de referencia/máscara wildcard, éste segundo par compara la dirección destino de los paquetes con la dirección de la regla. Para las acls extendidas, el paquete debe coincidir tanto en la dirección origen como en la destino.

Finalmente, la dirección de referencia 0.0.0.0 con máscara wildcard 255.255.255.255. Como esta máscara es todo unos, eso significa que ningún bit del paquete se compara con la dirección de referencia, es decir, no importa qué escriba en la dirección de referencia cualquier destino coincide. Esta máscara es lo mismo que any, debido a que la máscara es equivalente a cualquier dirección y puede usarse tanto para el origen como para el destino.

Explicación de la ACL

La primera regla aplica deny sólo si el paquete tiene como origen la dirección 192.168.1.1 y dirección destino 172.16.1.1, por lo tanto sólo el tráfico específico de entre esos host se deniega, la segunda regla permite el resto del tráfico del host hacia cualquier destino. La tercera regla permite el tráfico de la red 192.168.1.0/26 hacia el host 192.168.2.1. La 4a regla complementa a la anterior y niega todo el tráfico de la red, como ésta regla general esta después de la específica, el tráfico comparado con ésta regla ya no coincidió con el tráfico dirigido al servidor, que es una condición más específica dentro de la misma red. Finalmente cualquier tráfico que no coincida con las reglas anteriores se permite sin importar de dónde provenga y hacia dónde vaya.

¿Qué más?

Finalmente y para no dejar incompleto el ejemplo, hay que instalarla en una interfaz por la que pase el tráfico que se quiere interceptar y recordar que el sentido en el que se instala la acl, indica cuáles serán las direcciones origen y destino (que se invierten si se invierte el sentido del tráfico).

  • interface serial 0/0
  • ip access-group 100 in

Las listas de acceso extendidas no difieren de las estándar más que en las características mencionadas, por lo tanto los comandos usados para verificar las estándar siguen siendo válidos.

  • show ip interface serial 0/0
  • show ip access-list

Conclusión





Las acls extendidas son mucho más eficientes en el filtrado que las acls estándar, pero como ya he mencionado en otras entradas, las acls son mecanismos de clasificación de tráfico y direcciones y hay algunas aplicaciones que se corresponden mejor con las acl estándar que con las extendidas, por lo tanto se siguen usando tanto como las extendidas.

Sigan pendientes que todavía falta más sobre acls: acls complejas y ejemplos verificables.

20 comentarios en “¿Cómo funcionan las ACLs? III: ACLs extendidas”

  1. Que tal Cesar…

    veo que eres un entendido en la materia, necesito que me ayudes con un ejercicio de acl estandar….al parecer es sencillo, pero te soy sincero le he dado muchas vueltas y no lo consigo realizar

    te planteo el escenario: tengo dos router(A y B) conectados entre si por puerto serial, en el router (A), tengo conectado un host a la FA0/0, en el router (B), tengo conectado un server a la FA0/0. el ejercicio me pide lo siguieente:
    1.- bloquear el trafico (ping), desde el host al Server…(este paso ya lo realice y no tengo problema)
    2.- permitir el trafico (ping) desde el server al host (aqui tengo problema), como estuve leyendo en tu blog, el trafico cambia de direccion y esto origina que el host sea origen y el server destino en el primer caso, y la acl la cree en el router (B).

    PERO EN EL 2DO CASO EL SERVER ES ORIGEN Y EL HOST DESTINO, Y AL YA HABER UNA ACL EN EL ROUTER (B),QUE BLOQUEA EL TRAFICO DEL HOST EN ESTE CASO DESTINO EL PAQUETE NO SE COMPLETA. COMO DE BERIA CONFIGURAR LAS ACLS, PARA QUE AMBOS CASOS SE CUMPLAN….

    TE AGRADECERIA MUCHO SI ME AYUDAS CON ESTE EJERCICIO…

    SALUDOS

  2. Buenas Cesar, 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)

  3. Hola Luis,

    en mis clases acostumbro decirles que no se fijen en los porcentajes del PT porque a veces hay pequeños errores que impiden lograr el 100%, por ejemplo cuando el nombre de la VLAN en la actividad y el en PDF es en español pero el PT sólo aumenta % si se escribe en inglés.

    Sobre tu caso te recomiendo que revises lo siguiente:
    * Recuerda verificar conectividad antes de instalar la ACL, no sea que antes de instalarla ya tuvieras un problema de conectividad (p. ej.: enrutamiento)
    * Listas de acceso extendidas se instalan lo más cerca del origen, que sería la interfaz de entrada del enrutador directamente conectado a la fuente o la serial del enrutador de la mitad si no puedes hacerlo en los otros.
    * Recuerda que la dirección de la ACL determina cuál red es origen y cuál destino, entonces cuando pones la misma acl tanto de entrada como de salida una puede que sirva pero la otra no.
    * Puedes usar show ip access-list para ver cuántos paquetes se han correspondido con cada regla de la ACL.

    Ojalá te sirva, gracias y hasta pronto.

  4. Hola Cesar, gracias por tu respuesta, recuerdo tambien a ver tenido ese problema con la creacion de las vlan. Al iniciar la practica intento ir siempre paso por paso, incluyo en esto en como afectaba a la red cada ACL que ingreso. Incluso despues de ingresar estas dos ACL que te comento, aparentemente bloquea el trafico como me piden. Pero la cuestion es que quizas exista otra forma de crear la ACL para filtrar el trafico que me piden y esa es la ACL que quieren que ingrese. Nose si me he explicado bien. Estoy preparando el CCNA y quiero tenerlo todo bastante entendido y desarrollado, gracias.

    1. Hola Inés,

      gracias por el comentario tan favorable, espero que siga encontrando cosas interesantes por acá y que lo recomiende a quienes estén interesados(as).

      Hasta pronto.

  5. Hola saludos estoy empezando a estudiar lo que son las ACLs y tengo una duda se pueden aplicar varias ACLs en un mismo sentido. Por ejemplo: tengo estas dos ACLs Politica1 y Politica2 y las quiero en la interfaz 0/0 en sentido in.

    Router(config)#interface fastEthernet 0/0
    Router(config-if)#ip access-group Politica1, Politica2 in

    Se puede hacer o no? gracias de antemano

  6. Hola Cesar…

    Necesito que me ayudes con un ejercicio de acl Extendida…

    te planteo el escenario: tengo dos router(A y B) conectados entre si por puerto serial, en el router (A), tengo conectado un host a la FA0/0, en el router (B), tengo conectado un server a la FA0/0. el ejercicio me pide lo siguiente:
    1.- bloquear el trafico (ping), desde el host al Server…(este paso ya lo realice y no tengo problema)
    2.- permitir el trafico (ping) desde el server al host (aqui tengo problema), como estuve leyendo en tu blog, el trafico cambia de direccion y esto origina que el host sea origen y el server destino en el primer caso, y la acl la cree en el router (B).

    PERO EN EL 2DO CASO EL SERVER ES ORIGEN Y EL HOST DESTINO, Y AL YA HABER UNA ACL EN EL ROUTER (B),QUE BLOQUEA EL TRAFICO DEL HOST EN ESTE CASO DESTINO EL PAQUETE NO SE COMPLETA. COMO DE BERIA CONFIGURAR LAS ACLS, PARA QUE AMBOS CASOS SE CUMPLAN….

    TE AGRADECERIA MUCHO SI ME AYUDAS CON ESTE EJERCICIO…

    SALUDOS

    1. Hola Francis,

      en tu caso deberías usar una ACL extendida, esas permiten poner tanto IP origen como destino. Creo que con eso se solucionaría tu problema. Adicionalmente, debes recordar que el orden de las reglas importan: pon las más específicas al inicio (un host o una porción de una red) y las más generales al final (una red completa o el comportamiento por defecto de la ACL).

      Espero te sirva y disculpa que no contesté rápido.

      Gracias y hasta pronto.

Responder a mario pulgarin Cancelar respuesta

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.