🔐 Protocolos Seguros – Secure Protocols

Arquitectura, implementación segura, debilidades y gestión de protocolos de red.

1️. Explicación en Profundidad del Concepto

🔍 ¿Qué son los protocolos seguros?

Secure Protocols – Protocolos Seguros
Son conjuntos de reglas que rigen la transmisión de datos en redes, diseñados específicamente para proteger la confidencialidad, integridad y autenticación de la información mediante técnicas criptográficas.

🧪 Se diferencian de los protocolos "inseguros" porque cifran la información, utilizan métodos de autenticación, y previenen la manipulación de los datos en tránsito.

⚙️ ¿Cómo funcionan?

• Utilizan TLS/SSL – Transport Layer Security / Secure Sockets Layer para cifrar datos.

• Requieren certificados digitales emitidos por una CA – Certificate Authority.

• Incorporan autenticación mutua (usuario ↔ servidor).

• Aseguran el canal antes de transmitir datos sensibles.

📌 ¿Por qué son fundamentales?

• Sin cifrado, las credenciales, mensajes y archivos viajan en texto plano, visibles para cualquier atacante con acceso a la red.

• Son el pilar base del modelo CIA (Confidentiality, Integrity, Availability).

• Su uso es obligatorio en cualquier sistema profesional o regulado (ISO 27001, NIST, PCI-DSS).

🏰 Analogía 

Imagínate que vas a enviar una carta con tus datos bancarios.

• Con protocolo inseguro (HTTP, Telnet): Escribes la carta en una hoja abierta, sin sobre, y la entregas al cartero sin identidad verificada.

• Con protocolo seguro (HTTPS, SSH): Metes la carta en un sobre blindado, lacrado con tu sello personal, y la entregas a un mensajero verificado con credenciales.

2️. Ejemplos Prácticos

Aplicaciones reales y casos conocidos:

Protocolo Seguro: Qué reemplaza --Uso real

• HTTPS: HTTP -- Cifrado web: banca, e-commerce, logins
• SSH: Telnet -- Acceso remoto a servidores
• SFTP / FTPS: FTP -- Transferencia segura de archivos
• IMAPS / SMTPS: IMAP / SMTP -- Correo electrónico cifrado
• LDAPS: LDAP -- Autenticación segura en redes
• DNSSEC: DNS -- Protección contra falsificación de DNS

💣 Ejemplo de incidente por no usar protocolos seguros:

• Yahoo Data Breach (2013-2014): No aplicaban correctamente HTTPS → interceptación de cookies de sesión por MITM → 3 mil millones de cuentas comprometidas.

3️. Herramientas y Soluciones

Herramienta Función - Entorno

