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 détecter une chaîne en clair connue, une caractéristique de protocole inhabituelle ou une combinaison précise de port, de direction et de payload.

La signature seule ne protège encore rien. Elle doit être utilisée dans une IPS policy, cette policy doit être affectée à la règle firewall réellement appliquée et le flux de données doit être visible par IPS. Un motif trop large peut bloquer du trafic légitime ; un motif trop étroit ne produit aucun résultat.

Tester d’abord toute nouvelle signature avec Allow packet et le logging sur un petit chemin pilote. Drop packet, Drop session, Reset et Bypass session modifient le trafic de production et ne doivent être utilisés qu’après un test positif et un test négatif reproductibles.

Un pilote contrôlé en six étapes

1. Décrire le cas de détection avec le protocole, la direction, le port et un motif univoque.
2. Sous Intrusion prevention > Custom IPS signatures, créer une signature étroite avec Allow packet.
3. Ajouter la signature à une règle dédiée dans une IPS policy supprimable.
4. Affecter cette IPS policy uniquement à la règle firewall pilote prévue et activer le logging.
5. Générer un test correspondant et un autre volontairement différent, puis comparer Log Viewer, ips.log et la règle appliquée.
6. Ne définir l’action prévue qu’après une validation stable ; retirer l’affectation de policy ou la signature en cas de résultats inattendus.

Une entrée enregistrée ou un contrôle de syntaxe réussi ne prouve pas encore le fonctionnement. Le succès signifie que le test positif déclenche exactement la Custom Signature et la règle firewall attendues, que le test négatif reste sans résultat et que l’application de production se comporte comme avant.

Quand une signature personnalisée convient

Les Custom Signatures conviennent à une caractéristique stable et visible au niveau du paquet ou du flux. Il peut s’agir d’une valeur de protocole propriétaire, d’un indicateur d’exploitation clair ou d’une protection temporaire pour une vulnérabilité interne connue. Le chemin des données et la réaction souhaitée doivent être définis avant la rédaction.

Pour des adresses IP ou domaines variables, les hôtes, services et groupes, les threat feeds ou des règles firewall étroites sont généralement plus adaptés. Une signature personnalisée ne remplace pas non plus la gestion des correctifs ni une règle maintenue par l’éditeur. Développer une signature permanente pour un événement de log unique est rarement proportionné.

Le payload chiffré constitue une limite importante. IPS ne peut détecter un motif content dans un payload HTTPS que si le contenu est réellement déchiffré et visible par le moteur dans le chemin de traitement choisi. Sans TLS Inspection adaptée, seuls les attributs non chiffrés ou visibles par ailleurs sont normalement disponibles.

Vérifier d’abord la licence et le cycle de vie

Les signatures personnalisées ne peuvent pas être configurées si la version d’essai IPS a expiré ou si IPS Protection est désactivé sous Intrusion prevention > IPS policies. Sophos recommande de réactiver IPS dans les 30 jours pour conserver les Custom Signatures existantes. Un backup ou un export doit donc figurer dans le plan de rollback avant toute modification de licence, d’IPS ou de policy importante.

IPS doit ensuite être actif globalement et la règle firewall qui traite le trafic doit disposer d’une IPS policy. La configuration de base complète est décrite dans Configurer et tester IPS en toute sécurité. Une signature personnalisée complète ce chemin de données ; elle ne constitue pas un mécanisme de protection parallèle.

Délimiter clairement la syntaxe de la règle

Le formulaire sépare Protocol et Custom rule. La règle combine des mots-clés, leurs valeurs et des points-virgules. Exiger la concordance de plusieurs caractéristiques indépendantes réduit généralement les résultats accidentels. La signature ne doit toutefois pas devenir si spécifique qu’une modification anodine du protocole la rende inefficace.

Pour un test en clair exclusivement contrôlé, sélectionner TCP comme protocole et utiliser par exemple ce motif de payload étroit :

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

AVANET-IPS-PILOT est une valeur de documentation volontairement distinctive. La règle firewall pilote correspondante est également limitée au service de test, par exemple au port TCP 8080. Le jeton, la direction et le port sont remplacés par des valeurs présentes dans le flux réel visible par IPS. Cet exemple n’est pas une signature d’attaque universelle et ne doit pas être appliqué tel quel à de larges règles de production.

Payload et fenêtre de recherche

content recherche une séquence de caractères ou d’octets ; les valeurs binaires sont placées entre des barres verticales. nocase ignore la casse pour une correspondance content, tandis que rawbytes travaille sur les données brutes. depth et offset limitent la recherche de manière absolue dans le payload ; distance et within agissent par rapport au résultat précédent. uricontent, isdataat et pcre couvrent des cas plus spécialisés d’URI, de position et d’expression régulière.

Une fenêtre de recherche étroite réduit les résultats accidentels et la charge de calcul. pcre, les grandes fenêtres ou plusieurs motifs content larges ne doivent notamment être introduits qu’avec des paquets réalistes et sous charge observée. Si depth est plus court que le motif content recherché, la signature ne pourra jamais correspondre.

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

