Créer et tester des signatures IPS personnalisées sur Sophos Firewall

Une signature IPS personnalisée est utile lorsque Sophos ne fournit pas de signature adaptée à un motif réseau ou applicatif clairement défini. Elle peut, par exemple, détecter une chaîne connue en clair, une caractéristique inhabituelle d’un protocole ou une combinaison précise de port, de sens du trafic et de charge utile.

La signature seule ne protège encore rien. Elle doit être utilisée dans une politique IPS, cette politique doit être associée à la règle de pare-feu effectivement appliquée et le flux de données doit être visible par l’IPS. Un motif trop large peut bloquer du trafic légitime ; un motif trop restrictif ne déclenchera aucune détection.

Tester d’abord toute nouvelle signature dans une règle IPS pilote avec Action: Allow packet. Même si Recommended action indique déjà Allow packet, c’est l’action de la règle de la politique IPS qui fait foi. Drop packet, Drop session, Reset ou Bypass session modifient le trafic de production et ne doivent être mis en service qu’après des tests positif et négatif reproductibles.

Six étapes pour un pilote maîtrisé

1. Décrire le cas de détection en précisant le protocole, le sens du trafic, le port et un motif sans ambiguïté.
2. Sous Intrusion prevention > Custom IPS signatures, créer une signature avec une règle restrictive et Recommended action: Allow packet.
3. Ajouter la signature à une règle dédiée dans une politique IPS pouvant être supprimée, puis y sélectionner Action: Allow packet.
4. Affecter cette politique IPS uniquement à la règle de pare-feu pilote prévue et y activer Log firewall traffic.
5. Générer un test correspondant au motif et un autre volontairement non correspondant, puis comparer les résultats dans Log Viewer, ips.log et la correspondance avec la règle.
6. Ne modifier l’action de la règle de la politique IPS qu’après une validation stable ; en cas de détections inattendues, rétablir l’affectation précédente de la politique.

Une entrée enregistrée ou une vérification syntaxique réussie ne prouve pas encore le bon fonctionnement. La réussite signifie que le test positif correspond exactement à la signature personnalisée et à la règle de pare-feu attendues, que le test négatif ne déclenche aucune détection et que le comportement de l’application en production reste inchangé.

Quand utiliser une signature personnalisée

Les signatures personnalisées conviennent à une caractéristique stable, visible au niveau des paquets ou du flux. Il peut s’agir d’une valeur de protocole propriétaire, d’un indicateur clair d’exploitation ou d’une protection temporaire contre une vulnérabilité connue en interne. Le chemin de traitement attendu des données et la réaction souhaitée doivent être définis avant de rédiger la règle.

Pour des adresses IP ou des domaines variables, les hôtes, services et groupes, les flux de renseignements sur les menaces ou des règles de pare-feu restrictives sont généralement mieux adaptés. Une signature personnalisée ne remplace par ailleurs ni la gestion des correctifs ni une règle correctement conçue par l’éditeur. Pour une détection ponctuelle dans les journaux, un développement personnalisé permanent est rarement proportionné.

Les données utiles chiffrées constituent une limite importante. L’IPS ne peut détecter un motif content dans la charge utile HTTPS que si le contenu est effectivement déchiffré dans le chemin de traitement choisi et visible par le moteur. Sans inspection TLS adaptée, seules les caractéristiques non chiffrées ou visibles par d’autres moyens restent normalement exploitables.

Vérifier au préalable la licence et le cycle de vie

Pour activer l’IPS, il faut un abonnement Network Protection actif ou une licence d’essai valide, ainsi qu’un accès administrateur permettant de gérer la signature, la politique et la règle de pare-feu. Avant le pilote, consigner l’affectation actuelle de la politique et l’ID de la règle, et conserver une sauvegarde pour le retour arrière. Le délai de 30 jours indiqué ci-dessous commence à l’expiration de la licence ou à la désactivation manuelle de l’IPS, et non à la tentative de configuration suivante.

Il n’est pas possible de configurer des signatures personnalisées lorsque la période d’essai IPS a expiré ou que IPS Protection est désactivé sous Intrusion prevention > IPS policies. Sophos recommande de réactiver l’IPS dans les 30 jours si les signatures personnalisées existantes doivent être conservées. Une sauvegarde ou un export doit donc faire partie du plan de retour arrière avant toute modification de licence, de l’IPS ou toute modification importante des politiques.

