CULTIVA IA · Servicio de Seguridad
BLOCK — NO APLICAR

Revisión de Configuración de Red: novamed-core-sw01

Dispositivo: Cisco IOS-XE 17.3.4a · Rol: Core Switch L3 — CPD Madrid · Cliente: NovaMed Digital · Ventana: Sáb 21 Jun 2026, 02:00–05:00 CEST · Auditor: CULTIVA IA Security Review
4
Crítico
3
Alto
3
Medio
2
Bajo
BLOCK
Ventana BLOQUEADA
novamed-core-sw01
Cisco IOS-XE 17.3.4a
Producción · ENS/RGPD
10.10.10.1/24
Pre-change window
VLAN 99 + migración SNMPv3

Crítico

4 hallazgos
CRITICAL-1 Comando reload in 60 destructivo sin plan de rollback
Evidencia
reload in 60
! --- FIN CAMBIO ---
Riesgo
Un reload in 60 reinicia el dispositivo incondicionalmente 60 minutos después de ser introducido. Si el cambio falla o la sesión queda bloqueada, el switch se reiniciará sin que los demás técnicos lo esperen, cortando la VLAN de producción EHR (VLAN10) con datos clínicos en tránsito. En un entorno ENS, una interrupción no planificada puede constituir incidente de disponibilidad notificable.
Corrección
Acción requerida antes de la ventana
Eliminar el reload in 60 del snippet. Si se desea usar como salvaguarda de rollback, documentarlo explícitamente y cancelarlo con reload cancel tras verificar el cambio.
! Cancelar el timer si ya fue introducido accidentalmente:
reload cancel
! Verificar estado:
show reload
CRITICAL-2 Comunidades SNMP públicas con acceso de escritura (community private RW)
Evidencia
snmp-server community public RO
snmp-server community private RW
snmp-server host 10.10.20.50 version 2c public
Riesgo
La comunidad private RW permite a cualquier host alcanzable reescribir la tabla de routing, añadir usuarios privilegiados o modificar interfaces vía SNMP SET. La comunidad public RO expone toda la topología, tabla ARP y estado de interfaces. Ambas son credenciales por defecto trivialmente conocidas. En un entorno con datos de salud esto es inaceptable bajo el ENS (categoría Media) y el RGPD.
Corrección
Incluir en el snippet de cambio como prerrequisito bloqueante
Eliminar ambas comunidades SNMPv2c antes de activar la nueva VLAN. El snippet propuesto ya incluye los no snmp-server community — moverlos al inicio del cambio y confirmar su eliminación antes de continuar.
no snmp-server community public RO
no snmp-server community private RW
! Verificar:
show snmp community
CRITICAL-3 Contraseñas en texto claro — enable password y usuarios password 0
Evidencia
enable password cisco123
username admin privilege 15 password 0 P@ssw0rd2024
! (Snippet propuesto añade también:)
username cultiva-temp privilege 15 password 0 Cultiva2026!
Riesgo
enable password almacena la contraseña en texto plano en el running-config y startup-config. password 0 indica cifrado tipo 0 (sin cifrar). Cualquier técnico con acceso al config (backup, pantalla, log) ve las credenciales. El nuevo usuario cultiva-temp privilege 15 hereda el mismo problema y tiene privilegio máximo sin restricción de acceso.
Corrección
Prerrequisito bloqueante — resolver antes de la ventana
! Reemplazar enable password por enable secret (SHA-256 / type 9)
no enable password
enable algorithm-type sha256 secret <contraseña-segura>
! Reemplazar usuarios con secret:
no username admin
username admin privilege 15 algorithm-type sha256 secret <nueva-pass>
! Para cultiva-temp: limitar a privilege 5 o usar AAA temporal
username cultiva-temp privilege 5 algorithm-type sha256 secret <pass>
! Activar service password-encryption como capa adicional:
service password-encryption
CRITICAL-4 Telnet habilitado en VTY — gestión en texto claro accesible desde todas las VLANs
Evidencia
line vty 0 4
 transport input telnet ssh
 login local
! No hay access-class para restringir origen
Riesgo
Telnet transmite credenciales en claro. La nueva VLAN99 (agentes CULTIVA) podrá alcanzar el plano de gestión sin restricción alguna. En entornos ENS, permitir Telnet en un dispositivo core con datos clínicos es un hallazgo bloqueante de auditoría.
Corrección
Prerrequisito — deshabilitar Telnet antes de añadir VLAN99
line vty 0 4
 transport input ssh
 access-class ACL_MGMT_ACCESS in
 exec-timeout 10 0
!
ip access-list standard ACL_MGMT_ACCESS
 permit 10.10.20.0 0.0.0.255
 deny   any log

Alto

3 hallazgos
HIGH-1 ACL ACL_CLIENTES referenciada en VLAN30 pero no definida
Evidencia
interface Vlan30
 description Clientes-VPN
 ip address 10.10.30.1 255.255.255.0
 ip access-group ACL_CLIENTES in
!
! ip access-list extended ACL_CLIENTES — NO EXISTE en el running-config
Riesgo
En IOS-XE, una ACL referenciada pero no definida implica que la interfaz aplica una ACL vacía, lo que en la mayoría de versiones equivale a permit any implícito. Los clientes VPN en VLAN30 pueden tener acceso sin filtro al segmento EHR (VLAN10) con registros clínicos.
Corrección
Definir ACL_CLIENTES antes de la ventana
ip access-list extended ACL_CLIENTES
 permit tcp 10.10.30.0 0.0.0.255 10.10.10.0 0.0.0.255 eq 443
 deny   ip any 10.10.10.0 0.0.0.255 log
 permit ip 10.10.30.0 0.0.0.255 any
