Protocolos Seguros de Red

¿Por qué necesitamos protocolos seguros?

El problema:
En ausencia de mecanismos de seguridad en red, cualquier sistema puede enviar paquetes aparentando ser otro, modificar información en tránsito o responder solicitudes sin ser el servicio legítimo, lo que impide distinguir entre tráfico válido y malicioso.

Los protocolos seguros de red surgen para resolver esta falta de confianza, permitiendo comprobar que los datos no han sido alterados, que las respuestas provienen de entidades autorizadas y que el acceso a los recursos se realiza bajo identidades verificables, reduciendo ataques de suplantación, manipulación de tráfico y accesos indebidos.

Solución:
Estos protocolos se utilizan para cifrar el tráfico de red, confirmar la identidad de los sistemas que se comunican, asegurar que los datos no sean modificados y controlar el acceso a recursos y dispositivos.

IPsec (Internet Protocol Security)

IPsec es un conjunto de protocolos cuyo objetivo es asegurar los paquetes IP, permitiendo verificar quién los envía, detectar si fueron alterados y proteger su contenido mediante cifrado.

Para lograrlo, utiliza dos protocolos principales para proteger los datos y uno para gestionar las claves, resolviendo el problema de que en una red común no se puede confiar en el origen ni en la integridad de los paquetes.

Capa de operación:
IPsec opera en la capa de red (capa 3 del modelo OSI). Esto significa que protege directamente los paquetes IP, antes de que lleguen a la capa de transporte. Por esta razón, cualquier tipo de tráfico puede ser protegido sin modificaciones adicionales.

IPsec funciona interceptando cada paquete IP, protegiéndolo con autenticación y/o cifrado según reglas ya negociadas, y permitiendo que el receptor verifique su origen y que no fue modificado antes de aceptarlo.

IPsec: Pasos de Funcionamiento

1

Definir qué se protege (Seleccionar el tráfico)

Primero se decide exactamente qué paquetes deben ir protegidos. Esto se define como una política: por ejemplo, el tráfico entre dos subredes, entre dos hosts específicos o hacia ciertos servicios.

2

Acordar identidad y reglas (Negociación inicial)

Luego, ambos extremos confirman que están hablando con la contraparte correcta y acuerdan cómo se va a aplicar la seguridad. Aquí se define si solo se verificará integridad y origen, o si también se cifrará.

3

Generar claves de sesión (Intercambio de claves)

Una vez acordadas las reglas, se generan claves temporales que se usarán para proteger el tráfico real. Estas claves son de sesión: se crean para ese intercambio y se cambian con el tiempo.

4

Proteger cada paquete (Seguridad por paquete)

Aquí ocurre lo esencial: cada paquete que coincide con la política es transformado antes de salir. Según lo acordado, se le agrega autenticación e integridad y, si aplica, se cifra el contenido.

5

Encapsular según el caso (Modo de operación)

Dependiendo del objetivo, la protección puede aplicarse de forma directa entre dos hosts o mediante un túnel que conecta redes enteras. Esto es lo que permite escenarios típicos como VPN de sitio a sitio.

6

Mantenerlo robusto (Rotación de claves)

Para que el canal no se vuelva predecible o vulnerable con el tiempo, las claves y parámetros se renuevan. Esto reduce el impacto si algún dato de sesión se filtra.

7

Comprobar operación (Monitoreo y validación)

Finalmente, se valida que lo que debía ir protegido realmente lo esté, y que la verificación esté rechazando lo que no corresponde.

Comandos IPsec en Linux (strongSwan)

┌─[root@vpn]─[~]

└──╼ $ ipsec status

Security Associations (1 up, 0 connecting):
site-to-site[1]: ESTABLISHED 5 minutes ago, 192.168.1.1 ... 192.168.2.1
✓ Túnel IPsec activo

└──╼ $ ipsec restart

Stopping strongSwan IPsec...
Starting strongSwan 5.9.8 IPsec [starter]...

DNSSEC (Domain Name System Security Extensions)

¿Qué es DNSSEC?

Extensión de seguridad para DNS que permite autenticar las respuestas DNS, asegurando que no han sido modificadas por un atacante (evita ataques de envenenamiento de caché y spoofing).

