Activer FIPS 140-3 sur Sophos Firewall

Sophos Firewall prend en charge le mode FIPS 140-3 Level 1 sous SFOS 22 sur les XGS Appliances, les plateformes virtuelles compatibles, AWS et Azure. Son activation n’est pas une modification de configuration ordinaire : la commande effectue une réinitialisation aux paramètres d’usine, redémarre le firewall avec la configuration d’usine et exige ensuite une nouvelle configuration conforme à FIPS.

La séquence sûre est donc la suivante :

1. Confirmer la plateforme, le firmware et l’exigence de conformité.
2. Inventorier les pairs VPN, les certificats et les algorithmes nécessaires.
3. Conserver la sauvegarde, la Secure Storage Master Key et la documentation de configuration dans un emplacement externe.
4. Planifier une fenêtre de maintenance, un accès à la console locale et une reconstruction complète.
5. Activer FIPS uniquement sur un firewall encore autonome.
6. Reconstruire la configuration de base et de production avec des algorithmes autorisés.
7. Valider complètement l’administration, le routage, les règles, les VPN, les certificats et les journaux.
8. Configurer HA seulement ensuite.

⚠️ Avertissement : system certification fips enable supprime la configuration actuelle. La commande ne doit pas être exécutée sans plan de migration approuvé, accès à la console locale et reconstruction planifiée.

Ce que signifie FIPS 140-3 sur Sophos Firewall

FIPS 140-3 est une norme des États-Unis relative aux modules cryptographiques. SFOS 22.0 GA et ses versions de maintenance utilisent des modules cryptographiques certifiés FIPS. L’activation du mode FIPS limite en outre les algorithmes sélectionnables, crée des stratégies par défaut adaptées et valide les certificats nouvellement créés ou importés par rapport aux exigences FIPS.

L’aide FIPS pour SFOS 23 reprend l’affirmation concernant SFOS 22.0 GA et ses versions de maintenance. Cela ne confirme pas à lui seul la certification d’un build SFOS 23. Pour une validation formelle, les responsables de la conformité doivent confirmer le build cible réel, le module cryptographique utilisé et le justificatif de validation correspondant ; l’activation du mode ne constitue pas une preuve de certification de l’ensemble du firewall.

La conformité FIPS est une exigence d’exploitation formelle et ne correspond pas automatiquement à la configuration la plus robuste disponible aujourd’hui. Par exemple, la documentation Sophos autorise SHA1 dans les limites FIPS pour certains cas d’authentification VPN. Pour les nouveaux designs IPsec, IKEv2 et des algorithmes modernes convenus avec le pair restent le meilleur point de départ. Comprendre et créer des profils IPsec Sophos Firewall explique les champs et les décisions de sécurité.

Vérifier les plateformes prises en charge

Sophos prend en charge le mode FIPS sur :

• les XGS Appliances
• VMware vSphere
• Microsoft Hyper-V
• KVM
• Xen
• AWS
• Azure

Il n’est pas pris en charge sur :

• les Software Appliances
• le matériel XG Series
• le matériel SG Series

Cette distinction est importante : une appliance virtuelle est prise en charge, contrairement à une Software Appliance installée sur du matériel x86 personnalisé. Sophos Firewall : matériel, virtuel ou cloud ? explique les modèles d’exploitation.

Arrêter l’opération si le modèle, la plateforme ou la version cible ne sont pas clairement pris en charge. La présence d’un réglage FIPS ou d’une commande CLI exécutable ne remplace pas la validation de la plateforme.

Inventorier les effets avant d’activer FIPS

Pairs VPN et algorithmes

Avant la réinitialisation, tous les VPN de production doivent être documentés avec les paramètres qu’ils négocient réellement. En mode FIPS, les algorithmes suivants sont notamment disponibles pour les nouvelles configurations VPN :

• groupes DH 14 à 21
• AES-CBC et AES-GCM en 128, 192 ou 256 bits
• clés RSA de 2048 bits et plus, bien que Sophos classe uniquement 2048 et 3072 comme conformes à FIPS
• courbes EC sur corps premier de 224 bits et plus
• SHA1, SHA256, SHA384 et SHA512 pour l’authentification VPN
• Preshared Keys d’au moins 14 octets
• TLS 1.2 et 1.3

Pour IPsec, DH 1, 2, 5 et 25 à 30, DES/3DES, Blowfish, Twofish, Serpent et MD5 ne sont pas disponibles. DH 31 peut être sélectionné, mais Sophos indique alors que la connexion n’est pas conforme à FIPS. Les digests MD5 et SHA1 ne sont pas autorisés pour les certificats.

