code_public/ja4-platform
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

feat: port v14 schema fixes, migration, MV verifier, thesis from ja4/

Browse Source 
deploy_views.sql (v13 → v14):
- CRITICAL: ml_detected_anomalies ORDER BY (src_ip) → (src_ip, ja4, host, model_name)
  ReplacingMergeTree was collapsing all detections to 1 row per IP on merge
- Add PARTITION BY toDate + ttl_only_drop_parts on all 4 data tables
- ml_all_scores TTL 3d → 7d; ml_detected_anomalies TTL 30d → 7d
- agg_host_ip_ja4_1h + agg_header_fingerprint_1h: add partition + TTL 7d
- view_ip_recurrence: add WHERE detected_at >= now() - 7 DAY (was full scan)
- Remove dead views: summary/timeseries/threat_dist/variability
- Add view_dashboard_entities (fixes HTTP 500 in clustering/incidents/fingerprints)
- Add view_dashboard_user_agents (fixes HTTP 500 in fingerprints/metrics)
- Add view_ai_features_24h (enables ENABLE_MULTIWINDOW in bot_detector)
- Mark max_requests_per_sec as DEPRECATED (always 0)

New files:
- correlator/sql/migrations/01_ttl_adjustments.sql: ALTER TABLE migration
- tests/integration/verify_mvs.py: MV pipeline verification assertions
- docs/THESIS_HTTP_Traffic_Detection.md: detection techniques thesis

All DB references use ja4_processing/ja4_logs (no mabase_prod).

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
This commit is contained in:
toto
2026-04-07 23:51:56 +02:00
parent ecceb04174
commit 51b8eb57a8
4 changed files with 1151 additions and 67 deletions
Download Patch File Download Diff File Expand all files Collapse all files

681
docs/THESIS_HTTP_Traffic_Detection.md Normal file
View File

