Skip to main content

Chapitre 2.2 Quiz - IDS/IPS : Signatures, detection d'anomalies et evasion

Mode Quiz - Toutes les reponses sont masquees. Tentez chaque question avant de reveler la reponse.

Question 1​

Vous deployez une regle Suricata avec le mot-cle content correspondant a "passwd" dans l'URI HTTP. Lors des tests, un attaquant utilise l'URL /etc%2Fpasswd. Votre regle ne se declenche pas. Quelle est la cause la plus probable, et quelle est la correction ?

Reveler la reponse et l'explication

Reponse : Le mot-cle content correspond au tampon URI brut (non normalise). %2F est la forme encodee URL de /, donc les octets litteraux dans le paquet sont %2Fpasswd, pas /passwd.

Correction : Utiliser le modificateur de tampon http_uri, qui applique la normalisation HTTP de Suricata (decodage d'URL) avant la correspondance :

alert http any any -> $HTTP_SERVERS any (
    msg:"Tentative LFI - /etc/passwd";
    content:"etc"; http_uri; nocase;
    content:"passwd"; http_uri; nocase; distance:0;
    sid:9900010;
    rev:1;
)

http_uri invoque l'inspecteur HTTP, qui decode %2F en /, %252F en %2F (double encodage), et simplifie les sequences /../. La correspondance se declenche maintenant sur /etc%2Fpasswd, /etc/./passwd, /%65tc/passwd (e encode en hexadecimal), etc.

Contexte approfondi : La normalisation HTTP est un processus a plusieurs etapes ; le double encodage (%252F en %2F en /) necessite deux passes de decodage. Configurer double_decode: yes dans la configuration HTTP de Suricata pour gerer cela. Cela correspond a l'evasion de T1027 (Fichiers ou informations obscurcis).

Question 2​

Un attaquant execute nmap -sS -T0 --randomize-hosts 10.0.0.0/24. Votre preprocesseur Snort sfportscan est configure pour se declencher apres 15 sondes en 60 secondes depuis une seule source. Ce scan declenche-t-il l'alerte ? Pourquoi ou pourquoi pas ? Quel mecanisme de detection permettrait de le capturer ?

Reveler la reponse et l'explication

Reponse : Avec -T0 (timing paranoide), Nmap envoie une sonde environ toutes les 5 minutes et randomise l'ordre des cibles. Sur un /24 (254 hotes), la duree totale du scan est d'environ 21 heures. Dans n'importe quelle fenetre de 60 secondes, au plus 1 a 2 sondes proviennent du scanner - bien en dessous du seuil de 15 sondes. L'alerte sfportscan ne se declenche pas.

Ce qui le detecte :

  1. Agregation comportementale sur longue fenetre - Analyse NetFlow/IPFIX avec une fenetre de plusieurs heures. Des outils comme Zeek avec des analyses personnalisees ou une requete SIEM sur les journaux de connexion peuvent detecter une seule source touchant de nombreuses destinations uniques sur des heures.
# Zeek conn.log : compter les IPs de destination uniques par source sur les 24 dernieres heures
cat conn.log \
  | zeek-cut id.orig_h id.resp_h \
  | awk '{count[$1][$2]=1} END {for(src in count) print length(count[src]), src}' \
  | sort -rn | head -20

  1. Anomalie de flux SYN uniquement - Les scans SYN furtifs (-sS) ne completent jamais la poignee de main a trois voies. Une IP source avec des centaines de flux SYN uniquement (sans SYN-ACK correspondant de la cible ni ACK de la source) est une valeur aberrante statistique independamment du timing.

  2. Detection de scan distribue - Si l'attaquant utilise -D (leurres) ou plusieurs IPs sources, les seuils par source echouent entierement. La detection necessite une correlation entre les sources (patterns de destination partages, meme timing de scan).

Cela correspond a T1046 (Decouverte de services reseau).

Question 3​

Expliquez la technique d'empreinte JA3. Pourquoi offre-t-elle une valeur de detection contre le trafic C2 chiffre en TLS, et quelles sont ses limites ?

Reveler la reponse et l'explication

Reponse : JA3 hache un ensemble de champs du message TLS ClientHello - des champs determines par la bibliotheque cliente TLS (pas le payload applicatif) : version TLS, liste de suites de chiffrement (dans l'ordre), liste d'extensions (dans l'ordre), courbes elliptiques, et formats de points de courbe elliptique. Le hachage MD5 de ces valeurs concatenees est l'empreinte JA3.

JA3 = MD5(SSLVersion,Ciphers,Extensions,EllipticCurves,EllipticCurvePointFormats)

Pourquoi elle a une valeur de detection :

  • Un framework C2 specifique (par ex. Cobalt Strike avec le profil par defaut) produit un JA3 coherent independamment du payload. La bibliotheque TLS de la balise est identifiable meme si le payload est chiffre.
  • Les hachages JA3 malveillants connus sont publies par des sources de renseignement sur les menaces et peuvent etre mis en correspondance avec le trafic observe.
  • Un mismatch JA3 - par ex. une connexion vers le port 443 qui produit une empreinte JA3 associee a la bibliotheque Python requests plutot qu'a un navigateur - est anormal meme sans correspondance d'IoC specifique.
# Zeek ssl.log a JA3 nativement
cat ssl.log | zeek-cut ts id.orig_h ja3 server_name \
  | grep "51c64c77e60f3980eea90869b68c58a8"  # Cobalt Strike par defaut connu

Limites :

  1. Profils malleables : Cobalt Strike et Sliver permettent aux operateurs de personnaliser le profil TLS, changeant l'empreinte JA3. Les defenseurs ne peuvent pas se fier a une liste de blocage de hachages statiques pour les acteurs sophistiques.
  2. JA3 partages : Un JA3 associe a un navigateur populaire (le JA3 de Chrome est utilise par des millions de sessions legitimes). Les bibliotheques d'attaquants peuvent imiter l'empreinte TLS de Chrome.
  3. JA3S (empreinte du serveur) : Hache la reponse ServerHello ; combiner les paires JA3 + JA3S reduit l'ambiguite mais augmente la complexite de reglage.
  4. TLS 1.3 + ECH (Encrypted Client Hello) : ECH chiffre les donnees d'extension ClientHello, eliminant potentiellement le signal JA3 dans les futurs deployements.

JA3 est un signal parmi d'autres dans une strategie de detection en couches, pas une methode de detection autonome. Cela est lie a T1573 (Canal chiffre).

Question 4​

Ecrivez une regle Suricata qui detecte le tunneling DNS potentiel en correspondant aux requetes DNS avec un QNAME de plus de 50 caracteres sur le port UDP 53. Incluez les metadonnees appropriees.

Reveler la reponse et l'explication

Reponse :

alert dns any any -> any 53 (
    msg:"TUNNELING DNS POSSIBLE - Longueur QNAME excessive";
    dns_query;                          -- correspondance dans le tampon du nom de requete DNS
    dsize:>50;                          -- payload de requete DNS > 50 octets (proxy pour QNAME long)
    threshold:type limit,               -- limitation du taux : alerter une fois par source par 60s
              track by_src,
              count 1,
              seconds 60;
    classtype:policy-violation;
    sid:9900020;
    rev:1;
    metadata:attack_target DNS_Server,
             affected_product DNS,
             mitre_tactic TA0011,       -- Commande et controle
             mitre_technique T1071.004; -- Protocole de couche applicative : DNS
)

Notes sur la precision :

  • dns_query est un tampon collant specifique a Suricata qui normalise le champ QNAME DNS, faisant en sorte que la correspondance content/dsize opere sur le nom de requete decode.
  • dsize seul est un instrument grossier - il se declenche sur tout grand payload DNS, pas seulement les noms de requetes longs. Pour la production, combiner avec une expression reguliere PCRE ou un script Lua pour mesurer precisement uniquement la longueur QNAME.
  • Les longues requetes QNAME sont utilisees dans iodine, dns2tcp, dnscat2, et des outils de tunneling DNS similaires. Les requetes legitimes depassent rarement 40 caracteres ; les domaines DGA se regroupent autour de 20-30 caracteres mais avec une entropie elevee plutot qu'une longueur.
  • Associer cette regle a une analyse d'entropie pour des taux de faux positifs plus faibles.

Contexte de detection (T1071.004) : Le tunneling DNS montre typiquement :

  • Des requetes vers un seul NS autoritaire (le domaine de l'attaquant) a haute frequence
  • De grandes reponses d'enregistrements TXT ou NULL
  • Un taux de requetes DNS inhabituellement eleve par hote
  • Des reponses contenant des donnees encodees en base64 ou binaires

Combiner la detection NIDS avec la journalisation des requetes DNS (BIND querylog, journalisation de debogage DNS Windows) pour une couverture complete.