Configurer et tester l’IPS de Sophos Firewall en toute sécurité

Le système de prévention des intrusions (IPS) analyse le trafic réseau à la recherche de schémas d’attaque connus, d’exploits et de caractéristiques de protocole inhabituelles. Pour que l’IPS assure effectivement une protection, il doit être activé globalement. En outre, la règle de pare-feu qui traite le flux de données doit utiliser une stratégie IPS adaptée.

La démarche sûre et rapide consiste à vérifier la licence et les patterns, à activer l’IPS, à choisir une stratégie en fonction du système à protéger, à l’affecter à la bonne règle de pare-feu, puis à valider le chemin de données avec un petit groupe pilote. Appliquer la stratégie la plus stricte à chaque règle n’offre pas automatiquement la meilleure protection. Un choix inadapté génère des détections, une charge ou des perturbations inutiles et complique l’analyse des événements pertinents.

PHP2Shell : vérifier séparément la détection et les correctifs

Pour PHP2Shell (CVE-2026-109618 et CVE-2026-109619), l’avis Sophos, version 4 du 22 octobre 2026, décrit des signatures IPS disponibles depuis cette date pour Firewall et Endpoint afin de détecter les tentatives d’exploitation. Cela ne constitue ni une garantie générale de blocage ni une protection WAF spécifique. Les environnements d’exécution PHP concernés doivent être mis à jour indépendamment de ces signatures.

Sur le pare-feu, contrôler le téléchargement réussi des patterns IPS, la règle réellement utilisée par le trafic concerné, sa stratégie IPS et l’action effective de la signature. Les sections de diagnostic ci-dessous détaillent ces contrôles. Corréler chronologiquement les journaux du pare-feu et du serveur ; sans alerte, il est impossible de démontrer l’installation d’un correctif ou l’absence d’attaque. Une véritable requête d’exploitation ne convient pas comme test en production.

Vérifier les prérequis et l’état de la licence

Avant de commencer la configuration, les éléments suivants sont nécessaires :

• un abonnement Network Protection actif ou une licence d’évaluation valide ;
• des signatures IPS disponibles et des mises à jour de patterns opérationnelles ;
• la Firewall Rule ID de la règle qui traite réellement le trafic concerné ;
• la journalisation de la règle afin de corréler la session, la règle de pare-feu et l’événement IPS ;
• une personne responsable, des tests définis et une procédure de retour arrière en cas de faux positif.

IPS Protection est désactivée par défaut. Sur un pare-feu en ligne, les signatures IPS ne sont mises à jour que si la licence est valide et que l’IPS est activé. Les pare-feu sous licence en environnement isolé (Air Gap) constituent l’exception documentée : ils peuvent recevoir les signatures IPS via la procédure de mise à jour prévue, même lorsque l’IPS est désactivé. L’article Licences Air Gap et mises à jour de patterns détaille ces différences.

Après l’expiration d’un abonnement Network Protection, le commutateur IPS peut encore sembler actif alors que le pare-feu n’applique plus la protection IPS. La licence d’évaluation se comporte différemment : à son expiration, l’IPS se désactive automatiquement. Lorsque l’IPS est désactivé, les signatures en ligne ne sont plus téléchargées et il n’est plus possible de configurer les stratégies ni les signatures personnalisées. Après 30 jours dans cet état, SFOS supprime les signatures et les règles IPS. Pour conserver la configuration, il faut auparavant l’exporter ou créer une sauvegarde.

Même lorsque l’IPS est désactivé, les stratégies IPS existantes peuvent toujours être affectées aux règles de pare-feu. Cette affectation ne prouve ni que l’inspection est active ni que la protection est effective. Si l’abonnement payant a expiré et que l’IPS est désactivé, ou si l’expiration d’une licence d’évaluation a automatiquement désactivé l’IPS, il faut d’abord activer un abonnement Network Protection avant de pouvoir réactiver l’IPS. Après l’activation, vérifier à nouveau le commutateur IPS et les signatures.

Même un abonnement valide n’assure pas une protection illimitée sans contact avec le service de licences. Les pare-feu en ligne synchronisent normalement leurs licences toutes les 24 heures. Si la synchronisation échoue pendant 90 jours consécutifs, SFOS désactive les abonnements de sécurité ; ce délai est de 180 jours avec une licence Air Gap. Les connexions à l’interface et le trafic peuvent alors continuer à fonctionner, mais sans la protection des abonnements désactivés. L’état de la licence doit donc faire partie du diagnostic lorsque l’IPS semble configuré, mais ne produit aucun effet.

