Solución de Problemas de ACL

Se explica cómo solucionar problemas en las ACL estándar IPv4 en un router Cisco como parte de una solución de seguridad. Se incluyen consejos y recomendaciones.

1. Deny any implícita

Una ACL de entrada única con solo una entrada de denegación tiene el efecto de denegar todo el tráfico. Se debe configurar al menos una ACE permit en una ACL. En caso contrario, se bloquea todo el tráfico.

ACL 1

R1(config)# access-list 1 permit ip 192.168.10.0 0.0.0.255

ACL 2

R1(config)# access-list 2 permit ip 192.168.10.0 0.0.0.255
R1(config)# access-list 2 deny any

Para la red en la ilustración, si se aplica la ACL 1 o la ACL 2 a la interfaz S0/0/0 del R1 en el sentido de salida, se obtiene el mismo resultado. A la red 192.168.10.0 se le permite acceder a las redes a las que puede llegar mediante S0/0/0, mientras que a 192.168.11.0 no se le permite acceder a esas redes. En la ACL 1, si un paquete no coincide con la instrucción de permit, se descarta.

2. El orden de las ACE en una ACL

El IOS de Cisco aplica una lógica interna al aceptar y procesar las ACE estándar. Como se mencionó anteriormente, las ACE se procesan de forma secuencial; por lo tanto, el orden en que se introducen las ACE es importante.

Por ejemplo, en el siguiente código, la ACL 3 contiene dos ACE. La primera ACE utiliza una máscara wildcard para denegar un rango de direcciones que incluye todos los hosts en la red 192.168.10.0/24. La segunda ACE es una instrucción que examina un host específico, 192.168.10.10, que pertenece a la red 192.168.10.0/24. La lógica interna del IOS para las listas de acceso estándar rechaza la segunda instrucción y envía un mensaje de error, porque es un subconjunto de la instrucción anterior.

R1(config)# access-list 3 deny 192.168.10.0 0.0.0.255
R1(config)# access-list 3 permit host 192.168.10.10
% Access rule can't be configured at higher sequence num as it is part of the existing rule at sequence num 10
R1(config)#

La configuración siguiente de la ACL 4 tiene las mismas dos instrucciones, pero en orden inverso. Esta es una secuencia válida de instrucciones, porque la primera instrucción se refiere a un host específico, no a un rango de hosts.

R1(config)# access-list 4 permit host 192.168.10.10 
R1(config)# access-list 4 deny 192.168.10.0 0.0.0.255
R1(config)#

Por último, la ACL 5 muestra que se puede configurar una instrucción de host después de una instrucción que denota un rango de hosts. El host no debe estar dentro del rango que abarca una instrucción anterior. La dirección host 192.168.11.10 no forma parte de la red 192.168.10.0/24, por lo que se trata de una instrucción válida.

R1(config)# access-list 5 deny 192.168.10.0 0.0.0.255
R1(config)# access-list 5 permit host 192.168.11.10
R1(config)#

3. El IOS reordena las ACL estándar

Es posible que el orden en que se introducen las ACE estándar no sea el orden en que se almacenen, se muestren o se procesen en el router.

En el siguiente código, se muestra la configuración de una lista de acceso estándar. Las instrucciones de rango que deniegan tres redes se configuran primero, y después se configuran cinco instrucciones de host. Las instrucciones de host son todas instrucciones válidas, porque sus direcciones IPv4 host no forman parte de las instrucciones de rango introducidas previamente.

R1(config)#access-list1deny192.168.10.00.0.0.255
R1(config)#access-list1deny192.168.20.00.0.0.255
R1(config)#access-list1deny192.168.30.00.0.0.255
R1(config)#access-list1permit10.0.0.1
R1(config)#access-list1permit10.0.0.2
R1(config)#access-list1permit10.0.0.3
R1(config)#access-list1permit10.0.0.4
R1(config)#access-list1permit10.0.0.5
R1(config)#end
R1#show running-config|includeaccess-list1
access-list1permit10.0.0.2
access-list1permit10.0.0.3
access-list1permit10.0.0.1
access-list1permit10.0.0.4
access-list1permit10.0.0.5
access-list1deny  192.168.10.00.0.0.255
access-list1deny  192.168.20.00.0.0.255
access-list1deny  192.168.30.00.0.0.255

El comando show running-config se utiliza para verificar la configuración de la ACL. Observe que las instrucciones se enumeran en un orden distinto al orden en que se introdujeron. Utilizaremos el comando show access-lists para comprender la lógica detrás de esto.

3.1. Números de secuencia después de la recarga

