# 🛡️ 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.