L’IPS doit ensuite être activé globalement et la règle de pare-feu qui traite le trafic doit disposer d’une politique IPS. La configuration de base complète est décrite dans Configurer l’IPS de Sophos Firewall et le tester en toute sécurité. Une signature personnalisée complète ce chemin de traitement des données ; ce n’est pas un mécanisme de protection parallèle.

Délimiter clairement la syntaxe des règles

Limites de la documentation pour SFOS 22/23 : L’aide syntaxique contient des exemples dont la mise en forme est contradictoire : distance: 4.within:4; n’est pas un modèle fiable à copier ; pour byte_jump, le texte explicatif mentionne des opérandes de comparaison absents du schéma syntaxique. Les libellés des bits TCP réservés sont également ambigus. Ces passages ne sont pas interprétés comme des capacités supplémentaires du moteur. Les fragments expliqués ci-dessous restent des exemples documentaires, et non des règles testées sur un pare-feu. Si une règle est rejetée ou semble ambiguë, conserver le build exact, la règle et le message d’erreur, puis demander une clarification au support Sophos ; en attendant, ne pas autoriser d’action de blocage en production.

Le formulaire de saisie sépare Protocol et Custom rule. Dans la règle, les différents mots-clés sont associés à leurs valeurs et à un point-virgule. Plus le nombre de caractéristiques indépendantes devant correspondre est élevé, plus le risque de détections fortuites est généralement faible. Toutefois, la signature ne doit pas devenir si spécifique qu’une modification anodine du protocole la rende inefficace.

Pour un test en clair exclusivement contrôlé, on peut utiliser TCP comme protocole et, par exemple, le motif restrictif suivant pour la charge utile :

content:"AVANET-IPS-PILOT"; nocase;

AVANET-IPS-PILOT est une valeur documentaire délibérément reconnaissable. La règle de pare-feu pilote correspondante est également limitée au service de test, par exemple au port TCP 8080. Le jeton, le sens du trafic et le port sont remplacés par des valeurs présentes dans le flux réel visible par l’IPS. Cet exemple n’est pas une signature d’attaque universelle et ne doit pas être appliqué tel quel à des règles de production de portée large.

Charge utile et fenêtre de recherche

content recherche une séquence de caractères ou d’octets ; les valeurs binaires sont placées entre des caractères de barre verticale. nocase ignore la casse lors d’une correspondance de contenu, tandis que rawbytes travaille sur les données brutes. depth et offset limitent la recherche de manière absolue dans la charge utile, tandis que distance et within travaillent relativement à la correspondance précédente. uricontent, isdataat et pcre couvrent des besoins plus spécifiques liés aux URI, aux positions et aux expressions régulières.

Une plage de recherche restreinte réduit les détections fortuites et la charge de calcul. En particulier, pcre, les grandes fenêtres ou plusieurs motifs de contenu larges ne doivent être introduits qu’avec des paquets réalistes et sous surveillance de la charge. Si depth est inférieur à la longueur du motif de contenu recherché, la signature ne peut jamais correspondre.

Les modificateurs nocase, rawbytes, depth, offset, distance et within se rattachent à content ; ce ne sont pas des règles de détection indépendantes. Sans depth, la recherche s’étend de offset jusqu’à la fin de la charge utile. Sans within, la recherche d’un deuxième motif de contenu reste elle aussi ouverte de distance jusqu’à la fin. Un point de départ seul ne suffit donc pas à maintenir une fenêtre de recherche restreinte. uricontent parcourt l’URI normalisée de la requête, et non des données utiles quelconques. isdataat vérifie la présence de données à une position donnée ; avec relative, cette position est définie par rapport à la fin de la correspondance de contenu précédente.

En-têtes, flux et valeurs structurées

La source, la destination et le port peuvent être restreints avec srcaddr, dstaddr, srcport et dstport. Pour les en-têtes IP, on dispose notamment de ttl, tos, id, ipopts, fragoffset, fragbits, dsize, ip_proto et samip. Les caractéristiques TCP sont décrites avec flags, flow, seq, ack et window ; itype, icode, icmp_id et icmp_seq s’appliquent à ICMP. rpc, byte_test et byte_jump sont destinés aux protocoles structurés ou binaires.

flow ne s’applique qu’à TCP. to_server et from_client sont équivalents, tout comme to_client et from_server. bi_direction étend la détection aux deux sens ; en cas de contrainte sur le port, le test négatif doit donc aussi tenir compte du trafic retour. Le choix entre no_stream et only_stream ne doit pas être confondu avec une vérification de taille de paquet : dsize vérifie la taille de la charge utile d’un paquet et ne correspond pas aux paquets reconstitués à partir d’un flux. Une combinaison avec only_stream n’est donc pas adaptée. En l’absence de détection, il faut d’abord déterminer si la caractéristique doit être recherchée dans le paquet individuel ou dans le flux reconstitué, plutôt que de modifier uniquement la taille ou le motif de contenu.