Como se muestra en el siguiente código, el comando show access-lists muestra las ACE junto con sus números de secuencia. Sería de esperar que el orden de las instrucciones en el resultado reflejara el orden en que se introdujeron. Sin embargo, el resultado de show access-lists muestra que este no es el caso.

R1# show access-lists 1
Standard IP access list 1
50 permit 10.0.0.2
60 permit 10.0.0.3
40 permit 10.0.0.1
70 permit 10.0.0.4
80 permit 10.0.0.5
10 deny192.168.10.0, wildcard bits 0.0.0.255
20 deny192.168.20.0, wildcard bits 0.0.0.255
30 deny192.168.30.0, wildcard bits 0.0.0.255
R1# copy running-config startup-config
R1# reload
R1# show access-lists 1
Standard IP access list 1
10 permit 10.0.0.2
20 permit 10.0.0.3
30 permit 10.0.0.1
40 permit 10.0.0.4
50 permit 10.0.0.5
60 deny 192.168.10.0, wildcard bits 0.0.0.255
70 deny 192.168.20.0, wildcard bits 0.0.0.255
80 deny 192.168.30.0, wildcard bits 0.0.0.255

El orden en que se enumeran las ACE estándar es la secuencia utilizada por el IOS para procesar la lista. Observe que las instrucciones se agrupan en dos secciones: las instrucciones de host seguidas por las instrucciones de rango. El número de secuencia indica el orden en que se introdujo la instrucción, no el orden en que se procesará.

Las instrucciones de host se enumeran primero, pero no necesariamente en el orden en que se introdujeron. El IOS ordena las instrucciones de host mediante una función de hash especial. El orden resultante optimiza la búsqueda de una entrada de ACL de host. Las instrucciones de rango se muestran después de las instrucciones de host. Estas instrucciones se enumeran en el orden en que se introdujeron.

Recuerde que las ACL estándar y numeradas se pueden editar con números de secuencia. Cuando se introduce una nueva instrucción de ACL, el número de secuencia solo afecta a la ubicación de una instrucción de rango en la lista. Las instrucciones de host siempre se ordenan con la función de hash.

Siguiendo con el ejemplo, una vez que se guarda la configuración en ejecución, el router se vuelve a cargar. Como se muestra en el último código, el comando show access-lists muestra la ACL en el mismo orden, sin embargo, las instrucciones se volvieron a numerar. Los números de secuencia ahora están en orden numérico.

4. Procesos de enrutamiento y ACL

En la Imagen 2, se muestra la lógica de los procesos de routing y ACL. Cuando un paquete llega a una interfaz del router, el proceso del router es el mismo, ya sea si se utilizan ACL o no. Cuando una trama ingresa a una interfaz, el router revisa si la dirección de capa 2 de destino coincide con la dirección de capa 2 de la interfaz, o si dicha trama es una trama de difusión.

• Si se acepta la dirección de la trama, se desmonta la información de la trama y el router revisa si hay una ACL en la interfaz de entrada. Si existe una ACL, el paquete se prueba en relación con las instrucciones de la lista.
• Ahora, si el paquete coincide con una instrucción, se permite o se deniega. Si se acepta el paquete, se compara con las entradas en la tabla de routing para determinar la interfaz de destino. Si existe una entrada para el destino en la tabla de routing, el paquete se conmuta a la interfaz de salida. De lo contrario, se descarta.
• A continuación, el router revisa si la interfaz de salida tiene una ACL. Si existe una ACL, el paquete se prueba en relación con las instrucciones de la lista.
• Ahora, si el paquete coincide con una instrucción, se permite o se deniega.
• Si no hay una ACL o si se permite el paquete, este se encapsula en el nuevo protocolo de capa 2 y se reenvía por la interfaz al siguiente dispositivo.

5. Errores estándar comunes de ACL de IPv4

Tomaremos el siguiente ejemplo (Imagen 3) para mostrar diferentes soluciones de acuerdo a las políticas establecidas.

5.1. Solución de problemas de ACL IPv4 estándar. Ejemplo 1

Mediante los comandos show descritos anteriormente, se revela la mayoría de los errores más comunes de ACL. Los errores más comunes incluyen introducir las ACE en el orden incorrecto y no especificar reglas de ACL adecuadas. Otros errores comunes incluyen la aplicación de la ACL mediante la dirección incorrecta, la interfaz incorrecta, o direcciones de origen incorrectas.

Política de seguridad: PC2 no debe poder acceder al servidor de archivos.

R3# show access-list
Standard IP access list 10
 10 denny 192.168.11.10
