Configurer et tester l’IPS de Sophos Firewall

L’Intrusion Prevention System (IPS) analyse le trafic afin de détecter des schémas d’attaque connus, des exploits et des caractéristiques de protocole suspectes. Pour que l’IPS protège réellement le trafic, il doit être activé globalement et une IPS Policy adaptée doit être attribuée à la règle firewall qui traite ce trafic.

Il ne faut pas appliquer systématiquement la policy la plus stricte à toutes les règles. Une policy adaptée au chemin des données, un déploiement pilote et des logs exploitables évitent les interruptions inutiles sans réduire à la légère le niveau de protection.

Activer l’IPS et l’attribuer à une règle firewall

Prérequis

Avant la configuration, les conditions suivantes doivent être remplies :

• abonnement Network Protection actif ou licence d’essai
• signatures IPS disponibles et mises à jour des patterns fonctionnelles
• règle firewall connue qui traite effectivement le trafic à inspecter
• logging de la règle activé et procédure définie pour les faux positifs

IPS Protection est désactivé par défaut. Sur un firewall connecté à Internet, les signatures IPS ne sont mises à jour que si la licence est valide et l’IPS activé. Les firewalls Air Gap sous licence constituent l’exception documentée : ils peuvent recevoir des signatures IPS même lorsque l’IPS est désactivé, au moyen du processus de mise à jour prévu. Les détails figurent dans Licences Air Gap et mises à jour des patterns.

À l’expiration de Network Protection, l’interrupteur IPS peut encore sembler actif alors que le firewall n’applique plus la protection IPS. Si l’IPS est désactivé manuellement, les signatures en ligne ne sont plus mises à jour et il n’est plus possible de configurer les policies ni les signatures personnalisées. Après 30 jours, le firewall supprime les signatures et les règles IPS.

À l’expiration d’une licence d’essai, l’IPS se désactive automatiquement. Durant les 30 jours suivants, il n’applique aucune protection, ne télécharge aucune signature et n’autorise aucune configuration de policy ; les signatures et les règles sont ensuite supprimées. Pour conserver la configuration, il faut l’exporter ou créer une sauvegarde au préalable.

Activer l’IPS globalement

1. Ouvrir Protect > Intrusion prevention > IPS policies. Selon l’affichage, le chemin abrégé est Intrusion prevention > IPS policies.
2. Activer IPS Protection.
3. Vérifier l’état de la licence et les mises à jour des patterns.
4. Attendre que les signatures soient disponibles.
5. Contrôler les policies par défaut existantes.
6. Si une policy personnalisée est nécessaire, utiliser Add pour cloner une policy par défaut appropriée.

Après l’activation, il ne suffit pas de vérifier l’interrupteur. Des patterns à jour et un premier événement dans le log indiquent bien mieux que toute la chaîne de protection fonctionne.

L’activation ou la désactivation de Firewall Acceleration ou PKI Acceleration redémarre l’IPS ou la DPI Engine. Ces modifications doivent être réalisées pendant une fenêtre de maintenance, pas au milieu d’une analyse d’incident.

Activer l’IPS dans la règle firewall

1. Ouvrir Rules and policies > Firewall rules.
2. Modifier la règle qui traite effectivement le trafic.
3. Sous Other security features, activer Detect and prevent exploits (IPS).
4. Sélectionner une IPS Policy adaptée au trafic.
5. Activer le logging de la règle, enregistrer et tester avec du trafic réel.

L’activation globale seule ne suffit pas. Si le trafic correspond d’abord à une autre règle sans IPS Policy, une règle placée plus bas ne le protégera pas. Dans ce cas, consulter La règle Sophos Firewall ne s’applique pas : identifier les causes.

Pour un serveur publié, les éléments suivants doivent être cohérents : DNAT, règle firewall restrictive, IPS Policy, logging et gestion des correctifs. Pour les segments internes, il faut également vérifier que le trafic traverse bien le firewall et la règle attendue.

Choisir l’IPS Policy adaptée

La policy dépend de la source, de la destination et de l’application :

• Clients vers Internet : utiliser une policy client ou LAN-to-WAN et la coordonner avec Web Protection, Application Control et, si nécessaire, TLS Inspection. Les navigateurs, services de mise à jour et applications métier doivent faire partie du pilote ; Zero-Day Protection complète l’analyse par signatures pour les téléchargements suspects.
• Internet vers un serveur par DNAT : adapter précisément une policy serveur ou serveur web au système cible et aux ports publiés. La protection concerne les services réellement exposés, pas toutes les technologies serveur de manière générale. Publier un serveur par DNAT explique le contexte NAT et les règles ; des adresses IP, domaines ou URL malveillants connus peuvent aussi être bloqués au moyen des Threat Feeds.
• VPN site à site ou Remote Access : sélectionner la policy en fonction des systèmes source et destination. Tester les applications de production, le MTU/MSS, la latence et le débit sur la liaison VPN réelle.
• VoIP : tester SIP/RTP avec une policy spécifique et un plan de retour arrière. Une policy client ou serveur agressive peut perturber la signalisation ou le flux média.
• Réseaux de management, de sauvegarde et d’infrastructure : appliquer une protection restrictive sans interrompre les connexions nécessaires à l’administration, à la supervision ou aux sauvegardes. Des règles étroites sont généralement plus utiles ici qu’une sélection très large de signatures.

