IPSec difícil con Linux

Desarrollando una infraestructura de TI, tarde o temprano, la tarea viene a integrarse con cualquier servicio de una gran organización. Esto puede ser, por ejemplo, un banco o un operador de telecomunicaciones. Como regla general, las grandes organizaciones han establecido políticas de seguridad de la información, que en particular requieren la implementación de un servicio con una infraestructura externa a través de canales encriptados: IPSec. Al mismo tiempo, en las organizaciones de inicio pequeñas no hay experiencia en la organización de tales esquemas, y desde el equipo solo hay VDS con Linux a bordo. Además, para mi sorpresa, prácticamente no hay materiales en Runet que describan las herramientas de solución de problemas de Linux. Intentemos eliminar esta brecha y describamos la parte práctica de la configuración.

El esquema general del servicio se presenta a continuación. Como regla general, en las organizaciones grandes, todo ya está estandarizado, puesto en funcionamiento, todo tipo de cifrado posible y otras piezas de red se realizan en equipos separados (tsiska-junipers y otros como ellos) y, lo que es más importante, por individuos (tal vez cada cuadro azul en el diagrama a continuación atendido por diferentes personas). Tiene una máquina virtual con la que se iniciará el servicio y se organizará IPSec.



Tenga en cuenta que IPSec está organizado entre una dirección IP (en mi ejemplo 10.0.255.1 <-> 10.0.1.1 ), y el servicio en sí está organizado entre otros ( 192.168.255.1<-> 192.168.1.1 ). Dichos esquemas también se denominan IPSec Network-Network .

Un ejemplo simple es que trabajas en una empresa joven pero muy ambiciosa, SuperService , y necesitas organizar la interacción con la API cerrada de MegaTelecom . Su infraestructura es un servidor VDS, la infraestructura de su socio es un conjunto de equipos de red y servidor. La tarea se divide en dos etapas:

1. Organizar el transporte (cómo ocurrirá el interfuncionamiento).
2. Configure el servicio (ejecute aplicaciones directamente en los servidores).

Entonces, el gerente de SuperService decidió organizar una conexión con alguna organización grande para resolver un problema comercial. Se dirigió a MegaTelecom , a lo que le enviaron especificaciones técnicas para la conexión. Una de estas condiciones es IPSec . Esta condición se presentó en forma de una placa de Excel , un ejemplo del cual presenté a continuación. En la imagen, destaqué parámetros técnicamente significativos en amarillo. El formato puede variar, pero la esencia sigue siendo la misma.



Inicialmente, viene sin llenar de su parte, debe completarse y enviarse para su aprobación al socio. Después de aceptar, puede sentarse e intentar ajustar su máquina Linux.

Concepto IPSec

A continuación, daré una pequeña teoría para las personas que no están familiarizadas con la tecnología. Todo lo que describiré más adelante se refiere a Ethernet puro e IPv4. No entraré en encriptación, algoritmos de intercambio de claves, sino que me enfocaré en la parte de la red.

IPSec : un conjunto de técnicas y protocolos para organizar una conexión segura.

A diferencia de otras tecnologías de túnel (GRE, PPP, L2TP, incluso MPLS-TE), no se crean interfaces de túnel explícitas para IPSec a través de las cuales se puede enrutar el tráfico. En cambio, IPSec proporciona el concepto de las denominadas Asignaciones de seguridad (SA) . SA es el túnel de un dispositivo de red a otro. Pero no olvide que SA no es una interfaz de red en el sentido normal de la palabra, el enrutamiento clásico no funciona aquí. En lugar de la tabla de enrutamiento, el concepto de Política de seguridad (SP) funciona aquí. Expresamos explícitamente algo como una lista de acceso (ACL) para pasar el tráfico a través de una SA específica. Todas estas cosas se definen en el llamado marco ISAKMP .