Sous Backup & firmware > Pattern updates, SFOS affiche notamment les états Ready to install, Downloading, Success et Failed. Update pattern now lance la mise à jour des définitions de patterns standard. Une entrée réussie pour Application Signatures ne prouve pas que les signatures IPS ont également été téléchargées : sur les systèmes en ligne, celles-ci nécessitent toujours une licence valide et l’activation de l’IPS.

Activer l’IPS et définir le chemin de données

1. Ouvrir Intrusion prevention > IPS policies.
2. Activer IPS Protection.
3. Sous Backup & firmware > Pattern updates, contrôler la date, l’heure et l’état des patterns IPS.
4. Documenter l’état initial de IPS Protection, la Firewall Rule ID du flux pilote, la stratégie IPS précédente, Log firewall traffic et les exceptions existantes.

L’activation ou la désactivation de Firewall Acceleration ou de PKI Acceleration redémarre l’IPS ou le moteur DPI. Ces changements ne font pas partie de cette procédure d’activation. Lorsqu’un problème reproductible concerne un paramètre global du moteur, l’article Vérifier les paramètres IPS globaux en toute sécurité précise quels changements s’appliquent immédiatement, lesquels nécessitent une validation avec Apply ou un redémarrage, et comment conserver la valeur initiale.

Le système à protéger détermine la stratégie

Target désigne le côté dont une signature protège le logiciel vulnérable. Il ne correspond pas simplement à la Source Zone ou à la Destination Zone. Pour un navigateur qui reçoit une réponse spécialement conçue, la cible peut par exemple être Client ; pour un serveur web publié qui reçoit une requête malveillante, elle peut être Server.

Le choix repose sur trois questions :

1. Dans le flux considéré, quel est le système à protéger : le client ou le serveur ?
2. Quelles plateformes, quels protocoles et quels services y sont réellement utilisés ?
3. Une stratégie existante couvre-t-elle ce périmètre sans inclure des groupes de signatures sans rapport avec le besoin ?

Pour un chemin Internet client classique, une stratégie Client ou LAN-to-WAN adaptée constitue le point de départ. Dans le cas d’une publication DNAT, il convient de sélectionner une stratégie Server ou Webserver correspondant au système d’exploitation et aux ports réellement publiés. Pour un flux VPN ou de segmentation, c’est également l’application protégée qui détermine le choix, et non le seul nom de la zone source. La MTU, le MSS, la latence et le débit doivent être contrôlés sur le trajet VPN réel.

La VoIP nécessite un test fonctionnel spécifique de la signalisation SIP et des flux multimédias RTP, ainsi qu’une procédure préparée de retour à la stratégie précédente. Pour les réseaux d’administration, de sauvegarde et d’infrastructure, des règles étroitement délimitées sont généralement plus utiles qu’une sélection de signatures particulièrement large. L’IPS peut aussi compliquer les attaques latérales aux frontières entre segments internes ; les seuils de spoofing et de flooding restent toutefois une fonction distincte des paramètres de protection contre le spoofing et les attaques DoS.

Une stratégie personnalisée est pertinente lorsque le chemin de données doit être délimité plus précisément, qu’un SID particulier nécessite une exception documentée ou qu’une action doit délibérément différer de Recommended. Sous Intrusion prevention > IPS policies > Add, attribuer alors un nom explicite tel que IPS-Pilot-LAN ou IPS-DNAT-Webserver, puis cloner comme point de départ une stratégie existante appropriée. Enregistrer d’abord la stratégie nouvelle ou clonée avec Save ; cette opération ne crée pas encore de nouvelle règle de stratégie. Adapter ensuite les règles de la copie ; les signatures fournies ne peuvent pas être modifiées.

Filtrer les signatures et ordonner les règles de la stratégie

Lors de l’ajout d’une règle, il est possible de sélectionner des signatures individuelles, des signatures personnalisées ou Select all. Le filtre intelligent accepte des termes de recherche et des critères tels que Category, Severity, Platform et Target ; après la saisie, appuyer sur Entrée pour appliquer le filtre.

L’éditeur de règles s’ouvre séparément de la création de la stratégie : sous Intrusion prevention > IPS policies, sélectionner Edit pour la stratégie souhaitée, déjà enregistrée, puis Add et saisir un nom de règle unique. Sélectionner ensuite les signatures nécessaires : Select individual signature pour les signatures individuelles ou Custom signature pour les signatures personnalisées. Pour effectuer une recherche avec Smart filter, sélectionner d’abord Select all, saisir le terme de recherche et appuyer sur Entrée pour appliquer le filtre.