HIGH-2 SSH versión 1 — protocolo con vulnerabilidades conocidas
Evidencia
ip ssh version 1
Riesgo
SSH v1 tiene vulnerabilidades de inserción de texto plano en la sesión cifrada (CVE históricos). Debe migrarse a SSH v2 antes de añadir nuevas VLANs con acceso de gestión.
Corrección
ip ssh version 2
ip ssh time-out 60
ip ssh authentication-retries 3
HIGH-3 ACL ACL_AI_AGENTS referenciada en snippet pero no definida
Evidencia
interface Vlan99
 description AI-Agents-CULTIVA
 ip address 10.10.99.1 255.255.255.0
 ip access-group ACL_AI_AGENTS in
!
! ACL_AI_AGENTS — no aparece en el snippet ni en el running-config
Riesgo
Los agentes de IA de CULTIVA en VLAN99 tendrían acceso sin restricciones al resto de VLANs, incluyendo producción EHR. Debe definirse la ACL antes o simultáneamente a la activación de la interfaz.
Corrección
Añadir al snippet antes de la interfaz Vlan99
ip access-list extended ACL_AI_AGENTS
 permit tcp 10.10.99.0 0.0.0.255 host 10.10.10.1 eq 443
 permit udp 10.10.99.0 0.0.0.255 any eq 53
 deny   ip 10.10.99.0 0.0.0.255 10.10.10.0 0.0.0.255 log
 deny   ip 10.10.99.0 0.0.0.255 10.10.20.0 0.0.0.255 log
 permit ip 10.10.99.0 0.0.0.255 any

Medio

3 hallazgos
MEDIUM-1 Sin logging remoto — sin trazabilidad de los cambios de la ventana
Evidencia
logging buffered 4096
no service timestamps log datetime msec
! Sin logging host / syslog remoto definido
Riesgo
Los logs sin timestamp y sin destino remoto no son válidos como evidencia forense bajo el ENS. Si ocurre un incidente durante la ventana, no habrá trazabilidad externa.
Corrección
service timestamps log datetime msec localtime show-timezone
service timestamps debug datetime msec
logging host 10.10.20.100
logging trap informational
MEDIUM-2 Acceso de gestión VTY no limitado a subred de administración
Evidencia
line vty 0 4
 transport input telnet ssh
 login local
! Sin access-class definido
Riesgo
Cualquier host en cualquier VLAN puede intentar conectarse por SSH/Telnet al plano de gestión. Con la nueva VLAN99 activa, los agentes externos tendrán alcance directo al switch core.
Corrección
Añadir access-class ACL_MGMT_ACCESS in en line vty. Ver fix de CRITICAL-4 para la definición completa de la ACL.
MEDIUM-3 NTP apunta a pool público sin autenticación
Evidencia
ntp server 0.pool.ntp.org
Riesgo
Sin autenticación NTP, el dispositivo es susceptible a ataques de desincronización temporal que invalidan timestamps de logs y certificados. Para ENS categoría Media se requiere NTP interno o autenticado.
Corrección
ntp authenticate
ntp authentication-key 1 md5 <clave-segura>
ntp trusted-key 1
ntp server 10.10.20.200 key 1    ! NTP interno NovaMed

Bajo

2 hallazgos
LOW-1 Uplink GigabitEthernet1/0/1 sin restricción de VLANs permitidas en trunk
Evidencia
interface GigabitEthernet1/0/1
 description Uplink-ISP
 switchport mode trunk
! Sin switchport trunk allowed vlan definido
Riesgo
Un trunk sin lista explícita de VLANs permitidas propagará automáticamente la nueva VLAN99 al uplink ISP. Revisar si esto es intencionado.
Corrección
interface GigabitEthernet1/0/1
 switchport trunk allowed vlan 10,20,30
! Añadir 99 solo si se requiere tráfico VLAN99 hacia ISP
LOW-2 Puerto de gestión GigabitEthernet1/0/24 sin VLAN de gestión asignada ni shutdown
Evidencia
interface GigabitEthernet1/0/24
 description Mgmt-Port
! Sin switchport access vlan, sin shutdown explícito
Riesgo
El puerto de gestión físico cae en VLAN1 (nativa por defecto), que no tiene IP de gestión definida. Si alguien conecta un cable, queda en una VLAN no controlada. Bajo riesgo operativo pero debe documentarse.
Corrección
Asignar a una VLAN de gestión dedicada o aplicar shutdown si no está en uso activo.

Resumen

Severidad Descripción Cantidad
Crítico Cambio destructivo, credenciales en texto claro, SNMP con escritura, Telnet activo 4
Alto ACLs no definidas (×2), SSH v1 3
Medio Sin logging remoto, VTY sin restricción de origen, NTP sin autenticación 3
Bajo Trunk sin lista de VLANs, puerto Mgmt sin VLAN asignada 2
Total 12
Generado por CULTIVA IA · Servicio de Seguridad — Revisor de Configuraciones de Red (Cisco IOS/IOS-XE) · 2026-06-18