ISAKMP : una descripción de los procedimientos de IPSec, en la literatura lo llaman marco. Describe los términos SA, SP, SAD (base de datos de negociaciones de seguridad), SPD (base de datos de políticas de seguridad), la necesidad de instalar túneles auxiliares ... ISAKMP está diseñado para no depender de tecnologías de túnel, algoritmos de autenticación y cifrado. Simplemente introduce las definiciones necesarias.

IKE (v1 / 2) : protocolo de autenticación directamente. Él ya implementa algoritmos de intercambio de claves y su aplicación.

Gracias al concepto de Cisco, ISAKMP e IKE ahora se consideran sinónimos.

Antes de cifrar el tráfico, las partes deben acordar los parámetros (y claves) de este cifrado. Para hacer esto, un túnel auxiliar se eleva entre ambos lados (también llamado túnel ISAKMP), que funciona todo el tiempo. Este túnel bidireccional es una conexión UDP (por defecto en el puerto 500). Para organizar este túnel auxiliar, las partes deben autenticarse mutuamente (la contraseña debe coincidir). Esto se realiza mediante el protocolo IKEv1 / 2 (Internet Key Exchange) . Y ya en el túnel organizado ISAKMP , las partes acuerdan cifrar directamente el tráfico de usuarios.

La propia organización IPSec se divide en dos fases:

1. Crear un túnel auxiliar ISAKMP
2. Crear un túnel de datos de usuario

Como escribí, en el concepto IPSec (o más bien, en el concepto ISAKMP ) los túneles se llaman SA .

La primera fase (organización ISAKMP SA) se puede llevar a cabo de dos modos:

1. main - las partes intercambian alternativamente parámetros de negociación. Se considera más seguro, se usa para canales permanentes (nuestro caso).
2. agresivo : en un mensaje, el iniciador envía todos los parámetros de coordinación necesarios; se utiliza cuando se conecta a un usuario remoto para una sesión temporal (para hacerlo más rápido).

Debe comprender que los túneles SA principales son unidireccionales . Para la transmisión de datos bidireccional a través del canal IPSec, debe haber dos túneles: fuente (src) → receptor (dst) y viceversa.

En todos los métodos de cifrado, se agregan encabezados adicionales al paquete IP original, se produce la encapsulación. Hay dos métodos para esta encapsulación: AH (Encabezado de autenticación) y ESP (Encapsulation Security Payload) . AH solo autentica el paquete (firmado digitalmente por el remitente), ESP y autentica (firma) y cifra. Hoy, AH casi nunca se usa, todo está empaquetado en ESP.

Puede cifrar y autenticar el paquete de IP de origen sin tener en cuenta el encabezado de IP (modo de transporte) o con él (modo de túnel). El transporte se utiliza cuando se planea organizar sus túneles utilizando otras tecnologías (no IPSec / ESP). Por ejemplo, GRE, l2tp, ppp. Con el fin de conectar algún servicio a la infraestructura interna de una gran organización, prácticamente no se utiliza. Usé este escenario para combinar varias oficinas en una VPN a través de IPSec. Estamos más interesados ​​en el modo túnel . Como puede ver en la imagen, aquí se agrega un encabezado IP adicional.

Por cierto, hay un ejemplo real de uso de encapsulación AH. Supongamos que tenemos dos redes conectadas a diferentes enrutadores. Los hosts deben transmitir información con una MTU de 1500 bytes sin fragmentación, pero tenemos una sección intermedia que solo admite 1380 bytes. Toda la pista es de confianza. Podemos aprovechar el hecho de que IPSec no crea interfaces de túnel, en el sentido clásico a través del cual el tráfico no se enruta. Crearemos un SA tipo túnel AH (no necesitamos encriptar), luego el tráfico irá a él. Solo los paquetes de IP externos (de acuerdo con los encabezados de IP externos) se fragmentarán en el tráfico, los internos se volverán a ensamblar sin cambios.

Tenga en cuenta que el encabezado ESP se eleva antes del transporte TCP / UDP . ¿Recuerdas que el campo IP tiene un campo de protocolo? Según este campo, el equipo de red (y los hosts finales) procesan correctamente los paquetes IP. Entonces, para ESP su número es 50. Una lista completa de protocolos para este campo se puede ver en la wiki , puede ser muy útil.