L’IPS complique également les mouvements latéraux après une compromission aux frontières entre segments, par exemple du client vers le serveur ou du VPN vers le serveur. Il ne fait toutefois que compléter de bonnes règles firewall. Les paramètres de protection contre le spoofing et le DoS traitent séparément les schémas simples d’usurpation et de flooding.

Créer une policy personnalisée à partir d’un modèle

L’option Add permet de cloner une policy par défaut, puis de l’adapter précisément. Cette méthode est plus compréhensible qu’une collection libre de signatures et conserve une protection de base pertinente. Le nom doit indiquer la fonction et le chemin des données, par exemple IPS-Pilot-LAN ou IPS-DNAT-Webserver.

Les règles de la policy sont évaluées de haut en bas. Une règle large englobant toutes les signatures serveur peut donc masquer une règle particulière située plus bas pour un SID donné. Les adaptations spécifiques doivent précéder les règles générales ; un événement correspondant dans le log doit ensuite confirmer que l’action attendue s’applique.

Filtrer et évaluer les signatures

Les signatures peuvent être filtrées par Category, Severity, Platform et Target. Il est également possible de créer ses propres signatures IPS, mais uniquement pour un cas de détection clairement décrit et avec une réévaluation ultérieure. Les informations suivantes sont essentielles pour les logs, les tickets et les exceptions :

• SID : identifiant unique de la signature
• Category : domaine technique, par exemple DNS, navigateur ou malware
• Severity : niveau de gravité
• Platform : plateforme concernée, par exemple Windows ou Linux
• Target : signature client ou serveur
• Recommended action : action recommandée par Sophos

Sophos associe Critical à un score CVSS de 9 à 10, Major de 7 à moins de 9, Moderate de 4 à moins de 7 et Minor de 1 à moins de 4 ou aux signatures parentes. Warning signale un trafic suspect sous forme d’alerte. La sévérité ne suffit toutefois pas à prendre une décision : une signature Major sur un serveur exposé ne s’évalue pas comme un événement Warning dans un réseau de test. Le système cible, son exposition, son niveau de correctifs et l’action réellement appliquée doivent toujours être pris en compte.

Comprendre les actions IPS

Une règle de policy peut remplacer l’action recommandée par Sophos :

• Recommended : bon point de départ pour les règles de production ; la recommandation Sophos propre à chaque signature est appliquée
• Allow packet : journaliser l’événement mais autoriser le paquet ; adapté à un pilote, mais n’empêche pas l’attaque détectée
• Drop packet : rejeter uniquement le paquet concerné ; l’application peut continuer à fonctionner ou générer des erreurs
• Drop session : terminer toute la session après un événement ; intervention plus forte lorsqu’un risque d’attaque est confirmé
• Reset : réinitialiser activement la session TCP ; l’utilisateur ou l’application constate une interruption brutale
• Disable : désactiver la signature ; la protection correspondant exactement à cette détection disparaît
• Bypass session : ne plus inspecter le reste de la session ; le trafic peut alors passer dans FastPath ou en Offload et ainsi échapper plus largement à l’inspection que prévu

Les actions sur les paquets s’appliquent à chaque paquet. Les actions sur les sessions inspectent jusqu’au premier événement, puis agissent sur l’ensemble de la connexion. Tout écart par rapport à Recommended doit donc être documenté avec la signature, la policy, la règle firewall, le motif, le responsable et la date de révision.

Patterns PQC à partir de SFOS 22.0 MR2

SFOS 22.0 MR2 détecte les négociations ML-KEM pures et hybrides, notamment ML-KEM-512, -768, -1024 ainsi que X25519 avec ML-KEM-768. Les nouveaux patterns PQC sont définis par défaut sur Disabled, car l’utilisation de PQC n’est pas automatiquement suspecte. Pour les analyser, il est préférable de tester d’abord une policy pilote personnalisée avec Allow packet et le logging, puis de n’utiliser Drop session ou Reset qu’après analyse. Les détails sont présentés dans Sophos Firewall v22 MR2 : contrôle PQC.

Déployer et tester de manière contrôlée

1. Choisir une règle pilote : commencer par un réseau client de test connu ou une seule règle DNAT. Le trafic attendu et la personne responsable doivent être clairement définis avant le test.
2. Tester les applications réelles : vérifier l’authentification, le transfert de fichiers, les mises à jour, les API et les sessions longues. Un simple ping ne prouve pas que l’application reste stable avec l’IPS.
3. Analyser les événements : dans le Log viewer, vérifier la source, la destination, le service, la règle firewall, la signature, le SID, la Severity, l’action et l’heure. Les outils ci-dessous fournissent le contexte technique.
4. Étendre progressivement : n’ajouter d’autres règles qu’après des tests stables. La VoIP, les ERP, les protocoles industriels, les VPN et les applications anciennes nécessitent une fenêtre de test et un plan de retour arrière.