Les catégories aident à délimiter le périmètre technique ; la référence des catégories suit la procédure de configuration.

Après la sélection des signatures, définir délibérément Action ; les différences sont expliquées dans la section consacrée à la sévérité et à l’action. Enregistrer la règle avec Save dans l’éditeur de règles. Cette étape est distincte du premier enregistrement de la stratégie. Dans la procédure DDoS, enregistrer ensuite également la stratégie contenant cette règle avec Save.

Après l’enregistrement, lancer une nouvelle session de test et vérifier ips_policy_id ou idp_policy_id ainsi que fw_rule_id ; en cas de détection, comparer aussi signature_id, classification et log_subtype avec la règle et l’action prévues. L’absence de détection ne prouve pas à elle seule que le filtre ou la stratégie a été appliqué.

Les règles d’une stratégie sont évaluées de haut en bas. Une règle générale couvrant toutes les signatures Server peut donc masquer une règle spéciale placée plus bas pour un SID particulier. Les exceptions spécifiques ou les actions dérogatoires doivent précéder la règle plus générale. Toute détection ultérieure doit afficher la stratégie, la Rule ID et l’action attendues.

Les signatures IPS personnalisées sont destinées à un cas de détection clairement défini, et non à compenser une sélection standard inadaptée. La procédure incluant la syntaxe, une stratégie pilote bien délimitée ainsi que des tests positifs et négatifs est décrite dans Créer et tester des signatures IPS personnalisées.

Évaluer séparément la sévérité et l’action

SID est l’identifiant unique d’une signature IPS. Category décrit son groupe fonctionnel, Severity la gravité de la menace et Platform la plateforme concernée, par exemple Microsoft Windows. Target distingue les signatures client et serveur ; Recommended action indique l’action prévue en cas de correspondance. Les noms et les descriptions des catégories ci-dessous ne garantissent pas un blocage : celui-ci dépend de la règle de stratégie effectivement appliquée.

Pour les journaux, les tickets et les exceptions, les champs SID, Category, Severity, Platform, Target et Recommended action sont importants. Sophos classe les scores CVSS de 9 à 10 comme Critical, de 7 à moins de 9 comme Major, de 4 à moins de 7 comme Moderate, et de 1 à moins de 4 ou les signatures parentes comme Minor. Warning identifie un type de trafic donné et génère une alerte. La sévérité ne détermine pas à elle seule le risque : l’accessibilité, le système cible, le niveau de correctifs et l’action effectivement appliquée doivent également être évalués.

Cette correspondance CVSS comporte des exceptions : Sophos décrit des cas dont le classement de sévérité ne correspond pas aux formules indiquées. Cela ne permet de déduire ni l’existence d’une fonction WebAdmin documentée pour remplacer la sévérité ni celle d’une procédure de reclassement ; vérifier la sévérité effectivement affichée pour la signature.

Une règle de stratégie peut remplacer l’action recommandée :

Warning ne prouve pas un blocage : L’aide sur la sévérité décrit Warning comme générant toujours une alerte, tandis que l’aide générale sur les règles décrit le remplacement de l’action recommandée. Ces indications ne précisent pas clairement leur interaction pour une signature Warning donnée. Ne pas déduire un blocage du seul libellé de sévérité ou d’une action Drop sélectionnée. Vérifier l’action effective dans un pilote contrôlé pour cet usage et clarifier tout comportement incertain avec le support Sophos avant la mise en production.

• Recommended applique l’action préconisée par Sophos pour la signature concernée et constitue généralement le point de départ des règles en production.
• Allow packet journalise la détection, mais autorise le paquet. Cette action convient à un pilote, mais n’empêche pas l’attaque détectée.
• Drop packet rejette uniquement le paquet concerné. L’application peut continuer à fonctionner ou renvoyer une erreur.
• Drop session met fin à l’ensemble de la session après une détection.
• Reset met activement fin à une session TCP en envoyant une réinitialisation à l’initiateur.
• Disable désactive uniquement cette signature ; la détection correspondante n’est alors plus assurée.
• Bypass session cesse d’inspecter le reste de la session. Le trafic peut ainsi passer dans FastPath ou être déchargé (offload), et échapper à une part plus importante de l’inspection que prévu.

