Configurer et tester Sophos Firewall IPS

Intrusion Prevention System (IPS) est l’une des fonctions de protection les plus importantes sur Sophos Firewall. IPS vérifie le trafic à la recherche de schémas d’attaque connus, d’exploits et de comportements de protocole suspects. Bien utilisé, il protège en complément les clients, les serveurs, les services publiés et les liaisons VPN, en plus des règles de firewall, de Web Protection, d’Application Control et de TLS Inspection.

En pratique, IPS n’est toutefois pas un interrupteur à activer partout au niveau maximal. Une IPS Policy incorrecte ou trop large peut interrompre du trafic légitime, perturber la VoIP, consommer des performances ou générer de fausses alertes. Il faut donc activer IPS de manière planifiée, choisir la policy adaptée à chaque règle, puis contrôler le résultat avec des logs et des tests.

Quand IPS est utile

IPS est particulièrement utile là où le trafic présente un risque plus élevé ou là où des exploits connus doivent être bloqués tôt.

Domaines d’utilisation typiques:

• Réseaux clients avec accès Internet
• Réseaux de serveurs et DMZ
• Règles DNAT vers des serveurs internes
• Trafic VPN site-à-site entre sites
• Trafic Remote Access lorsque des systèmes internes sont utilisés après la connexion VPN
• VoIP, uniquement avec une sélection de policy prudente et des tests
• segments particulièrement critiques comme les réseaux de management, de sauvegarde ou d’infrastructure

Pour les serveurs publiés, IPS doit toujours être considéré avec un NAT propre, des règles de firewall strictes, le logging et la gestion des correctifs. L’article Publier des serveurs via DNAT sur Sophos Firewall explique le contexte adapté pour NAT et les règles de firewall. Pour la structure de base des règles, voir Comprendre et configurer correctement les règles Sophos Firewall.

Prérequis

IPS ne fonctionne que si les prérequis nécessaires sont remplis.

À vérifier avant le déploiement:

• Une subscription Network Protection active ou une licence d’essai est disponible.
• IPS Protection est activé sous Intrusion prevention > IPS policies.
• Les pattern updates fonctionnent: via les services de mise à jour Sophos pour les firewalls en ligne, ou via le processus de mise à jour air gap prévu pour les firewalls air gap sous licence.
• Les règles de firewall contiennent les IPS Policies adaptées sous Detect and prevent exploits (IPS).
• Le logging est actif pour les règles et types de logs concernés.
• Il existe un processus pour les faux positifs, les exceptions et les adaptations de policy.
• Pour les services publiés et les limites de segmentation, la règle de firewall qui traite réellement le trafic est clairement identifiée.

Si la subscription Network Protection expire, le commutateur IPS peut encore sembler actif alors qu’IPS n’est plus appliqué. Si IPS est désactivé manuellement, les mises à jour de signatures s’arrêtent et la configuration des policies n’est plus disponible; après 30 jours, les signatures et règles IPS sont supprimées. À l’expiration d’une licence d’essai, IPS se désactive automatiquement. Un backup ou un export de la configuration IPS doit donc être effectué dans un délai de 30 jours.

Attention: IPS dépend de la licence et des mises à jour. Une règle de firewall avec une IPS Policy sélectionnée ne signifie pas automatiquement qu’IPS protège réellement. L’état de licence, l’activation globale d’IPS, les signatures et les logs doivent être vérifiés.

Activer IPS globalement

L’activation globale se fait dans les versions SFOS actuelles sous Protect > Intrusion prevention > IPS policies. Dans certaines vues, le chemin apparaît sous la forme abrégée Intrusion prevention > IPS policies.

1. Ouvrir Protect > Intrusion prevention > IPS policies.
2. Activer IPS Protection.
3. Vérifier les remarques de licence.
4. Attendre que les signatures soient disponibles.
5. Vérifier les policies standard existantes.
6. Si nécessaire, cloner une policy personnalisée à partir d’une policy existante.

Une policy personnalisée se crée avec Add, en attribuant un nom puis en clonant une policy existante comme point de départ. Ensuite, seules les règles réellement nécessaires sont adaptées. C’est plus traçable qu’une collection entièrement libre de signatures individuelles dont personne ne comprend plus la logique par la suite.

L’activation ou la désactivation de Firewall Acceleration ou PKI Acceleration redémarre le service IPS, également appelé DPI Engine. Ces changements ne doivent donc pas être effectués pendant une analyse d’incident en production ou dans une fenêtre de maintenance courte sans plan.

Choisir la bonne IPS Policy

Les IPS Policies doivent correspondre au trafic. La policy la plus stricte n’est pas automatiquement la meilleure.

