Conceptos

Protocolos de seguridad de red

#auth#crypto#defense#network

Un protocolo de red define reglas para que procesos en dispositivos se comuniquen (formatos, estados, errores, tiempos, puertos). Los protocolos “seguros” añaden controles para…

Definición

Un protocolo de red define reglas para que procesos en dispositivos se comuniquen (formatos, estados, errores, tiempos, puertos). Los protocolos “seguros” añaden controles para:

  • Confidencialidad (evitar lectura del tráfico).
  • Integridad (evitar modificación silenciosa).
  • Autenticidad (validar con quién hablas / quién envió qué).

En la práctica, muchos “protocolos seguros” son:

  • el mismo protocolo de siempre,
  • más un contenedor criptográfico (principalmente SSL/TLS), lo que genera variantes como HTTPS, FTPS, SMTPS, POP3S, IMAPS, etc.

Contexto

  • Los protocolos se ubican en capas OSI/TCP-IP y suelen operar en puertos conocidos.
  • El hardening no es solo “activar TLS”: también implica evitar versiones inseguras, bloquear protocolos en texto plano y asegurar la administración remota.
  • Notas relacionadas:

Desarrollo (MIT-style)

1) Capa de aplicación — Web: HTTP vs HTTPS

HTTPS es HTTP + SSL/TLS. El objetivo es que, aunque un atacante capture paquetes, no pueda leer ni modificar el contenido de la sesión sin ser detectado.

Puntos clave del RAW:

  • HTTP (TCP/80) transmite datos en texto plano.
  • HTTPS (TCP/443) añade cifrado SSL/TLS: el contenido queda cifrado en tránsito.

Qué protege (modelo mental):

  • Confidencialidad: evita espionaje del contenido.
  • Integridad: evita alteración silenciosa de datos.
  • Autenticidad: depende de validación del certificado (CA/PKI).

Pitfalls típicos:

  • TLS mal configurado (versiones antiguas, suites débiles).
  • Validación de certificado incorrecta (clientes que “aceptan cualquier cert”).
  • “HTTPS” solo cifra cliente↔servidor; no corrige fallos de app (p.ej., auth rota).

2) Capa de aplicación — Transferencia de archivos: FTP vs FTPS

FTPS es una extensión de FTP que añade seguridad TLS al canal de control y/o al de datos.

Conceptos del RAW (FTP):

  • Dos canales: control (TCP/21) y datos (transferencia real).
  • Modos:
    • Activo: el servidor inicia la conexión de datos hacia el cliente (típicamente TCP/20).
    • Pasivo: el cliente inicia control y datos; el servidor proporciona un puerto aleatorio tras PASV.

FTPS (según RAW):

  • Explícito: se negocia TLS sobre el puerto 21 (puedes cifrar control, datos o ambos).
  • Implícito: TLS “por defecto” (puerto 990).

Pitfalls típicos:

  • Complejidad con NAT/firewalls (especialmente en pasivo por rangos de puertos).
  • Certificados/PKI operativa (expiración, trust store, rotación).

3) Capa de aplicación — Correo: SMTPS, POP3S e IMAPS

El RAW distingue:

  • SMTP: envío (push) de correos.
  • POP3: recuperación (download) desde servidor al cliente.
  • IMAP: sincronización del buzón (menciona el concepto).

Problema base: envío de credenciales y mensajes en texto plano.

Solución TLS:

  • SMTPS: SMTP encapsulado en TLS; usa STARTTLS para negociar cifrado.
    • Puertos mencionados: 465 y 587.
  • POP3S: POP3 encapsulado en TLS (también con STARTTLS).
    • Puertos: POP3 110 vs POP3S 995.

Matiz importante:

  • TLS protege cliente↔servidor, pero el servidor de correo puede seguir leyendo el contenido.
  • La seguridad end‑to‑end requiere un estándar como OpenPGP (ver siguiente sección).

4) Capa de aplicación — DNSSEC (seguridad de DNS)

El RAW muestra el riesgo: un host puede aceptar una respuesta DNS falsa si un atacante responde.

DNSSEC añade:

  • firmas a registros DNS (zona firma con clave privada),
  • y publicación de la clave pública para verificación.

Propiedades que aporta (según RAW):

  • Autenticidad e integridad de los datos DNS.

Limitación práctica:

  • DNSSEC no cifra DNS; no aporta confidencialidad por sí mismo.

5) Capa de aplicación — OpenPGP (correo cifrado extremo a extremo)

Cuando TLS no te basta (porque “confías” en servidores intermedios), OpenPGP permite:

  • Cifrar para que solo el destinatario lea.
  • Firmar para que el destinatario verifique autenticidad.

Del RAW:

  • Estándar: RFC 4880.
  • Implementación: GnuPG (GPG).
  • Nota: protege contenido, no necesariamente encabezados.

Ejemplo operativo (del RAW):

  • Generación de claves: gpg --gen-key
  • Cifrar + firmar + armor:
    • gpg --encrypt --sign --armor -r strategos@tryhackme.thm message.txt

6) Administración remota: Telnet vs SSH

El RAW compara:

  • Telnet: credenciales y comandos en texto plano (Wireshark lo revela).
  • SSH: cifrado; en capturas solo se ven banners/versiones/compatibilidades, no credenciales ni comandos.

Buenas prácticas (conceptuales):

  • Reemplazar Telnet/rlogin por SSH.
  • Restringir acceso (origen, MFA/keys, bastion) y auditar.

