🧿 Secure Shell (SSH)

1️⃣ ALEGORÍA + 🧠 EXPLICACIÓN TÉCNICA

✨ ALEGORÍA PARA COMPRENDER SSH

Imagina que eres una espía de élite que necesita hablar en secreto con el comandante del castillo (servidor) desde un lugar lejano. El camino está lleno de bandidos, y los mensajeros ordinarios son interceptados fácilmente.

Entonces, usas un túnel mágico invisible que solo tú y el comandante conocéis. Ese túnel es SSH: una vía secreta, protegida con llaves encantadas.

Pero antes de entrar, el castillo te pide una prueba de identidad:

• Puedes decir tu nombre y contraseña.

• O puedes usar una llave mágica personal (clave pública).

• O puedes mostrar un sello real de Kerberos que demuestra tu identidad ante el reino entero.

Una vez dentro, puedes enviar órdenes, traer planos secretos (archivos) o salir con información confidencial. Pero cuidado:
Si alguien roba la llave privada del castillo, ¡puede hacerse pasar por él y engañar a todos los espías!

🧠 EXPLICACIÓN TÉCNICA

SSH (Secure Shell) es un protocolo que permite acceso remoto seguro a través de una terminal de línea de comandos. Opera sobre puerto 22 TCP, cifrando toda la comunicación.

🛡️ Usos principales:

• Administración remota de servidores y sistemas (Linux, routers, switches).

• Transferencia segura de archivos (scp, sftp).

• Túneles seguros para reenviar puertos.

🔐 Seguridad basada en:

• Cifrado simétrico para proteger la sesión.

• Autenticación asimétrica con claves públicas/privadas.

• Integridad mediante hash para verificar que el contenido no fue alterado.

📌 COMPONENTES CLAVE

🗝️ Claves de Host (Host Key)

Cada servidor SSH tiene una clave pública/privada que lo identifica. El cliente verifica esta clave al conectarse por primera vez. Si cambia sin explicación, puede ser un ataque (como Man in the Middle).

🔑 Autenticación de Cliente

Configurada en /etc/ssh/sshd_config:

• Password: clásico usuario + contraseña.

• PublicKey: claves SSH que se añaden al archivo ~/.ssh/authorized_keys.

• Kerberos: mediante tickets de sesión (TGT) y GSSAPI, ideal en entornos Windows con Active Directory.

💥 Una mala gestión de claves públicas puede ser desastrosa. Si se sospecha compromiso:

• Elimina la clave pública.

• Genera una nueva con ssh-keygen.

• Copia la nueva con ssh-copy-id.

2️⃣ EJEMPLOS PRÁCTICOS

📥 Conexión remota:

bash:ssh bobby@10.1.0.10

Accede al servidor remoto como el usuario bobby.

🛡️ Generar y copiar una nueva clave:

bash:ssh-keygen -t rsa ssh-copy-id bobby@10.1.0.10

Esto configura autenticación sin contraseña con clave pública.

📤 Transferir archivos:

Copiar archivo del servidor al host local:

bash:scp bobby@10.1.0.10:/logs/audit.log audit.log

Copiar archivo del host local al servidor:

bash:scp audit.log bobby@10.1.0.10:/logs/audit.log

Copiar carpeta completa (recursivamente):

bash:scp -r /mi/carpeta bobby@10.1.0.10:/backup

3️⃣ APLICACIONES Y HERRAMIENTAS REALES

⚙️ Herramientas:

• OpenSSH (más usado en Linux y BSD).

• PuTTY (cliente SSH para Windows).

• WinSCP / FileZilla (clientes gráficos SFTP).

• MobaXterm (cliente completo para Windows con terminal + X11).

🖥️ Sistemas:

• Todos los sistemas UNIX y derivados (Linux, macOS, BSD).

• Windows 10+ incluye cliente SSH nativo (cmd o PowerShell).

• Dispositivos de red (Cisco, FortiGate) permiten administración por SSH.

4️⃣ ¿QUÉ HACE CADA EQUIPO?

🔴 Red Team (ataca):

• Escanea redes en busca de puertos 22 abiertos (nmap, masscan).

• Captura claves privadas comprometidas (id_rsa) en endpoints sin protección.

• Suplantación de servidores mediante ataques Man in the Middle.

• Uso de fuerza bruta o credenciales por defecto.

🔵 Blue Team (defiende):

• Desactiva root login y password auth en el archivo sshd_config.

• Requiere autenticación por clave pública (con contraseña de clave cifrada).

