ja4-platform/docs/THESIS_HTTP_Traffic_Detection.md

Détection et Classification du Trafic HTTP Malveillant : Techniques Actuelles, Approche Multi-Couches et Nouvelles Perspectives

Document technique — Avril 2026

---

Résumé

La détection du trafic HTTP malveillant constitue un défi croissant à mesure que les attaquants adoptent des techniques d'évasion sophistiquées : rotation de fingerprints TLS, usurpation de User-Agent, navigation headless indistinguable des navigateurs réels, et botnets distribués exploitant des infrastructures résidentielles. Les pare-feu applicatifs (WAF) traditionnels, fondés sur des règles statiques telles que l'OWASP Core Rule Set (CRS), atteignent leurs limites face aux payloads polymorphes et aux attaques zero-day. Ce document présente une taxonomie complète des techniques de détection existantes — des signatures réseau (JA4+) à l'apprentissage automatique semi-supervisé — puis décrit une architecture de détection multi-couches opérationnelle (L3→L7), avant de proposer huit techniques originales exploitant des signaux jusqu'ici sous-utilisés.

Mots-clés : fingerprinting réseau, JA4+, détection de bots, IsolationForest, Extended Isolation Forest, autoencoders, ensemble hybride, corrélation TCP/TLS/HTTP, WAF, classification de trafic, apprentissage semi-supervisé.

---

Table des matières

1. Introduction
2. État de l'art
   • 2.1 Détection par règles statiques
   • 2.2 Fingerprinting réseau
   • 2.3 Analyse comportementale HTTP
   • 2.4 Apprentissage automatique pour la détection d'intrusions
   • 2.5 Détection côté client (browser fingerprinting)
3. Architecture de détection multi-couches
   • 3.1 Vue d'ensemble du pipeline
   • 3.2 Couche L3 — IP et paquets
   • 3.3 Couche L4 — TCP
   • 3.4 Couche L5 — TLS
   • 3.5 Couche L7 — HTTP
   • 3.6 Corrélation inter-couches
   • 3.7 Agrégation temporelle et features dérivées
   • 3.8 Détection ML semi-supervisée
4. Taxonomie des features de détection
5. Techniques originales proposées
   • 5.1 Entropie de séquence de chemins (Path Sequence Entropy)
   • 5.2 Graphe de co-occurrence JA4×ASN (Bipartite Bot Fleet Detection)
   • 5.3 Fingerprinting par timing inter-requêtes (Request Cadence Fingerprint)
   • 5.4 Détection de navigation synthétique par arbre de dépendances (Resource Dependency Tree)
   • 5.5 Analyse de dérive de fingerprint TLS intra-session (Intra-Session JA4 Drift)
   • 5.6 Corrélation DNS passive × flux HTTP (DNS Shadow Analysis)
   • 5.7 Détection par invariant de ratio de compression (Compression Ratio Invariant)
   • 5.8 Empreinte comportementale de session multi-domaine (Cross-Domain Session Linking)
6. Discussion et limites
7. Conclusion
8. Références

---

1. Introduction

Le trafic HTTP automatisé représente, selon les estimations d'Imperva (2024), plus de 49,6 % du trafic internet global, dont 32 % est classé comme malveillant. Cette proportion croît de manière continue, alimentée par la démocratisation des frameworks de scraping (Scrapy, Playwright, Puppeteer), des services de résolution de CAPTCHA, et des botnets-as-a-service opérant depuis des adresses IP résidentielles.

Face à cette menace, les mécanismes de défense ont évolué en plusieurs générations :

• Génération 1 (2000–2010) : Règles statiques sur les en-têtes HTTP — blocage par User-Agent, IP, ou pattern de requête. Limites : contournement trivial par rotation de UA.

• Génération 2 (2010–2018) : Fingerprinting TLS (JA3, 2017) et défis JavaScript côté client. Limites : JA3 est instable face au TLS padding (GREASE) ; les frameworks headless (Puppeteer) passent les défis JS.

• Génération 3 (2018–2023) : Fingerprinting multi-protocole (JA4+, 2023), corrélation TCP/TLS/HTTP, apprentissage automatique sur des features comportementales. Limites : les attaquants imitent les stacks TLS réelles (BotBrowser, CloakBrowser).

• Génération 4 (2024–) : Analyse multi-couches corrélée en temps réel, détection semi-supervisée avec dérive conceptuelle, graphes de co-occurrence réseau, et features temporelles à haute résolution.

Ce document se positionne à la charnière des générations 3 et 4. Il décrit d'abord l'état de l'art, puis détaille une architecture opérationnelle déployée intégrant 45+ features sur 5 couches réseau, et enfin propose huit techniques originales issues de notre analyse des angles morts persistants.

---

2. État de l'art

2.1 Détection par règles statiques

2.1.1 OWASP Core Rule Set (CRS)

Le CRS (v4, 2024) est le jeu de règles le plus déployé au monde pour ModSecurity et Coraza. Il opère par correspondance de patterns sur les requêtes HTTP : injection SQL (SQLi), cross-site scripting (XSS), inclusion de fichiers (LFI/RFI), exécution de commandes (RCE), et scanners connus.

Forces : déterministe, explicable, faible latence (<1ms), large couverture des attaques classiques.

Limites fondamentales :

• Pas de notion de session ou de comportement : chaque requête est évaluée indépendamment.
• Vulnérable aux payloads polymorphes : Osama et al. (2025, arXiv:2512.23610) démontrent que les WAF à règles CRS atteignent un taux de blocage de seulement 10-14 % sur des payloads augmentés par LLM, contre 96-100 % pour des modèles ML (XGBoost) entraînés sur le même corpus.
• Pas de détection comportementale : un scraper respectant la syntaxe HTTP est invisible.
• Maintenance manuelle intensive : chaque nouvelle technique d'obfuscation nécessite une règle.

2.1.2 Listes de réputation IP et ASN

Les dictionnaires de réputation (AbuseIPDB, GreyNoise, Spamhaus) associent des scores de confiance aux plages IP et aux ASN. L'architecture étudiée utilise trois dictionnaires ClickHouse en mémoire :

• dict_bot_ip : IP_TRIE pour correspondance CIDR O(1).
• dict_bot_ja4 : correspondance JA4→bot_name par hash.
• dict_asn_reputation : ASN→label (human/datacenter/proxy/tor/vpn/scanner/bot).

Limites : les botnets résidentiels (IoT compromis, proxies résidentiels comme Bright Data, SOCKS) opèrent depuis des ASN « human », rendant la réputation d'ASN insuffisante.

2.1.3 Projet Anubis (TecharoHQ)

Anubis est un système de règles communautaire (YAML) catégorisant les bots par UA, IP, ASN et pays avec des actions graduées (ALLOW, DENY, WEIGH, CHALLENGE). Son intégration dans un pipeline ML permet d'utiliser DENY comme vérité terrain forte et WEIGH comme signal auxiliaire dans le vecteur de features.

2.2 Fingerprinting réseau

2.2.1 TLS Fingerprinting : de JA3 à JA4+