Pour les règles complexes, la syntaxe Custom IPS prise en charge par SFOS 22 et décrite ci-dessus s’applique. Les mots-clés Snort non documentés ou les règles copiées depuis d’autres moteurs ne doivent pas être repris sans vérification.

Opérandes : adresse, port, URI et position des données

Les fragments suivants doivent être saisis dans Custom rule, et non dans le shell. Ils constituent une référence pour SFOS 22/23, et non des signatures d’attaque déjà testées. Seules les conditions adaptées au cas de détection sont combinées ; Protocol, la politique pilote et Allow packet restent des éléments du test décrit ci-dessus. Les crochets dans les modèles syntaxiques indiquent des parties facultatives et ne doivent pas être saisis.

• srcaddr:192.0.2.10; dstaddr:198.51.100.20; compare les IP source et destination à des adresses individuelles. Les adresses documentaires sont remplacées par les adresses de test observées ; on ne peut pas en déduire une prise en charge des sous-réseaux ou des listes d’adresses.

• srcport:40000; dstport:8080; compare les ports source et destination à des nombres. Le port de destination représente ici le service de test. Un port source client variable ne doit être fixé que s’il fait réellement partie du cas de détection ; sinon, les nouvelles connexions ne satisferont pas cette condition.

• uricontent:"/ips-pilot"; recherche le chemin à remplacer dans l’URI normalisée de la requête. Les motifs mêlant texte et données binaires sont également possibles. La comparaison doit correspondre à la valeur normalisée de l’URI, et pas seulement à sa représentation dans la barre d’adresse du navigateur.

• content:"AVANET-IPS-PILOT"; isdataat:50,relative; exige en plus la présence de données à la position 50 par rapport à la fin de cette correspondance de contenu. Sans relative, la position est absolue dans la charge utile. Le nombre est choisi en fonction de la structure réelle du protocole ; il vérifie la présence de données, et non leur contenu.

• content:"ABC"; content:"DEF"; distance:1; within:10; utilise deux motifs à remplacer avec une fenêtre de recherche relative. distance définit la distance à partir de la fin de la première correspondance, tandis que within limite la recherche suivante. Pour les fenêtres absolues, offset et depth reçoivent également des valeurs numériques, par exemple offset:4; depth:20; sur le content correspondant. Ces nombres sont choisis en fonction de la position et de la longueur réelles du motif ; ce ne sont pas des valeurs par défaut du protocole.

Expressions régulières avec pcre

Les formes de base sont pcre:"/REGEX/"; et pcre:"m/REGEX/";. Un ! placé avant le guillemet ouvrant inverse le résultat de l’expression, par exemple pcre:!"/AVANET-IPS-PILOT/i";. Il s’agit d’une condition de non-correspondance qui peut avoir une portée très large sans restriction supplémentaire. REGEX ou le jeton pilote est remplacé par le motif nécessaire. Les options sont placées après le / fermant, par exemple pcre:"/AVANET-IPS-PILOT/i";.

• i ignore la casse ; s permet à . de correspondre également aux sauts de ligne.
• m permet à ^ et $ de correspondre aussi aux débuts et fins de ligne dans le tampon. x ignore les caractères d’espacement non échappés dans le motif, sauf dans les classes de caractères.
• A ancre la correspondance au début du tampon. E lie $ uniquement à la fin réelle, et non à la position précédant un saut de ligne final.
• G inverse le comportement gourmand par défaut des quantificateurs ; un ? placé à leur suite l’inverse à nouveau.
• R commence relativement à la fin de la dernière correspondance de motif. U utilise des tampons d’URI décodés ; B n’utilise pas de tampons décodés.

Avant le pilote, il faut donc définir dans quel tampon et à partir de quelle position le motif doit s’appliquer. Une expression régulière correcte sur des données brutes ne correspond pas nécessairement à une URI décodée.

Lire des champs binaires : byte_test et byte_jump

