diff --git a/docs/THESIS_HTTP_Traffic_Detection.md b/docs/THESIS_HTTP_Traffic_Detection.md index a348a51..69c4ed1 100644 --- a/docs/THESIS_HTTP_Traffic_Detection.md +++ b/docs/THESIS_HTTP_Traffic_Detection.md @@ -8,7 +8,7 @@ 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. +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 **13 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. @@ -22,7 +22,10 @@ L'architecture opérationnelle intègre **85 features** réparties sur **8 famil - 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) + - 2.5 Détection côté client et fingerprinting passif + - 2.5.1 JavaScript Challenges + - 2.5.2 FingerprintJS BotD + - 2.5.3 Fingerprinting HTTP/2 passif côté serveur 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 @@ -32,6 +35,7 @@ L'architecture opérationnelle intègre **85 features** réparties sur **8 famil - 3.6 Corrélation inter-couches - 3.7 Agrégation temporelle et features dérivées - 3.8 Détection ML semi-supervisée + - 3.9 Browser Signature Detection (browser_matcher) 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) @@ -276,7 +280,7 @@ Le trafic web n'est pas stationnaire : les navigateurs sont mis à jour (changem 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. +**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'implémentation actuelle reste à 5 quantiles (p10, p25, p50, p75, p90) ; l'extension à p5/p95 (ou l'utilisation d'un t-digest complet) est identifiée comme amélioration future pour ces features spécifiques. **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. @@ -306,16 +310,27 @@ Les solutions commerciales (Cloudflare Turnstile, DataDome, PerimeterX) injecten 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.5.3 Fingerprinting HTTP/2 passif côté serveur + +Contrairement aux challenges JS (§2.5.1) et à la détection d'automates BotD (§2.5.2), le fingerprinting HTTP/2 passif ne nécessite aucune interaction côté client. Il exploite les artefacts de connexion que chaque implémentation HTTP/2 produit involontairement lors de la négociation du protocole. + +Bartlett (Cloudflare, 2023) et l'écosystème de détection Akamai utilisent le format de fingerprint Akamai : `SETTINGS|WINDOW_UPDATE|PRIORITY|PSEUDO_HEADER_ORDER`. Ce format est devenu un standard de facto adopté par les solutions de détection de bots commerciales. + +**Avantage fondamental** sur les challenges JS : le fingerprint HTTP/2 est produit par la couche de transport, en dessous du niveau applicatif. Un outil d'évasion doit implémenter une couche HTTP/2 complète et correcte pour éviter la détection, ce qui implique de reproduire des dizaines de paramètres internes (tailles de fenêtre, priorités, ordres de frames) qui sont transparents pour le développeur mais caractéristiques de chaque implémentation. httpcloak réussit à imiter les SETTINGS Chrome et le WINDOW_UPDATE, mais échoue systématiquement sur l'ordre exact des pseudo-headers (il utilise l'ordre curl par défaut) — créant une incohérence détectable. + +L'architecture opérationnelle implémente ce fingerprinting via le module `browser_matcher` (§3.9), qui, côté Apache (après terminaison TLS, les données HTTP/2 sont en clair), extrait ces paramètres et les corrèle avec les signaux TLS et HTTP. + ### 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 | +| JA4+ fingerprinting | Multi-protocole, stable | Contournable par imitation de stack TLS | | 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 | +| H2 fingerprinting passif | Passif, pas d'interaction client, stable 2+ ans | Inapplicable derrière reverse proxy CDN (SETTINGS perdus) | **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. @@ -372,10 +387,10 @@ BotD (open-source) détecte les frameworks d'automatisation (Puppeteer, Playwrig │ ┌──────▼───────┐ │ bot_detector │ - │ EIF+AE+XGB │ - │ +MetaLearner │ - │ +ExIFFI │ - │ +fleet.py │ + │ EIF + AE + XGB│ + │ + MetaLearner │ + │ + ExIFFI │ + │ + fleet.py │ │ HDBSCAN camp. │ │ SHAP explain │ └──────┬───────┘ @@ -507,10 +522,143 @@ browser_confidence = Σ (poids_i × score_axe_i) ∈ [0, 1] | 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. +> **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. +**Limites du système actuel** : le `browser_confidence` à 6 axes repose sur des conditions majoritairement binaires ou sur des lookups de dictionnaire. Les axes 2, 5 et 6 évaluent des propriétés booléennes grossières plutôt qu'une correspondance structurée avec les signatures connues de chaque famille navigateur. La section §3.9 décrit le moteur de signature (`browser_matcher`) qui remplace cette logique par une correspondance précise basée sur les paramètres HTTP/2 SETTINGS, l'ordre des pseudo-headers et les profils TLS par famille. + +### 3.9 Browser Signature Detection (browser_matcher) + +Le `browser_confidence` à 6 axes (§3.8) fournit un score agrégé utile comme feature ML, mais son logique de bypass (seuil 0.55) manque de précision pour les outils d'évasion modernes (httpcloak, curl_cffi) qui imitent les couches TLS et HTTP/1.1 sans reproduire les subtilités HTTP/2. Le moteur `browser_matcher` répond à cette limite en implémentant une correspondance structurée par famille navigateur. + +#### 3.9.1 Principes du fingerprinting HTTP/2 passif + +HTTP/2 introduit plusieurs artefacts de connexion mesurables passivement depuis le flux TCP déchiffré côté serveur Apache (mod_http2 a accès au flux HTTP/2 entrant en clair après terminaison TLS) : + +**Frame SETTINGS** : envoyé par le client immédiatement après le handshake, il contient les paramètres de connexion sous forme de paires clé-valeur. Chaque famille navigateur utilise un ensemble fixe de clés avec des valeurs caractéristiques : + +| Paramètre | Chrome 119+ | Firefox 90+ | Safari 15+ | curl | Go net/http | +|-----------|------------|------------|-----------|------|-------------| +| `HEADER_TABLE_SIZE` (ID 1) | 65536 | 65536 | absent | absent | absent | +| `ENABLE_PUSH` (ID 2) | 0 | 0 | 0 | 0 | absent | +| `MAX_CONCURRENT_STREAMS` (ID 3) | absent | absent | **100** | absent | absent | +| `INITIAL_WINDOW_SIZE` (ID 4) | **6291456** | **131072** | **2097152** | 65535 | 4194304 | +| `MAX_FRAME_SIZE` (ID 5) | absent | **16384** | absent | absent | absent | +| `MAX_HEADER_LIST_SIZE` (ID 6) | 262144 | absent | absent | absent | 10485760 | +| `ENABLE_CONNECT_PROTOCOL` (ID 9) | absent | absent | **1** | absent | absent | + +> Le paramètre `INITIAL_WINDOW_SIZE` seul discrimine Chrome (6 291 456, soit 48× Firefox), Firefox (131 072), Safari (2 097 152), et tous les outils non-navigateur (≤1 048 576). + +**WINDOW_UPDATE initial** : après l'échange SETTINGS, le client envoie un frame WINDOW_UPDATE incrémentant la fenêtre de connexion. Cette valeur est fixe par implémentation et constitue un signal de discrimination fiable : + +| Navigateur | Valeur WINDOW_UPDATE | Écart toléré | +|-----------|---------------------|---------------| +| Chrome 119+ | 15 663 105 | ±1 000 | +| Firefox 90+ | 12 517 377 | ±1 000 | +| Safari 15+ | 10 420 225 | ±1 000 | +| curl | absent (0) | — | +| Python httpx | absent (0) | — | +| Go net/http | 1 073 676 289 | ±1 000 | + +**Ordre des pseudo-headers** : les pseudo-headers HTTP/2 (`:method`, `:authority`, `:scheme`, `:path`) doivent être présents dans chaque HEADERS frame. Leur ordre est déterminé par l'implémentation HTTP/2 du client et reste stable à travers les versions : + +| Navigateur | Ordre | Mnémonique | +|-----------|-------|------------| +| Chrome | `:method` `:authority` `:scheme` `:path` | **masp** | +| Firefox | `:method` `:path` `:authority` `:scheme` | **mpas** | +| Safari | `:method` `:scheme` `:path` `:authority` | **mspa** | +| curl | `:method` `:path` `:scheme` `:authority` | **mpsa** | + +**PRIORITY frames** (RFC 7540, déprécié RFC 9218) : Firefox envoie encore des PRIORITY frames de démarrage (streams 3, 5, 7, 9, 11, 13) pour signaler les dépendances d'arbre de priorité. Chrome ≥ v119 n'envoie plus aucun PRIORITY frame (migration vers le système de priorités étendu RFC 9218). La présence de ces frames est un discriminant fort Chrome/Firefox. + +#### 3.9.2 Architecture du moteur browser_matcher + +Le moteur est implémenté en deux modules Python : + +**`browser_signatures.py`** : base de données de signatures par famille. Chaque entrée définit : +- `h2_settings_exact` : dict {clé_id: valeur_attendue} +- `h2_settings_forbidden_keys` : clés qui ne doivent pas être présentes +- `h2_window_update` + tolérance +- `h2_priority_frames_expected` : booléen +- `pseudo_header_order` : liste ["m", "a", "s", "p"] +- `tls` : version min, ALPN requis, GREASE attendu, plages cipher/ext count +- `headers_required` / `headers_forbidden` : listes d'en-têtes HTTP + +Les signatures négatives (`NON_BROWSER_SIGNATURES`) définissent les patterns curl, python-httpx, et Go net/http pour invalider un score partiel élevé. + +**`browser_matcher.py`** : moteur de scoring. Pour chaque session, un score 0–1 est calculé par famille à partir de 7 dimensions pondérées : + +| Dimension | Poids | Logique | +|-----------|-------|---------| +| H2 SETTINGS match | 0.30 | Toutes les clés attendues présentes avec valeur exacte ET aucune clé interdite → 1.0. Chaque écart → −0.15 | +| H2 WINDOW_UPDATE | 0.15 | `abs(observé − attendu) ≤ tolérance` → 1.0 ; absent (=0) → 0.0 | +| Pseudo-header order | 0.15 | Correspondance exacte → 1.0 ; 3/4 correct → 0.5 ; sinon 0.0 | +| H2 PRIORITY frames | 0.10 | Présence/absence conforme à l'attendu → 1.0 | +| HTTP headers cohérence | 0.15 | Tous `required` présents (+0.5) ; aucun `forbidden` présent (+0.5) | +| Structure TLS | 0.10 | TLS 1.3 + ALPN h2 + cipher_count dans plage + ext_count dans plage (0.25 chacun) | +| JA4 dict lookup | 0.05 | Correspondance dans `dict_browser_ja4` pour cette famille → 1.0 | + +``` +score_famille = Σ (poids_i × score_dimension_i) ∈ [0, 1] +``` + +#### 3.9.3 Logique de décision et intégration dans le pipeline + +Le `browser_matcher` s'insère dans la trifurcation du trafic comme deuxième porte, après la détection des bots connus et avant la baseline humaine : + +``` +Trafic entrant (view_ai_features_1h) + │ + ┌────┴───────────────────┐ + │ dict_bot_ip/ja4 match ? │──OUI─▶ KNOWN_BOT + │ Anubis DENY ? │ + └────┬───────────────────┘ + │ NON + ┌────┴───────────────────────────┐ + │ browser_matcher score ? │── score ≥ seuil_famille + │ Chrome ≥ 0.72 | Firefox ≥ 0.68 │ ET pas signature négative + │ Safari ≥ 0.68 │─▶ LEGITIMATE_BROWSER + └────┬───────────────────────────┘ + │ score dans [0.45, seuil[ (zone grise) + │ → score partiel : final_score × (1 − 0.5 × match_score) + │ score < 0.45 : pas d'effet + ┌────┴───────────────────┐ + │ asn_label == 'human' ? │──OUI─▶ Baseline IF + └────┬───────────────────┘ + │ NON + ▼ + Scoring triple-voix (EIF + AE + XGB) +``` + +**Gestion des imitateurs partiels** : les outils comme httpcloak répliquent parfaitement les SETTINGS H2 de Chrome et le WINDOW_UPDATE, mais leur pseudo-header order correspond souvent à curl (mpsa) plutôt que Chrome (masp). Le score résultant (~0.60) tombe en zone grise : le scoring ML est maintenu, mais le score final est atténué proportionnellement, réduisant les faux positifs sans exclure complètement la session. + +**Gestion des proxies inverses** : lorsque `has_xff = 1` (trafic terminé par un CDN), les SETTINGS H2 du client d'origine sont perdus (le proxy rouvre une connexion H2 vers Apache). Dans ce cas, les 4 dimensions H2 (SETTINGS, WINDOW_UPDATE, pseudo-header order, PRIORITY frames — 70 % du poids total) sont neutralisées à 0.5 (score neutre), et la détection non-navigateur basée sur H2 est également désactivée. Le scoring repose alors exclusivement sur les 3 dimensions restantes : HTTP headers (0.15), structure TLS (0.10) et JA4 dict (0.05). + +#### 3.9.4 Nouvelles features dérivées + +Le moteur produit les colonnes suivantes, intégrées dans `view_ai_features_1h` : + +| Feature | Type | Description | +|---------|------|-------------| +| `browser_match_chrome` | Float32 | Score de correspondance Chrome (0–1) | +| `browser_match_firefox` | Float32 | Score de correspondance Firefox (0–1) | +| `browser_match_safari` | Float32 | Score de correspondance Safari (0–1) | +| `browser_match_max` | Float32 | Max(chrome, firefox, safari) | +| `browser_family_detected` | String | Famille détectée ou vide | +| `h2_window_update_value` | UInt32 | Valeur WINDOW_UPDATE observée | +| `h2_has_priority_frames` | UInt8 | 1 si PRIORITY frames présents | +| `h2_pseudo_order` | String | Ordre observé (ex: "m,a,s,p") | +| `tls_h2_family_mismatch` | UInt8 | 1 si JA4 dit Chrome mais H2 SETTINGS dit Firefox/outil | + +La feature `tls_h2_family_mismatch` est intégrée dans la **Famille 4 (Cohérence cross-layer)** du vecteur ML : une incohérence entre la famille de la bibliothèque TLS (extraite du JA4) et la famille indiquée par le fingerprint HTTP/2 signale avec haute précision un outil d'évasion qui imite la couche TLS sans reproduire la couche HTTP/2 cohérente. + +#### 3.9.5 Maintenance des signatures + +Les fingerprints HTTP/2 sont remarquablement stables : Chrome maintient le même SETTINGS H2 depuis la version 119 (novembre 2023) jusqu'à 142 (2026), soit plus de 2 ans de stabilité. Cela contraste avec les fingerprints JA4 TLS qui varient à chaque mise à jour de cipher suite. La base de signatures est stockée dans la table ClickHouse `ja4_processing.browser_h2_signatures`, rechargée toutes les 24h dans le module Python, permettant des mises à jour sans redéploiement. + +Les sessions dont le fingerprint H2 est inconnu mais dont le comportement est navigateur-like sont logées dans une queue de revue, alimentant progressivement la base de signatures avec les nouvelles versions de navigateurs. + --- ## 4. Taxonomie des features de détection @@ -527,7 +675,7 @@ Nous proposons une classification en 8 familles (**85 features totales**) : `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` +`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`, `tls_h2_family_mismatch` ### 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` @@ -536,7 +684,7 @@ Nous proposons une classification en 8 familles (**85 features totales**) : `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` +`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`, `browser_match_chrome`, `browser_match_firefox`, `browser_match_safari`, `browser_match_max`, `h2_window_update_value`, `h2_has_priority_frames` ### 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 : @@ -702,7 +850,7 @@ Chaque technique de détection engendre une contre-mesure : - 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). +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 @@ -740,6 +888,7 @@ L'architecture ClickHouse avec vues matérialisées synchrones permet le traitem | 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 | +| Browser Signature Detection (§3.9) | Les 4 dimensions H2 (70 % du poids) sont neutralisées derrière un reverse proxy CDN (`has_xff=1`) ; le scoring repose alors sur les seuls signaux TLS + HTTP headers + JA4 dict (30 % du poids) | ### 6.6 Résultats de déploiement @@ -754,8 +903,9 @@ L'architecture décrite a été déployée et validée en conditions de producti | 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 | +| Architecture ML | Triple-voix (EIF + AE + XGBoost) + MetaLearner + ExIFFI + browser_matcher | | Dashboard | 16 pages + 37 API routes | +| Familles navigateur découvertes | Chrome (masp, INITIAL\_WINDOW=6291456), Firefox (mpas, PRIORITY frames), Safari (mspa, SETTINGS ID 3+9) | 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`). @@ -777,13 +927,15 @@ La détection du trafic HTTP malveillant est un problème fondamentalement multi 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. +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. -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. +7. **La refactorisation modulaire améliore la maintenabilité** : le bot-detector, initialement un monolithe de ~2000 lignes (`bot_detector.py`), a été restructuré en **13 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. +9. **La détection de signature navigateur (browser_matcher) est la troisième porte du pipeline** : en remplaçant la logique binaire du `browser_confidence` par un moteur de correspondance structurée sur 7 dimensions (SETTINGS H2, WINDOW_UPDATE, ordre des pseudo-headers, PRIORITY frames, headers HTTP, structure TLS, JA4 dict), le système identifie les vrais navigateurs avec une précision que les outils d'évasion (httpcloak, curl_cffi) ne peuvent pas contourner simultanément sur toutes les dimensions. La nouvelle feature `tls_h2_family_mismatch` est un signal de détection à haute précision : l'incohérence entre la famille TLS et la famille H2 trahit les imitateurs qui répliquent uniquement la couche TLS. + +**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 (§5.6) et invariant de compression via instrumentation Apache (§5.7)) constitue les priorités d'infrastructure à 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, et l'extension des quantiles de drift de 5 à 9 points (p5→p95) pour les features multimodales, constituent les pistes d'amélioration prioritaires du pipeline. --- @@ -869,4 +1021,5 @@ La détection du trafic HTTP malveillant est un problème fondamentalement multi --- -*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).* +*Document généré le 7 avril 2026, mis à jour le 9 avril 2026, révisé le 10 avril 2026 (v3 — 10 avril 2026 après-midi). 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, §2.5.3, §3.8, §3.9, §4, §5.2, §5.8, §6.5, §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 implémentées ou en cours (MetaLearner, ExIFFI, KL divergence drift, fleet detection, HTTP/2 fingerprinting passif, cross_domain_path_similarity, browser_matcher à 7 dimensions, tls_h2_family_mismatch).* +