Skip to main content

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

Module 2 : Analyse du trafic et detection des intrusions Prerequis : Chapitre 2.1 (Analyse de paquets et dissection de protocoles)

Table des matieres​

  1. Philosophie de detection : IDS vs IPS
  2. Architectures de deploiement
  3. Detection par signature
  4. Detection par anomalie et comportement
  5. Snort : regles, preprocesseurs et reglage
  6. Suricata : multithreading, EVE JSON et scripting Lua
  7. Techniques d'evasion
  8. Flux de travail d'ingenierie de detection
  9. Correspondance MITRE ATT&CK

1. Philosophie de detection : IDS vs IPS​

Un Systeme de detection d'intrusions (IDS) est un observateur passif - il duplique le trafic, l'inspecte et genere des alertes sans modifier le flux de trafic. Un Systeme de prevention d'intrusions (IPS) est positionne en ligne ; il peut supprimer, reinitialiser ou modifier les paquets en temps reel. Ce choix n'est pas purement technique - il reflete egalement la tolerance au risque de l'organisation. Un IPS mal configure qui genere des faux positifs devient un deni de service auto-inflige. La plupart des environnements d'entreprise commencent par l'IDS, valident les regles avec de faibles taux de faux positifs, puis passent en mode IPS uniquement pour les signatures a haute confiance.

Les deux paradigmes reposent sur les memes moteurs de detection. Ce qui change, c'est le crochet d'application : l'IDS lit depuis un TAP ou un port SPAN, tandis que l'IPS s'insere dans le chemin de transfert en utilisant des techniques comme NFQUEUE (Linux Netfilter), des paires d'interfaces en ligne, ou des appliances reseau en coupure.

NIDS vs HIDS :

  • Le NIDS (Network IDS) opere sur le trafic brut - voit tout ce qui traverse un segment reseau, mais n'a aucune visibilite sur l'etat de l'hote (memoire des processus, appels systeme, modifications de fichiers).
  • Le HIDS (Host IDS) s'execute en tant qu'agent sur le point de terminaison - visibilite approfondie de l'hote, mais ne voit que le trafic de cet hote et peut etre altere si l'hote est compromis.

Dans les environnements matures, ces couches sont complementaires. Un NIDS detecte le mouvement lateral sur le reseau ; un HIDS capture l'execution de processus resultante sur l'hote cible.

2. Architectures de deploiement​

TAP vs SPAN​

MethodeAvantagesInconvenients
TAP reseau (materiel)Passif, zero perte de paquets, ne peut pas etre detecte ni perturbeCout materiel, limite aux liens physiques
SPAN / Port miroirEconomique, flexible, configurable par logiciel sur les commutateurs administresPeut perdre des paquets sous charge, limite au trafic local du commutateur
En ligne (en coupure)Blocage actif possible, acces complet aux paquetsPoint unique de defaillance, latence ajoutee, decision fail-open/fail-closed requise
TAP virtuel / vSwitchFonctionne dans les environnements virtualises/cloudSurcharge de l'hyperviseur, configuration specifique au fournisseur

Strategie de placement​

Placer un NIDS unique au perimetre rate completement le trafic est-ouest. L'approche moderne segmente les capteurs selon les frontieres de confiance :

Internet -->[Pare-feu perimetre] --> Capteur DMZ
                               --> [Commutateur coeur] --> Capteur interne
                                                      --> [Fabric DC] --> Capteur centre de donnees

Chaque capteur rapporte a un SIEM central. La correlation entre capteurs est ce qui rend visibles les attaques sophistiquees multi-etapes - un scan de ports depuis le capteur perimetre suivi d'anomalies d'authentification sur le capteur interne est un signal de kill chain invisible pour chaque capteur seul.

3. Detection par signature​

Les signatures correspondent a des patterns malveillants connus : sequences d'octets, valeurs de champs de protocole, empreintes comportementales. La detection est rapide et precise pour les menaces connues. Les faiblesses sont tout aussi connues : les zero-days ne produisent pas d'hits de signature ; les mutations mineures du payload cassent les correspondances exactes.

Fonctionnement des signatures​

Une signature encode :

  1. Contexte de protocole - TCP, UDP, ICMP, couche applicative (HTTP, DNS, TLS)
  2. Direction - client vers serveur, serveur vers client, ou bidirectionnel
  3. Correspondance de contenu - patterns d'octets, regex, valeurs de champs de protocole
  4. Seuil / frequence - detecter sur N occurrences en T secondes

