Politiques de routage et de filtrage sortant, et configuration d'un VPN IPsec

Lorsque le pare-feu SNS est utilisé en tant que passerelle VPN, la bonne définition des routes et des règles de filtrage est critique pour garantir la confidentialité et l’intégrité des flux. Quatre fonctions sont fortement liées :

  • Le routage,

  • La politique de filtrage,

  • La NAT avant IPsec,

  • La politique IPsec.

Dans le cadre de la mise en œuvre de tunnels VPN IPsec, il est nécessaire d’avoir une route permettant de joindre les réseaux distants accessibles au travers des tunnels. Dans le cas contraire, le paquet est supprimé à l’étape de routage et n’atteint pas l’étape de chiffrement IPsec.

Pour éviter toute fuite de données, il est recommandé de configurer une route avec comme passerelle une IP fictive sur sa boucle locale, par exemple un objet de type machine ayant comme adresse 127.42.42.42. Cette technique est également appelée blackholing.

Après l’application de la politique IPsec, la politique de routage sera ré-évaluée en fonction du paquet chiffré. Cependant, en cas d’erreur sur la politique IPsec, les paquets seront détruits au lieu de sortir en clair.

Le séquencement des fonctions de routage, de filtrage, de NAT avant IPsec et de politique IPsec représenté sur l'image ci-dessous a un impact direct sur la confidentialité des flux. Ce séquencement n’est qu’une partie du cheminement complet du paquet dans le pare-feu SNS. En effet, lorsqu’il est chiffré, le paquet est ensuite traité par les fonctions de filtrage, de NAT après IPsec et de routage.

Il est indispensable d’écrire les règles les plus spécifiques pour la politique de filtrage et les règles les moins spécifiques pour la politique IPsec.

 

Briques fonctionnelles

 

R41 | SNS-SMC | Configurer les tunnels VPN IPsec de manière sécurisée
Lorsqu’un VPN IPsec est configuré, il est recommandé de :

  • Configurer une route statique à destination de la boucle locale (blackholing) pour joindre les réseaux distants accessibles au travers de tunnels VPN IPsec,

  • S’assurer que la politique IPsec n’est jamais désactivée y compris lors de phases transitoires,

  • S’assurer que les règles de filtrage sont toujours plus spécifiques que les règles de NAT avant IPsec,

  • S’assurer que les flux (adresse IP source et destination) après la translation (NAT) correspondent à la politique IPsec,

  • S’assurer qu’en l’absence de règles de NAT, les règles de filtrage sont toujours plus spécifiques que la politique IPsec.

ATTENTION
Idéalement, des pare-feux SNS distincts devraient être mis en œuvre afin de dissocier les fonctions de chiffrement, de filtrage des flux clairs et de filtrage des flux chiffrés.

Les exemples ci-dessous permettent d’illustrer l’intérêt de la recommandation précédente. Ils s’appliquent sur le pare-feu SNS en tant que passerelle VPN pour des flux en sortie du LAN local et à destination d’un LAN distant au travers d’un tunnel VPN IPsec établi avec une passerelle VPN distante. L’architecture est représentée sur l'image ci-dessous.

 

Schéma d’architecture

 

Dans chaque exemple sont données les configurations des briques fonctionnelles SNS traversées par un paquet réseau (image Briques fonctionnelles). Le paquet réseau entre avec une source et une destination spécifique. Les fonctions traversées sont, dans l’ordre :

  • Le pré-routage,

  • Le filtrage,

  • La NAT avant IPsec,

  • La politique IPsec.

Le résultat obtenu est décrit par le paquet de sortie, à savoir s’il est :

  • Chiffré,

  • Clair (non chiffré),

  • Détruit,

  • Filtré.

Un code couleur noir, rouge, vert est appliqué pour représenter respectivement : le cas nominal, le cas d’erreur (clair), le comportement après correction.

Pour chaque exemple, trois cas (C) sont représentés :

C1 Configuration ne respectant pas la recommandation, les paramètres d’entrée sont nominaux.
C2 Mise en évidence des problèmes liés à la configuration précédente. Une modification des entrées ou de la configuration est réalisée. Cette modification est repérée par l’utilisation d’un texte rouge.
C3 Configuration proposée afin de ne pas tomber dans le problème précédent. Cette modification est repérée par l’utilisation d’un texte rouge.

Politique IPsec toujours active

L’exemple représenté par l'image ci-dessous illustre la nécessité d’utiliser une route à destination de la boucle locale pour les réseaux IPsec distants. Dans le cas C1, les paquets passent en premier dans la table de routage. Elle contient une route valide vers le LAN distant (la route par défaut dans l’exemple traité). Ils passent ensuite dans la politique de filtrage qui accepte les paquets puis dans la politique IPsec qui se charge de l’encapsulation, du chiffrement et de la protection en intégrité des flux. La source et la destination des paquets chiffrés sont différentes de celles des paquets clairs. En particulier, la destination du paquet chiffré est la passerelle VPN distante. La table de routage est de nouveau traversée (la route à destination du LAN distant n’est pas utilisée, seule la route à destination de la passerelle VPN distante est utilisée), elle contient une route valide vers la passerelle IPsec (la route par défaut). Les paquets sont émis chiffrés.

 

Politique IPsec toujours active, route à destination de la boucle locale

 

La politique IPsec passe ensuite d’un état activé (C1) à un état désactivé (C2). L’état désactivé peut être permanent ou transitoire, ce dernier cas se produit lors de la désactivation puis de la réactivation de la politique IPsec.

