Seguridad en redes informáticas

Un mensaje puede ser privado y aun así haber sido alterado o proceder de una persona que suplanta a otra. Por eso la comunicación segura necesita varias propiedades, cada una de las cuales responde a una pregunta diferente sobre el intercambio.

Identifica la propiedad en riesgo

Alice y Bob son las partes que se comunican; Trudy es la atacante. Una atacante pasiva captura tráfico sin modificarlo. Leer una contraseña es escucha. Inferir un horario de trabajo ajetreado a partir de los tiempos de conexión es análisis de tráfico, incluso cuando el contenido está cifrado. Una atacante activa inyecta, modifica, elimina o repite paquetes. La suplantación consiste en declarar una identidad de origen falsa; el secuestro toma el control de un intercambio existente; la inundación intenta agotar los recursos.

Los encaminadores de internet generalmente reenvían paquetes sin demostrar que sus direcciones de origen son auténticas. Los paquetes también atraviesan redes fuera del control de cualquiera de los dos usuarios. En Wi-Fi, otro dispositivo de radio dentro del alcance puede capturar las tramas transmitidas. Los protocolos deben proteger la comunicación incluso cuando una atacante controla el trayecto.

Sigue un inicio de sesión expuesto

Bob se conecta al punto de acceso de una cafetería e inicia sesión mediante HTTP sin protección. Trudy lee la contraseña: la confidencialidad ha fallado. Cambia un enlace de descarga en la respuesta: la integridad ha fallado. Si proporciona un punto de acceso falso con el nombre de la cafetería, Bob tampoco dispone de una comprobación fiable de la identidad del punto de acceso. Cifrar solo la contraseña no solucionaría todos estos fallos. Una atacante puede alterar algunos mensajes cifrados sin entenderlos y puede repetir sin cambios un mensaje de autenticación capturado.

Mantén la clave en secreto

El principio de Kerckhoffs establece que la seguridad debe resistir la divulgación del algoritmo. El secreto es la clave. Un algoritmo secreto de elaboración propia puede recuperarse del software; cambiar y distribuir un algoritmo completo también es más difícil que sustituir una clave. Sustituir una clave expuesta protege el tráfico futuro, pero no hace seguros los registros obtenidos con la clave antigua.

El conocimiento de la atacante también importa. Un ataque de solo texto cifrado comienza con mensajes cifrados interceptados. Un ataque de texto en claro conocido añade los mensajes originales correspondientes, como el texto predecible de HTTP/1.1 que comienza por «GET /». En un ataque de texto en claro elegido, la atacante puede obtener el cifrado de los mensajes que seleccione. El cifrado moderno está diseñado para resistir estas situaciones más exigentes.

Localiza el trayecto protegido

La seguridad Wi-Fi y celular protege un enlace radioeléctrico. TLS protege la comunicación entre extremos de aplicación. IPsec protege el tráfico IP seleccionado entre sistemas terminales o pasarelas. La protección a nivel de mensaje, como el correo seguro, puede permanecer con un mensaje durante su almacenamiento. Un salto radioeléctrico seguro no protege el resto de una ruta por internet: después de que un punto de acceso elimine la protección del enlace, otro mecanismo debe proteger el tráfico posterior.

Un cifrado simétrico utiliza la misma clave secreta en ambos extremos. El texto en claro es el mensaje original; el texto cifrado es su forma cifrada. Escribe el cifrado como $c=E_{K_S}(m)$ y el descifrado como $m=D_{K_S}(c)$: la clave es compartida, pero las dos operaciones se deshacen entre sí.

Tamaño de clave y debilidades estructurales

Un desplazamiento César de 3 convierte «NOS VEMOS AL MEDIODIA» en «QRV YHPRV DO PHGLRGLD». Probar los 25 desplazamientos útiles permite romperlo. Un cifrado por sustitución tiene $26!\approx \mathrm{4,03}\times {10}^{26}$ claves, pero conserva las frecuencias de las letras. Una atacante puede utilizar letras repetidas y palabras comunes para recuperar las correspondencias sin probar todas las claves. El tamaño del espacio de claves por sí solo no demuestra que el cifrado sea seguro.

AES es un cifrado por bloques con bloques de 128 bits y claves de 128, 192 o 256 bits. DES tenía bloques de 64 bits y una clave de 56 bits; una búsqueda exhaustiva permitió encontrar una clave DES en 1998, y DES y Triple DES se han retirado del uso estándar. Cada bit adicional de la clave duplica el trabajo de la búsqueda exhaustiva. A ${10}^{12}$ intentos por segundo, buscar entre todas las claves DES lleva unos $2^{56}\mathrm{/}{10}^{12}\approx 72000$ segundos, o 20 horas; encontrarlas lleva en promedio la mitad de ese tiempo. Buscar entre todas las claves AES-128 a esa tasa lleva aproximadamente $\mathrm{1,1}\times {10}^{19}$ años.

El modo cambia la protección del mensaje

Un modo de operación trata mensajes de más de un bloque.

El primer bloque de CBC utiliza un vector de inicialización, o IV, en lugar de un bloque de texto cifrado anterior. El IV se envía abiertamente; importan su carácter impredecible y que sea nuevo, no su secreto. La aleatorización oculta los patrones que muestran directamente que unos mensajes son iguales a otros. Por sí sola no detecta manipulaciones.

Analiza la reutilización del flujo de clave

Supón que dos mensajes utilizan el mismo flujo de clave $k$. Sus textos cifrados son $c_1=m_1\oplus k$ y $c_2=m_2\oplus k$. Al aplicarles XOR, el flujo de clave repetido se cancela:

Conocer uno de los textos en claro revela ahora el otro. Los IV repetidos de WEP causaron este tipo de fallo. Una clave de cifrado más larga no soluciona la repetición de un flujo de clave.

AEAD, el cifrado autenticado con datos asociados, combina confidencialidad e integridad. AES-GCM y ChaCha20-Poly1305 autentican el texto cifrado y cualquier dato asociado. Los datos asociados, como un campo de encaminamiento, siguen siendo legibles, pero no pueden modificarse sin que falle la verificación. TLS 1.3 utiliza AEAD para cada registro protegido.

Distribuye el secreto

El cifrado rápido del grueso de los datos sigue requiriendo una clave compartida. Si cada pareja entre $n$ usuarios necesita una clave diferente, el total es $n(n-1)\mathrm{/}2$. Para 100 usuarios, son 4950 claves. Los mecanismos de clave pública permiten a las partes establecer claves de sesión sin distribuir de antemano un secreto distinto a cada pareja.

Bob publica $K_B^{+}$ y mantiene $K_B^{-}$ como clave privada. Alice puede cifrar para Bob sin compartir primero un secreto con él. Recuperar la clave privada a partir de la pública debe ser computacionalmente inviable.

Calcula un intercambio RSA simplificado

RSA comienza con los números primos $p$ y $q$. Calcula $n=pq$ y $z=(p-1)(q-1)$. Elige un exponente público $e$ coprimo con $z$ y encuentra después $d$ tal que $ed<mrow><mi\; mathvariant="normal">m</mi><mi\; mathvariant="normal">o</mi><mi\; mathvariant="normal">d</mi></mrow>z=1$. La clave pública es $(n,e)$; la clave privada es $(n,d)$. Para un número de mensaje menor que $n$:

