IPSec difficile avec Linux

Développer une infrastructure informatique, tôt ou tard, la tâche vient de s'intégrer à tous les services d'une grande organisation. Il peut s'agir, par exemple, d'une banque ou d'un opérateur télécom. En règle générale, les grandes organisations ont des politiques de sécurité de l'information bien établies, qui nécessitent notamment la mise en œuvre d'un service avec une infrastructure extérieure à elles via des canaux cryptés - IPSec. Dans le même temps, dans les petites organisations de démarrage , il n'y a aucune expérience dans l'organisation de tels programmes, et à partir de l'équipement, il n'y a que VDS avec Linux à bord. De plus, à ma grande surprise, il n'y a pratiquement aucun matériel dans Runet décrivant les outils de dépannage Linux. Essayons d'éliminer cet écart et décrivons la partie pratique des paramètres.

Le schéma général du service est présenté ci-dessous. En règle générale, dans les grandes organisations, tout est déjà standardisé, mis en service, toutes sortes de chiffrement possible et d'autres éléments de réseau sont réalisés sur des équipements séparés (tsiska-junipers et autres comme eux), et, plus important encore, par des individus (chaque boîte bleue dans le diagramme ci-dessous est possible servi par différentes personnes). Vous avez une machine virtuelle avec laquelle le service sera lancé et IPSec sera organisé.



Veuillez noter que IPSec lui-même est organisé entre une adresse IP (dans mon exemple 10.0.255.1 <-> 10.0.1.1 ), et le service lui-même est organisé entre autres ( 192.168.255.1<-> 192.168.1.1 ). De tels schémas sont également appelés IPSec Network-Network .

Un exemple simple est que vous travaillez dans une entreprise jeune mais très ambitieuse, SuperService , et que vous devez organiser l'interaction avec l'API fermée de MegaTelecom . Votre infrastructure est un serveur VDS, votre infrastructure partenaire est un ensemble d'équipements réseau et serveur. La tâche est divisée en deux étapes:

