Dolores de cableza por utilizar una ACL numerada

Fecha: 1 de abril del 2014 Clase: CCNA 4

 

Escenario

 

En este escenario se intentan simular los problemas comunes que acarrean asociar una ACL numerada a

una intefazen producción, entre ellos, la potencial perdida de conectividad.

El tema se inspira en un enunciado de la versión 3.1 de la currícula de CCNA 2, punto 11.1.3 y que al

momento no encontré la verión de IOS que menciona, pero sí la posible causa de la pérdida de conexión,

no al momento de borrar la ACL sino al aplicarla nuevamente estando todavía asociada a la interfaz.

 

La versión 4 de la currícula no menciona este efecto, CCNA Security v1.1 tampoco.

 

El escenario y la ACL se simplificaron para que el tema sea claro, pero se supone debería ser mas compleja

y tener datos de usuarios través del router.

 

La idea es agregar una línea permitiendo SSH , pero tenemos un deny any al final de la ACL, por lo tanto no

se puede agregar y listo.

 

 

 

 

Primer paso, se borra la ACL y se verifica que la conectividad no se pierde:

 

Esto se realizó en Packet Tracert y en equipos reales con diferentes versiones de IOS.

 

En Packet Tracert:

 

Segundo paso, se verifica este proceso en varias versiones de IOS:

 

C1601#sh ver (versión muy antigua)

Cisco Internetwork Operating System Software

IOS (tm) 1600 Software (C1600-SY-L), Version 11.3(9)T,  RELEASE SOFTWARE (fc1)

---resumido---

C1601 uptime is 19 minutes

System restarted by power-on

System image file is "flash:c1600-sy-l_113-9_T", booted via flash

---resumido---

C1601#

 

C2601#sh ver (versión antigua)

Cisco Internetwork Operating System Software

IOS (tm) C2600 Software (C2600-IK9S-M), Version 12.2(28), RELEASE SOFTWARE (fc5)

---resumido---

C2601 uptime is 8 minutes

System returned to ROM by power-on

System image file is "flash:c2600-ik9s-mz.122-28.bin"

---resumido---

C2601#

 

C1941#sh ver (versión nueva)

Cisco IOS Software, C1900 Software (C1900-UNIVERSALK9-M), Version 15.0(1)M6, RELEASE SOFTWARE (fc1)

---resumido---

C1941 uptime is 12 minutes

System returned to ROM by reload at 13:43:53 UTC Mon Mar 31 2014

System restarted at 13:45:04 UTC Mon Mar 31 2014

System image file is "flash0:c1900-universalk9-mz.SPA.150-1.M6.bin"

Last reload type: Normal Reload

Last reload reason: Reload Command

---resumido---

C1941#

 

Tercer paso, configurar la ACL

 

Primero configuramos una ACL para realizar las pruebas y acceder vía Telnet.

 

C1941#configure terminal

C1941(config)#access-list 100 permit icmp 192.168.0.0 0.0.0.255 host 192.168.0.1

C1941(config)#access-list 100 permit tcp 192.168.0.0 0.0.0.255 host 192.168.0.1 eq 23

C1941(config)#access-list 100 deny ip any any

C1941(config)#int gi0/0

C1941(config-if)#ip access-group 100 in

C1941(config-if)#exit

C1941(config)#

 

Ahora bien, necesitamos reconfigurar de Telnet a SSH, los pasos serían:

 

C1941(config)#ip domain-name cisco (necesario para generar el certificado)

C1941(config)#username remoto secret remoto123 (necesario para autenticarnos)

C1941(config)#crypto key generate rsa (generamos el certificado)

The name for the keys will be: C1941.cisco

Choose the size of the key modulus in the range of 360 to 2048 for your

  General Purpose Keys. Choosing a key modulus greater than 512 may take

  a few minutes.

 

How many bits in the modulus [512]: 1024

% Generating 1024 bit RSA keys, keys will be non-exportable...[OK]

 

C1941(config)#line vty 0 4

*Mar 1 0:6:28.298:  %SSH-5-ENABLED: SSH 1.99 has been enabled

C1941(config)#

C1941(config-line)#login local (acepta el user/pass configurado)

C1941(config-line)#transport input all (permite ambos protocolos, si ingresamos ssh la conexión se

C1941(config-line)#exit                            corta y la ACL 100 todavía no se modificó para el puerto 22)

C1941(config)#

 

Los pasos y la configuración a pegar en el router deberían ser los siguientes:

 

No se puede agregar una línea permitiendo SSH ya que tenemos un deny any al final de la ACL.

 

 

Donde:

 

no access-list 100 (elimina la ACL)

access-list 100 permit icmp 192.168.0.0 0.0.0.255 host 192.168.0.1 (permite el ping para verificar)

access-list 100 permit tcp 192.168.0.0 0.0.0.255 host 192.168.0.1 eq 23 (permite Telnet, hace que no se corte la conexión)

access-list 100 permit tcp 192.168.0.0 0.0.0.255 host 192.168.0.1 eq 22 (permite la futura conexión SSH)

access-list 100 deny ip any any

!

line vty 0 4

transport input ssh (ahora escucha sólo en el puerto 22)

exit

!

no access-list 100 (elimina la ACL)

access-list 100 permit icmp 192.168.0.0 0.0.0.255 host 192.168.0.1

access-list 100 permit tcp 192.168.0.0 0.0.0.255 host 192.168.0.1 eq 22 (permite la conexión SSH)

access-list 100 deny ip any any

end

 

Pero se presenta el siguiente problema al aplicar el script:

 

 

C1941(config)#no access-list 100 (la conexión no se corta)

C1941(config)#access-list 100 permit icmp 192.168.0.0 0.0.0.255 host 192.168.0.1 (el ping no se corta)

C1941(config)#access-list 100 per (aquí se corte la conexión porque la ACL tiene una sóla línea permit

                                                               que es el ICMP, y un deny ip any any implícito como línea siguiente)

 

 

 

Este esfecto también se verificó en Packet Tracer:

 

La conexión Telnet se cortó y el ping siguió respondiendo.

 

 

Recuperandose de la catástrofe:

 

Se supone que si fuede un equipo en producción, correr hasta el router lo mas rápido posible con un cable

de consola y tipear lo mas rápido que se pueda…

 

 

Vemos que ya la ACL está adpatada al SSH y nos ahorramos el paso de eliminar la línea del Telnet.

 

 

El procedimiento correcto sería:

 

Generamos una nueva ACL, activamos el SSH, asociamos la nueva ACL a la interface y eliminamos la ACL original.

 

 

Plan B (no tan correcto y por lo tanto, mas engorroso) :

 

Puede suceder que si o si la ACL deba ser la 100 (tal vez por estandarización), entonces…a luchar.

 

 

Desactivamos la ACL de la interface, eliminamos la ACL, la creamos a medida de lo necesario y la asociamos

a la interface nuevamente.

 

 

Podemos ver que la línea trasnport input SSH nos permite mantener la conexión Telnet, y cuando aplicamos

la ACL a la interface la conexión se pierde, pero se retoma vía el protocolo SSH.

 

 

Plan C (el mas desprolijo de los tres):

 

Colocamos la línea SSH primera en la lista, por lo tanto no se cortará la conexión y tal vez se pierda un solo ping.

 

 

Todos estos dolores de cabeza podemos evitarlos con una ACL nombrada y sus números de secuencia.

 

A trabajar!

 

 

(2014) Sensei, an ACL blocks the funny girls to me ?

Rosario, Argentina