Utiliza los números primos simplificados 11 y 13. Entonces $n=143$ y $z=120$. Con $e=7$, elige $d=103$ porque $7\times 103=721=6\times 120+1$. Para $m=9$, las elevaciones sucesivas al cuadrado dan $9^2<mrow><mi\; mathvariant="normal">m</mi><mi\; mathvariant="normal">o</mi><mi\; mathvariant="normal">d</mi></mrow>143=81$ y $9^4<mrow><mi\; mathvariant="normal">m</mi><mi\; mathvariant="normal">o</mi><mi\; mathvariant="normal">d</mi></mrow>143=126$. Al combinar las potencias se obtiene $9^7<mrow><mi\; mathvariant="normal">m</mi><mi\; mathvariant="normal">o</mi><mi\; mathvariant="normal">d</mi></mrow>143=48$. El descifrado devuelve ${48}^{103}<mrow><mi\; mathvariant="normal">m</mi><mi\; mathvariant="normal">o</mi><mi\; mathvariant="normal">d</mi></mrow>143=9$.

Estos números muestran la aritmética; RSA en la práctica utiliza módulos de al menos 2048 bits. Factorizar el módulo revela los números primos y permite recuperar la clave. El cifrado RSA real también utiliza relleno aleatorio OAEP: el RSA teórico sin relleno repite su texto cifrado cuando se repite un mensaje.

Acuerda un secreto con Diffie–Hellman

Diffie–Hellman establece un secreto compartido sin enviarlo. Alice y Bob publican un número primo $p$ y un generador $g$. Alice mantiene $a$ en secreto y envía $A=g^a<mrow><mi\; mathvariant="normal">m</mi><mi\; mathvariant="normal">o</mi><mi\; mathvariant="normal">d</mi></mrow>p$. Bob mantiene $b$ en secreto y envía $B=g^b<mrow><mi\; mathvariant="normal">m</mi><mi\; mathvariant="normal">o</mi><mi\; mathvariant="normal">d</mi></mrow>p$. Alice calcula $B^a<mrow><mi\; mathvariant="normal">m</mi><mi\; mathvariant="normal">o</mi><mi\; mathvariant="normal">d</mi></mrow>p$ y Bob calcula $A^b<mrow><mi\; mathvariant="normal">m</mi><mi\; mathvariant="normal">o</mi><mi\; mathvariant="normal">d</mi></mrow>p$; ambos obtienen $g^{ab}<mrow><mi\; mathvariant="normal">m</mi><mi\; mathvariant="normal">o</mi><mi\; mathvariant="normal">d</mi></mrow>p$.

Para $p=29$, $g=2$, $a=5$ y $b=12$, Alice envía 3 y Bob envía 7. El cálculo de Alice es $7^5<mrow><mi\; mathvariant="normal">m</mi><mi\; mathvariant="normal">o</mi><mi\; mathvariant="normal">d</mi></mrow>29=16$; el de Bob es $3^{12}<mrow><mi\; mathvariant="normal">m</mi><mi\; mathvariant="normal">o</mi><mi\; mathvariant="normal">d</mi></mrow>29=16$. Su ejemplo con números pequeños es fácil de romper; los grupos grandes hacen inviable recuperar los exponentes secretos. Los intercambios de curva elíptica como X25519 cumplen la misma función con claves más cortas.

Autentica el intercambio

Diffie–Hellman por sí solo no identifica a ninguno de los participantes. Trudy puede sustituir los valores públicos por los suyos y crear dos secretos compartidos distintos, uno con Alice y otro con Bob. Después lee y vuelve a cifrar el tráfico. Un protocolo autenticado vincula los valores intercambiados a identidades de confianza mediante firmas y certificados o un secreto compartido establecido previamente.

Los protocolos utilizan cifrado híbrido: las operaciones de clave pública establecen una clave de sesión y AES o ChaCha20 se encarga del grueso de los datos. RSA puede transportar una clave de sesión aleatoria, pero el robo posterior de la clave privada RSA deja expuestos los intercambios registrados. Los valores Diffie–Hellman efímeros nuevos, eliminados después de usarlos, proporcionan secreto hacia adelante frente al robo posterior de claves de autenticación de larga duración.

Una computadora cuántica suficientemente grande rompería RSA y Diffie–Hellman clásico. ML-KEM, estandarizado por el NIST en FIPS 203 en 2024, aborda el establecimiento de claves poscuántico. Un esquema híbrido como X25519MLKEM768 combina componentes clásicos y poscuánticos. En este uso, «híbrido» describe dos mecanismos de establecimiento de claves; el grueso de los datos sigue utilizando cifrado simétrico, incluidas claves de 256 bits para un amplio margen de seguridad.

Una comprobación de integridad debe resistir a una atacante que actúa deliberadamente, no solo a errores accidentales. Una suma de comprobación de red y una función hash criptográfica tienen propósitos diferentes, y ninguna autentica un mensaje por sí sola.

Comprende las propiedades de las funciones hash

Una función hash criptográfica transforma un mensaje de cualquier longitud en un resumen de tamaño fijo. SHA-256 produce 256 bits, normalmente escritos como 64 dígitos hexadecimales. Las buenas funciones hash tienen tres propiedades de resistencia distintas:

Las colisiones existen porque un conjunto finito de resúmenes representa un número mayor de mensajes posibles. La seguridad significa que encontrar una colisión útil es inviable. MD5 y SHA-1 tienen ataques de colisión prácticos y no son adecuados para firmas ni certificados. SHA-3 ofrece otra familia moderna de funciones hash.

Los cambios pequeños en el mensaje se propagan por todo el resumen: este es el efecto avalancha. Cambiar «Pay Ana 100» por «Pay Ana 900» modifica 124 bits de la salida SHA-256; los resúmenes comienzan por ECD0D31E y 21736708. En cambio, la suma de comprobación de internet tanto de «PAY 1290» como de «PAY 9012» es 0xEC3B: intercambiar las palabras de 16 bits correspondientes conserva su suma. Una suma de comprobación diseñada para detectar daños aleatorios es fácil de conservar deliberadamente.

Añade el secreto que la atacante no tiene

Enviar abiertamente un mensaje y su resumen hash no resuelve la manipulación activa. Trudy sustituye tanto el mensaje como su resumen, de modo que el nuevo cálculo del receptor coincide. Un código de autenticación de mensajes, o MAC, añade una clave de autenticación secreta compartida por Alice y Bob.

Alice envía $m$ y $\mathrm{M}\mathrm{A}\mathrm{C}(s,m)$. Bob calcula una etiqueta a partir del mensaje recibido y de su propia copia de $s$, y después compara las etiquetas. Si Trudy cambia «Paga a Ana 100» por «Paga a Ana 900», Bob calcula la etiqueta para el texto modificado. La etiqueta antigua que Trudy copió no supera la comparación. El mensaje puede seguir siendo legible: un MAC proporciona integridad y autenticación de quien posee la clave, no confidencialidad.

HMAC utiliza una función hash con dos pasadas anidadas que incorporan la clave. HMAC-SHA256 es una opción estándar. Utilizar simplemente $H(s\mathrm{\parallel }m)$ con SHA-256 no es seguro: la extensión de longitud puede permitir a una atacante añadir bytes y calcular una etiqueta que coincida sin conocer la clave. La construcción de HMAC evita ese fallo.