Les actions sur les paquets s’appliquent paquet par paquet. Les actions sur les sessions inspectent le trafic jusqu’à la première détection, puis s’appliquent à l’ensemble de la connexion. Tout écart par rapport à Recommended doit donc être justifié en indiquant la signature, la stratégie, la règle de pare-feu, la personne responsable et la date de révision.

Sélectionner la stratégie IPS dans la règle de pare-feu

1. Ouvrir Rules and policies > Firewall rules.
2. Modifier la règle dont la Rule ID a été confirmée pour le flux pilote.
3. Sous Other security features, sélectionner la stratégie IPS choisie pour Detect and prevent exploits (IPS).
4. Activer Log firewall traffic, enregistrer, puis créer une nouvelle session pour le test.

L’activation globale ne suffit pas. Si le trafic rencontre d’abord une autre règle sans stratégie IPS, une règle ultérieure ne le protégera pas. L’article La règle Sophos Firewall ne s’applique pas : rechercher les causes aide à vérifier la correspondance des règles.

Les règles de pare-feu limitent le trafic qui peut être autorisé. L’IPS détecte les schémas d’attaque dans le flux de données visible. Web Protection contrôle les contenus et les catégories web, Application Control classe les applications, TLS Inspection rend si nécessaire le contenu chiffré visible, et Zero-Day Protection analyse les fichiers suspects. Les Threat Feeds, comme les flux tenus à jour par Cybora, bloquent en complément les adresses IP, domaines ou URL malveillants connus. Ces modules sont complémentaires ; aucun ne remplace une règle de pare-feu restrictive, la gestion des correctifs ou le choix correct de la stratégie.

Distinguer les signatures DDoS des limites DoS locales

Les signatures DDoS sont disponibles uniquement sur XGS 5500 et les pare-feu de capacité supérieure. Sur un modèle compatible, créer une stratégie dédiée, par exemple DDoS_Protection, sous Intrusion prevention > IPS policies > Add et l’enregistrer avec Save. Ouvrir ensuite Edit > Add, saisir un nom de règle, choisir Select all, saisir ddos dans Smart filter et appuyer sur Enter. Régler Action sur Drop packet, puis enregistrer d’abord la règle et ensuite la stratégie avec Save. Sous Rules and policies > Firewall rules, affecter la stratégie à la règle qui traite réellement le trafic. Vérifier la licence, le commutateur IPS global, les signatures disponibles et l’affectation comme indiqué ci-dessus ; le nom du modèle ne prouve pas une inspection active.

Les DoS settings locaux sous Intrusion prevention > DoS & spoof protection sont distincts et prennent en charge IPv4 et IPv6. Adapter les débits de paquets et de rafales au trafic réel, sélectionner le Apply Flag correspondant et cliquer sur Apply. Lorsqu’une source dépasse la limite par minute activée pour ICMP/ICMPv6, le pare-feu rejette les paquets excédentaires tant que l’attaque continue. L’exemple documentaire de 1200 paquets par minute et par source n’est pas une valeur de production par défaut. Protection DoS et contre l’usurpation explique la mesure, l’état, les exceptions et le retour arrière. Si la liaison Internet est déjà saturée, une protection chez le fournisseur ou en amont est nécessaire ; l’IPS ne peut pas récupérer cette bande passante. Ne pas générer une véritable attaque par inondation pour un test fonctionnel.

Référence des catégories

Les catégories facilitent la délimitation fonctionnelle. Le tableau complet ci-dessous explique les libellés affichés par SFOS. Category reste une aide à la recherche, et non une évaluation du risque ; l’associer à Platform et Target permet au filtre intelligent de ne retenir que les signatures pertinentes.

Les catégories d’indicateurs très larges doivent d’abord être utilisées dans un pilote en mode observation. indicator-compromise peut notamment produire des faux positifs ; la catégorie seule ne justifie donc ni blocage ni exception.

Valider un pilote contrôlé

Avant le démarrage, définir la durée du test, la personne responsable, la base de comparaison et les critères d’arrêt. La référence initiale comprend la date et l’heure des patterns, la Firewall Rule ID, l’ancienne et la nouvelle stratégie IPS, les exceptions connues, l’utilisation du processeur et de la mémoire, ainsi qu’au moins une connexion témoin inchangée. Pour la VoIP, les ERP, les protocoles industriels, les VPN et les applications anciennes, le test nécessite une fenêtre de maintenance.

