Subnet Academy
CCNA v2.0
CCNA v2.0/Módulo 10 · Seguridad de red

0% del curso completado

Lectura

Acceso a dispositivos: usuarios locales, contraseñas y MFA (4.1 parcial)

📋 En esta lección

Quien controla tus switches y routers controla tu red: el acceso administrativo es la joya de la corona. Aquí consolidas y elevas lo que empezaste en el Módulo 3 — usuarios locales con hashes fuertes, niveles de privilegio, el endurecimiento completo de las líneas de acceso — y añades las políticas de contraseñas y el MFA que el examen y la realidad exigen.

El objetivo: cada acceso, identificado y limitado

Del Módulo 3 tienes la base (SSH, enable secret, usuario local). Esta lección la convierte en política completa: nadie anónimo (cuentas individuales, no compartidas — sin ellas el accounting de la 10.3 no significa nada), nadie con más poder del necesario (privilegios), ninguna puerta débil (líneas endurecidas, Telnet muerto, contraseñas con hash fuerte) y la credencial sola no basta (MFA).

Usuarios locales bien hechos

R1(config)# username ana privilege 15 secret Adm1n-Larga-Y-Unica!
R1(config)# username noc-luis privilege 1 secret Otra-Clave-Distinta!

Los detalles que importan:

  • secret, jamás password: secret almacena hash (en plataformas modernas, tipo 8/9 — PBKDF2/scrypt, diseñados para ser lentos de crackear); password deja la clave en claro o con el cifrado decorativo tipo 7 (reversible en segundos — hay descifradores online). Si auditas una config y ves password 7, apúntalo como hallazgo.
  • Cuentas individuales: "admin" compartido = cero atribución. Cada persona la suya — y al irse, se borra la suya (la lección del PSK vs Enterprise de la 9.3, aplicada a la administración).
  • Privilegios: nivel 1 = User EXEC (mirar sin tocar — perfecto para el técnico de NOC que solo diagnostica), nivel 15 = control total. Los niveles intermedios personalizables existen, pero la práctica moderna delega esa granularidad en el servidor AAA (10.3), que la hace por comando y por grupo.

Endurecer las líneas de acceso

La configuración completa de consola y VTY — cada línea con su porqué:

R1(config)# line console 0
R1(config-line)# login local                ← usuarios locales, no clave compartida de línea
R1(config-line)# exec-timeout 10 0          ← sesión abandonada = sesión cerrada (10 min)
R1(config-line)# logging synchronous        ← los logs no te rompen el comando a medias

R1(config)# line vty 0 15
R1(config-line)# login local
R1(config-line)# transport input ssh        ← SSH solo; Telnet, extinto (lección 3.1)
R1(config-line)# exec-timeout 10 0
R1(config)# access-list 5 permit 10.9.250.0 0.0.0.255
R1(config)# line vty 0 15
R1(config-line)# access-class 5 in          ← gestión SOLO desde la red de gestión

access-class es el primer uso defensivo de las ACLs que formalizarás en 10.4: aunque alguien robe credenciales válidas, solo puede intentarlas desde la subred de gestión — capa extra clásica de defensa en profundidad.

Y los complementos globales:

R1(config)# ip ssh version 2
R1(config)# ip ssh time-out 60
R1(config)# ip ssh authentication-retries 3       ← lo tres-y-fuera del login
R1(config)# login block-for 120 attempts 3 within 60   ← anti fuerza bruta: 3 fallos
                                                          en 60 s → 120 s de cuarentena
R1(config)# banner motd ^ Acceso restringido. Toda actividad queda registrada. ^

login block-for convierte la fuerza bruta online en una tortura de goteo (y genera logs de cada cuarentena — tu detector de intentos). El banner no detiene a nadie, pero elimina el "no sabía que no podía entrar" — las organizaciones lo exigen por razones legales.

Políticas de contraseñas: lo que de verdad funciona