1. Organiser le transport (comment l'interfonctionnement se produira).
2. Configurez le service (exécutez les applications directement sur les serveurs).

Ainsi, le gestionnaire de SuperService a décidé d'organiser une connexion avec une grande organisation pour résoudre un problème commercial. Il s'est tourné vers MegaTelecom , auquel ils lui ont envoyé les spécifications techniques de la connexion. IPSec est l'une de ces conditions. Cette condition est venue sous la forme d'une plaque Excel , dont j'ai présenté un exemple ci-dessous. Dans l'image, j'ai mis en évidence des paramètres techniquement significatifs en jaune. Le format peut varier, mais l'essence reste la même.



Au départ, il n'est pas rempli de votre part, il doit être rempli et envoyé pour approbation au partenaire. Après avoir accepté, vous pouvez vous asseoir et essayer de régler votre machine Linux.

Concept IPSec

Ensuite, je vais donner un peu de théorie aux personnes qui ne sont pas du tout familières avec la technologie. Tout ce que je décrirai plus loin se réfère à Ethernet pur et IPv4. Je n'entrerai pas dans le chiffrement, les algorithmes d'échange de clés, mais je me concentrerai plutôt sur la partie réseau.

IPSec - un ensemble de techniques et de protocoles pour organiser une connexion sécurisée.

Contrairement à d'autres technologies de tunnellisation (GRE, PPP, L2TP, même MPLS-TE), aucune interface de tunnel explicite n'est créée pour IPSec à travers laquelle le trafic peut être acheminé. Au lieu de cela, IPSec fournit le concept de ce qu'on appelle les associations de sécurité (SA) . SA est le tunnel d'un périphérique réseau à un autre. Mais n'oubliez pas que SA n'est pas une interface réseau au sens normal du terme, le routage classique ne fonctionne pas ici. Au lieu de la table de routage, le concept de politique de sécurité (SP) fonctionne ici. Nous prescrivons explicitement quelque chose comme une liste d'accès (ACL) pour faire passer le trafic via une SA spécifique. Toutes ces choses sont définies dans le cadre dit ISAKMP .

ISAKMP - une description des procédures IPSec, dans la littérature ils appellent cela un cadre. Il décrit les termes SA, SP, SAD (Security Assotiations Database), SPD (Security Policy Database), la nécessité d'installer des tunnels auxiliaires ... ISAKMP est conçu pour ne pas dépendre des technologies de tunneling, des algorithmes d'authentification et du chiffrement. Il introduit simplement les définitions nécessaires.

IKE (v1 / 2) - protocole d'authentification directe. Il implémente déjà des algorithmes d'échange de clés et leur application.

Grâce au concept Cisco, ISAKMP et IKE sont désormais considérés comme synonymes.

Avant de crypter le trafic, les parties doivent convenir des paramètres (et clés) de ce cryptage. Pour ce faire, un tunnel auxiliaire monte entre les deux côtés (il est aussi appelé tunnel ISAKMP), qui fonctionne tout le temps. Ce tunnel bidirectionnel est une connexion UDP (par défaut sur le port 500). Pour organiser ce tunnel auxiliaire, les parties doivent s'authentifier (le mot de passe doit correspondre). Cela se fait par le protocole IKEv1 / 2 (Internet Key Exchange) . Et déjà sur le tunnel organisé ISAKMP , les parties conviennent de crypter directement le trafic utilisateur.

L'organisation IPSec elle-même est divisée en deux phases:

1. Création d'un tunnel auxiliaire ISAKMP
2. Création d'un tunnel de données utilisateur

Comme je l'ai écrit, dans le concept IPSec (ou plutôt dans le concept ISAKMP ) les tunnels sont appelés SA .

La première phase (organisation ISAKMP SA) peut être réalisée en deux modes:

1. les parties principales échangent alternativement les paramètres de négociation. Il est considéré comme plus sûr, il est utilisé pour les canaux permanents (notre cas).
2. agressif - dans un message, l'initiateur envoie tous les paramètres de coordination nécessaires; il est utilisé lors de la connexion d'un utilisateur distant pour une session temporaire (pour le rendre plus rapide).

Vous devez comprendre que les principaux tunnels SA sont unidirectionnels . Pour la transmission de données bidirectionnelle sur le canal IPSec, il doit y avoir deux tunnels: source (src) → récepteur (dst) et vice versa.

Dans toutes les méthodes de chiffrement, des en-têtes supplémentaires sont ajoutés au paquet IP d'origine, l'encapsulation se produit. Il existe deux méthodes pour cette encapsulation - AH (Authentication Header) et ESP (Encapsulation Security Payload) . AH authentifie uniquement le paquet (signé numériquement par l'expéditeur), ESP et authentifie (signe) et chiffre. Aujourd'hui, AH n'est presque jamais utilisé, tout est emballé dans ESP.

Vous pouvez crypter et authentifier le paquet IP source sans prendre en compte l'en-tête IP (mode transport) ou avec lui (mode tunnel). Le transport est utilisé lorsqu'il est prévu d'organiser ses tunnels à l'aide d'autres technologies (pas IPSec / ESP). Par exemple, GRE, l2tp, ppp. Dans le but de connecter certains services à l'infrastructure interne d'une grande organisation, il n'est pratiquement pas utilisé. J'ai utilisé ce scénario pour combiner plusieurs bureaux en un VPN via IPSec. Nous sommes plus intéressés par le mode tunnel . Comme vous pouvez le voir sur l'image, un en-tête IP supplémentaire est ajouté ici.

Soit dit en passant, il existe un véritable exemple d'utilisation de l'encapsulation AH. Supposons que nous ayons deux réseaux connectés à des routeurs différents. Les hôtes doivent transmettre des informations avec une MTU de 1500 octets sans fragmentation, mais nous avons une section intermédiaire qui ne prend en charge que 1380 octets. La piste entière est fiable. Nous pouvons profiter du fait qu'IPSec ne crée pas d'interfaces tunnel, au sens classique par lequel le trafic n'est pas acheminé. Nous allons créer une SA de tunnel de type AH (nous n'avons pas besoin de crypter), puis le trafic y ira. Seuls les paquets IP externes (selon les en-têtes IP externes) seront fragmentés dans le trafic, les paquets internes seront réassemblés sans modifications.

Notez que l'en-tête ESP monte avant le transport TCP / UDP . Rappelez-vous que le champ IP a un champ Protocole? Sur la base de ce champ, l'équipement réseau (et les hôtes finaux) traitent correctement les paquets IP. Donc pour ESP son nombre est de 50. Une liste complète des protocoles pour ce champ peut être consultée sur le wiki , elle peut être très utile.

L'absence d'un en-tête de couche transport (TCP / UDP / ICMP est déjà chiffré!) Impose une limitation aux technologies telles que NAT. Rappelez-vous, NAT avec traduction de port (surcharge, PAT, MASQARADE, il a plusieurs noms) fonctionne sur la base des ports de protocole de transport. Et dans le tunnel IPSec crypté, ils ne le sont pas! Pour surmonter ce problème, il existe une technologie telle que IPSec NAT-Traversal (NAT-T) . Au cours de la première phase, les parties conviennent de l'utilisation de NAT-T. Si les deux côtés prennent en charge NAT-T (et même sur les mêmes ports UDP), l'en-tête UDP est ajouté aux tunnels résultants pour le trafic, avec lesquels les paquets passeront déjà par des routeurs avec traduction d'adresses réseau.

Le tunnel lui-même ne montera pas, vous devez y diriger le trafic. Comme je l'ai écrit ci-dessus, les règles de routage ne fonctionnent pas ici, vous devez écrire des politiques de sécurité (SP) .

Les politiques se composent de l'adresse source, de l'adresse de destination, de la direction (in, out, fwd) et des paramètres du tunnel utilisateur (ici, ESP sera décrit simplement s'il s'agira d'AH, d'une version tunnel ou d'un transport). Cela ressemble plus à l'organisation de règles pour NAT. NAT n'a pas non plus suffisamment d'entrées de table de routage. Et là aussi, les règles sont indiquées où, où et comment , et non où et par quoi . Et aussi avec le mauvais mouvement de la main, vous pouvez bloquer toutes les communications sur le serveur distant.

Toutes les manipulations IPSec ajoutent des en-têtes généraux. Au moins, ils mangeront encore 40 octets du paquet d'origine. Ainsi, par exemple, avec une MTU standard pour PPPoE de 1380 octets de connexions, la vraie MTU sera <1340.

IPSec sur Linux

Pratiquons l'utilisation de l'exemple des distributions DEB. Je ne considérerai que le cas d'une autorisation basée sur une clé pré-partagée (PSK) , nous configurerons le schéma depuis le début de l'article.

IPSec lui-même est pris en charge par le noyau, mais ce support est très limité. En fait, les modules vigoureux ne concernent que le chiffrement et les clés (traitement des paquets) qui ont déjà été reçues (transférées au noyau). Et pour y passer les paramètres et les règles avec lesquels vous devez traiter le trafic, vous avez besoin d'un logiciel séparé. En tant que tel logiciel, il existe plusieurs solutions:

1. KAME a migré de BSD
2. xSWAN (strongswan, freeswan, libreswan, etc.)
3. rivage

Il me semblait que la version la plus simple (la plus prévisible) de KAME, et nous continuerons à la tordre.

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

Traditionnellement, KAME se composait de deux composants

1. Le démon racoon pour contrôler le tunnel ISAKMP .
2. Utilitaires Setkey pour la gestion des tunnels SA avec des données.

Commençons par le premier. Racoon est responsable des paramètres d'autorisation du tunnel sous IKE. Il s'agit d'un démon, il est configuré avec un fichier de configuration ( /etc/racoon.conf ), il est lancé par un script d'initialisation normal ( /etc/init.d/racoon <start|stop|restart> ).



Comme toujours, détails dans man 5 racoon.conf

Ensuite, nous allons utiliser l' utilitaire setkey . Il démarre également en tant que démon ( /etc/init.d/setkey <start|stop|restart> ), mais en fait il exécute le script /etc/ipsec-tools.conf . Comme je l'ai dit, il définit déjà des tunnels pour le trafic des utilisateurs. À savoir définit SA et SP pour eux. C'est quelque chose comme une crypto-carte sur l'ASA. L'option la plus simple pour nous consiste à ajouter uniquement SP. Ensuite, le SA sera construit automatiquement en fonction des paramètres de la deuxième phase spécifiés dans les paramètres de racoon .

Mais il est possible de ne pas utiliser du tout les paramètres de la deuxième phase de racoon , mais de définir SA via cet utilitaire. Les détails et la syntaxe se trouvent dans man 8 setkey . Mais je vais donner un exemple de la configuration la plus simple.


Actuellement, l'utilitaire setkey est dupliqué par le module iproute2 .
Dans ce cadre, il existe deux équipes de gestion des enregistrements SA et SP.

1. état ip xfrm
2. politique d' ip xfrm

En plus de gérer cet utilitaire, vous pouvez voir l'état des SA et SP organisés appliqués au trafic. Plus de détails dans man 8 ip-xfrm .

Jetez un autre regard sur la tablette d'origine. Il existe différentes adresses IP pour IPSec et le service. L'adresse IP interne est filtrée à l'intérieur de l'infrastructure Megatelecom . Mais nous n'avons qu'une seule machine virtuelle. Une adresse IP interne devrait en quelque sorte y apparaître, et les paquets dans le tunnel devraient en sortir. Il existe plusieurs options pour réaliser ce scénario:

1. Un itinéraire statique sans détecter d'arrêt, mais avec une indication explicite de l'interface sortante et de l'adresse IP.
2. Définir des itinéraires basés sur un routage basé sur des politiques (PBR sous Linux ou règle ip ).
3. Traduction d'adresse ( NAT / MASQARADE ).

De mon point de vue, la première option convient ici.

Nous pouvons ajouter une adresse IP supplémentaire (secondaire) à notre interface, alors qu'il est préférable de créer un alias pour cette interface
root@localhost: ~# ip addr add 192.168.1.1/32 dev eth1 label eth1:1
et configurer l'itinéraire vers le serveur Megatelecom à partir de cette adresse IP.
root@localhost: ~# ip route add 192.168.255.1/32 dev eth1:1 src 192.168.1.1
Mais si vous le faites, rien ne commencera. Le fait est que lors de l'ajout d'un itinéraire sous cette forme, la station Linux essaiera de déterminer l'adresse MAC du destinataire, elle le fera via ARP ... L'ordinateur enverra des requêtes ARP Who has IP 192.168.255.1 . Étant donné que 192.168.255.1 n'est pas sur le même réseau que 192.168.1.1 (mask / 32!), Il n'y aura aucune réponse à ARP. Mais lorsque vous essayez de vous connecter, No route to host ne sera retournée à partir de l'adresse IP locale. Pour vaincre cela, nous devons définir un enregistrement ARP statique:
root@localhost: ~# arp -s 192.168.255.1 00:00:00:00:00:01 -i eth1:1
Un tel hack de vie. Soit dit en passant, de telles manipulations peuvent ne pas conduire au bon fonctionnement de la pile IP Linux. Dans l'un des cas, les commandes ip route n'ont pas produit le résultat souhaité, il a fallu redémarrer la pile réseau.

Bilan de santé

N'oubliez pas, le tunnel ne montera que lorsque le trafic y entrera! Il est nécessaire de lancer le ping depuis une interface spécifique (adresse IP) avant la destination.
root@localhost: ~# ping -I 192.168.1.1 192.168.255.1
Avec un léger retard, il devrait y avoir des réponses de l'arrière (à moins bien sûr que l'ICMP soit fermé n'importe où sur le site).

Nous pouvons voir si le tunnel ISAKMP a augmenté.


Nous pouvons également voir des tunnels avec des données utilisateur.


Il peut être utile dans tcpdump d' examiner la logique d'établissement d'une connexion. Ici, vous pouvez également voir les phases d'établissement de la connexion et le trafic déjà transmis crypté vers ESP. Bien sûr, il existe des techniques pour le déchiffrer, mais généralement cette conclusion est déjà suffisante.

Lors de la connexion à distance via SSH, afin de ne pas produire un tas de fenêtres, il est pratique d'exécuter tcpdump en arrière-plan:

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


On démarre ping, telnet, netcat ...

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


Dans les journaux, vous pouvez également voir l'état de la connexion. Il montre la réussite de la mise en place des deux phases d'IPSec.


C’est tout. Il reste à ajouter toutes les manipulations nécessaires au démarrage, et vous pouvez commencer l'intégration des applications.

PS: Une demande de signaler toutes les erreurs ou inexactitudes dans l'article par message personnel. Quand je peaufine l'article, les commentaires seront ridicules.