1. Confirmer l’affectation de la stratégie : créer une nouvelle session et vérifier, dans Packet Capture ou dans le journal du pare-feu, que la Firewall Rule ID et l’IPS Policy ID correspondent aux valeurs attendues. Cela confirme l’affectation, mais pas encore une détection de signature. La procédure commune pour Log Viewer et Packet Capture peut être appliquée directement à la connexion de test.
2. Tester les processus réels : exécuter l’authentification, le transfert de fichiers, les mises à jour, les API et les sessions de longue durée. Un ping ne remplace pas ces tests.
3. Analyser les événements : en cas de détection, consigner l’identifiant et le nom de la signature, la stratégie, la règle de pare-feu, la source, la destination, les ports et l’action effectivement appliquée. Il ne faut pas déclencher une attaque réelle uniquement pour vérifier le fonctionnement. Pour produire une détection inoffensive et déterministe, utiliser le pilote de signature personnalisée contrôlé.
4. Comparer la connexion témoin : une connexion autorisée du même périmètre doit toujours afficher la règle et l’application attendues. Si des paquets disparaissent, l’analyse distincte des paquets rejetés aide à isoler la cause.
5. Élargir seulement ensuite : n’ajouter d’autres hôtes ou règles que s’il ne subsiste aucun blocage inexpliqué et si les limites prédéfinies de charge, de latence et de fonctionnement applicatif sont respectées.

La réussite ne suppose pas nécessairement le déclenchement d’une signature d’attaque. Les critères déterminants sont l’affectation confirmée de la stratégie, le bon fonctionnement des scénarios de test et de contrôle, l’absence de blocage inexpliqué et des niveaux de ressources acceptables. Dès qu’un processus métier critique échoue, qu’un blocage inexpliqué survient ou qu’une limite de performances convenue est dépassée, les valeurs initiales documentées de l’affectation de stratégie et de la journalisation de la règle doivent être rétablies. Une stratégie pilote créée spécialement ne doit être supprimée qu’une fois qu’elle n’est plus affectée à aucune règle et que ses exceptions ont été documentées. Si l’IPS était globalement désactivé avant le pilote, cet état initial ne doit être rétabli qu’après avoir vérifié quelles autres règles de pare-feu perdraient alors leur protection IPS.

Interpréter correctement les journaux, Packet Capture et les rapports

Ces outils répondent à des questions différentes :

• Journal du pare-feu : ips_policy_id indique la stratégie affectée au flux. Cette information est également utile en l’absence de détection de signature.
• Événement IPS : log_type=IDP, signature_id, signature_msg, idp_policy_id, fw_rule_id, classification et log_subtype permettent de relier la signature, la stratégie, la règle et le résultat. Dans le journal, detection_severity ne correspond pas nécessairement à la représentation catégorielle de la sévérité dans la stratégie.
• Packet Capture : affiche notamment la Firewall Rule ID, la NAT ID et l’IPS Policy ID dans le flux de paquets.
• ips.log : fournit des informations plus détaillées sur les décisions prises par l’IPS, le moteur DPI, Application Control et Active Threat Response.
• sig_upgrade.log et sigmigration.log : retracent respectivement la mise à jour et la migration des signatures.
• Reports > Network & threats > Intrusion attacks : convient à l’analyse rétrospective ; Log Viewer reste préférable pour examiner des événements récents individuels.

L’article Services et journaux de Sophos Firewall explique l’association des autres fichiers journaux et services. Lorsque plusieurs modules de protection sont actifs, comparer le même instant dans les journaux du pare-feu, de l’IPS, du web, d’Application Control et de l’inspection SSL/TLS. Une règle de pare-feu peut autoriser un trafic qu’un module en aval bloque ensuite.

Contrôler les performances sous une charge comparable

Selon le modèle, le trafic, les signatures, TLS Inspection, Application Control, le VPN et la taille des paquets, l’IPS sollicite les ressources de manière différente. Avant et après l’activation, mesurer sous une charge comparable l’utilisation du processeur et de la mémoire, le débit, la latence, les retransmissions des applications critiques ainsi que les volumes IPS/DPI et Syslog.

Désactiver brièvement l’IPS ne suffit pas à établir une relation de cause à effet. Des comparaisons reproductibles nécessitent des mesures de performances du pare-feu correctement interprétées et un test iPerf contrôlé.

Traiter les faux positifs plutôt que simplement autoriser le trafic

