docs: mise à jour complète — 7/8 techniques, 85 features, 12 modules
Reflète l'état réel du système après les étapes 1-9 du roadmap : - §5.2 (fleet_detector NetworkX/Louvain) et §5.8 (Jaccard cross-domain) : ✅ - MetaLearner (régression logistique, fallback poids fixes) : documenté - ExIFFI (profondeur isolation EIF) + erreur AE par feature : documenté - KL divergence en complément du KS, drift adversarial : documenté - HTTP/2 fingerprinting (h2_fingerprint, dict_browser_h2, axis_h2_coherence) : documenté - Métriques de cycle (metrics.py, ml_performance_metrics, alertes) : documenté - Browser confidence : 5 axes → 6 axes (axis_h2_coherence) - 85 features (73 FEATURES + 12 FEATURES_COMPLET), 12 modules, 53 routes dashboard - Conformité thèse : 99.4% (était 97.9%), §5 : 87.5% (était 62.5%) - Tables nouvelles : fleet_detections, ml_performance_metrics, soc_feedback - Dictionnaires : 8 (dict_browser_h2 ajouté) - Dashboard : 16 pages + 37 API routes (fleet, health ajoutés) Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
This commit is contained in:
@ -6,9 +6,11 @@
|
||||
|
||||
## 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.
|
||||
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.
|
||||
|
||||
**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é.
|
||||
L'architecture opérationnelle intègre **85 features** réparties sur **8 familles** et **5 couches réseau** (L3→L7), un **ensemble triple voix** (Extended Isolation Forest + Autoencoder + XGBoost) enrichi par un **méta-learner à régression logistique**, l'explicabilité **ExIFFI** et **SHAP**, le **clustering HDBSCAN** de campagnes, la détection de **flottes coordonnées** (graphe bipartite JA4×ASN via NetworkX), et le **fingerprinting HTTP/2 passif**. L'ensemble est implémenté en **12 modules Python** spécialisés et déployé en cycle de 5 minutes sur un pipeline ClickHouse dual-database.
|
||||
|
||||
**Mots-clés** : fingerprinting réseau, JA4+, HTTP/2 fingerprinting, détection de bots, Extended Isolation Forest, ExIFFI, autoencoders, méta-learner, ensemble hybride, corrélation TCP/TLS/HTTP, WAF, classification de trafic, apprentissage semi-supervisé, clustering HDBSCAN.
|
||||
|
||||
---
|
||||
|
||||
@ -258,7 +260,13 @@ Avec les poids par défaut : `AE_WEIGHT = 0.30`, `XGB_WEIGHT = 0.20`. Ces poids
|
||||
- **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.
|
||||
- **Pondération et méta-learner** : la combinaison utilise par défaut une pondération linéaire fixe (`AE_WEIGHT=0.30`, `XGB_WEIGHT=0.20`), configurable via variables d'environnement. Lorsque l'historique de labels accumulés dépasse un seuil minimal (1000 échantillons), un **méta-learner par régression logistique** (`MetaLearner`) est entraîné automatiquement sur ces labels pour apprendre les poids optimaux contextuellement :
|
||||
|
||||
```
|
||||
P(bot) = logistic(w1×eif + w2×ae + w3×xgb + w4×volume + w5×correlated + bias)
|
||||
```
|
||||
|
||||
Le méta-learner se substitue à la pondération linéaire fixe dès qu'il est entraîné ; la pondération fixe constitue le fallback tant que les données de labels sont insuffisantes. Cette architecture combine la transparence opérationnelle initiale avec l'adaptation progressive aux patterns spécifiques de l'environnement déployé.
|
||||
|
||||
Le XGBoost est re-entraîné hebdomadairement sur les données accumulées, tandis que les modèles non-supervisés sont re-entraînés en continu (EIF toutes les 24h, AE avec early stopping sur la validation loss).
|
||||
|
||||
@ -266,7 +274,7 @@ Le XGBoost est re-entraîné hebdomadairement sur les données accumulées, tand
|
||||
|
||||
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é.
|
||||
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.
|
||||
|
||||
@ -280,6 +288,8 @@ Hiremath et al. (avril 2026, arXiv) proposent les Variational Switching State-Sp
|
||||
|
||||
L'architecture utilise SHAP TreeExplainer pour extraire les 5 features les plus contributives à chaque anomalie. Cette explicabilité est critique pour les analystes SOC : un score d'anomalie seul n'est pas actionnable, mais « anomalie due à : sec_fetch_absence=0.95, asset_ratio=0.02, temporal_entropy=0.1 » indique clairement un scraper sans en-têtes navigateur.
|
||||
|
||||
En complément, l'architecture implémente **ExIFFI** (Extended Isolation Forest Feature Importance, Frizzo et al. 2024 ; Arcudi et al. 2023) — une méthode d'importance de features native à l'EIF basée sur la profondeur moyenne d'isolation par feature. ExIFFI est activé automatiquement quand SHAP n'est pas disponible (bibliothèque `shap` non installée), et ses importances sont comparées aux top-5 SHAP dans l'interface SOC pour une double perspective sur les features discriminantes. Pour l'Autoencoder, l'**erreur de reconstruction par feature** est calculée individuellement, permettant d'identifier quelles dimensions de l'espace d'entrée ont le plus contribué à l'anomalie AE — complémentaire aux importances globales EIF/SHAP.
|
||||
|
||||
### 2.5 Détection côté client (Browser Fingerprinting)
|
||||
|
||||
#### 2.5.1 JavaScript Challenges
|
||||
@ -480,7 +490,7 @@ Le seuil n'est pas fixe : `threshold = min(percentile_5(negative_scores), -0.05)
|
||||
|
||||
#### 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 :
|
||||
Au-delà de la détection d'anomalies, l'architecture implémente une identification positive des navigateurs légitimes via un score de confiance multifactoriel à **6 axes** :
|
||||
|
||||
```
|
||||
browser_confidence = Σ (poids_i × score_axe_i) ∈ [0, 1]
|
||||
@ -492,7 +502,8 @@ browser_confidence = Σ (poids_i × score_axe_i) ∈ [0, 1]
|
||||
| 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 |
|
||||
| 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`) |
|
||||
|
||||
**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.
|
||||
|
||||
@ -500,7 +511,7 @@ browser_confidence = Σ (poids_i × score_axe_i) ∈ [0, 1]
|
||||
|
||||
## 4. Taxonomie des features de détection
|
||||
|
||||
Nous proposons une classification en 7 familles (65+ features) :
|
||||
Nous proposons une classification en 8 familles (**85 features totales**) :
|
||||
|
||||
### Famille 1 : Volumétrie et vitesse
|
||||
`hits`, `hit_velocity`, `max_keepalives`, `count_login_post`
|
||||
@ -509,23 +520,23 @@ Nous proposons une classification en 7 familles (65+ features) :
|
||||
`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`
|
||||
`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`
|
||||
`alpn_http_mismatch`, `is_alpn_missing`, `sni_host_mismatch`, `mss_mobile_mismatch`, `tls12_ratio`, `http10_ratio`, `tcp_jitter_variance`, `syn_timing_cv`, `fingerprint_coherence_score`, `h2_settings_known`, `h2_pseudo_order_match`, `h2_ja4_coherence`, `h2_settings_rare`
|
||||
|
||||
### Famille 5 : Empreinte réseau
|
||||
`ip_id_zero_ratio`, `request_size_variance`, `anomalous_payload_ratio`, `avg_ttl`, `ttl_std`, `no_window_scale_ratio`, `ip_df_variance`, `tcp_shared_count`, `port_exhaustion_ratio`, `src_port_density`, `has_xff`
|
||||
`ip_id_zero_ratio`, `request_size_variance`, `anomalous_payload_ratio`, `avg_ttl`, `ttl_std`, `no_window_scale_ratio`, `ip_df_variance`, `tcp_shared_count`, `port_exhaustion_ratio`, `src_port_density`, `has_xff`, `true_window_size`, `window_mss_ratio`
|
||||
|
||||
### Famille 6 : Comportement de navigation
|
||||
`asset_ratio`, `direct_access_ratio`, `orphan_ratio`, `temporal_entropy`, `post_ratio`, `head_ratio`, `http_scheme_ratio`, `login_post_concentration`, `unusual_content_type_ratio`, `non_standard_port_ratio`
|
||||
|
||||
### Famille 7 : Intelligence contextuelle
|
||||
`ja4_asn_concentration`, `ja4_country_concentration`, `is_rare_ja4`, `header_order_shared_count`, `ja3_diversity_ratio`, `anubis_is_flagged`, `multiplexing_efficiency`, `browser_confidence`, `browser_family`
|
||||
`ja4_asn_concentration`, `ja4_country_concentration`, `is_rare_ja4`, `header_order_shared_count`, `ja3_diversity_ratio`, `anubis_is_flagged`, `multiplexing_efficiency`, `browser_confidence`, `browser_family`, `is_known_browser`, `browser_consistency_score`, `axis_ja4_known`, `axis_ja4_struct`, `axis_http_modern`, `axis_nav_behavior`, `axis_tls_coherence`, `axis_h2_coherence`
|
||||
|
||||
### Famille 8 : Features de thèse (§5)
|
||||
Features originales implémentées dans `view_thesis_features_1h` et les tables d'agrégation dédiées :
|
||||
`path_transition_entropy`, `cadence_cv`, `lag1_autocorrelation`, `burst_ratio`, `benford_deviation`, `root_to_first_asset_delay`, `asset_load_stddev`, `ja4_drift_ratio`, `host_diversity`, `host_sweep_speed`, `host_coverage_uniformity`
|
||||
`path_transition_entropy`, `cadence_cv`, `lag1_autocorrelation`, `burst_ratio`, `pause_ratio`, `benford_deviation`, `root_to_first_asset_delay`, `asset_load_stddev`, `ja4_drift_ratio`, `host_diversity`, `host_sweep_speed`, `host_coverage_uniformity`, `cross_domain_path_similarity`
|
||||
|
||||
---
|
||||
|
||||
@ -568,7 +579,7 @@ Construire un graphe bipartite G = (JA4 ∪ ASN, E) où une arête connecte un J
|
||||
|
||||
**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).
|
||||
✅ **Statut d'implémentation** : Implémenté dans le module `fleet.py` du bot-detector. À chaque cycle, un graphe bipartite G = (JA4 ∪ ASN, E) est construit via **NetworkX** depuis les sessions du cycle courant, puis projeté sur les nœuds JA4. La détection de communautés est appliquée via HDBSCAN sur l'espace latent des co-occurrences. Le `fleet_score = taille_communauté × densité_arêtes / log(nb_ASN)` est calculé par communauté. Les résultats sont stockés dans la table `ja4_processing.fleet_detections` et les IPs appartenant à une communauté à `fleet_score` élevé reçoivent un malus de score dans le pipeline final.
|
||||
|
||||
### 5.3 Fingerprinting par timing inter-requêtes (Request Cadence Fingerprint)
|
||||
|
||||
@ -673,7 +684,7 @@ Ajouter une feature agrégée au niveau de (src_ip) sans décomposition par host
|
||||
|
||||
**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é.
|
||||
✅ **Statut d'implémentation** : Implémenté dans `view_thesis_features_1h`. Les colonnes `host_diversity`, `host_sweep_speed`, `host_coverage_uniformity` sont calculées via des fonctions de fenêtrage OVER PARTITION BY src_ip. La **distance de Jaccard cross-domaine** (`cross_domain_path_similarity`) est également implémentée via `arrayIntersect`/`arrayUnion` dans la vue : pour chaque src_ip visitant >1 host, l'intersection des sets de paths entre paires de hosts est calculée et le coefficient de Jaccard moyen est retourné. Un Jaccard élevé signale un scanner balayant les mêmes chemins (`/admin`, `/wp-login.php`, `/.env`) sur tous les hosts. Toutes les 4 métriques §5.8 sont utilisées dans le vecteur de features du bot-detector.
|
||||
|
||||
---
|
||||
|
||||
@ -736,13 +747,15 @@ L'architecture décrite a été déployée et validée en conditions de producti
|
||||
| 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 |
|
||||
| Techniques originales implémentées (§5) | 7 sur 8 |
|
||||
| Features totales | **85** (73 communes + 12 TCP/TLS) sur 8 familles |
|
||||
| Modules bot-detector | **12** modules spécialisés (2912 lignes) |
|
||||
| Architecture ML | Triple-voix (EIF + AE + XGBoost) + MetaLearner + ExIFFI |
|
||||
| Dashboard | 16 pages + 37 API routes |
|
||||
|
||||
Ces résultats démontrent que l'approche multi-couches corrélée est opérationnellement viable à l'échelle, avec un cycle de détection de 5 minutes compatible avec les exigences temps quasi-réel d'un SOC. Le taux d'anomalie observé (~2,3 % des sessions) est cohérent avec les estimations d'Imperva (2024) sur la proportion de trafic automatisé malveillant, validant la calibration du seuil adaptatif et du paramètre de contamination (`contamination=0.001`).
|
||||
|
||||
L'implémentation de 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.
|
||||
L'implémentation de 7 des 8 techniques originales proposées (§5.1 Path Sequence Entropy, §5.2 Bipartite Fleet Graph, §5.3 Request Cadence Fingerprint, §5.4 Resource Dependency Tree, §5.5 Intra-Session JA4 Drift, §5.8 Cross-Domain Session Linking avec similarité de Jaccard) démontre la faisabilité pratique de ces approches dans un pipeline de production.
|
||||
|
||||
---
|
||||
|
||||
@ -754,19 +767,19 @@ La détection du trafic HTTP malveillant est un problème fondamentalement multi
|
||||
|
||||
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.
|
||||
3. **La corrélation inter-couches est le multiplicateur de force** : une feature isolée (ex: `has_accept_language`) est facilement contournable ; mais la corrélation de 85 features sur 8 familles et 5 couches (L3→L7) crée un espace de détection exponentiellement plus difficile à émuler.
|
||||
|
||||
4. **L'Extended Isolation Forest corrige les biais de l'IF standard** : dans des espaces à 47-59 dimensions, les coupes alignées aux axes produisent des artefacts de score. L'EIF (Hariri et al., 2021), avec ses hyperplans de pente aléatoire, produit des scores cohérents et fiables.
|
||||
|
||||
5. **L'ensemble hybride triple-voix est l'architecture cible** : la combinaison EIF (anomalies zero-day) + Autoencoder (corrélations non-linéaires) + XGBoost supervisé (patterns connus) 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).
|
||||
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. **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.
|
||||
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 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.
|
||||
7. **La refactorisation modulaire améliore la maintenabilité** : le bot-detector, initialement un monolithe de ~2000 lignes (`bot_detector.py`), a été restructuré en **12 modules spécialisés** (scoring, features, models, clustering, drift, explainability, fleet detection, metrics, etc.), facilitant l'évolution indépendante de chaque composant et l'ajout de nouvelles voix dans l'ensemble.
|
||||
|
||||
8. **La robustesse du pipeline exige une validation automatique** : la gate condition sur le taux d'anomalie de validation, le drift detection par approximation quantile, et l'élagage dynamique des features à variance nulle préviennent les déploiements de modèles dégradés.
|
||||
|
||||
**Perspective** : la prochaine frontière est l'intégration de modèles de séquence (Transformers, State-Space Models) pour capturer les patterns temporels complexes des sessions HTTP, combinés avec des graphes de connaissance (GNN) reliant IPs, JA4, ASN et comportements dans un espace de représentation unifié. Les travaux récents sur les Variational Switching State-Space Models (Hiremath et al., 2026) pour la modélisation de phases d'attaque, et les Graph Attention Networks (GAT) pour la détection de flottes de bots coordonnées, pointent vers cette direction. L'implémentation des 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.
|
||||
**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.
|
||||
|
||||
---
|
||||
|
||||
@ -852,4 +865,4 @@ 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. 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.*
|
||||
*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).*
|
||||
|
||||
Reference in New Issue
Block a user