byte_test lit un champ et vérifie sa valeur numérique. Le schéma est byte_test:COUNT,[!]OPERATOR,VALUE,OFFSET[,relative][,big|little][,NUMBER_TYPE,string];. COUNT est le nombre d’octets lus, OFFSET le point de départ dans la charge utile ; avec relative, le point de départ est relatif à la dernière correspondance de motif. VALUE est la valeur de comparaison. Les opérateurs documentés sont <, >, =, ! et & : inférieur, supérieur, égal, différent et ET bit à bit, respectivement. Un ! placé avant un opérateur de comparaison inverse son résultat. big ou little définit l’ordre des octets. Avec string, des chiffres sous forme de texte sont lus à la place d’un champ numérique binaire ; hex, dec et oct ne s’appliquent qu’à ce mode texte.

Exemple pour un champ binaire : byte_test:2,=,16,0,big; lit deux octets à partir de la position 0 de la charge utile en big-endian et compare la valeur à 16. Le nombre d’octets, la position, l’ordre des octets et la valeur de comparaison doivent provenir du protocole, et non de cet exemple. Une valeur numérique fortuite ne constitue pas une preuve d’attaque.

byte_jump, en revanche, lit une longueur et déplace la position pour les vérifications suivantes. Le schéma est byte_jump:COUNT,OFFSET[,relative][,multiplier FACTOR][,big|little][,string][,hex|dec|oct][,align][,from_beginning];. Les deux premiers opérandes définissent la largeur du champ et la position de lecture ; relative définit le décalage par rapport à la dernière correspondance de motif. multiplier multiplie la valeur lue pour déterminer la distance du saut. align arrondit cette distance à la limite de 32 bits suivante. Avec from_beginning, la distance du saut est appliquée depuis le début de la charge utile plutôt que depuis la position courante. string et les bases numériques ont la même fonction qu’avec byte_test.

byte_jump:2,0,big; est donc un fragment destiné à un champ de longueur sur deux octets au début de la charge utile, avec un ordre des octets explicitement choisi. Ce n’est pas une comparaison de taille ; l’opérateur de comparaison et la valeur de comparaison ne sont pas des opérandes de byte_jump. Pour les deux mots-clés de traitement des octets, big ou little est explicitement choisi pour les champs binaires multi-octets : il ne faut pas se fier à un ordre des octets par défaut déduit de la documentation. Vérifier d’abord le champ et la cible du saut dans la charge utile réelle de test, puis tester un cas positif et un cas négatif pour la condition suivante. Une longueur incorrecte peut déplacer la position de recherche au-delà du motif souhaité.

Champs IP, options et fragments

• ttl:64;, ttl:>64; et ttl:<64; comparent la durée de vie IP par égalité exacte, supériorité ou infériorité. tos:16; compare le champ TOS, et id:1234; le champ d’identifiant IP. Ces nombres donnés en exemple ne sont pas des valeurs de détection recommandées ; ils sont choisis en fonction de la caractéristique d’en-tête effectivement recherchée.
• ipopts:rr; vérifie la présence d’une option IP. Les valeurs autorisées sont rr (Record Route), eol (End of List), nop (No Operation), ts (Timestamp), sec (Security), lsrr (Loose Source Routing), ssrr (Strict Source Routing), satid (Stream Identifier) et any (une option IP quelconque). any exige donc une option, et non simplement un paquet IP quelconque.
• fragoffset:0; compare le décalage de fragment dans l’en-tête IP à un nombre décimal. Ce champ n’est pas le décalage de recherche du contenu dans la charge utile.
• fragbits vérifie M (More Fragments), D (Don’t Fragment) et R (Reserved). Un + placé en préfixe autorise d’autres bits en plus de ceux indiqués, * exige au moins un des bits indiqués et ! exige que les bits indiqués ne soient pas positionnés. Ainsi, fragbits:+M; vérifie que More Fragments est positionné, sans exclure d’autres bits.
• dsize:300;, dsize:>300;, dsize:<300; et dsize:300<>400; décrivent une taille exacte de charge utile, une comparaison supérieure/inférieure ou une plage. Les nombres se rapportent aux données utiles du paquet, et non à l’ensemble de la connexion. Les limites expliquées ci-dessus concernant les flux reconstitués restent applicables.
• ip_proto:6;, ip_proto:!6;, ip_proto:>6; et ip_proto:<6; comparent l’identifiant numérique du protocole dans l’en-tête IP, et non le port TCP/UDP. samip; n’a pas de valeur et exige des IP source et destination identiques.

Champs TCP et sélection du flux