Une détection IPS peut être un faux positif, révéler une application inattendue ou signaler une véritable tentative d’exploitation. Commencer par consigner l’identifiant et le nom de la signature, la source, la destination, le service, la règle de pare-feu, l’heure, la fréquence, l’application concernée et son niveau de correctifs. Procéder ensuite comme suit :

1. Reproduire le processus légitime et confirmer que ce SID précis est bien à l’origine de la détection.
2. Vérifier le niveau de correctifs, les recommandations du fournisseur et l’accessibilité du système protégé.
3. Évaluer le risque si la détection est autorisée. Aucun constat incertain ou non reproductible ne doit donner lieu à une exception permanente.
4. Choisir la mesure réversible la plus restrictive : appliquer de préférence un correctif ou mieux délimiter le chemin de données ; à défaut, définir temporairement un seul SID sur Allow packet dans une stratégie utilisée uniquement à cet endroit. Disable et Bypass session retirent davantage de protection et nécessitent une justification plus solide.
5. Tester à nouveau le flux légitime positif et un flux négatif ou témoin.
6. Documenter l’exception, la personne responsable et la date de révision, puis réévaluer le cas après toute mise à jour de l’application, des patterns, du firmware ou du système.

Si de nombreuses signatures perturbent la même application, une stratégie personnalisée étroitement délimitée ou une meilleure segmentation constitue une solution plus propre qu’une accumulation d’exceptions globales permanentes. La désactivation globale de l’IPS n’est pas un retour arrière approprié pour un seul SID.

Dépannage par symptôme

Aucun événement IPS n’est visible

Commencer par créer une nouvelle session et vérifier la Firewall Rule ID ainsi que ips_policy_id dans le journal du pare-feu ou Packet Capture. Si la Policy ID est absente, le flux rencontre une autre règle ou aucune stratégie IPS n’est affectée à la règle sélectionnée. Si la stratégie est confirmée, mais qu’aucune signature n’est détectée, cela peut être normal pour un trafic inoffensif. Pour obtenir un résultat reproductible, utiliser une signature personnalisée strictement ciblée dans un pilote isolé, et non un véritable exploit.

Un événement existe, mais le trafic n’est pas bloqué

Dans l’événement IPS, vérifier signature_id, la stratégie et log_subtype. Contrôler ensuite la première règle de stratégie correspondante et l’action qu’elle applique effectivement. Allow packet, Disable ou Bypass session peuvent empêcher le blocage attendu ; une règle générale placée plus haut peut masquer la règle spécifique. Tester une nouvelle session après chaque modification.

Les signatures IPS sont absentes ou la mise à jour des patterns échoue

Vérifier conjointement l’état de la licence, le commutateur IPS global et Backup & firmware > Pattern updates. L’état Failed ou la date récente des signatures d’applications ne prouvent pas la réussite d’une mise à jour IPS. sig_upgrade.log retrace le processus de mise à jour ; en cas de problème de licence, licensing.log apporte du contexte supplémentaire. Dans un cluster HA, le nœud Primary met à jour les patterns IPS et les synchronise automatiquement avec le nœud Auxiliary.

Le service IPS affiche l’état DEAD

Sous System services > Services, vérifier et documenter l’état du service IPS. Si le support Sophos demande en complément une sortie shell propre à chaque nœud, 5 Device Management > 3 Advanced Shell permet d’effectuer ce contrôle en lecture seule :

service -S | grep -i ips

La ligne pertinente est celle dont le premier nom de service est exactement ips ; il ne s’agit pas de ipsec-monitor. Cette commande Advanced Shell ne fait pas partie de la procédure publiée pour le problème connu et ne doit être utilisée que dans le cadre d’un diagnostic coordonné avec le support. Dans un cluster HA, l’état demandé doit être relevé séparément sur chaque nœud concerné.

Sous SFOS 22.0 GA et les versions ultérieures, il peut arriver, dans de rares cas, que des données de configuration nécessaires à la stratégie web soient absentes. Le service de stratégie web ne démarre alors pas, l’IPS ne peut pas initialiser sa stratégie et reste à l’état DEAD ; les mises à jour de patterns échouent également. Dans un cluster HA, chaque nœud peut être affecté indépendamment.

Consigner la version de SFOS, l’heure, le nœud, l’état du service, ips.log et sig_upgrade.log, puis contacter le support Sophos en mentionnant NC-181971. L’état du service ne suffit pas à prouver cette cause. Dans la liste actuelle des problèmes connus, Sophos ne publie toujours aucune version corrigée et fournit la solution de contournement par l’intermédiaire du support. Les redémarrages répétés ou les commandes de réparation non documentées ne constituent pas une méthode de diagnostic fiable.