Dans le cas C2, les paquets passent en premier dans la table de routage. Elle contient une route valide vers le LAN distant. Ils passent ensuite dans la politique de filtrage qui accepte les paquets. Cependant, aucune politique IPsec n’étant définie, les paquets sont envoyés en clair au prochain saut, c’est-à-dire par la passerelle par défaut définie dans la table de routage. Il y a fuite d’informations.

La solution présentée dans le cas C3 consiste à définir une route à destination de la boucle locale (prendre une adresse IP particulière facilite la maintenance de la configuration, par exemple 127.42.42.42), également appelée blackholing. En l’absence de politique IPsec, le paquet sera détruit par le pare-feu SNS au lieu d’être envoyé à la passerelle par défaut.

R41+ | SNS-SMC | Ne pas utiliser de route par défaut
Si l’ensemble des réseaux utilisés sont connus, il est recommandé de ne pas utiliser de route par défaut et de privilégier des routes explicites pour joindre l’ensemble des correspondants distants. Ainsi seuls les paquets ayant une route explicitement définie pourront sortir en clair.

ATTENTION
Les plans d’adressage doivent être choisis afin d’éviter toute confusion entre les réseaux rouges et noirs tels que mentionnés dans l'image Schéma d’architecture, et pour faciliter la création des routes.

Règles de filtrage toujours plus spécifiques que la politique IPsec

L’exemple représenté dans l'image ci-dessous illustre la nécessité de définir une politique de filtrage toujours plus spécifique que la politique IPsec. Dans le cas C1, la politique de filtrage est définie en /24 alors que la politique IPsec est en /32. L’administrateur désire, par exemple, définir un contexte cryptographique par couple d’adresses IP, tout en gardant une politique de filtrage commune. Dans un premier temps, seules deux machines communiquent entre elles. Les paquets traversent la politique de filtrage puis la politique IPsec et sont émis chiffrés.

 

Règles de filtrage toujours plus spécifiques que la politique IPsec

 

Dans le cas C2, un équipement est rajouté sur le réseau, la configuration du pare-feu SNS n’est pas modifiée. Les paquets à destination de cette nouvelle adresse IP sont acceptés par la politique de filtrage et non sélectionnés par la politique IPsec et les paquets sont donc émis en clair. Il y a fuite d’informations.

La correction mise en œuvre dans le cas C3 consiste à positionner une politique de filtrage en /32 et une politique IPsec en /24. La politique de filtrage est ainsi plus restrictive que la politique IPsec. Les paquets seront soit filtrés soit chiffrés mais ils ne pourront pas être émis en clair.

Lorsqu’une politique IPsec est utilisée afin d’interconnecter des réseaux, sa fréquence de modification doit être faible et les réseaux utilisés peuvent être étendus contrairement à une politique de filtrage pouvant être fréquemment modifiée et très spécifique.

Règles de NAT avant IPsec incluses dans la politique IPsec

L’exemple représenté dans l'image ci-dessous illustre la nécessité de définir des règles de NAT avant IPsec incluses dans la politique IPsec. Dans le cas C1, une règle de NAT avant IPsec est appliquée. Son résultat est un critère de sélection de la politique IPsec. Toute modification de cette règle a un impact direct sur la confidentialité des données. Les paquets sont acceptés par la politique de filtrage puis modifiés par la règle de NAT avant IPsec et enfin sélectionnés par la politique IPsec. Ils sont émis chiffrés.

 

Règles de NAT avant IPsec incluses dans la politique IPsec

 

Dans le cas C2, la règle de NAT avant IPsec est modifiée. Les paquets sont acceptés par la politique de filtrage puis modifiés par la règle de NAT avant IPsec. L’adresse IP de sortie est modifiée, elle n’est plus sélectionnée par la politique IPsec et les paquets sont donc émis en clair. Il y a fuite d’informations.

La solution présentée dans le cas C3 consiste à définir une politique IPsec plus large que la règle de NAT utilisée. Si l’adresse IP de sortie est modifiée, le paquet sera toujours sélectionné par la politique IPsec et sera chiffré par le pare-feu SNS.

INFORMATION
La règle de NAT doit s’accompagner d’une publication ARP si la ou les adresses utilisées n’appartiennent pas aux interfaces du pare-feu SNS.

Règles de filtrage toujours plus spécifiques que les règles de NAT avant IPsec

L’exemple représenté dans l'image ci-dessous illustre la nécessité de définir des règles de filtrage toujours plus spécifiques que les règles de NAT avant IPsec. Dans le cas C1, le réseau source de la règle de NAT avant IPsec est en /25 alors que le réseau source dans la règle de filtrage est en /24. Les paquets proviennent d’une adresse source incluse à la fois dans le /24 et dans le /25. Les paquets sont acceptés par la règle de filtrage, puis la règle de NAT avant IPsec est appliquée et enfin la politique IPsec. Les paquets sont émis chiffrés.

 

Règles de filtrage toujours plus spécifiques que les règles de NAT avant IPsec

 

Dans le cas C2, l’adresse IP source est incluse dans le /24 mais non incluse dans le /25. Les paquets sont acceptés par la politique de filtrage et non sélectionnés par les règles de NAT avant IPsec. La politique IPsec n’est pas appliquée et les paquets sont donc émis en clair. Il y a fuite d’information.

La correction mis en œuvre dans le cas C3 consiste à positionner une politique de filtrage en /32. La politique de filtrage est ainsi plus restrictive que les règles de NAT avant IPsec. Les paquets seront soit filtrés, soit chiffrés.