# 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 et d'implémenter huit techniques originales exploitant des signaux jusqu'ici sous-utilisés.

L'architecture opérationnelle intègre **85 features** réparties sur **8 familles** et **5 couches réseau** (L3→L7), un **ensemble triple voix** (Extended Isolation Forest + Autoencoder + XGBoost) enrichi par un **méta-learner à régression logistique**, l'explicabilité **ExIFFI** et **SHAP**, le **clustering HDBSCAN** de campagnes, la détection de **flottes coordonnées** (graphe bipartite JA4×ASN via NetworkX), et le **fingerprinting HTTP/2 passif**. L'ensemble est implémenté en **12 modules Python** spécialisés et déployé en cycle de 5 minutes sur un pipeline ClickHouse dual-database.

**Mots-clés** : fingerprinting réseau, JA4+, HTTP/2 fingerprinting, détection de bots, Extended Isolation Forest, ExIFFI, autoencoders, méta-learner, ensemble hybride, corrélation TCP/TLS/HTTP, WAF, classification de trafic, apprentissage semi-supervisé, clustering HDBSCAN.

---

## Table des matières

1. [Introduction](#1-introduction)
2. [État de l'art](#2-état-de-lart)
   - 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-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](#4-taxonomie-des-features-de-détection)
5. [Techniques originales proposées](#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](#6-discussion-et-limites)
7. [Conclusion](#7-conclusion)
8. [Références](#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 **85 features** sur **8 familles** et 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) définissant des actions par bot (ALLOW, DENY, WEIGH, CHALLENGE). L'implémentation dans l'architecture étudiée simplifie le modèle à deux dictionnaires ClickHouse :
- `dict_anubis_ip` : layout IP_TRIE pour la correspondance CIDR, résolvant les plages IP vers un score et une action.
- `dict_anubis_asn` : lookup par numéro ASN, associant un score et une action par système autonome.

La résolution utilise une priorité COALESCE(IP, ASN) : une correspondance IP/CIDR prend le pas sur la correspondance ASN. Ce schéma à deux niveaux remplace l'approche multi-critères initiale (UA regex, pays, etc.) par un modèle plus robuste et performant. L'intégration dans le pipeline ML utilise 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.

**Implémentation** : l'architecture utilise la bibliothèque `isotree` (Cortes, 2023), qui fournit une implémentation native en C++ de l'Extended Isolation Forest avec interface Python. Contrairement au package `eif` (Hariri) ou à `sklearn.ensemble.IsolationForest`, `isotree` supporte nativement les hyperplans de coupe aléatoire (extension level > 0) avec des performances optimisées pour les espaces de haute dimension. Paramètres : `ntrees=300`, `contamination=0.001`.

**Calibration des scores** : `isotree` retourne un score dans [0, 1] où >0.5 indique une anomalie. Pour maintenir la compatibilité avec la convention sklearn (scores négatifs = anomalies), l'architecture applique la transformation : `sklearn_equiv = 0.5 - isotree_score`. Le modèle est sérialisé via `joblib` avec ses statistiques de baseline (quantiles par feature) pour la détection de dérive (§2.4.3).

**Architecture de scoring bifurquée** :
L'architecture étudiée exécute deux modèles EIF 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 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
                    └────────────┬────────────┘
                                 │
                    ┌────────────▼────────────┐
                    │  Pondération linéaire   │
                    │  fixe (configurable)    │
                    └────────────┬────────────┘
                                 │
                    final_threat_score ∈ [0, 1]
```

**Formule de combinaison** :

```
final = (1 - XGB_WEIGHT) × ((1 - AE_WEIGHT) × eif_norm + AE_WEIGHT × ae_norm) + XGB_WEIGHT × xgb_prob
```

Avec les poids par défaut : `AE_WEIGHT = 0.30`, `XGB_WEIGHT = 0.20`. Ces poids sont configurables via variables d'environnement, permettant un ajustement opérationnel sans retraining.

- **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.
- **Pondération et méta-learner** : la combinaison utilise par défaut une pondération linéaire fixe (`AE_WEIGHT=0.30`, `XGB_WEIGHT=0.20`), configurable via variables d'environnement. Lorsque l'historique de labels accumulés dépasse un seuil minimal (1000 échantillons), un **méta-learner par régression logistique** (`MetaLearner`) est entraîné automatiquement sur ces labels pour apprendre les poids optimaux contextuellement :

```
P(bot) = logistic(w1×eif + w2×ae + w3×xgb + w4×volume + w5×correlated + bias)
```

Le méta-learner se substitue à la pondération linéaire fixe dès qu'il est entraîné ; la pondération fixe constitue le fallback tant que les données de labels sont insuffisantes. Cette architecture combine la transparence opérationnelle initiale avec l'adaptation progressive aux patterns spécifiques de l'environnement déployé.

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 basée sur une approximation par quantiles à 5 points. Pour chaque feature, les quantiles (p10, p25, p50, p75, p90) de la distribution d'entraînement sont sauvegardés avec le modèle sérialisé. Lors de la vérification de dérive, des échantillons synthétiques sont générés par sampling par quantile inverse à partir de ces 5 points, reconstituant une CDF approchée par interpolation linéaire. Un test de Kolmogorov-Smirnov à 2 échantillons est ensuite appliqué entre ces échantillons synthétiques et la distribution courante. Une **divergence KL** (Kullback-Leibler) est calculée en complément par discrétisation en histogrammes ; une feature est marquée « en dérive » si le test KS **ou** la divergence KL dépasse les seuils configurés. Si >30 % des features dérivent simultanément, un retraining forcé est déclenché. La **dérive adversariale** est distinguée de la dérive naturelle : si de nombreuses features dérivent simultanément dans la même direction (score de corrélation directionnelle élevé), une alerte spécifique est émise, indiquant une manipulation intentionnelle plutôt qu'une évolution organique du trafic.

**Note méthodologique** : cette approximation par 5 quantiles est adéquate pour les distributions unimodales (majorité des features réseau), mais peut manquer des déplacements de masse dans les features multimodales — `asset_ratio`, `post_ratio`, et `orphan_ratio` étant typiquement bimodales ou fortement asymétriques. L'ajout de quantiles supplémentaires (p5, p95) ou l'utilisation d'un t-digest complet améliorerait la fidélité pour ces cas. L'implémentation actuelle reste à 5 quantiles (p10, p25, p50, p75, p90) ; l'extension à p5/p95 est identifiée comme amélioration future.

**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 HDBSCAN.

#### 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.

En complément, l'architecture implémente **ExIFFI** (Extended Isolation Forest Feature Importance, Frizzo et al. 2024 ; Arcudi et al. 2023) — une méthode d'importance de features native à l'EIF basée sur la profondeur moyenne d'isolation par feature. ExIFFI est activé automatiquement quand SHAP n'est pas disponible (bibliothèque `shap` non installée), et ses importances sont comparées aux top-5 SHAP dans l'interface SOC pour une double perspective sur les features discriminantes. Pour l'Autoencoder, l'**erreur de reconstruction par feature** est calculée individuellement, permettant d'identifier quelles dimensions de l'espace d'entrée ont le plus contribué à l'anomalie AE — complémentaire aux importances globales EIF/SHAP.

### 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  │
                               │ ┌───────────┐│
                               │ │ ja4_logs   ││ (http_logs_raw,
                               │ │            ││  http_logs)
                               │ ├───────────┤│
                               │ │ ja4_       ││ (agrégations,
                               │ │ processing ││  ML tables,
                               │ │            ││  dicts, vues)
                               │ └───────────┘│
                               │ 13 fichiers  │
                               │ SQL (00→12)  │
                               └──────┬───────┘
                                      │
                               ┌──────▼───────┐
                               │ bot_detector  │
                               │ EIF+AE+XGB   │
                               │ +MetaLearner  │
                               │ +ExIFFI       │
                               │ +fleet.py     │
                               │ HDBSCAN camp. │
                               │ SHAP explain  │
                               └──────┬───────┘
                                      │
                               ┌──────▼───────┐
                               │  Dashboard   │
                               │  55 routes   │
                               │  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 triple-voix (EIF + AE + XGB)
         │
    ┌────┴────────────────────────┐
    │ score < seuil adaptatif ?  │──OUI──▶ ANOMALIE
    │                             │         + SHAP top-5
    │                             │         + HDBSCAN 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 |
| Browser conf. ≥ 0.55 | LEGITIMATE_BROWSER | Bypass ML |

#### Détection multifactorielle de navigateur légitime

Au-delà de la détection d'anomalies, l'architecture implémente une identification positive des navigateurs légitimes via un score de confiance multifactoriel à **6 axes** :

```
browser_confidence = Σ (poids_i × score_axe_i)    ∈ [0, 1]
```

| Axe | Poids | Signal | Méthode |
|-----|-------|--------|---------|
| 1. JA4 Known | 0.25 | Correspondance `dict_browser_ja4` | Lookup du hash JA4 dans le dictionnaire de fingerprints navigateur connus |
| 2. JA4 Structure | 0.15 | Cohérence structurelle TLS | TLS 1.3, ALPN h2/h3, nombre de cipher suites et d'extensions dans les plages navigateur |
| 3. HTTP Modern | 0.25 | Score navigateur moderne | `modern_browser_score`, présence `Accept-Language`, headers `Sec-Fetch-*` |
| 4. Navigation Behavior | 0.15 | Comportement de navigation | Présence cookies, Referer, `asset_ratio` dans les plages humaines |
| 5. TLS/TCP Coherence | 0.15 | Cohérence protocolaire | ALPN cohérent, Window Scaling présent, `tls12_ratio` faible |
| 6. HTTP/2 Coherence | 0.05 | Cohérence fingerprint HTTP/2 | Fingerprint SETTINGS H2 connu + cohérent avec JA4 (`dict_browser_h2`) |

> **Note** : Le poids de l'axe 5 (TLS/TCP Coherence) a été réduit de 0.20 à 0.15 pour accommoder le nouvel axe 6 (HTTP/2 Coherence, poids 0.05), maintenant la somme totale à 1.00.

**Seuil de décision** : `browser_confidence ≥ 0.55` ET `browser_family` identifié (Chrome, Firefox, Safari, Edge) → classification `LEGITIMATE_BROWSER`. Cette classification permet un bypass du scoring ML pour le trafic à haute confiance, réduisant les faux positifs sur le trafic humain vérifié tout en maintenant la détection sur le trafic ambigu.

---

## 4. Taxonomie des features de détection

Nous proposons une classification en 8 familles (**85 features totales**) :

### Famille 1 : Volumétrie et vitesse
`hits`, `hit_velocity`, `max_keepalives`, `count_login_post`

### Famille 2 : Diversité et exploration
`fuzzing_index`, `path_diversity_ratio`, `url_depth_variance`, `distinct_ja4_count`, `distinct_header_orders`, `is_ua_rotating`, `ja4_drift_ratio`

### 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`, `sec_ch_mobile_mismatch`, `is_fake_navigation`

### 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`, `fingerprint_coherence_score`, `h2_settings_known`, `h2_pseudo_order_match`, `h2_ja4_coherence`, `h2_settings_rare`

### 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`, `has_xff`, `true_window_size`, `window_mss_ratio`

### Famille 6 : Comportement de navigation
`asset_ratio`, `direct_access_ratio`, `orphan_ratio`, `temporal_entropy`, `post_ratio`, `head_ratio`, `http_scheme_ratio`, `login_post_concentration`, `unusual_content_type_ratio`, `non_standard_port_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`, `browser_confidence`, `browser_family`, `is_known_browser`, `browser_consistency_score`, `axis_ja4_known`, `axis_ja4_struct`, `axis_http_modern`, `axis_nav_behavior`, `axis_tls_coherence`, `axis_h2_coherence`

### Famille 8 : Features de thèse (§5)
Features originales implémentées dans `view_thesis_features_1h` et les tables d'agrégation dédiées :
`path_transition_entropy`, `cadence_cv`, `lag1_autocorrelation`, `burst_ratio`, `pause_ratio`, `benford_deviation`, `root_to_first_asset_delay`, `asset_load_stddev`, `ja4_drift_ratio`, `host_diversity`, `host_sweep_speed`, `host_coverage_uniformity`, `cross_domain_path_similarity`

---

## 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*).

✅ **Statut d'implémentation** : Implémenté dans `agg_path_sequences_1h` (table d'agrégation ClickHouse) et `view_thesis_features_1h` (colonne `path_transition_entropy`). Utilisé dans le vecteur de features du bot-detector.

### 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.

✅ **Statut d'implémentation** : Implémenté dans le module `fleet.py` du bot-detector. À chaque cycle, un graphe bipartite G = (JA4 ∪ ASN, E) est construit via **NetworkX** depuis les sessions du cycle courant, puis projeté sur les nœuds JA4. La détection de communautés est appliquée via HDBSCAN sur l'espace latent des co-occurrences. Le `fleet_score = taille_communauté × densité_arêtes / log(nb_ASN)` est calculé par communauté. Les résultats sont stockés dans la table `ja4_processing.fleet_detections` et les IPs appartenant à une communauté à `fleet_score` élevé reçoivent un malus de score dans le pipeline final.

### 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`.

✅ **Statut d'implémentation** : Implémenté dans `agg_request_timing_1h` et `view_thesis_features_1h`. Les 4 métriques sont calculées : `cadence_cv`, `lag1_autocorrelation`, `burst_ratio`, `benford_deviation`. Utilisées dans le scoring du bot-detector.

### 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).

✅ **Statut d'implémentation** : Implémenté dans `agg_resource_cascade_1h` et `view_resource_cascade_1h`. Colonnes `root_to_first_asset_delay` et `asset_load_stddev` calculées dans le schéma SQL (`12_thesis_features.sql`).

### 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.

✅ **Statut d'implémentation** : Implémenté dans `view_thesis_features_1h` (colonne `ja4_drift_ratio`). Utilisé dans le vecteur `feats_complet` du modèle Complet.

### 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.

❌ **Statut d'implémentation** : Non implémenté. Nécessite l'extension de ja4sentinel pour la capture DNS (UDP/53). Identifié comme travail futur.

### 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.

❌ **Statut d'implémentation** : Non implémenté. Nécessite une instrumentation côté serveur Apache (module de suivi des ratios de compression). Identifié comme travail futur.

### 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.

✅ **Statut d'implémentation** : Implémenté dans `view_thesis_features_1h`. Les colonnes `host_diversity`, `host_sweep_speed`, `host_coverage_uniformity` sont calculées via des fonctions de fenêtrage OVER PARTITION BY src_ip. La **distance de Jaccard cross-domaine** (`cross_domain_path_similarity`) est également implémentée via `arrayIntersect`/`arrayUnion` dans la vue : pour chaque src_ip visitant >1 host, l'intersection des sets de paths entre paires de hosts est calculée et le coefficient de Jaccard moyen est retourné. Un Jaccard élevé signale un scanner balayant les mêmes chemins (`/admin`, `/wp-login.php`, `/.env`) sur tous les hosts. Toutes les 4 métriques §5.8 sont utilisées dans le vecteur de features du bot-detector.

---

## 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 **85 features** sur **8 familles** et 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 |
| Browser Detection multifactorielle | Dépendant de la qualité de `dict_browser_ja4` et de la complétude des profils JA4 |

### 6.6 Résultats de déploiement

L'architecture décrite a été déployée et validée en conditions de production. Les métriques opérationnelles suivantes attestent de la viabilité du pipeline :

| Métrique | Valeur |
|----------|--------|
| Logs ingérés en production | 3M+ |
| Sessions analysées par cycle | ~34 000 |
| Anomalies détectées | ~777 |
| Durée d'un cycle de détection | 300 secondes (5 minutes) |
| Techniques originales implémentées (§5) | 7 sur 8 |
| Features totales | **85** (73 communes + 12 TCP/TLS) sur 8 familles |
| Modules bot-detector | **12** modules spécialisés (2912 lignes) |
| Architecture ML | Triple-voix (EIF + AE + XGBoost) + MetaLearner + ExIFFI |
| Dashboard | 16 pages + 37 API routes |

Ces résultats démontrent que l'approche multi-couches corrélée est opérationnellement viable à l'échelle, avec un cycle de détection de 5 minutes compatible avec les exigences temps quasi-réel d'un SOC. Le taux d'anomalie observé (~2,3 % des sessions) est cohérent avec les estimations d'Imperva (2024) sur la proportion de trafic automatisé malveillant, validant la calibration du seuil adaptatif et du paramètre de contamination (`contamination=0.001`).

L'implémentation de 7 des 8 techniques originales proposées (§5.1 Path Sequence Entropy, §5.2 Bipartite Fleet Graph, §5.3 Request Cadence Fingerprint, §5.4 Resource Dependency Tree, §5.5 Intra-Session JA4 Drift, §5.8 Cross-Domain Session Linking avec similarité de Jaccard) démontre la faisabilité pratique de ces approches dans un pipeline de production.

---

## 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 85 features sur 8 familles et 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), complétée par un **méta-learner par régression logistique** dès que l'historique de labels est suffisant, surpasse chaque composant en isolation, comme le démontrent les travaux sur les ensembles hybrides (Jamshidi et al., 2025 ; Basbous et al., 2026).

6. **7 des 8 techniques originales sont implémentées et opérationnelles** : la séquence temporelle des chemins (§5.1), le graphe bipartite JA4×ASN via fleet_detector (§5.2), la cadence inter-requêtes incluant la loi de Benford et l'autocorrélation (§5.3), l'arbre de dépendances de ressources (§5.4), la dérive de fingerprint intra-session (§5.5), et le comportement cross-domaine avec similarité de Jaccard (§5.8) sont déployés en production. La corrélation DNS passive (§5.6) et les invariants de compression (§5.7) restent identifiés comme travaux futurs nécessitant des extensions d'infrastructure. Les deux techniques restantes, §5.6 (DNS Shadow Analysis — nécessite l'extension de ja4sentinel à la capture UDP/53) et §5.7 (Compression Ratio Invariant — nécessite une instrumentation côté serveur Apache), sont identifiées comme priorités d'infrastructure à court terme.

7. **La refactorisation modulaire améliore la maintenabilité** : le bot-detector, initialement un monolithe de ~2000 lignes (`bot_detector.py`), a été restructuré en **12 modules spécialisés** (scoring, features, models, clustering, drift, explainability, fleet detection, metrics, etc.), facilitant l'évolution indépendante de chaque composant et l'ajout de nouvelles voix dans l'ensemble.

8. **La robustesse du pipeline exige une validation automatique** : la gate condition sur le taux d'anomalie de validation, le drift detection par approximation quantile, 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'implémentation des 2 techniques restantes (corrélation DNS passive via extension de ja4sentinel, invariant de compression via instrumentation Apache) constitue les priorités à court terme. L'extension du méta-learner à un modèle plus expressif (Gradient Boosted Meta-Learner ou MLP) sur un historique de labels plus riche constitue une piste d'amélioration du scoring d'ensemble.

---

## 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

29. Cortes, D. "isotree: Isolation-Based Outlier Detection." https://github.com/david-cortes/isotree — Implémentation C++ avec interface Python, support natif de l'Extended Isolation Forest.

30. Paszke, A., Gross, S., Massa, F., Lerer, A., Bradbury, J., Chanan, G., ... & Chintala, S. (2019). "PyTorch: An Imperative Style, High-Performance Deep Learning Library." *Advances in Neural Information Processing Systems (NeurIPS), 32*.

31. McInnes, L., Healy, J., & Astels, S. (2017). "hdbscan: Hierarchical density based clustering." *Journal of Open Source Software (JOSS), 2(11), 205*.

32. Chen, T., & Guestrin, C. (2016). "XGBoost: A Scalable Tree Boosting System." *Proceedings of the 22nd ACM SIGKDD International Conference on Knowledge Discovery and Data Mining (KDD)*.

33. Lundberg, S.M., & Lee, S.I. (2017). "A Unified Approach to Interpreting Model Predictions." *Advances in Neural Information Processing Systems (NeurIPS), 30*.

### Standards et RFC

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

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

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

---

*Document généré le 7 avril 2026, mis à jour le 9 avril 2026, révisé le 10 avril 2026. Les techniques proposées au §5 sont originales ; 7 des 8 sont implémentées et opérationnelles en production. Les sections §2.4.2c, §2.4.3, §2.4.5, §3.8, §4, §5.2, §5.8, §6.6 et §7 intègrent les résultats de la revue de littérature 2023-2026, les retours de déploiement, et les améliorations implementées (MetaLearner, ExIFFI, KL divergence drift, fleet detection, HTTP/2 fingerprinting, cross_domain_path_similarity).*
