Configurer les profils IPsec Sophos Firewall en toute sécurité

Un profil IPsec détermine avec quel niveau de sécurité et dans quelles conditions un tunnel IPsec est négocié. Il définit la version IKE, le chiffrement, l’intégrité, le groupe DH, PFS, les Lifetimes, le Rekeying et Dead Peer Detection. Si ces valeurs ne correspondent pas à celles du pair, le tunnel reste down ou échoue plus tard lors du Rekeying.

Recommandation rapide pour les nouvelles connexions Site-to-Site : utiliser IKEv2, proposer uniquement les Proposals robustes réellement nécessaires, activer PFS et le Rekeying, puis configurer DPD selon le rôle du firewall. Si les deux pairs prennent en charge ces valeurs, AES256GCM16 avec DH19 et PFS19 constitue un point de départ moderne. Les exigences du fournisseur et du pair restent toutefois toujours prioritaires.

Cet article explique le profil. La connexion elle-même, avec Gateway, IDs, réseaux, règles, NAT et routage, est décrite dans Configurer un VPN IPsec Site-to-Site sur Sophos Firewall. Si un tunnel existant ne s’établit pas ou ne transporte aucun trafic, consulter Dépannage VPN IPsec sur Sophos Firewall.

Ce que contrôle un profil IPsec

Le profil contient les paramètres de sécurité communs à la Phase 1 et à la Phase 2. Un même profil peut être affecté à plusieurs connexions. C’est précisément pourquoi un profil système ou de production en cours d’utilisation ne doit pas être modifié spontanément : le changement peut affecter tous les tunnels associés lors du prochain établissement ou Rekeying.

Le profil ne contient pas :

l’adresse publique ou le FQDN du pair
le Preshared Key, le certificat ou la RSA Key
le Local ID et le Remote ID
les réseaux locaux et distants ou les Traffic Selectors
les règles de pare-feu, le NAT et le routage
l’adresse XFRM, la SD-WAN Route ou le chemin de failover

Ces valeurs se configurent dans la connexion IPsec ou dans les règles réseau associées. Un état Phase 1 vert ne prouve donc ni que la Phase 2 correspond, ni que le trafic utile est correctement routé et autorisé.

Authentication n’est pas identique à Authentication type

Dans un profil IPsec, Authentication désigne l’algorithme d’intégrité, tel que SHA2 256. Dans la connexion IPsec, Authentication type détermine si les pairs s’identifient avec un Preshared Key, un certificat ou une RSA Key.

Ces deux champs remplissent des fonctions différentes. Un SHA2 256 correct ne peut donc pas corriger un PSK erroné, et un certificat compatible ne compense pas une Proposal Phase 1 incompatible.

Phase 1 et Phase 2 expliquées

La Phase 1 établit l’IKE Security Association protégée. Les pairs s’authentifient sur ce canal de contrôle et négocient les autres clés et paramètres. La version IKE, le chiffrement, l’intégrité et le groupe DH doivent au minimum être compatibles.

La Phase 2 crée les Child ou IPsec Security Associations pour le trafic utile. Le chiffrement Phase 2, l’intégrité, PFS et les Traffic Selectors s’appliquent ici. Un tunnel peut donc terminer correctement la Phase 1 sans qu’aucune Child SA soit créée en raison d’une valeur PFS incorrecte ou d’une combinaison Phase 2 différente.

Avec IKEv2, la première Child SA peut être établie en même temps que l’IKE SA. Un problème de PFS ou de Rekeying peut ainsi n’apparaître que plusieurs heures plus tard, lorsque la Child SA doit être renouvelée. La validation n’est complète qu’après avoir observé au moins un Rekeying sans interruption.

Coordonner les paramètres avec le pair

Avant la configuration, les deux administrateurs conviennent des valeurs et les consignent par écrit. Une capture d’écran est souvent insuffisante, car les fournisseurs utilisent des noms différents pour une même fonction.

Il faut au minimum documenter les informations suivantes :

rôle : Initiator, Responder ou établissement depuis les deux côtés
version IKE et, pour IKEv1, Main ou Aggressive Mode
Phase 1 Encryption, Authentication et groupe DH
Phase 1 Key Life, Re-key Margin et randomisation
Phase 2 Encryption, Authentication, PFS et Key Life
Rekeying basé sur le temps et côté qui le lance
intervalle DPD et action lorsque le pair est injoignable
limites connues du fournisseur et Proposals autorisées