• Clients vers Internet: Policy client ou LAN-to-WAN. Tenir aussi compte de Web, Application Control et TLS Inspection.
• Internet vers serveur interne via DNAT: Policy serveur ou serveur web. Surveiller précisément le système cible, les ports et les faux positifs.
• VPN de site: Policy selon les systèmes source et cible. Tester les performances, MTU/MSS et les applications.
• VoIP: très prudente et spécifique. SIP/RTP ne doit pas être cassé par des signatures trop agressives.
• Réseaux de management: ciblée et restrictive. Tester les accès admin, le monitoring et le trafic de sauvegarde.

IPS est également utile aux limites de segmentation: client vers serveur, VPN vers serveur, management vers infrastructure. Cela rend les mouvements latéraux plus difficiles après une première compromission. L’ordre des règles de firewall reste toutefois déterminant. IPS ne protège que le trafic qui passe réellement par une règle avec une IPS Policy sélectionnée.

Une IPS Policy personnalisée est utile lorsqu’une policy standard est trop large ou lorsque seules certaines signatures avec une action adaptée sont nécessaires. Il ne faut toutefois pas désactiver des signatures sans plan. Il faut d’abord savoir quel trafic est concerné, quelle signature s’est déclenchée et s’il s’agit vraiment d’un faux positif.

Construire proprement des IPS Policies personnalisées

Les IPS Policies personnalisées doivent être clonées à partir d’une policy existante puis ajustées de manière ciblée. Les règles d’IPS Policy contiennent des signatures et une action. Le firewall évalue ces règles de haut en bas. Une règle trop large placée au-dessus d’une règle spécifique peut donc masquer le comportement souhaité.

Lorsqu’on ajoute une règle d’IPS Policy, on sélectionne les signatures. Elles peuvent être filtrées selon Category, Severity, Platform et Target. Des signatures IPS personnalisées peuvent être ajoutées pour des cas particuliers. Cela ne doit se faire que si le cas de détection est clairement décrit et si la policy sera réexaminée ultérieurement.

Pour les signatures, les champs suivants sont particulièrement importants:

• SID: ID de signature unique pour les logs, tickets et exceptions.
• Category: domaine technique, par exemple navigateur, système d’exploitation, DNS, RPC ou malware.
• Severity: gravité de la menace.
• Platform: plateforme cible, par exemple Windows, Linux ou composants liés au navigateur.
• Target: signature liée au client ou au serveur.
• Recommended action: action standard recommandée par Sophos.

La sévérité ne doit pas être interprétée au ressenti. Sophos associe grossièrement Critical à CVSS 9 à 10, Major à 7 jusqu’à moins de 9, Moderate à 4 jusqu’à moins de 7 et Minor à 1 jusqu’à moins de 4 ou à des signatures moins critiques. Warning indique un trafic suspect et est traité comme alerte. Pour la policy, cela signifie qu’une signature Major sur un serveur exposé ne se juge pas comme une détection Warning dans un réseau de test.

L’action dans une règle de policy peut remplacer l’action de signature recommandée. C’est utile, mais risqué. Un Allow packet, Disable ou Bypass session généralisé peut supprimer une protection sans que cela soit immédiatement visible au quotidien.

Les actions basées sur les paquets inspectent chaque paquet. Les actions basées sur la session inspectent jusqu’à la première détection puis agissent sur la session. Drop session, Reset et Bypass session sont donc des interventions plus fortes que l’autorisation ou le rejet d’un paquet individuel.

Gestion pratique des actions:

• Recommended: Standard pour la plupart des règles de production. Le comportement dépend de la signature.
• Allow packet: Observation sans blocage, par exemple en pilote. L’attaque n’est pas empêchée.
• Drop packet: Rejeter des paquets individuels. Peut perturber des applications.
• Drop session: Terminer la session lorsqu’une attaque doit être empêchée. Intervention plus forte dans le trafic de production.
• Reset: Réinitialiser activement la session TCP. L’utilisateur ou l’application voit des interruptions nettes.
• Disable: Désactiver la signature. La protection disparaît pour cette signature.
• Bypass session: Ne plus analyser le reste de la session. Selon l’architecture, ce trafic peut passer par FastPath ou être offloadé. Cela peut retirer plus de trafic de l’inspection que prévu.

Pour les policies de production, une courte note de changement est donc utile: quelle signature a été modifiée, pourquoi, dans quelle policy, pour quelle règle de firewall et jusqu’à quand l’adaptation sera réexaminée.

Utiliser IPS dans les règles de firewall

IPS n’est pas seulement activé globalement. La policy doit aussi être utilisée dans la règle de firewall appropriée.

1. Ouvrir Rules and policies > Firewall rules.
2. Modifier ou créer la règle concernée.
3. Sous Other security features, activer Detect and prevent exploits (IPS).
4. Sélectionner l’IPS Policy adaptée.
5. Activer le logging de la règle.
6. Enregistrer la modification.
7. Tester le trafic de manière contrôlée.

