Vue d'ensemble de l'architecture¶

HYDRA × PDX est un système à trois couches : capture, routage et sortie, connectées par une boucle de retour continue. Le run HYDRA SSH original sur VPS est maintenant historique ; le portfolio public actuel utilise une couche de deception contrôlée, tandis que PDX reste le pipeline local-first actif.

Couche 1 — Capture¶

Trois sources de données peuvent alimenter le pipeline :

Run HYDRA SSH (passif historique)¶

Le run de recherche original utilisait un honeypot SSH exposé sur le port 2222. Les attaquants se connectaient, s'authentifiaient (tout credential était accepté), et interagissaient avec un environnement Linux simulé. Chaque commande était traitée par llama-3.3-70b (via l'API Groq), générant des réponses contextuelles en temps réel.

HYDRA n'est pas un système de replay statique. Il maintient un système de fichiers virtuel mutable par session (Copy-on-Write), alterne entre trois personas (fintech_trading, crypto_validator, corp_ad), et inclut un anti-empreinte profond pour déjouer les techniques standard de détection de honeypots.

Le routeur de commandes gère un pipeline en 9 étapes : sanitize → PromptGuard → expand → split → pipes → classify → execute → mutate VFS → log. 65+ commandes built-in gèrent les utilitaires courants nativement ; tout le reste est routé vers le LLM avec le contexte VFS complet.

Chaque session produisait un fichier JSONL avec des événements structurés : auth_attempt, session_start, command_executed, injection_detected, session_end.

Couche deception portfolio (surface publique contrôlée)¶

Le portfolio sert aussi de surface de démonstration contrainte. Il peut exposer des comportements leurres sûrs à des visiteurs, bots et scanners, puis normaliser ces interactions en télémétrie de style HYDRA sans exposer de vrais credentials, secrets de production ou interfaces administratives. Voir Couche de deception.

Pont Burp Suite (actif)¶

Une extension Java + un proxy Python qui connecte PDX à Burp Suite. Pendant un pentest web, chaque paire requête/réponse HTTP est analysée et convertie au même format delta .pdx utilisé par HYDRA.

Le même pipeline peut ainsi traiter les données HYDRA historiques, les leurres contrôlés du portfolio et les résultats actifs de pentest.

Couche 2 — Routage¶

Le SessionClassifier sépare d'abord le signal du bruit — seuls 2,2 % des sessions (interactions humaines) passent. Il identifie 5 catégories de trafic automatisé (bot_ephemeral, bot_exec_scanner, bot_dropper, bot_recon, unclassified) et une catégorie signal (likely_human).

Le DataRouter lit ensuite chaque événement et le classifie dans un ou plusieurs flux :

• Défensif — chaque command_executed et auth_attempt y va. Utilisé pour l'entraînement à la détection.
• Offensif — les commandes correspondant à des patterns d'attaque connus (accès aux credentials, escalade de privilèges, mouvement latéral) y vont. Utilisé pour la reconstruction de chaînes d'attaque.
• Les deux — la plupart des événements se qualifient pour les deux flux. Le même cat /etc/shadow est à la fois une alerte de détection (défensif) et une technique d'extraction de credentials (offensif).

La classification repose sur un mapping MITRE ATT&CK avec 11 tactiques, chacune ayant une description duale dans le code.

Couche 3 — Sortie¶

Sept générateurs d'entraînement produisent des datasets structurés :

Avant l'export, tout passe par un Pipeline Qualité : déduplication par trigrammes, filtrage qualité (avec pondération de validation humaine), ordonnancement curriculaire (exemples simples d'abord, kill chains complexes ensuite) et décroissance temporelle (demi-vie de 90 jours).

Le fine-tuning s'exécute localement via Unsloth avec des adaptateurs LoRA sur des modèles Qwen ou Llama.

La boucle de retour¶

Le pipeline n'est pas unidirectionnel. L'Orchestrateur Pipeline PDX coordonne un cycle de feedback continu :

1. SessionAnalyzer parse les logs HYDRA en deltas structurés
2. FeedbackEngine regroupe le comportement des attaquants en profils et calcule des métriques agrégées
3. LureGenerator traduit les métriques en changements concrets du système de fichiers (nouveaux fichiers leurres, credentials mis à jour, .bash_history enrichi)
4. FeedbackStore écrit feedback.yaml
5. FeedbackConsumer (dans HYDRA) poll toutes les 60s et injecte les mises à jour dans le VFS live

L'orchestrateur peut tourner en trois modes : one-shot (--once), mode watch (--watch pour la surveillance continue), ou mode auto (déclenché par l'AutoTraining quand le seuil min_sessions est atteint).

Résultat : le honeypot s'améliore de lui-même continuellement. Après 48h de feedback, l'engagement moyen du persona fintech est passé de ~800 à 1 349 commandes par session.

Analyse multi-modèles¶

PDX ne repose pas sur un seul LLM. Une cascade à 4 niveaux analyse chaque delta de sécurité :

Niveau 1 : Copilot local (7B)     — première passe rapide sur chaque delta
   ↓ incertain ?
Niveau 2 : Teacher local (32B)    — seconde passe détaillée
   ↓ toujours incertain ?
Niveau 3 : API Anthropic          — quand la complexité l'exige
   ↓ indisponible ?
Niveau 4 : WebChat fallback       — marqué NÉCESSITE VALIDATION HUMAINE

Chaque niveau produit un verdict (VULNERABLE, NOT_VULN, INFORMATIONAL, UNCERTAIN, FALSE_POS). Quand les niveaux divergent, le conflit est signalé. Rien n'est supprimé.

Enrichissement des données¶

8 collecteurs enrichissent chaque observation avec du contexte externe : NVD/NIST (CVEs), ExploitDB (exploits connus), OWASP (classifications web), MITRE ATT&CK (tactiques/techniques), Nuclei (signatures de détection), CWE (classifications de faiblesses), IETF RFCs (spécifications de protocoles) et pages man Linux (documentation des commandes).

Infrastructure¶