Compromis faux positif vs faux negatif​

L'alerte se declencheL'alerte ne se declenche pas
Attaque presenteVrai positifFaux negatif
Pas d'attaqueFaux positifVrai negatif

La sensibilite des signatures est reglees en ajustant la specificite du contenu et le seuil. Une signature correspondant a User-Agent: Mozilla se declenche sur pratiquement tout le trafic HTTP (inutile). Une signature correspondant a une sequence de shellcode de 16 octets specifique est tres precise mais rate les variantes polymorphes.

4. Detection par anomalie et comportement​

La detection par anomalie etablit une base de reference statistique du "normal" et alerte quand le comportement observe devie au-dela d'un seuil. C'est le seul mecanisme avec une chance theorique de capturer des attaques nouvelles.

Methodes statistiques​

  • Basee sur le volume : octets/sec, paquets/sec, flux/sec par hote ou segment. Un hote envoyant soudainement 10 fois son trafic egress de base est anormal.
  • Conformite au protocole : les parseurs conformes aux RFC signalent les en-tetes malformes. Un segment TCP avec SYN et FIN simultanément est illegale selon la RFC - soit un scanner, soit une tentative d'evasion.
  • Analyse d'entropie : les etiquettes de requetes DNS avec une entropie elevee (ex. a3f9c2b1d4e7.evil.com) suggerent un tunneling DNS ou du trafic DGA (Domain Generation Algorithm). Entropie de Shannon :
H = -Sum p(x) * log2(p(x))