Pour l’analyse, consulter Services et logs, utiliser conjointement Log Viewer et Packet Capture et analyser les paquets rejetés.

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

• ips.log : informations détaillées sur les décisions IPS, DPI et Application Control
• Packet Capture : flux de paquets, direction, Firewall Rule ID, NAT ID et IPS Policy ID
• Test de règle : règle firewall qui traite effectivement le trafic
• Syslog ou Central Reporting : conservation plus longue et corrélation

Lorsque plusieurs modules de protection sont actifs, comparer les heures dans les logs firewall, IPS, Web, Application Control et SSL/TLS Inspection. Une règle firewall peut autoriser un trafic qu’un module situé plus loin dans la chaîne bloque ensuite.

Comparer les performances

Selon le modèle, le trafic, les signatures, TLS Inspection, Application Control, le VPN et la taille des paquets, l’IPS consomme plus ou moins de ressources. Il faut donc mesurer les valeurs suivantes sous une charge comparable avant et après l’activation :

• charge CPU et mémoire
• débit sur les interfaces concernées
• latence et retransmissions des applications critiques
• volume IPS/DPI et Syslog
• messages des utilisateurs et des applications

Désactiver brièvement l’IPS ne suffit pas à démontrer la cause. Des comparaisons reproductibles nécessitent des données de performance du firewall correctement interprétées et un test iPerf contrôlé.

Traiter les faux positifs et les exceptions

Si un trafic légitime est bloqué, il ne faut pas désactiver l’IPS globalement par réflexe. Un événement peut être un faux positif, une application inattendue ou une véritable tentative d’exploitation. Il faut d’abord collecter :

• identifiant et nom de la signature
• source, destination, service et règle firewall concernée
• heure, fréquence et application concernée
• niveau de correctifs du système cible
• extrait de log ou Packet Capture pertinent

Des questions concrètes facilitent l’analyse : l’erreur se produit-elle uniquement pour un hôte ou un port ? Est-elle reproductible ? Disparaît-elle après l’installation d’un correctif ? Le même SID concerne-t-il à plusieurs reprises la même cible ? Seuls ces éléments justifient une modification de la policy.

La modification doit ensuite être limitée au strict nécessaire :

• adapter une seule signature plutôt qu’une catégorie entière
• utiliser une IPS Policy personnalisée uniquement dans la règle firewall concernée
• contrôler l’ordre des règles de la policy
• restreindre davantage la source, la destination et le service dans la règle firewall
• documenter le motif, le responsable et la date de révision
• vérifier après la modification que seul le trafic attendu est concerné

Une exception temporaire vaut généralement mieux qu’une désactivation permanente. Elle doit être réévaluée après une mise à jour de l’application, du firmware ou du système. Si de nombreuses signatures perturbent la même application, une policy dédiée ou une meilleure segmentation est plus propre qu’une exception globale étendue.

Dépannage et exploitation

L’IPS n’agit pas

Vérifier dans cet ordre :

1. La licence Network Protection ou d’essai est-elle valide ?
2. IPS Protection est-il activé globalement ?
3. Les patterns IPS sont-ils à jour ? Dans un cluster HA, ils sont mis à jour sur le Primary, puis automatiquement synchronisés avec l’Auxiliary.
4. Le trafic correspond-il à la règle firewall attendue, avec IPS Policy et logging ?
5. Une règle de policy générale masque-t-elle une règle plus spécifique ?
6. La policy contient-elle des actions non justifiées telles que Allow packet, Disable ou Bypass session ?
7. La policy est-elle adaptée au trafic client, serveur, VPN ou VoIP ?
8. Du trafic réel a-t-il permis de vérifier que Log Viewer et ips.log contiennent des événements correspondants ?

Les exceptions sans responsable ni date de révision sont considérées comme ouvertes et doivent être examinées lors du prochain contrôle d’exploitation.

Le service IPS est à l’état DEAD

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

Dans la CLI, le chemin 5 Device Management > 3 Advanced Shell ouvre le shell requis. La commande read-only suivante y affiche toutes les lignes de service dont le nom contient ips :

service -S | grep -i ips

Seule la ligne dont le premier nom de service est exactement ips est pertinente ; ipsec-monitor ne l’est pas. Dans un cluster HA, chaque nœud concerné doit être vérifié séparément.

Si le service est à l’état DEAD, enregistrer la version de SFOS, l’heure, le nœud, la sortie d’état complète ainsi que ips.log et sig_upgrade.log, puis contacter Sophos Support en mentionnant NC-181971. La commande seule ne prouve pas que ce problème est présent. Sophos ne publie toujours aucune version corrigée et fournit la solution de contournement uniquement par l’intermédiaire du Support. Des tentatives répétées de redémarrage ou des commandes de réparation non documentées ne constituent pas une solution propre.

FAQ