Revisión Cisco IOS — Logistech SL

Resumen ejecutivo

Anti-patrones detectados

En la config candidata original

Riesgo de bloqueo SSH

ALTO

ACL bloquea gestión si no se añade permit

Estado del plan

REVISADO

Requiere correcciones antes de aplicar

Hallazgos críticos

⚠

Wildcard mask incorrecta — se usa subnet mask en lugar de wildcard

La línea permit tcp 10.50.0.0 255.255.255.0 any eq 443 usa máscara de subred (255.255.255.0) donde IOS espera una wildcard mask (0.0.0.255). IOS puede aceptar el comando silenciosamente, pero la coincidencia de tráfico será incorrecta: se permitirá un rango de IPs completamente diferente al previsto.

⚠

ACL bloquea acceso de gestión SSH/Telnet — riesgo de lockout

La ACL WEB-IN sólo permite HTTPS (443) desde 10.50.0.0/24. No hay ningún permit para SSH (22) desde la red de gestión del técnico. Al aplicarse en GigabitEthernet0/0 in, bloqueará el SSH entrante por WAN. Si no hay acceso fuera de banda (consola OOB), el equipo quedará inaccesible remotamente.

⚠

Se guarda la config ANTES de validar el comportamiento

El plan original incluye copy running-config startup-config al final, sin haber ejecutado los comandos de verificación post-cambio. Si el cambio bloquea el acceso, un reload del dispositivo lo haría persistente.

⚠

ACL sin deny explícito con log — observabilidad limitada

El deny implícito al final de la ACL no genera logs. Se recomienda añadir 999 deny ip any any log para visibilidad de intentos bloqueados (tras confirmar que el volumen es seguro para el syslog).

Diff: Config candidata vs. Config corregida

config-candidata-original.ios 3 ERRORES

! ACL con subnet mask (INCORRECTO)
ip access-list extended WEB-IN
 10 permit tcp 10.50.0.0 255.255.255.0 any eq 443
 999 deny ip any any

! Sin permit de gestión SSH
interface GigabitEthernet0/0
 ip access-group WEB-IN in

! OK
interface GigabitEthernet0/1
 description UPLINK-TO-CORE-MAD

! Guardar SIN validar (INCORRECTO)
copy running-config startup-config

config-corregida.ios CORREGIDA

! Wildcard mask correcta (0.0.0.255)
ip access-list extended WEB-IN
 5 permit tcp 172.16.100.0 0.0.0.255 any eq 22
 10 permit tcp 10.50.0.0 0.0.0.255 any eq 443
 999 deny ip any any log

! Aplicar ACL (sin cambios)
interface GigabitEthernet0/0
 ip access-group WEB-IN in

! OK
interface GigabitEthernet0/1
 description UPLINK-TO-CORE-MAD

! Guardar SOLO tras validación
! copy running-config startup-config
! (ejecutar manualmente tras checks)

Referencia wildcard masks

Subred CIDR	Subnet Mask	Wildcard Mask (IOS)	Correcto para ACL IOS	Error típico
`10.50.0.0/24`	`255.255.255.0`	`0.0.0.255`	OK	Usar 255.255.255.0 → match incorrecto
`172.16.100.0/24`	`255.255.255.0`	`0.0.0.255`	OK	Red de gestión SSH del técnico
`192.168.1.0/30`	`255.255.255.252`	`0.0.0.3`	OK	Enlace punto a punto
`10.0.0.0/8`	`255.0.0.0`	`0.255.255.255`	OK	Rango RFC1918 completo
Host único	`255.255.255.255`	`0.0.0.0` o `host x.x.x.x`	OK	Omitir wildcard → error de sintaxis

Checklist pre-cambio (antes de la ventana)

Confirmar wildcard masks correctas en todas las ACEs

