logcorrelator/views.md

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