Distingue la autenticidad de la frescura

Un mensaje antiguo con su MAC original sigue teniendo una etiqueta válida. Para rechazar la repetición, autentica un número de secuencia o un desafío nuevo junto con el mensaje y comprueba ese valor de frescura en el receptor. Añadir un número sin autenticar no basta porque Trudy podría cambiarlo.

Ambos poseedores de la clave compartida pueden crear etiquetas válidas. Por tanto, una tercera parte no puede utilizar un MAC para decidir cuál de ellos escribió un mensaje. Las firmas digitales proporcionan esa prueba verificable públicamente. Al combinar cifrado con un MAC separado, utiliza claves separadas y cifra antes de aplicar el MAC, autenticando el texto cifrado; una construcción AEAD proporciona una alternativa integrada.

Una firma digital permite a cualquiera comprobar una prueba creada con una clave privada. Quien verifica necesita tanto una comprobación de firma sólida como un vínculo fiable entre la clave pública y la identidad que representa.

Firma y verifica un mensaje

Quien firma utiliza una clave privada; quien verifica utiliza la clave pública correspondiente. Las firmas vinculan su prueba al mensaje, por lo que una alteración hace que falle la verificación. La clave privada debe permanecer bajo el control de quien firma. Esto permite el no repudio: una prueba de la firma verificable de forma independiente, a diferencia de un MAC que cualquiera de los poseedores de la clave compartida podría crear.

Los esquemas procesan un resumen o una representación codificada del mensaje. En un modelo RSA simplificado, la firma es $K_B^{-}(H(m))$. El receptor calcula el resumen y lo compara con el valor recuperado mediante la clave pública de Bob. Las firmas RSA reales añaden una codificación como RSASSA-PSS; ECDSA y Ed25519 utilizan una aritmética diferente. Firmar no es un método de propósito general para cifrar un mensaje con una clave privada.

Para una clave RSA simplificada con $n=143$, $e=7$ y $d=103$, supón que el número del resumen es 20. Bob calcula $\sigma ={20}^{103}<mrow><mi\; mathvariant="normal">m</mi><mi\; mathvariant="normal">o</mi><mi\; mathvariant="normal">d</mi></mrow>143=58$. Alice obtiene ${58}^7<mrow><mi\; mathvariant="normal">m</mi><mi\; mathvariant="normal">o</mi><mi\; mathvariant="normal">d</mi></mrow>143=20$ y lo compara con su propio resumen. Si el texto alterado tiene el resumen 21, el 20 recuperado no coincide. La resistencia a colisiones importa porque, de otro modo, dos mensajes con el mismo resumen podrían compartir la misma entrada para la firma.

Vincula una clave a un nombre

Trudy puede generar un par de claves perfectamente válido. Si etiqueta su clave pública como «Bob», una verificación correcta de la firma por sí sola no revelará la sustitución. Un certificado digital vincula una identidad a una clave pública mediante la firma de una autoridad de certificación.

Un certificado X.509 de un sitio web contiene nombres de dominio en el campo de nombre alternativo del sujeto, la clave pública del sujeto, un emisor, fechas de validez y la firma del emisor. Un servidor normalmente proporciona su certificado final y los certificados intermedios. El cliente comprueba esta cadena hasta llegar a una raíz en la que ya confía su sistema operativo o navegador. La autofirma de una raíz no es lo que hace que sea de confianza; su inclusión en el almacén de confianza proporciona esa confianza inicial.

Quien verifica comprueba las firmas a lo largo de la cadena, las fechas de validez, el nombre previsto, el uso permitido y la información de revocación cuando está disponible. Una cadena que termina en una raíz desconocida no pasa a ser de confianza solo porque sus firmas sean matemáticamente válidas.

Exige una prueba de posesión de la clave

Los certificados son públicos y pueden copiarse. Un servidor también debe demostrar que controla la clave privada asociada firmando datos nuevos del intercambio de establecimiento. Un archivo de certificado robado por sí solo no puede producir esa firma. Un certificado ordinario válido de un sitio web establece el control de su nombre de dominio; no establece que el contenido o la actividad del sitio sean honestos.

La autenticación de los extremos pregunta quién participa ahora. Un mensaje antiguo válido puede demostrar que alguien poseyó una clave en algún momento, pero no demostrar que el emisor actual la posee.

Rompe las versiones débiles

Alice envía primero «Soy Alice». Trudy puede enviar esas mismas palabras. Añadir la dirección IP de origen de Alice falla porque un datagrama puede contener una dirección falsificada. Enviar una contraseña la expone a quien observa. Cifrar una contraseña fija oculta su contenido, pero deja una prueba reutilizable: Trudy registra el texto cifrado y lo envía en otro inicio de sesión.

Esto es un ataque de repetición. La atacante no descifra ni modifica la prueba antigua. La debilidad está en que Bob acepta los mismos bytes en una sesión nueva. Un cifrado más fuerte no solucionaría ese error del protocolo.

Haz que la prueba dependa de este intento

Bob envía un valor de un solo uso nuevo e impredecible, un desafío que se utiliza una vez en este contexto de autenticación. Alice devuelve un valor que requiere su clave secreta, como un HMAC del desafío. Bob calcula la respuesta esperada con su copia de la clave. Una respuesta copiada de un desafío anterior no coincidirá.

Por ejemplo, el desafío del lunes es 0x7F3A91C2. Trudy captura su respuesta válida. El martes Bob envía 0x0B66E4D9. Repetir la respuesta del lunes falla porque la etiqueta esperada del martes se calcula a partir de bytes diferentes. Los valores hexadecimales cortos ilustran el intercambio; los desafíos reales necesitan suficientes bits aleatorios para evitar predicciones útiles o repeticiones.

El carácter impredecible también impide la recopilación anticipada. Si el siguiente desafío de Bob es fácil de adivinar, Trudy puede hacerse pasar por Bob, pedir a Alice que responda a ese desafío futuro y después presentar la respuesta obtenida a Bob. Un desafío debe estar ligado al intercambio actual del protocolo, no solo parecer diferente del anterior.

Autentica con claves públicas

Alice puede firmar un desafío nuevo con su clave privada. Bob lo verifica con la auténtica clave pública de Alice. Si Bob acepta una clave pública sustituta proporcionada por Trudy, Trudy puede firmar ella misma el desafío de Bob. Los certificados establecen el vínculo entre identidad y clave; la firma nueva demuestra la posesión actual de esa clave.

En la autenticación mutua, ambos pares demuestran sus identidades. Un protocolo debe distinguir sus funciones y vincular las pruebas a la sesión para que la respuesta de una parte no pueda simplemente devolverse como si fuera la de la otra. TLS en la web ordinaria suele autenticar al servidor con un certificado; después, el usuario se autentica dentro de ese canal protegido mediante una contraseña o una clave de acceso. Las conexiones entre servicios y las VPN suelen autenticar ambos extremos.

Protege lo que sigue al inicio de sesión

Una autenticación satisfactoria no protege el tráfico posterior en claro. Trudy podría esperar a que termine el inicio de sesión y después inyectar comandos o secuestrar la conexión. Los intercambios de establecimiento seguros establecen claves de sesión y los mensajes posteriores llevan una protección de integridad vinculada a esa sesión.