• Audita intentos de conexión fallida (/var/log/auth.log o SIEM).

• Establece reglas de Fail2Ban y listas de acceso (iptables, firewalld).

🟣 Purple Team (supervisa y refuerza):

• Simula ataques de conexión por fuerza bruta y mide detección.

• Verifica integridad de claves host (/etc/ssh/ssh_host_*).

• Genera alertas por conexiones SSH fuera de horario o desde IPs inusuales.

• Refuerza prácticas de rotación y distribución de claves en entornos DevOps.

6️⃣ ✅ RESUMEN PRÁCTICO

• SSH es la puerta mágica para administrar sistemas de forma remota y segura.

• Usa claves criptográficas para asegurar el canal y verificar la identidad.

• La seguridad de SSH depende totalmente de una buena gestión de claves.

• El Red Team explota SSH mal configurado, el Blue Team lo blinda, y el Purple Team verifica que se mantenga seguro.

🧪 EJERCICIOS PURPLE TEAM – SSH

🧩 Ejemplo 1 – Fuerza bruta SSH y evasión de detección

🔴 Red Team ataca

• Escanea la red para identificar servidores con puerto 22 abierto usando nmap o masscan.

• Ejecuta fuerza bruta con hydra, medusa o ncrack, probando usuarios y contraseñas comunes.

• Prueba técnicas de evasión de Fail2Ban, como sleep entre intentos o rotación de IPs mediante proxychains/Tor.

🔵 Blue Team defiende

• Configura Fail2Ban para detectar múltiples intentos fallidos en /var/log/auth.log.

• Desactiva la autenticación por contraseña (PasswordAuthentication no) en sshd_config.

• Aplica listas de acceso por IP (AllowUsers, AllowGroups) y segmentación por firewall (iptables o ufw).

• Revisa logs y correlaciona con alertas SIEM.

🟣 Purple Team gestiona

• Ejecuta campañas de fuerza bruta simuladas desde una IP controlada.

• Mide tiempo de detección, respuesta de bloqueo y generación de alertas.

• Valida que los registros del sistema y las métricas del SIEM reflejan correctamente los intentos anómalos.

• Ajusta thresholds y mejora reglas de detección.

✅ Qué se logra: Se verifica la eficacia de los mecanismos de protección ante ataques de diccionario SSH. Se ajustan los umbrales de respuesta automática y se confirma la correcta visualización de alertas en SIEM.

🧩 Ejemplo 2 – Abuso de clave privada robada

🔴 Red Team ataca

• Encuentra o exfiltra un archivo id_rsa sin passphrase desde un endpoint comprometido.

• Usa ssh -i id_rsa usuario@servidor para obtener acceso inmediato.

• Si el archivo está cifrado, crackea el passphrase con ssh2john + john o hashcat.

🔵 Blue Team defiende

• Exige passphrase para todas las claves privadas.

• Activa el uso de AuthorizedPrincipals o CertificateAuthority para validar identidad además de la clave.

• Aplica política de rotación periódica de claves SSH.

• Monitoriza conexiones con claves no reconocidas o desde ubicaciones inusuales.

🟣 Purple Team gestiona

• Simula un acceso no autorizado usando una clave previamente conocida en entorno de pruebas.

• Verifica qué logs (auth.log, auditd, Wazuh) capturan la acción.

• Crea alertas basadas en fingerprint de claves no autorizadas.

• Desarrolla playbooks para revocación y rotación automática de claves comprometidas.

✅ Qué se logra: Se detecta y mitiga el uso de claves SSH robadas. Se refuerzan las políticas de autenticación y se confirma la visibilidad de accesos anómalos por clave en SIEM.

🧩 Ejemplo 3 – Reverse SSH para pivoting interno encubierto

🔴 Red Team ataca

• Compromete un equipo interno (por ejemplo, un portátil de empleado).

• Inicia una sesión SSH inversa con túnel (ssh -R) hacia un servidor externo controlado por el atacante.

• Utiliza el canal cifrado para acceder de vuelta a la red interna desde Internet, eludiendo cortafuegos y NDR.

🔵 Blue Team defiende

• Restringe el uso de flags como AllowTcpForwarding, PermitTunnel, GatewayPorts en sshd_config.

• Monitoriza procesos SSH no estándar con auditd, Sysmon (Windows), osquery.

• Detecta tráfico anómalo saliente en puertos 22 con NDR o NetFlow.

• Aplica Zero Trust + segmentación por identidad + contexto.