Le nom du profil ne doit pas nécessairement être identique sur les deux appareils. Il faut qu’au moins une combinaison complète soit compatible des deux côtés. Davantage de Proposals n’est pas automatiquement préférable : cela augmente la surface d’attaque et d’erreur et peut agrandir les paquets IKE au point que la fragmentation devienne problématique.

Choisir une configuration initiale sûre

Les exemples suivants sont des points de départ Avanet pour les nouvelles connexions Site-to-Site. Ils ne remplacent pas les exigences d’Azure, d’AWS, d’un opérateur ou d’un firewall tiers.

Profil moderne pour des pairs contrôlés

Si les deux côtés prennent en charge des algorithmes actuels :

Key exchange: IKEv2
Phase 1: AES256GCM16, DH19
Phase 2: AES256GCM16, PFS19
Re-key connection: On
Use strict profile: On
Compression: Off
SHA2 96-bit truncation: Off
Dead peer detection: On

AES256GCM16 est un algorithme AEAD : il assure le chiffrement et la protection de l’intégrité en une seule opération. Cette combinaison ne sélectionne aucun algorithme Authentication supplémentaire tel que SHA2. GCM16 désigne l’Authentication Tag de 16 octets, et non un chiffrement de 16 bits.

La Pseudo-Random Function utilisée pour générer les clés IKE ne peut pas être sélectionnée séparément dans SFOS. Le firewall la déduit des algorithmes d’intégrité proposés et la coordonne avec le pair.

DH19 utilise une courbe elliptique et offre un bon compromis entre niveau de sécurité, taille des paquets et charge de calcul. AES128GCM16 reste également un algorithme actuel et n’est pas automatiquement peu sûr pour un niveau de sécurité normal de 128 bits. La solidité globale dépend toujours du composant le plus faible du profil.

Profil de compatibilité pour des pairs tiers actuels

Si le pair ne prend en charge ni AES-GCM ni un groupe ECP, cette combinaison constitue un point de départ plus largement compatible :

Key exchange: IKEv2
Phase 1: AES256, SHA2 256, DH14
Phase 2: AES256, SHA2 256, PFS14
Re-key connection: On
Dead peer detection: On

AES fonctionne ici en mode CBC et nécessite donc la protection d’intégrité distincte SHA2 256. DH14 et PFS14 sont des choix de compatibilité, pas la variante moderne privilégiée lorsque les deux pairs prennent en charge DH19.

À éviter pour les nouveaux profils

Pour les nouveaux designs, éviter IKEv1, Aggressive Mode, DES, 3DES, Blowfish, MD5, SHA1 et les groupes DH 1, 2 et 5. PFS: None doit également rester une exception documentée pour les pairs qui ne prennent pas en charge PFS.

Malgré sa présence dans le champ Phase 2 Encryption, AES-GMAC ne fournit aucun chiffrement, mais uniquement l’authentification et l’intégrité. Un tunnel Site-to-Site confidentiel normal utilise donc AES-GCM ou AES avec un algorithme SHA2 approprié.

Les exceptions Legacy sont documentées avec leur motif, le pair concerné, le risque, l’Owner et la date de remplacement. Une combinaison faible ne doit pas rester aux côtés de Proposals robustes uniquement parce que le tunnel peut également s’établir avec elle. La BSI TR-02102-3 sur IPsec et IKEv2 et le guide NIST sur les VPN IPsec fournissent des orientations techniques.

Lorsqu’un environnement doit respecter des exigences cryptographiques formelles, la procédure dédiée explique comment le mode FIPS 140-3 sur Sophos Firewall affecte les plateformes, les profils, les certificats, les sauvegardes et HA. La conformité FIPS ne remplace pas le choix délibéré d’une proposal commune et moderne.

Cloner ou créer un profil

Chemin de menu :

Profiles > IPsec profiles

Pour les connexions Sophos-to-Sophos, les profils système associés constituent des modèles compréhensibles :

Branch office (IKEv2) pour la filiale initiatrice
Head office (IKEv2) pour le siège répondant

Cloner le profil approprié et lui donner un nom clair, par exemple Branch-Zurich-IKEv2. Le profil système reste ainsi inchangé et l’ancien profil du tunnel peut être réaffecté lors d’un Rollback.

