| Linux VPN Masquerade HOWTO - Version française | ||
|---|---|---|
| Précédent | ||
Le trafic utilisant le protocole AH ne peut pas être masqué. Le protocole AH inclut un contrôleur d'intégrité cryptographique qui couvre les adresses IP, et que la passerelle de masquage ne peut pas régénérer correctement. Donc tout le trafic AH masqué va être rejeté car il aura des contrôleurs d'intégrité non valides.
Le trafic IPsec utilisant le mode de transport ESP ne peut pas non plus être correctement masqué. Le mode de transport ESP crypte tout ce qui se trouve après l'entête IP. Or, par exemple, les contrôleurs d'intégrité de TCP et UDP incluent les adresses IP source et destination, ils se trouvent dans la partie cryptée, et ne peuvent donc pas être recalculés après que la passerelle de masquage ait modifié les adresses IP. L'entête TCP/UDP ne va donc pas passer les contrôles d'intégrité sur la passerelle distante, et le paquet va être rejeté. Les protocoles n'incluant pas les informations sur les adresses IP source ou destination peuvent utiliser le masquage du mode de transport.
Ces limites mises à part, le masquage IPsec est sûr et fiable à condition qu'un seul hôte IPsec soit masqué à un instant donné, ou que chaque hôte masqué communique avec un serveur distant différent. Lorsque plusieurs machines masquées communiquent avec la même machine distante, quelques faiblesses apparaissent :
Les communications du mode transport sont sujettes à collisions.
Si deux machines masquées ou plus utilisent le mode transport pour communiquer avec le même hôte distant, et si la politique de sécurité sur l'hôte distant permet plusieurs sessions de mode transport avec la même machine, il est possible que les sessions aient des collisions. Ceci arrive parce que l'adresse IP de la passerelle de masquage va être utilisée pour identifier les sessions, et que les autres informations d'identification ne pourront pas être masquées puisqu'elles sont dans la portion cryptée du paquet.
Si la politique de sécurité de l'hôte distant n'autorise pas plusieurs sessions simultanées en mode transport avec la même machine, la situation est pire : la session en mode transport négociée en dernier va écraser tout le trafic de la session précédente, entraînant sa "mort". Alors que les sessions établies via l'ancienne session IPsec en mode transport vont être rapidement réinitialisées si l'hôte distant n'attend pas de trafic, au moins un paquet de données va être envoyé à la mauvaise machine. Ce paquet va probablement être ignoré par le destinataire, mais il va tout de même être envoyé.
Donc une collision du mode transport peut avoir comme conséquence une fuite d'information entre les deux sessions ou bien la fin de l'une des deux sessions. L'utilisation d'IPsec en mode transport via une passerelle de masquage n'est pas recommandée s'il y a une possibilité que d'autres sessions IPsec en mode transport soient initialisées via la même passerelle de masquage vers le même hôte IPsec distant.
IPsec en mode tunnel avec une adresse de réseau externe (l'hôte IPsec masqué se voit attribuer une adresse IP du réseau de l'hôte distant) n'est pas sujet à ces problèmes, car l'adresse IP fournie par le réseau distant sera utilisée pour identifier les sessions plutôt que l'adresse IP de la machine masquante.
Les communications ISAKMP sont sujettes à des collisions de cookies.
Si deux ou plusieurs machines masquées établissant une session avec la même machine distante utilisent le même cookie lors de l'initialisation du trafic ISAKMP, la passerelle de masquage va router tout le trafic ISAKMP vers la seconde machine. Il y a une chance sur 2^64 (ie. très petite) pour que cette collision ait lieu lorsque la connexion ISAKMP initiale est établie.
Pour corriger cela, il faut inclure le cookie de réponse dans la clé utilisée pour router le trafic ISAKMP entrant. Cette modification est incluse dans le code de masquage IPsec des noyaux 2.2.x, et la courte période entre le moment où l'hôte masqué initialise l'échange ISAKMP et la réponse de l'hôte distant est protégée par le bloquage de tout nouveau trafic ISAKMP qui pourrait entrer en collision avec le trafic actuel. Cette modification va bientôt être portée sur le code des 2.0.x.
Il peut y avoir une collision entre les valeurs SPI du trafic entrant.
Deux ou plusieurs hôtes IPsec masqués communiquant avec la même machine IPsec distante peuvent négocier pour utiliser la même valeur SPI pour le trafic entrant. Si cela arrive, la passerelle de masquage va router tout le trafic entrant vers la première machine qui va recevoir tout le trafic entrant avec ce SPI. La probabilité est de 1 sur 2^32 pour chaque session ESP, et le cas peut se présenter à chaque renouvellement de clés.
Les valeurs SPI sont rattachées à différents SA ayant différentes clés de cryptage, le premier hôte ne sera donc pas capable de décrire les données destinées aux autres machines, donc il n'y aura aucune fuite de données. Il n'y a aucun moyen pour la passerelle de masquage de détecter ou d'empêcher cette collision. La seule façon d'empêcher cette collision est que l'hôte IPsec distant vérifie la valeur SPI proposée par la machine masquée pour voir si cette valeur SPI est déjà utilisée par un autre SA depuis la même adresse IP. Il est peu probable que ceci soit implémenté un jour, car cela imposerait une charge supplémentaire à une opération déjà coûteuse (le renouvellement des clés) pour un bénéfice concernant un nombre réduit de personnes et un type d'évènement assez rare.
Les valeurs SPI entrantes et sortantes peuvent être dissociées.
Ceci sera vu en détail dans la section suivante.
Pour éviter ces problèmes, le code des noyaux 2.2.x empêche par défaut l'établissement de plusieurs connexions vers la même machine distante. Si vous estimez que la faiblesse liée à plusieurs connexions vers la même machine distante est acceptable, vous pouvez activer les "sessions parallèles".
Il peut être gênant de bloquer pour des raisons de sécurité les sessions parallèles : il n'y a aucun moyen pour le code de masquage IPsec de sniffer la session et de voir quand elle se termine, donc les entrées de la table de masquage vont être conservées pendant leur durée de vie standard, même si la session se termine juste après qu'elle ait été établie. Si l'on empêche les sessions parallèles, cela signifie que le serveur n'acceptera pas d'autre client tant que l'entrée de la table de masquage la plus récente sera présente. Cela peut prendre plusieurs heures.
La partie de l'échange de clés ISAKMP où les valeurs SPI d'ESP sont communiquées est cryptée, donc les valeurs SPI d'ESP doivent être déterminées en étudiant le trafic ESP actuel. Le trafic ESP sortant ne contient aucune indication sur ce que sera le SPI entrant. Cela signifie qu'il n'y a aucune méthode fiable pour associer le trafic ESP entrant avec le trafic ESP sortant.
Le masquage IPsec tente d'associer le trafic ESP entrant et sortant en sérialisant le trafic ESP par machine distante. Concrètement :
Si un paquet ESP sortant avec une valeur SPI qui n'a pas encore été vue (ou dont l'entrée dans la table de masquage a expiré) est reçu (il sera appelé par la suite un "paquet initial"), une entrée dans la table de masquage est créée pour cette combinaison AdresseSource+SPI+AdresseDest. Elle est marquée comme "en attente", ce qui signifie qu'aucun trafic correspondant à cette entrée n'a été pour l'instant reçu. Le marquage se fait en mettant la valeur "SPI entrant" dans l'entrée de la table de masquage à zéro, qui est une valeur réservée pour cela. Ceci arrivera lors de l'initialisation d'une nouvelle connexion ESP et à intervalles réguliers lors du renouvellement de clés d'une connexion ESP existante.
Tant que l'entrée de la table de masquage est en attente, aucun autre paquet ESP initial à destination du même hôte distant n'est traité. Les paquets sont immédiatement rejetés, et une entrée du journal système est ajoutée, précisant que le trafic est temporairement bloqué. Ceci s'applique également au trafic initial en provenance de la même machine masquée à destination du même hôte distant, si les valeurs SPI sont différentes. Le trafic vers d'autres hôtes distants, et le trafic où les deux valeurs SPI sont connues (trafic déjà "établi") n'est pas affecté.
Ceci peut facilement mener à un déni de service sur la machine distante, c'est pour cela que la durée de vie de cette entrée en attente de la table de masquage ESP est faible, et que seul un nombre limité de tentatives pour le même trafic est autorisé. Ceci permet de faire un accès via round-robin à la machine distante si plusieurs machines masquées tentent d'initialiser simultanément la connexion et que les réponses n'arrivent pas très vite, par exemple à cause d'une congestion réseau, ou d'une machine distante lente. Le décompte des tentatives commence dès qu'il y a une collision, donc l'hôte IPsec masqué peut attendre une réponse aussi longtemps qu'il le faut jusqu'à ce qu'il soit nécessaire de faire une mise en série des connexions.
Quand un paquet ESP est reçu en provenance de l'hôte distant en attente, et que la valeur SPI n'apparaît dans aucune entrée de la table de masquage, il est supposé que le paquet est la réponse au paquet en attente initial. La valeur SPI est stockée dans l'entrée courante de la table de masquage associant les valeurs SPI, et le trafic ESP entrant est alors routé vers la machine masquée. A ce point un autre paquet initial destiné au serveur distant peut être traité.
Tout trafic ESP avec une valeur SPI de zéro est rejeté comme étant invalide, conformément au RFC.
Il y a plusieurs possibilités pour que l'association de trafic ne se fasse pas proprement :
La latence du réseau ou la lenteur d'une machine distante peuvent retarder suffisamment la réponse au paquet initial pour que l'entrée de la table de masquage ait expiré, et qu'une autre machine masquée ait eu sa chance d'initialiser un trafic. Ceci peut faire que la réponse sera associée au mauvais SPI sortant, et donc le trafic entrant sera routé vers la mauvaise machine masquée. Si cela arrive, la machine masquée recevant le trafic par erreur le rejettera parce qu'il n'aura pas la valeur SPI attendue, et tout le monde risque de patienter jusqu'à la fin du temps d'attente pour faire un nouvel échange de clés, et réessayer. On peut y remédier en éditant /usr/src/linux/net/ipv4/ip_masq.c (ip_masq_ipsec.c dans le 2.2.x) et en augmentant la durée de vie d'INIT ou le nombre de tentatives INIT autorisées, avec pour coût l'agrandissement de la fenêtre de bloquage (et de déni de service).
Les sessions inactives ou semi-inactives (avec un trafic entrant peu fréquent et aucun trafic sortant) sur une longue période peuvent le rester suffisamment longtemps pour que l'entrée de la table de masquage expire. Si la machine distante envoie du trafic d'une session ayant déjà expiré au niveau de la table de masquage pendant qu'une initialisation est en cours vers la même machine, le trafic peut être incorrectement routé, pour la même raison que plus haut. On peut y remédier en s'assurant que le paramètre de configuration du noyau IPsec Masq Table Lifetime est légèrement plus grand que l'intervalle de renouvellement des clés, qui est la durée la plus longue que les paires SPI peuvent utiliser. Le problème ici est que vous ne pouvez pas connaître tous les intervalles de renouvellement des clés si vous masquez plusieurs serveurs distants, ou que certains peuvent avoir leurs intervalles de renouvellement des clés positionnés à des valeurs déraisonnablement élevées, comme plusieurs heures.
S'il y a un délai entre un renouvellement de clés et la transmission du trafic ESP sortant utilisant le nouveau SPI, et si durant ce délai un trafic ESP entrant utilisant ce nouveau SPI est reçu, il n'y a pas d'entrée de la table de masquage décrivant comment router le trafic entrant. Si une autre machine masquée a une initialisation en attente avec le même hôte distant, le trafic va être dissocié. Notez que la sérialisation du trafic ESP initial n'affecte pas le trafic de renouvellement des clés ISAKMP.
La meilleure solution est d'avoir un moyen de pré-charger la table de masquage avec les bonnes paires SPI-sortie/SPI-entrée, ou une autre forme d'association machine_distante + SPI_entrée avec la machine_masquée. Cela ne peut pas être fait en suivant l'échange de clés ISAKMP, car il est crypté. Il peut être possible d'utiliser RSIP (également connu en tant que Translation d'Adresse Réseau pour un hôte (NdT : Host-NAT)) pour communiquer avec l'hôte IPsec masqué et demander une notification sur les informations SPI une fois que la négociation a eu lieu. Ce point est à étudier. Si quelque chose est fait pour l'implémenter, ce ne sera pas fait avant les séries 2.3.x, car RSIP est un protocole NAT client/serveur assez complexe.
Quand un paquet ESP entrant avec un nouveau SPI est reçu, le pare-feu de masquage tente de deviner à quel(s) hôte(s) masqué(s) ce trafic entrant est destiné. Si le trafic ESP entrant ne correspond pas à une session établie, ou à une session en cours d'initialisation, alors le paquet est envoyé à la (aux) machine(s) masquée(s) qui a (ont) renouvelé en dernier ses (leurs) clés avec cet hôte distant. Les machines masquées "incorrectement" vont rejeter le trafic comme n'étant pas correctement crypté, et la machine "correctement" masquée va recevoir des données. Lorsque la machine "correctement" masquée répond, le processus normal de sérialisation de l'initialisation ESP a lieu.