view

views.md

@@ -0,0 +1,84 @@
+# 🛡️ Manuel de Référence Technique : Moteur de Détection Antispam & Bot
+
+Ce document détaille les algorithmes de détection implémentés dans les vues ClickHouse pour la plateforme.
+
+---
+
+## 1. Analyse de la Couche Transport (L4) : La "Trace Physique"
+Avant même d'analyser l'URL, le moteur inspecte la manière dont la connexion a été établie. C'est la couche la plus difficile à falsifier pour un attaquant.
+
+### A. Fingerprint de la Pile TCP (`tcp_fingerprint`)
+* **Fonctionnement :** Nous utilisons `cityHash64` pour créer un identifiant unique basé sur trois paramètres immuables du handshake : le **MSS** (Maximum Segment Size), la **Window Size** et le **Window Scale**.
+* **Ce que ça détecte :** L'unicité logicielle. Un bot tournant sur une image Alpine Linux aura une signature TCP différente d'un utilisateur sur iOS 17 ou Windows 11.
+* **Détection de botnet :** Si 500 IPs différentes partagent exactement le même `tcp_fingerprint` ET le même `ja4`, il y a une probabilité de 99% qu'il s'agisse d'un cluster de bots clonés.
+
+
+
+### B. Analyse de la gigue (Jitter) et Handshake
+* **Fonctionnement :** On calcule la variance (`varPop`) du délai entre le `SYN` et le `ClientHello` TLS.
+* **Ce que ça détecte :** La stabilité robotique.
+    * **Humain :** Latence variable (4G, Wi-Fi, mouvements). La variance est élevée.
+    * **Bot Datacenter :** Latence ultra-stable (fibre optique dédiée). Une variance proche de 0 indique une connexion automatisée depuis une infrastructure cloud.
+
+---
+
+## 2. Analyse de la Session (L5) : Le "Passeport TLS"
+Le handshake TLS est une mine d'or pour identifier la bibliothèque logicielle (OpenSSL, Go-TLS, etc.).
+
+### A. Incohérence UA vs JA4
+* **Fonctionnement :** Le moteur croise le `header_user_agent` (déclaratif) avec le `ja4` (structurel).
+* **Ce que ça détecte :** Le **Spoofing de Browser**. Un script Python peut facilement écrire `User-Agent: Mozilla/5.0...Chrome/120`, mais il ne peut pas simuler l'ordre exact des extensions TLS et des algorithmes de chiffrement d'un vrai Chrome sans une ingénierie complexe (comme `utls`).
+* **Logique de score :** Si UA = Chrome mais JA4 != Signature_Chrome -> **+50 points de risque**.
+
+### B. Discordance Host vs SNI
+* **Fonctionnement :** Comparaison entre le champ `tls_sni` (négocié en clair lors du handshake) et le header `Host` (envoyé plus tard dans la requête chiffrée).
+* **Ce que ça détecte :** Le **Domain Fronting** ou les attaques par tunnel. Un bot peut demander un certificat pour `domaine-innocent.com` (SNI) mais tenter d'attaquer `api-critique.com` (Host).
+
+
+
+---
+
+## 3. Analyse Applicative (L7) : Le "Comportement HTTP"
+Une fois le tunnel établi, on analyse la structure de la requête HTTP.
+
+### A. Empreinte d'ordre des Headers (`http_fp`)
+* **Fonctionnement :** Nous hashons la liste ordonnée des clés de headers (`Accept`, `User-Agent`, `Connection`, etc.).
+* **Ce que ça détecte :** La signature du moteur de rendu. Chaque navigateur (Firefox, Safari, Chromium) a un ordre immuable pour envoyer ses headers.
+* **Détection :** Si un client envoie les headers dans un ordre inhabituel ou minimaliste (pauvreté des headers < 6), il est marqué comme suspect.
+
+### B. Analyse des Payloads et Entropie
+* **Fonctionnement :** Recherche de patterns via regex dans `query` et `path` (détection SQLi, XSS, Path Traversal).
+* **Complexité :** Nous détectons les encodages multiples (ex: `%2520`) qui tentent de tromper les pare-feux simples.
+
+---
+
+## 4. Corrélation Temporelle & Baseline : Le "Voisinage Statistique"
+Le score final dépend du passé de la signature TLS.
+
+### A. Le Malus de Nouveauté (`agg_novelty`)
+* **Logique :** Une signature (JA4 + FP) vue pour la première fois aujourd'hui est "froide".
+* **Traitement :** On applique un malus si `first_seen` date de moins de 2 heures. Un botnet qui vient de lancer une campagne de rotation de signatures sera immédiatement pénalisé par son manque d'historique.
+
+### B. Le Dépassement de Baseline (`tbl_baseline_ja4_7d`)
+* **Fonctionnement :** On compare les `hits` actuels au 99ème percentile (`p99`) historique de cette signature précise.
+* **Exemple :** Si le JA4 de "Chrome 122" fait habituellement 10 requêtes/min/IP sur votre site, et qu'une IP en fait soudainement 300, le score explose même si la requête est techniquement parfaite.
+
+---
+
+## 5. Synthèse du Scoring (Le Verdict)
+
+| Algorithme | Signal | Impact Score |
+| :--- | :--- | :--- |
+| **Fingerprint Mismatch** | UA vs TLS (Spoofing) | **Haut (50)** |
+| **L4 Anomaly** | Variance latence < 0.5ms | **Moyen (30)** |
+| **Path Sensitivity** | Hit sur `/admin` ou `/config` | **Haut (40)** |
+| **Payload Security** | Caractères d'injection (SQL/XSS) | **Critique (60)** |
+| **Mass Distribution** | 1 JA4 sur > 50 IPs différentes | **Moyen (30)** |
+
+
+
+---
+
+## 6. Maintenance et faux positifs
+* **Exceptions :** Les bots légitimes (Googlebot, Bing) sont filtrés par ASN et Reverse DNS avant le scoring pour éviter de déréférencer le site.
+* **Réinitialisation :** Un `final_score` est volatile (calculé sur 5 minutes). Une IP bloquée par erreur retrouvera un score normal dès qu'elle cessera son comportement atypique.