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.

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 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.

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

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 :

• 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.

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

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