El desafío-respuesta tampoco refuerza automáticamente una contraseña débil elegida por una persona. Si quien observa puede volver a calcular una respuesta capturada para cada posible contraseña, puede realizar un ataque de diccionario sin conexión. La comprobación de frescura detiene la repetición, mientras que un secreto fuerte o un intercambio adecuado autenticado mediante contraseña hace frente a los intentos de adivinarla; las dos protecciones resuelven problemas diferentes.

TLS proporciona a dos procesos de aplicación un canal confidencial y autenticado sobre un flujo fiable de bytes. En el caso habitual de HTTPS, HTTP utiliza TLS sobre TCP, normalmente en el puerto 443. Una biblioteca de la aplicación, como OpenSSL o BoringSSL, gestiona TLS; TCP transporta sus bytes sin interpretarlos.

Establece claves y después protege los registros

Un intercambio de establecimiento autentica al par y establece material de claves compartido. La derivación de claves convierte ese material en secretos separados para el tráfico del intercambio y para los datos de aplicación, con claves diferentes para cada dirección. Un registro saliente de Alice no puede simplemente devolverse como si fuera de Bob porque la dirección de recepción utiliza una protección diferente.

TLS divide los datos en registros, lo que permite al receptor verificar una parte cada vez. Un registro en claro transporta como máximo $2^{14}=16384$ bytes de contenido. Su cabecera corta incluye un tipo, un campo de versión heredado y una longitud. El cifrado añade información adicional, por lo que un registro cifrado es más grande que el contenido original. En TLS 1.3, el tipo externo de registro protegido no revela directamente el tipo de contenido de aplicación o de intercambio que contiene.

TLS 1.3 exige AEAD. El receptor verifica la etiqueta de autenticación de un registro antes de entregar su texto en claro a la aplicación. Si Trudy modifica una solicitud HTTP protegida, la etiqueta falla: el receptor termina la conexión y utiliza bad_record_mac para indicar un fallo de protección del registro. TLS detecta la interferencia; no convierte los bytes modificados maliciosamente de nuevo en una solicitud válida.

Cuenta los registros en cada dirección

Cada emisor y receptor mantiene un número de secuencia de registro implícito. Este no se envía en la cabecera del registro TLS. TLS 1.3 le aplica XOR con un IV propio de cada dirección para producir el valor de un solo uso de AEAD. Repetir un registro antiguo en una posición nueva utiliza un número esperado incorrecto y hace que falle la autenticación. Eliminar o reordenar registros protegidos altera igualmente la secuencia esperada cuando se procesan los bytes posteriores.

Los números de secuencia de TCP siguen ocupándose de la entrega y la reordenación ordinarias. No autentican al par: una atacante que controla el trayecto puede falsificar cabeceras TCP. El recuento de registros de TLS está vinculado a la protección con clave secreta, por lo que una entrega TCP satisfactoria por sí sola no implica que la verificación TLS también lo sea.

Detecta un final incompleto

Supón que Bob espera un documento, pero la conexión TCP se cierra a mitad de la transmisión. Un FIN falsificado o un enlace interrumpido puede terminar la entrega del transporte sin demostrar que el emisor TLS haya terminado. TLS utiliza la alerta protegida close_notify para señalar el final ordenado de su flujo de envío. Sin ella, el receptor debe considerar un posible truncamiento y utilizar las reglas de integridad de la aplicación; un fin de archivo TCP inesperado no es un marcador de final autenticado.

Una atacante siempre puede descartar paquetes y detener el progreso. La confidencialidad y la integridad no garantizan la disponibilidad. La longitud completa de un mensaje HTTP puede ayudar a una aplicación a reconocer que llegó un mensaje, pero esa es una comprobación distinta del cierre ordenado de TLS.

Distingue protocolos relacionados

TLS 1.3 se especifica en RFC 9846, que sustituyó a RFC 8446 en 2026. TLS 1.2 sigue desplegado; SSL 2.0/3.0 y TLS 1.0/1.1 están obsoletos. DTLS adapta el diseño de seguridad a los datagramas. QUIC transporta el intercambio de establecimiento de TLS 1.3 dentro de su protocolo de transporte basado en UDP y después protege por sí mismo los paquetes QUIC; no envía registros ordinarios de TLS sobre TCP a través de UDP.

Un intercambio de establecimiento de TLS debe establecer un secreto y mostrar a quién pertenece. En un intercambio completo de TLS 1.3 basado en certificados, el acuerdo de claves efímero proporciona material de claves nuevo y las firmas vinculan la negociación a la identidad del servidor.

Sigue las tandas de mensajes

1. ClientHello ofrece versiones, conjuntos de cifrado AEAD, grupos de intercambio de claves, algoritmos de firma, datos aleatorios y uno o varios valores key_share. Normalmente identifica el servidor mediante SNI.
2. ServerHello selecciona parámetros y proporciona el valor de intercambio de claves del servidor. Ambos pares calculan material de claves compartido y derivan las claves de tráfico del intercambio de establecimiento.
3. El servidor envía los mensajes cifrados EncryptedExtensions, Certificate, CertificateVerify y Finished. CertificateVerify firma una entrada estructurada que incluye el resumen hash de la transcripción del intercambio; Finished autentica la transcripción con una clave MAC derivada.
4. El cliente comprueba la cadena, el nombre del servidor, la firma y Finished, y después envía su propio Finished. El tráfico de aplicación utiliza secretos de tráfico derivados por separado.

El certificado del servidor asocia un nombre a una clave pública. CertificateVerify demuestra el control de la clave privada en este intercambio. Finished detecta interferencias en la transcripción de la negociación. Son comprobaciones separadas: derivar un secreto compartido correctamente no establece la identidad del servidor.

Cuenta los tiempos de ida y vuelta

Con un RTT de 40 ms, sin contar los retardos de procesamiento ni de transmisión, el establecimiento de TCP tarda 40 ms y un intercambio completo de TLS 1.3 añade 40 ms. El cliente envía su solicitud a los 80 ms; una respuesta puede llegar alrededor de los 120 ms. Un intercambio completo de TLS 1.2 añade dos RTT después de TCP, por lo que los tiempos correspondientes son 120 ms y 160 ms. QUIC combina el establecimiento del transporte con el intercambio TLS, lo que permite a una conexión nueva enviar su solicitud después de un RTT, a los 40 ms.

Un HelloRetryRequest añade un tiempo de ida y vuelta cuando el servidor necesita un valor de intercambio de claves diferente. Que ambas partes admitan un grupo no basta si la oferta inicial no contenía un valor aceptable.

Vincula la negociación y separa los secretos

Si Trudy elimina conjuntos de cifrado fuertes de un ClientHello durante el tránsito, el cliente y el servidor registran transcripciones diferentes. La autenticación de esas transcripciones falla. TLS también incluye una señal de degradación de versión cuando un servidor compatible negocia una versión anterior.

El esquema de derivación de claves utiliza HKDF, basado en HMAC, para derivar secretos específicos para cada propósito. Las claves del intercambio protegen los mensajes de establecimiento; las claves de aplicación protegen los datos posteriores. KeyUpdate sustituye las claves de tráfico de aplicación durante una conexión larga. TLS 1.3 eliminó el transporte de claves RSA estático: un certificado RSA aún puede autenticar un intercambio mediante una firma, mientras el acuerdo de claves efímero proporciona secreto hacia adelante.