R3#

En el esquema anterior, aunque la PC2 no puede acceder al servidor de archivos, tampoco puede PC1. Al observar el resultado del comando show access-list, solo la PC2 está explícitamente denegada. Sin embargo, no hay instrucción de permiso para ningún otro acceso.

Solución: Todo acceso desde la interfaz G0/0 a la LAN 192.168.30.0/24 se deniega de forma implícita actualmente. Agregue una instrucción a la ACL 10 para permitir el resto del tráfico, como se muestra a continuación. La PC1 ahora debe poder acceder al servidor de archivos. El resultado del comando show access-list verifica que el ping de la PC1 al servidor de archivos coincida con la instrucción permit any.

R3(config)# access-list 10 permit any
R3(config)# end
R3# show access-list
Standard IP access list 10
 10 deny 192.168.11.10
 20 permit any (4 match(es))
R3#

5.2. Solución de problemas de ACL IPv4 estándar. Ejemplo 2

Política de seguridad: la red 192.168.11.0/24 no debe poder acceder a la red 192.168.10.0/24.

R1# show access-list
Standard IP access list 20
 10 deny 192.168.11.10, wildcard bits 0.0.0.255 (8 match(es))
 20 permit any

En el esquema anterior, la PC2 no puede acceder a la PC1. Tampoco puede acceder a Internet con R2. Al observar el resultado del comando show access-list, puede ver que PC2 coincide con la instrucción deny. La ACL 20 parece estar correctamente configurada. Sospecha que está incorrectamente aplicada y revisa las configuraciones de interfaz de R1

Ahora, el comando show run filtrado para ver las configuraciones de interfaz revela que la ACL 20 se aplicó a la interfaz equivocada en la dirección incorrecta. Se deniega todo el tráfico entrante de 192.168.11.0/24 a través de la interfaz G0/1.

R1# show run | section interface
interface GigabitEthernet0/0
ip address 192.168.10.1 255.255.255.0
duplex auto
speed auto
interface GigabitEthernet0/1
ip address 192.168.11.1 255.255.255.0
ip access-group 20 in
duplex auto
speed auto
<Se omitió el resultado>

Solución: Para corregir este error, elimine la ACL 20 de la interfaz G0/1 y aplíquela en la interfaz G0/0 saliente, como se muestra en el siguiente código. La PC2 no puede acceder a la PC1, pero ahora puede acceder a Internet.

R1# config t
R1(config)# interface g0/1
R1(config-if)# no ip access-group 20 in
R1(config-if)# interface g0/0
R1(config-if)# ip access-group 20 out

5.3. Solución de problemas de ACL IPv4 estándar. Ejemplo 3

Política de seguridad: Solo a la PC1 se le permite el acceso remoto de SSH a R1.

R1# show run | section line vty
line vty 0 4
 access-class PC1-SSH in
 login
 transport input ssh
R1# show access-list
Standard IP access list PC1-SSH
 10 permit 192.168.10.1
 20 deny any (5 match(es))
R1#

En el esquema anterior, la PC1 no puede tener acceso remoto a R1 mediante una conexión SSH. Al ver la sección de configuración en ejecución para las líneas VTY se revela que una ACL con el nombre PC1-SSH está correctamente aplicada a las conexiones entrantes. Las líneas VTY están configuradas correctamente para permitir solo conexiones SSH. En el resultado del comando show access-list, advierte que la dirección IPv4 es la interfaz G0/0 del R1, no la dirección IPv4 de la PC1. Además, observa que el administrador configuró una instrucción deny any explícita en la ACL. Esto es útil porque, en esta situación, verá coincidencias para que los intentos fallidos de acceso remoto a R1.

Solución: El siguiente código muestra el proceso para corregir el error. Debido a que la instrucción que se debe editar es la primera, utilizamos el número de secuencia 10 para eliminarla ingresando no 10. Luego configuramos la dirección correcta IPv4 de la PC1. El comando clear access-list counters restablece el resultado para mostrar sólo las nuevas coincidencias. El intento de PC2 para acceeder remotamente a R1 es e, como se muestra en el resultado del comando show access-list.

R1# conf t
Enter configuration commands, one per line. End with CNTL/Z.
R1(config)# ip access-list standard PC1-SSH
R1(config-std-nacl)# no 10
R1(config-std-nacl)# 10 permit host 192.168.10.10
R1(config-std-nacl)# end
R1# clear access-list counters
R1# show access-list
Standard IP access list PC1-SSH
 10 permit 192.168.10.10 (2 match(es))
 20 deny any
R1#