# Détection et Classification du Trafic HTTP Malveillant : Techniques Actuelles, Approche Multi-Couches et Nouvelles Perspectives **Document technique — Avril 2026** --- ## Résumé La détection du trafic HTTP malveillant constitue un défi croissant à mesure que les attaquants adoptent des techniques d'évasion sophistiquées : rotation de fingerprints TLS, usurpation de User-Agent, navigation headless indistinguable des navigateurs réels, et botnets distribués exploitant des infrastructures résidentielles. Les pare-feu applicatifs (WAF) traditionnels, fondés sur des règles statiques telles que l'OWASP Core Rule Set (CRS), atteignent leurs limites face aux payloads polymorphes et aux attaques zero-day. Ce document présente une taxonomie complète des techniques de détection existantes — des signatures réseau (JA4+) à l'apprentissage automatique semi-supervisé — puis décrit une architecture de détection multi-couches opérationnelle (L3→L7), avant de proposer huit techniques originales exploitant des signaux jusqu'ici sous-utilisés. **Mots-clés** : fingerprinting réseau, JA4+, détection de bots, IsolationForest, Extended Isolation Forest, autoencoders, ensemble hybride, corrélation TCP/TLS/HTTP, WAF, classification de trafic, apprentissage semi-supervisé. --- ## Table des matières 1. [Introduction](#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 65+ features sur 7 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** : combinaison linéaire fixe des trois scores, configurable via variables d'environnement (`AE_WEIGHT`, `XGB_WEIGHT`). Contrairement à un méta-learner appris (régression logistique, stacking), cette approche offre une transparence totale et une interprétabilité immédiate pour les analystes SOC. 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. Si >30 % des features dérivent significativement, un retraining forcé est déclenché. **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. **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. ### 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 │ │ 3× EIF+AE │ │ +XGB │ │ 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 à 5 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.20 | Cohérence protocolaire | ALPN cohérent, Window Scaling présent, `tls12_ratio` faible | **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 7 familles (65+ features) : ### 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` ### Famille 4 : Cohérence cross-layer `alpn_http_mismatch`, `is_alpn_missing`, `sni_host_mismatch`, `mss_mobile_mismatch`, `tls12_ratio`, `http10_ratio`, `tcp_jitter_variance`, `syn_timing_cv` ### Famille 5 : Empreinte réseau `ip_id_zero_ratio`, `request_size_variance`, `anomalous_payload_ratio`, `avg_ttl`, `ttl_std`, `no_window_scale_ratio`, `ip_df_variance`, `tcp_shared_count`, `port_exhaustion_ratio`, `src_port_density`, `has_xff` ### 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` ### 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`, `benford_deviation`, `root_to_first_asset_delay`, `asset_load_stddev`, `ja4_drift_ratio`, `host_diversity`, `host_sweep_speed`, `host_coverage_uniformity` --- ## 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** : Non implémenté. Identifié comme travail futur nécessitant un module de graphe dédié (ex: NetworkX ou DGL). ### 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. Utilisées dans le vecteur de features du bot-detector. Note : `cross_domain_path_similarity` (distance de Jaccard) non implémenté. --- ## 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 65+ features sur 7 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) | 5 sur 8 | | Features totales | 65+ sur 7 familles | | Architecture ML | Triple-voix (EIF + AE + XGBoost) opérationnel | 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 5 des 8 techniques originales proposées (§5.1 Path Sequence Entropy, §5.3 Request Cadence Fingerprint, §5.4 Resource Dependency Tree, §5.5 Intra-Session JA4 Drift, §5.8 Cross-Domain Session Linking) 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 65+ features sur 7 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) via une pondération linéaire fixe configurable surpasse chaque composant en isolation, comme le démontrent les travaux sur les ensembles hybrides (Jamshidi et al., 2025 ; Basbous et al., 2026). 6. **5 des 8 techniques originales sont implémentées et opérationnelles** : la séquence temporelle des chemins (§5.1), 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 (§5.8) sont déployés en production. Les graphes de co-occurrence réseau (§5.2), la corrélation DNS passive (§5.6), et les invariants de compression (§5.7) restent identifiés comme travaux futurs. 7. **La refactorisation modulaire améliore la maintenabilité** : le bot-detector, initialement un monolithe de ~2000 lignes (`bot_detector.py`), a été restructuré en 11 modules spécialisés (scoring, features, models, clustering, drift, explainability, 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 3 techniques restantes (graphe bipartite JA4×ASN, corrélation DNS, invariant de compression) et l'extension du scoring multifactoriel navigateur constituent les priorités à court terme. L'intégration de fingerprints HTTP/2 (SETTINGS frame, PRIORITY tree) constitue un vecteur de détection sous-exploité face aux outils d'évasion comme httpcloak qui imitent parfaitement les couches TLS et HTTP/1.1 mais pas encore les subtilités HTTP/2. --- ## 8. Références ### Publications académiques 1. Liu, F.T., Ting, K.M., & Zhou, Z.H. (2008). "Isolation Forest." *IEEE International Conference on Data Mining (ICDM)*. 2. Hariri, S., Kind, M.C., & Brunner, R.J. (2021). "Extended Isolation Forest." *IEEE Transactions on Knowledge and Data Engineering (TKDE), 33(4), 1479-1489*. arXiv:1811.02141. 3. Osama, H., et al. (2025). "Enhanced Web Payload Classification Using WAMM: An AI-Based Framework for Dataset Refinement and Model Evaluation." *arXiv:2512.23610*. 4. Sanna Passino, F., et al. (2025). "Clustering Terminal Session Commands for Cyber-Threat Analysis." *Annals of Applied Statistics, 19(1), 586-613*. arXiv:2301.02505. 5. Hiremath, P.S., et al. (2026). "PARD-SSM: Probabilistic Cyber-Attack Regime Detection via Variational Switching State-Space Models." *arXiv (April 2026)*. 6. Sosnowski, M., et al. (2023). "Active TLS Stack Fingerprinting: Characterizing TLS Server Deployments at Scale." arXiv:2206.13230. 7. Anderson, B., et al. (2018). "Limitless HTTP in an HTTPS World: Inferring the Semantics of the HTTPS Protocol without Decryption." arXiv:1805.11544. 8. Hosain, M., et al. (2025). "Web Technologies Security in the AI Era: A Survey of CDN-Enhanced Defenses." *arXiv (December 2025)*. 9. Kadel, J., et al. (2024). "BOTracle: A framework for Discriminating Bots and Humans." *arXiv (December 2024)*. 10. Schraven, J., et al. (2025). "MAWIFlow Benchmark: Realistic Flow-Based Evaluation for Network Intrusion Detection." *arXiv (June 2025)*. 11. Akbari, E., et al. (2025). "One task to rule them all: A closer look at traffic classification generalizability." *arXiv (July 2025)*. 12. Mirsky, Y., Doitshman, T., Elovici, Y., & Shabtai, A. (2018). "Kitsune: An Ensemble of Autoencoders for Online Network Intrusion Detection." *Network and Distributed Systems Security Symposium (NDSS)*. arXiv:1802.09089. 13. Baptiste, D., Saddem, R., Philippot, A., & Foyer, F. (2026). "Unsupervised Anomaly Detection in NSL-KDD Using β-VAE: A Latent Space and Reconstruction Error Approach." *arXiv (February 2026)*. 14. Jamshidi, S., et al. (2025). "Lightweight Autoencoder-Isolation Forest Anomaly Detection for Green IoT Edge Gateways." *arXiv (November 2025)*. 15. Basbous, F., et al. (2026). "Hybrid Autoencoder-Isolation Forest approach for time series anomaly detection." *arXiv (March 2026)*. 16. Frizzo, D., et al. (2024). "Towards Transparent and Efficient Anomaly Detection in Industrial Processes through ExIFFI." *arXiv (May 2024)* — Extended Isolation Forest with Feature Importance. 17. Arcudi, A., et al. (2023). "Enhancing Interpretability and Generalizability in Extended Isolation Forests." *arXiv (October 2023)*. ### Projets et outils open-source 18. Althouse, J. (2023). "JA4+ Network Fingerprinting." FoxIO. https://github.com/FoxIO-LLC/ja4 19. Althouse, J. (2024). "JA4T: TCP Fingerprinting." FoxIO Blog. https://blog.foxio.io/ja4t-tcp-fingerprinting 20. OWASP Foundation. "OWASP ModSecurity Core Rule Set (CRS) v4." https://github.com/coreruleset/coreruleset 21. TecharoHQ. "Anubis — Bot Detection Rules." https://github.com/TecharoHQ/anubis 22. FingerprintJS. "BotD — Browser Bot Detection." https://github.com/fingerprintjs/BotD 23. Zalewski, M. (2013). "p0f v3 — Passive OS Fingerprinting." https://lcamtuf.coredump.cx/p0f3/ 24. sardanioss. "httpcloak — Go HTTP Client with Browser-Identical TLS/HTTP2 Fingerprinting." https://github.com/sardanioss/httpcloak 25. Imperva. (2024). "2024 Bad Bot Report." https://www.imperva.com/resources/reports/2024-bad-bot-report/ 26. Hariri, S. "Extended Isolation Forest (eif)." https://github.com/sahandha/eif — Implémentation Python, v2.0.2. 27. CrowdSec. "CrowdSec Security Engine." https://github.com/crowdsecurity/crowdsec — IDS/WAF collaboratif open-source. 28. Coraza WAF. "Coraza — Enterprise-grade WAF in Go." https://github.com/corazawaf/coraza 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. Les techniques proposées au §5 sont originales et n'ont pas été publiées précédemment ; 5 des 8 sont implémentées et opérationnelles en production. Les sections §2.4.2b, §2.4.2c et les mises à jour de §3-§7 intègrent les résultats de la revue de littérature 2023-2026 et les retours de déploiement.*