Una de las primeras cosas que uno se da cuenta cuando se trata de configurar IPsec es que hay tantos botones y opciones: incluso un par de totalmente standard de las implementaciones de los deportes un desconcertante número de maneras de impedir una conexión exitosa.
Es sólo un conjunto increíblemente complejo de protocolos.
Una de las causas de la complejidad es que IPsec proporciona mecanismo no, la política: en lugar de definir tal y como algoritmo de cifrado o una función de autenticación ciertas, proporciona un marco que permite una implementación para proporcionar casi cualquier cosa que ambos extremos están de acuerdo.
En esta sección, vamos a tocar algunos de los elementos de la forma de un glosario, con una comparación y contraste para mostrar qué términos se refieren a que los demás términos. Esto no es ni remotamente completa.
AH en comparación con ESP
"Authentication Header" (AH) y "Carga de seguridad encapsuladora" (ESP) son los dos principales a nivel de cable protocolos utilizados por IPsec, y autenticarse (AH) y cifrar + autenticar (ESP) los datos que fluyen en la conexión. Se suelen utilizar de forma independiente, aunque es posible (pero raro) a utilizar los dos juntos.
Túnel de modo versus modo de transporte
Modo de transporte proporciona una conexión segura entre dos puntos finales, ya que encapsula la carga útil IP, mientras que el modo de túnel encapsula todo el paquete IP para proporcionar un virtual "salto seguro" entre dos pasarelas. Esta última se utiliza para formar una VPN tradicional, donde el túnel por lo general crea un túnel seguro a través de un Internet de confianza.
MD5 contra SHA-1 en comparación con DES en comparación con 3DES contra AES contra, bla, bla, bla,
Configuración de una conexión IPsec implica todo tipo de opciones de cifrado, pero esto es una simplificación sustancial por el hecho de que cualquier conexión determinada puede utilizar como máximo dos o tres (rara vez) a la vez.
Autenticación calcula un valor de comprobación de integridad (ICV) sobre el contenido del paquete, y por lo general es construida en la cima de un hash criptográfico, como MD5 o SHA-1. Se incorpora una clave secreta conocida por ambos extremos, lo que permite al receptor calcular el ICV de la misma manera. Si el destinatario recibe el mismo valor, el remitente tiene efectivamente se autenticado (basándose en la propiedad que hashes criptográficos prácticamente no se pueden invertir). AH proporciona autenticación de siempre, y lo hace ESP opcional.
Cifrado utiliza una clave secreta para cifrar los datos antes de la transmisión, y esto oculta el contenido real del paquete de espías. Hay bastantes opciones para los algoritmos de aquí, con DES, 3DES, Blowfish y AES que son comunes. Otros son posibles también.
IKE en comparación con claves manuales
Desde ambos lados de la conversación que saber los valores secreta que se utiliza en hash o cifrado, está la cuestión de hasta qué punto estos datos son intercambiados. Claves manuales requieren la introducción manual de los valores secretos en ambos extremos, probablemente transmitida por un mecanismo fuera de banda, y IKE (Internet Key Exchange) es un sofisticado mecanismo para hacer esto en línea.
Modo principal en comparación con el modo agresivo
Estos modos de control de una compensación de eficiencia versus la seguridad durante el intercambio inicial de claves IKE. "Modo principal" requiere de seis paquetes de un lado a otro, sino que ofrece una completa seguridad durante el establecimiento de una conexión IPsec, mientras que el modo agresivo utiliza la mitad de las bolsas de garantizar la seguridad un poco menos ya que cierta información se transmite en texto plano.
Sin duda, se enfrentará a más opciones como desenvolver IPsec.
Los datagramas IP
Ya que estamos buscando en IPsec de abajo hacia arriba, primero tenemos que tomar un pequeño desvío para visitar la cabecera IP en sí, que lleva todo el tráfico que va a estar considerando. Tenga en cuenta que no estamos tratando de ofrecer una cobertura completa de la cabecera IP - existen otros recursos excelentes para que (el mejor es TCP / IP Illustrated, vol 1).
ver
Esta es la versión del protocolo, que ahora es 4 = IPv4
hlen
Longitud de la cabecera IP, como un número de cuatro bits de palabras de 32 bits que van de 0 .. 15. Un estándar de la cabecera IPv4 es siempre 20 bytes de longitud (5 palabras), y opciones de IP - si alguna - se indican con un mayor campo de hlen hasta un máximo de 60 bytes. Esta longitud de la cabecera no incluye el tamaño de los encabezados de carga u otros que le siguen.
TOS
Tipo de Servicio
Este campo es una máscara que le da algunas pistas sobre el tipo de servicio deben recibir este datagrama: optimizar el ancho de banda? Latencia? De bajo costo? Fiabilidad?
pkt len
La longitud del paquete en bytes, en general, hasta el 65535. Este recuento incluye los bytes de la cabecera, por lo que esto sugiere que el tamaño máximo de cualquier carga útil es de al menos 20 bytes menos. La gran mayoría de los datagramas IP son mucho más pequeños.
Identificación
El campo ID se utiliza para asociar los paquetes relacionados que han sido fragmentadas (paquetes grandes dividida en otras más pequeñas).
FLGS
Estas son pequeñas banderas que controlan principalmente la fragmentación: una marca el paquete como no elegible para la fragmentación, y el otro dice que más fragmentos de seguir.
fragmentos de compensación
Cuando un paquete es fragmentado, esto demuestra que en la general "virtual" paquete pertenece este fragmento.
TTL
Este es el tiempo de vida, y se reduce en cada router que pasa este paquete. Cuando el valor llega a cero, sugiere algún tipo de bucle de enrutamiento, por lo que es descartado para evitar que correr alrededor de la Internet para siempre.
proto
Esto representa el protocolo realizado dentro de este paquete, y que va a ser fundamental para la mayor parte de nuestras discusiones. Aunque el propio datagrama IP, que siempre encierra un protocolo filial (TCP, UDP, ICMP, etc - vea la tabla de abajo) en su interior. Se puede pensar en como dar el tipo de cabecera que sigue.
cabecera cksum
Esto es una suma de comprobación de la cabecera IP completo, y está diseñado para detectar errores en el tránsito. Esto no es una suma de comprobación criptográfica, y no cubrir ninguna parte de los datagramas que siguen a la cabecera IP.
src dirección IP
La de 32 bits dirección IP de origen, que el destinatario utiliza para responder a este datagrama. En términos generales, es posible suplantar estas direcciones (es decir, mentir acerca de que el datagrama está viniendo).
dst dirección IP
La de 32 bits dirección IP de destino, que es donde el paquete está destinado a llegar.
Opciones IP
Estos son una parte opcional de la cabecera IP que contiene información específica de la aplicación, a pesar de que no se utilizan habitualmente para el tráfico normal. La presencia de las opciones de IP se indica mediante un hlen superior a 5, y (si existe) se incluyen en la cabecera de comprobación.
Carga útil
Cada tipo de protocolo implica su propio formato para lo que sigue a la cabecera IP y TCP hemos utilizado aquí sólo para
mostrar un ejemplo.
Estos códigos de proto se definen por IANA - Internet Assigned Numbers Authority - y hay muchos más que nunca sería utilizado por cualquier instalación única, pero la mayoría hará sonar una campana con un técnico de la red inteligente. Estos tipos representativos se han tomado de la lista de protocolos de IANA sitio web:
| Protocol code | Protocol Description |
|---|---|
| 1 | ICMP — Internet Control Message Protocol |
| 2 | IGMP — Internet Group Management Protocol |
| 4 | IP within IP (a kind of encapsulation) |
| 6 | TCP — Transmission Control Protocol |
| 17 | UDP — User Datagram Protocol |
| 41 | IPv6 — next-generation TCP/IP |
| 47 | GRE — Generic Router Encapsulation (used by PPTP) |
| 50 | IPsec: ESP — Encapsulating Security Payload |
| 51 | IPsec: AH — Authentication Header |
Vamos a estudiar los dos últimos en detalle.
AH: Autenticación Sólo
AH se utiliza para autenticar - pero no cifrar - el tráfico IP, y esto sirve para agudos de asegurar que realmente estamos hablando de lo que pensamos que son, la detección de alteración de los datos en tránsito, y (opcionalmente) para protegerse contra la repetición por los atacantes, que la captura de datos desde el cable y el intento de volver a inyectar esos datos en el cable en una fecha posterior.
La autenticación se realiza mediante el cálculo de un hash criptográfico basado en código de autenticación de mensajes a través de casi todos los campos del paquete IP (con exclusión de los que podrían ser modificados en tránsito, como el TTL o la cabecera de comprobación), y almacena esta en un AH agregados recientemente cabecera y se envía al otro extremo.
Esta cabecera AH contiene sólo cinco campos de interés, y se inyecta entre el encabezado IP original y la carga útil. Vamos a tocar en cada uno de los campos de aquí, aunque su utilidad no puede ser completamente evidente hasta que veamos cómo se utilizan en el cuadro más grande.
próximo Informe sobre Desarrollo Humano
Esto identifica el tipo de protocolo de la carga útil siguiente, y es el tipo de paquete original se encapsula: esta es la forma en la cabecera IPsec (s) están unidos entre sí.
AH len
Esto define la longitud, en palabras de 32 bits, de la cabecera AH todo, menos dos palabras (el "menos dos palabras" fuentes de la condición de formato de las cabeceras IPv6 RFC 1883 la extensión, de los cuales es un AH).
Reservado
Este campo está reservado para uso futuro y debe ser cero.
Índice de parámetros de seguridad
Se trata de un opaco de 32 bits de identificación que ayuda al oyente seleccionar cuál de las conversaciones en curso, posiblemente, muchos se aplica este paquete. Cada conexión de AH-protegidos implica un algoritmo de hash (MD5, SHA-1, etc), algún tipo de información secreta, y una serie de otros parámetros. El SPI puede ser considerado como un índice en una tabla de estos valores, lo que permite fácil asociación de paquetes con el parámetro.
Número de secuencia
Este es un identificador que se incrementa que se utiliza para ayudar en la protección antireplay. Este valor está incluido en los datos de autenticación, por lo que las modificaciones (intencional o no) son detectados.
Los datos de autenticación
Este es el valor de comprobación de integridad calculado sobre el paquete completo - incluyendo la mayoría de las cabeceras - El receptor recalcula el mismo hash; valores que no coinciden marca el paquete como sea dañado durante el transporte, o no tener la clave secreta adecuada. Éstas se descartan.
El modo de transporte
El modo más fácil de comprender es el modo de transporte, que se utiliza para proteger a una conversación de extremo a extremo entre dos ejércitos. Esta protección es la autenticación o el cifrado (o ambos), pero no es un protocolo de túnel. No tiene nada que ver con una VPN tradicional: es simplemente una conexión IP segura.
AH en modo transporte, el paquete IP se ha modificado ligeramente para incluir la nueva cabecera AH entre el encabezado IP y la carga de protocolo (TCP, UDP, etc), y hay un rumor de que el código de protocolo de las distintas cabeceras enlaces juntos .
Este intercambio protocolo es necesario para permitir que el paquete IP original para ser reconstituido en el otro extremo: después de las cabeceras IPsec se han validado a la recepción, que está despojado, y el tipo de protocolo original (TCP, UDP, etc) se almacena de vuelta en la cabecera IP. Vamos a ver esta cadena de campos de cabecera al lado una y otra vez a medida que examinamos IPsec.
Cuando el paquete llega a su destino y pasa a la comprobación de autenticación, la cabecera AH se elimina y el proto = AH campo en el encabezado IP es reemplazado con el guarda "Protocolo Siguiente". Esto coloca a la IP de nuevo datagrama a su estado original, y puede ser entregado en el proceso de espera.
Modo de túnel
Modo túnel forma la funcionalidad de VPN más familiar, donde todo los paquetes IP son encapsulados dentro de otro y entregada en el destino.
Al igual que el modo de transporte, el paquete está sellado con un valor de comprobación de integridad para autenticar al remitente y para evitar la modificación en el tránsito. Pero a diferencia del modo de transporte, que encapsula la cabecera IP completo, así como la carga útil, y esto permite que las direcciones de origen y de destino para ser diferentes de los del paquete que abarca: Esto permite la formación de un túnel.
Cuando un paquete de túnel de modo que llegue a su destino, que pasa a través de la comprobación de autenticación como cualquier paquete AH-tipo, y los que pasan la comprobación de que su IP completa y cabeceras AH quitó. Esto efectivamente reconstruye el datagrama IP original, que luego se inyecta en el proceso de enrutamiento de costumbre.
La mayoría de las implementaciones de tratar el punto final del túnel, como un modo de interfaz de red virtual - como una interfaz Ethernet o localhost - y el tráfico de entrada o salida está sujeta a todas las decisiones ordinarias de enrutamiento.
El paquete reconstituido puede ser entregado a la máquina local o no se colocan en otra parte (de acuerdo con la dirección IP de destino se encuentran en el paquete encapsulado), aunque en cualquier caso ya no está sujeto a la protección de IPsec. En este punto, es sólo un datagrama IP normal.
Aunque el modo de transporte se utiliza exclusivamente para asegurar una conexión de extremo a extremo entre dos equipos, el modo de túnel es más habitual entre gateways (routers, firewalls, dispositivos VPN o independiente) para proporcionar una red privada virtual (VPN).
Transporte o túnel?
Curiosamente, no hay explícitas campo "Mode" en IPsec: lo que distingue el modo de transporte desde el modo de túnel es el campo de la cabecera al lado de la cabecera AH.
Cuando el valor de la siguiente cabecera es IP, significa que este paquete encapsula un datagrama IP completo (incluyendo la fuente independiente y direcciones IP de destino que permiten enrutamiento separada después de la encapsulación). Este es el modo de túnel.
Cualquier otro valor (TCP, UDP, ICMP, etc) significa que es el modo de transporte y asegurar una conexión punto final a punto final.
El nivel más alto de los datagramas IP está estructurado de la misma manera, independientemente de la modalidad, y los routers intermedios tratar a todos los sabores de IPsec / AH tráfico de forma idéntica, sin más inspección.
Vamos a observar que una gran cantidad - en lugar de una puerta de entrada - es necesaria para apoyar los modos de transporte y túnel, pero al crear una conexión host-a-host, que parece un poco superfluo usar el modo de túnel.
Además, una pasarela (router, firewall, etc) sólo es necesaria para apoyar el modo de túnel, aunque compatible con el modo de transporte sólo es útil cuando se crea un punto final a la misma puerta de entrada, como en el caso de las funciones de gestión de red.
Los algoritmos de autenticación
AH lleva a un valor de comprobación de integridad en la parte de autenticación de los datos de la cabecera, y es por lo general (pero no siempre), construido en la parte superior de la norma algoritmos criptográficos hash como MD5 o SHA-1.
En lugar de utilizar una suma de comprobación, que habría no proporcionan seguridad real frente a la manipulación intencional, que utiliza un algoritmo hash Message Authentication Code (HMAC), que incorpora un valor secreto, mientras que la creación del ICV. A pesar de que un atacante puede fácilmente volver a calcular un valor hash, sin que el valor secreto que no será capaz de recrear el ICV adecuada.
HMAC se describe en el RFC 2104, y este ejemplo muestra cómo los datos del mensaje y el secreto de contribuir a la Integrity Check Value final:
Vamos a señalar que IPsec / AH no define cuál es la función de autenticación debe ser, en su lugar proporciona un marco que permite a cualquier aplicación razonable acordado por ambos extremos para su uso. Es posible utilizar otras funciones de autenticación, como una firma digital o una función de cifrado, siempre y cuando ambos lados que ofrecen para ello.
AH y NAT - no va a suceder
Aunque AH proporciona una protección muy fuerte de los contenidos de un paquete, ya que abarca todo lo que puede ser, posiblemente, consideran inmutables, esta protección tiene un costo: AH es incompatible con NAT (Network Address Translation).
NAT se utiliza para asignar un rango de direcciones privadas (por ejemplo, 192.168.1.x) y de un conjunto (normalmente) más pequeño de la dirección pública, reduciendo así la demanda de espacio de enrutamiento, IP pública. En este proceso, la cabecera IP se modificó sobre la marcha por el dispositivo NAT para cambiar la fuente y / o dirección IP de destino.
Cuando la fuente adecuada o la dirección IP de cabecera se cambia, se fuerza una actualización de la cabecera de comprobación. Esto tiene que ser hecho en cualquier caso, ya que el dispositivo NAT normalmente sirve como un "salto" en la ruta del origen al destino, y esto requiere que el decremento de la TTL (Time To Live) de campo.
Debido a que el jefe del equipo y los campos de cabecera de control siempre son modificados durante el vuelo, AH sabe que los excluye de la cobertura, pero esto no se aplica a las direcciones IP. Estos se incluyen en el valor de comprobación de integridad, así como cualquier modificación hará que la comprobación de ésta fallara al verificada por el receptor. Debido a que el ICV incorpora una clave secreta que es desconocido por las partes intermedias, el router NAT no es capaz de volver a calcular el ICV.
Esta misma dificultad se aplica también a PAT (Port Address Translation), que mapea varias direcciones IP privadas en una sola dirección IP externa. No sólo son las direcciones IP modificados sobre la marcha, pero el TCP y UDP números de puerto (ya veces incluso a la carga útil). Esto requiere mucha más inteligencia por parte del dispositivo NAT, y las modificaciones más extensas de todo este período de datagramas.
Por esta razón, AH - ya sea en túnel o en el modo de transporte - es absolutamente incompatible con NAT, y sólo puede emplearse cuando el origen y las redes de destino son accesibles sin necesidad de traducción.
Vamos a señalar que esta dificultad particular no se aplica a ESP, como la autenticación y el cifrado no incorporan la cabecera IP es modificado por NAT. Sin embargo, NAT impone algunos desafíos, incluso en ESP.
NAT traduce las direcciones IP en el momento - pero tiene que realizar un seguimiento de las conexiones que están fluyendo a través de ella para que las respuestas pueden ser correctamente asociados con las fuentes. Cuando se utiliza TCP o UDP, esto se hace habitualmente con números de puerto (ya sea escribir o dibujar sobre la marcha o no), pero no proporciona IPsec gancho para permitir esto.
Al principio, uno podría sospechar de la SPI, que parece ser un identificador útil, pero debido a que el SPI es diferente en ambas direcciones, el dispositivo NAT no tiene forma de asociar el paquete de regreso con la conexión de salida.
Frente a esto requiere instalaciones especiales para NAT transversal, algo no cubierto en este documento.
ESP - Carga de seguridad encapsuladora
Agrega el cifrado ESP hace un poco más complicado debido a la encapsulación rodea a la carga en lugar de lo que precede al igual que con AH: ESP incluye cabecera y los campos de remolque para apoyar el cifrado y autenticación opcional. También ofrece los modos de transporte del túnel y que se utilizan en por ahora los medios conocidos.
Las RFC IPsec no insistir en los algoritmos de cifrado en particular, pero nos encontramos con DES, Triple DES, AES, Blowfish y de uso común para proteger la carga de miradas indiscretas. El algoritmo utilizado para una conexión en particular es especificada por la Asociación de Seguridad (cubierta en una sección posterior), y el SA no sólo incluye el algoritmo, sino que se utiliza la clave.
A diferencia de AH, que ofrece una pequeña cabecera antes de la carga útil, ESP rodea la carga útil es la protección. El Índice de parámetros de seguridad y número de secuencia de servir al mismo propósito que en AH, pero nos encontramos con el acolchado, la siguiente cabecera, y los datos de autenticación opcional al final, en el trailer ESP.
Es posible utilizar sin ningún tipo de cifrado ESP real (para usar un algoritmo NULL), que, sin embargo las estructuras del paquete de la misma manera. Esto no proporciona confidencialidad, y que sólo tiene sentido si se combina con la autenticación ESP. No tiene sentido usar ESP sin que ninguna de cifrado o autenticación (a menos que uno es simplemente hacer las pruebas de protocolo).
El relleno se proporciona para permitir el cifrado de bloques orientados a sala de algoritmos para los múltiplos de su bloque, y la longitud del relleno que se proporciona en la libreta de campo len. El siguiente campo de HDR da el tipo (IP, TCP, UDP, etc) de la carga de la forma habitual, aunque puede ser considerado como apuntando "hacia atrás" en el paquete y no hacia delante, como hemos visto en el AH.
Además del cifrado, ESP Opcionalmente, también puede proporcionar servicios de autenticación, con el HMAC mismo que se encuentra en AH. A diferencia de AH, sin embargo, esta autenticación es sólo para la cabecera ESP y la carga útil encriptada: no cubre el paquete IP completo. Sorprendentemente, esto no pone en debilitar la seguridad de la autenticación, pero sí ofrece algunos beneficios importantes.
Cuando un forastero examina un paquete IP que contiene los datos de ESP, que es esencialmente imposible hacer conjeturas sobre lo que es verdadero en el interior a excepción de los datos habituales en la cabecera IP (en particular, la fuente y las direcciones IP de destino). El atacante luego se sabe que es ESP datos - que también está en la cabecera -, sino el tipo de la carga útil se cifra con la carga útil.
Incluso la presencia o ausencia de datos de autenticación no se puede determinar observando el mismo paquete (esta determinación se realiza mediante el índice de parámetros de seguridad para hacer referencia al conjunto de parámetros previamente compartida y los algoritmos para esta conexión).
Sin embargo, cabe señalar que a veces la dotación proporciona indicios de que la carga no lo hace. Con más gente que envía VoIP dentro de ESP a través de Internet, el taggings QoS están en la cabecera exterior y es bastante obvio lo que el tráfico es de señalización VoIP (IP prioridad 3) y lo que es el tráfico RTP (IP precedencia 5). No es una cosa segura, pero puede ser suficiente de una pista a la materia en algunas circunstancias.
ESP en modo transporte
Al igual que con AH, el modo de transporte encapsula el datagrama sólo de carga útil y ha sido diseñado exclusivamente para las comunicaciones de host a host. La cabecera IP original se queda en su lugar (a excepción de la baraja campo Protocol), y significa que - entre otras cosas - la fuente y las direcciones IP de destino no se modifican.
ESP en modo túnel
Nuestro aspecto final del ESP es autónomo en el modo de túnel, que resume todo un datagrama IP dentro de la cáscara cifrado:
Proporciona una conexión en modo túnel encriptado está muy cerca de la VPN tradicional que viene a la mente cuando la mayoría de nosotros pensamos acerca de IPsec, pero tenemos que agregar la autenticación de un tipo u otro para completar el cuadro: esto está cubierto en la siguiente sección.
A diferencia de AH, donde un espectador puede decir fácilmente si el tráfico en el túnel o el modo de transporte, esta información no está disponible aquí: el hecho de que este es el modo de túnel (a través de IP de próxima =) es parte de la carga útil encriptada, y simplemente no está visible a incapaz de descifrar el paquete de una.
Poniendo todo junto: Creación de una VPN reales
Con la cobertura de la cabecera de autenticación y la carga útil de seguridad encapsuladora completa, estamos listos para activar el cifrado y autenticación para construir una VPN real.
El propósito de una red privada virtual consiste en unir dos redes de confianza a través de una red intermedia no son de confianza, como es por tendido de un cable Ethernet mucho tiempo entre los dos. Esto es comúnmente utilizado para conectar sucursales con sede de la empresa, permitiendo a todos los usuarios compartir los recursos sensibles, sin temor de la interceptación.
Claramente, una VPN segura requiere autenticación y encriptación. Sabemos que la PES es la única manera de proporcionar cifrado, pero el ESP y AH tanto puede proporcionar autenticación: ¿cuál debemos utilizar?
La solución obvia de envolver ESP dentro de AH es técnicamente posible, pero en la práctica no es utilizado debido a las limitaciones de AH con respecto a la traducción de direcciones de red. Mediante el uso de AH + ESP, este túnel no podría atravesar con éxito un dispositivo NAT.
En cambio, ESP + autenticación se utiliza en el modo de túnel para encapsular completamente el tráfico en su camino a través de una red insegura, protegidos por el cifrado y la autenticación en la misma cosa.
Tráfico protegido de esta manera, los rendimientos de casi ninguna información útil para un intruso salvo por el hecho de que los dos sitios están conectados mediante una VPN. Esta información puede ayudar a un atacante entender las relaciones de confianza, pero nada sobre el tráfico real en sí mismo se revela. Incluso el tipo de encapsulado de protocolo - TCP, UDP, ICMP o - se oculta de los forasteros.
Lo que es particularmente bueno de este modo de operación es que los anfitriones de los usuarios finales por lo general no saben nada acerca de la VPN u otras medidas de seguridad en su lugar. Desde una red privada virtual implementado por un dispositivo de puerta de enlace VPN como trata a la otra interfaz, el tráfico destinado para el otro extremo se dirige normalmente.
Este paquete en un paquete-en realidad se pueden anidar aún más los niveles de: Host A y Host B puede establecer su propia conexión autenticada (por AH), y tener esta enrutan a través de la VPN. Esto pondría un paquete AH interior encierra dentro de un paquete de autenticación ESP +.
Actualización - es importante para utilizar la autenticación, incluso si se utiliza la encriptación, ya que cifrar sólo implementaciones son objeto de un ataque eficaz como se describe en la criptografía de papel en la teoría y la práctica: El caso de la encriptación en IPsec, consulte la sección Recursos para obtener más información.
Tocar en otros asuntos
IPsec es un conjunto muy complejo de protocolos, y este Consejo Técnico no puede dar la debida justicia a más de una pequeña parte de ella. En esta sección vamos a mencionar unas pocas áreas que piden una mayor cobertura.
Asociaciones de seguridad y el SPI
Parece evidente que si dos puntos finales o puertas de enlace se va a establecer una conexión segura, una especie de secreto compartido se requiere que la simiente de la función de autenticación y / o la clave del algoritmo de cifrado. La cuestión de hasta qué punto se trata de secretos se han establecido es un tema importante a tratar en otro lugar, y para los fines de esta discusión que sólo se asume que las claves del arte de magia aterrizó al que pertenecen.
Cuando un datagrama IPsec - AH o ESP - llega a una interfaz, simplemente, ¿cómo la interfaz de saber qué conjunto de parámetros (algoritmo de clave, y las políticas) a utilizar? Cualquier host puede tener varias conversaciones en curso, cada uno con un conjunto distinto de claves y algoritmos, y algo debe ser capaz de dirigir este proceso.
Seguro!
Se ha señalado que la SADB sólo utiliza el tipo de protocolo y SPI para seleccionar una entrada, no la dirección IP asociada; simplemente no lo sé.
Esto podría depender de si la asociación se configura con el modo principal o de modo agresivo, pero damos la bienvenida a las aclaraciones.
Esto se especifica por la Asociación de Seguridad (SA), una colección de parámetros específicos de la conexión, y cada socio puede tener una o más asociaciones de seguridad. Cuando un datagrama llega, tres datos se utilizan para localizar la SA correcta dentro de la base de datos de asociaciones de seguridad (SADB):
Socio dirección IP
Protocolo IPSec (ESP o AH)
Índice de parámetros de seguridad
En muchos sentidos, este triple se puede comparar a una toma de IP, que es el único indicado por la dirección IP remota, protocolo y número de puerto.
Asociaciones de seguridad son una forma, por lo que una conexión de dos vías (el caso típico) requiere al menos dos. Además, cada protocolo (ESP / AH) tiene su propio SA en cada dirección, por lo que un total AH + ESP VPN requiere de cuatro asociaciones de seguridad. Estos son mantenidos en la base de datos de asociaciones de seguridad.
Una enorme cantidad de información se mantiene en el SADB, y no podemos ahondar en algunas de ellas:
AH: La autenticación de algoritmo
AH: La autenticación de secreto
ESP: algoritmo de cifrado
ESP: clave de codificación secreta
ESP: habilitada la autenticación sí / no
Muchos de intercambio de claves, parámetros
Enrutamiento de las restricciones
La política de filtrado de IP
Algunas implementaciones de mantener el SPD (Base de Datos de Seguridad Común), con herramientas de línea de comandos, y otros con una interfaz gráfica de usuario, mientras que otras ofrecen una interfaz basada en web en la red. La cantidad de detalles que mantiene una implementación en particular depende de las facilidades que ofrece, así como si se está operando en el host o el modo de puerta de enlace (o ambos).
De administración de claves
Por último, una breve visita de la materia muy compleja de la gestión de claves. Esta área incluye varios protocolos y muchas opciones, y la mayor parte de esto se tratará en un artículo futuro. Esta sección es necesariamente muy incompleta.
IPsec sería casi inútil sin las facilidades criptográficas de autenticación y cifrado, y estos requieren el uso de claves secretas conocer a los participantes, pero no a nadie más.
La manera más obvia y directa para establecer estos secretos es a través de la configuración manual: una de las partes genera un conjunto de secretos, y transmite a todos los socios. Todas las partes de instalación de estos secretos en sus asociaciones de seguridad apropiadas en el SPD.
Pero este proceso no escala bien, ni es siempre muy seguros: el mero hecho de transmitir los secretos de la SPD de otro sitio y puede exponer en tránsito. En una instalación más grande con muchos dispositivos utilizando la misma clave previamente compartida, el compromiso de esa llave lo convierte en un muy perjudicial re-despliegue de las nuevas llaves.
IKE - Internet Key Exchange - existe para permitir que dos puntos finales para la correcta configuración de sus asociaciones de seguridad, incluyendo los secretos para ser utilizado. IKE utiliza el ISAKMP (Internet Security Association Key Management Protocol) como un marco para apoyar el establecimiento de una asociación de seguridad compatible con los dos extremos.
Múltiples de intercambio de claves protocolos mismos son compatibles con Oakley es el más ampliamente utilizado. Vamos a señalar que el intercambio de claves IPsec normalmente se lleva a cabo a través del puerto el puerto 500 UDP.
Recursos
Internet tiene una gran cantidad de recursos alrededor de IPsec, algunos mejores que otros. El punto de partida, por supuesto, es siempre con el RFC (Peticiones de comentarios) que constituyen los estándares de Internet la definición de los protocolos. Estas son las principales obras de referencia sobre el que toda la documentación - se basa - incluido éste.
Actualización: En diciembre de 2005, un nuevo conjunto de RFC fue publicado por el IETF, y la serie 43xx en gran parte obsoletas de la serie 24xx. Se incluyeron las referencias a todos los RFCs (viejos y nuevos) a continuación, aunque este documento en realidad no ha sido actualizado para los nuevos.
RFC 2401 - Arquitectura de seguridad para IPsec - obsoletas
RFC 4301 - Arquitectura de seguridad para IPsec - nuevos 12 2005
Este es el resumen de toda la suite de protocolo IPsec desde el punto de vista de la RFC. Esto, y la Hoja de Ruta de Documentación (RFC 2411) son buenos lugares para empezar.
RFC 2402 - AH: Authentication Header - obsoletas
RFC 4302 - AH: Authentication Header - nuevos 12 2005
Esto define el formato de la cabecera de autenticación IPsec, tanto en el túnel y los modos de transporte.
RFC 2403 - Uso de HMAC-MD5-96 en ESP y AH
RFC 2404 - Uso de HMAC-SHA-1-96 en ESP y AH
Estos dos RFC definir algoritmos de autenticación utilizado en AH y ESP: MD5 y SHA-1 son resúmenes criptográficos, y son parte de un código de autenticación de mensajes hash. AH siempre realiza la autenticación, mientras que ESP hace de forma opcional.
RFC 2104 - HMAC: Teclea-Hashing para autenticación de mensajes
Este RFC define el algoritmo de autenticación que utiliza un hash criptográfico, junto con un secreto para verificar la integridad y la autenticidad de un mensaje. No está escrito para ser parte de IPsec, pero es referencia en el RFC 2403 y
RFC 2404.
RFC 2405 - El ESP DES-CBC algoritmo de cifrado con Explicit IV
Esto define el uso de DES (Data Encryption Standard del) como algoritmo de la confidencialidad en el contexto de ESP.
RFC 2406 - ESP: Carga de seguridad encapsuladora obsoletos
RFC 4303 - ESP: Carga de seguridad encapsuladora nuevas diciembre 2005
ESP es el compañero de encriptación para AH, y que permite la confidencialidad sobre el contenido de su carga. ESP por sí misma no define los algoritmos de cifrado en particular, pero proporciona un marco para ellas.
RFC 2407 - El Dominio de Internet IP Seguridad de Interpretación de ISAKMP
Este RFC describe el uso de ISAKMP - Internet Security Association y el Protocolo de administración de claves - en el contexto de IPsec. Es un marco para el intercambio de claves en el inicio de una conversación, y su uso evita la mala
práctica del uso de claves manual.
RFC 2408 - Internet Security Association y Key Management Protocol (ISAKMP)
De la mano con RFC 2407, RFC esta inmersiones en mucho más detalle en el protocolo ISAKMP para apoyar el intercambio de
claves (aunque no define los protocolos de intercambio de claves a sí mismos).
RFC 2409 - La Internet Key Exchange (IKE) Protocolo obsoletos
RFC 4306 - La Internet Key Exchange (IKE) nuevo Protocolo 12 2005
A pesar de ISAKMP proporciona un marco para el intercambio de claves, no define los protocolos de sí mismos: esta RFC hace eso. IKE incluye la autenticación inicial, así como de intercambio de claves Oakley.
RFC 2410 - El algoritmo de cifrado NULL y su uso con IPsec
ESP IPsec es el protocolo realiza el cifrado de la carga con uno de los varios algoritmos disponibles, pero un algoritmo de cifrado NULL es que habitualmente está disponible para la prueba. Por supuesto, esto no ofrece confidencialidad para los "protegidos" de datos, pero puede ser útil para los desarrolladores o los que tratan de entender IPsec por la inhalación del cable. Esta RFC se escribe con humor y podría haber sido (pero no), escrito el 1 de abril.
RFC 2411 - Hoja de ruta IP Documento de Seguridad
Esta RFC se proporciona una distribución de los diversos relacionados con IPsec RFC, así como proporciona un marco para nuevos tipos de RFC en particular ("algoritmos de autenticación", "algoritmos de cifrado"). Es un buen punto de partida.
RFC 2412 - El Protocolo de Determinación de Claves OAKLEY
OAKLEY forma parte de IKE (Internet Key Exchange), y proporciona un servicio en dos partes autentificadas pueden ponerse de acuerdo sobre los secretos necesarios para las comunicaciones IPsec.
Una guía ilustrada de resúmenes criptográficos - Unixwiz.net Consejo técnico
Un documento introductorio sobre el uso de resúmenes criptográficos como MD5 o SHA-1, que se utilizan en HMAC de AH para la
autenticación.
IPsec referencia técnica de Microsoft
Esto proporciona información sobre la implementación de Microsoft de IPsec en el servidor de producto de Windows 2003, incluyendo una gran cantidad de la infraestructura necesaria para apoyar grandes IPsec en la empresa.
TCP / IP Illustrated, Volumen 1, de W. Richard Stevens.
Este es el texto clásico sobre el protocolo TCP / IP, que abarca hasta la cabecera del paquete con un detalle exquisito: Se trata de un recurso extraordinario.
Una evaluación de cifrado de IPsec, por Bruce Schneier y Niels Ferguson.
Un interesante trabajo sobre la seguridad de IPsec, cuyo principal punto es que IPsec es demasiado complejo como para nunca ser realmente seguro (algo que ha cruzado nuestras mentes también). Entre sus propuestas para acabar con el modo de transporte y AH: ESP en modo túnel puede ofrecer todo esto la misma funcionalidad.
RFC 3884 - Uso del modo de transporte IPSec para enrutamiento dinámico
En contraste con el papel Schneier, también se ha sugerido que el modo de transporte es el único que es estrictamente necesario para cumplir con todo, y RFC 3884 muestra una forma de proporcionar el modo de túnel. Se ha sugerido para nosotros que esto hace que algunas cuestiones de aplicación mucho más fácil, aunque no hemos investigado realmente nada de eso.
Criptografía en la teoría y la práctica: El caso de la encriptación en IPsec, Paterson y Yau
Este artículo muy interesante analiza algunos de los peligros de las conexiones IPsec cifrado, pero no autenticado, con ataques efectivos en sistemas reales (incluyendo la implementación del núcleo Linux de IPsec). Es un trabajo muy inteligente.
Seguir leyendo:
http://www.unixwiz.net/techtips/iguide-ipsec.html
Fuente:
http://www.unixwiz.net/techtips/iguide-ipsec.html
Traduccion: Dellcom1@
Saludos Mundo Libre.
No hay comentarios:
Publicar un comentario