markdown
Nota de estudio: Este tema es el núcleo de la seguridad informática en el temario. Conecta directamente con las preguntas Q2 (MFA y autenticación), 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. Su seguridad no proviene del secreto del algoritmo sino de la imposibilidad computacional de encontrar la clave.
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.
AES (Advanced Encryption Standard): el estándar actual. Bloques de 128 bits, claves de 128, 192 o 256 bits. Adoptado por el NIST en 2001. Usado en prácticamente todo: HTTPS, WiFi (WPA2/WPA3), disco cifrado (BitLocker, LUKS), VPN (IPsec, OpenVPN). Considerado seguro ante todos los ataques conocidos con claves de 128 bits o más.
DES (Data Encryption Standard): estándar anterior (1977). Clave de solo 56 bits. Obsoleto: se demostró que puede romperse por fuerza bruta en menos de 24 horas. No debe usarse.
3DES (Triple DES): aplica DES tres veces consecutivas con dos o tres claves diferentes. Clave efectiva de 112 bits. Casi obsoleto: lento y con clave corta para los estándares actuales. El NIST lo desaprobó en 2019. Solo en sistemas heredados.
Cifrado en flujo (stream cipher): genera un flujo pseudoaleatorio de bits (keystream) que se combina con el mensaje bit a bit mediante XOR.
Los modos de operación determinan cómo se aplica un cifrado de bloque a mensajes más largos que un bloque:
|
Modo
|
Nombre
|
Características
|
Uso
|
|
|
|
**
ECB
**
|
Electronic Codebook
|
Cada bloque cifrado independientemente.
**
Inseguro:
**
bloques iguales producen 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. Si el canal es seguro, ¿para qué necesitas cifrado?
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 que quieren comunicarse de forma privada entre sí, se necesitan N×(N-1)/2 claves distintas. Para 1000 personas: ~500.000 claves.
- No proporciona no repudio: cualquiera de los dos extremos que conoce la clave podría haber generado el mensaje.
La criptografía asimétrica (o de clave pública) resuelve el problema de distribución de claves mediante el uso de pares de claves matemáticamente relacionadas:
La relación matemática entre ambas claves garantiza: lo que se cifra con una solo puede descifrarse con la otra del mismo par. Sin embargo, aunque conozcas la clave pública, es computacionalmente imposible derivar la clave privada (con los recursos computacionales actuales).
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):
El algoritmo de clave pública más usado históricamente. Su seguridad se basa en la dificultad de factorizar números enteros muy grandes en sus factores primos. Factorizar 2 = 2×1 es trivial. Factorizar un número de 2048 bits en sus dos factores primos es computacionalmente inviable con hardware clásico.
ECC (Elliptic Curve Cryptography — Criptografía de Curva Elíptica):
Criptografía 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), considerado más difícil que la factorización de RSA.
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 es equivalente en seguridad a RSA-3072. Esto significa:
- Operaciones más rápidas (menor carga computacional).
- Menor tamaño de certificados y firmas.
- 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: la clave pública se puede distribuir libremente.
- Proporciona no repudio: la firma solo puede generarla el poseedor de la clave privada.
- Escalabilidad: N personas necesitan N pares de claves (no N² como en simétrico).
- Base de toda la infraestructura PKI y los certificados digitales.
Inconvenientes:
- Lenta: 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 criptografía simétrica o asimétrica. Se usa un esquema híbrido que combina las ventajas de ambas:
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:
Propiedades fundamentales:
hash("Hola mundo") = a591a6d40bf420404a011733cfb7b190d62c65bf0bcda32b
hash("hola mundo") = d5fdde47e9c2a7e62a7389fd8d32485e9f9b3e81dbe44da7
← un carácter diferente → hash completamente distinto
hash("Hola mundo ") = 2ce3c46a2a5e1d03e0e3282afaf5e553fb0eb2b0e2ae3fe5
Algoritmos hash más importantes:
|
Algoritmo
|
Tamaño del hash
|
Estado
|
Uso
|
|
|
|
**
MD5
**
|
128 bits (32 hex)
|
**
Roto
**
para integridad, no usar
|
Solo para checksums no criptográficos (comparar ficheros)
|
|
**
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 (cifradas se pueden descifrar si se obtiene la clave). 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 de 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 un 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 (ganador de la Password Hashing Competition en 2015) va un paso más allá: también requiere mucha RAM, lo que dificulta los ataques con GPU o ASIC especializados (que tienen mucha CPU pero poca RAM por núcleo).
2. Integridad de datos y verificación de ficheros:
sha256sum ubuntu-22.04.iso
# b85bfb25e3c2c58e34d74a8b8e20e6a5a0b0b0a7... ubuntu-22.04.iso
# Comparar con el hash oficial en la web del fabricante 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 de una blockchain 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 siempre es la misma independientemente del documento. La firma digital es diferente para cada documento (depende del hash del contenido). Intentar 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 (parte de EdDSA sobre Curve25519) es el estándar moderno recomendado para SSH keys, tokens de autenticación y firmas en general.
La criptografía de clave pública funciona perfectamente en teoría, pero 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 a este problema 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 DigiCert verificó que la entidad propietaria del dominio banco.com es Banco Ejemplo S.A. y que la clave pública incluida en el certificado les pertenece. Si el certificado fuera falsificado (cambiando la clave pública), la firma de DigiCert 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 (responder a email en admin@dominio.com o crear un fichero en el servidor)
|
Minutos
|
Bajo (~0-50€/año)
|
Candado verde, sin nombre empresa
|
|
**
OV (Organization Validation)
**
|
Verifica dominio + existencia legal de la organización (documentos oficiales)
|
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; navegadores modernos lo han eliminado visualmente
|
¿Por qué Let's Encrypt es gratuito? Emite solo certificados DV, automatizados completamente mediante el protocolo ACME (Automated Certificate Management Environment). No verifica identidad de la organización, solo control del dominio. Perfecto para HTTPS, pero no para e-commerce donde quieres mostrar quién es la empresa.
Subject Alternative Names (SAN): lista de dominios que cubre el certificado. Reemplazó al campo CN para identificar los dominios (el CN es solo el nombre principal). Un certificado wildcard como *.banco.com cubre todos los subdominios de primer nivel (www.banco.com, api.banco.com) pero no subdominios de nivel dos (test.api.banco.com).
Key Usage y Extended Key Usage: especifican para qué puede usarse la clave del certificado:
- 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 usarse para 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 (o ausente), es un certificado de entidad final (end-entity) 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. Contienen la clave pública del servidor.
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. Con firma válida, muestra el nombre del publicador.
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):
Certificados usados por las CAs para firmar otros certificados. 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, firmar documentos electrónicos con valor legal.
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 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 de compromiso de CA: en 2011, DigiNotar (CA holandesa) fue comprometida. Atacantes emitieron certificados fraudulentos para Google.com, Gmail.com y muchos otros dominios. Permitió 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, la CA y la RA están integradas en la misma entidad. En grandes PKIs corporativas o públicas, están separadas.
┌────────────────────┐
│ 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 ceremonia de claves (key ceremony) con múltiples testigos. Si la Root CA firmara directamente los certificados de usuarios, tendría que estar online constantemente, aumentando el riesgo.
Las CAs intermedias son las que operan online y firman los certificados de los usuarios. Si una CA intermedia se compromete:
1. Solo hay que revocar los certificados de esa CA intermedia.
2. La Root CA (offline) no está comprometida.
3. Se puede emitir una nueva CA intermedia con 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 navegador/SO.
4. Verifica las firmas hacia atrás: Root → Intermediate → End entity.
5. Toda la cadena válida → HTTPS seguro.
El SO y los navegadores tienen un almacén de certificados raíz de confianza preinstalado. Son las CAs cuya honestidad el fabricante del SO o navegador garantiza.
certmgr.msc./etc/ssl/certs/), o por la aplicación (Firefox tiene su propio almacén).A diciembre de 2024, hay ~140 organizaciones de CAs raíz con cientos de certificados en el almacén de Windows. Cada una de estas CAs puede emitir certificados válidos para cualquier dominio del mundo, lo cual es un punto de debilidad del sistema.
Lista de certificados que la CA ha revocado antes de su fecha de expiración. Los motivos de revocación incluyen: clave privada comprometida, la información del certificado ya no es válida, el propietario ha dejado de usar el certificado.
Problemas de las CRL:
- Pueden ser grandes (miles de entradas).
- El cliente debe descargarlas periódicamente: entre las actualizaciones puede haber un periodo donde un certificado revocado parece válido.
- Acceso a internet necesario para descargarlas.
Protocolo alternativo a las CRL. En lugar de descargar toda la lista, el cliente consulta al servidor OCSP de la CA si un certificado específico está revocado, en tiempo real.
Respuesta OCSP: good (válido), revoked (revocado, con fecha y motivo), unknown (la CA no conoce ese certificado).
OCSP Stapling: el servidor TLS consulta periódicamente el estado OCSP de su propio certificado y "grapa" la respuesta firmada del OCSP en el handshake TLS. El cliente recibe la respuesta directamente del servidor sin consultar la CA, más rápido y privado.
Certificate Transparency (CT): sistema moderno donde las CAs deben publicar en logs públicos auditables todos los certificados que emiten. Permite detectar certificados fraudulentos o emitidos sin autorización. Chrome requiere CT para confiar en un certificado desde 2018.
Active Directory Certificate Services (AD CS) es la implementación de PKI de Microsoft para entornos Windows. Permite crear una CA privada corporativa para emitir certificados internos.
Usos de una PKI corporativa:
- Certificados para los servidores internos (intranet HTTPS, LDAPS).
- Certificados para autenticación de usuarios y equipos en la red (802.1X, Smart Card login).
- Cifrado de correo interno (S/MIME).
- Autenticación de VPN sin contraseña.
- Firma de scripts PowerShell.
Ventajas sobre CAs públicas: control total, coste cero por certificado, certificados con vida más larga si es necesario, no depende de terceros.
Desventaja: los certificados solo son de confianza dentro de la organización (hay que añadir la CA corporativa al almacén de confianza de todos los equipos, lo que AD GPO hace automáticamente).
TLS (Transport Layer Security) es el protocolo criptográfico que proporciona comunicaciones seguras sobre redes inseguras. Es la "S" de HTTPS, SMTPS, FTPS, LDAPS, etc.
SSL (Secure Sockets Layer) es el predecesor de TLS, desarrollado por Netscape. Las versiones SSL 2.0 y 3.0 tienen vulnerabilidades conocidas. TLS 1.0 y 1.1 también son vulnerables. Solo TLS 1.2 y TLS 1.3 deben usarse.
|
Versión
|
Estado
|
Vulnerabilidades
|
|
|
|
SSL 2.0
|
**
Prohibido
**
(RFC 6176)
|
Múltiples, fundamental
|
|
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
|
Cliente Servidor
│ │
│── ClientHello ──────────────────────────► │
│ (versiones TLS soportadas, cipher │
│ suites, clave pública efímera ECDH) │
│ │
│◄─ ServerHello ────────────────────────── │
│ (versión elegida, cipher suite, │
│ clave pública efímera ECDH del servidor │
│ certificado del servidor) │
│ │
│ [Ambos calculan la clave de sesión │
│ con ECDHE sin intercambiarla] │
│ │
│◄─ Finished ───────────────────────────── │
│ (MAC de todo el handshake, cifrado) │
│ │
│── Finished ──────────────────────────── ► │
│ (MAC de todo el handshake, cifrado) │
│ │
│═══════ DATOS CIFRADOS (AES-256-GCM) ══════│
TLS 1.3 vs TLS 1.2:
- TLS 1.3 elimina algoritmos inseguros (RSA para intercambio de claves, MD5, SHA-1, RC4, 3DES, etc.).
- TLS 1.3 requiere PFS obligatoriamente (solo ECDHE o DHE para intercambio de claves).
- TLS 1.3 reduce el handshake de 2-RTT a 1-RTT (o incluso 0-RTT para reconexiones).
- TLS 1.3 cifra más del handshake (el certificado del servidor viaja cifrado).
Una cipher suite es una combinación de algoritmos criptográficos que define cómo funciona una sesión TLS:
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
│ │ │ │ │
│ │ │ │ └─ Hash para PRF/HMAC
│ │ │ └─────────── Cifrado simétrico + modo
│ │ └──────────────────── Autenticación del servidor
│ └─────────────────────────── Intercambio de claves (con PFS)
└──────────────────────────────── Protocolo
Cipher suites recomendadas en TLS 1.3 (son las únicas disponibles en TLS 1.3):
- TLS_AES_256_GCM_SHA384
- TLS_AES_128_GCM_SHA256
- TLS_CHACHA20_POLY1305_SHA256
HTTPS es simplemente HTTP transportado sobre TLS. El puerto por defecto es el 443 (HTTP usa el 80).
¿Qué protege HTTPS?
- Confidencialidad: nadie puede leer las credenciales, datos bancarios, o mensajes que se envían.
- Integridad: nadie puede modificar el contenido en tránsito (inyectar publicidad, malware, etc.).
- Autenticación del servidor: el cliente puede verificar que está hablando con el servidor legítimo y no con un impostor.
¿Qué NO protege HTTPS?
- No oculta a quién te conectas (el SNI — Server Name Indication — es visible en el handshake, aunque TLS 1.3 lo cifra con ECH: Encrypted Client Hello).
- No oculta el volumen de datos intercambiados.
- No protege si el propio servidor está comprometido.
- No protege frente a vulnerabilidades en el código de la aplicación (XSS, SQL injection...).
HSTS (HTTP Strict Transport Security): cabecera HTTP que indica al navegador que ese dominio siempre debe accederse por HTTPS, nunca por HTTP. Si alguien intenta un downgrade a HTTP (p.ej. en una red WiFi comprometida), el navegador rechaza la conexión.
SSH (Secure Shell) es el protocolo para acceso remoto seguro a sistemas Unix/Linux. Reemplazó completamente a Telnet (texto plano) y rsh. Puerto por defecto: 22.
SSH proporciona:
- Confidencialidad: toda la comunicación está cifrada.
- Autenticación del servidor: al conectar por primera vez, SSH muestra el fingerprint (hash) de la clave pública del servidor. Si la clave cambia (posible ataque MitM), SSH avisa. Las claves de hosts conocidos se almacenan en ~/.ssh/known_hosts.
- Autenticación del cliente: por contraseña (no recomendado) o por par de claves (recomendado).
Autenticación SSH por clave pública:
# 1. El cliente genera su par de claves (una sola vez)
ssh-keygen -t ed25519 -C "usuario@empresa.com"
# Genera: ~/.ssh/id_ed25519 (PRIVADA, nunca compartir)
# ~/.ssh/id_ed25519.pub (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
# El servidor envía un desafío cifrado con la clave pública del cliente
# El cliente demuestra que tiene la clave privada sin revelarla
SSH tunneling: SSH puede crear túneles cifrados para transportar otros protocolos:
# Túnel local: acceder a la base de datos del servidor remotamente
ssh -L 5432:localhost:5432 usuario@servidor.com
# Ahora localhost:5432 en el cliente es el puerto 5432 del servidor (cifrado)
# Dynamic port forwarding (proxy SOCKS)
ssh -D 8080 usuario@servidor.com
# Convierte el cliente en un proxy SOCKS que enruta el tráfico por SSH
Una VPN (Virtual Private Network) crea un canal cifrado (túnel) entre el cliente y el servidor VPN, haciendo que todo el tráfico del cliente viaje cifrado y aparezca como si viniera de la IP del servidor VPN.
Protocolos VPN principales:
|
Protocolo
|
Estándar
|
Seguridad
|
Velocidad
|
Notas
|
|
|
|
**
OpenVPN
**
|
Open source
|
Alta (TLS)
|
Media
|
Muy configurable, ampliamente auditado
|
|
**
IPsec/IKEv2
**
|
Estándar IETF
|
Alta
|
Alta
|
Nativo en muchos routers y SO
|
|
**
WireGuard
**
|
Open source (2020)
|
Muy alta
|
Muy alta
|
Código mínimo (~4000 líneas), moderno, preferido
|
|
**
L2TP/IPsec
**
|
IETF
|
Media
|
Media
|
Obsoleto, L2TP solo no cifra; depende de IPsec
|
|
**
PPTP
**
|
Microsoft (1999)
|
**
Roto
**
|
Alta
|
**
No usar. Múltiples vulnerabilidades críticas
**
|
Tipos de VPN:
VPN de acceso remoto (Remote Access VPN): conecta un usuario individual a la red corporativa desde fuera. El cliente VPN del usuario crea un túnel hasta el concentrador VPN de la empresa. Usado por empleados en teletrabajo.
VPN site-to-site: conecta dos redes completas (dos oficinas, una oficina con un CPD). No requiere software en los equipos individuales; los routers/firewalls de cada sede gestionan el túnel. Ejemplo: la sede de Madrid y la de Barcelona comparten red como si estuvieran físicamente conectadas.
Split tunneling: solo el tráfico hacia la red corporativa va por el túnel VPN. El resto del tráfico (Netflix, Google...) va directamente a Internet sin pasar por la VPN. Reduce la carga en el servidor VPN pero el tráfico no corporativo no está protegido.
Full tunneling: todo el tráfico del usuario va por el túnel VPN, incluyendo Internet. La empresa tiene visibilidad y control de todo el tráfico. Más seguro pero mayor carga en la VPN.
Conexión con el examen (pregunta 5): la pregunta pide describir qué es una VPN, sus propósitos y su funcionamiento. Los conceptos de cifrado, autenticación, túnel y protocolo son exactamente lo que cubre este apartado.
OAuth 2.0: protocolo de autorización (no autenticación) que permite a una aplicación acceder a recursos de otra en nombre del usuario sin que el usuario comparta sus credenciales.
Usuario quiere usar la app "ClimateApp" y esta quiere acceder a su Google Calendar
1. ClimateApp redirige al usuario a Google: "¿Autorizas a ClimateApp a ver tu Calendar?"
2. El usuario se autentica en Google (directamente, sin pasar por ClimateApp)
3. Google pregunta al usuario: "¿Autorizas el acceso?"
4. El usuario acepta: Google emite un token de acceso a ClimateApp
5. ClimateApp usa el token para acceder al Calendar del usuario
6. El usuario nunca da su contraseña de Google a ClimateApp
OpenID Connect (OIDC): capa de identidad sobre OAuth 2.0 que añade autenticación. Permite que una aplicación verifique la identidad del usuario basándose en la autenticación realizada por un servidor de autorización (Google, Microsoft, etc.).
Es la base del Single Sign-On (SSO): inicias sesión una vez con Google/Microsoft/empresa y accedes a múltiples aplicaciones sin volver a autenticarte.
JSON Web Token (JWT): formato estándar para transmitir información de identidad y autorización entre partes. Un JWT tiene tres partes separadas por puntos (.):
- Header: tipo de token y algoritmo de firma (Base64URL).
- Payload: claims (aserciones) sobre el usuario: sub (subject/usuario), iss (issuer), exp (expiration), roles, etc. (Base64URL).
- Signature: HMAC o firma RSA/ECDSA del header+payload. Garantiza que no ha sido manipulado.
eyJhbGciOiJSUzI1NiJ9.eyJzdWIiOiJ1c3VhcmlvMTIzIiwiaXNzIjoiYXV0aC5lbXByZXNhLmNvbSIsImV4cCI6MTcxNjMwMDAwMH0.firma...
La autenticación ya fue cubierta parcialmente en el Tema 1. Aquí se amplía desde la perspectiva de la criptografía y los estándares.
|
Factor
|
Tipo
|
Ejemplos
|
Vulnerabilidades
|
|
|
|
**
Algo que sabes
**
|
Conocimiento
|
Contraseña, PIN, pregunta secreta
|
Phishing, keyloggers, shoulder surfing, brechas de datos
|
|
**
Algo que tienes
**
|
Posesión
|
TOTP, hardware token, smart card, teléfono
|
Robo físico, SIM swapping, clonación
|
|
**
Algo que eres
**
|
Inherencia
|
Huella, iris, rostro, voz
|
Falsificación biométrica, privacidad, irrevocabilidad
|
|
**
Dónde estás
**
|
Ubicación
|
Geolocalización, IP corporativa
|
VPN, Tor, spoofing de IP
|
|
**
Cómo actúas
**
|
Comportamiento
|
Dinámica de tecleo, patrón de uso
|
Menos fiable, puede cambiar
|
import hmac, hashlib, time, base64, struct
def totp(secret_base32, timestamp=None, period=30, digits=6):
"""Genera un código TOTP según RFC 6238"""
if timestamp is None:
timestamp = time.time()
# Contador: número de intervalos de 30s desde epoch Unix
counter = int(timestamp // period)
# Decodificar el secreto compartido de Base32
key = base64.b32decode(secret_base32.upper())
# HMAC-SHA1 del contador (en big-endian de 8 bytes)
msg = struct.pack(">Q", counter)
h = hmac.new(key, msg, hashlib.sha1).digest()
# Dynamic Truncation: extraer 4 bytes usando el último nibble como offset
offset = h[-1] & 0x0F
code = struct.unpack(">I", h[offset:offset+4])[0] & 0x7FFFFFFF
# Modulo para obtener N dígitos
return str(code % (10 ** digits)).zfill(digits)
# Resultado: "483921" (varía cada 30 segundos)
Por qué TOTP es seguro: el código cambia cada 30 segundos. Un atacante que intercepta el código solo tiene 30 segundos para usarlo. Con latencia de red y tiempo de procesamiento, en la práctica el código ya ha caducado cuando el atacante lo intenta usar.
Vulnerabilidad de TOTP al phishing en tiempo real: si el atacante tiene un sitio de phishing y lleva al usuario a introducir su usuario, contraseña Y el código TOTP, y automáticamente usa esas credenciales en el sitio real, puede funcionar en los 30 segundos de validez. Solución: usar FIDO2/WebAuthn, que vincula criptográficamente la autenticación al dominio del sitio.
FIDO2 (Fast Identity Online 2) es un estándar de autenticación sin contraseña basado en criptografía de clave pública. WebAuthn es la API web que implementa FIDO2.
Funcionamiento:
1. Durante el registro, el autenticador (llave hardware como YubiKey, o el propio dispositivo con TPM/Secure Enclave) genera un par de claves específico para ese servicio. La clave pública se registra en el servidor.
2. Durante la autenticación, el servidor envía un desafío. El autenticador firma el desafío con la clave privada (que nunca sale del dispositivo). El servidor verifica la firma con la clave pública almacenada.
Ventajas cruciales:
- La clave privada nunca sale del dispositivo. No hay contraseña que robar en un servidor.
- La firma incluye el origen (dominio + protocolo). Un sitio de phishing banc0.com recibirá una firma vinculada a banc0.com, no a banco.com. El servidor banco.com rechazará esa firma. Inmune al phishing por diseño.
- Sin secretos compartidos en el servidor: si el servidor es comprometido, solo se filtran claves públicas, que no sirven para nada al atacante.
Passkeys: implementación de FIDO2 integrada en los SO y navegadores (Apple, Google, Microsoft). Permite autenticación sin contraseña usando Face ID, Touch ID o el PIN del dispositivo. Se sincroniza entre dispositivos del mismo usuario.
RBAC (Role-Based Access Control):
Usuario → Rol → Permisos
│ │
Ana Administrador → {leer_todo, escribir_config, gestionar_usuarios}
Bob Desarrollador → {leer_código, escribir_código, leer_logs}
Carol Solo_Lectura → {leer_código}
ABAC (Attribute-Based Access Control):
Las decisiones de acceso se toman evaluando atributos del sujeto (usuario), el objeto (recurso) y el entorno (contexto):
Regla: PERMITIR acceso si:
- usuario.departamento == "finanzas"
- recurso.clasificacion <= "confidencial"
- entorno.hora >= 08:00 && entorno.hora <= 18:00
- entorno.red IN ["red_corporativa", "VPN"]
Más flexible que RBAC pero más complejo. Usado en sistemas cloud (AWS IAM policies son básicamente ABAC).
PAM (Privileged Access Management):
Gestión específica de cuentas privilegiadas (administradores, root, DBA...). Las cuentas privilegiadas son los objetivos más valiosos para los atacantes. PAM incluye:
- Just-in-time access: los privilegios se conceden solo cuando se necesitan y por tiempo limitado.
- Session recording: todas las sesiones privilegiadas se graban.
- Password vaulting: las contraseñas de cuentas privilegiadas se rotan automáticamente y se almacenan en un vault seguro.
- Approval workflows: pedir acceso privilegiado requiere aprobación.
Principio de mínimo privilegio: cada usuario, proceso o sistema debe tener solo los permisos mínimos necesarios para realizar su función. No dar permisos "por si acaso". Un servidor web no necesita permisos de escritura en /etc. Un usuario de RRHH no necesita acceso a la base de datos de facturación.
Separación de funciones (Segregation of Duties): una acción crítica requiere la participación de múltiples personas para completarse. Impide el fraude interno: si crear una transferencia bancaria y aprobarla son funciones separadas, nadie puede hacerlo solo. En IT: quien desarrolla el código no debería tener permisos para desplegarlo en producción directamente.
Defensa en profundidad: no confiar en una única capa de seguridad. Si falla una capa, las demás siguen protegiendo. Contraseña + MFA + restricción de IP + VPN + firewall + detección de anomalías.
Activo: cualquier cosa de valor que necesita protección. Hardware, software, datos, reputación, personal, servicios.
Vulnerabilidad: debilidad en un sistema que puede ser explotada. Puede ser técnica (bug en el software), de configuración (contraseña por defecto) o humana (empleado susceptible a phishing).
Amenaza: agente o evento que puede explotar una vulnerabilidad. Puede ser un actor (hacker, empleado descontento, espía) o un evento (incendio, inundación, corte de luz).
Riesgo: probabilidad de que una amenaza explote una vulnerabilidad y el impacto resultante.
RIESGO = Probabilidad × Impacto
= f(Amenaza, Vulnerabilidad, Activo)
Exploit: código o técnica que aprovecha una vulnerabilidad específica para causar un comportamiento no deseado.
CVE (Common Vulnerabilities and Exposures): sistema estándar de identificación de vulnerabilidades conocidas públicamente. Cada vulnerabilidad tiene un identificador único: CVE-2021-44228 (Log4Shell). Puedes buscar la descripción, severidad (CVSS score) y parches disponibles en el NVD (National Vulnerability Database).
CVSS (Common Vulnerability Scoring System): sistema de puntuación de 0 a 10 que evalúa la severidad de una vulnerabilidad:
- 0.0: Ninguna
- 0.1 – 3.9: Baja
- 4.0 – 6.9: Media
- 7.0 – 8.9: Alta
- 9.0 – 10.0: Crítica
Zero-day: vulnerabilidad desconocida por el fabricante o sin parche disponible. Especialmente peligrosa porque no hay defensa directa hasta que se parcheé.
Un virus es código malicioso que se replica insertándose en otros programas o ficheros cuando estos se ejecutan. Necesita la acción del usuario para propagarse (ejecutar un fichero infectado).
Fases del ciclo de vida de un virus:
1. Infección: el virus se inserta en un programa o sector de arranque.
2. Latencia: permanece dormido, esperando un disparador (fecha, evento).
3. Propagación: se copia a otros ficheros/medios.
4. Activación: ejecuta su payload (borra ficheros, cifra datos, muestra mensajes).
Tipos por objetivo:
- Virus de fichero: infecta ejecutables (.exe, .com, .dll). Al ejecutar el programa infectado, el virus se activa.
- Virus de sector de arranque: infecta el MBR o sector de arranque. Se activa antes de que cargue el SO.
- Virus de macro: infecta documentos Office mediante macros VBA. Muy common en correos de phishing.
- Virus polimórfico: cambia su código en cada copia para evadir la detección por firma. El motor muta la encriptación del virus pero el comportamiento es el mismo.
- Virus metamórfico: reescribe completamente su código en cada generación, manteniendo la funcionalidad pero cambiando totalmente la apariencia. Muy difícil de detectar.
Un gusano es malware que se replica automáticamente a través de redes sin necesidad de un programa anfitrión ni acción del usuario. Explota vulnerabilidades de red para propagarse.
Diferencia clave con virus: el virus necesita que el usuario ejecute un fichero infectado. El gusano se propaga solo, automáticamente, a través de la red.
Ejemplos históricos:
- Morris Worm (1988): primer gusano de Internet. Explotó vulnerabilidades en sendmail, fingerd y rsh. Infectó miles de sistemas en horas. Creó el precedente legal para delitos informáticos.
- ILOVEYOU (2000): gusano/virus combinado. Se propagó por email con asunto "ILOVEYOU". Infectó 50 millones de PCs en 10 días. Daños estimados: 10.000 millones de dólares.
- WannaCry (2017): gusano/ransomware. Explotó la vulnerabilidad EternalBlue (MS17-010, SMBv1) desarrollada por la NSA y filtrada por Shadow Brokers. Infectó 200.000+ sistemas en 150 países en un día. Afectó al NHS (sistema sanitario británico), Telefónica, y decenas de grandes empresas.
- NotPetya (2017): disfrazado de ransomware pero era un wiper (borrador) diseñado para causar daño máximo. Misma vulnerabilidad que WannaCry. Daño: ~10.000 millones de dólares. Considerado el ciber-ataque más destructivo de la historia.
Impacto de los gusanos: consumo masivo de ancho de banda, sobrecarga de sistemas, payload secundario (ransomware, backdoor, espionaje).
Un troyano es malware que se presenta como software legítimo y útil, pero que contiene código malicioso oculto. Se llama así por el Caballo de Troya de la mitología griega.
No se replica: a diferencia de virus y gusanos, el troyano no se copia a sí mismo. El usuario lo instala voluntariamente pensando que es algo legítimo.
Técnicas de engaño:
- Crack de software de pago.
- Utilidades gratuitas descargadas de sitios no oficiales.
- Actualizaciones falsas ("actualice su Flash Player").
- Adjuntos de correo electrónico ("factura.pdf.exe").
Tipos de troyanos por función:
- RAT (Remote Access Trojan): da acceso remoto completo al sistema del atacante. Puede capturar pantalla, activar cámara/micrófono, descargar ficheros, ejecutar comandos.
- Troyano bancario: roba credenciales de banca online mediante keylogging o inyección web (modifica el HTML que ve el usuario para añadir campos de captura de datos).
- Dropper: descarga e instala otro malware (actúa como instalador silencioso).
- Backdoor: crea una puerta trasera para acceso futuro, evadiendo la autenticación normal.
- Rootkit: se instala en el nivel del kernel para ocultar su presencia (procesos, ficheros, conexiones de red) del SO y el antivirus.
El ransomware es malware que cifra los ficheros de la víctima y exige un rescate (ransom) a cambio de la clave de descifrado. Es el tipo de malware más destructivo económicamente en la actualidad.
Funcionamiento técnico de un ransomware moderno:
1. INFECCIÓN: entra por phishing, vulnerabilidad RDP, exploit de software, USB
2. PERSISTENCIA: se instala para sobrevivir reinicios (clave de registro, tarea programada)
3. RECONOCIMIENTO: enumera recursos compartidos de red, backups accesibles, AD
4. MOVIMIENTO LATERAL: se propaga a otros sistemas de la red (usando credenciales robadas)
5. EXFILTRACIÓN: antes de cifrar, copia datos a servidores del atacante (doble extorsión)
6. CIFRADO:
a. Genera una clave AES-256 aleatoria para cifrar los ficheros
b. Cifra la clave AES con la clave pública RSA del atacante (solo el atacante puede descifrarla)
c. Elimina copias de volumen (VSS) y backups locales accesibles
d. Cifra todos los ficheros de usuario en local y en red
7. RANSOM NOTE: muestra instrucciones para pagar en Bitcoin/Monero
Doble extorsión: además de cifrar, el atacante amenaza con publicar los datos robados si no se paga. Esto afecta a empresas aunque tengan backups (el descifrado no evita la publicación de datos confidenciales).
Triple extorsión: añade ataques DDoS al sitio web de la víctima o contacto directo a clientes de la víctima.
Ejemplos notables:
- CryptoLocker (2013): primer ransomware moderno exitoso. Usó RSA-2048. Recaudó ~27M$ antes de ser desmantelado.
- WannaCry (2017): ya mencionado. Afectó a infraestructuras críticas.
- REvil/Sodinokibi: grupo ransomware-as-a-service (RaaS). Atacó Kaseya (2021) afectando a 1500+ empresas a través de su software de gestión.
- Colonial Pipeline (2021): ataque al oleoducto de EEUU. Pagaron 4.4M$ de rescate. Causó escasez de combustible en la Costa Este.
Spyware: recopila información del usuario sin su conocimiento (historial de navegación, credenciales, capturas de pantalla) y la envía al atacante.
Adware: muestra publicidad no deseada. A menudo incluye funcionalidades de spyware. Técnicamente gris: a veces el usuario lo aceptó en la letra pequeña.
Rootkit: kit de herramientas para mantener acceso root/administrador a un sistema mientras se oculta la presencia del malware del SO y las herramientas de seguridad. Los rootkits de kernel (ring 0) son los más peligrosos y difíciles de detectar/eliminar.
Bootkit: rootkit que infecta el MBR o el proceso de arranque UEFI. Se carga antes del SO, por lo que el SO no puede detectarlo. Secure Boot previene los bootkits que no están firmados.
Keylogger: registra las pulsaciones de teclado. Puede capturar contraseñas, números de tarjeta, mensajes. Puede ser hardware (dispositivo físico entre teclado y ordenador) o software.
Cryptominer: usa los recursos de la CPU/GPU del sistema para minar criptomonedas en beneficio del atacante. No destruye datos pero degrada el rendimiento y aumenta el consumo eléctrico.
Fileless malware: no escribe ficheros en disco. Vive completamente en memoria RAM, en el registro de Windows, o en scripts de PowerShell/WMI. Muy difícil de detectar por antivirus tradicionales basados en análisis de ficheros.
Fuerza bruta: probar todas las combinaciones posibles. Para una contraseña de 8 caracteres (minúsculas + mayúsculas + números + símbolos = 95 caracteres):
- 95^8 = 6.6 × 10^15 combinaciones.
- Una GPU moderna puede probar ~10^10 hashes SHA-256 por segundo.
- Tiempo para romper: ~660.000 segundos = ~7.6 días.
- Con bcrypt (factor de coste 12): ~9 años.
Diccionario: probar palabras del diccionario y variaciones comunes (contraseñas con sustituciones: p@ssw0rd, c0ntr4seña). Las personas son predecibles en cómo crean contraseñas.
Ataque de rainbow table: usar tablas precomputadas de hash→contraseña. Muy rápido pero requiere mucho almacenamiento. Inútil contra contraseñas con sal, porque hay que precalcular una tabla para cada sal posible.
Password spraying: en lugar de probar muchas contraseñas para un usuario (que activaría el bloqueo), probar una contraseña común (p.ej. "Verano2024!") contra muchos usuarios. Evita los bloqueos por intentos fallidos.
Credential stuffing: usar listas de usuario/contraseña obtenidas en brechas de datos para intentar acceder a otros servicios (muchos usuarios reutilizan contraseñas). HaveIBeenPwned.com tiene miles de millones de credenciales filtradas.
Phishing: emails, SMS o webs falsas que imitan entidades legítimas (banco, administración pública, empresa) para robar credenciales o instalar malware.
Spear phishing: phishing dirigido a una persona o empresa específica, con información personalizada (nombre, empresa, cargo) para aumentar la credibilidad.
Vishing: phishing por teléfono (voice phishing). El atacante llama haciéndose pasar por el soporte técnico, el banco, etc.
Smishing: phishing por SMS.
Whaling: spear phishing dirigido a altos ejecutivos (CEO, CFO). Los ejecutivos son objetivos valiosos porque tienen acceso a información sensible y autoridad para realizar transferencias bancarias.
BEC (Business Email Compromise): el atacante compromete o suplanta la cuenta de email de un ejecutivo para ordenar transferencias fraudulentas al departamento de finanzas.
Baiting: dejar un USB infectado en el aparcamiento de la empresa esperando que un empleado curioso lo conecte.
Pretexting: crear una historia elaborada para conseguir información o acceso. El atacante llama al soporte técnico diciendo ser el CTO en viaje de negocios que necesita acceso urgente.
Vishing de soporte técnico: el atacante llama a la víctima diciendo ser el soporte de Microsoft/Apple, alertando de un problema grave en su ordenador, y pidiendo acceso remoto para "solucionarlo".
Man-in-the-Middle (MitM): el atacante se coloca entre dos partes interceptando y posiblemente modificando las comunicaciones. En redes WiFi abiertas es especialmente fácil.
ARP Spoofing/Poisoning: en una red local, el atacante envía respuestas ARP falsas para asociar su dirección MAC con la IP del router, consiguiendo que el tráfico de la red pase por su equipo. Base de ataques MitM en LAN. Mitigación: Dynamic ARP Inspection en switches gestionados.
DNS Spoofing/Cache Poisoning: enviar respuestas DNS falsas para redirigir el tráfico de un dominio a una IP maliciosa. Si el servidor DNS de la víctima almacena en caché la respuesta falsa, todos los usuarios afectados son redirigidos.
DNSSEC: extensión de DNS que usa firmas criptográficas para garantizar la autenticidad de las respuestas DNS. Mitiga el DNS spoofing.
SSL Stripping: el atacante hace un downgrade de la conexión HTTPS a HTTP, interceptando el tráfico en texto plano. Mitigado por HSTS (el navegador rechaza conexiones HTTP a dominios con HSTS).
DDoS (Distributed Denial of Service): inundar un servidor o red con tráfico masivo desde miles de máquinas (botnet) para hacer el servicio inaccesible. No requiere comprometer el objetivo; solo saturar su capacidad.
SQL Injection: insertar código SQL malicioso en campos de entrada de una aplicación web:
Campo "nombre de usuario": admin' OR '1'='1
Consulta SQL resultante: SELECT * FROM usuarios WHERE user='admin' OR '1'='1' AND pass='...'
'1'='1' siempre es verdadero → login sin contraseña
XSS (Cross-Site Scripting): inyectar JavaScript malicioso en una web que se ejecuta en el navegador de otros usuarios. Puede robar cookies de sesión, redirigir a páginas de phishing, etc.
CSRF (Cross-Site Request Forgery): engañar al navegador del usuario para que realice solicitudes no autorizadas a un sitio donde está autenticado. Por ejemplo, un enlace en un foro que al hacer clic transfiere dinero desde tu cuenta bancaria (si estás logado en el banco).
Las APT (Amenazas Persistentes Avanzadas) son ataques sofisticados y prolongados realizados por actores con recursos significativos (generalmente estados-nación o grupos muy organizados).
Características:
- Objetivos específicos: una empresa, una agencia gubernamental, infraestructura crítica.
- Largo plazo: pueden pasar meses o años sin ser detectados.
- Multi-etapa: exploración → compromiso inicial → persistencia → movimiento lateral → exfiltración de datos.
- Evasión activa: evitan los sistemas de detección, adaptan sus técnicas.
Ejemplos:
- Stuxnet: malware de estado-nación (atribuido a EEUU/Israel). Destruyó centrifugadoras de uranio iraníes manipulando los PLCs sin que los operadores lo notaran.
- SolarWinds (2020): compromiso de la cadena de suministro. Los atacantes insertaron backdoor en las actualizaciones de SolarWinds Orion, afectando a miles de organizaciones incluyendo agencias del gobierno de EEUU.
No depender de una sola capa de seguridad. Si una falla, las demás siguen protegiendo.
[INTERNET]
│
▼
[Filtrado DNS / Threat Intelligence]
│
▼
[Firewall perimetral / IPS]
│
▼
[DMZ: servidores públicos]
│
▼
[Firewall interno]
│
▼
[Segmentación de red / VLANs]
│
▼
[Endpoint Protection (EDR/AV)]
│
▼
[Autenticación + MFA]
│
▼
[Cifrado de datos en reposo y en tránsito]
│
▼
[Datos]
Un cortafuegos es el sistema de seguridad que controla el tráfico de red entre zonas según un conjunto de reglas.
Filtrado de paquetes (Packet Filtering):
Analiza los paquetes individualmente sin contexto. Filtra por:
- IP origen/destino.
- Puerto origen/destino.
- Protocolo (TCP, UDP, ICMP).
Stateless: no recuerda el estado de las conexiones. Una regla que permite TCP/80 entrante deja pasar cualquier paquete TCP con destino puerto 80, independientemente de si corresponde a una conexión establecida o no. Simple pero limitado.
Inspección de estado (Stateful Inspection / SPI):
Mantiene una tabla de estado con las conexiones activas. Un paquete entrante se permite si corresponde a una conexión establecida desde dentro. Mucho más seguro que stateless.
Tabla de estado:
| IP src | Puerto src | IP dst | Puerto dst | Estado |
|-----------|------------|------------|------------|-----------|
| 192.168.1.5 | 52341 | 93.184.216.34 | 443 | ESTABLISHED |
| 192.168.1.10| 49231 | 8.8.8.8 | 53 | ESTABLISHED |
Conexión directa con el examen (pregunta 6): el cortafuegos de la pregunta 6 es exactamente un stateful inspection firewall. Las reglas se aplican secuencialmente y se considera el estado de la conexión (por eso puede permitir el tráfico de retorno de conexiones establecidas sin necesitar reglas explícitas para ello).
Deep Packet Inspection (DPI) / NGFW (Next-Generation Firewall):
Analiza el contenido de los paquetes (capa de aplicación), no solo las cabeceras. Puede:
- Identificar el protocolo real independientemente del puerto (P2P en puerto 80).
- Filtrar por aplicación (bloquear WhatsApp aunque use HTTPS).
- Detectar intrusiones (IDS/IPS integrado).
- Filtrar URLs y categorías web.
- Inspeccionar tráfico SSL/TLS (SSL inspection/man-in-the-middle corporativo).
WAF (Web Application Firewall):
Específico para proteger aplicaciones web. Filtra, monitoriza y bloquea tráfico HTTP/HTTPS. Protege contra SQL injection, XSS, CSRF, ataques de fuerza bruta a formularios de login, etc. Se sitúa frente al servidor web.
[INTERNET]
│
▼
[Router ISP / modem]
│
▼
[FIREWALL PERIMETRAL]
├──────────────────► [DMZ (Red Desmilitarizada)]
│ Servidores públicos:
│ Web, Email, DNS, VPN
│
└──────────────────► [RED INTERNA]
Equipos de usuarios,
servidores internos,
bases de datos
DMZ (Demilitarized Zone): zona intermedia entre Internet y la red interna. Los servidores en la DMZ son accesibles desde Internet pero están aislados de la red interna. Si un servidor DMZ es comprometido, el atacante no tiene acceso directo a la red interna.
Conexión con el examen (pregunta 6): la DMZ mencionada en la pregunta 6 es exactamente esta arquitectura. Los servidores web (139.44.55.23) y DNS (139.55.44.39) están en la DMZ.
Regla implícita de denegación al final (implicit deny all): si ninguna regla acepta el paquete, se rechaza por defecto. El cortafuegos solo permite lo que está explícitamente permitido.
Principio de menor privilegio: solo abrir los puertos estrictamente necesarios.
Orden de reglas: las reglas más específicas deben ir antes que las más generales. En el examen, la regla que permite el DNS desde 139.55.44.39 debe ir ANTES que la regla que bloquea el DNS desde toda la DMZ.
Stateful vs stateless para servicios: para tráfico TCP (web, SSH, email...), el firewall stateful gestiona automáticamente las respuestas. Para UDP (DNS), el tracking de estado es más limitado.
IDS (Intrusion Detection System): monitoriza el tráfico de red o el comportamiento del sistema en busca de actividad sospechosa y alerta al administrador. Detecta pero no bloquea.
IPS (Intrusion Prevention System): como el IDS pero puede tomar acción automática: bloquear el tráfico malicioso, terminar conexiones, aislar el equipo. Detecta y bloquea.
Tipos de detección:
Detección por firma (signature-based): compara el tráfico o comportamiento contra una base de datos de firmas de ataques conocidos. Eficaz contra ataques conocidos, inútil contra zero-days o variantes nuevas. Similar a los antivirus tradicionales.
Detección por anomalías (anomaly-based): establece una línea base de comportamiento normal y alerta cuando algo se desvía significativamente. Puede detectar ataques nuevos pero genera más falsos positivos.
Detección por comportamiento (behavioral): modelos de ML que aprenden patrones de comportamiento legítimo e identifican desviaciones. Base de los EDR modernos.
SIEM (Security Information and Event Management): plataforma centralizada que recopila logs de múltiples fuentes (firewalls, IDS, servidores, aplicaciones, endpoints), los correlaciona y detecta patrones de ataque multi-etapa que serían invisibles analizando cada fuente por separado.
La mayoría de los ataques exitosos explotan vulnerabilidades conocidas con parche disponible. WannaCry explotó MS17-010, para el que Microsoft había publicado el parche MS17-010 dos meses antes del ataque. Los sistemas sin parchear eran vulnerables; los parcheados no.
Proceso de gestión de parches:
1. Inventario: conocer todos los sistemas y versiones de software.
2. Evaluación: determinar la criticidad de cada parche (CVSS score, si hay exploit público).
3. Priorización: primero parches críticos para sistemas expuestos a Internet.
4. Pruebas: probar en un entorno de test antes de producción.
5. Despliegue: aplicar parches con gestión centralizada (WSUS en Windows, Satellite/Ansible en Linux).
6. Verificación: confirmar que el parche se aplicó correctamente.
Ventana de parche: tiempo desde que se publica el parche hasta que los atacantes lo usan en exploits masivos. Históricamente: días a semanas. Herramientas de explotación automática aceleran esto.
Los EDR son la evolución de los antivirus tradicionales. En lugar de solo comparar ficheros contra firmas de malware conocido, los EDR:
Ejemplos: CrowdStrike Falcon, Microsoft Defender for Endpoint, SentinelOne, Palo Alto Cortex XDR.
La copia de seguridad es la última línea de defensa contra ransomware, borrado accidental, fallos de hardware y desastres.
Evolución de la regla 3-2-1 clásica:
- 3 copias de los datos.
- 2 tipos de soporte diferentes (disco local + cinta / nube).
- 1 copia offsite (fuera de las instalaciones).
- 1 copia offline o inmutable (no accesible desde la red; el ransomware no puede cifrarla).
- 0 errores verificados en las restauraciones (los backups se prueban regularmente).
Por qué el backup offline es crítico frente al ransomware: el ransomware moderno, antes de cifrar, busca y elimina o cifra todos los backups accesibles desde la red. Un backup en cinta desconectada o en almacenamiento inmutable (tipo WORM: Write Once Read Many) no puede ser afectado.
RPO (Recovery Point Objective): punto máximo en el tiempo hasta el que se puede restaurar. Si el RPO es 4 horas, como máximo se pierden 4 horas de datos.
RTO (Recovery Time Objective): tiempo máximo aceptable para restaurar el servicio tras un desastre. Si el RTO es 2 horas, el servicio debe estar operativo en 2 horas.
DRP (Disaster Recovery Plan): plan documentado y probado que define cómo restaurar los sistemas y datos tras un desastre mayor. Debe incluir: lista de sistemas críticos, orden de recuperación, procedimientos paso a paso, contactos de emergencia, y ensayos periódicos.
Conexión directa con el examen (pregunta 8): las preguntas 8b (tipos de backup), 8c (recuperación ante desastres) y 8d (deduplicación) se cubren directamente aquí.
Cifrado en reposo (encryption at rest): protege los datos almacenados para que sean ilegibles si el medio de almacenamiento es robado o accedido físicamente.
BitLocker (Windows): cifrado de disco completo usando AES-256. La clave se puede proteger con TPM, PIN + TPM, o USB + TPM. Si se roba el portátil o se extrae el disco, los datos son ilegibles.
FileVault (macOS): similar a BitLocker para macOS. Usa XTS-AES-128.
LUKS (Linux Unified Key Setup): estándar de cifrado de disco en Linux. Usa dm-crypt del kernel. Configurable con múltiples slots de clave (hasta 32 contraseñas distintas pueden descifrar el disco).
Transparent Data Encryption (TDE): cifrado a nivel de base de datos. Los ficheros de base de datos en disco están cifrados, pero la base de datos los descifra automáticamente cuando el motor de BD los necesita. Protege contra robo del medio de almacenamiento pero no contra acceso al motor de BD.
Cifrado de ficheros individuales: EFS en NTFS, OpenPGP, VeraCrypt para contenedores cifrados portátiles.
Hardening es el proceso de reducir la superficie de ataque de un sistema eliminando servicios y configuraciones innecesarias y activando los mecanismos de seguridad disponibles.
Principios de hardening:
Eliminar lo innecesario:
# Desactivar y eliminar servicios no necesarios en Linux
systemctl disable bluetooth
systemctl disable cups # servicio de impresión si no se necesita
apt remove telnetd rsh-server nis # protocolos inseguros
Configurar correctamente lo que se mantiene:
# SSH: deshabilitar login de root y contraseñas, solo claves
# /etc/ssh/sshd_config:
PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
Protocol 2
MaxAuthTries 3
Gestión de privilegios:
- Eliminar o deshabilitar cuentas por defecto (Administrator, Guest).
- Cambiar contraseñas por defecto de todos los dispositivos (routers, switches, cámaras IP).
- Usar el principio de mínimo privilegio en todas las cuentas.
Configuraciones de seguridad del SO:
- Activar el firewall local.
- Activar el registro/auditoría de eventos.
- Desactivar el autorun/autoplay de medios extraíbles.
- Activar Secure Boot y TPM.
- Cifrar el disco con BitLocker/LUKS.
Benchmarks de hardening:
- CIS Benchmarks: guías de configuración segura para cada SO, base de datos y aplicación, publicadas por el Center for Internet Security. El estándar de facto en la industria.
- DISA STIGs: guías del Departamento de Defensa de EEUU para sistemas de alta seguridad.
El usuario es el eslabón más débil. 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.
Formación en seguridad:
- Reconocer phishing (verificar remitente, no hacer clic en enlaces sospechosos, verificar URLs).
- Gestión de contraseñas: usar gestores de contraseñas (Bitwarden, 1Password, KeePass), contraseñas únicas por servicio, MFA en todo lo posible.
- Política de escritorio limpio (no dejar información sensible visible).
- Reportar incidentes: cultura de reporte sin culpabilización.
Simulacros de phishing: la empresa envía emails de phishing simulados a sus empleados. Los que caen reciben formación adicional. Métricas: tasa de clics, tasa de reporte.
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.
La certificación ISO 27001 demuestra a clientes y socios que la organización gestiona la seguridad de la información de forma sistemática y rigurosa.
Ámbitos del Anexo A: 114 controles de seguridad organizados en 14 dominios (política de seguridad, seguridad en RRHH, control de accesos, criptografía, seguridad física, gestión de incidentes, continuidad del negocio, etc.).
El ENS (Esquema Nacional de Seguridad) es el marco de seguridad obligatorio para las administraciones públicas españolas (Real Decreto 311/2022). Define los principios y requisitos mínimos de seguridad para los sistemas de información que tratan datos o prestan servicios de las AAPP.
Categorías del ENS: Alta, Media, Básica (según el impacto si se viera comprometida la seguridad).
El Reglamento General de Protección de Datos (RGPD/GDPR) es el reglamento europeo de protección de datos personales. Aplica a cualquier organización que procese datos de ciudadanos de la UE.
Principios relevantes para seguridad:
- Cifrado y seudonimización de datos personales.
- Notificación de brechas de seguridad en 72 horas.
- Privacidad por diseño y por defecto.
- Evaluaciones de impacto para tratamientos de alto riesgo.
Multas: hasta 20 millones de euros o el 4% de la facturación global anual, lo que sea mayor.
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. (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?
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. ¿Por qué HTTPS no usa exclusivamente criptografía de clave pública para cifrar los datos? Describe el esquema híbrido que usa TLS y explica el concepto de Perfect Forward Secrecy y por qué es importante.
Pregunta 3
Una empresa necesita implementar acceso seguro sin contraseña para sus empleados, usando certificados digitales. (a) Describe la arquitectura PKI que necesitarías, incluyendo los componentes y su función. (b) ¿Cómo verificaría un cliente que el certificado de un servidor es válido? Describe la cadena de confianza. (c) ¿Qué ocurre si un certificado es comprometido? ¿Cómo se gestiona la revocación? Describe CRL y OCSP.
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 cómo funciona el cifrado del ransomware (¿por qué usa AES + RSA?). (b) Describe los pasos que seguirías para gestionar y remediar el incidente. (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.
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. Considera: (a) segunda contraseña estática, (b) código TOTP generado por una app en el móvil, (c) autenticación biométrica (huella) vinculada a un dispositivo corporativo. Para cada opción indica si es MFA real, qué factores combina, sus ventajas e inconvenientes técnicos y frente a qué ataques es efectivo o vulnerable.
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. ¿Por qué WannaCry causó tanto daño en tan poco tiempo? ¿Qué dos medidas concretas habrían evitado o limitado significativamente el impacto de WannaCry?
Pregunta 7
En el contexto de la configuración de un cortafuegos de inspección de estado (stateful), explica: (a) qué ventaja tiene sobre un cortafuegos de filtrado de paquetes stateless, (b) qué es una tabla de estado y cómo se usa para permitir el tráfico de retorno sin necesidad de reglas explícitas, (c) por qué las reglas se aplican de forma secuencial y qué implicación tiene esto en el orden de las reglas, (d) diseña las reglas para permitir tráfico web (80/443) a un servidor con IP 10.0.1.20 en la DMZ desde cualquier origen.
Pregunta 8
Explica qué es una función hash criptográfica y cuáles son sus cinco propiedades fundamentales. ¿Por qué las contraseñas se almacenan como hashes en lugar de en texto cifrado? ¿Qué es la sal (salt) y por qué es necesaria? Compara bcrypt y SHA-256 para el almacenamiento de contraseñas, explicando por qué uno es preferible al otro para este uso. ¿Qué es Argon2 y qué lo hace especialmente resistente a ataques?
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, (b) VPN con WireGuard, (c) solución Zero Trust Network Access (ZTNA). Para cada una describe cómo funciona criptográficamente, qué protege, sus ventajas e inconvenientes. ¿Cuál recomendarías para una empresa de 200 empleados con aplicaciones tanto en la nube como en un CPD propio?
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 y evalúa el riesgo. (b) Describe las medidas inmediatas y a corto plazo que tomarías. (c) Explica qué proceso de gestión de vulnerabilidades habría evitado que este servidor llegara a producción con una vulnerabilidad crítica conocida.
Fin del Tema 2 — Criptografía, Certificados Digitales, PKI, Autenticación, Riesgos y Protección
Listo
Se quedó sin mensajes gratuitos has