JA3 (Althouse et al., 2017) : hash MD5 de la concatenation des versions TLS, cipher suites, extensions, groupes elliptiques, et formats de points dans le ClientHello. Largement adopté (Cloudflare, AWS, Akamai), mais souffrant de deux problèmes majeurs :

• Instabilité GREASE : RFC 8701 introduit des valeurs aléatoires dans les extensions TLS, rendant JA3 non-déterministe pour un même client.
• Collision inter-versions : les mises à jour de navigateurs changent JA3 fréquemment.

JA4 (Althouse, 2023) : refonte complète avec format a_b_c :

• Section a : type de protocole (TCP/QUIC), version TLS, nombre de cipher suites et d'extensions, ALPN, SNI — human-readable.
• Section b : hash des cipher suites triées.
• Section c : hash des extensions triées (GREASE filtré).

Le tri et le filtrage GREASE éliminent la variabilité non-sémantique. Le format modulaire permet l'analyse partielle : JA4_ac ignore les cipher suites, JA4_b seul identifie la bibliothèque TLS.

JA4+ comprend 12 méthodes complémentaires :

Méthode	Protocole	Signal
JA4	TLS Client	Application/bibliothèque TLS
JA4S	TLS Server	Serveur + réponse au client spécifique
JA4H	HTTP	Application HTTP (méthode, headers, cookies)
JA4T	TCP Client	OS, tunnels, VPN, proxies
JA4TS	TCP Server	OS serveur et réponse
JA4TScan	TCP Active	Fingerprint serveur actif + retransmissions
JA4X	X.509	Certificat TLS — détection C2
JA4L	Latence	Distance client→serveur (estimée par RTT)
JA4SSH	SSH	Fingerprint session SSH
JA4D	DHCP	Fingerprint client DHCP

Adoption (2026) : Cloudflare, AWS WAF, Google Cloud Armor, Azure Front Door, Akamai, Palo Alto, Zscaler, F5, Suricata, Zeek, Arkime — l'écosystème JA4+ est devenu un standard de facto.

2.2.2 TCP Fingerprinting

JA4T exploite quatre champs du SYN : Window Size, TCP Options, Window Scale, et MSS. Ces valeurs sont déterminées par le netcode de l'OS, permettant l'identification de :

• L'OS : Windows (pas de timestamp option), Linux (64240_2-1-3-1-1-4_1460_8), iOS (option 0 terminale).
• Les tunnels/VPN : MSS réduit (1380 pour VPN, 1360 pour double encapsulation).
• Les outils de scan : signatures distinctives (Masscan: window=1024, MSS=1460; ZMap: window=65535; Nmap: window=1024, options 2-4-8-1-3).
• L'opérateur mobile : MSS spécifique par carrier (AT&T=1340, Verizon=1392).

L'architecture étudiée capture tcp_meta_window_size, tcp_meta_mss, tcp_meta_window_scale, tcp_meta_options, et ip_meta_ttl pour chaque connexion, alimentant les features mss_mobile_mismatch, no_window_scale_ratio, avg_ttl, ttl_std, et ip_df_variance.

2.2.3 Fingerprinting TLS avancé

Au-delà de JA4, l'architecture exploite :

• JA3 (conservé pour diversité) : le ratio ja3_diversity_ratio = count(distinct JA3) / count(distinct JA4) détecte les bots qui randomisent JA3 dans un JA4 stable.
• ALPN : absence d'ALPN (is_alpn_missing) indique un client non-navigateur ou une bibliothèque TLS minimaliste.
• SNI ↔ Host : divergence (sni_host_mismatch) signale du domain fronting ou une mauvaise configuration de proxy.
• SYN→ClientHello timing : le délai entre le SYN TCP et le ClientHello TLS (syn_to_clienthello_ms) est caractéristique de l'implémentation TLS ; sa variance (tcp_jitter_variance) et son coefficient de variation (syn_timing_cv) détectent les scripts automatisés (faible variance) vs. les humains (variance naturelle).

2.3 Analyse comportementale HTTP

2.3.1 Signaux d'en-têtes HTTP

Les navigateurs modernes (Chrome ≥80, Firefox ≥90, Safari ≥15) envoient systématiquement un ensemble d'en-têtes que les outils automatisés omettent fréquemment :