La ACE 10 usaba 255.255.255.0 — corregida a 0.0.0.255. Revisar cada línea antes del cambio.
Verificar acceso de gestión protegido en ACL (línea 5: permit SSH desde red de gestión)

Red de gestión técnico: 172.16.100.0/24. Añadir ACE 5 antes de aplicar. Confirmar con show running-config | section line vty.
Confirmar acceso OOB (consola física o gestión fuera de banda) disponible durante el cambio

Si la ACL bloquea acceso por error, la consola serie o una segunda interfaz de gestión es el rollback de emergencia.
Descripción de interfaz GigabitEthernet0/1 verificada

UPLINK-TO-CORE-MAD — nomenclatura clara y coherente con el inventario.
Confirmar que el volumen de logs del deny explícito es manejable

Si la interfaz WAN recibe muchos paquetes rechazados, el syslog puede saturarse. Estimar tráfico o añadir rate-limit de logging.

Comandos de captura de estado (solo lectura)

ANTES del cambio — guardar output en ticket

Madrid-R1# (read-only)

show version
show ip interface brief
show interfaces GigabitEthernet0/0
show interfaces GigabitEthernet0/1
show running-config | section interface
show running-config | section line vty
show ip access-lists
show ip route
show logging | last 30

DESPUÉS del cambio — comparar con baseline

Madrid-R1# (post-change)

show ip access-lists WEB-IN
! Verificar hit counters tras test controlado
show interfaces GigabitEthernet0/0
show running-config | section interface Gi0/0
show running-config | section interface Gi0/1
show logging | include ACL|changed state
! Solo si todo OK:
copy running-config startup-config

Plan de ventana de mantenimiento

02:00 — Captura de estado actual

Ejecutar todos los comandos de solo lectura. Guardar output en el ticket JIRA #LOG-2231.

show version · show ip interface brief · show ip access-lists · show ip route

02:15 — Aplicar config corregida

Pegar el bloque corregido en orden: primero la ACL (con wildcard correcta + ACE de gestión), luego aplicar a interfaz, luego descripción. NO guardar todavía.

configure terminal → acl WEB-IN → interface Gi0/0 → interface Gi0/1 → end

02:20 — Verificación con test controlado

Desde la red de gestión (172.16.100.x), confirmar SSH al router. Desde 10.50.0.x, confirmar acceso HTTPS. Leer hit counters de la ACL.

show ip access-lists WEB-IN · show interfaces Gi0/0 · show logging | include WEB-IN

02:35 — Guardar si todo OK

Solo tras confirmar que SSH de gestión funciona y el tráfico HTTPS es permitido correctamente.

copy running-config startup-config

02:40 — Rollback si hay problemas

Si la ACL bloquea acceso y aún hay sesión activa, eliminar la aplicación de la ACL a la interfaz. Si hay lockout, usar consola OOB.

interface Gi0/0 → no ip access-group WEB-IN in → end

Anti-patrones identificados en el plan original

#	Anti-patrón	Presencia	Riesgo	Corrección aplicada
1	Usar subnet mask donde IOS espera wildcard mask	Sí	Crítico	Cambiado a `0.0.0.255`
2	Guardar config antes de validar post-cambio	Sí	Alto	Comentado, movido al paso 4
3	No verificar que ACL no bloquea acceso de gestión	Sí	Crítico	Añadida ACE 5 para SSH de gestión
4	Deny implícito sin log (observabilidad cero)	Sí	Medio	Añadido `999 deny ip any any log`
5	No capturar estado antes del cambio	Sí	Medio	Plan de ventana incluye captura previa

ℹ

Recuerda: running-config vs startup-config

Los cambios en running-config son activos en memoria pero se pierden en un reload. No ejecutar copy running-config startup-config hasta haber validado completamente el comportamiento esperado. Un reload no planificado (caída de alimentación, reset remoto) durante la ventana podría revertir los cambios y restaurar la config anterior.

Revisión de Cambio — Ventana de Mantenimiento