TheStaff

Transformer l’audit de sécurité en atelier convivial lors d’événements physiques (meetups, hackathons, game jams). Les participants choisissent de jouer en se connectant à un WiFi de défi et passent par une page de consentement honnête. L’objectif collectif : que toutes les cartes soient vertes (corrigées) ou bleues (risque accepté en connaissance de cause) à la fin de l’événement.

Usage réservé aux événements autorisés par le propriétaire du réseau, avec l’accord explicite des participants ; le dépôt fournit une charte éthique et des règles d’engagement.

• Découverte périodique des appareils du réseau avec nmap.
• Identification du type (téléphone, portable, imprimante, TV, routeur, NAS, objet connecté, caméra, console) par détection d’OS, préfixe MAC du fabricant et ports ouverts.
• Correspondance ports → services → CVE : script vulners en ligne, base vulscan hors ligne, enrichissement NVD optionnel.
• Schéma radial en direct : une carte par invité autour du nœud « réseau de l’événement », colorée selon son pire résultat (rouge ouvert, vert corrigé, bleu accepté).
• Vue détaillée : ports, CVE avec score CVSS, résumé lisible, pistes de correction et commandes de test non destructives à copier.
• Contre-vérification automatique qui repasse un résultat au vert quand le port est fermé ou le service mis à jour.
• Assistant IA optionnel par CVE (clé Claude ou OpenAI conservée dans le navigateur, transmise requête par requête via un proxy qui ne l’écrit jamais).
• Mode confidentialité qui masque les deux derniers octets des adresses IP à l’écran et dans les messages envoyés à l’IA.
• Jeton opérateur obligatoire pour toutes les actions (scan, acceptation, vérification, effacement, IA).

Un planificateur (APScheduler) lance le cycle de scan : nmap en sous-processus asynchrone, analyse du XML, identification, correspondance CVE puis réconciliation avec l’état connu, stocké en SQLite (WAL, SQLModel). Chaque nouvel instantané est diffusé par WebSocket au tableau de bord Vue 3, qui dessine le schéma avec @vue-flow/core et un store Pinia.

Le conteneur tourne en Podman rootful avec --network=host et la seule capacité CAP_NET_RAW (racine du système de fichiers en lecture seule, no-new-privileges, jamais --privileged), indispensable aux scans ARP, SYN et à la détection d’OS. Images pour amd64 et arm64, Raspberry Pi 64 bits compris.

1. Les invités se connectent au WiFi du défi et acceptent la page de consentement.
2. L’équipe suit le tableau de bord : les nouveaux appareils apparaissent en rouge.
3. Un membre de l’équipe s’assoit avec chaque invité et parcourt ses résultats avec les pistes de correction.
4. Correction faite → Run healthcheck → carte verte. Correction impossible ou refusée → Accept → carte bleue.

Essai en mode simulé (sans réseau, nmap ni conteneur), avec huit appareils fictifs et de vraies CVE :

./scripts/dev.sh                              # backend simulé sur :8000
cd frontend && npm install && npm run dev    # http://localhost:5173/dashboard

Sur place, en conteneur :

cp .env.example .env
sed -i "s|^THESTAFF_ADMIN_TOKEN=.*|THESTAFF_ADMIN_TOKEN=$(openssl rand -hex 24)|" .env
sudo ./start.sh        # construit l’image si besoin et détecte le sous-réseau
sudo ./update.sh       # reconstruire et redéployer
sudo ./stop.sh

Le tableau de bord est servi sur le port 8000 de la machine ; le même jeton se saisit dans Settings → Operator token. TARGET_CIDR dans .env fixe le sous-réseau si la détection automatique ne convient pas.