7) SSL/TLS (capas de presentación/sesión)

TLS actúa como “envoltorio” para cifrar protocolos (HTTP→HTTPS, FTP→FTPS, etc.). El RAW describe el handshake de forma resumida:

  1. ClientHello (versiones/ciphers/aleatorios)
  2. ServerHello + certificado + cipher elegido
  3. Autenticación del certificado (CA)
  4. Premaster cifrado con la pública del servidor
  5. Servidor descifra con su privada
  6. Derivación de claves de sesión (no se transmiten)
  7. Mensajes “finished” y canal cifrado listo

8) SOCKS5 (proxy a nivel de sesión)

El RAW describe SOCKS5 como protocolo proxy/relay:

  • El cliente se asocia al proxy (versión, auth, destino/puerto).
  • Luego el proxy reenvía tráfico hacia el destino.

Beneficios (según RAW):

  • Oculta detalles internos al enrutar por el proxy.
  • Puede ayudar a sortear censura basada en IP (en entornos autorizados).

Pitfall: SOCKS5 no implica cifrado por sí mismo; depende del protocolo encapsulado (p.ej., HTTPS/SSH).

9) IPsec (capa de red)

El RAW presenta IPsec (v3) con:

  • AH (Authentication Header): autenticidad + integridad (sin confidencialidad).
  • ESP (Encapsulating Security Payload): autenticidad + integridad + confidencialidad.
  • SA (Security Association): negociación de claves/algoritmos (p.ej., IKE).

Modos (según RAW):

  • Transporte: protege el payload (y según el caso encabezados) entre extremos.
  • Túnel: encapsula para proteger tráfico entre redes/segmentos (útil en site‑to‑site).

10) VPN (uso de IPsec o TLS)

Una VPN crea un canal privado sobre una red pública para conectar:

  • sedes (site‑to‑site),
  • usuarios remotos (remote access), usando principalmente:
  • IPsec (ESP) o
  • SSL/TLS (p.ej., OpenVPN).

Nota del RAW: protocolos antiguos como PPTP ya no se consideran seguros.

Ejemplos

Ejemplo 1 — Migración de protocolos “en claro” a versiones seguras

  • HTTP → HTTPS
  • FTP → FTPS (o alternativas seguras según entorno)
  • SMTP/POP3/IMAP → SMTPS/POP3S/IMAPS
  • Telnet/rlogin → SSH

Ejemplo 2 — Evidencia de riesgo (texto plano) vs cifrado

  • HTTP/Telnet: el contenido puede leerse en capturas.
  • HTTPS/SSH: el contenido queda cifrado (visibilidad limitada a metadatos y handshakes).

Ejemplo 3 — DNSSEC como defensa ante respuestas DNS falsas

El RAW muestra consultas/respuestas DNS con tshark (puerto 53). DNSSEC añade firma/validación para evitar aceptar respuestas no autorizadas.

Pitfalls

  • Confundir “TLS” con cifrado extremo a extremo: en correo, el servidor puede leer el contenido si no usas OpenPGP.
  • Dejar protocolos legacy habilitados “por compatibilidad” sin controles compensatorios.
  • Depender de proxies (SOCKS5) como si cifraran: el cifrado lo aporta el protocolo superior.
  • Aplicar DNSSEC esperando confidencialidad: DNSSEC aporta autenticidad/integridad, no ocultación.
  • Configuraciones FTPS incompatibles con firewalls/NAT: especialmente en modo pasivo con rangos mal definidos.
  • Usar VPNs antiguas (p.ej., PPTP) por facilidad.

Diagrama

Mapa rápido: capa → protocolo/seguridad

flowchart TD
  A[Capa aplicación] --> A1[HTTP → HTTPS (TLS)]
  A --> A2[FTP → FTPS (TLS)]
  A --> A3[SMTP/POP3/IMAP → *S (TLS)]
  A --> A4[DNS → DNSSEC (firmas)]
  A --> A5[OpenPGP (E2E)]
  S[Capa sesión/presentación] --> S1[TLS handshake]
  S --> S2[SOCKS5 proxy/relay]
  N[Capa red] --> N1[IPsec: AH/ESP + SA/IKE]
  N --> N2[VPN (IPsec o TLS)]

Flujo simplificado de correo: TLS vs OpenPGP

sequenceDiagram
  participant C as Cliente
  participant M as Servidor correo
  participant I as Internet
  participant R as Servidor destinatario

  C->>M: SMTPS/POP3S (TLS) ✅ cifrado en tránsito
  M->>I: SMTP (posible texto plano) ⚠️
  I->>R: SMTP/SMTPS (depende) ⚠️/✅
  Note over C,R: OpenPGP cifra el contenido E2E (servidores no leen contenido)

Referencias

  1. THM — OSI Model: https://tryhackme.com/room/osimodelzi
  2. THM — Protocols and Servers (HTTP): https://tryhackme.com/room/protocolsandservers
  3. THM — Principles of Security: https://tryhackme.com/room/principlesofsecurity
  4. THM — HTTP in detail: https://tryhackme.com/room/httpindetail
  5. THM — Cryptography Intro: https://tryhackme.com/room/cryptographyintro
  6. RFC 4880 (OpenPGP): https://www.rfc-editor.org/rfc/rfc4880
  7. Google (ejemplo de certificado/PKI en TLS): https://www.google.com/
  8. THM — Wireshark: https://tryhackme.com/room/wireshark
Título original en mis apuntes: Network Security Protocols