Reanuda sin repetir la autenticación mediante certificado

Después del establecimiento, NewSessionTicket permite a los pares preparar la reanudación. Derivan una PSK de reanudación a partir del secreto de reanudación y del valor de un solo uso del ticket; más tarde, el cliente presenta el ticket como identificador de la PSK y demuestra que la posee. La reanudación puede incluir un nuevo intercambio Diffie–Hellman para obtener secreto hacia adelante.

0-RTT envía datos anticipados con la primera tanda de mensajes, pero esos datos pueden repetirse. Utilízalo solo cuando sea seguro repetir una solicitud, nunca para una operación de pago repetible sin protección. Las protecciones del intercambio posterior no hacen que los datos anticipados sean resistentes a la repetición de forma retroactiva.

TLS mutuo añade un certificado de cliente solicitado y una prueba de posesión de su clave privada. Los grupos híbridos poscuánticos como X25519MLKEM768, definido en RFC 10024, combinan X25519 y ML-KEM-768 de modo que el secreto se mantenga si cualquiera de los dos componentes sigue siendo seguro.

El cifrado solo es útil cuando llega al par previsto. Un cliente debe validar la identidad asociada a las claves antes de enviar datos de aplicación sensibles.

Comprueba toda la declaración de identidad

Un cliente TLS comprueba que la cadena de certificados llega a una raíz de su almacén de confianza, que las firmas y los períodos de validez son correctos, que el nombre solicitado coincide con el certificado y que el certificado permite la autenticación de servidores TLS. Cuando comprueba la revocación, esta comprobación también debe superarse. CertificateVerify demuestra después la posesión de la clave privada correspondiente.

La coincidencia de nombres se refiere al sistema terminal con el que el cliente pretendía contactar, no a un nombre que el servidor sugiera después de conectarse. Un certificado para *.example.com cubre www.example.com y mail.example.com. No cubre ni example.com ni a.b.example.com: el comodín sustituye exactamente una etiqueta. Un certificado perfectamente válido para un dominio incorrecto sigue fallando la autenticación.

Por ejemplo, un cliente solicita shop.example.net, pero recibe un certificado de confianza y vigente para *.example.com. La cadena y las fechas pueden superar la comprobación; la comprobación del nombre falla. El cliente debe rechazar esa conexión. Un certificado no es una autorización general para que su poseedor suplante a cualquier servidor.

Comprende una interceptación cifrada

Si se desactiva la verificación de certificados, Trudy puede terminar la conexión TLS del cliente y crear una segunda conexión TLS con el servidor real. Ambos enlaces están cifrados, pero Trudy tiene el texto en claro entre ellos. Por tanto, comprobar el cifrado sin comprobar al par no detecta el ataque. Mantén activada la validación de certificados y trata una comprobación de identidad fallida como una conexión fallida.

Un proxy de inspección TLS de una organización sigue deliberadamente una estructura relacionada. Los dispositivos administrados confían en la raíz de la organización, lo que permite a su proxy emitir certificados que aceptan. El proxy termina una conexión segura y comienza otra. El trayecto del navegador al servidor tiene entonces un extremo de confianza adicional con acceso al texto en claro.

Protege la primera solicitud

En la eliminación de la protección SSL, una atacante mantiene el lado del usuario en HTTP mientras contacta con el sitio mediante HTTPS. Esto puede comenzar cuando un navegador intenta acceder por primera vez a una dirección sin protocolo mediante HTTP. HSTS indica al navegador que utilice HTTPS en las visitas posteriores. Una entrada precargada puede imponer HTTPS incluso antes de la primera visita; una política aprendida solo después de una visita HTTPS satisfactoria no puede proteger retroactivamente una solicitud HTTP anterior.

Identifica lo que sigue siendo visible

TLS 1.3 cifra el certificado del servidor y el contenido de la aplicación, pero quienes observan aún ven las direcciones de red, los puertos, los tiempos y los tamaños de los registros. El SNI ordinario de ClientHello expone el nombre del servidor solicitado. El saludo del cliente cifrado, estandarizado en RFC 9849, protege ese nombre cuando está desplegado. Una consulta DNS sin protección independiente también puede revelar el nombre de destino.

TLS protege los datos entre sus extremos mientras viajan. No puede reparar el software malicioso en el cliente, un servidor comprometido, datos almacenados de forma insegura ni fallos de la aplicación. Tampoco puede impedir el descarte de paquetes. IPsec aborda un alcance diferente: aplica protección de capa de red al tráfico IP seleccionado sin exigir que cada aplicación invoque TLS. Utilizar ambos puede proteger distintos tramos de la misma ruta.

IPsec aplica protección en la capa IP, donde puede cubrir el tráfico TCP, UDP e ICMP sin modificar sus aplicaciones. Sus extremos pueden ser sistemas terminales individuales o pasarelas que conectan redes completas.

Elige un protocolo y un modo

AH utiliza el número de protocolo IP 51; ESP utiliza el 50. ESP es la opción habitual para el tráfico de las VPN modernas. La protección de AH incluye campos de dirección que NAT modifica, lo que hace que la traducción ordinaria de direcciones sea incompatible con su comprobación de autenticación. ESP no autentica la cabecera IP externa.

En modo transporte, la cabecera ESP se sitúa entre la cabecera IP original y el segmento de transporte. Los encaminadores siguen viendo el origen y el destino originales. En modo túnel, una nueva cabecera IP contiene las direcciones de los dos extremos del túnel y el datagrama IP original viaja en su interior. Con ESP cifrado en modo túnel, quienes observan desde fuera no pueden leer las direcciones de los sistemas terminales originales ni los puertos de transporte, pero sí pueden leer las direcciones de las pasarelas necesarias para el reenvío. AH en modo túnel sigue sin proporcionar confidencialidad.

IPsec puede proporcionar confidencialidad, integridad, autenticación del origen y protección contra repeticiones. Los servicios reales dependen del protocolo, los algoritmos y la política; elegir AH no proporciona cifrado solo por pertenecer a IPsec.

Mantén el estado en cada dirección

Una asociación de seguridad, o SA, define una dirección del tráfico protegido. Contiene algoritmos, claves, modo, extremos, estado de secuencia, estado de la ventana contra repeticiones y un tiempo de vida. Un índice de parámetros de seguridad, o SPI, de 32 bits ayuda al receptor a seleccionar la SA adecuada. Es un identificador, no una clave de cifrado, y puede viajar abiertamente en la cabecera ESP.

El tráfico en ambos sentidos necesita dos SA IPsec. Una pasarela de la sede central que atiende a una sucursal y a 50 portátiles de empleados que viajan tiene 51 pares. Con un par ESP por cada par, necesita $2\times 51=102$ SA ESP, más una SA IKE por cada par para la gestión. La renovación de claves o las clases de tráfico separadas pueden añadir más SA; el recuento aquí sigue el diseño indicado de un par por cada uno.

Aunque el reenvío IP es sin conexión, este estado criptográfico se mantiene en los extremos que proporcionan la protección. Los encaminadores entre ellos no necesitan conocer las claves de sesión ni mantener la SA IPsec.

Separa la política del estado de protección activa