Les noms d'hotes normaux scorent 2,5-3,5 bits/char. Les domaines DGA scorent typiquement 3,8-4,2.

  • Profilage comportemental des flux : tuples port_src, port_dst, octets, paquets, duree par IP source. Les donnees NetFlow / IPFIX alimentent des modeles ML (forets d'isolation, autoencodeurs) qui signalent les flux aberrants sans inspecter le payload.

Detection comportementale​

Plutot que de detecter un exploit specifique, les regles comportementales se declenchent sur des patterns d'activite :

  • Scan horizontal : une IP contacte plus de N IP uniques sur le meme port en T secondes
  • Scan vertical : une IP contacte plus de N ports uniques sur la meme destination en T secondes
  • Balise C2 : connexions sortantes periodiques a intervalles fixes (enregistrement C2)
  • Pic d'exfiltration : inversion du ratio upload/download pour un hote qui consomme normalement plus qu'il ne produit

La detection comportementale produit moins d'alertes actionnables que la detection par signature, mais capture les campagnes evasives a evolution lente qui restent deliberement sous les seuils par signature.

5. Snort : regles, preprocesseurs et reglage​

Snort est l'implementation de reference NIDS. Son langage de regles est largement clone (Suricata accepte les regles compatibles Snort). Comprendre l'anatomie des regles Snort est fondamental.

Structure des regles​

action proto ip_src port_src direction ip_dst port_dst (options)

Anatomie complete d'une regle reelle :

alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS (
    msg:"ET WEB_SERVER SQL Injection attempt -- select from";
    flow:established,to_server;
    content:"select"; nocase; http_uri;
    content:"from"; nocase; http_uri; distance:0;
    pcre:"/select.{0,30}from/Ui";
    classtype:web-application-attack;
    sid:2006445;
    rev:9;
    metadata:affected_product Web_Server_Applications,
              attack_target Web_Server,
              mitre_tactic TA0001;
)
ChampSignification
alertGenerer une alerte (autres actions : drop, reject, pass, log)
tcpCorrespondre au protocole TCP
$EXTERNAL_NETVariable definie dans snort.conf ; typiquement !$HOME_NET
flow:established,to_serverCorrespondre uniquement aux paquets dans une session TCP etablie, dans la direction client->serveur
content:"select"; nocase; http_uriCorrespondance d'octets insensible a la casse dans le tampon URI HTTP (apres normalisation)
distance:0Le deuxieme content doit apparaitre immediatement apres le premier
pcre:"/select.{0,30}from/Ui"Regex compatible Perl ; U = tampon URI HTTP, i = insensible a la casse
classtypeAttribue la classe de priorite pour l'alerte
sidID de regle unique

Preprocesseurs / Inspecteurs​

Le reassemblage TCP brut et la normalisation de la couche applicative se produisent dans les preprocesseurs avant l'execution des regles. C'est critique : une correspondance de contenu contre un flux fragmente ou desordonne raterait les attaques fractionnees entre segments.

Preprocesseurs cles :

  • stream5 - Reassemblage de flux TCP/UDP et suivi de session
  • frag3 - Defragmentation IP (previent les attaques par chevauchement de fragments)
  • http_inspect - Normalisation HTTP : decodage de %20, //, ..%2F, encodage chunk, etc.
  • dcerpc2 - Parsing SMB/DCERPC (detecte les exploits de type EternalBlue)
  • sfportscan - Detecte les patterns de scan horizontal/vertical
# Lancer Snort en mode IDS sur l'interface eth0, journaliser dans /var/log/snort
snort \
  -i eth0 \                          # interface de capture
  -c /etc/snort/snort.conf \         # configuration principale (inclut regles, preprocesseurs, variables)
  -A fast \                          # format d'alerte : fast (une ligne), full, unified2
  -l /var/log/snort \                # repertoire de journaux
  -D \                               # daemoniser
  -u snort -g snort                  # abandonner les privileges apres le demarrage

# Tester un fichier de regles pour les erreurs de syntaxe sans capturer le trafic en direct
snort -T -c /etc/snort/snort.conf

# Rejouer un pcap contre les regles Snort (analyse hors ligne)
snort \
  -r capture.pcap \                  # lire depuis pcap au lieu de l'interface en direct
  -c /etc/snort/snort.conf \
  -A console \                       # afficher les alertes sur stdout
  -l /tmp/snort_replay

Reglage : suppression et limitation du taux​

Un Snort non regle sur un reseau charge produit des milliers d'alertes par heure, dont la plupart sont des faux positifs ou du bruit de faible valeur. La suppression et la limitation du taux sont les outils principaux :

# threshold.conf -- supprimer entierement un sid specifique depuis une source specifique
suppress gen_id 1, sig_id 2006445, track by_src, ip 10.10.10.5

# Limitation du taux : alerter une seule fois par 60 secondes par IP source
threshold gen_id 1, sig_id 2006445, type limit, track by_src, count 1, seconds 60

# Alerter uniquement quand le seuil est depasse : 10 hits en 5 secondes
threshold gen_id 1, sig_id 1000001, type threshold, track by_src, count 10, seconds 5

6. Suricata : multithreading, EVE JSON et scripting Lua​

Suricata est l'evolution de production du modele Snort. Differences cles :

FonctionnaliteSnort 2.xSnort 3.xSuricata
MultithreadingNon (mono-thread)OuiOui (threads de travail par CPU)
Detection de protocoleBasee sur les portsBasee sur les portsIndependante des ports (identification profonde)
Inspection TLSLimiteeLimiteeEmpreinte JA3/JA4, extraction de certificats
Sortieunified2 binaireunified2 / JSONEVE JSON (journaux structures riches)
Scripting LuaNonLimiteOui - moteur de regles Lua complet
Extraction de fichiersNonNonOui (HTTP, SMB, FTP, NFS)

Sortie EVE JSON​

Le journal JSON EVE (Extensible Event Format) de Suricata est le principal point d'integration avec les SIEM et la pile Elastic. Chaque type d'evenement (alert, flow, dns, http, tls, files) emet un enregistrement JSON structure :

{
  "timestamp": "2024-11-15T14:23:01.882342+0000",
  "event_type": "alert",
  "src_ip": "192.168.1.50",
  "src_port": 54821,
  "dest_ip": "203.0.113.44",
  "dest_port": 4444,
  "proto": "TCP",
  "alert": {
    "action": "allowed",
    "gid": 1,
    "signature_id": 2100498,
    "rev": 7,
    "signature": "GPL ATTACK_RESPONSE id check returned root",
    "category": "Potentially Bad Traffic",
    "severity": 2
  },
  "flow": {
    "pkts_toserver": 6,
    "pkts_toclient": 9,
    "bytes_toserver": 472,
    "bytes_toclient": 1841
  },
  "payload": "aWQKdWlkPTAocm9vdCkgZ2lkPTAocm9vdCkK",
  "payload_printable": "id\nuid=0(root) gid=0(root)\n"
}

CLI Suricata​

# Demarrer Suricata en mode IDS ; AF_PACKET pour la capture haute performance
suricata \
  -c /etc/suricata/suricata.yaml \   # configuration principale
  --af-packet=eth0 \                 # mode AF_PACKET (contournement noyau leger)
  -D \                               # daemoniser
  --pidfile /var/run/suricata.pid

# Rejouer un pcap hors ligne (utile pour tester de nouvelles regles)
suricata \
  -c /etc/suricata/suricata.yaml \
  -r trafic_suspect.pcap \           # pcap hors ligne
  -l /tmp/sortie_suricata            # EVE JSON ecrit ici

# Suivre en temps reel les alertes depuis EVE JSON
tail -f /var/log/suricata/eve.json \
  | jq 'select(.event_type == "alert") | {ts: .timestamp, sig: .alert.signature, src: .src_ip}'

# Mettre a jour le jeu de regles Emerging Threats
suricata-update                      # recupere les dernieres regles ET Open, reconstruit l'index
suricata-update --reload-command "kill -USR2 $(cat /var/run/suricata.pid)"

Exemple de scripting Lua​

Les regles Lua executent une logique de detection arbitraire au-dela de ce que le langage de mots-cles des regles supporte. Utile pour la detection avec etat sur plusieurs paquets :

-- detecter_tunnel_dns_base64.lua
-- Se declenche si un nom de requete DNS depasse 40 chars et que l'entropie > 3.8

function init(args)
    local besoins = {}
    besoins["payload"] = tostring(true)  -- demander acces au payload du paquet
    return besoins
end

function match(args)
    local payload = args["payload"]
    if not payload then return 0 end

    -- extraire le QNAME DNS (simplifie : ignorer l'en-tete de 12 octets)
    local qname = payload:sub(13)
    if #qname < 40 then return 0 end

    -- calcul de l'entropie de Shannon
    local comptes = {}
    for i = 1, #qname do
        local c = qname:sub(i, i)
        comptes[c] = (comptes[c] or 0) + 1
    end
    local entropie = 0
    for _, compteur in pairs(comptes) do
        local p = compteur / #qname
        entropie = entropie - p * math.log(p) / math.log(2)
    end

    if entropie > 3.8 then return 1 end  -- 1 = correspondance, 0 = pas de correspondance
    return 0
end
-- Regle referencant le script Lua
alert dns any any -> any 53 (
    msg:"Tunnel DNS possible - Requete a entropie elevee";
    lua:detecter_tunnel_dns_base64.lua;
    sid:9900001;
    rev:1;
)

7. Techniques d'evasion​

L'evasion est la reponse de l'adversaire a la detection par signature. Comprendre l'evasion est obligatoire pour rediger des regles efficaces et pour comprendre les limites strictes des systemes bases sur les signatures.

Architecture de l'evasion​

Fragmentation TCP et desynchronisation du reassemblage​

L'evasion classique de Ptacek-Newsham : envoyer la meme plage d'octets dans deux fragments qui se chevauchent avec un contenu different. L'IDS voit le fragment A (benin), le point de terminaison reassemble en utilisant le fragment B (malveillant) selon la politique de chevauchement du systeme d'exploitation.

# fragroute -- intercepter et fragmenter les paquets sortants
# /etc/fragroute.conf :
# ip_frag 8            # fragmenter en morceaux de 8 octets
# tcp_seg 1            # segmenter TCP en morceaux de 1 octet

fragroute -f /etc/fragroute.conf 192.168.1.100

# scapy -- creer des fragments qui se chevauchent manuellement
python3 << 'EOF'
from scapy.all import *

cible = "192.168.1.100"
payload_a = b"GET /safe"          # fragment 1 : benin
payload_b = b"GET /exploit"       # fragment 2 : meme decalage, contenu malveillant
# Note : la politique de reassemblage du systeme d'exploitation determine lequel gagne

p1 = IP(dst=cible, flags="MF", frag=0) / TCP(dport=80) / payload_a[:8]
p2 = IP(dst=cible, frag=0) / TCP(dport=80) / payload_b[:8]  # chevauche le fragment 0
send([p1, p2], verbose=False)
EOF

Defense : Les preprocesseurs modernes (frag3 dans Snort, moteur de defragmentation dans Suricata) implementent des politiques de reassemblage par systeme d'exploitation et resolvent les chevauchements de maniere coherente avec l'OS cible, eliminant la fenetre de desynchronisation - a condition que l'OS cible soit correctement identifie dans la configuration du preprocesseur.

Evasion HTTP​

Les attaques d'applications web sont particulierement susceptibles a l'evasion par normalisation car HTTP permet de nombreuses representations equivalentes :

/admin/../admin/         -> /admin/           (collapse traversee de chemin)
/%61dmin/                -> /admin/           (%61 = 'a' en hexadecimal)
/ADMIN/                  -> /admin/           (normalisation de casse)
/%252F                   -> /%2F -> /          (double encodage)
/admin%09/               -> /admin/           (caractere tabulation)

Une signature correspondant a content:"/etc/passwd" rate /etc%2Fpasswd, /%65%74%63/passwd, /etc/./passwd, etc. Les preprocesseurs HTTP des IDS doivent normaliser avant de faire correspondre.

# Tester la couverture de normalisation avec nikto
nikto \
  -h http://192.168.1.100 \
  -evasion 1 \    # encodage URI aleatoire
  -evasion 2 \    # auto-reference de repertoire /./
  -evasion 4      # fin d'URL prematuree

Attaques par insertion​

Envoyer des paquets que l'IDS traite mais que le point de terminaison rejette - inserant du "bruit" dans le flux pour casser les correspondances de contenu :

  • Segments TCP avec des sommes de controle invalides (le point de terminaison les ignore ; certains moteurs IDS les traitent)
  • Paquets avec des TTL expires (atteignent l'IDS mais pas le point de terminaison)
  • TCP RST en milieu de flux (le point de terminaison ferme la connexion ; l'IDS peut continuer a suivre)
# scapy : envoyer un paquet avec TTL=1 (meurt au premier saut, n'atteint jamais la cible)
# Si l'IDS est derriere ce saut, il traite le paquet ; la cible ne le voit jamais
from scapy.all import *
p = IP(dst="192.168.1.100", ttl=1) / TCP(dport=80, flags="A") / b"BADCONTENT"
send(p)

Defense : Les capteurs IDS doivent etre places aussi pres que possible de la cible pour minimiser les fenetres de manipulation TTL. Le moteur stream-reassembly de Suricata valide les sommes de controle ; configurer checksum-validation: yes dans suricata.yaml.

Scans lents / furtifs​

# nmap scan lent : 1 sonde par ~15 minutes, ordre aleatoire
nmap \
  -sS \                     # scan SYN
  -T0 \                     # timing paranoide : 5 min entre les sondes
  --randomize-hosts \       # randomiser l'ordre des cibles
  --data-length 15 \        # ajouter des donnees aleatoires aux paquets (casse les signatures de longueur)
  --ttl 64 \
  192.168.1.0/24

# hping3 : creer un timing personnalise
hping3 \
  -S \                      # drapeau SYN
  -p 22 \                   # port destination
  -i u1000000 \             # intervalle : 1 seconde entre les paquets
  192.168.1.100

La detection basee sur les seuils (declencher apres N sondes en T secondes) a un contournement direct : reduire le taux de sondes en dessous du seuil. La detection comportementale avec des fenetres de temps plus longues et un suivi par source est necessaire.

Le chiffrement comme evasion (T1573)​

TLS 1.3 avec confidentialite persistante rend l'inspection du payload impossible sans un proxy d'inspection TLS. Les attaquants acheminent le trafic C2 via HTTPS/443 vers des domaines d'apparence legitime :

  • Domain Fronting : acheminer le trafic via un CDN (Cloudflare, AWS CloudFront) ; le header SNI/Host pointe vers un domaine legitime tandis que le contenu reel est proxifie vers le C2
  • C2 HTTPS : Cobalt Strike, Covenant, Sliver supportent tous des canaux C2 TLS complets
  • DNS chiffre : DNS-over-HTTPS (DoH) achemine les requetes DNS via HTTPS, contournant la detection basee sur DNS

Sans acces au payload, la detection repose sur les metadonnees :

  • Empreinte JA3/JA4 : hachage des parametres du TLS ClientHello (suites de chiffrement, extensions, courbes elliptiques) - identifie la bibliotheque cliente TLS independamment du payload
  • Analyse de certificat : certificats auto-signes, courtes fenetres de validite, domaines nouvellement enregistres
  • Analyse de timing des flux : periodicite des balises, patterns de gigue
# Extraire les empreintes JA3 d'un pcap avec zeek
zeek -r capture.pcap /opt/zeek/share/zeek/policy/protocols/ssl/ja3.zeek
cat ssl.log | zeek-cut ja3 ja3s server_name

# ja3 via python-ja3
pip install pyja3
python3 -m ja3 --json capture.pcap | jq '.[] | select(.ja3_digest == "51c64c77e60f3980eea90869b68c58a8")'
# JA3 Cobalt Strike par defaut connu : 51c64c77e60f3980eea90869b68c58a8 (change avec les profils malleables)

8. Flux de travail d'ingenierie de detection​

Ecrire et deployer des regles n'est pas une tache ponctuelle - c'est une boucle d'ingenierie continue. La qualite des alertes se degrade au fur et a mesure que l'environnement evolue ; les regles ecrites pour les patterns d'attaque de l'annee derniere peuvent etre ajustees jusqu'au silence tandis que les nouvelles techniques passent non detectees.

Construire un laboratoire de test pour la validation des regles​

# Rejouer des PCAP d'attaque contre Suricata hors ligne -- aucun risque en production
# 1. Telecharger un PCAP malveillant connu
wget https://malware-traffic-analysis.net/2024/01/15/2024-01-15-Formbook-infection-traffic.pcap.zip
unzip -P infected 2024-01-15*.zip

# 2. Lancer Suricata contre lui
suricata \
  -c /etc/suricata/suricata.yaml \
  -r 2024-01-15-Formbook-infection-traffic.pcap \
  -l /tmp/sortie_test \
  -S /etc/suricata/rules/emerging-malware.rules  # charger uniquement le jeu de regles specifique

# 3. Verifier ce qui s'est declenche
cat /tmp/sortie_test/eve.json \
  | jq 'select(.event_type=="alert") | .alert.signature' \
  | sort | uniq -c | sort -rn

# 4. Verifier les evenements manques (ce qu'un jeu de regles concurrent detecte et pas le votre)
# Comparer avec les resultats ET Pro ou Snort VRT

Profilage des performances des regles​

# Profilage des regles Suricata -- identifie les regles les plus lentes
# Dans suricata.yaml, activer :
#   profiling:
#     rules:
#       enabled: yes
#       filename: perf_regles.log
#       append: yes
#       sort: avgticks

# Apres une execution, examiner les principaux consommateurs de CPU
cat /var/log/suricata/rule_perf.log | head -30
# Les regles lentes sont generalement lourdes en PCRE ; optimiser en ajoutant d'abord une correspondance fast_pattern
# fast_pattern indique a Suricata d'utiliser le contenu specifie pour le matcher multi-pattern
# avant d'evaluer la regle complete

alert http any any -> any any (
    msg:"PCRE lent - optimise avec fast_pattern";
    content:"cmd.exe"; fast_pattern; http_uri;  # MPSE correspond en premier
    pcre:"/cmd\.exe(\s|%20|\+)\/[cC]/U";        # PCRE s'execute uniquement si fast_pattern correspond
    sid:9900002;
)

9. Correspondance MITRE ATT&CK​

TechniqueID ATT&CKMethode de detectionRegle/Logique cle
Decouverte de services reseauT1046Comportemental (seuils de scan de ports)Preprocesseur sfportscan ; comptage de flux par source
Exploitation d'application publiqueT1190Signature (patterns HTTP/injection SQL)Famille de regles ET 2006445
C2 via HTTPST1071.001Metadonnees TLS (JA3, analyse de certificat)Liste noire JA3 ; periodicite de balise
Tunneling DNS (C2)T1071.004Analyse d'entropie ; longueur de requeteScript d'entropie Lua ; seuil de longueur dns_query
Tunneling de protocoleT1572Anomalie de protocoleNon-HTTP sur port 80/443
Signalisation de trafic (C2 dissimule)T1205Comportemental (analyse de timing)Analyse de gigue NetFlow
Fichiers/informations obscurcisT1027Inspection de contenu (base64, en-tetes de compression dans contextes inattendus)Inspection du tampon file_data
Suppression d'indicateurs : journauxT1070HIDS (surveillance d'integrite de fichiers)Hors perimetre NIDS
Evasion par defragmentationT1599Normalisation par preprocesseurfrag3 / moteur de defragmentation
Canal chiffreT1573Empreinte TLS ; inspection de certificatJA3 ; couche applicative TLS Suricata