La longueur minimale de la PSK de 14 octets ne signifie pas qu’il suffit de 14 caractères quelconques. Une nouvelle PSK aléatoire composée de caractères ASCII facilite une vérification sans ambiguïté de la longueur, car chaque caractère correspond alors à un octet. La longueur minimale seule ne garantit en rien la robustesse d’un mot de passe prévisible. Convenir de la PSK avec le pair par un canal protégé et ne pas la consigner dans les rapports de validation ni dans les journaux.

Le pair technique doit prendre en charge au moins une combinaison complète et commune de phase 1 et de phase 2. Cette règle s’applique aussi aux anciennes appliances, aux VPN de fournisseurs et aux passerelles cloud. En l’absence de combinaison commune, aucune improvisation ne doit avoir lieu pendant la fenêtre de maintenance. Le pair doit d’abord être adapté, sinon le projet FIPS est arrêté.

Pour IPsec en accès distant sous Remote access VPN > IPsec > Authentication type, seuls les certificats conformes à FIPS sont autorisés ; External CA ne peut pas être sélectionné comme certificat distant. Cette exigence s’applique aussi à l’accès distant L2TP avec authentification par certificat et au certificat du serveur SSL sous Site-to-site VPN > SSL VPN > SSL VPN global settings. L’assistant IPsec propose des paramètres conformes à FIPS. Avant la migration, vérifier l’attribution réelle des certificats de chaque connexion, pas seulement la taille de clé et le digest. Utiliser IKEv1 uniquement sur les systèmes anciens et avec des algorithmes approuvés FIPS ; utiliser IKEv2 pour les nouvelles installations.

Sophos décrit l’utilisation de la bibliothèque cryptographique certifiée FIPS pour l’établissement des tunnels IPsec en phase 1 et pour SSL VPN en phases 1 et 2. Ne pas en déduire une certification globale du déploiement VPN entier ou d’une version cible SFOS quelconque.

Ne pas présumer l’existence d’une stratégie L2TP par défaut

L’aide FIPS contient deux affirmations contradictoires pour SFOS 22 et 23 : d’une part, elle décrit une stratégie L2TP par défaut utilisant SHA1 au lieu de MD5 ; d’autre part, elle indique que les appareils FIPS n’ont pas de stratégie L2TP par défaut. Il n’est donc possible d’en déduire ni son existence ni la présence d’un réglage par défaut sûr. Si L2TP est nécessaire, vérifier avant la migration en production la stratégie réellement présente et les valeurs d’authentification autorisées pour le build cible, puis clarifier le comportement avec le support Sophos si nécessaire. Ne pas compenser l’absence de stratégie par MD5 ou un autre algorithme non autorisé. Le service L2TP n’est mis en service qu’après une validation réussie ; tant que la stratégie n’est pas clarifiée, cette migration reste arrêtée.

SSL VPN et Amazon VPC

Pour SSL VPN, BF-CBC, 3DES, MD5 et la taille de clé 1024 ne sont pas disponibles. Un profil SSL VPN site-to-site protégé par mot de passe provenant d’un firewall FIPS n’est pas interchangeable avec les versions SFOS antérieures à 18.5 MR2, et inversement.

Une connexion Amazon VPC en mode FIPS doit utiliser Use VPC configuration file. Use AWS security credentials reste visible, mais Sophos indique que la connexion échoue. La configuration VPC importée doit aussi être adaptée pour utiliser des algorithmes DH et de chiffrement conformes à FIPS.

Certificats et CAs

En mode FIPS, le firewall génère les certificats avec la bibliothèque cryptographique certifiée et vérifie que les certificats et CAs chargés utilisent des algorithmes autorisés. Documenter auparavant :

• quels certificats utilisent une clé RSA ou EC
• quels algorithmes de digest figurent dans la chaîne
• quels services IPsec, SSL VPN, portail, WAF et SMTP référencent un certificat
• si les clés privées, les chaînes de CAs et les mots de passe sont disponibles pour la reconstruction

Un certificat doté d’une clé formellement autorisée peut néanmoins échouer en raison de son nom, de sa durée de validité ou d’une chaîne de confiance incomplète. Importer et attribuer des certificats sur Sophos Firewall explique le processus.

Préparer la sauvegarde et la reconstruction

Avant l’activation, conserver dans un emplacement externe :