flags vérifie les indicateurs TCP : S pour SYN, A pour ACK, F pour FIN, R pour RST, U pour URG et P pour PSH. Sans modificateur, flags:S;, par exemple, vérifie la présence de SYN seul. Un +, * ou ! placé en préfixe a la signification expliquée ci-dessus pour fragbits. flags:+S; autorise donc des indicateurs supplémentaires. L’aide présente un deuxième groupe d’indicateurs facultatif après une virgule, mais n’explique pas sa sémantique de comparaison. Il ne faut donc pas traiter flags:S,A; comme une instruction confirmée permettant d’ignorer ACK ; faire clarifier ce comportement pour le build installé avant de l’utiliser. Les cas particuliers des bits TCP réservés et de « l’absence d’indicateurs positionnés » ne sont volontairement pas proposés ici sous forme de syntaxe à copier ; ils nécessitent une règle confirmée pour la version concernée et ne doivent pas être déduits d’un libellé ambigu.

Pour flow, les sens déjà expliqués ainsi que established, no_stream et only_stream sont disponibles. flow:established; exige une connexion TCP établie. flow:no_stream; exclut les paquets de flux reconstitués, tandis que flow:only_stream; limite la détection à ces paquets. Ces fragments expliquent chaque choix individuellement et ne constituent pas une invitation à utiliser les deux options de flux ensemble. bi_direction reste l’extension au trafic aller et retour décrite ci-dessus.

seq:1234;, ack:1234; et window:4096; comparent respectivement le numéro de séquence TCP, le numéro d’acquittement et la taille de fenêtre à un nombre. Les valeurs exactes de séquence ou d’ACK changent d’une connexion à l’autre et ne sont pertinentes que si cette valeur précise fait partie du cas de détection. La fenêtre TCP n’est pas une fenêtre de recherche dans la charge utile.

ICMP et RPC

itype:8; et icode:0; comparent le type et le code ICMP. Tous deux prennent également en charge <, > et des plages telles que itype:3<>5; ; le type et le code sont des champs distincts. icmp_id:1234; et icmp_seq:1; comparent exactement l’identifiant ICMP et la valeur de séquence. Les valeurs sont choisies en fonction du cas ICMP souhaité et ne sont pas assimilées aux numéros de séquence TCP.

rpc:100000,2,*; vérifie, dans les requêtes SUNRPC-CALL, le numéro d’application 100000, la version 2 et une procédure quelconque. Le schéma est rpc:APPLICATION,VERSION,PROCEDURE; ; * est autorisé pour la version et la procédure, mais pas pour le numéro d’application. Les nombres sont remplacés par l’application, la version et la procédure recherchées. Un caractère générique ne dispense pas d’analyser le protocole : il laisse délibérément la partie concernée sans restriction et élargit ainsi la détection.

Créer une signature et l’affecter à une politique

Sous Intrusion prevention > Custom IPS signatures > Add, définir Name, Protocol, Custom rule, Severity et Recommended action. Un nom tel que PILOT-TCP-8080-AVANET-TOKEN rend visibles l’objectif et le périmètre du test. Severity décrit votre propre évaluation du risque ; cette évaluation ne prouve pas que le motif est malveillant.

Pour le premier essai, Recommended action reste sur Allow packet. Important : l’action de la règle de la politique IPS prend le pas sur cette recommandation. La règle pilote doit donc elle aussi utiliser Allow packet. Les autres actions ont des conséquences nettement plus importantes :

• Drop packet rejette uniquement le paquet correspondant.
• Drop session met fin à la session après la détection.
• Reset met fin à une session TCP et envoie un reset à l’origine.
• Bypass session autorise le trafic et ne vérifie plus le reste de la session.

Pour les actions portant sur la session, SFOS n’inspecte que jusqu’au premier paquet correspondant. Avant de passer de Allow packet à une telle action, il faut donc confirmer que ce premier déclenchement concerne bien la session visée.

Lors de l’enregistrement, SFOS reconfigure le moteur IPS. Si la RAM libre est suffisante, cette opération s’effectue sans interruption. Si la RAM libre est faible, le moteur peut redémarrer et provoquer une brève interruption. Même pour une signature apparemment mineure, les modifications doivent donc être effectuées dans une fenêtre sous surveillance. Après l’enregistrement, vérifier l’état de l’IPS et ips.log pour détecter un redémarrage ou des erreurs avant de poursuivre le pilote.

Après cette vérification préalable, enregistrer la signature avec Save, puis rouvrir son entrée : Protocol, Custom rule, Severity et Recommended action doivent correspondre aux valeurs prévues. Laisser Firewall Acceleration et PKI Acceleration inchangés pendant le pilote ; chaque activation ou désactivation redémarre l’IPS et fausse la comparaison. La vérification des zones, Trusted MAC, les paires IP-MAC et les exceptions DoS sont des mécanismes distincts décrits dans Protection contre le DoS et l’usurpation, et non des propriétés d’une signature personnalisée.

