Muestra las diferencias entre dos versiones de la página.
| Ambos lados, revisión anteriorRevisión previaPróxima revisión | Revisión previa | ||
| master_cs:secom:tm3_v2 [2026/05/27 23:06] – thejuanvisu | master_cs:secom:tm3_v2 [2026/05/28 00:22] (actual) – thejuanvisu | ||
|---|---|---|---|
| Línea 82: | Línea 82: | ||
| * Comentario | * Comentario | ||
| + | ===== Procesamiento de paquetes de salida ===== | ||
| + | * Coinciden los campos de selector del paquete saliente con las políticas de salida en el SPD: | ||
| + | * Si no hay política definida para el paquete, se descarta | ||
| + | * El Procesado IPSec no es requerido por la política | ||
| + | * El Procesado IPSec es necesario por la política. | ||
| + | * En el último caso anterior, se localiza la primera entrada para el paquete, si no hay SA o gurpo SA especificado en la entrada se usa IKE para establecer el SA y el nuevo SA se almacena en el SAD. | ||
| + | * Cada SA en el SAD está especificado por: | ||
| + | * Modo de protocolo de IPSec: Tunnel o transporte, AH o ESP | ||
| + | * Algoritmos y parámetros | ||
| + | * Algoritmos de autenticación AH | ||
| + | * Algoritmo de cifrado ESP | ||
| + | * Algoritmo de autenticación ESP | ||
| + | * Tiempo de vida del SA | ||
| + | * Parámetros Anti-Replay | ||
| + | * Si hay una SA o grupo de SA especificado en la entrada: | ||
| + | * Se va a la entrada correspondiente en el SAD y se realiza el procesado IPSec especificado. | ||
| + | ===== Procesamiento de paquetes de entradda ===== | ||
| + | * Si el paquete de entradda no contiene ninguna cabecera IPSec, la capa IPSec revisa su SPD para determinar como procesar el paquete. | ||
| + | * Si el paquete de entraada contiene una cabecera IPSec: | ||
| + | * Se usan la IP, el protocolo IPSec y el SPI del destino para reivsar el SA en el SAD, si el paquete no se encuentra se hace un DROP. | ||
| + | * Se realiza el procesado IPSec de acuerdo al SA del paquete | ||
| + | * Se busca una política de entrada en el SPD que que coincida con el paquete | ||
| + | * Se entrega el paquete a la capa de transporte o se le hace forward. | ||
| + | |||
| + | ===== Combinando Security Associations ===== | ||
| + | * Las SA pueden implementar tanto AH como ESP. Para implementar ambos se deben combinar las SA: | ||
| + | * Formar un grupo de Security Association | ||
| + | * Puede finalizar en el mismo extremo o en uno diferente | ||
| + | * Combinado por la adjacencia de transporte o la iteración de tunelado | ||
| + | * Para combianar autenticación y cifrado: | ||
| + | * ESP con autenticación, | ||
| + | |||
| + | ===== Internet Key Exchange (IKE) ===== | ||
| + | Busca crear una asociaciación de seguridad entre 2 dispositivos IPSec incluyento el establecimiento dinámico de claves compartidas temporales para cifrado y autenticación, | ||
| + | * Fase 1: Establece la asociación de seguridad (IKE-SA) para la segunda fase, siempre autenticado por Diffie-Hellman | ||
| + | * Fase 2: Usa IKE-SA para crear una Security association (child-SA) para usar con AH y ESP. Usa claves derivadas en la primera fase para evitar intercambio Diffie-Hellman. | ||
| + | |||
| + | ==== IKEv2 ==== | ||
| + | Intergra IKEv1 y características ISAKMP, además de otras extensiones | ||
| + | * Hereda todos los tipos de la payload ISAKMP añadiendo algunos más: | ||
| + | * Security Association | ||
| + | * Key Exchange | ||
| + | * Identification | ||
| + | * Certificate | ||
| + | * Certificate request | ||
| + | * Authentication | ||
| + | * Nonce | ||
| + | * Notify | ||
| + | * Delete | ||
| + | * Vendor ID | ||
| + | * Traffic Selector | ||
| + | * Encrypted | ||
| + | * Configuration | ||
| + | * Extensible Autehntication | ||
| + | * La payload tiene una estructura jerárquica compleja | ||
| + | * Puede contener múltiples porposiciones conmúltiples protocolos y múltiples transforms | ||
| + | |||
| + | ==== Intercambios del protocolo IKEv2 ==== | ||
| + | * IKE_SA_INIT: | ||
| + | * Proposciones en la payload SA: | ||
| + | * Grupo Diffie-Hellman | ||
| + | * Función pseudoaleatoria | ||
| + | * Algoritmo de cifrado | ||
| + | * Algoritmo de integridad | ||
| + | * Determinación de material base criptográfico para derivar las claves | ||
| + | * IKE_SA es bidireccional | ||
| + | * IKE_AUTH: | ||
| + | * HDR no está cifrado pero tiene protección de integridad | ||
| + | * Las otras payload estan escondidas | ||
| + | * Autenticación mutua en los extremos del túnel. | ||
| + | * Clave compartida | ||
| + | * Firma Digital (PKI) | ||
| + | * EAP | ||
| + | * Negociación y establecimiento del primer child-SA para transmisión de datos. | ||
| + | * CREATE_CHILD_SA | ||
| + | * Para establecer otras SA y componer un grupo de SA | ||
| + | * Para regenerar la clave de IKE_SA o cualquier child-SA que haya expirado | ||
| + | * Cuando se renueva la clave, un nuevo intercambio Diffie-hellman toma lugar | ||
| + | * INFORMATIONAL: | ||
| + | * Notification | ||
| + | * Eliminación de SA | ||
| + | * Configuración de intercambio de Payload | ||
| + | * Dead Peer Detection | ||
| + | * NAT keepalive | ||
| + | |||
| + | ===== Ataque Anti Dos Resource-Clogging ===== | ||
| + | Si el responder abre un state para cada intento de conexión, el atacante puede iniciar miles de conexiones con IPs falsas. Las Cookies aseguran que el responder es stateles hasta que el iniciador produce al menos 2 mensajes | ||
| + | * El state del responder se almacena en una cookie y se envia al iniciador | ||
| + | * Una vez el iniciador responde, la cookie se regenera y se compara con la cookie devuelta por el iniciador | ||
| + | * Cuesta 2 mesajes extra en cada ejecución | ||
| + | |||
| + | ===== IPSec AUTH exchange ===== | ||
| + | Para evitar ataques MitM de intercambios Diffie-hellman, | ||
| + | * El mecanismo es asimétrico, | ||
| + | * Peer Authorization Database (PAD): Enlaza SPD con IKE. Define una lista de peer IPSec autorizados, | ||
| + | * La autenticación de clave compartida es susceptible a ataques de fuerza bruta: Si el atacante spoofea el responder original en la fase IKE_SA_INT, puede obtener toda la información, | ||
| + | |||
| + | ===== IPSec y NAT ===== | ||
| + | * El Authentication Header (AH) y NAT son incompatibles. ESP en transporte, al principio, también. | ||
| + | * Cambiando ladirección ip de origen requiere el cambio del checksum del encabecado TCP/UDP, el cual o esta cifrado o su modificación puede afectar al valor de revisión de integridad. | ||
| + | * Para Tunnel Mode ESP un dispositivo Nat especial puede usar el SPI de los paquetes ESP para diferenciar flijos IPSec localizados tras el. | ||
| + | * Para correr IPSec con un NAT normal, se usa NAT Transversal, | ||
| + | * IKE tiene un mencaniso de detección de NAT intriseca que realiza cambios del puerto 500 al 4500 | ||