Utiliser le pack complet de signatures uniquement dans des cas particuliers avérés

Lors d’une mise à jour des patterns, SFOS peut télécharger le pack complet de signatures IPS au lieu d’un pack partiel. Cette option est réservée aux appliances disposant d’au moins 32 GB de RAM et peut, selon Sophos, affecter les performances. Elle n’active pas l’IPS et n’affecte aucune stratégie à une règle de pare-feu.

Un cas d’utilisation pertinent est celui d’une signature explicitement indiquée par le support Sophos, mais absente du pack partiel. L’option ne doit pas être activée par précaution au seul motif qu’un plus grand nombre de signatures semblerait préférable. Commencer par lire l’état actuel dans la Device Console :

system ips full-signature-pack show

L’aide de la Device Console n’indique aucune valeur par défaut. Une fois la limite de RAM et le besoin concret confirmés, activer le téléchargement complet :

system ips full-signature-pack enable

Après la mise à jour suivante des patterns, vérifier la date et l’heure des patterns, sig_upgrade.log, la signature attendue, l’état de l’IPS, le CPU, la RAM et le trafic concerné. Si le bénéfice attendu n’est pas constaté ou si le fonctionnement se dégrade, rétablir l’état relevé précédemment. S’il était défini sur disable avant le test, la commande de retour arrière est la suivante :

system ips full-signature-pack disable

Interpréter la configuration IPS via l’API XML en toute sécurité

Pour des configurations reproductibles, l’API XML distingue deux fonctions : IPSFullSignaturePack contrôle le téléchargement du pack, tandis que IPSPolicy décrit une stratégie avec une sélection de signatures et des actions. Aucun de ces objets ne remplace la vérification de la licence, le commutateur IPS global, l’affectation à la règle de pare-feu qui traite réellement le trafic ou la validation avec du nouveau trafic. Les prérequis et la procédure pilote ci-dessus s’appliquent donc également aux modifications automatisées. L’article Utiliser l’API XML en toute sécurité explique l’accès et l’analyse des réponses.

Pack complet : Status n’est pas une opération Get générale

La référence de l’API SFOS-22/23 décrit pour IPSFullSignaturePack le champ scalaire obligatoire Status. Ses valeurs sont exactement, en minuscules, enable, disable et show : les deux premières activent ou désactivent le téléchargement du pack complet, tandis que la troisième sert à consulter l’état dans cet objet. L’exemple montre uniquement enable/disable ; il ne permet pas d’en déduire une opération Get générale. Le tableau des paramètres de l’API indique disable comme valeur par défaut, alors que l’aide de la Device Console ci-dessus n’en indique aucune. Cela ne dispense pas de lire l’état initial réel.

Même via l’API, cette option reste réservée aux appliances disposant d’au moins 32 GB de RAM et à un besoin avéré. Elle ne constitue ni un commutateur de licence ni une affectation de stratégie. Pour l’opération IPSFullSignaturePack, la référence indique le statut 200 avec Operation Successful. et 500 avec Operation Fail.. Une réponse de configuration réussie ne prouve pas encore que le téléchargement des patterns est terminé ou que la protection IPS est effective : après la mise à jour suivante, effectuer les contrôles des signatures, des ressources et du trafic indiqués ci-dessus.

Stratégies : distinguer les règles héritées de la sélection personnalisée

Dans l’exemple de configuration, IPSPolicy contient les champs Name, Description, Template et RuleList. Le commentaire relatif à Template précise que, lorsqu’une stratégie existante est choisie comme modèle, toutes ses règles sont héritées et les règles supplémentaires indiquées sont ajoutées ; sans modèle, la stratégie contient uniquement les règles indiquées. Une courte liste de règles personnalisées ne signifie donc pas automatiquement que la stratégie est étroitement délimitée lorsqu’un modèle est utilisé. Vérifier la liste complète réellement enregistrée et son ordre afin qu’aucune règle générale héritée ne masque une exception SID prévue. L’exemple ne garantit pas la manière dont une mise à jour ultérieure traite les règles qui ne sont pas transmises.