La base de datos de políticas de seguridad (SPD) busca coincidencias con selectores de tráfico como direcciones, protocolos y puertos. Su decisión es proteger el tráfico seleccionado, omitir la protección o descartarlo. La base de datos de asociaciones de seguridad (SAD) almacena los parámetros y el estado cambiante de las SA establecidas. Un receptor utiliza el SPI del paquete y el contexto pertinente para encontrar ese estado.

La SPD responde «¿Qué debe ocurrir con este tráfico?». La SAD responde «¿Qué claves y contadores establecidos aplican esa protección?». Una política VPN puede proteger las subredes de una oficina y permitir que otro destino evite la protección. Tener IPsec activado no significa que cada paquete que envía un sistema terminal entre en un túnel.

Una VPN entre sitios une dos redes mediante pasarelas; una VPN de acceso remoto une el dispositivo de un usuario a una pasarela. Ambas encapsulan el tráfico para que los encaminadores ordinarios de internet puedan transportarlo entre los extremos que lo protegen.

Establece las asociaciones

IKEv2 establece claves y SA. IKE_SA_INIT intercambia propuestas de algoritmos, valores Diffie–Hellman y valores de un solo uso. Las claves resultantes protegen IKE_AUTH, donde los pares autentican sus identidades y crean el primer par de SA ESP. Con firmas o una clave precompartida, esto normalmente requiere cuatro mensajes en dos tiempos de ida y vuelta. La autenticación EAP puede añadir intercambios IKE_AUTH. Los intercambios posteriores crean más SA o sustituyen las claves que están por caducar.

IKE utiliza inicialmente el puerto UDP 500. Cuando se detecta NAT, IKE y ESP encapsulado en UDP utilizan el puerto 4500. ESP por sí mismo no tiene puertos TCP ni UDP; la encapsulación permite que las asignaciones NAT basadas en puertos lo transporten de forma fiable, incluso con varios clientes. El transporte externo cambia, mientras ESP sigue protegiendo el tráfico interno.

Envía un datagrama

El sistema terminal 10.1.0.5 envía datos a 10.2.0.9. La pasarela de la sucursal es 198.51.100.1; la sede central utiliza 203.0.113.1.

1. La SPD de la sucursal selecciona la protección mediante túnel para la subred de destino y la pasarela obtiene la SA correspondiente.
2. Trata el datagrama original completo como la carga útil interna de ESP y añade un tráiler con relleno, longitud del relleno y cabecera siguiente 4 para IPv4.
3. Cifra el datagrama interno y el tráiler y añade la cabecera ESP que contiene el SPI y el siguiente número de secuencia. La protección de integridad cubre la cabecera ESP y la carga útil protegida; un algoritmo AEAD integra el cifrado y la generación de la etiqueta.
4. Añade la cabecera IP externa, dirigida desde la pasarela de la sucursal a la de la sede central. ESP nativo utiliza el protocolo 50; el recorrido de NAT transporta ESP dentro de UDP.

Los encaminadores de internet ven las direcciones de los extremos externos. Las direcciones y los puertos internos están dentro de la carga útil cifrada.

Recibe y autentica

La sede central utiliza el SPI para seleccionar una SA, comprueba preliminarmente el número de secuencia, verifica la integridad y descifra. Actualiza el estado fiable contra repeticiones solo después de que la autenticación sea satisfactoria. Elimina la protección del túnel y reenvía el datagrama original recuperado a 10.2.0.9. La cabecera siguiente identifica la carga útil recuperada: 4 para IPv4, 41 para IPv6 o 6 para TCP en un ejemplo de ESP en modo transporte.

Permite la reordenación, pero rechaza la repetición

Una ventana contra repeticiones de 64 paquetes cuyo número autenticado más alto es 1000 abarca de 937 a 1000. El paquete 990, aún no recibido, puede llegar tarde y aceptarse. Su siguiente copia se rechaza. El paquete 930 es demasiado antiguo. Un paquete válido 1005 desplaza el intervalo de 942 a 1005. Una atacante no puede desplazar la ventana de confianza simplemente enviando un paquete no autenticado con un número grande.

Una VPN solo protege el trayecto entre sus extremos. Después de retirar el túnel, la entrega interna necesita su propia protección cuando sea necesario. La tunelización dividida envía parte del tráfico fuera de la VPN. Una VPN comercial convierte a su proveedor en otro operador de red de confianza. Las VPN basadas en TLS/DTLS y WireGuard utilizan otros protocolos para implementar túneles; «VPN» designa la organización de la red, no un protocolo de cifrado obligatorio.

Una trama Wi-Fi está disponible para los dispositivos de radio dentro del alcance. Una atacante cercana puede capturar tráfico o anunciar un punto de acceso gemelo malicioso, un punto de acceso falso que utiliza un nombre de red conocido. La seguridad inalámbrica debe autenticar el acceso y proteger las tramas, no limitarse a ocultar el nombre de la red.

Por qué falló WEP

WEP combinaba un secreto compartido de 40 o 104 bits con un IV público de 24 bits para inicializar RC4. Su comprobación CRC-32 detectaba errores, pero no era un mecanismo de autenticación con clave. El espacio de IV solo tiene $2^{24}=16777216$ posibilidades; los IV elegidos al azar alcanzan una probabilidad de repetición de aproximadamente el 50 % después de unas 4823 tramas.

Un IV repetido con la misma clave repite el flujo de clave. Aplicar XOR a dos textos cifrados revela entonces el XOR de los textos en claro. La estructura lineal de CRC-32 también permite a una atacante modificar bits y ajustar la comprobación de errores. La débil planificación de claves de RC4 permitió recuperar la clave a partir de tramas capturadas. Estos fallos implican la reutilización de valores de un solo uso, la integridad sin autenticar y la construcción del cifrado; simplemente elegir un nombre de red menos evidente no soluciona ninguno de ellos.

Sustituye la protección de las tramas

WPA2, basado en IEEE 802.11i, utiliza CCMP: cifrado AES en modo contador combinado con integridad CBC-MAC. Su número de paquete ayuda a construir valores de un solo uso únicos y a rechazar repeticiones. El anterior WPA/TKIP fue una medida de transición para hardware antiguo y está obsoleto.

La conexión pasa por el descubrimiento, la autenticación que establece una clave maestra por pares (PMK), el intercambio de cuatro pasos y la transferencia protegida. En WPA2-Personal, una frase de contraseña y un nombre de red producen una PMK de 256 bits mediante PBKDF2 con 4096 iteraciones de HMAC-SHA1. Todas las personas que utilizan esa frase de contraseña y ese SSID derivan la misma PMK. La autenticación aún no ha proporcionado una clave de tráfico nueva para cada asociación.

Sigue el intercambio de cuatro pasos

1. El punto de acceso envía ANonce.
2. La estación genera SNonce y deriva la PTK a partir de la PMK, ambos valores de un solo uso y ambas direcciones MAC. Envía SNonce y un código de integridad del mensaje (MIC).
3. El punto de acceso deriva la misma PTK y comprueba el MIC. Proporciona la clave de tráfico de grupo (GTK) en un mensaje protegido.
4. La estación confirma la recepción y la instalación.

La PMK no se envía en el intercambio. Los valores de un solo uso nuevos producen claves de sesión nuevas a partir de la PMK existente. La GTK sirve para el tráfico de grupo, mientras que la clave por pares sirve para la comunicación entre esa estación y el punto de acceso.