• OpenSSL Gestión de claves y certificados TLS - Linux/Unix
• Certbot (Let's Encrypt) Instalación automática de certificados SSL gratuitos - Web servers
• sshd (OpenSSH daemon) Servicio de SSH seguro - Linux/Unix
• Wireshark Análisis de tráfico (ver si está cifrado o no) - Red
• SSL Labs (Qualys) Escáner de seguridad de HTTPS - Web pública
• sslyze / testssl.sh Auditoría de configuración TLS - Local o remoto

🧰 Ejemplo real de configuración mínima:

bash# Habilitar HTTPS en NGINX (Linux) 

server { 

listen 443 ssl; 

ssl_certificate /etc/ssl/certs/miweb.crt;

ssl_certificate_key /etc/ssl/private/miweb.key; 

}

4️. Visión Estratégica: Red, Blue, Purple Team

🔴 Red Team – Cómo se explotan los protocolos inseguros

• Sniffing en HTTP, Telnet, FTP para robar credenciales.

• DNS spoofing sin DNSSEC.

• Suplantación de sesión en HTTP (cookie hijacking).

• Downgrade attacks: Forzar conexiones de HTTPS a HTTP (SSL Strip).

🔵 Blue Team – Cómo se protegen

• Configurar TLS fuerte (TLS 1.2 o 1.3), eliminar SSLv2/v3 y TLS 1.0/1.1.

• Usar certificados válidos y monitorizar fechas de expiración.

• Forzar HTTPS (HSTS – HTTP Strict Transport Security).

• Deshabilitar puertos inseguros en firewall (23, 21, 80).

• Monitorizar tráfico claro en Wireshark + alertas SIEM.

🟣 Purple Team – Cómo se validan y mejoran

• Ejecutar simulaciones de MITM y SSL Strip.

• Auditar puertos activos (nmap -sV).

• Revisar certificados caducados o mal configurados.

• Crear un plan de mejora continua: renovar claves, rotación, alertas de expiración.

5️. Resumen 

Los protocolos seguros son obligatorios en cualquier infraestructura moderna.
Cifran el tráfico, validan la identidad y protegen la integridad de los datos.
La gestión de certificados, claves y puertos debe ser estricta.
El uso de HTTP, Telnet, FTP u otros protocolos en texto plano debe evitarse completamente salvo en entornos aislados para pruebas controladas.

6️. Conceptos Clave

📘 Extras para entendimiento profundo:

🔁 ¿Por qué cuesta tanto implementar protocolos seguros?

• Gestión de certificados (emisión, renovación, expiración).

• Configuraciones más complejas.

• Errores de configuración → brechas (ej: certificado autofirmado).

• Dificultades para diagnosticar problemas en tráfico cifrado.

💡 Mejores prácticas:

• Siempre usar TLS 1.2 o 1.3.

• Mantener los certificados con validez corta + renovación automática.

• Usar Let's Encrypt + Certbot para facilitar gestión.

• Activar OCSP Stapling + HSTS para HTTPS.

• Configurar alertas para expiración de certificados.

Curiosidades y Claves Avanzadas

En esta sección exploramos lo que no se dice en las definiciones estándar: detalles que marcan la diferencia en la práctica profesional y que solo aprendes en el campo o en entornos altamente exigentes.

🔍 1. HTTPS ≠ Seguridad Total

• HTTPS solo cifra el canal, no verifica si el contenido del sitio es malicioso.

• Sitios de phishing pueden tener HTTPS válido (¡con candado verde y todo!).

• Solución: Implementar además detección de phishing, sandboxing, y políticas de navegación segura.

🧠 Aprendizaje: No te fíes del "candadito". Analiza el contenido, no solo el canal.

🔐 2. Certificados autofirmados no sirven para producción

• Un certificado autofirmado no ofrece validación por terceros → cualquiera puede crearlo.

• Muy usados en laboratorios, pero peligrosos si se filtran a entornos reales.

• Muchos ataques MITM han usado certificados autofirmados + usuarios que hacen clic en "Aceptar".

✅ En producción, usa siempre certificados emitidos por CA confiables (Let's Encrypt, DigiCert, etc).

🔁 3. Renovación de certificados expirada = Caída del sistema

• Hay incidentes globales por certificados que expiran y nadie renueva.

• Ejemplo real: Microsoft Teams (enero 2020) dejó de funcionar varias horas por un simple certificado no renovado.

🛎️ Lección: Automatiza la renovación de certificados (Certbot, scripts de monitoreo, alertas en SIEM).

🧱 4. TLS tiene versiones obsoletas que aún se usan

• TLS 1.0 y 1.1 son vulnerables a múltiples ataques (BEAST, POODLE).

• Muchos sistemas legacy aún los tienen habilitados "por compatibilidad".

• Dejar habilitadas versiones antiguas abre puertas al downgrade + explotación.

🔥 Buenas prácticas:

bash 

# En un servidor 

NGINX: ssl_protocols TLSv1.2 TLSv1.3;

🔎 5. SSH puede ser explotado si no se endurece

• Por defecto, muchos servidores permiten:

  • Login por usuario root

  • Autenticación por contraseña

  • Puerto 22 abierto al mundo

• Ataques por fuerza bruta vía SSH son constantes.

🔒 Fortalecimiento recomendado:

• Deshabilitar root login

• Forzar autenticación por clave pública

• Cambiar puerto por uno no estándar

• Usar fail2ban para bloquear IPs por intentos fallidos

📡 6. Telnet sigue activo en muchos dispositivos IoT

• Telnet aún se encuentra habilitado por defecto en miles de cámaras IP, routers baratos, impresoras.

• Es uno de los vectores más usados por botnets como Mirai o Mozi para propagar malware.

🛡️ Si haces pentesting o gestión de red, bloquea Telnet por completo en el firewall.

📑 7. La gestión de claves es el verdadero talón de Aquiles

• Implementar protocolos seguros no sirve de nada si no sabes:

  • Cómo almacenar claves privadas de forma segura

  • Cómo revocar un certificado comprometido

  • Qué hacer si tu CA ha sido hackeada

🧠 Recomendación:

• Aprende a usar HSM – Hardware Security Modules

• Usa Vaults como HashiCorp Vault o Azure Key Vault

🧬 8. UDP no es "malo", pero necesita control

• Aunque UDP es inseguro por naturaleza (sin cifrado, sin handshake), puede ser asegurado con:

  • DTLS – Datagram Transport Layer Security

  • VPNs que encapsulen el tráfico UDP (ej: WireGuard)

🔧 Ejemplo de aplicación real: VoIP (SIP) sobre UDP + TLS

📊 9. Todo protocolo seguro genera overhead

• Cada handshake TLS consume CPU, RAM y tiempo.

• En tráfico masivo (ej: bancos, e-commerce) esto puede afectar al rendimiento si no se optimiza.

🧠 Solución:

• Usa TLS session resumption

• Optimiza certificados y curvas de cifrado

🧙‍♀️ 10. Los atacantes también usan protocolos seguros

• Malware moderno como Emotet, Trickbot y Cobalt Strike se comunica vía HTTPS/443 cifrado, evadiendo inspección.

• Muchos firewalls no pueden ver lo que pasa dentro del canal cifrado.

💡 ¿Solución?

• TLS inspection (requiere CA interna y aceptación por endpoints)

• Integración con EDR/NDR + análisis de comportamiento

📌 Recapitulación rápida

Clave Avanzada Lección Oculta
HTTPS no basta Cifra ≠ Seguridad total
TLS 1.0 sigue activo Riesgo de downgrade
SSH mal configurado Entrada directa al sistema
Certificados autofirmados No sirven en producción
Telnet/FTP aún existen Deben ser erradicados
UDP puede asegurarse DTLS, VPN encapsulada
SSL Inspection ≠ trivial Requiere buena arquitectura
Gestión de claves = esencial Más que instalar, hay que mantener

¿Qué ganamos con esta parte?

• Comprensión profunda del riesgo real detrás de protocolos inseguros.

• Visión estratégica sobre cómo proteger, cómo mantener y cómo detectar errores en protocolos seguros.

• Mentalidad de arquitecta de seguridad y auditora de protocolos, no solo técnica.

🧪 EJERCICIOS PURPLE TEAM: Protocolos Seguros

💡 Objetivo: Comprender cómo se explotan, cómo se defienden y cómo se integran los controles para crear una infraestructura segura.

📘 Temas que pondremos en juego:

• HTTP vs HTTPS

• SSH vs Telnet

• FTP vs SFTP

• Certificados caducados

• Seguridad en la gestión de claves

• TLS downgrade y explotación MITM

EJEMPLO 1 – Ataque HTTP Inseguro + Captura de Credenciales (Nivel Avanzado)

🔴 Red Team: Ataque

Escenario: La aplicación web interna de RRHH usa HTTP en el puerto 80.

Pasos del atacante:

1. Realiza escaneo:

   nmap -p 80 192.168.1.10

2. Captura tráfico con Wireshark:

   • Filtro: http

   • Busca credenciales en formularios o cookies

Simula ataque MITM con SSLStrip:

sslstrip -l 8080 

iptables -t nat -A PREROUTING -p tcp --destination-port 80 -j REDIRECT --to-port 8080

Resultado esperado: Robo de credenciales o sesión.

🔵 Blue Team: Defensa

Medidas de protección:

1. Redirige HTTP → HTTPS forzado con HSTS en webserver.

2. Elimina el puerto 80 de la configuración si no se necesita:

   sudo ufw deny 80/tcp

3. Configura certificado TLS válido (Let's Encrypt o DigiCert).

4. Valida que no haya mixed content:

   curl -I https://intranet.local

🟣 Purple Team: Integración y mejora

Actividades conjuntas:

1. Escanea infraestructura con sslyze:

   sslyze --regular intranet.local

2. Simula tráfico HTTP para validar redirección automática.

3. Documenta respuesta del sistema ante intento de MITM.

4. Automatiza alerta SIEM para conexiones a puerto 80.

EJEMPLO 2 – Acceso Telnet Activo en un Router Legacy (Nivel Experto)

🔴 Red Team: Ataque

Escenario: Un router antiguo permite acceso por Telnet.

Ataque paso a paso:

1. Descubre servicio expuesto:

   nmap -p 23 192.168.0.1

2. Conecta y accede:

   telnet 192.168.0.1

3. Si hay credenciales por defecto (admin/admin), entra.

Impacto: Acceso total a la configuración de red.

🔵 Blue Team: Defensa

Mitigación inmediata:

1. Inhabilita Telnet en el router (interfaz web o consola).

2. Habilita SSH con autenticación por clave.

3. Cambia credenciales por defecto.

4. Añade firewall:

   sudo ufw deny 23/tcp

🟣 Purple Team: Validación y cierre de brechas

Acciones clave:

1. Usa nmap y telnet para validar exposición.

2. Implementa scanner automático de servicios inseguros con lynis.

3. Audita logs de acceso al router.

4. Genera política de "no protocolos inseguros en red corporativa".

EJEMPLO 3 – Simulación de TLS Downgrade + Falla en Certificado (Nivel Maestro)

🔴 Red Team: Ataque sofisticado

Escenario: Un sitio web permite conexiones TLS 1.0 por compatibilidad.

Ataque paso a paso:

1. Detecta versiones inseguras:

   testssl.sh https://portal.empresa.com

2. Usa mitmproxy para interceptar tráfico forzando downgrade:

   mitmproxy --mode transparent --ssl-insecure

3. Intercepta credenciales si cliente acepta versión débil.

🔵 Blue Team: Defensa experta

Refuerzo técnico:

1. Fuerza TLS 1.2+ en servidor:

   nginx

ssl_protocols TLSv1.2 TLSv1.3;

1. Configura cipher suites fuertes.

2. Aplica HSTS + revoca certificados caducados.

3. Establece monitoreo de expiración con:

   openssl s_client -connect portal.empresa.com:443

🟣 Purple Team: Evaluación avanzada

Actividades conjuntas:

1. Valida todos endpoints con sslyze y testssl.sh.

2. Simula intento de conexión TLS 1.0 y genera alerta SIEM.

3. Implementa reporte mensual de seguridad en protocolos.

🎯 DESAFÍO FINAL: ¿Qué protocolo inseguro vive aún en tu entorno?

Haz un barrido completo de tu red (real o de laboratorio) y responde:

1. ¿Hay algún puerto 21, 23, 80 aún activo?

2. ¿Se permite aún SSLv3, TLS 1.0 o 1.1?

3. ¿Hay certificados autofirmados o expirados en uso?

4. ¿Están habilitadas alertas de expiración de certificados?

5. ¿Se usa aún alguna app legacy con protocolos antiguos?

→ Documenta, mitiga, y crea una política.