Chaque entrée Rule de RuleList associe un RuleName, le RuleType, la sélection et une Action. RuleType distingue Default Signature et Custom Signature. Dans la référence, le champ de sélection porte littéralement le nom SignaturSelectionType, sans ajout ultérieur d’une lettre. Il distingue All Application et Individual Application. L’exemple présente également CategoryList avec Category, SeverityList avec Severity, PlatformList avec Platform, TargetList avec Target ainsi que SignatureList avec Signature. Les critères de filtrage délimitent la sélection fonctionnelle ; les signatures individuelles sont désignées séparément. Les descriptions de Platform et de Target parlent de listes par ID : ne pas utiliser les libellés affichés comme identifiants d’API sans les vérifier.

Pour Action, l’exemple présente les valeurs textuelles Allow Packet, Drop Packet, Disable, Drop Session, Reset, Bypass Session et Recommended. Leurs effets sont expliqués ci-dessus. Le tableau des paramètres mentionne également 7, mais n’explique aucune correspondance avec une action nommée. Ne pas déduire de ce nombre une signification ou un réglage à utiliser en production ; si la sélection est ambiguë, modifier la stratégie dans WebAdmin ou clarifier la syntaxe avec le support Sophos.

Le tableau des paramètres exige un nom de stratégie scalaire en UTF-8, sans virgule et comportant au maximum 60 caractères ; Description est facultatif. Pour les règles, il indique des noms obligatoires de 70 caractères au maximum, ainsi que Rule Type, le mode de sélection des signatures et l’action sous forme de tableaux à plusieurs valeurs. Selon le tableau, les valeurs en double sont ignorées uniquement pour les noms de règles, et non pour les autres tableaux mentionnés. Les signatures individuelles et les quatre listes de filtres sont des tableaux bidimensionnels facultatifs de chaînes de caractères. Ces indications ne garantissent ni un traitement atomique ni que les champs de sélection omis restent inchangés lors d’une mise à jour. Avant toute modification, sauvegarder la stratégie complète avec ses règles héritées, ses actions, ses exceptions et ses affectations aux règles de pare-feu ; ensuite, relire la sélection et l’ordre enregistrés, puis valider le pilote avec de nouvelles sessions.

Réponses : vérifier conjointement l’opération et l’état enregistré

Les correspondances suivantes figurent dans les deux références SFOS-22/23. Les identifiants Message.* restent des symboles documentaires non résolus : ils ne constituent ni des messages garantis à l’exécution ni une preuve d’une cause précise. Les valeurs sont des statuts de l’API XML, et non automatiquement des codes de statut HTTP.

En particulier, en cas de 505 après Add, ne pas supposer que la stratégie est restée inchangée et ne pas déduire un redémarrage du moteur du seul symbole. En cas de 502, comparer le nom existant et la stratégie souhaitée plutôt que de créer une seconde stratégie ; en cas de 522, vérifier les stratégies réellement présentes. En cas de 506, consulter la licence et l’état global de l’IPS, sans activer l’IPS comme traitement automatique de l’erreur. Ces contrôles aident à cerner l’état, mais ne remplacent pas l’analyse de la réponse réelle.

Selon la référence, Delete identifie la stratégie au moyen du champ obligatoire Name, avec les mêmes limites pour le nom. La page Delete ne contient pas de structure de requête complète ; il ne faut donc pas en assembler ici une requête de suppression exécutable. Avant une suppression prévue, vérifier les affectations et les dépendances, puis préparer le retour arrière nécessaire. En cas de 503, contrôler notamment les références existantes, sans déduire du symbole une liste complète des relations bloquantes. Après une réponse ambiguë ou un échec, vérifier d’abord dans WebAdmin si la stratégie existe encore et quelles règles, actions et affectations sont réellement enregistrées. Ce n’est qu’une fois l’état réel clarifié qu’il convient de décider d’une nouvelle tentative ciblée ou de la restauration des valeurs initiales documentées ; les tableaux de réponses ne garantissent ni la possibilité de répéter automatiquement l’opération ni un retour arrière. Conserver dans cette démarche la procédure centrale de sécurité de l’API.

Détection de la PQC à partir de SFOS 22.0 MR2

SFOS 22.0 MR2 peut détecter et contrôler les mécanismes d’échange de clés post-quantiques purs et hybrides reposant sur ML-KEM. Les nouveaux patterns IPS sont désactivés par défaut, car la PQC n’est pas intrinsèquement suspecte. Pour analyser ces connexions, commencer par utiliser une stratégie pilote personnalisée avec Allow packet et la journalisation. Seuls un cas d’utilisation défini et des tests positif et témoin stables justifient l’emploi de Drop session ou de Reset. L’article Sophos Firewall v22 MR2 : contrôle de la PQC fournit des informations complémentaires.

FAQ