¿Qué resuelve?

El DNS tradicional no tiene mecanismos de autenticación, permitiendo que un atacante redirija el tráfico a sitios maliciosos. DNSSEC añade firmas digitales para validar que la respuesta proviene del servidor autoritativo.

¿Cómo funciona?

Utiliza criptografía de clave pública. Cada zona DNS firma sus registros con una clave privada, y los resolvers verifican la firma con la clave pública, creando una cadena de confianza desde la raíz.

Verificación DNSSEC con dig

┌─[hackwise@kali]─[~]

└──╼ $ dig +dnssec google.com

;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2
;; ANSWER SECTION:
google.com. 300 IN A 142.250.185.46
google.com. 300 IN RRSIG A 8 2 300 ...
✓ AD flag = Autenticado (DNSSEC válido)

Protocolos de Autenticación y Control de Acceso

RADIUS

Remote Authentication Dial-In User Service
Protocolo AAA ampliamente usado para autenticar usuarios en redes Wi-Fi empresariales, VPNs y equipos de red. Opera sobre UDP y combina autenticación y autorización en el mismo proceso.

TACACS+

Terminal Access Controller Access Control System Plus
Protocolo de Cisco para AAA que separa autenticación, autorización y contabilidad. Opera sobre TCP y cifra todo el paquete. Ideal para administración de dispositivos de red.

Kerberos

Protocolo de autenticación de red
Desarrollado por MIT, usa tickets cifrados y un centro de distribución de claves (KDC) para autenticar usuarios sin enviar contraseñas por la red. Ampliamente usado en entornos Windows (Active Directory).

Comandos Kerberos (kinit, klist)

┌─[usuario@dominio]─[~]

└──╼ $ kinit hackwise@HACKWISE.LOCAL

Password for hackwise@HACKWISE.LOCAL: ••••••••
✅ Ticket obtenido

└──╼ $ klist

Ticket cache: FILE:/tmp/krb5cc_1000
Default principal: hackwise@HACKWISE.LOCAL
Valid starting Expires Service principal
04/30/26 10:00:00 04/30/26 20:00:00 krbtgt/HACKWISE.LOCAL

Comparativa: RADIUS vs TACACS+

Característica	RADIUS	TACACS+
Protocolo de transporte	UDP	TCP
Cifrado	Solo contraseña	Todo el paquete
Separación AAA	Autenticación + Autorización juntas	AAA completamente separados
Uso principal	Acceso de usuarios (Wi-Fi, VPN)	Administración de dispositivos
Fabricante	Estándar (RFC 2865)	Cisco (propietario)

¿Cuál elegir?
RADIUS es más común para acceso de usuarios finales (WiFi empresarial, VPN). TACACS+ es preferido para administración de dispositivos de red (routers, switches) porque permite mayor granularidad y la conexión TCP es más fiable.

Laboratorio Práctico

Ejercicios para realizar en tu entorno:
1. Investiga cómo configurar un túnel IPsec entre dos máquinas Linux con strongSwan.
2. Prueba dig +dnssec con dominios que soporten DNSSEC (ej: .org, .se).
3. Configura un servidor RADIUS (FreeRADIUS) para autenticación Wi-Fi.
4. Simula autenticación Kerberos con kinit en un entorno con KDC.
5. Analiza tráfico IPsec con Wireshark y observa los paquetes ESP/AH.

Preguntas de Reflexión

1. ¿Por qué IPsec opera en capa 3 y qué ventaja tiene sobre TLS (capa de aplicación)?
2. ¿Qué ataque específico evita DNSSEC que el DNS tradicional no puede prevenir?
3. ¿Cuándo usarías RADIUS y cuándo TACACS+ en una empresa?
4. ¿Cómo logra Kerberos autenticar sin enviar contraseñas por la red?

Comandos y Herramientas de Referencia

ipsec status - Estado de conexiones IPsec
dig +dnssec dominio - Consulta DNSSEC
kinit usuario@REALM - Obtener ticket Kerberos
klist - Listar tickets Kerberos
kdestroy - Destruir tickets
Wireshark con filtro ipsec o esp - Analizar tráfico IPsec