Si la règle de firewall ne contient aucune IPS Policy, l’activation globale d’IPS n’a aucun effet sur ce trafic.

Lorsque plusieurs règles se chevauchent, l’ordre est déterminant. Si le trafic correspond à une règle sans IPS, l’IPS Policy d’une règle ultérieure n’aide pas. Dans ce cas, La règle Sophos Firewall ne s’applique pas: vérifier les causes est le meilleur article de suite.

Déploiement dans les environnements de production

IPS doit être introduit progressivement.

1. Commencer avec des règles pilotes

Choisir d’abord une petite règle bien connue, par exemple un réseau client de test ou une seule règle DNAT. Ensuite, vérifier les logs et tester avec de vraies applications.

2. Évaluer les détections

Filtrer les événements IPS dans le Log viewer. Les éléments importants sont la source, la destination, le service, la règle, la signature, le SID, la Severity, l’action et l’heure. Si plusieurs modules de protection sont impliqués, il faut examiner ensemble Web, Application Control, SSL/TLS Inspection et les logs de firewall.

3. Délimiter les faux positifs

Si du trafic légitime est bloqué, il ne faut pas désactiver IPS globalement tout de suite. Une analyse étroite est préférable:

• Quelle signature s’est déclenchée?
• Quelle application ou quel service était concerné?
• Cela concerne-t-il un hôte, un réseau ou seulement un port?
• Le système cible est-il à jour?
• Une règle de firewall plus stricte est-elle possible?
• Une IPS Policy adaptée suffit-elle au lieu d’une exception globale?

4. Étendre progressivement

Ce n’est que lorsque la règle pilote est stable qu’IPS doit être déployé sur d’autres règles. En particulier pour la VoIP, les systèmes ERP, les protocoles industriels, les liaisons VPN et les anciennes applications, il faut des fenêtres de test et un plan de retour arrière.

Contrôler les exceptions et les changements de signatures

Les exceptions IPS sont des décisions de sécurité. Lorsqu’une signature perturbe du trafic légitime, une adaptation peut être nécessaire. Il ne faut cependant pas affaiblir toute l’IPS Policy par réflexe ni désactiver IPS sur la règle. Il faut d’abord savoir s’il s’agit vraiment d’un faux positif ou si la signature rend visible un risque réel.

Avant une exception, collecter au minimum:

• ID et nom de signature: montre quelle détection s’est déclenchée.
• Source, destination, service et règle de firewall: délimite le trafic concerné.
• Heure et fréquence: distingue un événement isolé d’un schéma récurrent.
• Application ou protocole: aide à évaluer si le trafic est légitime.
• Niveau de patch du système cible: réduit le risque d’autoriser un vrai exploit.
• Packet Capture ou extrait de log: fournit une preuve avant la modification de policy.

Si une exception est nécessaire, elle doit être aussi étroite que possible:

• désactiver une signature individuelle plutôt qu’une catégorie complète
• utiliser une IPS Policy personnalisée exactement pour la règle de firewall concernée
• vérifier l’ordre des règles de policy afin que les règles spécifiques ne soient pas masquées par des règles larges
• restreindre davantage source, destination et service dans la règle de firewall
• documenter l’exception avec motif, owner et date de review
• après la modification, vérifier que seul le trafic attendu est concerné

Une exception temporaire est souvent meilleure qu’une désactivation durable. Après une mise à jour applicative, une mise à jour firmware ou un patch du système cible, l’exception doit être réexaminée. Si de nombreuses signatures gênent la même application, une policy personnalisée ou une segmentation propre est généralement préférable à une grande exception globale.

Logging et troubleshooting

L’analyse IPS demande plusieurs angles de vue.

• Log viewer: Détections IPS, signature, action, source, destination, règle.
• ips.log: indications plus détaillées sur les décisions IPS, DPI et Application Control.
• Packet Capture: flux de paquets, rule ID, NAT ID, IPS policy ID et direction.
• Test de règle: vérification de la règle de firewall qui correspond réellement.
• Syslog ou Central Reporting: conservation plus longue et corrélation.

L’article Troubleshooting Sophos Firewall: services et logs classe ips.log et les fichiers de logs associés. Pour la combinaison Log Viewer et Packet Capture, voir Tester une règle Sophos Firewall avec Log Viewer et Packet Capture. Si des paquets sont rejetés de manière inattendue, Analyser les paquets rejetés sur Sophos Firewall aide.

Le service IPS affiche DEAD

Sous SFOS 22.0 GA et versions ultérieures, le service IPS peut, dans de rares cas, passer à l’état DEAD. Il ne peut alors plus être redémarré, et les pattern updates IPS ainsi que les services Web Policy qui en dépendent peuvent échouer. Dans un cluster HA, chaque nœud peut être affecté indépendamment.

