Nota de estudio: Este tema es el núcleo de la seguridad informática. Conecta directamente con las preguntas Q2 (MFA), Q6 (cortafuegos), Q7 (malware), Q9 (permisos NTFS) y Q10 (redes seguras) del examen de la Politécnica. Sin entender criptografía no se puede entender HTTPS, VPN, firma digital, certificados SSL, ni por qué las contraseñas se almacenan con hash y sal.
La criptografía es la ciencia que estudia técnicas para proteger la información transformándola de manera que sea ilegible para quien no tenga autorización. Deriva del griego kryptos (oculto) y graphia (escritura).
En informática, la criptografía proporciona cuatro servicios de seguridad fundamentales:
| Servicio | Definición | Sin criptografía |
|---|---|---|
| Confidencialidad | Solo el destinatario autorizado puede leer el mensaje | Cualquiera que intercepte la comunicación puede leerla |
| Integridad | El mensaje no ha sido alterado en tránsito | Un atacante podría modificar los datos sin que nadie lo detecte |
| Autenticación | Verificar la identidad del emisor | No se puede confiar en que el interlocutor es quien dice ser |
| No repudio | El emisor no puede negar haber enviado el mensaje | Alguien puede negar haber firmado un contrato digital |
Terminología básica:
- Texto en claro (plaintext): datos originales, legibles.
- Texto cifrado (ciphertext): datos transformados, ilegibles sin la clave.
- Cifrado (encryption): proceso de transformar plaintext en ciphertext.
- Descifrado (decryption): proceso inverso.
- Clave (key): parámetro secreto que controla el cifrado/descifrado.
- Algoritmo criptográfico (cipher): la función matemática que realiza la transformación.
- Criptoanálisis: ciencia de intentar romper sistemas criptográficos.
Principio de Kerckhoffs (1883): la seguridad de un sistema criptográfico debe depender únicamente del secreto de la clave, nunca del secreto del algoritmo. El algoritmo puede ser público; la clave debe ser secreta. Los algoritmos modernos (AES, RSA, SHA-256) son completamente públicos y analizados por la comunidad científica mundial.
Analogía: una caja fuerte cuyo diseño es público (todos saben cómo funciona el mecanismo) pero cuya combinación es secreta. El fabricante puede mostrar los planos; lo que protege es la combinación específica.
En la criptografía simétrica, la misma clave se usa tanto para cifrar como para descifrar. Ambas partes deben conocer y mantener en secreto esa clave.
Emisor Receptor
│ │
│ Texto claro │
│ ↓ │
│ [CIFRADO con clave K] │
│ ↓ │
│ Texto cifrado ──────────────► │
│ │ [DESCIFRADO con clave K]
│ │ ↓
│ │ Texto claro
Cifrado en bloque (block cipher): divide el mensaje en bloques de tamaño fijo (p.ej. 128 bits) y cifra cada bloque.
Cifrado en flujo (stream cipher): genera un flujo pseudoaleatorio de bits (keystream) que se combina con el mensaje bit a bit mediante XOR.
| Modo | Nombre | Características | Uso |
|---|---|---|---|
| ECB | Electronic Codebook | Cada bloque cifrado independientemente. Inseguro: bloques iguales → ciphertext igual (revela patrones) | Nunca usar |
| CBC | Cipher Block Chaining | Cada bloque se combina con el anterior antes de cifrar. Requiere IV (vector de inicialización) | Cifrado de disco, TLS antiguo |
| CTR | Counter Mode | Convierte el bloque en cifrado de flujo usando un contador. Paralelizable | TLS moderno |
| GCM | Galois/Counter Mode | CTR + autenticación integrada (AEAD). Detecta manipulación del ciphertext | TLS 1.3, AES-GCM |
Por qué GCM es el estándar actual: proporciona confidencialidad (cifrado) e integridad (autenticación) en una sola operación. AES-128-GCM y AES-256-GCM son los conjuntos de cifrado preferidos en TLS 1.3.
El gran problema de la criptografía simétrica: ¿cómo comparten la clave de forma segura dos partes que nunca se han visto? Si el canal no es seguro, un atacante puede interceptar la clave. Este problema se soluciona con la criptografía asimétrica y el protocolo Diffie-Hellman.
Ventajas:
- Velocidad: entre 100 y 10.000 veces más rápida que la criptografía asimétrica. AES puede cifrar a varios GB/s en hardware moderno.
- Eficiencia: poco overhead computacional.
- Adecuada para grandes volúmenes de datos: cifrado de disco, streaming cifrado.
Inconvenientes:
- Problema de distribución de claves: compartir la clave de forma segura es difícil.
- Escalabilidad: en un grupo de N personas, se necesitan N×(N-1)/2 claves distintas. Para 1000 personas: ~500.000 claves.
- No proporciona no repudio: cualquiera de los dos extremos podría haber generado el mensaje.
La criptografía asimétrica resuelve el problema de distribución de claves mediante pares de claves matemáticamente relacionadas:
La relación matemática garantiza: lo que se cifra con una solo puede descifrarse con la otra del mismo par. Aunque conozcas la clave pública, es computacionalmente imposible derivar la clave privada.
Uso 1: Cifrado / Confidencialidad
Emisor (tiene la clave pública de Bob) Bob (tiene su clave privada)
│ │
│ Cifra con clave pública de Bob ──────► │
│ │ Descifra con su clave privada
│ │ (SOLO Bob puede descifrar)
Uso 2: Firma digital / Autenticación e integridad
Alice (tiene su clave privada) Receptor (tiene la clave pública de Alice)
│ │
│ Firma con su clave PRIVADA ──────────► │
│ │ Verifica con clave PÚBLICA de Alice
│ │ (cualquiera puede verificar,
│ │ pero solo Alice pudo firmar)
RSA (Rivest–Shamir–Adleman, 1977):
Su seguridad se basa en la dificultad de factorizar números enteros muy grandes en sus factores primos.
ECC (Elliptic Curve Cryptography):
Basada en la estructura algebraica de curvas elípticas sobre cuerpos finitos. Su seguridad se basa en el Problema del Logaritmo Discreto en curvas elípticas (ECDLP).
La ventaja clave: ECC proporciona el mismo nivel de seguridad que RSA con claves mucho más pequeñas:
| Nivel de seguridad | RSA | ECC |
|---|---|---|
| 80 bits | 1024 bits | 160 bits |
| 112 bits | 2048 bits | 224 bits |
| 128 bits | 3072 bits | 256 bits |
| 192 bits | 7680 bits | 384 bits |
| 256 bits | 15360 bits | 512 bits |
Una clave ECC-256 equivale en seguridad a RSA-3072. Esto significa operaciones más rápidas, menor tamaño de certificados y es ideal para dispositivos con recursos limitados (IoT, tarjetas inteligentes, móviles).
Curvas más usadas:
- P-256 (prime256v1 / secp256r1): curva del NIST, muy usada en TLS y certificados.
- Curve25519: diseñada por Daniel Bernstein. Muy eficiente, sin parámetros sospechosos. Usada en WireGuard, Signal, SSH moderno.
- P-384, P-521: para mayor seguridad (gobierno, militar).
Diffie-Hellman (DH) y ECDH:
Protocolo que permite a dos partes establecer una clave secreta compartida a través de un canal público, sin haberla intercambiado previamente.
Alice Bob
Genera secreto privado a Genera secreto privado b
Calcula: A = g^a mod p Calcula: B = g^b mod p
Envía A públicamente ─────────► Recibe A
Recibe B ◄───────────────────── Envía B públicamente
Calcula: K = B^a mod p Calcula: K = A^b mod p
K = (g^b)^a = g^(ab) K = (g^a)^b = g^(ab)
¡Ambos obtienen la misma K sin haberla enviado!
Un atacante que intercepta A y B no puede calcular K sin conocer a o b, porque el problema del logaritmo discreto es computacionalmente inviable.
ECDHE (Elliptic Curve Diffie-Hellman Ephemeral): variante de DH usando curvas elípticas con claves efímeras (nuevas en cada sesión). Es el mecanismo de intercambio de claves en TLS 1.3 y proporciona Perfect Forward Secrecy.
Perfect Forward Secrecy (PFS): si un atacante graba el tráfico cifrado de hoy y en el futuro consigue la clave privada del servidor, NO puede descifrar el tráfico pasado porque las claves de sesión eran efímeras y ya no existen. TLS 1.3 exige PFS obligatoriamente.
Ventajas:
- Resuelve el problema de distribución de claves.
- Proporciona no repudio.
- Escalabilidad: N personas necesitan N pares de claves (no N² como en simétrico).
- Base de toda la infraestructura PKI y certificados digitales.
Inconvenientes:
- Entre 100 y 10.000 veces más lenta que la criptografía simétrica.
- No apta para cifrar grandes volúmenes de datos directamente.
- Seguridad condicionada al secreto de la clave privada.
En la práctica, ningún sistema usa exclusivamente un solo tipo de criptografía. Se usa un esquema híbrido:
1. [Asimétrico] Se genera una clave de sesión aleatoria (simétrica, ej. AES-256)
2. [Asimétrico] La clave de sesión se cifra con la clave pública del receptor (RSA/ECDH)
3. [Simétrico] Los datos se cifran con la clave de sesión (AES-GCM)
4. Se envían: {clave de sesión cifrada} + {datos cifrados}
5. [Asimétrico] El receptor descifra la clave de sesión con su clave privada
6. [Simétrico] El receptor descifra los datos con la clave de sesión
HTTPS/TLS usa exactamente este esquema: RSA o ECDH para el intercambio de clave + AES-GCM para el cifrado de los datos.
Una función hash criptográfica transforma una entrada de cualquier tamaño en una salida de tamaño fijo (el "digest" o "resumen"), con las siguientes propiedades:
hash("Hola mundo") = a591a6d40bf420404a011733cfb7b190d62c65bf0bcda32b
hash("hola mundo") = d5fdde47e9c2a7e62a7389fd8d32485e9f9b3e81dbe44da7
← un carácter diferente → hash completamente distinto
| Algoritmo | Tamaño del hash | Estado | Uso |
|---|---|---|---|
| MD5 | 128 bits (32 hex) | Roto, no usar | Solo checksums no criptográficos |
| SHA-1 | 160 bits (40 hex) | Roto (2017, Google SHAttered) | Obsoleto. Deprecado en certificados SSL desde 2017 |
| SHA-256 | 256 bits (64 hex) | Seguro | Bitcoin, certificados TLS, firmado de código, contraseñas |
| SHA-384 | 384 bits (96 hex) | Seguro | TLS 1.3, documentos gubernamentales |
| SHA-512 | 512 bits (128 hex) | Seguro | Almacenamiento de contraseñas en Linux (/etc/shadow) |
| SHA-3 | Variable | Seguro | Alternativa a SHA-2 con diseño diferente (keccak) |
| bcrypt | 184 bits + sal | Seguro, deliberadamente lento | Almacenamiento de contraseñas |
| Argon2 | Variable | Seguro, resistente a GPU | El mejor para contraseñas hoy (ganador PHC 2015) |
| BLAKE3 | 256 bits | Seguro, muy rápido | Checksums de alta velocidad |
1. Almacenamiento seguro de contraseñas:
Las contraseñas nunca se almacenan en texto plano ni cifradas. Se almacena su hash.
Problema con el hash simple: si dos usuarios tienen la misma contraseña, tienen el mismo hash. Un atacante con una tabla de hashes precalculados (rainbow table) puede invertir millones de hashes instantáneamente.
Solución: sal (salt): valor aleatorio único generado por usuario que se concatena a la contraseña antes de hashear:
hash("password123") = 5baa61... ← siempre el mismo, tabla rainbow útil
hash("password123" + "x7Kq2mP9") = a3f8d1... ← diferente para cada usuario
hash("password123" + "9nL4rT2v") = b7e2c9... ← aunque misma contraseña
En Linux, /etc/shadow almacena el formato $algoritmo$sal$hash:
$6$x7Kq2mP9$[hash] → SHA-512 ($6$) con sal x7Kq2mP9
$2b$12$[sal+hash] → bcrypt con 12 rondas de cost factor
$argon2id$...$[sal+hash] → Argon2id
bcrypt y Argon2 son especialmente resistentes porque son intencionalmente lentos (ajustable mediante factor de coste). Verificar una contraseña tarda ~100 ms, aceptable para el usuario. Pero para un atacante intentando 1 millón de contraseñas: 100.000 segundos (>27 horas) vs fracciones de segundo con SHA-256 simple.
Argon2 también requiere mucha RAM, lo que dificulta los ataques con GPU o ASIC especializados.
2. Integridad de datos y verificación de ficheros:
sha256sum ubuntu-22.04.iso
# Comparar con el hash oficial en la web para verificar que el ISO
# no fue alterado (corrupción o ataque man-in-the-middle)
3. Firma digital (en combinación con clave asimétrica):
En lugar de firmar el mensaje completo (lento con RSA), se firma el hash del mensaje:
Firma = Cifrar_con_clave_privada( hash(mensaje) )
Verificación: hash(mensaje) == Descifrar_con_clave_pública(Firma)
4. HMAC (Hash-based Message Authentication Code):
Combina una función hash con una clave secreta para proporcionar autenticación de integridad. Verifica que el mensaje proviene de alguien que conoce la clave y que no ha sido modificado.
HMAC = hash(clave || mensaje) (simplificado)
5. Blockchain: cada bloque contiene el hash del bloque anterior, formando una cadena donde modificar un bloque requiere recalcular todos los bloques siguientes.
La firma digital es el mecanismo criptográfico que proporciona autenticación, integridad y no repudio a documentos o mensajes digitales. Es el equivalente digital de la firma manuscrita, pero con garantías matemáticas mucho más fuertes.
═══════════ FIRMA ═══════════
Documento original
│
▼
hash(documento) ← SHA-256, SHA-384...
│
▼
Cifrar hash con ──► FIRMA DIGITAL
clave PRIVADA del firmante
Enviar: [Documento] + [Firma digital] + [Certificado del firmante]
═══════════ VERIFICACIÓN ═══════════
Receptor:
1. hash_recibido = Descifrar_con_clave_PÚBLICA_del_firmante(Firma digital)
2. hash_calculado = hash(Documento recibido)
3. Si hash_recibido == hash_calculado → Firma VÁLIDA
Si son distintos → Documento alterado O firma falsa
Diferencia crítica firma digital vs firma manuscrita: la firma manuscrita es siempre la misma independientemente del documento. La firma digital es diferente para cada documento (depende del hash del contenido). Copiar la firma de un documento a otro es imposible porque los hashes son diferentes.
| Algoritmo | Base matemática | Tamaño de firma | Estado |
|---|---|---|---|
| RSA-PKCS#1 | Factorización de enteros | 256 bytes (2048 bits) | Seguro, ubicuo |
| RSA-PSS | Factorización (probabilístico) | 256 bytes | Más seguro que PKCS#1, preferido |
| ECDSA | Curvas elípticas (DLP) | 64 bytes (P-256) | Seguro, eficiente |
| EdDSA (Ed25519) | Curvas de Edwards | 64 bytes | Moderno, muy seguro y rápido |
| DSA | Logaritmo discreto | 40-60 bytes | Obsoleto |
Ed25519 es el estándar moderno recomendado para SSH keys, tokens de autenticación y firmas en general.
La criptografía de clave pública tiene un problema práctico fundamental: ¿cómo sé que la clave pública que me están dando realmente pertenece a quien dice ser?
Ataque Man-in-the-Middle (MitM):
Alice quiere comunicarse con "banco.com"
│
│ intercepta la comunicación
▼
[ATACANTE]
│
▼ presenta su propia clave pública haciéndose pasar por banco.com
Alice cifra datos con la clave del ATACANTE (cree que es de banco.com)
El ATACANTE descifra, lee/modifica, y reencripta con la clave real de banco.com
banco.com responde al ATACANTE, que hace lo mismo en sentido inverso
Alice y banco.com creen hablar directamente, pero el ATACANTE ve todo
La solución son los certificados digitales: documentos que vinculan una clave pública con la identidad de su propietario, firmados por una tercera parte de confianza.
El estándar X.509 define el formato de los certificados digitales. Es el estándar de facto para certificados en TLS/SSL, firma de código, email seguro, etc.
Un certificado X.509 contiene:
┌─────────────────────────────────────────────────────┐
│ CERTIFICADO X.509 v3 │
├─────────────────────────────────────────────────────┤
│ Versión: 3 │
│ Número de serie: 0A:1B:2C:3D:... (único en la CA) │
│ Algoritmo de firma: sha256WithRSAEncryption │
├─────────────────────────────────────────────────────┤
│ Emisor (Issuer): │
│ CN=DigiCert TLS RSA SHA256 2020 CA1 │
│ O=DigiCert Inc │
│ C=US │
├─────────────────────────────────────────────────────┤
│ Validez: │
│ Válido desde: 2024-01-15 00:00:00 │
│ Válido hasta: 2025-01-14 23:59:59 │
├─────────────────────────────────────────────────────┤
│ Sujeto (Subject): │
│ CN=www.banco.com │
│ O=Banco Ejemplo S.A. │
│ L=Madrid │
│ C=ES │
├─────────────────────────────────────────────────────┤
│ Clave pública del sujeto: │
│ Algoritmo: RSA 2048 bits │
│ Valor: [clave pública en formato DER] │
├─────────────────────────────────────────────────────┤
│ Extensiones: │
│ Subject Alternative Names (SAN): │
│ DNS: www.banco.com │
│ DNS: banco.com │
│ DNS: m.banco.com │
│ Key Usage: Digital Signature, Key Encipherment │
│ Extended Key Usage: TLS Web Server Authentication │
│ CRL Distribution Points: http://crl.digicert.com/ │
│ Authority Information Access: │
│ OCSP: http://ocsp.digicert.com │
│ CA Issuers: http://cacerts.digicert.com/... │
│ Basic Constraints: CA:FALSE │
├─────────────────────────────────────────────────────┤
│ FIRMA DE LA CA: │
│ [Firma digital de DigiCert sobre todo lo anterior] │
└─────────────────────────────────────────────────────┘
¿Qué garantiza la firma de la CA? Que la CA verificó que la entidad propietaria del dominio banco.com es Banco Ejemplo S.A. y que la clave pública incluida les pertenece. Si el certificado fuera falsificado, la firma de la CA no coincidiría y el navegador lo rechazaría.
| Tipo | Validación | Tiempo emisión | Costo | Indicador en navegador |
|---|---|---|---|---|
| DV (Domain Validation) | Solo verifica que controlas el dominio | Minutos | Bajo (~0-50€/año) | Candado verde, sin nombre empresa |
| OV (Organization Validation) | Verifica dominio + existencia legal de la organización | Días | Medio (~100-300€/año) | Candado verde, organización visible en certificado |
| EV (Extended Validation) | Verificación exhaustiva: dominio + organización + dirección física + estado legal | Semanas | Alto (~300-1000€/año) | Antiguamente barra verde con nombre empresa |
¿Por qué Let's Encrypt es gratuito? Emite solo certificados DV, automatizados completamente mediante el protocolo ACME. No verifica identidad de la organización, solo control del dominio.
Subject Alternative Names (SAN): lista de dominios que cubre el certificado. Un certificado wildcard *.banco.com cubre todos los subdominios de primer nivel pero no los de nivel dos.
Key Usage y Extended Key Usage:
- Digital Signature: firma de datos.
- Key Encipherment: cifrado de clave de sesión (servidores TLS con RSA).
- Key Agreement: intercambio de claves (servidores TLS con ECDH).
- TLS Web Server Authentication: el certificado puede autenticar un servidor HTTPS.
- TLS Web Client Authentication: autenticación de cliente (certificados de cliente).
- Code Signing: firma de ejecutables y código.
- Email Protection: S/MIME para email seguro.
Basic Constraints: si CA:TRUE, este certificado es de una CA y puede firmar otros certificados. Si CA:FALSE, es un certificado de entidad final que no puede firmar certificados.
Certificados de servidor (TLS/SSL):
Permiten a los clientes verificar que están hablando con el servidor legítimo. Usados en HTTPS, FTPS, SMTPS, etc.
Certificados de cliente:
Permiten al servidor verificar la identidad del cliente. Autenticación mutua (mTLS: mutual TLS). Muy usado en VPNs corporativas, APIs entre servicios internos, acceso a sistemas críticos.
Certificados de firma de código (Code Signing):
Garantizan que un ejecutable fue producido por el firmante y no ha sido modificado. Windows muestra una advertencia al ejecutar código sin firma.
Certificados de email (S/MIME):
Permiten firmar y cifrar emails. El receptor puede verificar que el email viene del remitente legítimo y no ha sido alterado.
Certificados de CA (Certification Authority):
Tienen Basic Constraints: CA:TRUE. Los certificados raíz (Root CA) están autofirmados y vienen preinstalados en el SO y navegadores.
Certificados personales / DNI electrónico:
Emitidos a personas físicas por CAs reconocidas oficialmente. En España: FNMT (Fábrica Nacional de Moneda y Timbre) o el DNI electrónico emitido por la Policía. Permiten identificarse digitalmente ante la administración pública y firmar documentos con valor legal.
Un certificado puede quedar inválido antes de su fecha de expiración (clave privada comprometida, error de emisión, cese de actividad). Existen dos mecanismos para comprobarlo:
CRL (Certificate Revocation List):
Lista firmada digitalmente que la CA publica periódicamente con los números de serie de los certificados revocados. El cliente descarga la lista y comprueba si el certificado en cuestión aparece.
- Ventaja: simple.
- Inconveniente: puede crecer mucho, no es en tiempo real (actualización periódica).
OCSP (Online Certificate Status Protocol):
El cliente consulta en tiempo real a un servidor OCSP de la CA si un certificado concreto sigue siendo válido.
- Ventaja: respuesta en tiempo real, más eficiente que descargar toda la CRL.
- Inconveniente: depende de la disponibilidad del servidor OCSP.
OCSP Stapling: el propio servidor web incluye ("adjunta") en el handshake TLS una respuesta OCSP firmada recientemente por la CA. Evita que el cliente tenga que consultar al servidor OCSP por separado, mejorando la privacidad y el rendimiento.
Una PKI (Public Key Infrastructure — Infraestructura de Clave Pública) es el conjunto de hardware, software, políticas, procedimientos y estándares necesarios para crear, gestionar, distribuir, usar, almacenar y revocar certificados digitales.
La PKI es lo que hace que HTTPS funcione de forma automática en millones de webs. Cuando tu navegador se conecta a https://banco.com, automáticamente verifica el certificado del banco contra la PKI sin que el usuario haga nada.
La CA es el componente central de la PKI. Es la entidad de confianza que:
- Verifica la identidad de quien solicita un certificado.
- Emite certificados firmando digitalmente su contenido con su clave privada.
- Mantiene y publica la lista de certificados revocados (CRL).
- Publica su propia clave pública para que todos puedan verificar sus firmas.
La seguridad de toda la PKI depende de la seguridad de la CA. Si la clave privada de la CA es comprometida, todos los certificados que emitió son potencialmente falsificables. Las CAs raíz almacenan sus claves en HSMs (Hardware Security Modules) certificados, en instalaciones físicamente seguras, con procedimientos de multi-persona (se necesitan varias personas simultáneamente para acceder a la clave).
Ejemplo histórico: en 2011, DigiNotar (CA holandesa) fue comprometida. Atacantes emitieron certificados fraudulentos para Google.com, Gmail.com y muchos otros dominios, permitiendo ataques MitM a usuarios iraníes. DigiNotar fue eliminada de todos los almacenes de confianza y quebró en semanas.
Entidad intermediaria que realiza la verificación de identidad de los solicitantes de certificados antes de aprobar la emisión. La CA delega la verificación a la RA pero se reserva la firma. En muchas PKIs pequeñas, CA y RA están integradas.
Entidad que responde a las consultas sobre el estado de un certificado (OCSP). Puede estar integrada en la CA o ser un componente independiente para distribuir la carga de consultas.
Base de datos o directorio LDAP donde se publican los certificados emitidos y las CRLs. Permite a cualquier entidad descargar certificados públicos y comprobar su estado de revocación.
Servicio que acredita que un documento o firma existía en un momento determinado. Emite un sello de tiempo (timestamp) firmado digitalmente que incluye el hash del documento y el instante temporal verificado. Esencial para la validez a largo plazo de documentos firmados (cuando el certificado del firmante ha expirado, el sello de tiempo demuestra que la firma fue válida en el momento de realizarla).
Las PKIs se organizan en una jerarquía de confianza:
┌─────────────────┐
│ ROOT CA │ ← Autofirmada. Máxima confianza.
│ (raíz) │ Clave privada offline o en HSM.
└────────┬────────┘
│ firma los certificados de las CAs intermedias
┌─────────────┴──────────────┐
▼ ▼
┌──────────────────┐ ┌──────────────────┐
│ CA Intermedia 1 │ │ CA Intermedia 2 │
│ (Sub-CA) │ │ (Sub-CA) │
└────────┬─────────┘ └────────┬─────────┘
│ firma certificados finales │
┌─────┴──────┐ ┌─────┴──────┐
▼ ▼ ▼ ▼
Cert. Cert. Cert. Cert.
servidor cliente servidor código
¿Por qué una jerarquía y no una sola CA raíz?
- Seguridad: la Root CA puede mantenerse offline. Solo se usa para firmar certificados de CAs intermedias, reduciendo la exposición de su clave privada.
- Escalabilidad: diferentes CAs intermedias para diferentes propósitos o regiones.
- Revocación limitada: si se compromete una CA intermedia, solo se revocan sus certificados, no toda la jerarquía.
Cadena de certificados (certificate chain):
Para validar un certificado de servidor, el cliente verifica toda la cadena:
Certificado del servidor → firmado por CA Intermedia
CA Intermedia → firmada por Root CA
Root CA → autofirmada (confiada por el SO/navegador)
Si cualquier eslabón de la cadena falla (expirado, revocado, firma inválida), la validación falla.
El trust store es la colección de certificados raíz (Root CA) en los que el SO o navegador confía de forma predeterminada. Viene preinstalado con el SO o el navegador.
certmgr.msc o mediante GPO en entornos de dominio./etc/ssl/certs/ o paquete ca-certificates. Las aplicaciones pueden usar NSS (Mozilla) o el almacén del sistema.En entornos corporativos, los administradores añaden el certificado raíz de la CA corporativa al trust store de todos los equipos mediante GPO (Windows) o gestión de configuración (Ansible, Puppet en Linux). Esto permite que los certificados emitidos por la CA corporativa sean confiados automáticamente.
| Característica | PKI Pública (ej. DigiCert) | PKI Corporativa (ej. Microsoft AD CS) |
|---|---|---|
| Ámbito | Internet, cualquier cliente | Interna, clientes en el dominio |
| Trust store | Incluida por defecto en SOs | Hay que distribuirla manualmente o por GPO |
| Coste | De pago (DV gratis con Let's Encrypt) | Gratuita una vez implantada |
| Validación | Verificada por tercero | Gestionada internamente |
| Uso típico | Webs públicas, correo externo | VPN, WiFi 802.1X, mTLS interno, correo interno firmado |
TLS es el protocolo que proporciona comunicaciones seguras sobre una red. Es el sucesor de SSL (ya obsoleto y vulnerable). Cuando ves https:// en el navegador, estás usando TLS.
Versiones:
| Versión | Estado | Notas |
|---|---|---|
| SSL 2.0 | Roto, prohibido | Vulnerabilidades críticas |
| SSL 3.0 | Roto, prohibido | Vulnerable a POODLE |
| TLS 1.0 | Deprecado (2020) | Vulnerable a BEAST, POODLE |
| TLS 1.1 | Deprecado (2020) | Mejoras menores sobre 1.0 |
| TLS 1.2 | Aceptable | Ampliamente usado, seguro si bien configurado |
| TLS 1.3 | Recomendado | Más rápido, PFS obligatorio, eliminó algoritmos débiles |
Cliente Servidor
│ │
│── ClientHello ─────────────────────────►│
│ (versiones TLS soportadas, │
│ cipher suites, clave pública ECDHE) │
│ │
│◄─ ServerHello ───────────────────────────│
│ (versión elegida, cipher suite, │
│ clave pública ECDHE del servidor, │
│ certificado del servidor, │
│ datos cifrados ya desde aquí) │
│ │
│ [Ambos calculan la clave de sesión │
│ con ECDHE: K = g^(ab) mod p] │
│ │
│── Finished ──────────────────────────────►│ (cifrado con K)
│ │
│◄─ Finished ──────────────────────────────│ (cifrado con K)
│ │
│════════ DATOS CIFRADOS CON AES-GCM ══════│
En TLS 1.3, el handshake es 1-RTT (1 Round Trip Time) vs 2-RTT de TLS 1.2, lo que reduce la latencia. Además existe 0-RTT para reconexiones (con las implicaciones de seguridad que conlleva).
Una cipher suite es una combinación de algoritmos criptográficos que define cómo se realiza el intercambio de claves, la autenticación, el cifrado y la integridad en una sesión TLS.
Formato TLS 1.2: TLS_[Intercambio]_[Autenticación]_WITH_[Cifrado]_[Hash]
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
│ │ │ │
│ │ │ └─ Hash para HMAC: SHA-384
│ │ └─── Cifrado simétrico: AES-256-GCM
│ └────────────── Autenticación: RSA (certificado del servidor)
└──────────────────── Intercambio de claves: ECDHE (con PFS)
TLS 1.3 simplifica esto: solo 5 cipher suites, todas con PFS, y elimina algoritmos obsoletos (RC4, 3DES, SHA-1, RSA para intercambio de claves):
TLS_AES_256_GCM_SHA384 ← Preferida
TLS_CHACHA20_POLY1305_SHA256 ← Alternativa (donde no hay AES hardware)
TLS_AES_128_GCM_SHA256
Técnica en la que la aplicación (normalmente móvil) almacena el hash del certificado o de la clave pública del servidor esperado. Si el servidor presenta un certificado diferente (aunque sea válido y firmado por una CA de confianza), la conexión se rechaza. Protege contra CAs comprometidas. Ejemplo: las apps bancarias usan certificate pinning para evitar ataques MitM aunque el atacante tenga un certificado válido de otra CA.
Autenticación (AuthN): proceso de verificar que alguien o algo es quien dice ser. Responde a la pregunta: ¿Quién eres?
Autorización (AuthZ): proceso de determinar qué acciones o recursos puede acceder una entidad ya autenticada. Responde a: ¿Qué puedes hacer?
Auditoría / Accounting: registro de las acciones realizadas por las entidades autenticadas. Responde a: ¿Qué hiciste?
Mnemotecnia AAA: Authentication, Authorization, Accounting. Marco de seguridad completo (usado en RADIUS, TACACS+).
Los factores de autenticación se clasifican en tres categorías:
| Factor | Categoría | Ejemplos | Riesgo principal |
|---|---|---|---|
| Algo que sabes | Conocimiento | Contraseña, PIN, pregunta secreta | Robo, phishing, fuerza bruta |
| Algo que tienes | Posesión | Token hardware, tarjeta inteligente, móvil (TOTP) | Pérdida, robo físico |
| Algo que eres | Inherencia (biometría) | Huella dactilar, iris, reconocimiento facial, voz | No revocable si comprometido, falsos positivos/negativos |
Factores adicionales:
- Dónde estás (ubicación): dirección IP, geolocalización, red corporativa.
- Cuándo actúas (comportamiento): hora de acceso, patrones de uso (autenticación continua).
La MFA requiere verificar la identidad mediante dos o más factores de categorías distintas. Dos contraseñas son doble factor de conocimiento, pero no son MFA.
¿Por qué es efectiva? Un atacante que robe la contraseña (factor 1) todavía necesita el segundo factor (físico o biométrico) para acceder. La probabilidad de que ambos factores sean comprometidos simultáneamente es exponencialmente menor.
Contraseña de un solo uso, válida una sola vez. Evita el riesgo de reutilización de contraseñas robadas.
HOTP (HMAC-based OTP) — RFC 4226:
OTP = truncate( HMAC-SHA1(clave_secreta, contador) )
TOTP (Time-Based OTP) — RFC 6238:
OTP = truncate( HMAC-SHA1(clave_secreta, floor(tiempo_unix / 30)) )
SMS OTP:
Código enviado por SMS. Desaconsejado por el NIST (NIST SP 800-63B) por:
- SIM swapping: el atacante convence al operador de transferir el número a una SIM suya.
- Interceptación de SS7 (protocolo de señalización telefónica con vulnerabilidades conocidas).
- Phishing.
FIDO2 es el estándar moderno de autenticación sin contraseña (o como segundo factor). Compuesto por:
- WebAuthn: API web para autenticación fuerte en navegadores.
- CTAP (Client to Authenticator Protocol): protocolo de comunicación con el autenticador (llave hardware).
Funcionamiento:
1. El servidor envía un "challenge" aleatorio al cliente.
2. El autenticador (llave hardware o biométrico del dispositivo) firma el challenge
con la clave privada del usuario (almacenada de forma segura en el autenticador).
3. El servidor verifica la firma con la clave pública registrada previamente.
Ventajas sobre TOTP:
- Resistente a phishing: la clave privada nunca sale del autenticador. La firma incluye el origen (dominio), por lo que una firma válida para banco.com no sirve para banco-fake.com.
- Sin secretos compartidos en el servidor: el servidor solo almacena la clave pública.
- Sin necesidad de introducir códigos: la interacción es una pulsación de botón o biometría.
Dispositivos FIDO2: YubiKey, Google Titan Key, passkeys en móviles y ordenadores modernos (Windows Hello, Face ID, Touch ID integrados con FIDO2).
a) Segunda contraseña fija:
- No es MFA real (dos factores de la misma categoría: conocimiento + conocimiento).
- Mismo riesgo que la primera contraseña: phishing, fuerza bruta, reutilización.
- Solo aumenta levemente la seguridad.
- Valoración: enfoque incorrecto. No se considera MFA.
b) Segunda contraseña dinámica TOTP:
- Sí es MFA: algo que sabes (contraseña) + algo que tienes (dispositivo con app TOTP).
- Mucho más segura que la opción a).
- Inconvenientes: susceptible a phishing en tiempo real si el atacante actúa rápido. Requiere que el usuario tenga el dispositivo móvil disponible.
- Valoración: enfoque correcto. Es el MFA más común hoy en día. Implementación estándar y bien documentada.
c) Acceso solo desde portátiles corporativos + biometría (sin contraseña):
- Factor 1: algo que tienes (portátil corporativo específico, identificado por certificado de cliente o MAC address controlada).
- Factor 2: algo que eres (huella dactilar).
- Es MFA: posesión + inherencia.
- Ventajas: muy alta seguridad si los portátiles están correctamente gestionados. No se pueden robar contraseñas porque no las hay.
- Inconvenientes: las huellas dactilares no se pueden cambiar si se comprometen. Dependencia total del hardware corporativo (¿qué pasa si el empleado trabaja desde otro equipo?). Mayor coste de implantación.
- Valoración: enfoque correcto y muy seguro para entornos de alta sensibilidad. Requiere mayor inversión en gestión de dispositivos. La biometría como único sustituto de contraseña es aceptable si el hardware está bien protegido.
Protocolo para acceder y mantener servicios de directorio distribuidos. Permite consultar y modificar información sobre usuarios, grupos, equipos, etc.
cn=usuario,ou=empleados,dc=empresa,dc=com.Servicio de directorio de Microsoft basado en LDAP + Kerberos. Gestiona identidades y accesos en entornos Windows corporativos. Elementos clave:
- Dominio: unidad administrativa principal.
- Forest: conjunto de dominios con relación de confianza.
- GPO (Group Policy Object): políticas que se aplican a usuarios o equipos del dominio (configuración de seguridad, software, restricciones).
- DC (Domain Controller): servidor que autentica a los usuarios del dominio.
Protocolo de autenticación de red basado en tickets. Diseñado para que los usuarios demuestren su identidad a los servicios sin enviar contraseñas por la red.
1. Cliente → AS (Authentication Server): solicita TGT con su contraseña hasheada.
2. AS → Cliente: TGT (Ticket Granting Ticket) cifrado con la clave del KDC.
3. Cliente → TGS (Ticket Granting Server): presenta TGT, solicita acceso a un servicio.
4. TGS → Cliente: Service Ticket cifrado con la clave del servicio destino.
5. Cliente → Servicio: presenta Service Ticket. El servicio lo descifra y autentica al cliente.
Ventajas: las contraseñas nunca viajan por la red. Single Sign-On (SSO): con un solo login se accede a todos los servicios del dominio.
Vulnerabilidades conocidas: Pass-the-Ticket, Golden Ticket (si se compromete la cuenta krbtgt del KDC), Kerberoasting (solicitar tickets para cuentas de servicio y atacarlos offline).
Protocolo AAA (Authentication, Authorization, Accounting) para acceso a red. Muy usado en:
- Autenticación WiFi empresarial (802.1X): los usuarios se autentican contra el servidor RADIUS antes de acceder a la red WiFi.
- VPN: autenticación de usuarios en concentradores VPN.
- Acceso a dispositivos de red (switches, routers vía TACACS+).
Cliente WiFi → [Solicitud de acceso] → Access Point → [RADIUS Request] → Servidor RADIUS
│
Consulta AD/LDAP
│
Cliente WiFi ← [Acceso permitido] ← Access Point ← [RADIUS Accept/Reject] ←────────┘
Estándar XML para intercambiar datos de autenticación y autorización entre un Identity Provider (IdP) y un Service Provider (SP). Permite SSO (Single Sign-On) en entornos web federados.
Usuario → SP (recurso protegido) → redirección al IdP
Usuario → IdP (autentica al usuario) → genera aserción SAML firmada
IdP → SP con aserción SAML → el SP verifica la firma y concede acceso
OAuth 2.0: framework de autorización (no autenticación) que permite a una aplicación acceder a recursos en nombre del usuario sin compartir credenciales. Ejemplo: "Iniciar sesión con Google" para que una app acceda a tu Google Drive.
Flujo simplificado (Authorization Code Flow):
1. App → Servidor de autorización (Google): solicita permiso para acceder a Drive.
2. Usuario → Google: se autentica y aprueba el permiso.
3. Google → App: código de autorización.
4. App → Google: intercambia código por Access Token.
5. App → Google Drive API: accede con el Access Token.
OpenID Connect (OIDC): capa de autenticación sobre OAuth 2.0. Añade un ID Token (JWT) que contiene información sobre el usuario autenticado. Permite SSO en aplicaciones web modernas.
El propietario del recurso decide quién puede acceder a él y con qué permisos. Modelo implementado en sistemas de archivos tradicionales (Unix, NTFS). Flexible pero puede ser inseguro si los usuarios otorgan permisos de forma irresponsable.
El sistema operativo o el administrador establece políticas de seguridad que ni siquiera el propietario puede anular. Basado en etiquetas de seguridad (niveles de clasificación: Secreto, Confidencial, Público) y compartimentos.
Los permisos se asignan a roles (funciones laborales), no directamente a usuarios. Los usuarios se asignan a roles según sus responsabilidades.
Usuario → Roles → Permisos → Recursos
Juan → [Contable] → [Leer facturas, Generar informes] → BD_Financiera
María → [Admin] → [Leer/Escribir/Borrar todo] → Todos los sistemas
Pedro → [Técnico TI] → [Acceder a logs, reiniciar VMs] → Plataforma virtualización
Ventajas: gestión simplificada (cambiar permisos del rol afecta a todos los usuarios del rol), separación de funciones, principio de mínimo privilegio.
Los permisos se evalúan dinámicamente en función de atributos del usuario, del recurso y del entorno.
Regla: PERMITIR acceso SI:
- usuario.departamento == "RRHH"
- recurso.clasificacion == "Confidencial-RRHH"
- entorno.hora ENTRE 08:00 Y 20:00
- entorno.red == "RedCorporativa"
Más flexible y granular que RBAC, pero más complejo de gestionar. Usado en entornos cloud (AWS IAM policies, por ejemplo).
Cada entidad (usuario, proceso, servicio) debe tener únicamente los permisos mínimos necesarios para realizar sus funciones legítimas, y nada más. Es uno de los principios fundamentales de seguridad.
Aplicaciones prácticas:
- Un servidor web no debe ejecutarse como root.
- Un empleado de soporte técnico no necesita acceso a datos financieros.
- Una aplicación solo debe poder leer la base de datos que necesita, no escribir en otras.
- Las cuentas de administración deben usarse solo cuando sea necesario (no como cuenta de uso diario).
Ninguna persona debe tener control completo sobre un proceso crítico de principio a fin. Ejemplo: quien aprueba pagos no puede ser quien los ejecute; quien crea usuarios no puede asignarse permisos a sí mismo.
Activo (Asset): cualquier elemento con valor para la organización que debe protegerse. Datos, sistemas, infraestructura, reputación, personas.
Vulnerabilidad: debilidad o fallo en un sistema que puede ser explotado. Puede ser técnica (bug en software), de configuración (contraseñas por defecto) o humana (empleado sin formación).
Amenaza (Threat): circunstancia o evento con potencial para causar daño explotando una vulnerabilidad. Puede ser intencional (atacante externo, empleado malicioso) o no intencional (error humano, desastre natural).
Riesgo: probabilidad de que una amenaza explote una vulnerabilidad multiplicada por el impacto resultante.
Riesgo = Probabilidad × Impacto
Exploit: código o técnica que aprovecha una vulnerabilidad específica para causar un efecto no deseado.
CVE (Common Vulnerabilities and Exposures): sistema de identificación pública de vulnerabilidades conocidas. Formato: CVE-AÑO-NÚMERO (ej. CVE-2021-44228 — Log4Shell).
CVSS (Common Vulnerability Scoring System): sistema de puntuación de la severidad de vulnerabilidades. Escala 0-10. Tiene en cuenta vector de ataque, complejidad, privilegios requeridos, interacción del usuario, impacto en confidencialidad/integridad/disponibilidad.
Zero-day (0-day): vulnerabilidad que no ha sido divulgada públicamente ni tiene parche disponible. El fabricante tiene "cero días" para haberla corregido. Extremadamente peligrosas porque no hay defensa directa.
Código malicioso que se adjunta a archivos o programas legítimos y se replica cuando el archivo infectado es ejecutado. Requiere intervención humana para propagarse (ejecutar el archivo).
Funcionamiento: el virus inserta su código en el ejecutable huésped. Cuando el usuario ejecuta el programa legítimo, el código del virus también se ejecuta, realiza su acción maliciosa y puede infectar otros archivos.
Tipos:
- Virus de archivo: infecta ejecutables (.exe, .com).
- Virus de sector de arranque (MBR): infecta el sector de arranque del disco, se carga antes del SO.
- Virus de macro: infecta documentos Office que contienen macros (VBA). Muy comunes en ataques por email con documentos adjuntos.
- Virus polimórfico: cambia su firma (código) en cada infección para evadir la detección por antivirus basados en firmas.
- Virus metamórfico: reescribe completamente su código en cada infección.
Daño: corrupción de archivos, robo de información, instalación de backdoors, borrado de datos.
Malware que se replica de forma autónoma a través de redes sin necesitar adjuntarse a archivos ni intervención humana.
Diferencia clave con virus: el gusano se propaga solo, sin necesitar que el usuario ejecute nada. Explota vulnerabilidades de red o servicios para propagarse.
Ejemplos históricos:
- Morris Worm (1988): primer gusano de Internet. Explotó vulnerabilidades en Unix. Causó la primera condena por delito informático en EE.UU.
- Code Red (2001): explotó vulnerabilidad en IIS de Microsoft. Infectó 359.000 máquinas en 14 horas.
- WannaCry (2017): ransomware con capacidad de gusano. Explotó EternalBlue (vulnerabilidad SMB de Windows). Infectó +200.000 equipos en 150 países en horas, incluyendo el NHS británico.
Daño: consumo de ancho de banda, saturación de redes, instalación de backdoors, descarga de otros malware.
Malware disfrazado de software legítimo o útil. No se replica por sí mismo. El usuario lo instala voluntariamente creyendo que es otra cosa.
Tipos:
- RAT (Remote Access Trojan): proporciona acceso remoto completo al atacante. Ejemplo: njRAT, DarkComet.
- Backdoor: abre una puerta trasera en el sistema para acceso posterior del atacante.
- Dropper/Downloader: su función es descargar e instalar otros malware una vez ejecutado.
- Banker Trojan: especializado en robar credenciales bancarias. Intercepta transacciones, realiza web injects, roba OTPs.
- Infostealer: roba credenciales, cookies de sesión, datos del portapapeles, capturas de pantalla.
Vectores de distribución: adjuntos de email, software pirata, actualizaciones falsas, descargas drive-by.
Malware que cifra los archivos del sistema y exige un rescate (generalmente en criptomonedas) para proporcionar la clave de descifrado.
Funcionamiento técnico:
1. Infección (phishing, exploit, RDP expuesto...)
2. Movimiento lateral: se propaga por la red buscando sistemas accesibles.
3. Reconocimiento: identifica archivos valiosos, deshabilita backups, extrae datos (para doble extorsión).
4. Cifrado: genera clave AES aleatoria por fichero, cifra los ficheros,
cifra la clave AES con la clave pública RSA del atacante.
5. Eliminación de copias sombra (VSS), backups locales.
6. Nota de rescate: instrucciones para pagar (Tor, Bitcoin).
Doble extorsión: además de cifrar, el atacante exfiltra datos antes de cifrar. Si la víctima no paga, amenaza con publicar los datos robados.
Ejemplos: WannaCry, NotPetya (2017, daños >10.000M$), REvil, LockBit, Ryuk, Conti.
Respuesta ante ransomware (Pregunta 7b del examen):
1. Aislar inmediatamente los sistemas afectados de la red para evitar propagación.
2. No pagar el rescate (no garantiza recuperación, financia futuros ataques, puede ser ilegal).
3. Identificar el ransomware (puede haber herramientas de descifrado gratuitas en nomoreransom.org).
4. Restaurar desde copias de seguridad limpias y verificadas (previas a la infección).
5. Notificar a las autoridades (INCIBE en España, AEPD si hay datos personales afectados — obligatorio en <72h bajo RGPD).
6. Análisis forense para identificar el vector de entrada y cerrar la vulnerabilidad.
7. Revisar y mejorar las medidas de seguridad para prevenir futuros ataques.
Spyware: recopila información del usuario (actividad, credenciales, pulsaciones de teclado) sin su conocimiento.
Keylogger: registra todas las pulsaciones del teclado. Puede ser software (proceso en segundo plano) o hardware (dispositivo físico entre teclado y PC).
Adware: muestra publicidad no deseada. Generalmente no malicioso per se, pero puede ser vector de otros malware.
Rootkit: malware que obtiene acceso privilegiado al sistema (nivel kernel) y se oculta de las herramientas de detección. Extremadamente difícil de detectar y eliminar. Puede persistir aunque se reinstale el SO si infecta el firmware.
Bootkit: rootkit que infecta el sector de arranque (MBR/UEFI), cargándose antes del SO y el antivirus.
Fileless malware: malware que no escribe archivos en disco. Opera en memoria, usa herramientas legítimas del SO (PowerShell, WMI, cmd). Muy difícil de detectar por antivirus tradicionales basados en análisis de archivos.
Botnet: red de equipos infectados (bots/zombies) controlados remotamente por un atacante (C2 — Command & Control). Usada para spam masivo, DDoS, minería de criptomonedas, distribución de otros malware.
Fuerza bruta (Brute Force): probar todas las combinaciones posibles de contraseña hasta encontrar la correcta. Efectivo contra contraseñas cortas. Contramedidas: lockout de cuenta, captcha, MFA, contraseñas largas.
Ataque de diccionario (Dictionary Attack): probar palabras comunes, contraseñas filtradas, variaciones conocidas. Más eficiente que fuerza bruta pura. Contramedida: contraseñas largas y complejas no basadas en palabras.
Credential Stuffing: usar listas de credenciales filtradas de otras brechas (usuario + contraseña de una brecha en sitio A para intentar acceder al sitio B). Funciona porque muchos usuarios reutilizan contraseñas. Contramedida: MFA, no reutilizar contraseñas (gestores de contraseñas).
Pass-the-Hash: en entornos Windows, robar el hash NTLM de una contraseña y usarlo directamente para autenticarse sin necesidad de conocer la contraseña en texto plano. Funciona porque el protocolo NTLM acepta el hash como credencial.
DoS (Denial of Service): inundar un servicio con tráfico o solicitudes para hacerlo inaccesible. Un solo origen.
DDoS (Distributed DoS): mismo objetivo pero usando una botnet (miles de equipos) como origen del ataque. Mucho más difícil de bloquear.
Man-in-the-Middle (MitM): el atacante se posiciona entre dos partes que se comunican, interceptando y potencialmente modificando el tráfico. Contramedida: TLS/HTTPS, certificados, HSTS.
ARP Spoofing: el atacante envía respuestas ARP falsas en una red local para asociar su dirección MAC con la IP de otro host (ej. el gateway). Permite ataques MitM en LAN.
DNS Spoofing / DNS Poisoning: corromper la caché de un servidor DNS para que resuelva un dominio legítimo hacia una IP maliciosa. Contramedida: DNSSEC.
Replay Attack: capturar una transmisión legítima (ej. token de autenticación) y retransmitirla para autenticarse. Contramedida: tokens con timestamp, nonces, HTTPS.
Phishing: emails fraudulentos que suplantan organizaciones legítimas para robar credenciales o instalar malware. El vector de ataque más común estadísticamente.
Spear Phishing: phishing dirigido a una persona o organización específica, con información personalizada para aumentar la credibilidad.
Whaling: spear phishing dirigido a altos ejecutivos (CEO, CFO).
Vishing (Voice Phishing): llamadas telefónicas fraudulentas.
Smishing: phishing por SMS.
Baiting: dejar un dispositivo USB con malware en un lugar donde la víctima lo encuentre y lo conecte.
Pretexting: crear una historia falsa (pretexto) para obtener información o acceso. Ejemplo: hacerse pasar por técnico de IT para solicitar credenciales.
Quid pro quo: ofrecer un servicio a cambio de información. Ejemplo: hacerse pasar por soporte técnico y ofrecer ayuda a cambio de credenciales.
Tailgating / Piggybacking: acceder a una zona física restringida siguiendo a alguien autorizado sin identificarse.
El OWASP Top 10 es la lista de las vulnerabilidades más críticas en aplicaciones web:
SQL Injection: el atacante inyecta código SQL en campos de entrada para manipular la base de datos.
-- Input normal: usuario = 'admin', password = 'mipassword'
-- Input malicioso: usuario = 'admin'--', password = 'cualquiera'
-- Query resultante: SELECT * FROM users WHERE user='admin'--' AND pass='...'
-- El '--' comenta el resto: SELECT * FROM users WHERE user='admin'
-- Resultado: acceso sin contraseña
XSS (Cross-Site Scripting): inyección de código JavaScript malicioso en páginas web que se ejecuta en el navegador de otros usuarios.
Un cortafuegos es un sistema (hardware y/o software) que controla el tráfico de red entrante y saliente basándose en reglas de seguridad predefinidas.
Filtrado de paquetes (Packet Filtering):
Examina los paquetes individualmente en base a:
- Dirección IP origen/destino.
- Puerto origen/destino.
- Protocolo (TCP, UDP, ICMP).
Inspección de estado (Stateful Inspection):
Mantiene una tabla de estado de las conexiones activas. Sabe si un paquete pertenece a una conexión ya establecida, lo que permite bloquear paquetes que no corresponden a ninguna conexión legítima. Es el modelo del examen (Pregunta 6).
Proxy / Application Gateway:
Opera a nivel de aplicación (capa 7). Analiza el contenido del tráfico, no solo las cabeceras. Puede hacer inspección profunda de protocolo (ej. bloquear comandos específicos de HTTP).
NGFW (Next-Generation Firewall):
Combina stateful inspection con funcionalidades avanzadas: DPI (Deep Packet Inspection), IPS integrado, identificación de aplicaciones (no solo por puerto), inspección TLS, control por usuario/identidad (integración con AD).
WAF (Web Application Firewall):
Cortafuegos específico para proteger aplicaciones web. Analiza tráfico HTTP/HTTPS. Protege contra SQLi, XSS, CSRF, etc. Puede ser hardware, software o cloud (Cloudflare WAF, AWS WAF).
Las reglas del cortafuegos del examen tienen la estructura:
Acción | IP origen | Máscara origen | IP destino | Máscara destino | Protocolo | Puerto origen | Puerto destino
Convenciones importantes:
- ANY / 0.0.0.0/0: cualquier dirección.
- Las reglas se procesan de forma secuencial: gana la primera regla que coincida.
- Regla por defecto (implícita al final): generalmente DENY ALL (denegar todo lo que no esté explícitamente permitido).
- Para un cortafuegos con inspección de estado, las respuestas de conexiones establecidas se permiten automáticamente, por lo que generalmente no es necesario añadir regla explícita para el tráfico de retorno.
Solución Pregunta 6a — Conexiones web entrantes (HTTP/80 y HTTPS/443) al servidor 139.44.55.23:
ACCEPT | ANY | ANY | 139.44.55.23 | /32 | TCP | ANY | 80
ACCEPT | ANY | ANY | 139.44.55.23 | /32 | TCP | ANY | 443
Solución Pregunta 6b — Conexiones DNS entrantes (UDP/53) al servidor 139.55.44.39:
ACCEPT | ANY | ANY | 139.55.44.39 | /32 | UDP | ANY | 53
ACCEPT | ANY | ANY | 139.55.44.39 | /32 | TCP | ANY | 53
Solución Pregunta 6c — Bloquear tráfico DNS saliente desde DMZ hacia 8.8.8.8, excepto desde 139.55.44.39:
ACCEPT | 139.55.44.39 | /32 | 8.8.8.8 | /32 | UDP | ANY | 53
DENY | 139.44.55.0 | /24 | 8.8.8.8 | /32 | UDP | ANY | 53
Segmento de red intermedio entre la red pública (Internet) y la red privada interna. Los servidores accesibles desde Internet (web, DNS, correo) se colocan en la DMZ.
Internet ──── [Firewall externo] ──── DMZ ──── [Firewall interno] ──── Red interna
(Servidores
públicos)
¿Por qué una DMZ? Si un servidor de la DMZ es comprometido, el atacante accede a la DMZ pero el firewall interno le impide acceder directamente a la red interna con datos sensibles.
IDS (Intrusion Detection System): detecta actividad sospechosa o maliciosa y genera alertas, pero no actúa (no bloquea tráfico). Opera en modo pasivo (copia del tráfico mediante port mirroring).
IPS (Intrusion Prevention System): detecta y bloquea activamente el tráfico malicioso. Opera en línea (inline), el tráfico pasa a través de él.
Métodos de detección:
- Basado en firmas: compara el tráfico contra una base de datos de patrones de ataques conocidos. Rápido y preciso para ataques conocidos; incapaz de detectar ataques nuevos (zero-days).
- Basado en anomalías: establece una línea base del comportamiento normal y alerta cuando se detectan desviaciones. Puede detectar ataques nuevos; genera más falsos positivos.
- Basado en reputación: bloquea IPs o dominios conocidos como maliciosos (threat intelligence feeds).
SIEM (Security Information and Event Management): plataforma que centraliza, correlaciona y analiza logs y eventos de seguridad de múltiples fuentes (firewalls, IDS, servidores, endpoints). Permite detectar patrones de ataque complejos que ningún sistema individual detectaría por separado. Ejemplos: Splunk, IBM QRadar, Microsoft Sentinel, Elastic SIEM.
Una VPN crea un túnel cifrado sobre una red pública (Internet) que permite comunicarse de forma segura como si se estuviera en una red privada.
Propósitos principales:
- Acceso remoto seguro: empleados que trabajan desde casa acceden a la red corporativa de forma segura.
- Interconexión de sedes (Site-to-Site): conectar oficinas geográficamente separadas a través de Internet como si estuvieran en la misma LAN.
- Privacidad: ocultar el tráfico de Internet del ISP o de redes WiFi públicas no seguras.
- Bypass de restricciones geográficas: acceder a contenido bloqueado en cierta región.
Protocolos VPN:
| Protocolo | Puerto | Cifrado | Características |
|---|---|---|---|
| IPsec | UDP 500/4500 | AES, 3DES | Estándar, muy seguro. Dos modos: Transport (cifra solo payload) y Tunnel (cifra todo el paquete IP). Usado en VPNs corporativas y site-to-site. |
| OpenVPN | TCP 443 / UDP 1194 | OpenSSL (AES) | Open source, muy configurable, difícil de bloquear en TCP 443. |
| WireGuard | UDP 51820 | ChaCha20-Poly1305 | Moderno, muy simple (~4000 líneas de código vs 400.000 de OpenVPN), rápido, PFS por diseño. Integrado en Linux kernel. |
| L2TP/IPsec | UDP 1701 | IPsec | L2TP para el túnel + IPsec para el cifrado. Estándar amplio soporte. |
| SSTP | TCP 443 | TLS | Propietario de Microsoft. Buena integración con Windows. |
| IKEv2/IPsec | UDP 500 | IPsec | Rápido en reconexiones (MOBIKE). Muy bueno para móviles. |
Funcionamiento de un túnel VPN (IPsec en modo Túnel):
Paquete original: [IP src: 10.0.0.1] [IP dst: 10.1.0.5] [Datos]
│
[ENCAPSULADO + CIFRADO por IPsec]
│
Paquete VPN: [IP src: 203.0.113.1] [IP dst: 198.51.100.1] [IPsec header] [Datos cifrados]
└── IP pública del └── IP pública del
cliente VPN servidor VPN/gateway
Split tunneling: configuración VPN donde solo el tráfico hacia la red corporativa va cifrado por el túnel, mientras que el resto (ej. navegación web personal) va directamente a Internet sin pasar por el concentrador VPN.
Una política de contraseñas robusta debe incluir:
Requisitos de complejidad:
- Longitud mínima: 12 caracteres (NIST recomienda priorizar longitud sobre complejidad).
- Mezcla de mayúsculas, minúsculas, números y caracteres especiales.
- Prohibición de contraseñas en listas de contraseñas comprometidas conocidas (haveibeenpwned.com).
Gestión:
- No reutilizar las últimas N contraseñas.
- Cambio periódico (aunque el NIST SP 800-63B recomienda NO forzar cambios periódicos a menos que haya evidencia de compromiso, ya que genera contraseñas predecibles).
- Bloqueo de cuenta tras N intentos fallidos (típicamente 3-5).
- Uso de gestores de contraseñas para contraseñas únicas y aleatorias por servicio.
PAM (Privileged Access Management): gestión y control de cuentas con privilegios elevados (administradores, root, cuentas de servicio). Funcionalidades:
- Bóveda de contraseñas (vault): almacena las credenciales de cuentas privilegiadas. Las contraseñas se rotan automáticamente.
- Just-In-Time (JIT) access: los privilegios se conceden solo cuando son necesarios y por un tiempo limitado.
- Grabación de sesiones: todas las acciones realizadas con cuentas privilegiadas quedan registradas.
- Ejemplos: CyberArk, BeyondTrust, HashiCorp Vault.
SSO (Single Sign-On): el usuario se autentica una sola vez y accede a múltiples aplicaciones sin volver a introducir credenciales. Implementado con Kerberos (entornos Windows), SAML, OIDC.
Copia completa (Full Backup):
Copia de todos los datos del sistema, independientemente de si han cambiado desde la última copia.
- Ventaja: restauración más rápida y simple (solo necesitas el último backup completo).
- Desventaja: mayor tiempo de realización y mayor espacio de almacenamiento. No práctico realizarlo a diario en entornos con grandes volúmenes de datos.
Copia diferencial (Differential Backup):
Copia todos los datos modificados desde la última copia completa.
- Ventaja: restauración más rápida que incremental (solo necesitas la última completa + la última diferencial).
- Desventaja: crece con el tiempo (el sábado incluye todos los cambios de lunes a sábado).
- Para restaurar: última copia completa + última copia diferencial.
Copia incremental (Incremental Backup):
Copia solo los datos modificados desde la última copia (sea completa o incremental).
- Ventaja: más rápida de realizar, ocupa menos espacio por cada backup.
- Desventaja: restauración más lenta y compleja (necesitas la completa + todos los incrementales en orden).
- Para restaurar: última copia completa + todos los incrementales desde entonces.
Lunes: [FULL]
Martes: [DIFF: cambios desde Lunes] | [INCR: cambios desde Lunes]
Miércoles: [DIFF: cambios desde Lunes] | [INCR: cambios desde Martes]
Jueves: [DIFF: cambios desde Lunes] | [INCR: cambios desde Miércoles]
Viernes: [DIFF: cambios desde Lunes] | [INCR: cambios desde Jueves]
Restaurar Viernes:
DIFF: Full Lunes + Diff Viernes (2 backups)
INCR: Full Lunes + Incr Martes + Incr Miércoles + Incr Jueves + Incr Viernes (5 backups)
Esta regla garantiza que ningún fallo único (incendio, inundación, fallo de hardware) destruya todas las copias.
RPO (Recovery Point Objective): cuánto tiempo de datos como máximo se puede perder. Define la frecuencia mínima de las copias de seguridad. Si el RPO es 4 horas, hay que hacer backups al menos cada 4 horas.
RTO (Recovery Time Objective): cuánto tiempo como máximo puede estar el sistema inoperativo antes de que sea inaceptable para el negocio. Define qué tan rápido debe poder restaurarse el servicio.
RPO pequeño = backups frecuentes = mayor coste
RTO pequeño = infraestructura de alta disponibilidad = mayor coste
Último backup Fallo
│ │
──────────────●───────────────────X────────────────────►
│←─────────────────►│←──────────────────►
RPO RTO
(datos perdidos max) (tiempo recuperación max)
Plan y conjunto de procedimientos para restaurar sistemas y datos tras un incidente grave (incendio, inundación, ataque masivo, fallo catastrófico de hardware).
Estrategias de DR:
- Cold Site: instalación con infraestructura básica pero sin equipamiento activo. Hay que instalar y configurar todo desde cero. Bajo coste, alto RTO (días o semanas).
- Warm Site: instalación con equipamiento preinstalado pero no actualizado en tiempo real. RTO de horas a días.
- Hot Site: réplica exacta del entorno de producción, activa en tiempo real o casi real. RTO de minutos. Mayor coste.
- Cloud DR: replicación hacia cloud (AWS, Azure). Pago por uso, escalable, RTO variable según configuración.
NAS (Network-Attached Storage): dispositivo de almacenamiento conectado a la red que proporciona servicios de almacenamiento de archivos a múltiples clientes a través de protocolos estándar de red.
Protocolos: SMB/CIFS (Windows), NFS (Linux/Unix), AFP (macOS), iSCSI (acceso a nivel de bloque).
Características:
- Almacenamiento centralizado accesible desde múltiples equipos.
- Generalmente incluye RAID para tolerancia a fallos.
- Gestión simplificada vía interfaz web.
- Soporte para snapshots, replicación, control de acceso.
Diferencia NAS vs SAN:
| | NAS | SAN |
|---|---|---|
| Protocolo | Archivos (SMB, NFS) | Bloques (Fibre Channel, iSCSI) |
| Acceso | Múltiples clientes simultáneos | Un cliente por LUN (normalmente) |
| Rendimiento | Adecuado para uso general | Alto rendimiento para bases de datos |
| Coste | Bajo-medio | Alto |
| Uso típico | Almacenamiento de ficheros compartidos | Bases de datos, almacenamiento de VMs |
Deduplicación (Pregunta 8d):
Técnica de optimización del almacenamiento que identifica y elimina bloques de datos duplicados, almacenando solo una copia y referencias a ella.
Sin deduplicación:
Archivo A: [Bloque1][Bloque2][Bloque3][Bloque4]
Archivo B: [Bloque1][Bloque5][Bloque3][Bloque6]
Total almacenado: 8 bloques
Con deduplicación:
Almacenado: [Bloque1][Bloque2][Bloque3][Bloque4][Bloque5][Bloque6]
Archivo A → [Ref:1][Ref:2][Ref:3][Ref:4]
Archivo B → [Ref:1][Ref:5][Ref:3][Ref:6]
Total almacenado: 6 bloques (25% de ahorro)
Especialmente útil en backups (muchos archivos similares entre backups consecutivos) y entornos VDI (muchas VMs con el mismo SO base).
| Permiso | Archivos | Directorios |
|---|---|---|
| Lectura (Read) | Ver contenido y atributos del archivo | Listar el contenido del directorio |
| Escritura (Write) | Modificar el archivo, agregar datos | Crear archivos y subdirectorios |
| Ejecución (Execute) | Ejecutar el archivo si es un programa | Atravesar el directorio |
| Modificación (Modify) | Leer + Escribir + Eliminar el archivo | Leer + Escribir + Eliminar contenido |
| Lectura y ejecución (R&X) | Leer + Ejecutar | Listar + Atravesar |
| Control total (Full Control) | Todos los permisos + cambiar permisos + tomar posesión | Todos los permisos + cambiar permisos + tomar posesión |
Permisos heredados: se propagan automáticamente desde el objeto padre (directorio) a los objetos hijos (subdirectorios y archivos). Se muestran en gris en la interfaz de Windows.
Permisos explícitos: asignados directamente al objeto, sin ser heredados del padre. Tienen prioridad sobre los permisos heredados.
Ejemplo:
- Directorio C:\Proyectos tiene permiso de Lectura para el grupo "Usuarios".
- Un subdirectorio C:\Proyectos\Secreto hereda ese permiso de Lectura (heredado).
- Si al usuario "Pedro" se le asigna directamente Control Total en C:\Proyectos\Secreto, ese es un permiso explícito que coexiste con los heredados.
Jerarquía de prioridad:
1. Denegación explícita (más prioritaria).
2. Permiso explícito.
3. Denegación heredada.
4. Permiso heredado.
| Permisos NTFS | Permisos de uso compartido (Share) | |
|---|---|---|
| Aplican | Siempre, sea acceso local o en red | Solo cuando se accede por red (UNC path \servidor\recurso) |
| Granularidad | Muy detallados (6 tipos básicos + permisos especiales) | Solo 3: Lectura, Cambio, Control total |
| Cuando coexisten | Se aplica el permiso más restrictivo resultante de combinar ambos |
Regla práctica: cuando un usuario accede a un recurso compartido por red, Windows aplica primero los permisos de compartición y luego los NTFS. El permiso efectivo es el más restrictivo de los dos.
Ejemplo: si los permisos de compartición son "Control total" para un usuario, pero los permisos NTFS solo le dan "Lectura", el permiso efectivo por red es Lectura (el más restrictivo).
La mayoría de los ataques exitosos explotan vulnerabilidades conocidas y con parche disponible. Un programa de gestión de parches debe:
- Inventariar todos los sistemas y versiones de software.
- Monitorizar boletines de seguridad (CERT, fabricantes).
- Priorizar parcheo según criticidad del sistema y severidad CVSS.
- Probar parches en entorno de pruebas antes de producción.
- Definir SLAs de parcheo: ej. crítico (<72h), alto (<7 días), medio (<30 días).
Antivirus tradicional: detecta malware conocido comparando contra una base de datos de firmas. Reactivo (solo detecta lo que ya se conoce).
EDR (Endpoint Detection and Response): monitoriza continuamente el comportamiento de los endpoints para detectar actividades anómalas, incluso de malware desconocido o fileless. Permite respuesta: aislar el endpoint, terminar procesos, revertir cambios. Ejemplos: CrowdStrike Falcon, Microsoft Defender for Endpoint, SentinelOne.
Dividir la red en segmentos mediante VLANs reduce el impacto de un compromiso: si un segmento es infectado (ej. con ransomware), el cortafuegos entre VLANs puede limitar la propagación lateral.
Implementar múltiples capas de seguridad de forma que si una falla, las demás sigan proporcionando protección:
[Capa Perimetral] → Firewall, IPS, WAF, DDoS protection
[Capa de Red] → Segmentación, VLANs, monitorización de tráfico
[Capa de Host] → EDR, antivirus, hardening, actualizaciones
[Capa de Aplicación] → Autenticación fuerte, validación de entradas, OWASP
[Capa de Datos] → Cifrado en reposo y en tránsito, backups, DLP
[Capa Humana] → Formación y concienciación, phishing simulado
Modelo de seguridad basado en el principio "nunca confiar, siempre verificar". Elimina el concepto de red interna como zona de confianza. Aplica autenticación y autorización estrictas para cada solicitud de acceso, independientemente del origen.
Pilares de Zero Trust:
- Verificar explícitamente la identidad en cada acceso (MFA, contexto).
- Usar acceso de mínimo privilegio (JIT, ABAC).
- Asumir siempre que puede haber una brecha (monitorización continua, segmentación).
Log management: recopilar, almacenar y analizar logs de todos los sistemas (firewalls, IDS/IPS, servidores, aplicaciones, endpoints). Los logs son esenciales para la detección de incidentes y el análisis forense posterior.
Alertas: definir reglas que generen alertas cuando se detecten patrones sospechosos:
- Múltiples intentos de login fallidos.
- Acceso fuera del horario habitual.
- Transferencia masiva de datos al exterior.
- Ejecución de herramientas de administración en equipos de usuario.
El factor humano es el eslabón más débil de la cadena de seguridad. El 90% de los ciberataques exitosos comienzan con un ataque de ingeniería social (phishing).
Medidas:
- Formación periódica en ciberseguridad para todos los empleados.
- Simulaciones de phishing para medir la vulnerabilidad real de la organización.
- Procedimientos claros para reportar incidentes sospechosos.
- Política de escritorios limpios (no dejar contraseñas escritas, documentos sensibles a la vista).
┌────────────────────┐
│ ROOT CA │
│ (Autofirmada) │
│ Clave RSA-4096 │
│ Offline físico │
└────────┬───────────┘
│ firma
┌──────────────┼──────────────┐
▼ ▼ ▼
┌──────────────┐ ┌──────────────┐ ┌──────────────┐
│Intermediate │ │Intermediate │ │Intermediate │
│ CA 1 │ │ CA 2 │ │ CA 3 │
│(TLS certs) │ │(Code signing)│ │(Email/S-MIME)│
└──────┬───────┘ └──────┬───────┘ └──────┬───────┘
│ firma │ firma │ firma
┌──────▼───────┐ ┌──────▼───────┐ ┌──────▼───────┐
│ Certificado │ │ Certificado │ │ Certificado │
│ servidor TLS │ │ firma código │ │ email S/MIME │
└──────────────┘ └──────────────┘ └──────────────┘
¿Por qué usar CAs intermedias? La Root CA nunca debe estar online. Está guardada en una cámara acorazada, desconectada de la red, solo accesible con procedimientos de key ceremony (ceremonia de claves) con múltiples testigos y notario. Si la Root CA firmara directamente los certificados de usuarios, tendría que estar online constantemente, exponiendo su clave privada.
Las CAs intermedias son las que operan online. Si una CA intermedia se compromete:
1. Solo hay que revocar los certificados emitidos por esa CA intermedia.
2. La Root CA (offline) no está comprometida.
3. Se puede emitir una nueva CA intermedia firmada por la Root CA.
Cadena de confianza (certificate chain):
Para verificar www.banco.com, el navegador:
1. Recibe el certificado de www.banco.com, firmado por "DigiCert TLS RSA CA".
2. Busca el certificado de "DigiCert TLS RSA CA", firmado por "DigiCert Global Root CA".
3. "DigiCert Global Root CA" está en el almacén de confianza del SO.
4. Verifica las firmas en sentido inverso: Root → Intermedia → Certificado final.
5. Toda la cadena válida → HTTPS seguro.
El SO y los navegadores tienen un almacén de certificados raíz preinstalado. Los fabricantes deciden qué CAs incluir, auditando periódicamente su comportamiento.
certmgr.msc. Las actualizaciones de Windows añaden o eliminan CAs automáticamente./etc/ssl/certs/, gestionado por el paquete ca-certificates de la distribución.A fecha actual, hay ~140 organizaciones de CAs raíz en el almacén de Windows, con cientos de certificados raíz. Cada una de ellas puede emitir certificados válidos para cualquier dominio del mundo, lo que es un punto de debilidad sistémico.
Certificate Transparency (CT): sistema moderno donde las CAs están obligadas a publicar en logs públicos auditables todos los certificados que emiten. Cualquiera puede consultar estos logs para detectar certificados fraudulentos emitidos sin autorización del dueño del dominio. Chrome requiere CT para confiar en un certificado desde 2018.
PKI corporativa (Microsoft AD CS):
En entornos empresariales, Active Directory Certificate Services (AD CS) permite crear una CA privada para emitir certificados internos. Usos típicos:
- Certificados para servidores web de intranet (HTTPS interno).
- Autenticación de usuarios y equipos en WiFi corporativa (802.1X con EAP-TLS).
- Autenticación de clientes VPN sin contraseña (certificado de cliente).
- Firma de scripts PowerShell.
- Cifrado de correo interno (S/MIME).
Los equipos del dominio reciben automáticamente el certificado raíz de la CA corporativa a través de GPO (Group Policy Object), por lo que confían en los certificados internos sin configuración manual.
| Versión | Estado | Vulnerabilidades |
|---|---|---|
| SSL 2.0 | Prohibido (RFC 6176) | Múltiples, diseño fundamental inseguro |
| SSL 3.0 | Prohibido (RFC 7568) | POODLE, DROWN |
| TLS 1.0 | Deprecado (RFC 8996) | BEAST, POODLE, Heartbleed |
| TLS 1.1 | Deprecado (RFC 8996) | BEAST |
| TLS 1.2 | Activo | Seguro si bien configurado |
| TLS 1.3 | Recomendado | Nuevo en 2018, más seguro y rápido |
Mejoras de TLS 1.3 sobre TLS 1.2:
- Elimina todos los algoritmos obsoletos (RSA para intercambio de claves, MD5, SHA-1, RC4, 3DES, DH estático).
- PFS obligatorio: solo ECDHE o DHE para intercambio de claves.
- Handshake reducido de 2-RTT a 1-RTT (o 0-RTT para reconexiones), reduciendo latencia.
- El certificado del servidor viaja cifrado dentro del handshake (antes era visible).
- Cipher suites simplificadas: solo 5 disponibles (todas seguras).
¿Qué protege HTTPS?
- Confidencialidad del contenido (datos, credenciales, cookies).
- Integridad (nadie puede modificar la respuesta en tránsito, inyectar scripts o publicidad).
- Autenticación del servidor (el cliente verifica que habla con el servidor legítimo).
¿Qué NO protege HTTPS?
- No oculta con qué servidor te comunicas (el SNI es visible en el handshake, aunque TLS 1.3 añade ECH — Encrypted Client Hello — para cifrar esto).
- No protege si el servidor está comprometido.
- No protege frente a vulnerabilidades en el código de la aplicación (SQLi, XSS).
- No oculta el volumen de datos intercambiados (análisis de tráfico).
HSTS (HTTP Strict Transport Security): cabecera HTTP que indica al navegador que ese dominio debe accederse siempre por HTTPS, nunca por HTTP. Previene ataques de SSL stripping (downgrade forzado a HTTP). El navegador almacena esta instrucción y rechaza conexiones HTTP aunque el usuario escriba http://.
SSH (Secure Shell) es el protocolo estándar para acceso remoto seguro a sistemas Unix/Linux. Puerto por defecto: 22. Reemplazó completamente a Telnet y rsh (ambos en texto plano).
Lo que proporciona SSH:
- Confidencialidad: toda la comunicación está cifrada (AES, ChaCha20).
- Autenticación del servidor: al conectar por primera vez, SSH muestra el fingerprint (hash) de la clave pública del servidor. Las claves de hosts conocidos se guardan en ~/.ssh/known_hosts. Si la clave cambia en una conexión posterior (posible ataque MitM), SSH avisa con un error de seguridad crítico.
- Autenticación del cliente: por contraseña (no recomendado) o por par de claves (recomendado).
Autenticación SSH por clave pública — flujo completo:
# 1. El cliente genera su par de claves (una sola vez)
ssh-keygen -t ed25519 -C "usuario@empresa.com"
# Genera:
# ~/.ssh/id_ed25519 ← CLAVE PRIVADA: nunca sale del cliente
# ~/.ssh/id_ed25519.pub ← CLAVE PÚBLICA: se copia al servidor
# 2. Copiar la clave pública al servidor
ssh-copy-id usuario@servidor.com
# Añade la clave pública a ~/.ssh/authorized_keys en el servidor
# 3. Conectar sin contraseña
ssh usuario@servidor.com
# Protocolo: el servidor envía un challenge cifrado con la clave pública del cliente.
# El cliente demuestra que posee la clave privada firmando el challenge, sin revelarla nunca.
SSH tunneling: SSH puede crear túneles cifrados para otros protocolos:
# Local forwarding: acceder al puerto de BD del servidor desde el cliente
ssh -L 5432:localhost:5432 usuario@servidor.com
# localhost:5432 en el cliente → cifrado por SSH → puerto 5432 del servidor
# Dynamic forwarding (proxy SOCKS)
ssh -D 8080 usuario@servidor.com
# Convierte el cliente en proxy SOCKS: todo el tráfico configurado sale por el servidor
OAuth 2.0 es un protocolo de autorización (no autenticación) para que una aplicación acceda a recursos de otra en nombre del usuario sin que este comparta sus credenciales.
Flujo Authorization Code (el más seguro):
Usuario → App (ClimateApp) → "Necesito acceder a tu Google Calendar"
App → Redirige al usuario a Google con un code_challenge
Usuario → Se autentica en Google directamente (nunca en ClimateApp)
Google → "¿Autorizas a ClimateApp a ver tu Calendar?"
Usuario acepta → Google emite un código de autorización a ClimateApp
ClimateApp → Intercambia el código + code_verifier por un Access Token
ClimateApp → Usa el Access Token para llamar a Google Calendar API
OpenID Connect (OIDC): capa de identidad sobre OAuth 2.0. Añade un ID Token en formato JWT que contiene información verificada sobre el usuario (quien es, cuándo se autenticó, etc.). Base de la mayoría de los sistemas de SSO modernos.
JWT (JSON Web Token): formato estándar para tokens. Tres partes codificadas en Base64URL separadas por puntos:
eyJhbGciOiJSUzI1NiJ9 ← Header: algoritmo y tipo
.eyJzdWIiOiJ1c2VyMTIzIn0 ← Payload: claims (sub, iss, exp, roles...)
.firma_RSA_o_HMAC ← Signature: garantiza integridad del token
La firma del JWT garantiza que no ha sido manipulado. El servidor lo verifica con la clave pública (si es RSA/ECDSA) o la clave secreta compartida (si es HMAC). Si el payload se altera aunque sea un carácter, la firma no coincide y el token se rechaza.
Vulnerabilidad clásica de JWT: el algoritmo alg: none (sin firma). Versiones antiguas de bibliotecas aceptaban tokens con alg: none, permitiendo que cualquiera forjara tokens válidos simplemente eliminando la firma. Siempre verificar que el algoritmo es uno esperado y firmado.
El algoritmo TOTP funciona de la siguiente manera:
Entrada: clave_secreta_compartida (en Base32, ej: JBSWY3DPEHPK3PXP)
tiempo_unix_actual (ej: 1716300000)
periodo (30 segundos por defecto)
dígitos (6 por defecto)
Pasos:
1. contador = floor(tiempo_unix / 30) → número de intervalos de 30s desde epoch
2. msg = contador codificado en 8 bytes big-endian
3. h = HMAC-SHA1(clave_secreta, msg) → 20 bytes
4. offset = h[19] & 0x0F → último nibble (0-15)
5. code_int = (h[offset:offset+4] como entero de 32 bits) & 0x7FFFFFFF
6. OTP = code_int % 10^6 → últimos 6 dígitos
Resultado: "483921"
El código cambia cada 30 segundos. El servidor permite una ventana de ±1 intervalo para compensar diferencias de reloj entre dispositivos.
Por qué TOTP no es suficiente contra phishing en tiempo real: si el atacante tiene un sitio phishing que captura usuario, contraseña y código TOTP y los usa inmediatamente en el sitio real, tiene 30 segundos para completar el ataque. Con automatización, es factible. Por eso FIDO2/WebAuthn es superior.
Funcionamiento técnico del registro:
1. Usuario solicita registrar un nuevo autenticador en ejemplo.com
2. Servidor genera un challenge aleatorio + envía el RP ID (dominio: "ejemplo.com")
3. El autenticador (YubiKey, TPM, Secure Enclave del móvil):
a. Genera un par de claves ED25519 específico para este sitio
b. Almacena la clave privada internamente (nunca exportable)
c. Firma el challenge + el RP ID con la clave privada
d. Devuelve: clave pública + attestation (prueba del tipo de autenticador)
4. El servidor almacena la clave pública asociada al usuario
Funcionamiento técnico de la autenticación:
1. Servidor envía un nuevo challenge aleatorio + RP ID ("ejemplo.com")
2. El autenticador firma: challenge + RP ID + contador de uso + flags
3. El servidor verifica la firma con la clave pública almacenada
4. El RP ID firmado es "ejemplo.com": un sitio de phishing "ejempl0.com"
recibiría una firma para "ejempl0.com", que el servidor "ejemplo.com"
rechazará porque el RP ID no coincide → IMPOSIBLE el phishing
Passkeys: implementación de FIDO2 sincronizada entre dispositivos del mismo usuario (iCloud Keychain en Apple, Google Password Manager, Windows Hello). Permite autenticación sin contraseña usando biometría del dispositivo, con sincronización cifrada en la nube.
Kerberos es el protocolo de autenticación de Active Directory. Basado en tickets cifrados, evita que las contraseñas viajen por la red.
Componentes:
KDC (Key Distribution Center): servidor central con dos servicios:
- AS (Authentication Service): emite TGTs
- TGS (Ticket Granting Service): emite tickets de servicio
Flujo completo:
1. Cliente → AS: "Soy Alice" + timestamp cifrado con hash de contraseña de Alice
2. AS → Cliente: TGT cifrado con clave del KDC + clave de sesión cifrada con hash de Alice
3. Cliente → TGS: TGT + "Quiero acceder al servidor FILE01"
4. TGS → Cliente: Service Ticket cifrado con clave de FILE01 + nueva clave de sesión
5. Cliente → FILE01: Service Ticket (FILE01 lo descifra con su clave y autentica a Alice)
Ventajas: la contraseña nunca viaja por la red. SSO completo en el dominio.
Ataques conocidos contra Kerberos:
- Pass-the-Ticket: robar un TGT de memoria (mimikatz) y usarlo para autenticarse sin contraseña.
- Golden Ticket: comprometer la cuenta krbtgt del KDC y forjar TGTs para cualquier usuario, incluidos administradores de dominio. Persistencia total en el dominio.
- Silver Ticket: forjar un Service Ticket para un servicio específico (sin necesitar el KDC).
- Kerberoasting: solicitar tickets de servicio para cuentas con SPN y atacarlos offline con fuerza bruta para obtener la contraseña de la cuenta de servicio.
RADIUS es el protocolo AAA estándar para control de acceso a red. Muy usado en WiFi corporativa (802.1X) y VPN.
Flujo WiFi 802.1X con RADIUS:
Dispositivo WiFi → [EAPOL] → Access Point (autenticador) → [RADIUS] → Servidor RADIUS
│
Consulta LDAP/AD
│
Acceso a la red ← [VLAN asignada] ← Access Point ← [RADIUS Accept + VLAN] ─┘
EAP (Extensible Authentication Protocol): protocolo de autenticación usado dentro de 802.1X. Variantes más comunes:
- EAP-TLS: el más seguro. El cliente se autentica con un certificado de cliente. Requiere PKI corporativa.
- PEAP: el cliente usa usuario/contraseña, protegido dentro de un túnel TLS establecido con el certificado del servidor RADIUS.
- EAP-TTLS: similar a PEAP pero más flexible.
MAC (Mandatory Access Control) se basa en etiquetas de clasificación asignadas tanto a sujetos (usuarios/procesos) como a objetos (recursos):
Etiquetas de clasificación (ejemplo militar):
TOP SECRET > SECRET > CONFIDENTIAL > UNCLASSIFIED
Reglas del modelo Bell-LaPadula (confidencialidad):
- No read up: un sujeto NO puede leer objetos de nivel superior al suyo
- No write down: un sujeto NO puede escribir en objetos de nivel inferior al suyo
(evita que información secreta "fluya" hacia niveles de menor clasificación)
SELinux (Security-Enhanced Linux) implementa MAC en Linux. Cada proceso y archivo tiene un contexto de seguridad (user:role:type:level). Una política define qué tipos pueden acceder a qué. Incluso root no puede hacer lo que la política no permite. Es complejo de configurar pero extremadamente eficaz para limitar el impacto de exploits (un proceso web comprometido solo puede acceder a los recursos que su política le permite, no a todo el sistema).
Zero Trust es un modelo de seguridad que elimina el concepto de "red de confianza". La premisa: "Nunca confiar, siempre verificar" independientemente del origen de la solicitud.
Principios técnicos:
- Verificación explícita: autenticar y autorizar cada solicitud usando todos los datos disponibles (identidad, dispositivo, ubicación, servicio, clasificación de datos, anomalías).
- Mínimo privilegio: acceso JIT (Just-In-Time) y JEA (Just Enough Access). Los privilegios expiran automáticamente.
- Asumir la brecha: operar como si la red ya estuviera comprometida. Segmentar la red, cifrar todo el tráfico, monitorizar continuamente.
Componentes tecnológicos de una arquitectura Zero Trust:
- IAM con MFA fuerte: identidad es el nuevo perímetro.
- MDM (Mobile Device Management): verificar que el dispositivo cumple las políticas de seguridad (actualizado, cifrado, sin jailbreak).
- Microsegmentación: aislar cada workload para limitar el movimiento lateral.
- Cifrado de todos los datos en tránsito: incluso dentro de la red interna.
- SIEM + UEBA (User and Entity Behavior Analytics): detección continua de anomalías.
Las APT son ataques sofisticados y prolongados realizados por actores con grandes recursos (generalmente estados-nación o grupos muy organizados).
Fases de un APT (Kill Chain de Lockheed Martin):
1. RECONOCIMIENTO → OSINT, escaneo de puertos, LinkedIn para identificar empleados clave
2. ARMAMENTO → Crear exploit personalizado + payload (RAT, backdoor)
3. ENTREGA → Spear phishing, watering hole, USB, compromiso de cadena de suministro
4. EXPLOTACIÓN → Ejecutar el exploit en el sistema objetivo
5. INSTALACIÓN → Instalar persistencia (backdoor, rootkit, tarea programada)
6. C2 (Command&Control) → Establecer canal de comunicación cifrado con el servidor del atacante
7. ACCIONES → Movimiento lateral, escalada de privilegios, exfiltración de datos
Ejemplos históricos:
Stuxnet (2010): malware de estado-nación (atribuido a EE.UU./Israel, operación "Olympic Games"). Diseñado específicamente para destruir las centrifugadoras de enriquecimiento de uranio iraníes en Natanz. Manipulaba los PLCs Siemens para hacer girar las centrifugadoras a velocidades destructivas mientras mostraba valores normales a los operadores. Se propagó por USB (air gap). Primer ciberarma conocida públicamente.
SolarWinds Sunburst (2020): compromiso de cadena de suministro. Los atacantes (APT29/Cozy Bear, atribuido a Rusia) insertaron un backdoor ("Sunburst") en las actualizaciones firmadas del software Orion de SolarWinds. 18.000 organizaciones instalaron la actualización maliciosa, incluyendo el Departamento de Estado de EE.UU., el Tesoro, y grandes empresas tecnológicas. El backdoor estuvo activo durante meses sin ser detectado.
El atacante no compromete directamente el objetivo sino a uno de sus proveedores o dependencias para llegar al objetivo a través de ellos.
Tipos:
- Compromiso de software legítimo: insertar malware en una actualización firmada (SolarWinds, CCleaner 2017).
- Typosquatting en repositorios: publicar paquetes con nombres similares a populares en npm, PyPI (colourama vs colorama) esperando que los desarrolladores los instalen por error.
- Dependency confusion: publicar paquetes con el mismo nombre que paquetes internos de una empresa en el repositorio público, aprovechando que algunos gestores de paquetes priorizan el repositorio público.
El cortafuegos del examen es un stateful inspection firewall. Las reglas tienen esta estructura:
Acción | IP origen | Máscara origen | IP destino | Máscara destino | Protocolo | Puerto origen | Puerto destino
Conceptos clave para el examen:
- ANY en IP = 0.0.0.0 con máscara 0.0.0.0 (cualquier dirección).
- Orden secuencial: la primera regla que coincide se aplica. Las excepciones (permits específicos) van ANTES que las denegaciones generales.
- Stateful: las respuestas a conexiones establecidas se permiten automáticamente. No hace falta regla explícita de retorno para TCP.
- DMZ clase C = máscara /24 = 255.255.255.0.
Pregunta 6a — Conexiones web entrantes HTTP/80 y HTTPS/443 al servidor 139.44.55.23:
ACCEPT | 0.0.0.0 | 0.0.0.0 | 139.44.55.23 | 255.255.255.255 | TCP | ANY | 80
ACCEPT | 0.0.0.0 | 0.0.0.0 | 139.44.55.23 | 255.255.255.255 | TCP | ANY | 443
Pregunta 6b — Conexiones DNS entrantes UDP/53 y TCP/53 al servidor 139.55.44.39:
ACCEPT | 0.0.0.0 | 0.0.0.0 | 139.55.44.39 | 255.255.255.255 | UDP | ANY | 53
ACCEPT | 0.0.0.0 | 0.0.0.0 | 139.55.44.39 | 255.255.255.255 | TCP | ANY | 53
Pregunta 6c — Bloquear DNS saliente desde DMZ hacia 8.8.8.8, excepto desde 139.55.44.39:
ACCEPT | 139.55.44.39 | 255.255.255.255 | 8.8.8.8 | 255.255.255.255 | UDP | ANY | 53
DENY | 139.44.55.0 | 255.255.255.0 | 8.8.8.8 | 255.255.255.255 | UDP | ANY | 53
| Protocolo | Año | Cifrado | Estado | Vulnerabilidades |
|---|---|---|---|---|
| WEP | 1999 | RC4 (40/104 bits) | Roto | IV corto, clave recuperable en minutos |
| WPA | 2003 | TKIP (RC4 mejorado) | Deprecado | TKIP vulnerable, solo mejora parcial |
| WPA2-Personal | 2004 | AES-CCMP | Aceptable | KRACK (2017), ataques de diccionario offline al handshake |
| WPA2-Enterprise | 2004 | AES-CCMP + 802.1X | Recomendado para empresas | Requiere RADIUS y PKI |
| WPA3-Personal | 2018 | AES-GCMP + SAE | Recomendado | Elimina ataques de diccionario offline |
| WPA3-Enterprise | 2018 | AES-GCMP-256 + 802.1X | Máxima seguridad | — |
WPA2-Personal: usa una PSK (Pre-Shared Key — contraseña WiFi). Vulnerabilidad: si se captura el handshake de 4 vías (al conectar un cliente), se puede atacar offline con diccionario sin límite de intentos. Si la contraseña es débil, se rompe.
WPA3-Personal: usa SAE (Simultaneous Authentication of Equals), basado en Diffie-Hellman. Elimina los ataques de diccionario offline: cada intento de autenticación requiere interacción con el AP. También proporciona Forward Secrecy.
WPA2/WPA3-Enterprise (802.1X): cada usuario se autentica individualmente contra un servidor RADIUS. No hay contraseña WiFi compartida entre todos. Si un empleado se va, solo se desactiva su cuenta en AD; no hay que cambiar la contraseña de toda la red.
IAM (Identity and Access Management) es el conjunto de políticas, procesos y tecnologías para gestionar las identidades digitales y controlar su acceso a los recursos.
Ciclo de vida de una identidad:
Provisioning → Autenticación → Autorización → Auditoría → Deprovisioning
(Alta/creación) (login/MFA) (permisos) (logs) (baja/borrado)
PAM (Privileged Access Management): gestión específica de las cuentas con privilegios elevados.
- Bóveda de contraseñas (Password Vault): almacena las contraseñas de cuentas privilegiadas de forma segura y las rota automáticamente. Un administrador solicita acceso y recibe la contraseña temporalmente, sin saber cuál es la contraseña real (la bóveda la proporciona directamente a la sesión).
- JIT Access (Just-In-Time): los privilegios se conceden solo cuando son necesarios y por tiempo limitado. Un desarrollador que necesita acceso de admin a producción lo solicita, se aprueba, tiene acceso durante 1 hora, y los privilegios expiran automáticamente.
- Session Recording: todas las sesiones privilegiadas quedan grabadas para auditoría forense.
Un SIEM (Security Information and Event Management) centraliza, correlaciona y analiza eventos de seguridad de múltiples fuentes para detectar incidentes.
Fuentes de datos típicas de un SIEM:
- Logs de firewalls y routers (Netflow).
- Logs de IDS/IPS.
- Logs de autenticación (AD, RADIUS, VPN).
- Logs de servidores web (Apache, Nginx, IIS).
- Logs de endpoints (EDR).
- Logs de aplicaciones críticas.
Casos de uso de detección:
- Múltiples intentos de login fallidos seguidos de éxito → posible brute force exitoso.
- Login desde país inusual para un usuario → posible credencial comprometida.
- Proceso que abre y cifra miles de ficheros en segundos → posible ransomware.
- Exfiltración de datos: transferencia masiva fuera de horario laboral a IP desconocida.
- Movimiento lateral: un equipo de usuario intentando conectarse por SMB a muchos equipos de la red.
UEBA (User and Entity Behavior Analytics): extensión del SIEM con modelos de ML que aprenden el comportamiento normal de cada usuario y entidad, y alertan cuando se detectan desviaciones significativas. Efectivo para detectar amenazas internas y cuentas comprometidas.
Las tres recomendaciones más impactantes para prevenir infecciones por malware en una organización:
1. Gestión de parches y actualizaciones periódicas:
Mantener todos los sistemas operativos, aplicaciones y firmware actualizados. La mayoría de los ataques exitosos (WannaCry, EternalBlue, Log4Shell) explotan vulnerabilidades con parche disponible que no se había aplicado. Implantar un proceso de gestión de parches con SLAs definidos por criticidad (críticos: <72h, altos: <7 días).
2. Formación y concienciación de los usuarios (Security Awareness Training):
El 90% de los ciberataques comienzan con phishing o ingeniería social. Formar a los empleados para reconocer emails sospechosos, no hacer clic en enlaces de fuentes no verificadas, no conectar dispositivos USB desconocidos, y reportar incidentes al equipo de seguridad. Complementar con simulacros de phishing periódicos para medir y mejorar el nivel de concienciación.
3. Backups regulares offline y aislados de la red:
Ante un ataque de ransomware, la única recuperación garantizada sin pagar el rescate es restaurar desde backups limpios. Los backups deben seguir la regla 3-2-1, incluir al menos una copia offline o inmutable (inaccesible desde la red) y probarse periódicamente con restauraciones reales. Un backup que no se ha verificado no es un backup fiable.
| Pregunta del examen | Concepto del tema |
|---|---|
| Q2 — MFA | Factores de autenticación, TOTP, biometría, análisis de enfoques MFA |
| Q5 — VPN | Túneles VPN, protocolos (IPsec, WireGuard, OpenVPN), cifrado híbrido |
| Q6 — Cortafuegos | Stateful inspection, reglas de firewall, DMZ, puertos estándar |
| Q7 — Malware | Tipos de malware, ransomware, respuesta a incidentes |
| Q8 — Almacenamiento | NAS, tipos de backup, RPO/RTO, deduplicación, regla 3-2-1 |
| Q9 — NTFS | Permisos NTFS, herencia, permisos explícitos, NTFS vs Sharing |
Cifrado en reposo (encryption at rest): protege los datos almacenados para que sean ilegibles si el medio de almacenamiento es robado, extraído físicamente o accedido sin autorización. Complementa al cifrado en tránsito (TLS/VPN): uno protege los datos moviéndose, el otro los protege quietos.
BitLocker (Windows):
Cifrado de disco completo integrado en Windows Pro/Enterprise. Usa AES-256 en modo XTS. La clave de cifrado puede protegerse con:
- TPM solo: el disco se descifra automáticamente si arranca en el hardware original. Si se roba solo el disco, los datos son ilegibles.
- TPM + PIN: requiere introducir un PIN en el arranque. Más seguro, pero requiere intervención del usuario.
- TPM + USB: la clave se almacena en un USB que debe estar presente al arrancar.
- Recovery Key: clave de recuperación de 48 dígitos que debe guardarse en AD o en un lugar seguro. Esencial para recuperar el acceso si el TPM falla.
FileVault (macOS):
Equivalente a BitLocker para macOS. Usa XTS-AES-128. Se activa en Preferencias del Sistema → Seguridad. La clave de recuperación se puede guardar en iCloud o localmente.
LUKS (Linux Unified Key Setup):
Estándar de cifrado de disco en Linux. Usa dm-crypt del kernel. Características:
- Soporta hasta 32 slots de clave (32 contraseñas o ficheros de clave distintos pueden descifrar el mismo disco, útil para administradores).
- Header LUKS al inicio del dispositivo: contiene metadatos del cifrado, los slots y las claves maestras cifradas.
- El cifrado real usa AES-256-XTS por defecto en versiones modernas (LUKS2).
# Crear un contenedor LUKS cifrado
cryptsetup luksFormat /dev/sdb1
# Abrir el contenedor (descifrar)
cryptsetup luksOpen /dev/sdb1 datos_cifrados
# Ahora /dev/mapper/datos_cifrados es el disco descifrado
mkfs.ext4 /dev/mapper/datos_cifrados
mount /dev/mapper/datos_cifrados /mnt/datos
Transparent Data Encryption (TDE):
Cifrado a nivel de base de datos (SQL Server, Oracle, MySQL Enterprise). Los ficheros de la base de datos en disco están cifrados, pero el motor de BD los descifra automáticamente cuando los necesita. Protege contra robo del medio de almacenamiento pero no protege contra un atacante que ya tenga acceso al motor de BD en ejecución (los datos se descifran en memoria para el motor). Complementario al control de acceso a la BD, no sustituto.
Cifrado de ficheros individuales:
- EFS (Encrypting File System): cifrado a nivel de fichero en NTFS. Vinculado al certificado del usuario. Si se pierde el certificado, se pierden los datos.
- VeraCrypt: sucesor de TrueCrypt. Crea contenedores cifrados portátiles o cifra particiones completas. Compatible con Windows, macOS y Linux.
- OpenPGP / GPG: cifrado de ficheros y emails basado en clave pública. Estándar abierto.
El TPM es un chip de seguridad integrado en la placa base que proporciona funciones criptográficas en hardware:
TPM 2.0 es el estándar actual, requerido por Windows 11.
Hardening es el proceso de reducir la superficie de ataque de un sistema eliminando servicios, cuentas, puertos y configuraciones innecesarias, y activando los mecanismos de seguridad disponibles. El objetivo es que el sistema sea lo más difícil posible de comprometer.
Principio: minimizar la superficie de ataque. Todo lo que no es necesario es una posible vía de entrada para un atacante.
1. Eliminar servicios y software innecesarios:
# Desactivar y deshabilitar servicios no necesarios (Linux)
systemctl disable bluetooth
systemctl disable cups # impresión, si no se necesita
systemctl stop avahi-daemon # descubrimiento de red Zeroconf
# Eliminar software innecesario
apt remove telnetd rsh-server nis xinetd
2. Configurar correctamente los servicios que se mantienen:
# SSH hardening — /etc/ssh/sshd_config
PermitRootLogin no # nunca hacer login directo como root
PasswordAuthentication no # solo claves pública/privada
PubkeyAuthentication yes
Protocol 2 # solo SSHv2, nunca SSHv1
MaxAuthTries 3 # máximo 3 intentos
ClientAliveInterval 300 # desconectar sesiones inactivas
AllowUsers admin deploy # whitelist de usuarios permitidos
3. Gestión de cuentas y privilegios:
- Eliminar o deshabilitar cuentas por defecto no necesarias (Guest, Administrator en Windows, cuentas de demostración).
- Cambiar todas las contraseñas por defecto en dispositivos (routers, switches, cámaras IP, impresoras de red). Las contraseñas por defecto están publicadas en Internet y son el primer vector de ataque.
- Separar la cuenta de administración de la cuenta de uso diario. Un administrador usa su cuenta normal para el trabajo cotidiano y su cuenta de admin solo cuando es estrictamente necesario.
- Aplicar el principio de mínimo privilegio en todas las cuentas y procesos.
4. Configuraciones de seguridad del SO:
- Activar el firewall local (Windows Defender Firewall, iptables/nftables en Linux, pf en macOS).
- Activar el registro y auditoría de eventos de seguridad (intentos de login, cambios de privilegios, acceso a ficheros sensibles).
- Desactivar el autorun/autoplay de medios extraíbles (USB, CD).
- Activar Secure Boot (previene bootkits no firmados).
- Activar ASLR (Address Space Layout Randomization): aleatoriza la dirección base de los procesos en memoria, dificultando los exploits de buffer overflow.
- Activar DEP/NX (Data Execution Prevention / No-Execute): impide ejecutar código en zonas de memoria marcadas como datos.
5. Hardening de contraseñas y autenticación:
- Política de complejidad y longitud mínima.
- Bloqueo de cuenta tras N intentos fallidos.
- Historial de contraseñas (no reutilizar las últimas N).
- MFA para todos los accesos críticos.
6. Reducción de privilegios de procesos:
- Los servicios deben ejecutarse con cuentas dedicadas de mínimo privilegio, no como root/SYSTEM.
- Usar chroot/namespaces/contenedores para aislar procesos.
- Aplicar AppArmor o SELinux para confinar los procesos con políticas MAC.
CIS Benchmarks (Center for Internet Security):
Guías de configuración segura para cada SO (Windows, Linux, macOS), base de datos (SQL Server, MySQL, Oracle), plataforma cloud (AWS, Azure, GCP) y aplicación (Apache, Nginx, Docker). Son el estándar de facto en la industria. Gratuitas para uso no comercial. Cada control indica el nivel de seguridad (Level 1: recomendado para todos; Level 2: para entornos de alta seguridad con posible impacto en usabilidad).
DISA STIGs (Security Technical Implementation Guides):
Guías del Departamento de Defensa de EE.UU. para sistemas de alta seguridad. Más restrictivos que los CIS Benchmarks. Obligatorios para sistemas del gobierno de EE.UU.
OWASP Application Security Verification Standard (ASVS):
Marco de verificación de seguridad para aplicaciones web. Define tres niveles de seguridad con controles específicos.
El usuario es el eslabón más débil de la cadena de seguridad. Todas las medidas técnicas pueden ser inútiles si el usuario hace clic en un enlace de phishing, usa contraseñas débiles, o conecta un USB desconocido.
Programa de formación en seguridad:
- Reconocer phishing: verificar el remitente real (no solo el nombre), no hacer clic en URLs sospechosas, verificar que la URL del navegador es la correcta antes de introducir credenciales.
- Uso de gestores de contraseñas (Bitwarden, 1Password, KeePass): contraseñas únicas y aleatorias para cada servicio.
- MFA activado en todas las cuentas personales y corporativas.
- Política de escritorio limpio: no dejar información sensible visible, bloquear el equipo al alejarse.
- Cultura de reporte sin culpabilización: los empleados deben sentirse seguros reportando un incidente aunque hayan cometido un error.
Simulacros de phishing:
La empresa envía periódicamente emails de phishing simulados a sus empleados. Los que hacen clic reciben formación adicional inmediata. Las métricas (tasa de clics, tasa de reporte) permiten medir la madurez de seguridad de la organización y el progreso de la formación.
ISO/IEC 27001 es el estándar internacional para Sistemas de Gestión de Seguridad de la Información (SGSI). Define los requisitos para establecer, implementar, mantener y mejorar continuamente un SGSI. Publicado por la ISO (International Organization for Standardization) y la IEC.
¿Qué es un SGSI? Un conjunto de políticas, procesos, personas, tecnologías y controles que gestionan los riesgos de seguridad de la información de forma sistemática y continua.
Estructura:
- Cláusulas 4-10: requisitos del sistema de gestión (contexto, liderazgo, planificación, soporte, operación, evaluación, mejora).
- Anexo A: 93 controles de seguridad organizados en 4 temas: controles organizacionales, controles de personas, controles físicos, controles tecnológicos. (ISO 27001:2022; la versión anterior de 2013 tenía 114 controles en 14 dominios.)
Ciclo PDCA (Plan-Do-Check-Act):
PLAN → Identificar riesgos, definir controles, establecer políticas
DO → Implementar los controles y procesos
CHECK → Auditar, medir el rendimiento, revisar incidentes
ACT → Mejorar continuamente basándose en los resultados
Certificación ISO 27001: una auditoría externa por un organismo acreditado verifica que la organización cumple los requisitos. La certificación demuestra a clientes y socios que la seguridad se gestiona de forma rigurosa. Válida por 3 años con auditorías de seguimiento anuales.
Relación con ISO 27002: la ISO 27002 proporciona las guías de implementación detalladas para cada control del Anexo A de la ISO 27001. ISO 27001 dice qué hay que hacer; ISO 27002 dice cómo hacerlo.
El ENS (Esquema Nacional de Seguridad) es el marco de seguridad obligatorio para todas las administraciones públicas españolas y los proveedores que les prestan servicios. Regulado por el Real Decreto 311/2022, que actualiza el original de 2010.
Objetivos:
- Establecer la política de seguridad en el uso de medios electrónicos en las AAPP.
- Proporcionar un tratamiento homogéneo de la seguridad en todo el sector público.
- Fomentar la confianza en los servicios electrónicos.
Categorías de los sistemas:
Los sistemas se clasifican en tres categorías según el impacto que tendría un incidente de seguridad:
- Categoría ALTA: impacto muy grave en las funciones de la organización, activos, o individuos.
- Categoría MEDIA: impacto grave pero limitado.
- Categoría BÁSICA: impacto limitado.
La categoría determina las medidas de seguridad exigidas (más de 70 medidas organizadas en tres grupos: marco organizativo, marco operacional, medidas de protección).
CCN-CERT (Centro Criptológico Nacional): organismo responsable de la aplicación del ENS y de la respuesta a incidentes de las AAPP españolas. Publica las Guías CCN-STIC con instrucciones técnicas detalladas para implementar el ENS.
El Reglamento General de Protección de Datos (RGPD en español, GDPR en inglés) es el reglamento europeo de protección de datos personales. En vigor desde mayo de 2018. Aplica a cualquier organización que procese datos de ciudadanos de la UE, independientemente de dónde esté ubicada la organización.
Principios clave:
- Licitud, lealtad y transparencia: base legal para tratar datos (consentimiento, contrato, obligación legal, interés legítimo...).
- Limitación de finalidad: los datos solo pueden usarse para los fines para los que fueron recogidos.
- Minimización de datos: recoger solo los datos estrictamente necesarios.
- Exactitud: mantener los datos actualizados.
- Limitación del plazo de conservación: no guardar datos más tiempo del necesario.
- Integridad y confidencialidad: proteger los datos con medidas técnicas y organizativas apropiadas.
Implicaciones de seguridad directas:
- Cifrado y seudonimización de datos personales como medidas de protección adecuadas.
- Notificación de brechas de seguridad: obligatorio notificar a la AEPD (Agencia Española de Protección de Datos) en un máximo de 72 horas desde que se tiene conocimiento de una brecha. Si afecta a derechos y libertades de los interesados, también hay que notificarles a ellos.
- Privacidad por diseño y por defecto (Privacy by Design): incorporar la protección de datos desde el diseño del sistema, no como añadido posterior.
- EIPD (Evaluación de Impacto en la Protección de Datos): obligatoria para tratamientos de alto riesgo (videovigilancia masiva, perfilado, datos sensibles a gran escala).
- DPO (Delegado de Protección de Datos): obligatorio en ciertas organizaciones (AAPP, tratamiento a gran escala de datos sensibles).
Multas:
- Hasta 10 millones de euros o el 2% de la facturación global anual para infracciones menos graves.
- Hasta 20 millones de euros o el 4% de la facturación global anual para infracciones graves (las que afectan a principios básicos, derechos de los interesados, transferencias internacionales).
En España: la LOPDGDD (Ley Orgánica 3/2018) complementa y adapta el RGPD al ordenamiento jurídico español.
PCI-DSS (Payment Card Industry Data Security Standard):
Estándar de seguridad para organizaciones que procesan, almacenan o transmiten datos de tarjetas de crédito. Definido por las principales marcas de tarjetas (Visa, Mastercard, Amex...). Incluye 12 requisitos: red segura, protección de datos de tarjetas, gestión de vulnerabilidades, control de acceso, monitorización, política de seguridad.
NIST Cybersecurity Framework (CSF):
Marco voluntario del Instituto Nacional de Estándares y Tecnología de EE.UU. Organiza las actividades de ciberseguridad en cinco funciones: Identificar, Proteger, Detectar, Responder, Recuperar. Muy usado como referencia para evaluar y mejorar la postura de seguridad.
SOC 2 (Service Organization Control 2):
Estándar de auditoría para proveedores de servicios en la nube y SaaS. Evalúa los controles relacionados con seguridad, disponibilidad, integridad del procesamiento, confidencialidad y privacidad. Muy solicitado por clientes empresariales en EE.UU.
Pregunta 1
Una empresa ha detectado que varios empleados han recibido correos electrónicos muy convincentes suplantando al director financiero, solicitando transferencias urgentes a cuentas externas. Algunos empleados cayeron en el engaño.
a) ¿Qué tipo de ataque es este? Descríbelo técnicamente e indica sus variantes (whaling, BEC, spear phishing).
b) ¿Qué medidas técnicas y organizativas implementarías para prevenir este tipo de ataque en el futuro? Menciona al menos cuatro medidas concretas.
c) ¿Qué papel puede jugar la firma digital de correos electrónicos (S/MIME o DKIM) en la prevención de estos ataques? Explica cómo funciona cada mecanismo y sus limitaciones.
Pregunta 2
Explica la diferencia entre criptografía simétrica y asimétrica en términos de: número de claves, velocidad, seguridad del intercambio de claves y casos de uso.
a) ¿Por qué HTTPS no usa exclusivamente criptografía de clave pública para cifrar los datos? Describe el esquema híbrido que usa TLS.
b) Explica el concepto de Perfect Forward Secrecy (PFS) y por qué es importante. ¿Qué protocolo de intercambio de claves lo proporciona y cómo funciona matemáticamente?
c) Compara TLS 1.2 y TLS 1.3 indicando las mejoras de seguridad y rendimiento introducidas en la versión más reciente.
Pregunta 3
Una empresa necesita implementar acceso seguro sin contraseña para sus empleados, usando certificados digitales emitidos por una PKI propia.
a) Describe la arquitectura PKI que necesitarías, incluyendo todos los componentes (Root CA, CA intermedia, RA, VA, TSA) y su función. Justifica por qué no se usa la Root CA directamente para emitir certificados de usuario.
b) ¿Cómo verificaría un cliente que el certificado de un servidor es válido? Describe la cadena de confianza paso a paso.
c) ¿Qué ocurre si una clave privada de un certificado es comprometida? ¿Cómo se gestiona la revocación? Describe CRL y OCSP, incluyendo OCSP Stapling y sus ventajas.
Pregunta 4
Una empresa ha sido víctima de un ransomware que cifró todos los ficheros de sus servidores, eliminó las copias de seguridad locales y exige 500.000 € en Bitcoin.
a) Explica técnicamente por qué el ransomware usa AES para cifrar los ficheros y RSA para proteger la clave AES. ¿Por qué la víctima no puede descifrar sin pagar si no tiene la clave privada RSA del atacante?
b) Describe los pasos que seguirías para gestionar y remediar el incidente, desde el momento de detección hasta la restauración del servicio.
c) ¿Qué arquitectura de backup habría que haber implementado para que el ransomware no pudiera destruirla? Explica la regla 3-2-1-1-0 y el concepto de backup inmutable.
Pregunta 5
Explica qué es la autenticación multifactor (MFA) y analiza las tres opciones del siguiente escenario: una empresa quiere implementar MFA para su aplicación de gestión de personal.
a) Segunda contraseña estática: ¿es MFA real? ¿Qué factores combina? Ventajas e inconvenientes.
b) Código TOTP generado por una app en el móvil: ¿es MFA real? Explica técnicamente cómo se genera el código (RFC 6238). ¿Frente a qué ataques es efectivo y frente a cuáles es vulnerable?
c) Autenticación biométrica (huella) vinculada a un dispositivo corporativo, sin contraseña: ¿es MFA? ¿Qué factores combina? ¿Por qué la biometría no puede revocarse si se ve comprometida y qué implicaciones tiene eso?
Pregunta 6
Describe las diferencias técnicas entre un virus, un gusano y un troyano, incluyendo su mecanismo de propagación, el daño que causan y un ejemplo histórico relevante de cada uno.
a) ¿Por qué WannaCry causó tanto daño en tan poco tiempo? Describe la vulnerabilidad que explotó, cómo se propagaba y qué sistemas afectó.
b) ¿Qué dos medidas concretas habrían evitado o limitado significativamente el impacto de WannaCry? Razona tu respuesta.
c) Un empleado recibe un email con un documento Word adjunto llamado factura_2024.docx. Al abrirlo, aparece un mensaje pidiendo habilitar macros para "ver el contenido correctamente". ¿Qué tipo de malware es probable que sea y cómo funciona? ¿Qué debería hacer el empleado?
Pregunta 7
En el contexto de la configuración de un cortafuegos de inspección de estado (stateful inspection):
a) ¿Qué ventaja tiene sobre un cortafuegos de filtrado de paquetes stateless? Explica qué es la tabla de estado y cómo permite el tráfico de retorno sin reglas explícitas.
b) ¿Por qué las reglas se aplican de forma secuencial y qué implicación tiene en el diseño de las reglas? Ilustra con un ejemplo en el que el orden incorrecto rompe la seguridad.
c) Diseña las reglas necesarias para: (1) permitir tráfico web HTTP/80 y HTTPS/443 al servidor 10.0.1.20 desde cualquier origen, (2) permitir DNS (UDP/53) al servidor 10.0.1.53 solo desde la red interna 192.168.0.0/24, (3) denegar todo el resto del tráfico.
Pregunta 8
Explica qué es una función hash criptográfica y cuáles son sus cinco propiedades fundamentales.
a) ¿Por qué las contraseñas se almacenan como hashes en lugar de en texto cifrado o texto plano? ¿Qué problema resuelve la sal (salt) y cómo funciona?
b) Compara bcrypt y SHA-256 para el almacenamiento de contraseñas: ¿por qué bcrypt es preferible para este uso aunque SHA-256 sea más rápido? ¿Qué es Argon2 y qué lo hace especialmente resistente a ataques con GPU o ASIC?
c) Una empresa almacena contraseñas como MD5(contraseña) sin sal en su base de datos. La base de datos es robada. ¿Cuáles son los dos ataques concretos que el atacante puede usar para recuperar las contraseñas? ¿Cómo los habría mitigado una implementación correcta con Argon2 y sal?
Pregunta 9
Una empresa quiere asegurar el acceso remoto de sus empleados en teletrabajo a los recursos internos. Compara las siguientes opciones:
a) Acceso por SSH con autenticación de clave pública: describe cómo funciona criptográficamente el proceso de autenticación. ¿Por qué es más seguro que la autenticación por contraseña?
b) VPN con WireGuard: describe el protocolo criptográfico que usa (ChaCha20-Poly1305, Curve25519, BLAKE2). ¿Qué ventajas tiene frente a OpenVPN e IPsec en términos de superficie de ataque y rendimiento?
c) ¿Qué es Zero Trust Network Access (ZTNA) y en qué se diferencia conceptualmente de una VPN tradicional? ¿Cuál recomendarías para una empresa de 200 empleados con aplicaciones tanto en la nube como en un CPD propio, y por qué?
Pregunta 10
Define los conceptos de vulnerabilidad, amenaza, riesgo y exploit. Una empresa descubre que su servidor web usa Apache 2.4.49, que tiene la vulnerabilidad CVE-2021-41773 (Path Traversal / RCE, CVSS 9.8). El servidor está en producción y accesible desde Internet.
a) Clasifica la amenaza (interna/externa, intencional/accidental) y evalúa el riesgo teniendo en cuenta que hay exploits públicos disponibles para esta CVE. ¿Qué significa que el CVSS sea 9.8?
b) Describe las medidas inmediatas (primeras horas) y a corto plazo (primera semana) que tomarías ante este hallazgo.
c) Explica qué proceso de gestión de vulnerabilidades y hardening habría evitado que este servidor llegara a producción con una vulnerabilidad crítica conocida. ¿Qué papel juegan los CIS Benchmarks en este proceso?
Fin del Tema 2 — Criptografía, Certificados Digitales, PKI, Autenticación, Riesgos y Protección