Règles de signature avec Snort et Suricata

Snort et Suricata sont les deux principaux moteurs IDS/IPS à code source ouvert. Ils partagent un langage de règles largement compatible ; une règle écrite pour l'un fonctionne généralement sur l'autre.

Suricata ajoute le traitement multithread, des analyseurs de protocoles natifs, l'extraction de fichiers et une journalisation riche (EVE JSON) ; Snort 3 a modernisé son propre moteur de manière similaire. Apprendre une seule fois la syntaxe des règles vous donne un avantage sur les deux.

Chaque règle comporte deux parties : un en-tête et un corps d'options entre parenthèses. L'en-tête définit l'action, le protocole et la direction du trafic ; le corps définit les éléments à rechercher et la manière de les signaler.

L’en-tête se lit de gauche à droite :

• action — alerter, abandonner, rejeter, autoriser
• protocole — TCP, UDP, ICMP, IP (ou protocoles applicatifs dans Suricata : HTTP, DNS, TLS)
• IP/port source et IP/port de destination
• direction — -> unidirectionnelle ou <> bidirectionnelle

Des variables comme $HOME_NET et $EXTERNAL_NET proviennent de votre configuration afin que les règles restent portables d’un site à l’autre.

L’action détermine le comportement IDS ou IPS de cette règle :

• alert — consigner et notifier, sans bloquer le trafic (IDS)
• drop — supprimer silencieusement le paquet (IPS, uniquement en ligne)
• reject — supprimer le paquet et envoyer une réinitialisation TCP ou un message d’inaccessibilité ICMP
• pass — autoriser explicitement, en ignorant les règles suivantes

Le même moteur devient IDS ou IPS selon qu’il est déployé en ligne et selon les actions utilisées.

Le mot-clé content recherche une séquence d’octets dans la charge utile. Le texte est placé entre guillemets ; les données binaires sont placées entre barres verticales sous forme hexadécimale.

Les mots-clés d’ancrage affinent les correspondances : offset, depth, distance et within limitent l’emplacement où la séquence peut apparaître, ce qui améliore à la fois la précision et les performances.

Les règles modernes recherchent des correspondances dans des tampons adaptés au protocole plutôt que dans le flux brut. Après un mot-clé de tampon, les correspondances content suivantes s’appliquent à cette partie du protocole analysé.

• http_uri — l’URI de la requête
• http_header — les en-têtes de la requête ou de la réponse
• http_user_agent — l’agent utilisateur
• tls_sni / dns_query — le nom du serveur TLS / la requête DNS

Cette méthode est bien plus fiable que la recherche d’une sous-chaîne dans l’intégralité du paquet.

Lorsque les chaînes fixes ne suffisent pas, pcre permet d’utiliser des expressions régulières compatibles avec Perl. Associez un préfiltre content peu coûteux à pcre afin que l’expression régulière ne s’exécute que sur les paquets candidats, ce qui préserve les performances.

Le modificateur nocase rend une correspondance de contenu insensible à la casse, ce qui est important pour les en-têtes et les champs contrôlés par l’utilisateur que les attaquants peuvent faire varier.

L’option flow restreint une règle à l’état et à la direction de la connexion, ce qui réduit les faux positifs et le coût de traitement.

• established — uniquement pour les sessions TCP établies
• to_server / to_client — direction de la requête ou de la réponse

Rechercher les réponses du serveur uniquement lorsque la connexion est établie et dans la direction to_client évite de déclencher la règle sur des paquets isolés ou usurpés.

Les options de gestion facilitent la maintenance d’un ensemble de règles :

• sid — identifiant de signature unique (utilisez 1000000 ou plus pour les règles locales)
• rev — numéro de révision, à incrémenter à chaque modification
• msg — texte de l’alerte visible par les analystes
• classtype — catégorie qui détermine la priorité
• reference — lien vers un CVE ou un avis de sécurité

Des identifiants de signature stables et des numéros de révision incrémentés permettent de suivre et de mettre à jour les règles sans perturber les tableaux de bord ni les suppressions d’alertes.

Bien que leurs règles soient compatibles, ces moteurs offrent des fonctionnalités différentes :

• Suricata fonctionne avec plusieurs fils d’exécution, analyse nativement les protocoles applicatifs, extrait les fichiers, calcule les empreintes JA3 et produit des fichiers JSON EVE
• Snort 3 a entièrement réécrit son moteur pour améliorer les performances et fournir un système modulaire de modules d’extension

Certains mots-clés sont propres à un moteur. Suricata ajoute des mots-clés de la couche applicative (tls.sni, dns.query, http.method) ainsi que des fonctionnalités liées aux jeux de données et aux bits de flux. Lorsque vous partagez des règles, ciblez le plus petit dénominateur commun ou conservez des ensembles de règles propres à chaque moteur.

Pour éviter qu’une règle n’inonde la console, appliquez des seuils. detection_filter ne se déclenche qu’après N événements sur une période donnée ; threshold associé à limit plafonne le volume d’alertes.

C’est essentiel pour détecter les attaques par force brute et les balayages, lorsqu’un événement isolé n’a pas de signification mais qu’une rafale constitue le signal.

Lisez une règle et prédisez son comportement.

Vous pouvez désormais lire et écrire des signatures Snort/Suricata :

• Une règle = en-tête (action, protocole, source/destination, direction) + options du corps
• L’action détermine IDS ou IPS : alert, drop, reject, pass
• content associé à un décalage, une profondeur et une valeur hexadécimale recherche des octets dans la charge utile
• Les tampons persistants (URI HTTP, tls.sni, dns.query) recherchent des correspondances dans les champs analysés du protocole
• pcre et nocase gèrent les séquences variables
• flow restreint la recherche à un état et une direction
• Les identifiants, révisions, messages et références facilitent la maintenance des règles
• Les seuils limitent le bruit des attaques par force brute et des balayages

Ensuite : détecter les menaces sans aucune signature.