• une sauvegarde chiffrée actuelle
• le mot de passe de sauvegarde et la Secure Storage Master Key utilisée à l’époque
• Entities.xml comme référence de configuration lisible
• la documentation des interfaces, VLAN, routage, NAT et règles firewall
• les profils VPN, les pairs, les IDs, les attributions de certificats et les responsables des PSK
• Device Access, le FQDN d’administration, DNS, NTP et les données de licence
• le design HA, le Cluster ID, le Peer Admin Port et le câblage
• les tests de validation et un critère d’abandon clair

Créer ou restaurer une sauvegarde Sophos Firewall explique la relation entre sauvegarde, SSMK, compatibilité de restauration et validation. Sophos Firewall Config Studio permet également de créer un rapport de configuration structuré.

Activer FIPS sur un firewall autonome

Conditions d’arrêt avant la commande

Ne pas continuer tant que l’un des points suivants reste ouvert :

• aucun objectif de conformité confirmé ou aucune autorisation pour la réinitialisation
• la plateforme ou le firmware n’est pas clairement compatible avec FIPS
• le firewall fait encore partie d’un cluster HA
• aucune console locale ni voie d’administration indépendante équivalente n’est disponible
• la sauvegarde, son mot de passe ou la SSMK manque
• un pair VPN de production ne prend en charge aucune combinaison FIPS commune
• les certificats ou clés privées nécessaires à la reconstruction manquent
• la reconstruction et les tests de validation ne tiennent pas dans la fenêtre de maintenance

FIPS ne peut pas être activé ou désactivé tant que HA est actif. Un cluster existant ne doit pas être démantelé spontanément pendant la même opération. Sa suppression, sa réinitialisation et sa reconstruction nécessitent un plan de migration séparé et approuvé.

Exécuter la commande

Avant d’autoriser l’opération, relever le mode actuel dans la Device Console avec la commande de lecture system certification fips show. Si FIPS est déjà actif, enable ne sert pas de contrôle : ne pas répéter l’étape d’activation destructive, mais vérifier la configuration existante. Pour l’accès initial, vérifier au préalable que la voie d’accès à la console adaptée à la plateforme est réellement accessible ; pour une VM ou un déploiement cloud, il s’agit de la console indépendante de la plateforme, et non d’une connexion SSH passant par la voie d’administration qui sera ensuite réinitialisée.

Exécuter la commande suivante dans la Device Console :

system certification fips enable

Le firewall redémarre avec les paramètres d’usine. L’ancienne IP d’administration et la configuration de production ne sont alors plus garanties accessibles. L’accès suivant passe par la voie d’accès initiale locale préparée.

Ne pas redémarrer plusieurs fois, importer aveuglément l’ancienne configuration ni utiliser de modifications shell non documentées. Rétablir d’abord la configuration initiale, la voie d’administration, l’heure, DNS et la licence.

Vérifier l’état

Pour afficher le mode actuel :

system certification fips show

Consignez le résultat avec l’appareil, le build SFOS et l’heure. Device Console répertorie également une option pour désactiver FIPS, mais l’aide FIPS officielle ne documente pas de bout en bout ses effets ni la séquence de restauration. N’en déduisez aucune procédure de commande. Faites appel au support Sophos pour désactiver FIPS ou si le comportement d’une restauration reste incertain, avec la plateforme, le build, l’état HA et les métadonnées de sauvegarde.

Reconstruire une configuration conforme à FIPS

La reconstruction suit une séquence contrôlée :

1. Configurer l’IP d’administration, l’accès administratif, DNS, NTP et l’heure actuelle.
2. Documenter à nouveau le build du firmware et la plateforme.
3. Créer les zones, interfaces, VLAN et routes, puis les tester localement.
4. Importer les certificats et chaînes de CAs sans contourner les algorithmes refusés.
5. Créer les profils IPsec et SSL VPN uniquement avec des valeurs autorisées.
6. Transférer progressivement les règles firewall, NAT, WAF et de messagerie.
7. Configurer Device Access, MFA, la journalisation, les notifications et l’intégration Central.
8. Valider chaque service de production avant de passer au suivant.

Le firewall génère des stratégies par défaut avec des paramètres adaptés en mode FIPS ; la stratégie L2TP par défaut, dont la documentation est contradictoire, ne doit expressément pas être considérée comme un point de départ garanti. Un réglage par défaut compatible FIPS ne confirme toutefois pas la compatibilité d’un pair externe ou d’un objet importé.

Configurer HA uniquement après FIPS

Pour un nouveau cluster HA, FIPS est d’abord activé sur le firewall Primary prévu, qui est ensuite entièrement reconfiguré. HA n’est créé qu’après cette étape. Sophos active automatiquement FIPS sur le firewall Auxiliary pendant la configuration HA.