La ausencia de un encabezado de capa de transporte (¡TCP / UDP / ICMP ya está encriptado!) Impone una limitación en tecnologías como NAT. Recuerde, NAT con traducción de puerto (sobrecarga, PAT, MASQARADE, tiene muchos nombres) funciona sobre la base de puertos de protocolo de transporte. ¡Y en el túnel cifrado IPSec no lo están! Para superar este problema, existe una tecnología como IPSec NAT-Traversal (NAT-T) . Durante la primera fase, las partes acuerdan el uso de NAT-T. Si ambos lados admiten NAT-T (e incluso en los mismos puertos UDP), entonces el encabezado UDP se agrega a los túneles resultantes para el tráfico, con el cual los paquetes ya pasarán por enrutadores con traducción de direcciones de red.

El túnel en sí no se elevará, debe dirigir el tráfico allí. Como escribí anteriormente, las reglas de enrutamiento no funcionan aquí, debe escribir las Políticas de seguridad (SP) .

Las políticas consisten en la dirección de origen, la dirección de destino, la dirección (entrada, salida, avance) y los parámetros del túnel del usuario (aquí ESP se describirá solo si será AH, versión del túnel o transporte). Esto es más como organizar reglas para NAT. NAT tampoco tiene suficientes entradas en la tabla de enrutamiento. Y allí, también, las reglas se indican dónde, dónde y cómo , y no dónde y a través de qué . Y también con el movimiento incorrecto de la mano puede bloquear todas las comunicaciones en el servidor remoto.

Todas las manipulaciones de IPSec agregan encabezados generales. Al menos comerán otros 40 bytes del paquete original. Así, por ejemplo, con una MTU estándar para PPPoE de 1380 bytes de conexiones, la MTU real será <1340.

IPSec en Linux

Practiquemos usando el ejemplo de distribuciones DEB. Consideraré solo el caso con autorización basada en clave precompartida (PSK) , configuraremos el esquema desde el comienzo del artículo.

IPSec es compatible con el núcleo, pero este soporte es muy limitado. En realidad, los módulos vigorosos solo están relacionados con el cifrado y las claves (procesamiento de paquetes) que ya se han recibido (transferido al núcleo). Y para pasar allí los parámetros y reglas con los que necesita procesar el tráfico, necesita un software separado. Como tal software, hay varias soluciones:

1. KAME migró de BSD
2. xSWAN (strongswan, freeswan, libreswan, etc.)
3. muro costero

Me pareció la versión más simple (más predecible) de KAME, y continuaremos girándola.

 # deb-       root@localhost: ~# apt-get install racoon ipsec-tools 

Tradicionalmente, KAME constaba de dos componentes.

1. El demonio mapache para controlar el túnel ISAKMP .
2. Utilidades Setkey para gestionar túneles SA con datos.

Comencemos con el primero. Racoon es responsable de la configuración de autorización del túnel bajo IKE. Este es un demonio, se configura con un archivo de configuración ( /etc/racoon.conf ), se inicia mediante un script de inicio normal ( /etc/init.d/racoon <start|stop|restart> ).



Como siempre, detalles en man 5 racoon.conf

A continuación, tomaremos la utilidad setkey . También comienza como un demonio ( /etc/init.d/setkey <start|stop|restart> ), pero de hecho ejecuta el script /etc/ipsec-tools.conf . Como dije, ya establece crea túneles para el tráfico de usuarios. A saber establece SA y SP para ellos. Esto es algo así como un mapa criptográfico en el ASA. La opción más fácil para nosotros es agregar solo SP. Luego, el SA se construirá automáticamente en función de los parámetros de la segunda fase especificada en la configuración del mapache .

Pero es posible no utilizar los parámetros de la segunda fase del mapache en absoluto , sino establecer SA a través de esta utilidad. Los detalles y la sintaxis se pueden encontrar en man 8 setkey . Pero daré un ejemplo de la configuración más simple.