Vient ensuite la deuxième partie, souvent oubliée : sous Intrusion prevention > IPS policies, ouvrir une politique pouvant être supprimée et destinée au pilote, ajouter une règle, choisir Custom signature, sélectionner la signature et placer la règle spécifique au-dessus des règles plus larges. SFOS évalue les règles des politiques IPS de haut en bas. Enregistrer la règle de la politique avec Save, puis enregistrer également la politique IPS qui la contient avec Save. Rouvrir la politique et vérifier la sélection de signature et l’action enregistrées. Associer ensuite cette politique à la règle pilote effectivement appliquée sous Rules and policies > Firewall rules > [règle pilote] > Detect and prevent exploits (IPS) ; enregistrer également la règle de pare-feu et vérifier avec une nouvelle session.

Gérer le même objet de signature via l’API XML

Pour automatiser le pilote, on utilise l’objet XML IPSCustomSignature, et non une règle de politique IPS. La référence SFOS 22/23 désigne les opérations par Add Custom Signature, Update custom signature et Delete Custom Signature. L’accès, l’opération d’écriture explicite, la sauvegarde, l’analyse de la réponse et l’arrêt en cas de charge utile non clarifiée sont expliqués de manière centralisée dans Utiliser l’API XML en toute sécurité. Avant toute écriture, la définition de l’objet et l’opération doivent être confirmées dans API help du build installé ; aucune requête d’écriture exécutable supplémentaire n’est fournie ici.

Dans l’exemple d’objet, Name, Protocol, CustomRule, Severity et RecommendedAction se trouvent à l’intérieur de IPSCustomSignature. Name désigne la signature, et non la politique ou la règle de pare-feu. Le tableau des paramètres exige pour ce champ une chaîne scalaire de 15 caractères au maximum ; Delete exige également ce nom exact. Pour l’automatisation via l’API, choisir donc un nom court et unique, tel que IPS-PILOT-8080. Le nom d’exemple WebAdmin plus long indiqué ci-dessus n’est pas un modèle à copier pour l’API. Avant Update ou Delete, lire l’identité effectivement enregistrée et toutes les utilisations dans les politiques, plutôt que de déduire la cible à partir d’un SID ou d’une entrée portant un nom similaire.

Le tableau indique que les cinq paramètres sont obligatoires et scalaires pour Add/Update. Protocol autorise TCP, UDP, ICMP ou ALL ; Severity autorise Critical, Major, Moderate, Minor ou Warning. CustomRule contient la définition de la signature sous forme de chaîne. Le libellé Custom Rule du tableau, avec une espace, n’est pas l’écriture XML CustomRule. Son indication supplémentaire demandant de séparer les lettres par un point n’explique ni une conversion générale des règles ni l’échappement XML. Il ne faut donc pas modifier mécaniquement la syntaxe décrite ci-dessus en ajoutant des points, mais vérifier le contenu de la règle et l’encodage XML correct pour le build. L’exemple de l’éditeur utilise uniquement SignatureDefinition comme espace réservé ; cela ne produit pas une signature prête à l’emploi ni une signature dont la capacité à détecter du trafic malveillant est démontrée.

Ne pas confondre recommandation et action : L’exemple XML utilise RecommendedAction, tandis que le tableau des paramètres désigne le même sujet par Action. Il liste les valeurs textuelles Allow Packet, Drop Packet, Drop Session, Reset et Bypass Session, ainsi que 3. Cela ne constitue pas une autorisation confirmée de remplacer RecommendedAction par une balise XML Action. Aucune signification ni correspondance avec une action textuelle n’est expliquée pour 3 ; ne pas deviner cette valeur ni l’utiliser comme raccourci pour une action donnée. Relire la recommandation effectivement enregistrée et continuer à vérifier séparément l’action de la règle de la politique IPS. Un objet créé via l’API ne remplace ni l’affectation à une politique ni les tests positif et négatif.

Confronter les réponses de l’API à l’opération et à l’état enregistré

Les lignes suivantes sont documentées dans les références d’objets SFOS 22/23. Les noms Message.* restent des symboles documentaires non résolus : ils ne constituent ni des messages d’exécution garantis, ni des textes d’erreur traduits, ni des causes définitivement confirmées. Les nombres sont eux aussi des codes d’état XML, et non des codes d’état HTTP. Conserver ensemble l’opération, le code et la réponse réelle ; ne pas remplacer les lignes propres à l’objet par une interprétation générale des codes tirée de l’article central sur l’API.