Signal	Navigateur	Bot typique
Accept-Language	Toujours présent	Souvent absent
Accept-Encoding: gzip, deflate, br	Complet	Absent ou */*
Sec-Fetch-Site/Mode/Dest	Toujours (Chrome/FF)	Jamais
Sec-CH-UA*	Chrome ≥89	Absent ou incohérent
Cookie	Après première visite	Souvent absent (stateless)
Referer	Navigation normale	Absent (accès direct)
Ordre des headers	Stable par navigateur	Variable par bibliothèque

L'architecture exploite ces signaux via des ratios agrégés : has_accept_language, has_cookie, has_referer, sec_fetch_absence_rate, generic_accept_ratio, missing_accept_enc_ratio, modern_browser_score (0/50/100 selon Sec-CH-UA), ua_ch_mismatch, header_count, et header_order_confidence.

2.3.2 Patterns de navigation

• Asset ratio (count_assets / hits) : un navigateur réel charge CSS, JS, images (~60-80 % des requêtes) ; un scraper ne charge que le HTML.
• Direct access ratio (count_no_referer / hits) : navigation humaine suit des liens (Referer présent) ; les bots accèdent directement aux URLs.
• Path diversity (uniq_paths / hits) : un crawler explore largement (diversité haute) ; un bot ciblé répète les mêmes chemins (diversité basse).
• URL depth variance : la variance de la profondeur des URLs (nombre de /) est faible pour les crawlers systématiques.

2.3.3 Détection de brute-force et credential stuffing

Le ratio fuzzing_index = uniq_query_params / uniq_paths détecte les attaques par paramétrage : un fuzzer teste de nombreux paramètres sur peu de chemins (ratio élevé), tandis qu'une navigation normale a un ratio proche de 1. Le post_ratio élevé signale les attaques par formulaire.

2.4 Apprentissage automatique pour la détection d'intrusions

2.4.1 Approches supervisées

Les approches supervisées (Random Forest, XGBoost, réseaux profonds) nécessitent des jeux de données labellisés. Osama et al. (2025) démontrent que XGBoost atteint 99,59 % de précision sur la classification de payloads web avec une inférence en microsecondes. Cependant, ces modèles souffrent de :

• Concept drift : le trafic web évolue continuellement.
• Rareté des labels : les attaques nouvelles n'ont pas de label.
• Biais de dataset : les jeux comme CICIDS ou NSL-KDD ne reflètent pas le trafic web moderne (Schraven et al., 2025 — MAWIFlow Benchmark).

2.4.2 Approches semi-supervisées

L'approche semi-supervisée contourne le problème du labelling en apprenant uniquement la distribution du trafic « normal » (ou « humain ») :

Isolation Forest (Liu et al., 2008) : algorithme de détection d'anomalies basé sur des arbres d'isolation. L'intuition est que les anomalies, étant rares et différentes, sont « isolées » plus rapidement (en moins de splits) que les points normaux.

Extended Isolation Forest (Hariri et al., IEEE TKDE 2021) : l'IF standard sélectionne à chaque nœud une feature unique et un seuil, créant des coupes alignées aux axes. Dans des espaces de dimension élevée (>10 features), cette contrainte produit des artefacts de score — des « ghost clusters » où des régions sans données reçoivent des scores d'anomalie artificiellement bas car les coupes parallèles aux axes découpent l'espace de manière non-uniforme. L'EIF résout ce problème en utilisant des hyperplans de pente aléatoire (vecteur normal aléatoire + intercept aléatoire) au lieu de coupes alignées. Le résultat est un scoring plus cohérent et fiable, particulièrement critique pour des espaces à 47-59 features comme l'architecture étudiée. L'IF standard est un cas particulier de l'EIF (extension level 0).

Avantages de l'approche semi-supervisée pour la détection de bots :

• Pas besoin d'exemples d'attaques — le modèle apprend « ce qui est humain ».
• Détection zero-day intrinsèque : tout ce qui dévie significativement du comportement humain est signalé.
• Adaptation à l'environnement : chaque déploiement apprend son propre trafic normal.

Architecture de scoring bifurquée : L'architecture étudiée exécute deux modèles IF en parallèle sur chaque cycle (300 secondes) :

• Modèle Complet (45 features L3→L7) : sur le trafic corrélé TCP/TLS/HTTP (correlated=1).
• Modèle Applicatif (35 features L7) : sur le trafic non-corrélé HTTP-only (correlated=0).

Cette séparation est essentielle : les features TCP/TLS ne sont disponibles que lorsque ja4sentinel a corrélé la connexion réseau avec la requête HTTP. Forcer des valeurs à zéro pour le trafic non-corrélé introduirait un biais systématique.

2.4.2b Autoencoders et détection d'anomalies réseau

Les autoencoders (AE) offrent une approche complémentaire fondamentalement différente de l'IF. Là où l'IF mesure la « facilité d'isolation » d'un point, l'AE mesure l'erreur de reconstruction — la difficulté pour un réseau de neurones entraîné sur du trafic normal à reconstituer fidèlement un échantillon donné.

Kitsune (Mirsky et al., NDSS 2018) : ensemble d'autoencoders pour la détection d'intrusions réseau en ligne. Démontre que des AE légers (~64 neurones) tournant sur un Raspberry Pi détectent des attaques avec une performance comparable aux détecteurs offline. L'architecture KitNET utilise un feature mapper automatique qui répartit les features entre sous-ensembles d'autoencoders, permettant une détection distribuée.

β-VAE pour la détection d'anomalies (Baptiste et al., arXiv, février 2026) : les autoencoders variationnels (VAE) ajoutent un terme de régularisation KL-divergence qui structure l'espace latent. Le score d'anomalie combine erreur de reconstruction et déviation de la distribution latente : anomaly = -log p(x|z) + KL(q(z|x) || p(z)). Cette double mesure détecte des anomalies qu'un AE standard manque — des échantillons bien reconstruits mais dont la représentation latente est atypique.

Complémentarité AE + IF : des études comparatives (Jamshidi et al., arXiv, novembre 2025 — « Lightweight Autoencoder-Isolation Forest for Green IoT Edge Gateways » ; Basbous et al., arXiv, mars 2026 — « Hybrid Autoencoder-Isolation Forest ») démontrent que la combinaison des deux méthodes surpasse chacune en isolation :

• L'IF excelle sur les anomalies ponctuelles (points isolés dans l'espace des features).
• L'AE excelle sur les anomalies distributionnelles (corrélations non-linéaires entre features perturbées).
• Un bot utilisant httpcloak pour imiter les features individuelles d'un navigateur Chrome présente des corrélations inter-features inhabituelles (e.g., tcp_jitter_variance × sec_fetch_absence_rate × asset_ratio) que seul un AE détecte.

L'espace latent du AE (typiquement 16 dimensions) fournit en outre un espace de clustering bien adapté pour la détection de campagnes coordonnées (remplacement du feature space brut pour DBSCAN/HDBSCAN).

2.4.2c Ensembles hybrides supervisé + non-supervisé

L'accumulation de décisions de classification (historique ml_all_scores, feedback SOC, étiquettes KNOWN_BOT, ANUBIS_DENY) crée progressivement un jeu de données labellisé exploitable par un classifieur supervisé.

Architecture en ensemble triple :

                    ┌─────────────────────────┐
                    │  EIF (non-supervisé)    → score_eif
                    ├─────────────────────────┤
 Features ────────▶ │  AE  (non-supervisé)    → recon_error_ae
                    ├─────────────────────────┤
                    │  XGBoost (supervisé)    → prob_bot_xgb
                    └────────────┬────────────┘
                                 │
                    ┌────────────▼────────────┐
                    │  Méta-learner           │  (régression logistique)
                    │  Pondération adaptative │
                    └────────────┬────────────┘
                                 │
                    final_threat_score ∈ [0, 1]

• EIF : détecte les anomalies zero-day (pas de labels nécessaires, résistant au concept drift via retraining).
• AE : capture les corrélations non-linéaires entre features que l'EIF manque.
• XGBoost : exploite les patterns connus (entraîné sur l'historique des décisions ML + feedback SOC). Osama et al. (2025) démontrent 99,59 % de précision sur classification de payloads.
• Méta-learner : pondère dynamiquement les trois voix en fonction de leur performance récente.

Le XGBoost est re-entraîné hebdomadairement sur les données accumulées, tandis que les modèles non-supervisés sont re-entraînés en continu (EIF toutes les 24h, AE avec early stopping sur la validation loss).

2.4.3 Concept Drift et retraining adaptatif

Le trafic web n'est pas stationnaire : les navigateurs sont mis à jour (changement de JA4), les patterns de navigation évoluent (SPA, HTTP/3), et les attaquants adaptent leurs techniques.

L'architecture implémente une détection de dérive par test de Kolmogorov-Smirnov par feature entre la distribution d'entraînement et la distribution courante. Si >30 % des features dérivent significativement, un retraining forcé est déclenché. Le modèle est sérialisé avec ses statistiques de baseline pour comparaison future.

Amélioration par quantile digest : la reconstruction de la distribution d'entraînement à partir de la seule moyenne et écart-type (distribution normale synthétique) est inadéquate pour les features non-gaussiennes — asset_ratio, post_ratio, et orphan_ratio sont typiquement bimodales ou fortement asymétriques. La sauvegarde d'un ensemble de quantiles (p10, p25, p50, p75, p90) permet de reconstruire la CDF empirique par interpolation linéaire et de produire des échantillons synthétiques fidèles à la distribution réelle via le sampling par quantile inverse.

Validation et gate condition : au-delà de la détection de drift, la validation du modèle après retraining est critique. Un taux d'anomalie sur le jeu de validation >20 % signale une baseline contaminée — le modèle entraîné considère trop de trafic normal comme anomal, indiquant une pollution de la baseline asn_label='human' par des bots résidentiels ou des proxies. Dans ce cas, le modèle précédent est conservé et une alerte est émise.

2.4.4 Régime d'attaque probabiliste (PARD-SSM)

Hiremath et al. (avril 2026, arXiv) proposent les Variational Switching State-Space Models pour modéliser les campagnes d'attaque comme des séquences de phases comportementales (Reconnaissance → Mouvement latéral → Intrusion → Exfiltration). Cette approche pourrait enrichir la détection de campagnes actuellement implémentée par DBSCAN.

2.4.5 Explicabilité par SHAP

L'architecture utilise SHAP TreeExplainer pour extraire les 5 features les plus contributives à chaque anomalie. Cette explicabilité est critique pour les analystes SOC : un score d'anomalie seul n'est pas actionnable, mais « anomalie due à : sec_fetch_absence=0.95, asset_ratio=0.02, temporal_entropy=0.1 » indique clairement un scraper sans en-têtes navigateur.

2.5 Détection côté client (Browser Fingerprinting)

2.5.1 JavaScript Challenges

Les solutions commerciales (Cloudflare Turnstile, DataDome, PerimeterX) injectent du JavaScript dans la page pour collecter des signaux côté client : rendu Canvas, WebGL, propriétés du navigateur, timing d'exécution JS.

Limites :

• Contourné par les navigateurs headless patchés (BotBrowser, CloakBrowser — « 30/30 tests passed »).
• Inapplicable aux APIs (pas de navigateur).
• Latence ajoutée au premier chargement.
• Dépendance à JavaScript côté client (exclut les clients non-JS).

2.5.2 FingerprintJS BotD

BotD (open-source) détecte les frameworks d'automatisation (Puppeteer, Playwright, Selenium) par inspection des propriétés JavaScript (navigator.webdriver, phantom/selenium artifacts). Efficace contre les outils non-patchés, mais contourné par les patchs de bas niveau (rebrowser-patches).

2.6 Synthèse des limites de l'état de l'art

Approche	Force	Angle mort principal
Règles CRS	Explicable, rapide	Pas de détection comportementale
JA4+ fingerprinting	Multi-protocole, stable	Contournable par imitation de stack
Analyse headers HTTP	Détecte les scripts simples	Les frameworks modernes imitent les headers
ML supervisé	Haute précision sur patterns connus	Concept drift, manque de labels
ML semi-supervisé (IF)	Détection zero-day, adaptatif	Seuils de contamination sensibles
JS challenges	Détecte les headless	Contourné par BotBrowser ; inapplicable aux APIs

Constat : aucune technique isolée n'est suffisante. La détection robuste exige une approche multi-couches fusionnant les signaux des couches L3 à L7, enrichie par l'apprentissage automatique.

---

3. Architecture de détection multi-couches

3.1 Vue d'ensemble du pipeline

                    Trafic Internet
                         │
          ┌──────────────┼──────────────┐
          ▼              ▼              ▼
    ┌──────────┐   ┌──────────┐   ┌──────────┐
    │ L3: IP   │   │ L4: TCP  │   │ L5: TLS  │
    │ TTL, DF  │   │ Window,  │   │ JA4, JA3 │
    │ ID, Len  │   │ MSS,     │   │ ALPN,    │
    │          │   │ Scale,   │   │ SNI,     │
    │          │   │ Options  │   │ Timing   │
    └────┬─────┘   └────┬─────┘   └────┬─────┘
         │              │              │
         └──────────────┼──────────────┘
                        ▼
              ┌──────────────────┐
              │   ja4sentinel    │  Capture passive (libpcap)
              │   L3/L4/L5      │  CAP_NET_RAW
              │   Extraction     │  → Source B
              └────────┬─────────┘
                       │
          ┌────────────┼──────────────┐
          │                           │
          ▼                           ▼
    ┌──────────┐               ┌──────────────┐
    │ Apache   │               │ logcorrelator│
    │ L7: HTTP │               │ Corrélation  │
    │ mod_req  │──Source A────▶│ src_ip:port  │
    │ in_log   │               │ A↔B matching │
    └──────────┘               └──────┬───────┘
                                      │
                               ┌──────▼───────┐
                               │  ClickHouse  │
                               │  Agrégation  │
                               │  horaire     │
                               │  Features    │
                               └──────┬───────┘
                                      │
                               ┌──────▼───────┐
                               │ bot_detector │
                               │ 2× IF model  │
                               │ DBSCAN camp. │
                               │ SHAP explain │
                               └──────┬───────┘
                                      │
                               ┌──────▼───────┐
                               │  Dashboard   │
                               │  21 modules  │
                               │  Clustering  │
                               │  SOC tools   │
                               └──────────────┘

3.2 Couche L3 — IP et paquets

Les métadonnées IP sont extraites par ja4sentinel pour chaque paquet :

• TTL (Time to Live) : valeur initiale caractéristique de l'OS (64=Linux, 128=Windows, 255=réseau). La déviation (ttl_std) signale des chaînes de proxy hétérogènes.
• IP ID : le champ Identification à zéro (ip_id_zero_ratio) indique des paquets forgés (Scapy, hping3) — les OS réels incrémentent ce champ.
• Don't Fragment (DF) : la variance du bit DF (ip_df_variance) est normalement nulle pour un client unique ; une variance non-nulle indique un mélange de stacks.
• Total Length : la variance (request_size_variance) est faible pour les outils automatisés (requêtes uniformes) et élevée pour la navigation humaine.
• Anomalous payload ratio : paquets <60 octets (trop petits) ou >1500 octets (fragmentation anormale) — signale les paquets crafted.

3.3 Couche L4 — TCP

Les métadonnées TCP du SYN sont capturées pour chaque connexion :

• Window Size × Scale : true_window_size = window × 2^scale. Combiné avec MSS, identifie l'OS et détecte les incohérences.
• MSS : 1460 = Ethernet standard ; <1460 = tunnel/VPN/mobile ; 1460 avec UA mobile et browser_score élevé = mss_mobile_mismatch.
• Options : l'absence de timestamp (Windows) ou de Window Scale (no_window_scale_ratio) identifie des stacks minimalistes.
• TCP fingerprint sharing (tcp_shared_count) : nombre d'IPs partageant le même fingerprint TCP. Un cluster élevé signale un botnet utilisant le même OS/outil.
• Jitter SYN→ClientHello (tcp_jitter_variance) : les bots scriptés ont un timing quasi-constant ; les humains introduisent une variance naturelle.
• Port density (src_port_density) : ratio hits/(ports uniques × durée) — une densité anormale signale un scanner ou un outil avec réutilisation de ports.
• Keepalive count : le nombre de requêtes HTTP sur une même connexion TCP. Les bots simples ouvrent une connexion par requête ; les navigateurs réutilisent.

3.4 Couche L5 — TLS

• JA4 : fingerprint du ClientHello (voir §2.2.1). is_rare_ja4 (globalement <100 hits) signale une bibliothèque TLS inhabituelle.
• JA3 : conservé pour le ratio de diversité ja3_diversity_ratio — les bots rotatifs ont un JA3 variable dans un JA4 stable.
• ALPN : is_alpn_missing (pas d'ALPN ou "00") — les navigateurs annoncent toujours h2 ou h1.
• SNI : sni_host_mismatch (SNI ≠ Header Host) — domain fronting, proxy mal configuré.
• TLS version : tls12_ratio — TLS 1.2 encore dominant chez les bots utilisant des bibliothèques anciennes.
• ALPN × HTTP version : alpn_http_mismatch (annonce h2 mais communique en HTTP/1.1) — incohérence protocolaire.

3.5 Couche L7 — HTTP

La couche la plus riche en signaux, avec ~25 features dérivées des en-têtes et du comportement de navigation (voir §2.3 pour le détail).

Signaux additionnels spécifiques :

• HEAD requests (head_ratio) : les scanners utilisent HEAD pour minimiser le transfert.
• HTTP/1.0 (http10_ratio) : protocole obsolète, utilisé par des outils minimalistes.
• Temporal entropy : entropie de Shannon sur la distribution horaire des hits par IP. Un bot régulier a une entropie faible (distribution uniforme) ; un humain a une entropie élevée (pics d'activité).

3.6 Corrélation inter-couches

La corrélation est le pilier de l'architecture. Le logcorrelator fusionne les événements de deux sources :

• Source A (mod_reqin_log) : événements HTTP avec timestamp nanoseconde, src_ip:src_port, méthode, chemin, en-têtes.
• Source B (ja4sentinel) : événements TCP/TLS avec JA4, JA3, métadonnées IP/TCP, timing SYN→ClientHello.

Clé de corrélation : src_ip:src_port. Mode Keep-Alive : un événement B corrèle avec multiples événements A (réutilisation de connexion).

Gestion des orphelins : après 500ms sans correspondance, un événement A est émis avec correlated=0, orphan_side='A'. Cela alimente le modèle Applicatif (L7-only), garantissant que tout le trafic est analysé même en cas d'échec de corrélation.

3.7 Agrégation temporelle et features dérivées

L'agrégation horaire via les vues matérialisées ClickHouse (AggregatingMergeTree) transforme les logs bruts (potentiellement des millions de lignes) en ~100k sessions agrégées par (window_start, src_ip, ja4, host).

Vue finale view_ai_features_1h : 45+ colonnes calculées par CTE + window functions, servant de vecteur de features pour IsolationForest. Les fonctions de fenêtrage OVER PARTITION BY permettent de calculer des features inter-sessions (JA4 rarity, ASN concentration, TCP fingerprint sharing) sans auto-jointures coûteuses.

3.8 Détection ML semi-supervisée

Trifurcation du trafic

Trafic entrant (view_ai_features_1h)
         │
    ┌────┴────────────────────────┐
    │ dict_bot_ip/ja4 match ?    │──OUI──▶ KNOWN_BOT (score=0)
    │ Anubis ALLOW ?             │
    └────┬───────────────────────┘
         │ NON
    ┌────┴────────────────────────┐
    │ asn_label == 'human' ?     │──OUI──▶ Baseline IF (training set)
    └────┬───────────────────────┘
         │ NON
         ▼
    Scoring par IF (test set)
         │
    ┌────┴────────────────────────┐
    │ score < seuil adaptatif ?  │──OUI──▶ ANOMALIE
    │                             │         + SHAP top-5
    │                             │         + DBSCAN campaign
    │                             │         + Recurrence penalty
    └────┬───────────────────────┘
         │ NON
         ▼
    NORMAL (score enregistré dans ml_all_scores)

Seuil adaptatif

Le seuil n'est pas fixe : threshold = min(percentile_5(negative_scores), -0.05). Cela adapte automatiquement la sensibilité au volume d'anomalies du cycle courant.

Niveaux de menace

Seuil	Niveau	Action recommandée
score < -0.30	CRITICAL	Blocage immédiat
score < -0.15	HIGH	Investigation prioritaire
score < -0.05	MEDIUM	Surveillance
score < 0	LOW	Information
Dict match	KNOWN_BOT	Selon politique
Anubis DENY	ANUBIS_DENY	Blocage

---

4. Taxonomie des features de détection

Nous proposons une classification en 7 familles :

Famille 1 : Volumétrie et vitesse

hits, hit_velocity, max_keepalives

Famille 2 : Diversité et exploration

fuzzing_index, path_diversity_ratio, url_depth_variance, distinct_ja4_count, distinct_header_orders, is_ua_rotating

Famille 3 : Authenticité protocolaire

modern_browser_score, ua_ch_mismatch, has_accept_language, has_cookie, has_referer, sec_fetch_absence_rate, generic_accept_ratio, missing_accept_enc_ratio, header_count, header_order_confidence

Famille 4 : Cohérence cross-layer

alpn_http_mismatch, is_alpn_missing, sni_host_mismatch, mss_mobile_mismatch, tls12_ratio, http10_ratio, tcp_jitter_variance, syn_timing_cv

Famille 5 : Empreinte réseau

ip_id_zero_ratio, request_size_variance, anomalous_payload_ratio, avg_ttl, ttl_std, no_window_scale_ratio, ip_df_variance, tcp_shared_count, port_exhaustion_ratio, src_port_density

Famille 6 : Comportement de navigation

asset_ratio, direct_access_ratio, orphan_ratio, temporal_entropy, post_ratio, head_ratio, http_scheme_ratio

Famille 7 : Intelligence contextuelle

ja4_asn_concentration, ja4_country_concentration, is_rare_ja4, header_order_shared_count, ja3_diversity_ratio, anubis_is_flagged, multiplexing_efficiency

---

5. Techniques originales proposées

5.1 Entropie de séquence de chemins (Path Sequence Entropy)

Constat : les features actuelles mesurent la diversité des chemins (path_diversity_ratio) mais pas leur ordre. Or, la navigation humaine suit des patterns séquentiels prévisibles (page d'accueil → catégorie → produit → panier), tandis que les crawlers systématiques parcourent les chemins en ordre lexicographique ou par profondeur.

Technique proposée : Pour chaque session (src_ip, window), calculer l'entropie de transition de Markov d'ordre 1 sur la séquence des chemins normalisés (path → prefix de profondeur 2, ex: /shop/product/*).

H_transition = -Σ P(path_i → path_j) × log₂(P(path_i → path_j))

Signal attendu :

• Humain : entropie de transition élevée (navigation non-déterministe).
• Crawler systématique : entropie de transition faible (transitions prévisibles).
• Scanner ciblé : entropie nulle (même chemin répété).

Implémentation : nécessite de stocker les séquences de paths par session dans l'agrégation, par exemple via groupArray(path) dans une nouvelle colonne AggregateFunction. Le calcul de l'entropie se fait dans la vue de features via une UDF ClickHouse ou en post-processing Python.

Avantage : cette feature est résistante à la rotation de chemins aléatoire (qui augmente la diversité mais produit des transitions uniformes, donc une entropie maximale — distinguable de la navigation réelle qui a des transitions structurées).

5.2 Graphe de co-occurrence JA4×ASN (Bipartite Bot Fleet Detection)

Constat : les features actuelles mesurent la concentration ASN par JA4 (ja4_asn_concentration) individuellement. Mais les botnets sophistiqués utilisent des dizaines d'ASN et de JA4 rotatifs, rendant chaque paire (JA4, ASN) banale. C'est le pattern de co-occurrence global qui est révélateur.

Technique proposée : Construire un graphe bipartite G = (JA4 ∪ ASN, E) où une arête connecte un JA4 à un ASN si au moins N IPs utilisent ce JA4 depuis cet ASN dans une fenêtre temporelle. Appliquer une détection de communautés (Louvain, Label Propagation) sur le graphe projeté sur les JA4.

Signal attendu :

• Un botnet distribué sur 50 ASN avec 10 JA4 rotatifs formera une communauté dense dans le graphe projeté.
• Le trafic légitime produit des cliques isolées (un JA4 navigateur × quelques ASN résidentiels).

Métrique dérivée : fleet_score = taille_communauté × densité_arêtes / log(nb_ASN). Un score élevé signale une flotte de bots coordonnée.

Avantage : résistant à la rotation de JA4 et d'ASN, car c'est la structure du graphe qui est analysée, pas les identifiants individuels.

5.3 Fingerprinting par timing inter-requêtes (Request Cadence Fingerprint)

Constat : les features temporelles actuelles se limitent à hit_velocity (moyenne) et temporal_entropy (distribution horaire). Or, le rythme des requêtes contient un signal riche : les humains produisent des intervalles irréguliers avec des « bursts » de lecture suivis de pauses, tandis que les bots produisent des intervalles réguliers (Sleep-based) ou exponentiels (backoff).

Technique proposée : Pour chaque session, calculer le vecteur des intervalles inter-requêtes Δt = [t₂-t₁, t₃-t₂, ...], puis extraire :

1. Coefficient de variation : CV(Δt) = σ(Δt)/μ(Δt). Humain ≈ 1.5-3.0 ; Bot régulier ≈ 0.01-0.3.
2. Autocorrélation lag-1 : ρ₁(Δt). Humain ≈ 0 (indépendant) ; Bot avec jitter ≈ 0.8+ (corrélé).
3. Ratio burst/pause : proportion de Δt < 100ms (burst) vs Δt > 5s (pause). Navigateurs : pattern alternant ; scrapers : tout en burst.
4. Distribution de la mantisse (Loi de Benford sur Δt en ms) : déviation par rapport à la distribution attendue — les Sleep(N) artificiels ne suivent pas la loi de Benford.

Implémentation : requiert groupArray(time) dans l'agrégation. Les 4 métriques sont calculables en SQL ClickHouse via arrayMap/arrayReduce.

5.4 Détection de navigation synthétique par arbre de dépendances (Resource Dependency Tree)

Constat : asset_ratio détecte les bots qui ne chargent pas les ressources, mais les scraping frameworks modernes (Playwright, Puppeteer) chargent toutes les ressources. Le signal n'est plus la présence des chargements de ressources, mais leur ordre temporel.

Technique proposée : Un navigateur réel charge les ressources dans un ordre déterminé par le parsing HTML : d'abord le document, puis les CSS (bloquants), puis les JS et images (différés). Cet arbre de dépendances produit des « cascades » caractéristiques.

Pour chaque session, construire le graphe de dépendances temporelles :

1. Ordonner les requêtes par timestamp.
2. Détecter les « racines » (HTML) et les « feuilles » (assets) par le Content-Type demandé (Accept header) et le path (extension).
3. Calculer le délai moyen racine→première-feuille et la simultanéité des feuilles (écart-type des timestamps des assets dans une cascade).

Signal attendu :

• Navigateur réel : cascade naturelle avec ~50-200ms de délai HTML→CSS→JS, assets parallélisés (écart-type faible au sein d'un batch).
• Playwright headless : chargement quasi-simultané (toutes les requêtes déclenchées en <10ms), puis éventuellement un délai artificiel.
• Scraper avec assets : pas de cascade (resources chargées séquentiellement ou dans un ordre non-hiérarchique).

Implémentation : nécessite de préserver l'ordre temporel des requêtes au sein de chaque page view. Peut être implémenté comme une vue ClickHouse utilisant arraySort sur les timestamps par (src_ip, referer).

5.5 Analyse de dérive de fingerprint TLS intra-session (Intra-Session JA4 Drift)

Constat : distinct_ja4_count mesure la diversité globale de JA4 par IP sur une fenêtre. Mais un attaquant sophistiqué peut maintenir un seul JA4 pendant la majorité de la session et ne le changer qu'à un moment précis (par exemple, passer d'un mode reconnaissance à un mode exploitation).

Technique proposée : Pour les IPs à connexions multiples, calculer un drift score temporel :

1. Segmenter les connexions par fenêtre de 10 minutes.
2. Calculer le JA4 dominant par segment.
3. Compter les transitions (changements de JA4 dominant entre segments consécutifs).
4. Drift ratio = transitions / (segments - 1).

Signal attendu :

• Humain : drift ratio = 0 (même navigateur = même JA4).
• Bot rotatif simple : drift ratio ≈ 1 (change à chaque segment).
• APT multi-phases : drift ratio bas (0.1-0.3) avec une transition unique — corrélée temporellement avec un changement de comportement (ex: passage de GET à POST).

Détection APT : combiner drift_ratio avec changement simultané de post_ratio ou path_prefix pour détecter les transitions reconnaissance→exploitation.

5.6 Corrélation DNS passive × flux HTTP (DNS Shadow Analysis)

Constat : l'architecture actuelle ne capture pas les requêtes DNS. Or, chaque première visite d'un domaine par un navigateur est précédée d'une résolution DNS, tandis que les bots qui ciblent directement des IPs ou utilisent des résolveurs personnalisés ne génèrent pas de requête DNS observable sur le réseau local.

Technique proposée : Capturer passivement les requêtes DNS (via ja4sentinel étendu aux paquets UDP/53) et corréler avec les flux HTTP :

dns_shadow_ratio = requêtes HTTP vers host X / résolutions DNS de host X observées

Signal attendu :

• Navigateur réel : ratio ≈ 1 (une résolution DNS → plusieurs requêtes HTTP via Keep-Alive, mais le DNS est bien observé).
• Bot avec /etc/hosts ou DNS-over-HTTPS privé : ratio → ∞ (requêtes HTTP sans résolution DNS observable).
• CDN/proxy : ratio variable mais cohérent.

Extension JA4D : les fingerprints DHCP/DHCPv6 (JA4D/JA4D6) peuvent être corrélés pour identifier les périphériques derrière un NAT, ajoutant une dimension d'identification au-delà de l'IP.

5.7 Détection par invariant de ratio de compression (Compression Ratio Invariant)

Constat : les navigateurs modernes annoncent systématiquement Accept-Encoding: gzip, deflate, br (Brotli). La feature missing_accept_enc_ratio détecte l'absence de cet en-tête. Mais certains bots l'incluent sans réellement traiter la compression.

Technique proposée : Côté serveur (Apache module), comparer la taille des réponses compressées envoyées avec le Content-Length non-compressé :

1. Calculer le ratio de compression effectif par session.
2. Corréler avec les tailles de requêtes suivantes : un client qui reçoit une réponse compressée mais renvoie des données suggérant qu'il a parsé la version non-compressée (ex: paramètre de longueur spécifique) trahit une décompression absente.

Signal plus subtil : le timing de réponse du client après réception d'une réponse Brotli (haute compression, décompression coûteuse) vs. gzip (compression modérée, décompression rapide). Un bot qui ne décompresse pas répondra au même rythme quelle que soit la compression ; un vrai navigateur sera légèrement plus lent après Brotli.

5.8 Empreinte comportementale de session multi-domaine (Cross-Domain Session Linking)

Constat : dans un environnement multi-host (plusieurs VirtualHosts Apache), les features sont calculées indépendamment par (src_ip, ja4, host). Mais un attaquant scannant plusieurs domaines depuis la même IP présente un pattern cross-domain caractéristique.

Technique proposée : Ajouter une feature agrégée au niveau de (src_ip) sans décomposition par host :

1. Host diversity = uniqExact(host) OVER (PARTITION BY src_ip). Humain : 1-3 ; Scanner : 10+.
2. Host sweep speed = uniqExact(host) / durée_session. Un scanner balaye rapidement tous les vhosts.
3. Host coverage uniformity = 1 - stddev(hits_par_host) / avg(hits_par_host). Un scanner distribue uniformément ; un humain concentre sur 1-2 hosts.
4. Cross-domain path similarity = distance de Jaccard entre les sets de chemins par host. Un scanner utilise les mêmes chemins (/admin, /wp-login.php) sur tous les hosts.

Avantage : détecte les scans horizontaux (« host sweep ») qui sont banals sur chaque host individuel mais caractéristiques en vue agrégée.

---

6. Discussion et limites

6.1 Course aux armements (Arms Race)

Chaque technique de détection engendre une contre-mesure :

• JA4 fingerprinting → BotBrowser, httpcloak (imitation exacte du stack TLS de Chrome).
• Analyse d'en-têtes → Frameworks qui reproduisent l'ordre exact des headers Chrome.
• Timing analysis → Jitter artificiel randomisé.
• Asset ratio → Chargement de toutes les ressources.

L'architecture multi-couches atténue ce problème : imiter simultanément les 45 features sur 5 couches réseau a un coût computationnel et une complexité d'implémentation qui augmentent exponentiellement avec le nombre de signaux corrélés. Un attaquant qui perfectionne sa stack TLS (L5) peut encore être trahi par son timing TCP (L4) ou son pattern de navigation (L7).

6.2 Faux positifs et le problème de la baseline humaine

L'approche semi-supervisée suppose que le trafic asn_label='human' est effectivement humain. Or :

• Les proxies résidentiels (Bright Data, Oxylabs) opèrent depuis des ASN résidentiels labellisés « human ».
• Un botnet IoT utilise des ASN résidentiels.

Contamination de la baseline : si >1 % du trafic « humain » est en réalité automatisé, le modèle IF apprend ces patterns comme normaux, réduisant la sensibilité.

Mitigation multi-niveaux :

1. Le seuil de contamination IF (contamination=0.001) combiné avec la déduplication Anubis (les bots connus sont exclus avant l'entraînement) limite ce risque.
2. Les techniques proposées (§5.2 graphe de co-occurrence, §5.3 cadence fingerprint) offrent des signaux orthogonaux résistants à cette contamination.
3. Validation gate : après chaque retraining, le taux d'anomalie sur le jeu de validation (20 % du baseline, split temporel) est vérifié. Un taux >20 % déclenche un rejet automatique du modèle et la conservation du modèle précédent — évitant le déploiement d'un modèle entraîné sur une baseline polluée.
4. Feedback SOC : les classifications manuelles (faux positif → IP reclassée « human » dans la baseline ; vrai positif → IP exclue de la baseline) permettent un nettoyage itératif de la baseline au fil du temps.
5. Ensemble triple (§2.4.2c) : le XGBoost supervisé entraîné sur les labels accumulés constitue un « correcteur » qui atténue les erreurs systématiques des modèles non-supervisés.

6.3 Vie privée et conformité

Le fingerprinting réseau opère sans déchiffrement TLS et sans exécution de code côté client, ce qui le rend compatible RGPD (pas de données personnelles collectées au-delà de l'IP source, qui est une donnée technique nécessaire à la communication réseau). JA4H_d (fingerprint user) est explicitement conçu pour le tracking non-SPII.

6.4 Scalabilité

L'architecture ClickHouse avec vues matérialisées synchrones permet le traitement en temps quasi-réel de ~100k requêtes/seconde sur du matériel standard. Les TTL à 2 heures sur les données brutes et 7 jours sur les agrégations maintiennent un volume de données constant. Le modèle IF s'entraîne en <2 secondes sur la baseline (~500-10000 sessions), permettant un cycle de 5 minutes.

6.5 Limites des techniques proposées

Technique	Limite principale
Path Sequence Entropy	Nécessite un volume minimum de requêtes par session
Bipartite Fleet Graph	Computationnellement coûteux sur de grands graphes
Cadence Fingerprint	Le jitter randomisé de qualité peut imiter un humain
Resource Dependency Tree	Inapplicable aux APIs (pas de cascade HTML→assets)
Intra-Session JA4 Drift	Nécessite des sessions longues (>10 min)
DNS Shadow	Nécessite la capture DNS (extension de ja4sentinel)
Compression Invariant	Nécessite une instrumentation côté serveur
Cross-Domain Linking	Uniquement pertinent en environnement multi-host

---

7. Conclusion

La détection du trafic HTTP malveillant est un problème fondamentalement multi-dimensionnel qui ne peut être résolu par aucune technique isolée. Ce document a montré que :

1. Les règles statiques (CRS) sont nécessaires mais insuffisantes : elles couvrent les attaques syntaxiques connues mais sont aveugles aux attaques comportementales et aux payloads polymorphes.

2. Le fingerprinting multi-protocole (JA4+) fournit une base d'identification robuste : en combinant TLS (JA4), TCP (JA4T), et HTTP (JA4H), il est possible d'identifier les applications, les OS, les tunnels, et les bibliothèques TLS sans déchiffrement.

3. La corrélation inter-couches est le multiplicateur de force : une feature isolée (ex: has_accept_language) est facilement contournable ; mais la corrélation de 59 features sur 5 couches (L3→L7) crée un espace de détection exponentiellement plus difficile à émuler.

4. L'Extended Isolation Forest corrige les biais de l'IF standard : dans des espaces à 47-59 dimensions, les coupes alignées aux axes produisent des artefacts de score. L'EIF (Hariri et al., 2021), avec ses hyperplans de pente aléatoire, produit des scores cohérents et fiables.

5. L'ensemble hybride triple-voix est l'architecture cible : la combinaison EIF (anomalies zero-day) + Autoencoder (corrélations non-linéaires) + XGBoost supervisé (patterns connus) via un méta-learner adaptatif surpasse chaque composant en isolation, comme le démontrent les travaux sur les ensembles hybrides (Jamshidi et al., 2025 ; Basbous et al., 2026).

6. Les techniques proposées exploitent des signaux sous-utilisés : la séquence temporelle des chemins, les graphes de co-occurrence réseau, la cadence inter-requêtes (incluant la loi de Benford et l'autocorrélation), l'arbre de dépendances de ressources, la dérive de fingerprint intra-session, la corrélation DNS passive, les invariants de compression, et le comportement cross-domaine ouvrent de nouvelles dimensions de détection, chacune orthogonale aux signaux existants.

7. La robustesse du pipeline exige une validation automatique : la gate condition sur le taux d'anomalie de validation, le drift detection par quantile digest, et l'élagage dynamique des features à variance nulle préviennent les déploiements de modèles dégradés.

Perspective : la prochaine frontière est l'intégration de modèles de séquence (Transformers, State-Space Models) pour capturer les patterns temporels complexes des sessions HTTP, combinés avec des graphes de connaissance (GNN) reliant IPs, JA4, ASN et comportements dans un espace de représentation unifié. Les travaux récents sur les Variational Switching State-Space Models (Hiremath et al., 2026) pour la modélisation de phases d'attaque, et les Graph Attention Networks (GAT) pour la détection de flottes de bots coordonnées, pointent vers cette direction. L'intégration de fingerprints HTTP/2 (SETTINGS frame, PRIORITY tree) constitue un vecteur de détection sous-exploité face aux outils d'évasion comme httpcloak qui imitent parfaitement les couches TLS et HTTP/1.1 mais pas encore les subtilités HTTP/2.

---

8. Références

Publications académiques

1. Liu, F.T., Ting, K.M., & Zhou, Z.H. (2008). "Isolation Forest." IEEE International Conference on Data Mining (ICDM).

2. Hariri, S., Kind, M.C., & Brunner, R.J. (2021). "Extended Isolation Forest." IEEE Transactions on Knowledge and Data Engineering (TKDE), 33(4), 1479-1489. arXiv:1811.02141.

3. Osama, H., et al. (2025). "Enhanced Web Payload Classification Using WAMM: An AI-Based Framework for Dataset Refinement and Model Evaluation." arXiv:2512.23610.

4. Sanna Passino, F., et al. (2025). "Clustering Terminal Session Commands for Cyber-Threat Analysis." Annals of Applied Statistics, 19(1), 586-613. arXiv:2301.02505.

5. Hiremath, P.S., et al. (2026). "PARD-SSM: Probabilistic Cyber-Attack Regime Detection via Variational Switching State-Space Models." arXiv (April 2026).

6. Sosnowski, M., et al. (2023). "Active TLS Stack Fingerprinting: Characterizing TLS Server Deployments at Scale." arXiv:2206.13230.

7. Anderson, B., et al. (2018). "Limitless HTTP in an HTTPS World: Inferring the Semantics of the HTTPS Protocol without Decryption." arXiv:1805.11544.

8. Hosain, M., et al. (2025). "Web Technologies Security in the AI Era: A Survey of CDN-Enhanced Defenses." arXiv (December 2025).

9. Kadel, J., et al. (2024). "BOTracle: A framework for Discriminating Bots and Humans." arXiv (December 2024).

10. Schraven, J., et al. (2025). "MAWIFlow Benchmark: Realistic Flow-Based Evaluation for Network Intrusion Detection." arXiv (June 2025).

11. Akbari, E., et al. (2025). "One task to rule them all: A closer look at traffic classification generalizability." arXiv (July 2025).

12. Mirsky, Y., Doitshman, T., Elovici, Y., & Shabtai, A. (2018). "Kitsune: An Ensemble of Autoencoders for Online Network Intrusion Detection." Network and Distributed Systems Security Symposium (NDSS). arXiv:1802.09089.

13. Baptiste, D., Saddem, R., Philippot, A., & Foyer, F. (2026). "Unsupervised Anomaly Detection in NSL-KDD Using β-VAE: A Latent Space and Reconstruction Error Approach." arXiv (February 2026).

14. Jamshidi, S., et al. (2025). "Lightweight Autoencoder-Isolation Forest Anomaly Detection for Green IoT Edge Gateways." arXiv (November 2025).

15. Basbous, F., et al. (2026). "Hybrid Autoencoder-Isolation Forest approach for time series anomaly detection." arXiv (March 2026).

16. Frizzo, D., et al. (2024). "Towards Transparent and Efficient Anomaly Detection in Industrial Processes through ExIFFI." arXiv (May 2024) — Extended Isolation Forest with Feature Importance.

17. Arcudi, A., et al. (2023). "Enhancing Interpretability and Generalizability in Extended Isolation Forests." arXiv (October 2023).

Projets et outils open-source

18. Althouse, J. (2023). "JA4+ Network Fingerprinting." FoxIO. https://github.com/FoxIO-LLC/ja4

19. Althouse, J. (2024). "JA4T: TCP Fingerprinting." FoxIO Blog. https://blog.foxio.io/ja4t-tcp-fingerprinting

20. OWASP Foundation. "OWASP ModSecurity Core Rule Set (CRS) v4." https://github.com/coreruleset/coreruleset

21. TecharoHQ. "Anubis — Bot Detection Rules." https://github.com/TecharoHQ/anubis

22. FingerprintJS. "BotD — Browser Bot Detection." https://github.com/fingerprintjs/BotD

23. Zalewski, M. (2013). "p0f v3 — Passive OS Fingerprinting." https://lcamtuf.coredump.cx/p0f3/

24. sardanioss. "httpcloak — Go HTTP Client with Browser-Identical TLS/HTTP2 Fingerprinting." https://github.com/sardanioss/httpcloak

25. Imperva. (2024). "2024 Bad Bot Report." https://www.imperva.com/resources/reports/2024-bad-bot-report/

26. Hariri, S. "Extended Isolation Forest (eif)." https://github.com/sahandha/eif — Implémentation Python, v2.0.2.

27. CrowdSec. "CrowdSec Security Engine." https://github.com/crowdsecurity/crowdsec — IDS/WAF collaboratif open-source.

28. Coraza WAF. "Coraza — Enterprise-grade WAF in Go." https://github.com/corazawaf/coraza

Standards et RFC

29. RFC 8701 — "Applying Generate Random Extensions And Sustain Extensibility (GREASE) to TLS Extensibility." (2020).

30. RFC 9293 — "Transmission Control Protocol (TCP)." (2022).

31. RFC 8446 — "The Transport Layer Security (TLS) Protocol Version 1.3." (2018).

---

Document généré le 7 avril 2026, mis à jour le 8 avril 2026. Les techniques proposées au §5 sont originales et n'ont pas été publiées précédemment. Les sections §2.4.2b, §2.4.2c et les mises à jour de §6-§7 intègrent les résultats de la revue de littérature 2023-2026.