La commande read-only suivante affiche dans l’Advanced Shell toutes les lignes de service dont le nom contient ips:

service -S | grep -i ips

La ligne pertinente est celle dont le premier nom de service est exactement ips; les services aux noms similaires tels que ipsec-monitor ne sont pas concernés. Si le service IPS est à l’état DEAD et que les pattern updates échouent, il faut consigner la version SFOS, l’heure, le nœud HA concerné et la sortie d’état complète, puis sauvegarder ips.log et sig_upgrade.log avant de contacter Sophos Support. La commande seule ne prouve pas la présence du problème connu NC-181971. Sophos n’indique actuellement aucune version corrigée et ne fournit le workaround que par l’intermédiaire du Support; des tentatives de redémarrage répétées ou des commandes de réparation non documentées ne constituent donc pas une solution propre.

Tenir compte des performances

IPS consomme des ressources. L’augmentation de charge dépend du modèle, du trafic, des signatures activées, de TLS Inspection, d’Application Control, du VPN, de la taille des paquets et du débit.

Avant et après l’activation, vérifier:

• Charge CPU et mémoire
• Charge liée à IPS et DPI
• Débit sur les interfaces concernées
• Latence et retransmissions pour les applications critiques
• Volume de logs et charge syslog
• Messages des utilisateurs ou des applications après la modification

Si un problème de débit est suspecté, il ne faut pas simplement désactiver IPS et clore le cas. Une comparaison avec une méthode de test claire est préférable, par exemple avec Interpréter correctement les données de performance Sophos Firewall et Tester les performances Sophos Firewall avec iPerf.

Erreurs typiques

• IPS Protection est désactivé globalement.
• Network Protection a expiré ou n’est pas actif.
• Aucune IPS Policy n’est sélectionnée dans la règle de firewall.
• Le trafic correspond à une autre règle que prévu.
• Une règle IPS Policy trop large est placée au-dessus d’une règle spécifique et la masque.
• Le logging est désactivé sur la règle concernée.
• Une policy serveur est appliquée au trafic client ou inversement.
• La VoIP ou des protocoles spéciaux sont inspectés avec une policy agressive sans phase pilote.
• Les faux positifs sont résolus par une désactivation globale au lieu d’une adaptation étroite.
• Des signatures sont désactivées sans preuve, owner ou date de review.
• Après l’expiration d’un essai, personne ne vérifie si les signatures ou policies sont encore disponibles.
• Les problèmes de performance ne sont pas comparés avec des valeurs mesurées avant et après la modification.

Checklist d’exploitation

• Network Protection ou licence d’essai vérifiée.
• IPS Protection activé sous Protect > Intrusion prevention > IPS policies.
• Signatures et pattern updates vérifiés.
• IPS Policy adaptée sélectionnée par règle de firewall.
• Logging de règle activé.
• Règle pilote testée avec du trafic réel.
• Log viewer et ips.log vérifiés.
• Processus de faux positifs défini.
• Exceptions IPS documentées étroitement et réexaminées plus tard.
• Les IPS Policies personnalisées ne contiennent pas de règles Allow, Disable ou Bypass session non justifiées.
• Performance comparée avant et après l’activation.
• Exceptions critiques documentées et dotées d’une date de review.

Thèmes connexes de Security Inspection

IPS n’est qu’un élément de Security Inspection. Selon le problème ou l’objectif de déploiement, un autre article peut être plus adapté:

• Activer IPS, choisir une policy et vérifier les faux positifs: Cet article.
• Contrôler les catégories web, les Web Policies et le trafic web des utilisateurs: Configurer Sophos Firewall Web Protection avec Web Policies.
• Déchiffrer et inspecter le trafic web chiffré: Déployer correctement Sophos Firewall TLS Inspection.
• Vérifier les fichiers et téléchargements avec sandbox ou ML: Comprendre et exploiter Sophos Firewall Zero-Day Protection.
• Bloquer des IP, domaines ou URL malveillants connus: Configurer et exploiter Sophos Firewall Threat Feeds en sécurité.
• Réduire les schémas simples de spoofing ou de flooding: Vérifier Sophos Firewall Spoof Protection et DoS Settings.
• Sécuriser des serveurs publics avec NAT et IPS: Publier des serveurs via DNAT sur Sophos Firewall.
• Analyser des drops inattendus, une rule ID ou une IPS policy ID: Analyser les paquets rejetés sur Sophos Firewall.

La logique de protection reste ainsi compréhensible: les règles de firewall limitent le trafic autorisé, IPS vérifie ce trafic à la recherche de schémas d’attaque, Web Protection contrôle les contenus web, TLS Inspection apporte davantage de visibilité sur HTTPS et Zero-Day Protection complète l’analyse des fichiers et téléchargements.

FAQ