🟣 Purple Team gestiona

• Simula el ataque con reverse SSH en un entorno controlado.

• Visualiza el tráfico saliente y lateral dentro del túnel mediante Zeek o Corelight.

• Genera alertas por conexiones salientes con ssh -R y evalúa la capacidad de contención.

• Documenta los IOC y genera dashboards de detección en Grafana, Kibana o SIEM.

✅ Qué se logra: Se comprueba si es posible eludir cortafuegos saliendo por SSH. Se refuerzan políticas de túneles inversos y se mejoran las capacidades de visibilidad y respuesta ante pivoting encubierto.

EJERCICIOS PURPLE TEAM – SSH (Secure Shell)

📍ATAQUE 1 – Nivel AVANZADO

🎯 Objetivo: Acceso inicial a SSH mediante fuerza bruta

🔴 Red Team:

Simulación:

• Utilizas Hydra para realizar un ataque de diccionario a un servidor con SSH expuesto.

bash:hydra -l root -P /usr/share/wordlists/rockyou.txt ssh://192.168.1.20

🔵 Blue Team:

Defensa:

• Implementas fail2ban para bloquear IPs tras varios intentos fallidos.

• Configuras sshd_config para:

  • Desactivar login de root

  • Limitar intentos (MaxAuthTries 3)

  • Cambiar el puerto por defecto (opcional)

bash:sudo nano /etc/ssh/sshd_config PermitRootLogin no MaxAuthTries 3

🟣 Purple Team:

Supervisión:

• Verificas que el SIEM reciba alertas desde /var/log/auth.log.

• Simulas varios intentos para asegurar que fail2ban reacciona correctamente.

• Documentas los tiempos de reacción y ajustes necesarios.

📍ATAQUE 2 – Nivel EXPERTO

🎯 Objetivo: Movimiento lateral usando clave privada robada

🔴 Red Team:

Simulación:

• Obtienes acceso inicial en una máquina (por otro vector) y encuentras un archivo id_rsa sin passphrase.

bash:ssh -i id_rsa user@192.168.1.30

• Pivotas lateralmente a otros sistemas sin levantar sospechas.

🔵 Blue Team:

Defensa:

• Monitorizas accesos SSH y revisas patrones inusuales de IP/origen.

• Correlacionas logs de autenticación con cambios en .ssh/authorized_keys.

• Automatizas revocación de claves con Ansible o scripts internos.

🟣 Purple Team:

Supervisión:

• Simulas la explotación y verificas si los accesos SSH con clave robada aparecen en el SIEM.

• Diseñas una rutina automatizada para:

  • Eliminar claves robadas.

  • Alertar a los administradores.

  • Forzar la regeneración del par de claves.

📍ATAQUE 3 – Nivel MAESTRO

🎯 Objetivo: Ataque MITM + Suplantación de clave de host (Trust On First Use bypass)

🔴 Red Team:

Simulación:

• Levantas un servidor SSH malicioso que responde en lugar del servidor real.

• Capturas credenciales si el cliente acepta la clave sin validación (con StrictHostKeyChecking=no).

bash:bettercap -iface wlan0 -caplet ssh-mitm

• También puedes utilizar honeypots como Cowrie para capturar interacciones.

🔵 Blue Team:

Defensa:

• Configuras StrictHostKeyChecking=yes en todos los clientes.

• Almacenas claves de host verificadas previamente en /etc/ssh/ssh_known_hosts.

• Desplegas scripts de compliance para comprobar que no se acepten claves nuevas automáticamente.

• Aplicación de certificados SSH firmados por autoridad (CA interna).

🟣 Purple Team:

Supervisión:

• Realizas ejercicios controlados con Bettercap y Evilginx2 para verificar reacciones.

• Validas si hay detección de cambio de clave de host en el SIEM.

• Automatizas auditoría de archivos known_hosts y detectas entradas sospechosas nuevas.

• Propones el uso de SSH CA signing para infraestructuras críticas.

🧬 OPCIONAL – BONUS CHALLENGE

🧠 Retar tu visión como arquitecta:

Plantea tú una regla de correlación para el SIEM que detecte movimientos sospechosos relacionados con SSH, como:

• Múltiples accesos SSH desde IPs nuevas en un corto periodo de tiempo.

• Acceso SSH exitoso seguido de transferencia de archivos con scp.

• Cambios en .ssh/authorized_keys fuera del horario laboral.

👉 ¿Te animas a diseñar esa regla con pseudocódigo o lógica?