Pour Add Custom Signature, la référence indique :

• 200 — Message.CustomSigAddSuccess
• 500 — Message.CustomSigAddFailed
• 502 — Message.CustomSigRecordExists
• 504 — Message.CustomSigInvalidSignatureRule
• 505 — Message.IPSpolicyEngineRestartFail
• 506 — Message.CustomSignatureIpsOff

Pour Update custom signature, elle indique :

• 200 — Message.CustomSigUpdateSuccess
• 500 — Message.CustomSigUpdateFailed
• 502 — Message.CustomSigRecordExists
• 504 — Message.CustomSigCustomSignatureCheck1
• 505 — Message.IPSpolicyEngineRestartFail
• 506 — Message.CustomSignatureIpsOff

C’est notamment 504 qui distingue Add d’Update par le symbole ; Message.CustomSigCustomSignatureCheck1 ne doit pas être réinterprété comme un message d’erreur syntaxique prétendument sans ambiguïté. Avant de relancer Add/Update, rouvrir l’entrée dans WebAdmin ou la vérifier avec une requête de lecture confirmée pour le build : Name, Protocol, Custom rule, Severity et Recommended action correspondent-ils à l’état souhaité ? En cas de 502, comparer l’identité existante à l’identité souhaitée, sans écraser automatiquement l’entrée ni la créer sous un deuxième nom. En cas de 504, confronter en plus la règle exacte à la documentation du build. En cas de 505, vérifier ensemble l’état enregistré, l’état de l’IPS et ips.log ; le symbole ne permet de conclure ni à un retour arrière garanti ni à l’autorisation de redémarrer le moteur. En cas de 506, contrôler l’état de l’IPS et de la licence comme indiqué dans la section sur le cycle de vie, mais ne pas activer ou désactiver l’IPS sur une simple supposition. Même après 200, il reste à vérifier les valeurs enregistrées, l’association à la politique et le chemin de traitement des données ; 500 ne prouve pas qu’aucune modification partielle n’a eu lieu.

Pour Delete Custom Signature, les lignes spécifiques suivantes sont documentées :

• 200 — Message.CustomSigDeleteSuccess
• 500 — Message.CustomSigDeleteFailed
• 503 — Message.CustomSignatureInUse
• 506 — Message.CustomSignatureIpsOff

N’autoriser Delete qu’après le retour arrière décrit ci-dessous et une vérification complète des utilisations. En cas de 503, examiner les références des politiques sur l’objet réel, sans supprimer globalement une politique de production. En cas de 506, clarifier l’état de l’IPS et de la licence plutôt que de désactiver globalement l’IPS pour tenter une suppression. Après la réponse, vérifier l’absence du nom exact et l’état attendu des politiques dépendantes ; en cas de 500 ou de réponse ambiguë, ne pas relancer aveuglément la suppression. Si l’état enregistré, la réponse ou les responsabilités restent incertains, arrêter l’automatisation et demander une clarification au support Sophos en fournissant la réponse expurgée, la version de la règle, le build et les journaux. Aucun comportement à l’exécution n’est présenté ici comme ayant été testé sur un pare-feu.

Effectuer les tests positif et négatif

Le test positif envoie le motif convenu via le port prévu et dans le sens attendu. Dans Log Viewer, en haut à droite de WebAdmin, sélectionner le module IPS et filtrer selon l’heure du test, Source et Destination. La signature ou le SID, l’action et l’horodatage doivent correspondre au test. ips.log fournit des détails complémentaires sur le moteur. Packet Capture, sous Diagnostics > Packet capture, affiche en plus Firewall Rule ID et IPS Policy ID. Le lien entre la règle, Packet Capture et le module de sécurité est expliqué dans Tester méthodiquement une règle de pare-feu.

Après la phase pilote, l’effet peut également être évalué sous Reports > Network & threats > Intrusion attacks. Le rapport est utile pour comparer des périodes, mais ne remplace pas les tests positif et négatif effectués rapidement dans Log Viewer. Les XGS 87/87w et XGS 88/88w ne prennent pas en charge les rapports locaux sur l’appareil ; sur ces modèles, effectuer les vérifications immédiates décrites dans Log Viewer.

Effectuer ensuite au moins un test négatif : le même service sans jeton, un autre port ou un sens différent. La signature ne doit pas déclencher de détection. Pour un motif de contenu, les requêtes normales de l’application sont également importantes, car des chaînes courtes ou génériques peuvent apparaître dans des charges utiles parfaitement légitimes.