La source, la destination et le port se limitent avec srcaddr, dstaddr, srcport et dstport. Les options d’en-tête IP comprennent notamment ttl, tos, id, ipopts, fragoffset, fragbits, dsize, ip_proto et samip. Les caractéristiques TCP utilisent 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.

La référence complète de la syntaxe IPS personnalisée de SFOS 22 reste la référence pour les règles complexes. 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.

Créer la signature et l’affecter à une policy

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 la fonction et la limite du test visibles. Severity exprime l’évaluation du risque choisie ; elle ne prouve pas que le motif est malveillant.

Pour le premier passage, Recommended action reste sur Allow packet. Les autres actions ont des conséquences bien plus importantes :

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

Lors de l’enregistrement, SFOS reconfigure le moteur IPS. Selon Sophos, cette opération s’effectue sans interruption si suffisamment de RAM est disponible. Avec peu de RAM libre, le moteur peut redémarrer et provoquer une brève interruption. Même une modification apparemment mineure doit donc être effectuée dans une fenêtre surveillée.

Vient ensuite la seconde partie souvent oubliée : sous Intrusion prevention > IPS policies, ouvrir une policy supprimable réservée au pilote, ajouter une règle, sélectionner la Custom Signature et placer cette règle précise au-dessus des règles plus larges. Affecter ensuite cette policy, sous Rules and policies > Firewall rules, à la règle pilote réellement appliquée.

Effectuer un test positif et un test négatif

Le test positif envoie le motif convenu sur le port et dans la direction prévus. Relever simultanément dans Log Viewer Firewall Rule ID, IPS policy, nom de signature, source, destination, action et heure. ips.log fournit des détails supplémentaires du moteur ; Tester systématiquement une règle firewall explique le lien entre règle, Packet Capture et module de sécurité.

Au moins un test négatif suit : le même service sans le jeton, un autre port ou une direction différente. La signature ne doit pas correspondre. Pour un motif content, les requêtes normales de l’application sont également importantes, car des chaînes courtes ou générales peuvent apparaître dans des payloads tout à fait légitimes.

Ce n’est qu’après la stabilité des deux tests que l’action de blocage prévue est définie et testée à nouveau. Une signature bloquante n’est validée que si elle arrête exactement le cas positif, laisse passer le cas négatif et qu’aucune autre règle firewall ou IPS ne produit cet effet.

Vérifier le nombre de signatures

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

Sophos documente également deux requêtes en lecture seule dans 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 par défaut et la seconde les Custom Signatures. Ces requêtes de base de données ne modifient rien, mais doivent rester dans une session de support ou de diagnostic documentée. Le nombre ne prouve ni la qualité ni le fonctionnement et peut varier avec les mises à jour de patterns.

Si la signature ne fonctionne pas comme prévu

Aucun résultat n’apparaît

Vérifier d’abord qu’IPS est actif, que le trafic rencontre la règle firewall attendue avec la bonne IPS policy et que la Custom Signature figure réellement dans une règle de policy évaluée. Examiner ensuite le protocole, la direction, le port, le chiffrement et le payload réel. Une chaîne affichée dans un navigateur ne se retrouve pas nécessairement telle quelle dans le paquet réseau.

Un Packet Capture filtré précisément aide à confirmer le contenu visible et la direction. Si le motif n’y figure déjà pas, une modification de la règle IPS ne peut pas le créer. Si les paquets sont visibles, contrôler offset, depth, distance, within, l’état du flux et l’ordre des règles de policy.

Trop de connexions correspondent

La signature reste sur Allow packet jusqu’à ce que la source, la destination, le port, la direction ou la fenêtre de recherche soient mieux limités. Les mots génériques, les courtes séquences binaires et les expressions régulières non bornées sont des causes typiques. Une règle firewall large rend l’effet encore plus difficile à contrôler.

Si la firewall présente une hausse des ressources ou un redémarrage d’IPS après l’enregistrement, conserver l’heure, le modèle, le firmware, les ressources libres et ips.log. L’enregistrement répété de variantes différentes ne constitue alors plus un test propre ; clarifier d’abord la cause et une fenêtre de maintenance.

Revenir en arrière en toute sécurité

En cas de résultats inattendus, retirer d’abord la règle personnalisée de la policy pilote ou rétablir l’ancienne IPS policy sur la règle firewall. Vérifier ensuite de nouvelles sessions avec les tests positif et négatif. Ne supprimer la Custom Signature que lorsqu’elle n’a plus aucun autre usage.

Avant la suppression, documenter la policy, la règle firewall et l’application qui l’utilisaient. Les logs, la version testée de la règle et le motif du rollback font partie de la preuve du changement. Désactiver IPS globalement ou retirer toute la policy de production n’est pas un rollback adapté à une seule signature défectueuse.

FAQ