Implement offline profile building (profile_builder.py) and real-time
dynamic scoring (browser_matcher_dynamic.py) using HDBSCAN-based browser
fingerprint clustering. Add ClickHouse materialized view (13_h2_profiling.sql)
for h2_profile_stats aggregation. Update thesis and project documentation
to cover the new dynamic profiling architecture.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Ce document présente une architecture complète de détection et classification du trafic HTTP malveillant, positionnée à la frontière des générations 3 et 4 de défenses applicatives. Le système exploite 96 features organisées en 8 familles couvrant les couches réseau L3 à L7, corrélant des signaux TCP, TLS et HTTP en un vecteur unifié par session. La détection repose sur un ensemble triple-voix combinant un Extended Isolation Forest (EIF), un autoencodeur (AE) et XGBoost, fusionnés par un MetaLearner à régression logistique activé à partir de 1 000 étiquettes accumulées. L'explicabilité est assurée par ExIFFI (nativement pour EIF) et SHAP TreeExplainer (pour XGBoost). Le clustering de campagnes est réalisé par HDBSCAN dans l'espace latent 16 dimensions de l'autoencodeur, et la détection de flottes coordonnées par graphes bipartis via NetworkX. Le fingerprinting HTTP/2 passif — extraction des trames SETTINGS, WINDOW_UPDATE et de l'ordre des pseudo-headers côté serveur — constitue un signal inédit difficile à contourner sans implémenter une pile HTTP/2 complète fidèle à un navigateur cible. L'infrastructure repose sur 14 modules Python (3 700 lignes), une base ClickHouse à double schéma (ja4_logs bruts TTL 2 h, ja4_processing agrégés TTL 7 j), des cycles d'analyse de 300 secondes, et traite en production plus de 3 millions de logs, environ 34 000 sessions par cycle, avec approximativement 777 anomalies détectées par cycle (≈ 2,3 %). Les mots-clés couvrent : fingerprinting réseau, JA4+, HTTP/2 fingerprinting passif, détection de bots, Extended Isolation Forest, ExIFFI, autoencodeurs, méta-learner, ensemble hybride, corrélation TCP/TLS/HTTP, WAF, classification de trafic, apprentissage semi-supervisé, clustering HDBSCAN.
Ce document présente une architecture complète de détection et classification du trafic HTTP malveillant, positionnée à la frontière des générations 3 et 4 de défenses applicatives. Le système exploite 96 features organisées en 8 familles couvrant les couches réseau L3 à L7, corrélant des signaux TCP, TLS et HTTP en un vecteur unifié par session. La détection repose sur un ensemble triple-voix combinant un Extended Isolation Forest (EIF), un autoencodeur (AE) et XGBoost, fusionnés par un MetaLearner à régression logistique activé à partir de 1 000 étiquettes accumulées. L'explicabilité est assurée par ExIFFI (nativement pour EIF) et SHAP TreeExplainer (pour XGBoost). Le clustering de campagnes est réalisé par HDBSCAN dans l'espace latent 16 dimensions de l'autoencodeur, et la détection de flottes coordonnées par graphes bipartis via NetworkX. Le fingerprinting HTTP/2 passif — extraction des trames SETTINGS, WINDOW_UPDATE et de l'ordre des pseudo-headers côté serveur — constitue un signal inédit difficile à contourner sans implémenter une pile HTTP/2 complète fidèle à un navigateur cible. L'infrastructure repose sur 16 modules Python (4 800 lignes), une base ClickHouse à double schéma (ja4_logs bruts TTL 2 h, ja4_processing agrégés TTL 7 j), des cycles d'analyse de 300 secondes, et traite en production plus de 3 millions de logs, environ 34 000 sessions par cycle, avec approximativement 777 anomalies détectées par cycle (≈ 2,3 %). Le système intègre un moteur de profiling dynamique automatique des navigateurs (HDBSCAN sur les vecteurs H2 observés, centroïdes auto-appris, scoring temps réel par distance normalisée) qui s'adapte aux évolutions des piles HTTP/2 sans intervention manuelle. Les mots-clés couvrent : fingerprinting réseau, JA4+, HTTP/2 fingerprinting passif, détection de bots, Extended Isolation Forest, ExIFFI, autoencodeurs, méta-learner, ensemble hybride, corrélation TCP/TLS/HTTP, WAF, classification de trafic, apprentissage semi-supervisé, clustering HDBSCAN.
Le système de signatures statiques (§3.9.2) est robuste mais fragile face aux mises à jour de navigateurs : chaque changement de version peut modifier les valeurs SETTINGS ou WINDOW_UPDATE, nécessitant une mise à jour manuelle du dictionnaire. Le **profiling dynamique automatique** résout ce problème en apprenant les signatures directement à partir du trafic observé, sans intervention humaine.
#### Architecture du pipeline
Le pipeline s'articule en deux phases :
1.**Phase hors-ligne** (`profile_builder.py`, exécuté quotidiennement par cron) :
- Lit la vue `view_h2_profiling_raw` (sessions H2 filtrées des 7 derniers jours, dédupliquées par IP)
- Clusterise les sessions similaires via HDBSCAN (`min_cluster_size=1000`) sur un vecteur mixte (variables continues normalisées par StandardScaler + variables catégorielles brutes)
- Calcule les centroïdes par cluster : moyenne et tolérance (`mean + 3σ`) pour les continues, mode pour les catégorielles
- Labelise les clusters par analyse des User-Agents → familles `Auto_Chrome`, `Auto_Firefox`, `Auto_Safari`, `Auto_Unknown`
- Fusionne les clusters redondants (même famille + même `pseudo_order` + `window_update` à <5%d'écart)
@ -2989,7 +3086,8 @@ Un seul utilisateur réel alterne quelques connexions (2–6 ports source actifs
**browser_matcher maintenance (§3.9)** :
- État actuel : `[impl.]` — logique de score complète à 7 dimensions, base de signatures Chrome/Firefox/Safari complète
- Données H2 brutes : `[impl.]` — capture des 7 paramètres SETTINGS individuels, WINDOW_UPDATE, flag PRIORITY et ordre pseudo-headers par ja4ebpf via le parser HTTP/2 du flux SSL_read déchiffré. Colonnes individuelles dans `ja4_logs.http_logs` (`h2_header_table_size`, `h2_enable_push`, `h2_max_concurrent_streams`, `h2_initial_window_size`, `h2_max_frame_size`, `h2_max_header_list_size`, `h2_enable_connect_protocol`, `h2_window_update`, `h2_has_priority`, `h2_pseudo_order`)
-Travail restant : maintenance des signatures lors des nouvelles versions de navigateurs, enrichissement de la base via la file d'examen `unknown_h2_fingerprints`
-Profiling dynamique : `[impl.]` — moteur HDBSCAN hors-ligne (`profile_builder.py`, 614 lignes) + scorer temps réel (`browser_matcher_dynamic.py`, 387 lignes). Les profils auto-appris dans `auto_browser_profiles` s'adaptent automatiquement aux nouvelles versions de navigateurs, éliminant la maintenance manuelle du dictionnaire statique.
- Travail restant : monitoring de la convergence des clusters dynamiques, validation croisée entre scores statique et dynamique
**DNS Shadow Analysis (§5.6)** :
- État actuel : `[todo]` non implémenté
@ -3061,6 +3159,8 @@ La capture passive est réalisée par ja4ebpf via un uprobe sur `SSL_read` (Open
Cette technique permet de détecter des outils d'évasion qui reproduisent correctement la couche TLS (curl_cffi, httpcloak) mais échouent à reproduire les subtilités H2 — notamment l'ordre des pseudo-headers et la valeur WINDOW_UPDATE. Le module de scoring est entièrement implémenté (`browser_matcher.py`, 497 lignes) avec les signatures des trois familles majeures (Chrome, Firefox, Safari) et trois signatures non-navigateur (curl, python-httpx, Go net/http) dans `browser_signatures.py` (165 lignes).
Le **profiling dynamique automatique** (`profile_builder.py`, 614 lignes + `browser_matcher_dynamic.py`, 387 lignes) étend cette approche en apprenant les signatures H2 directement à partir du trafic observé via HDBSCAN, sans nécessiter de mise à jour manuelle du dictionnaire. Les centroïdes auto-appris (moyenne + tolérance 3σ pour les continues, mode pour les catégorielles) sont stockés dans `auto_browser_profiles` et scorés en temps réel par distance normalisée pondérée avec confiance volumétrique. Ce mécanisme élimine la fragilité du système statique face aux mises à jour de navigateurs et couvre les implémentations H2 non répertoriées via les familles `Auto_Unknown`.
La stabilité des empreintes H2 de Chrome sur 2+ ans (novembre 2023 – 2026) contraste favorablement avec JA4 TLS (instable à chaque mise à jour de ciphersuites), justifiant l'investissement dans cette dimension additionnelle.
#### Contribution 4 : Huit techniques originales de détection
@ -3100,7 +3200,7 @@ Architecture de données fondée sur ClickHouse avec **AggregatingMergeTree view
### Perspective
Le système atteint ses objectifs opérationnels actuels. La capture HTTP/2 passive est intégrée avec 12 colonnes individuelles dans `ja4_logs.http_logs`, et le module `browser_matcher` est opérationnel avec ses 7 dimensions de scoring. Les axes d'amélioration prioritaires sont l'enrichissement continu des signatures navigateur via la file d'examen `unknown_h2_fingerprints`, l'extension DNS Shadow Analysis pour la couverture DNS (`[todo]` → `[partiel]`), et le passage à l'apprentissage en ligne pour XGBoost. À plus long terme, le support HTTP/3 (QUIC) deviendra nécessaire à mesure que la proportion de trafic HTTP/3 augmente dans la baseline.
Le système atteint ses objectifs opérationnels actuels. La capture HTTP/2 passive est intégrée avec 12 colonnes individuelles dans `ja4_logs.http_logs`, et le module `browser_matcher` est opérationnel avec ses 7 dimensions de scoring statique. Le moteur de profiling dynamique automatique (§3.9.6) complète le système statique en apprenant les signatures H2 à partir du trafic réel, éliminant la dépendance aux signatures codées en dur. Les axes d'amélioration prioritaires sont le monitoring de la convergence des clusters dynamiques, l'extension DNS Shadow Analysis pour la couverture DNS (`[todo]` → `[partiel]`), et le passage à l'apprentissage en ligne pour XGBoost. À plus long terme, le support HTTP/3 (QUIC) deviendra nécessaire à mesure que la proportion de trafic HTTP/3 augmente dans la baseline.
La technique la plus prometteuse parmi les travaux futurs est le **PARD-SSM** (Hiremath et al., 2026 [Référence à vérifier / Identifier le vrai papier]), qui permettrait de modéliser explicitement les phases d'attaque séquentielles — comblant la lacune actuelle entre la détection de sessions individuelles et la détection de campagnes d'attaque coordonnées multi-phases.
15. Insertion → fleet_detections (flottes détectées avec fleet_score)
16. Enregistrement → ml_performance_metrics (métriques de cycle + alertes)
```
---
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Jacquin Antoine