Identifica lo que permite la contraseña

Un intercambio WPA2-Personal capturado permite probar contraseñas sin conexión: deriva una PMK y una PTK candidatas, vuelve a calcular el MIC y compáralo con el capturado. Un usuario que ya conoce la frase de contraseña de la red también puede derivar la PTK de otro usuario a partir del intercambio capturado de este. KRACK explotó la reinstalación de claves y la reutilización de valores de un solo uso en las implementaciones; los parches corrigen ese defecto.

WPA2-Enterprise utiliza 802.1X. La estación es el suplicante; el punto de acceso es el autenticador y retransmite EAP a un servidor de autenticación, normalmente mediante RADIUS. EAP-TLS utiliza certificados de cliente; PEAP y EAP-TTLS transportan credenciales dentro de la protección TLS. Los usuarios obtienen material de claves individual y su acceso puede revocarse por separado. En ambos modos, la protección Wi-Fi termina en el punto de acceso; TLS puede continuar la protección hasta un servidor de aplicación.

Un enlace inalámbrico protegido necesita una forma sólida de establecer sus claves. WPA3 cambia el establecimiento de claves Wi-Fi basado en contraseña, mientras que las redes celulares parten de un secreto de abonado que poseen la SIM y la red de origen.

Mejora la Wi-Fi basada en contraseña

WPA3-Personal utiliza SAE, autenticación simultánea entre iguales, para establecer la PMK. Un intercambio SAE capturado no permite probar contraseñas sin conexión como en WPA2: cada intento requiere una interacción activa. SAE también proporciona secreto hacia adelante, por lo que conocer la contraseña más tarde no expone las sesiones pasadas registradas. El intercambio de cuatro pasos deriva después claves de tráfico a partir de la PMK.

WPA3 exige tramas de gestión protegidas (PMF), que autentican las tramas de gestión robustas, como los mensajes de desautenticación. Esto bloquea los mensajes falsificados de cierre, pero no puede impedir la interferencia radioeléctrica intencionada. WPA3-Enterprise conserva 802.1X y ofrece un modo de seguridad opcional de 192 bits que utiliza algoritmos más fuertes, como GCMP-256.

El modo de transición acepta WPA2 y WPA3 bajo un mismo nombre de red. Su compatibilidad puede exponer los dispositivos a la vía WPA2, más débil. En el funcionamiento a 6 GHz se exige WPA3 o Enhanced Open y no se permite el modo de transición WPA2; WPA3-Personal utiliza el método hash-to-element de SAE.

Enhanced Open, basado en OWE, establece cifrado sin contraseña mediante Diffie–Hellman. Impide que quienes escuchan pasivamente lean las tramas, pero no autentica el punto de acceso. Un punto de acceso gemelo malicioso puede establecer su propio enlace cifrado con el usuario.

Autentica a un abonado celular

Un secreto de larga duración $K$ reside en la USIM y en la infraestructura de autenticación de la red de origen: HSS en 4G y UDM/ARPF en 5G. Una red visitada recibe material de autenticación sin conocer ese secreto de larga duración.

En 4G AKA, la MME de la red visitada obtiene del HSS de origen un vector que contiene RAND, AUTN, XRES y material de claves. El teléfono recibe el desafío aleatorio RAND y el token de autenticación AUTN. Su USIM comprueba AUTN para autenticar la red y la frescura, y después calcula RES. La red visitada acepta al abonado cuando RES coincide con XRES. Las claves derivadas protegen la comunicación posterior.

Esto es autenticación mutua. El antiguo 2G GSM autenticaba el teléfono ante la red, pero no proporcionaba al teléfono una comprobación equivalente de la red, lo que permitía ataques mediante estaciones base falsas. La autenticación mutua sigue necesitando algoritmos seguros y una gestión correcta de las claves; el secreto de larga duración nunca necesita enviarse a la red visitada.

Oculta la identidad permanente

En 5G, la red de origen toma la decisión final de autenticación. El teléfono también puede ocultar la parte específica del abonado de su identidad permanente, SUPI, utilizando la clave pública de la red de origen para formar el SUCI. La información de encaminamiento sigue siendo legible para que la solicitud pueda llegar a la red de origen correcta.

La ocultación requiere un esquema de protección configurado. El esquema nulo deja la identidad sin protección. Un SUCI protegido reduce la exposición a dispositivos que solicitan identidades permanentes; no hace que toda la actividad radioeléctrica sea anónima. Tras el registro, los identificadores temporales reducen el uso habitual de la identidad permanente. La seguridad del acceso celular sigue sin proteger toda la ruta hasta un servidor de aplicación: TLS proporciona esa protección separada entre los extremos de la aplicación.

Un cortafuegos aplica una política entre redes o segmentos de red. Solo funciona cuando el tráfico pertinente pasa por él, y el propio cortafuegos debe resistir los intentos de comprometerlo. Un filtro sin estado toma una nueva decisión para cada paquete mediante los campos de la cabecera.

Lee una regla con precisión

Una regla puede buscar coincidencias en las direcciones IP de origen y destino, el protocolo de transporte, los puertos, los indicadores TCP, el tipo de ICMP, la interfaz y la dirección. Las reglas se evalúan en orden: decide la primera coincidencia. Una denegación predeterminada final descarta los paquetes que no coinciden con ninguna regla que los permita.

Para la red 203.0.113.0/24, considera un servidor web en 203.0.113.10:

Un SYN de 198.51.100.7:50000 al puerto 443 del servidor web coincide con la regla 1. Un SYN a su puerto 22 llega a la regla 3 y se descarta. Una respuesta desde el puerto 443 del servidor con ACK activado coincide con la regla 2. Todos los campos de una regla importan: un paquete que utiliza el puerto UDP 443 no coincide con una regla que permite TCP.

Encuentra reglas eclipsadas

Supón que una regla anterior dice «permitir TCP entrante a cualquier sistema terminal de 203.0.113.0/24 en cualquier puerto». Una regla posterior que deniega SSH a 203.0.113.10 no tiene efecto: la regla permisiva general anterior ya ha tomado la decisión. Comprueba el orden de las reglas junto con el texto de cada una. Coloca las excepciones deseadas antes de la regla general con la que, de otro modo, coincidirían.

La denegación predeterminada es útil porque añadir un servicio nuevo no hace que se pueda acceder a él sin indicarlo. Permitir por defecto tiene la consecuencia contraria: pasa todo el tráfico que no esté bloqueado explícitamente. Ninguna de las dos opciones predeterminadas corrige una tabla de reglas mal ordenada.

Reconoce el atajo de ACK

Una política puede bloquear los paquetes SYN entrantes con ACK desactivado para impedir nuevas conexiones TCP iniciadas desde fuera. Para permitir las respuestas a clientes internos, un filtro sin estado podría permitir TCP entrante desde el puerto de origen 443 cuando ACK está activado. Trudy puede preparar tanto ese puerto de origen como ese indicador. El filtro no tiene memoria que demuestre que un sistema terminal interno abrió realmente la conexión.

Un indicador TCP ACK es un campo que elige el emisor, no un certificado de que exista una sesión establecida. El filtrado con estado mejora esta decisión al consultar el historial de conexiones.

Filtra direcciones falsificadas