La doctrina moderna (alineada con NIST y con lo que pregunta el examen):

  • Longitud sobre complejidad barroca: una passphrase de 4-5 palabras (20+ caracteres) supera a P@ssw0rd1! en todo — entropía real y memorable. Los requisitos de "mayúscula+símbolo+número" producen patrones predecibles (Empresa2026!).
  • Únicas por servicio — el antídoto del credential stuffing (10.1) — y por tanto, gestores de contraseñas: la única forma humana de tener 200 claves únicas y largas.
  • Caducidad forzada periódica: ya no. Rotar cada 90 días genera Clave01!Clave02!. Se cambia cuando hay sospecha de compromiso — y se compensa con MFA y monitorización.
  • Listas negras: vetar las claves filtradas/comunes (los diccionarios del atacante como filtro propio).

MFA: la credencial sola ya no basta

MFA (Multi-Factor Authentication) exige dos o más factores de naturaleza distinta:

Factor"Algo que…"Ejemplos
Conocimiento…sabesContraseña, PIN
Posesión…tienesApp TOTP, llave FIDO2, tarjeta
Inherencia…eresHuella, cara

Dos claves distintas no son MFA (mismo factor). Y dentro de posesión hay jerarquía: SMS es el eslabón débil (SIM swapping, interceptable — mejor que nada, peor que todo lo demás); TOTP (la app de códigos) es el estándar razonable; FIDO2/llaves físicas el patrón oro — resistente incluso al phishing, porque la llave verifica el dominio antes de firmar (el usuario engañado no puede "entregar" el segundo factor en la web falsa).

En equipos de red, el MFA no se configura suelto en cada switch: llega via AAA — el login del administrador se valida contra el servidor central (TACACS+/RADIUS, lección 10.3) que a su vez integra el MFA corporativo. Otra razón para centralizar.

💡 💡 El orden correcto de las piezas

Usuarios individuales con secret fuerte → líneas endurecidas (SSH, timeouts, access-class, block-for) → todo apuntando a AAA central (10.3) → MFA en el AAA. Los usuarios locales quedan como respaldo de emergencia (si el servidor AAA cae, entras con la cuenta local — el fallback que configurarás en la próxima lección).

Relación con otros conceptos

  • Base directa del Módulo 3 (SSH, secret, modos) — esta lección es su versión de producción.
  • access-class anticipa las ACLs de 10.4; la centralización con TACACS+/RADIUS y el accounting, la 10.3.
  • El credential stuffing y la ingeniería social que estas defensas mitigan: lección 10.1; el paralelo PSK-vs-identidades: 9.3.
  • Los logs de login block-for y de cada sesión van al syslog central de la 8.5 — detección, no solo prevención.

Resumen

Acceso administrativo = identidad individual + mínimo poder + puertas duras + segundo factor. Usuarios: username X privilege N secret (hashes tipo 8/9; password 7 es un hallazgo de auditoría), cuentas por persona, privilegio 1 para mirar y 15 para administrar (la granularidad fina, en el AAA). Líneas: login local, transport input ssh, exec-timeout, access-class (gestión solo desde su subred), login block-for contra fuerza bruta, banner legal. Contraseñas: longitud (passphrases) > complejidad ritual, únicas por servicio (gestor), sin caducidad calendario, con listas negras. MFA: factores de naturaleza distinta (saber/tener/ser); SMS débil < TOTP < FIDO2 (anti-phishing); en red se despliega via el AAA central — con los usuarios locales como respaldo de emergencia.

Fuentes oficiales

Quiz

Comprueba lo que has aprendido

1.En una auditoría encuentras `username admin password 7 0822455D0A16`. ¿Qué reportas?

2.¿Qué aporta `access-class 5 in` en las líneas VTY que no aporte la autenticación?

3.¿Qué hace `login block-for 120 attempts 3 within 60` y contra qué ataque va?

4.¿Por qué "contraseña + PIN" no es MFA y "contraseña + app TOTP" sí lo es?

5.¿Por qué la doctrina moderna eliminó la caducidad periódica obligatoria de contraseñas?

6.¿Por qué las llaves FIDO2 resisten el phishing donde el TOTP puede caer?