General settings

Key exchange : utiliser IKEv2 pour les nouvelles connexions Site-to-Site. Utiliser IKEv1 uniquement pour un pair Legacy documenté.
Authentication mode : existe uniquement avec IKEv1. Ne pas utiliser Aggressive Mode, car les informations d’authentification sont moins protégées pendant la transmission.
Key negotiation tries : Sophos recommande 0. Pour un VPN Failover Group, SFOS définit toutefois la valeur effective sur 3.
Re-key connection : activer cette option afin de négocier de nouvelles clés Phase 1 et Phase 2 avant leur expiration. SFOS prend uniquement en charge le Rekeying basé sur le temps.
Use strict profile : activer cette option lorsque les Proposals du pair sont connues exactement. SFOS propose alors uniquement les paramètres configurés. Pour les profils de fournisseur, vérifier d’abord leurs exigences ; l’exemple AWS officiel n’utilise par exemple pas cette option.
Pass data in compressed format : laisser cette option désactivée dans des conditions normales. L’activer uniquement lorsque son intérêt et sa prise en charge des deux côtés sont confirmés.
SHA2 with 96-bit truncation : activer cette option uniquement pour une exigence de compatibilité documentée, pas comme amélioration générale de la sécurité.

Use strict profile réduit les Fallbacks inattendus et peut aider lorsque des Proposals IKE trop volumineuses posent problème. Il ne s’agit toutefois pas d’une option à activer sans contrôle dans chaque profil de fournisseur.

Phase 1

La Phase 1 contient Key life, Re-key margin, Randomize re-keying margin by, le groupe DH et jusqu’à trois paires d’algorithmes Encryption et Authentication.

SFOS accepte de 120 à 86400 secondes pour Key Life, de 30 à 999 secondes pour Re-key Margin et de 0 à 100 pour cent pour la randomisation. Une valeur formellement admise n’est pas automatiquement pertinente : la Margin doit rester nettement inférieure à la Key Life et correspondre au comportement du pair.

Saisir uniquement les groupes DH et Proposals réellement nécessaires. Le problème connu NC-136352 peut survenir lorsqu’un profil IKEv2 par défaut propose tellement de groupes DH que le paquet IKE dépasse 1'500 octets. Si un composant intermédiaire rejette les fragments, l’Initiator envoie les paquets à plusieurs reprises alors que le Responder ne voit rien. Pour un pair connu, un seul groupe DH confirmé constitue la configuration la plus propre.

Phase 2

La Phase 2 contient PFS, Key Life, Encryption et Authentication pour le trafic utile.

PFS impose un nouvel échange de clés DH lors du Rekeying Phase 2. Si une clé à long terme est compromise ultérieurement, cela doit empêcher le déchiffrement d’anciennes sessions enregistrées avec le même matériel de clés. Il faut donc activer PFS et choisir une valeur compatible avec le pair. Dans les profils modernes, le groupe PFS correspond souvent au groupe DH Phase 1.

Choisir une Key Life Phase 2 plus courte que la Key Life Phase 1. Les clés du trafic utile sont ainsi renouvelées plus fréquemment que le canal de contrôle IKE.

Dead Peer Detection

DPD détecte un pair qui ne répond plus. Il ne remplace ni Gateway Monitoring ni un véritable test d’application.

Filiale ou Initiator : Re-initiate, afin que le firewall tente immédiatement une nouvelle connexion après un DPD Timeout.
Siège ou Responder : Disconnect, afin de fermer la connexion obsolète. Hold constitue une alternative délibérée lorsque les Traffic Selectors doivent être conservés et que la renégociation ne doit commencer qu’à l’arrivée de nouveau trafic.
Check peer after every : intervalle de contrôle en secondes.
Wait for response up to : s’applique uniquement à IKEv1. Avec IKEv2, SFOS utilise son IKE Retransmission Timeout interne ; la valeur saisie ne modifie pas ce comportement.

Pour les groupes de failover IPsec, SFOS désactive DPD sur les connexions affectées et définit Key negotiation tries sur 3. La condition du groupe assure alors la surveillance. Le guide associé explique l’ordre, la Failover Condition et Automatic failback ; la vue du Profile ne montre pas à elle seule l’intégralité du comportement de Failover effectif.