Actualmente, la utilidad setkey está duplicada por el módulo iproute2 .
Como parte de esto, hay dos equipos de administración de registros SA y SP.

1. estado de ip xfrm
2. política ip xfrm

Además de administrar esta utilidad, puede ver el estado de las SA y SP organizadas aplicadas al tráfico. Más detalles en man 8 ip-xfrm .

Eche otro vistazo a la tableta original. Hay diferentes direcciones IP para IPSec y servicio. La dirección IP interna se está filtrando dentro de la infraestructura de Megatelecom . Pero solo tenemos una máquina virtual. Una dirección IP interna debería aparecer de alguna manera en él, y los paquetes en el túnel deberían salir de él. Hay varias opciones para lograr este escenario:

1. Una ruta estática sin detectar una parada, pero con una indicación explícita de la interfaz saliente y la dirección IP.
2. Definición de rutas basadas en el enrutamiento basado en políticas (PBR en Linux, también conocida como regla ip ).
3. Traducción de direcciones ( NAT / MASQARADE ).

Desde mi punto de vista, la primera opción es adecuada aquí.

Podemos agregar una dirección IP adicional (secundaria) a nuestra interfaz, mientras que es mejor crear un alias para esta interfaz
root@localhost: ~# ip addr add 192.168.1.1/32 dev eth1 label eth1:1
y configure la ruta al servidor Megatelecom desde esta dirección IP.
root@localhost: ~# ip route add 192.168.255.1/32 dev eth1:1 src 192.168.1.1
Pero si lo haces, nada comenzará. El hecho es que al agregar una ruta en este formulario, la estación de Linux intentará determinar la dirección MAC del destinatario, lo hará a través de ARP ... La computadora enviará solicitudes ARP Who has IP 192.168.255.1 . Dado que 192.168.255.1 no está en la misma red que 192.168.1.1 (máscara / 32!), No habrá respuesta a ARP. Pero cuando intenta conectarse, No route to host se devolverá No route to host desde la dirección IP local. Para vencer esto, necesitamos establecer un registro ARP estático:
root@localhost: ~# arp -s 192.168.255.1 00:00:00:00:00:01 -i eth1:1
Tal truco de vida. Por cierto, tales manipulaciones pueden no conducir al correcto funcionamiento de la pila IP de Linux. En uno de los casos, los comandos de ip route no produjeron el resultado deseado, fue necesario reiniciar la pila de red.

Control de salud

¡No olvides que el túnel solo se elevará cuando el tráfico entre en él! Es necesario iniciar el ping desde una interfaz específica (dirección IP) antes del destino.
root@localhost: ~# ping -I 192.168.1.1 192.168.255.1
Con un ligero retraso, debería haber respuestas desde el reverso (a menos, por supuesto, que ICMP esté cerrado en cualquier parte del sitio).

Podemos ver si el túnel ISAKMP ha subido.


También podemos ver túneles con datos de usuario.


Puede ser útil en tcpdump observar la lógica para establecer una conexión. Aquí también puede ver las fases de establecimiento de la conexión y el tráfico ya transmitido encriptado a ESP. Por supuesto, existen técnicas para descifrarlo, pero generalmente esta conclusión ya es suficiente.

Cuando se conecta de forma remota a través de SSH, para no producir un montón de ventanas, es conveniente ejecutar tcpdump en segundo plano:

root@localhost: ~# tcpdump -i eth1 -w ipsec.pcap esp &


Comenzamos ping, telnet, netcat ...

root@localhost: ~# killall tcpdump
root@localhost: ~# tcpdump -vr ipsec.pcap


También en los registros puede ver el estado exitoso de la conexión. Muestra el establecimiento exitoso de ambas fases de IPSec.


Eso es todo Queda por agregar todas las manipulaciones necesarias al inicio, y puede comenzar la integración de las aplicaciones.

PD: Una solicitud para informar todos los errores o inexactitudes en el artículo por mensaje personal. Cuando modifique el artículo, los comentarios se verán tontos.