@ -0,0 +1,681 @@
# 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, 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 45+ features sur 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) catégorisant les bots par UA, IP, ASN et pays avec des actions graduées (ALLOW, DENY, WEIGH, CHALLENGE). Son intégration dans un pipeline ML permet d'utiliser 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. L'architecture étudiée utilise IF avec `n_estimators=300`, `contamination=0.001`, entraîné sur la baseline humaine (`asn_label='human'`, minimum 500 échantillons).
**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.
**Architecture de scoring bifurquée** :
L'architecture étudiée exécute deux modèles IF 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.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 par test de Kolmogorov-Smirnov par feature entre la distribution d'entraînement et la distribution courante. Si >30 % des features dérivent significativement, un retraining forcé est déclenché. Le modèle est sérialisé avec ses statistiques de baseline pour comparaison future.
#### 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 DBSCAN.
#### 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 │
│ Agrégation │
│ horaire │
│ Features │
└──────┬───────┘
│
┌──────▼───────┐
│ bot_detector │
│ 2× IF model │
│ DBSCAN camp. │
│ SHAP explain │
└──────┬───────┘
│
┌──────▼───────┐
│ Dashboard │
│ 21 modules │
│ 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 par IF (test set)
│
┌────┴────────────────────────┐
│ score < seuil adaptatif ? │──OUI──▶ ANOMALIE
│ │ + SHAP top-5
│ │ + DBSCAN 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 |
---
## 4. Taxonomie des features de détection
Nous proposons une classification en 7 familles :
### Famille 1 : Volumétrie et vitesse
`hits`, `hit_velocity`, `max_keepalives`
### Famille 2 : Diversité et exploration
`fuzzing_index`, `path_diversity_ratio`, `url_depth_variance`, `distinct_ja4_count`, `distinct_header_orders`, `is_ua_rotating`
### 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`
### 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`
### Famille 6 : Comportement de navigation
`asset_ratio`, `direct_access_ratio`, `orphan_ratio`, `temporal_entropy`, `post_ratio`, `head_ratio`, `http_scheme_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`
---
## 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*).
### 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.
### 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`.
### 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).
### 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.
### 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.
### 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.
### 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.
---
## 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 45 features sur 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** : 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. Les techniques proposées (§5.2 graphe de co-occurrence, §5.3 cadence fingerprint) offrent des signaux orthogonaux résistants à cette contamination.
### 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 |
---
## 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 45 features sur 5 couches (L3→L7) crée un espace de détection exponentiellement plus difficile à émuler.
4. **L'apprentissage semi-supervisé (Isolation Forest) est adapté au problème** : en apprenant « ce qui est humain » plutôt que « ce qui est malveillant », le système détecte les attaques zero-day sans labels.
5. **Les techniques proposées exploitent des signaux sous-utilisés** : la séquence temporelle des chemins, les graphes de co-occurrence réseau, la cadence inter-requêtes, l'arbre de dépendances de ressources, la dérive de fingerprint intra-session, la corrélation DNS passive, les invariants de compression, et le comportement cross-domaine ouvrent de nouvelles dimensions de détection, chacune orthogonale aux signaux existants.
**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 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 pointent vers cette direction.
---
## 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. Osama, H., et al. (2025). "Enhanced Web Payload Classification Using WAMM: An AI-Based Framework for Dataset Refinement and Model Evaluation." *arXiv:2512.23610*.
3. 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.
4. Hiremath, P.S., et al. (2026). "PARD-SSM: Probabilistic Cyber-Attack Regime Detection via Variational Switching State-Space Models." *arXiv (April 2026)*.
5. Sosnowski, M., et al. (2023). "Active TLS Stack Fingerprinting: Characterizing TLS Server Deployments at Scale." arXiv:2206.13230.
6. Anderson, B., et al. (2018). "Limitless HTTP in an HTTPS World: Inferring the Semantics of the HTTPS Protocol without Decryption." arXiv:1805.11544.
7. Hosain, M., et al. (2025). "Web Technologies Security in the AI Era: A Survey of CDN-Enhanced Defenses." *arXiv (December 2025)*.
8. Kadel, J., et al. (2024). "BOTracle: A framework for Discriminating Bots and Humans." *arXiv (December 2024)*.
9. Schraven, J., et al. (2025). "MAWIFlow Benchmark: Realistic Flow-Based Evaluation for Network Intrusion Detection." *arXiv (June 2025)*.
10. Akbari, E., et al. (2025). "One task to rule them all: A closer look at traffic classification generalizability." *arXiv (July 2025)*.
### Projets et outils open-source
11. Althouse, J. (2023). "JA4+ Network Fingerprinting." FoxIO. https://github.com/FoxIO-LLC/ja4
12. Althouse, J. (2024). "JA4T: TCP Fingerprinting." FoxIO Blog. https://blog.foxio.io/ja4t-tcp-fingerprinting
13. OWASP Foundation. "OWASP ModSecurity Core Rule Set (CRS) v4." https://github.com/coreruleset/coreruleset
14. TecharoHQ. "Anubis — Bot Detection Rules." https://github.com/TecharoHQ/anubis
15. FingerprintJS. "BotD — Browser Bot Detection." https://github.com/fingerprintjs/BotD
16. Zalewski, M. (2013). "p0f v3 — Passive OS Fingerprinting." https://lcamtuf.coredump.cx/p0f3/
17. sardanioss. "httpcloak — Go HTTP Client with Browser-Identical TLS/HTTP2 Fingerprinting." https://github.com/sardanioss/httpcloak
18. Imperva. (2024). "2024 Bad Bot Report." https://www.imperva.com/resources/reports/2024-bad-bot-report/
### Standards et RFC
19. RFC 8701 — "Applying Generate Random Extensions And Sustain Extensibility (GREASE) to TLS Extensibility." (2020).
20. RFC 9293 — "Transmission Control Protocol (TCP)." (2022).
21. RFC 8446 — "The Transport Layer Security (TLS) Protocol Version 1.3." (2018).
---
*Document généré le 7 avril 2026. Les techniques proposées au §5 sont originales et n'ont pas été publiées précédemment.*