Bien comprendre Lifetimes et Rekeying

Key life n’est pas un Session Timeout ni un Idle Timeout. Elle limite la durée de vie d’une Security Association. Avant son expiration, la négociation de nouvelles clés commence dans la Re-key Margin.

Des Lifetimes plus courtes renouvellent les clés plus fréquemment, mais entraînent davantage de charge de calcul et d’occasions d’erreurs d’interopérabilité ou de Rekeying. Des Lifetimes plus longues réduisent cette charge, mais utilisent le matériel de clés plus longtemps. Ni la valeur admise la plus courte ni la plus longue ne constitue donc automatiquement le meilleur choix.

NIST cite 86400 secondes pour l’IKE SA et 28800 secondes pour l’IPsec SA comme orientation courante. Sophos et les fournisseurs Cloud utilisent d’autres valeurs selon le rôle et la plateforme. Ces chiffres ne constituent donc pas un profil SFOS universel.

Sophos recommande les mesures suivantes pour éviter les collisions de Rekeying :

La Key Life de l’Initiator est plus courte que celle du Responder.
La Key Life Phase 2 des deux firewalls est plus courte que la Key Life Phase 1.
Le Rekeying est activé sur au moins un côté et utilise explicitement un Rekeying basé sur le temps avec les appareils tiers.

La randomisation modifie la Re-key Margin, pas l’ensemble de la Key Life. Avec une Key Life de huit heures, une Margin de dix minutes et une randomisation de 20 pour cent, Sophos indique que le Rekeying commence entre 7 heures 48 minutes et 7 heures 52 minutes.

Pour les fournisseurs, utiliser leurs valeurs exactes. L’exemple AWS documenté utilise environ 28000 pour la Phase 1, une Re-key Margin de 360, une randomisation de 50 et 3600 secondes pour la Phase 2 sur Sophos Firewall. Il s’agit d’un exemple AWS, pas d’une valeur Avanet par défaut générale.

Affecter et tester le profil en toute sécurité

Pendant une fenêtre de maintenance, affecter d’abord le nouveau profil uniquement à la connexion prévue. Documenter le nom du profil, les anciennes valeurs et le Rollback avant la modification.

Pour Site-to-Site, l’affectation s’effectue sous :

Site-to-site VPN > IPsec

Remote Access IPsec utilise également des profils, mais impose d’autres limites : la configuration Sophos Connect actuelle accepte les profils IKEv1 avec DPD désactivé ou défini sur Disconnect. Le profil IKEv2 Site-to-Site moderne ne doit donc pas être réutilisé sans contrôle pour Remote Access. La procédure complète est décrite dans Configurer Sophos Connect sur Sophos Firewall. Le cas particulier OTP/Rekeying est expliqué dans Sophos Connect interrompt la connexion après environ quatre heures.

Après l’établissement, contrôler en lecture seule l’état et les derniers messages IKE dans l’Advanced Shell :

ipsec statusall
tail -n 200 /log/strongswan.log

Tester ensuite du trafic réel dans les deux sens. Les compteurs d’octets de la Child SA doivent augmenter. Répéter le test après au moins un Rekeying Phase 2 ; ce n’est qu’alors que les Lifetimes, PFS et le comportement de Rekeying sont réellement validés.

Causes typiques selon le symptôme :

Le tunnel reste entièrement down : vérifier la version IKE, Phase 1 Encryption, Authentication, DH, Strict Profile, ID et l’authentification du pair.
NO_PROPOSAL_CHOSEN avant la Phase 1 : comparer les Proposals Phase 1.
La Phase 1 est établie, mais la Child SA manque : vérifier Phase 2 Encryption, Authentication, PFS et les Traffic Selectors.
Déconnexion après un intervalle similaire : comparer Key Life, Re-key Margin, randomisation et valeurs de l’Initiator et du Responder.
Le tunnel est vert, mais aucun trafic ne passe : ne pas modifier d’abord le profil ; vérifier les règles de pare-feu, le NAT, le routage, le chemin retour et les compteurs d’octets.

Si la modification pose problème, réaffecter à la connexion l’ancien profil documenté. Aucun service, aucune base de données et aucune configuration Advanced Shell ne doit être modifié pour un Rollback normal du profil.