Ce n’est que lorsque les deux tests sont stables que l’action de blocage prévue est définie, puis vérifiée à nouveau. Une signature bloquante n’est considérée comme validée que si le cas positif est précisément celui qui est arrêté, si le cas négatif continue de fonctionner et si aucune autre règle de pare-feu ou IPS n’est à l’origine de l’effet.

Vérifier le nombre de signatures

Le nombre peut être déterminé dans WebAdmin sans utiliser le shell. Sous Intrusion prevention > IPS policies, ouvrir une politique pouvant être supprimée et créer une nouvelle règle de politique. Avec Select all, SFOS affiche le nombre total au-dessus de Action. La liste n’est visible que lors de l’ajout d’une règle à une politique pouvant être supprimée ; la boîte de dialogue peut ensuite être fermée sans enregistrer.

Sophos documente également deux requêtes en lecture sous 5. Device management > 3. Advanced shell :

psql -U nobody -d signature -p 5434 -c "select count (*) from tblidprules;"
psql -U nobody -d corporate -c "select count (*) from tblidpcustomsignature;"

La première commande compte les signatures standard, la seconde les signatures personnalisées. Ces requêtes de base de données ne modifient rien, mais doivent être exécutées dans le cadre d’une session de support ou de diagnostic documentée. Le nombre n’est pas une preuve de qualité ni de bon fonctionnement et peut évoluer avec les mises à jour des motifs.

Pour chaque requête, le résultat attendu est une seule ligne sous count, suivie de (1 row). Les valeurs d’exemple Sophos 28623 et 1 proviennent d’un exemple sous SFOS 19.0.1 et ne sont pas des valeurs de référence pour SFOS 22/23. En cas d’erreurs de base de données, de connexion ou d’autorisations, ne modifier ni les tables ni les services : utiliser la vérification dans WebAdmin et conserver la sortie exacte ainsi que le build pour le support.

Si la signature ne fonctionne pas comme prévu

Aucune détection

Vérifier d’abord que l’IPS est actif, que le trafic correspond à la règle de pare-feu attendue avec la bonne politique IPS et que la signature personnalisée figure effectivement dans une règle de politique évaluée. Vérifier ensuite le protocole, le sens du trafic, le port, le chiffrement et la charge utile réelle. Une chaîne affichée dans un navigateur n’est pas nécessairement présente à l’identique dans le paquet réseau.

Une capture de paquets étroitement filtrée est utile pour montrer le sens du trafic, le port et le contenu visible à ce point de capture. Toutefois, l’absence d’un motif en clair dans une capture chiffrée ne prouve pas qu’il est absent du tampon IPS déchiffré. Vérifier donc ensemble le point de capture, le déchiffrement et la reconstitution du flux. Pour un test en clair contrôlé, le motif réellement transmis doit pouvoir être vérifié ; examiner ensuite offset, depth, distance, within, l’état du flux et l’ordre des règles de la politique.

Trop de connexions déclenchent la signature

La signature reste sur Allow packet jusqu’à ce que Source, Destination, le port, le sens du trafic ou la fenêtre de recherche soient davantage restreints. Les mots génériques, les courtes séquences binaires et les expressions régulières sans limites sont des causes typiques. Une règle de pare-feu de portée large rend en outre l’effet plus difficile à maîtriser.

Si le pare-feu présente une augmentation de la consommation de ressources ou un redémarrage de l’IPS après l’enregistrement, conserver l’horodatage, le modèle, le firmware, les ressources libres et ips.log. Enregistrer à répétition différentes variantes ne constitue alors pas un test rigoureux ; il faut d’abord clarifier la cause et définir une fenêtre de maintenance.

Revenir en arrière en toute sécurité

En cas de détections inattendues, retirer d’abord la règle personnalisée de la politique pilote ou rétablir la politique IPS précédente sur la règle de pare-feu. Vérifier ensuite de nouvelles sessions au moyen de tests positif et négatif. Ne supprimer la signature personnalisée que lorsqu’elle n’a plus aucun autre usage.

Avant la suppression, il convient de documenter les politiques, règles de pare-feu et applications qui l’ont utilisée. Les journaux, la version de la règle testée et le motif du retour arrière doivent figurer dans le dossier de suivi du changement. Désactiver globalement l’IPS ou supprimer toute la politique de production n’est pas un retour arrière approprié pour une seule signature défectueuse.

FAQ