Tant que HA est actif, FIPS ne peut être activé ni désactivé sur aucun des deux appareils. Si HA est désactivé ultérieurement, l’état FIPS de chaque appareil reste inchangé.

Avant Initiate HA, vérifier :

• Le Primary fonctionne de manière stable en mode FIPS.
• L’Auxiliary est préparé comme plateforme compatible avec le même build.
• Les modèles, les ports, les licences et le lien HA satisfont aux exigences HA normales.
• Une sauvegarde et une validation FIPS complète du Primary sont disponibles.
• La fenêtre de maintenance comprend la création HA, la synchronisation et un test de failover.

Configurer la haute disponibilité Sophos Firewall fournit le processus complet. LINCE suit une autre séquence et ne doit pas être confondu avec FIPS : LINCE doit être aligné sur les deux appareils autonomes avant HA, tandis que Sophos transfère FIPS du Primary vers l’Auxiliary pendant la configuration HA. La limite de certification, l’interruption SSH et la procédure sûre sont décrites dans Comprendre et activer le mode LINCE sur Sophos Firewall.

Valider la migration

Cryptographie et configuration

• La modification FIPS est visible dans Log Viewer et, si le modèle les prend en charge, dans les rapports locaux. Les XGS 87/87w et XGS 88/88w ne prennent pas en charge les rapports locaux ; sur ces modèles, effectuer ce contrôle dans Log Viewer.
• Les algorithmes non autorisés ne sont plus disponibles dans les nouvelles configurations VPN et de certificats.
• Les certificats, les CAs, les clés privées, les SANs et la chaîne de confiance sont complets.
• Les tunnels IPsec et SSL VPN négocient les valeurs attendues.
• Un tunnel vert est confirmé par un trafic applicatif bidirectionnel réel.

Réseau et services

• WebAdmin n’est accessible que par la voie d’administration prévue.
• Le routage, SD-WAN, DNS et NTP fonctionnent.
• Les règles firewall et NAT correspondent à la Rule ID attendue.
• WAF, SMTP TLS, les portails et l’accès distant présentent les bons certificats.
• Le monitoring, les notifications, les sauvegardes et l’intégration Central fonctionnent.
• Avec HA, l’état, la synchronisation, le failover et le retour sont testés séparément.

Le build, l’heure, l’événement FIPS, les proposals VPN testées, les fingerprints des certificats et les résultats des connexions réelles sont consignés comme preuves. L’absence d’un champ dans une interface ou un seul ping réussi ne suffit pas comme preuve globale.

Évaluer les sauvegardes et le firmware

Après une reconstruction réussie, créer une nouvelle sauvegarde en état FIPS et la stocker de manière protégée avec le mot de passe, la SSMK, le build et le rapport de validation. Lorsqu’elle est restaurée sur une version compatible prenant en charge FIPS, la sauvegarde applique son état FIPS. Une sauvegarde dans laquelle FIPS est désactivé restaure donc un état dans lequel FIPS est désactivé. Sur une version qui ne prend pas en charge FIPS, le mode n’est pas disponible, quel que soit l’état enregistré dans la sauvegarde.

Une sauvegarde n’est donc pas une simple copie neutre des règles. Avant la restauration, confirmer séparément l’état FIPS de la sauvegarde et sa prise en charge par le build cible, puis faire approuver les conséquences sur la conformité. Ne pas utiliser la sauvegarde non-FIPS créée avant l’activation comme raccourci pour la reconstruction FIPS : une restauration réussie ne remplace ni la conformité FIPS des objets ni une nouvelle vérification du mode et de tous les services.

Sophos documente un cas limité de rollback : si FIPS est activé après une migration ou une mise à niveau, le firewall peut revenir à la version précédente où FIPS était désactivé, à condition que sa configuration reste disponible. Ce n’est ni une garantie générale de downgrade ni un moyen de restaurer la configuration FIPS actuelle sur n’importe quelle ancienne version. Vérifier d’abord le build cible, la configuration conservée, le chemin de mise à niveau, la sauvegarde, le mot de passe et la SSMK, puis faire approuver le chemin de reprise. Ne pas en déduire une commande de désactivation improvisée ; les limites de support et de HA décrites plus haut restent applicables.

Un firmware FIPS actif bloque le chargement d’un firmware qui ne prend pas en charge FIPS. Cette protection ne doit pas être contournée par un changement de mode non planifié. Les Release Notes, le chemin de mise à niveau, une sauvegarde et le test des dépendances cryptographiques restent obligatoires avant chaque mise à niveau.

FAQ