El filtrado de entrada puede rechazar paquetes que llegan desde internet y declaran una dirección de origen interna o una dirección privada que no debería llegar por esa vía. El filtrado de salida rechaza los paquetes salientes cuyo origen está fuera de los rangos asignados a la organización. Estas comprobaciones reducen la suplantación de rangos no permitidos; no identifican un sistema terminal individual ni impiden que una máquina suplante otra dirección interna permitida.

Los filtros sin estado inspeccionan cabeceras, no el significado de la aplicación. El puerto 443 no demuestra que el tráfico sea HTTPS ni que sea inofensivo. Una conexión permitida puede transportar contenido malicioso. Por eso el filtrado de paquetes funciona junto con pasarelas de aplicación, controles en los extremos y detección de intrusiones.

Un cortafuegos con estado añade contexto al filtrado de paquetes. Una pasarela de aplicación añade comprensión de las solicitudes de una aplicación concreta. La separación de redes limita el alcance de un servidor público comprometido.

Sigue el flujo real

Un filtro de paquetes con estado registra direcciones, puertos, protocolo y estado de conexión. Cuando un cliente interno abre una conexión permitida, el cortafuegos crea una entrada y permite los paquetes de respuesta adecuados. Una conexión entrante nueva sigue necesitando su propio permiso explícito. Las entradas caducan cuando la conexión se cierra o queda inactiva.

Supón que la tabla registra un flujo TCP establecido de 203.0.113.25:51000 a 198.51.100.80:443. Un segmento entrante que invierte ese par de direcciones y puertos puede coincidir con su estado. Un ACK de 192.0.2.66:443 a 203.0.113.30:52000 no coincide con la entrada. Su puerto de origen y su indicador ACK satisfarían una regla permisiva de respuesta sin estado, pero no demuestran que pertenezca a la conexión registrada.

UDP carece del establecimiento de conexión de TCP. Los filtros con estado aproximan una conversación mediante el seguimiento de pares de direcciones y puertos utilizados recientemente, con un tiempo de espera máximo. Una consulta DNS a un servidor elegido abre una oportunidad limitada para la respuesta correspondiente, no un permiso para cada paquete que afirma ser DNS.

Inspecciona la solicitud de aplicación

Una pasarela de aplicación, o proxy, recibe y procesa tráfico de aplicación en nombre de los usuarios. Un proxy web puede autenticar a un usuario y comprobar una dirección solicitada o el contenido según la política. Para hacer obligatorio ese trayecto, el filtro de paquetes debe impedir que los clientes abran conexiones directas que eviten el proxy.

Un proxy tiene lógica específica del protocolo, costes de procesamiento y posibles cuellos de botella. Los clientes pueden necesitar configuración, o la red puede interceptar el tráfico de forma transparente. El contenido cifrado permanece oculto para un proxy a menos que este termine la conexión TLS y cree otra hacia el destino. Esto cambia el conjunto de extremos a los que se confía el texto en claro.

Aísla los servidores públicos

Una DMZ es un segmento separado para servicios públicos. El cortafuegos permite tráfico seleccionado de internet a la DMZ, a la vez que restringe el acceso de la DMZ a la red interna. Si un servidor web se ve comprometido, la atacante no obtiene automáticamente acceso interno sin restricciones. Toda conexión necesaria de la DMZ a la red interna debe tener una política específica.

Esto es defensa en profundidad: varios controles reducen diferentes vías de fallo. Un cortafuegos del sistema terminal sigue siendo importante cuando un portátil infectado ya está dentro o cuando otro enlace evita el perímetro. Un diseño de confianza cero no concede acceso simplemente porque un dispositivo esté en una subred interna; autentica y autoriza las solicitudes. La ubicación en la red puede servir para definir la política, pero no puede sustituir las comprobaciones de identidad y permisos.

Un cortafuegos puede permitir una conexión que transporte un ataque. La detección de intrusiones examina el contenido y los patrones del tráfico en busca de señales de uso indebido; la prevención de intrusiones puede actuar directamente sobre lo que encuentra.

Elige la detección y la ubicación

Un IDS suele observar una copia del tráfico y generar alertas. Un IPS se sitúa en el trayecto y puede descartar tráfico sospechoso. Situarlo en el trayecto permite el bloqueo inmediato, pero añade retardo de procesamiento y corre el riesgo de interrumpir el uso legítimo cuando una detección es errónea.

Snort y Suricata son ejemplos de sistemas capaces de usar firmas. Una regla podría reconocer la ruta de solicitud ../../etc/passwd, más de 20 conexiones nuevas al puerto SSH 22 desde un mismo origen en un minuto, o SYN a cientos de puertos. Estos patrones indican un comportamiento sospechoso; una coincidencia por sí sola no demuestra que una intrusión haya tenido éxito.

Un detector de anomalías podría señalar un cambio grande en la tasa de tráfico o en la combinación de protocolos. Una nueva tarea legítima de copia de seguridad también puede parecer inusual. Un falso positivo es una alerta sobre actividad inofensiva; un falso negativo es un ataque que el detector no detecta. Cambiar un umbral de sensibilidad suele intercambiar un tipo de error por el otro.

Calcula qué significa una alerta

Considera 1 000 000 de conexiones inofensivas y 10 ataques al día. Un detector identifica el 99 % de los ataques y genera falsas alertas en el 0,1 % de las conexiones inofensivas.

1. Alertas verdaderas esperadas: $10\times \mathrm{0,99}=\mathrm{9,9}$.
2. Alertas falsas esperadas: $1000000\times \mathrm{0,001}=1000$.
3. Fracción verdadera esperada entre las alertas: $\mathrm{9,9}\mathrm{/}(\mathrm{9,9}+1000)\approx \mathrm{0,0098}$, o aproximadamente el 1 %.

Estas son cantidades esperadas a lo largo de varios días, por lo que 9,9 no tiene por qué ser un resultado diario entero. La tasa de detección del 99 % es la proporción de ataques detectados, no la probabilidad de que una alerta sea un ataque. La baja frecuencia de los ataques y la enorme población de conexiones inofensivas explican la diferencia: este es el problema de la tasa base.

Coloca sensores donde puedan ver

Los sensores situados justo dentro del cortafuegos observan el tráfico que lo ha atravesado. Los sensores de la DMZ observan el tráfico de los servicios públicos; los sensores internos pueden revelar ataques que nunca cruzan el perímetro. Un sensor debe poder seguir el ritmo del tráfico que recibe. También debe reensamblar fragmentos y segmentos TCP de forma coherente con el objetivo; de lo contrario, un ataque dividido entre paquetes puede eludir una comprobación de patrones.

TLS e IPsec ocultan las cargas útiles cifradas a un sensor de red que no tenga acceso al descifrado. Las direcciones, los puertos, los tiempos, las longitudes y los campos no cifrados del intercambio de establecimiento aún pueden ayudar. La inspección de la carga útil puede realizarse en un extremo donde se descifra, pero una copia ordinaria del flujo cifrado no proporciona ese texto en claro.

Un sistema señuelo es un sistema de engaño sin usuarios ordinarios previstos. Por tanto, el contacto es sospechoso y puede revelar técnicas de escaneo o ataque con menos ruido de fondo. Los clientes mal configurados o el tráfico automatizado inofensivo también pueden contactar con él, por lo que un señuelo no hace que todas las alertas sean concluyentes.