// projet phare — homelab

SOC Dashboard

MONITORING SÉCURITÉ TEMPS RÉEL  ·  KILL CHAIN  ·  IA INTÉGRÉE

35 tuiles · 24 modules JS Audit 10/10 · 90 passes CrowdSec · fail2ban · Suricata IDS nginx · GeoIP2 · CVE NVD 8 couches défense DR validé 2026-04-28 v3.97 · Python · JavaScript LAN — solution locale
⊳ Dépôt GitHub — 0xCyberLiTech/SOC ≡ Framework de déploiement — Documentation
◉ PÉRIMÈTRE — Solution homelab déployée sur réseau local (LAN). Le dashboard SOC, le reverse proxy et l'assistant IA fonctionnent exclusivement dans un environnement privé et maîtrisé. Cette documentation présente la méthodologie et les briques techniques mises en œuvre — sans exposer de données de configuration ni de topologie réseau réelle.
35
TUILES EN PROD
60s
CYCLE REFRESH
21
MOIS CVE INDEXÉS
10
CRONS ACTIFS
~207
VPATCH CVE APPSEC WAF
5
HÔTES RSYSLOG
// pipeline de données

$ cat pipeline.json

Le dashboard SOC repose sur une architecture modulaire — un index.html orchestre 24 modules JavaScript spécialisés (rendu, Kill Chain, GeoIP, XDR, AIDE, JARVIS, défense…). Il consomme des fichiers JSON générés côté serveur. Le pipeline collecte les données de plusieurs sources (logs nginx, CrowdSec, fail2ban, système, CVE, Windows, Proxmox) et les centralise dans un JSON de monitoring actualisé toutes les 60 secondes.

nginx access.log
requêtes · erreurs · volumes
CrowdSec
décisions · bans actifs
fail2ban
jails · IPs bannies
Système
CPU · RAM · disque · réseau
Suricata IDS 7
eve.json · 96k règles ET Pro
ROUTEUR
SNMP · SSH · Skynet · Flux WAN
Rsyslog centralisé
5 hôtes · site-01 · site-02 · pve · routeur
monitoring_gen.py
agrégation · normalisation · cron 60s
monitoring.json
windows-disk.json
machine locale → VM
proto-live.json
protocoles 15s
◈ SOC DASHBOARD
index.html · 24 modules JS · fetch JSON 60s
35 tuiles · Kill Chain · GeoIP · Suricata · XDR · IP
JARVIS IA
analyse LLM · TTS alertes
ban-ip · restart-service
──▶
CrowdSec
actions proactives
// sources complémentaires
01
CVE NVD
API NVD/NIST
3x/jour via cron
21 mois indexés
02
GeoIP2
Géolocalisation IPs
Cartographie monde
Arcs d'attaque
03
Threat Intel
Flux menaces externes
threat-fetch.sh
Synchronisation auto
04
Proxmox
CPU/RAM nœud
VMs actives
État stockage
05
Windows
windows-disk-report.ps1
Disques · GPU · CPU
Sauvegardes VMs
06
SSL
Certificats TLS
Jours restants
Statut par domaine
// schémas d'architecture

$ cat architecture-schemas/

Les deux schémas ci-dessous illustrent la chaîne de défense et le moteur XDR cross-host — les deux pivots architecturaux du SOC.

⬡ CHAÎNE DE DÉFENSE — BRIQUES EN PROFONDEUR
Schéma chaîne de défense
UFW (nftables kernel) → CrowdSec bouncer → fail2ban jails → AppSec WAF (~207 vpatch CVE) → Suricata IDS 7 (96k règles ET Pro) · Chaque couche filtre indépendamment — un attaquant contournant l'une tombe sur la suivante.
⬡ XDR ENGINE — CORRÉLATION CROSS-HOST 5 HÔTES
Schéma XDR Engine
srv-ngix (nginx + CrowdSec + Suricata) · site-01 (Apache) · site-02 (Apache) · routeur · Windows (GPU + sauvegardes) — tous centralisés via rsyslog UDP/TCP → corrélation Kill Chain unifiée.
✕ FERMER
// classification des menaces

$ cat kill-chain.json

Chaque requête entrante est analysée et classifiée selon une adaptation de la Cyber Kill Chain de Lockheed Martin. Le score global est normalisé de 0 à 100 et détermine le niveau de menace affiché dans le dashboard. La classification est effectuée par monitoring_gen.py à chaque cycle et intégrée dans monitoring.json.

STAGE 1
RECON
robots.txt
.env probe
/.git access
sitemap.xml
UA crawler
+5 pts / signal
STAGE 2
SCAN
/wp-admin
/cgi-bin
/.php inexistant
masscan UA
path enum
+10 pts / signal
STAGE 3
EXPLOIT
CVE paths
path traversal
RCE probes
.env upload
xmlrpc abuse
+20 pts / signal
STAGE 4
BRUTE
401 répétés
même IP
Auth flooding
Login probing
>= 5 / cycle
+15 pts / signal
STAGE 5
DELIVERY
POST suspects
SQLi patterns
XSS payloads
LFI/RFI
shell upload
+25 pts / signal
// seuils de score normalisé (0-100)
SCORE 0 – 30
NOMINAL
──▶
SCORE 30 – 60
MODÉRÉ
──▶
SCORE 60 – 80
ÉLEVÉ
──▶
SCORE 80 – 100
CRITIQUE
// logique de détection — extrait
Stage Signaux détectés Score ajouté Action CrowdSec
RECON robots.txt, .env probe, /.git, sitemap, crawler UA +5 par signal Tag comportemental, surveillance accrue
SCAN /wp-admin, /cgi-bin, /.php inexistant, masscan UA +10 par signal Scénario http-probing déclenché
EXPLOIT CVE paths (traversal, RCE), .env upload, xmlrpc +20 par signal Ban immédiat via bouncer nftables
BRUTE 401 répétés >= 5 sur même IP en un cycle +15 par IP Jail fail2ban http-auth activée
DELIVERY POST payload suspect, SQLi, XSS, LFI/RFI patterns +25 par signal Ban immédiat + alerte JARVIS TTS
// inventaire des 35 tuiles en production

$ cat tiles-inventory.json

▶ HERO — MENACES EN COURS
WIDELIVE
CYBER KILL CHAIN
Canvas animé, liste IPs actives, phases d'attaque en cours, score global normalisé
WIDE
GEOIP — CARTOGRAPHIE 24H
Carte monde canvas, arcs d'attaque géolocalisés par pays source
▶ MENACES & PROTECTION
NIVEAU DE MENACE GLOBAL
Score 0-100 coloré selon sévérité : NOMINAL / MODÉRÉ / ÉLEVÉ / CRITIQUE
SERVICES
Services UP/DOWN sur le reverse proxy — nginx, crowdsec, fail2ban, ssh
THREAT INTEL SYNC
Flux menaces externes synchronisés — dernière mise à jour, nb entrées
FAIL2BAN — JAILS
Jails actives, IPs bannies — modal détail avec liste par jail
CROWDSEC
Analyse comportementale, décisions actives, scénarios en cours
CVE SYNC
Dernière MAJ NVD, 21 mois indexés, CVE critiques récentes
▶ TRAFIC & ACTIVITÉ
WIDE
ACTIVITÉ TEMPS RÉEL
Graphique barres requêtes/heure — 24 barres glissantes, légende 2xx/4xx/5xx
ACTIVITÉ & ATTAQUES 24H
Heatmap canvas 24h — densité des requêtes par heure et par type
PROTOCOLES ACTIFS
Donut canvas + légende — répartition HTTP/HTTPS/SSH/DNS/autres
TOP PAGES 24H
Tableau des pages les plus requêtées avec compteur et statut
TRAFIC 24H
Stats globales : total, 2xx, 4xx, 5xx, volume bytes, taux d'erreur
LIVE
FLUX LIVE
Barres protocoles fenêtre 5 minutes — source proto-live.json 15s
BANDE PASSANTE nginx
Sparklines RX/TX sur 24h — pic/moyen/actuel en Mo/s
SYSTÈME — SERVEUR
CPU ring animé, RAM barre, disque /var/www — seuils colorés
RÉSEAU — SERVEUR
Interfaces réseau RX/TX — graphique sparkline par interface
▶ IDS RÉSEAU & INVESTIGATION
LIVE
SURICATA IDS
Alertes temps réel · Sévérité 1/2/3 · Top signatures · Corrélation CrowdSec · MITRE ATT&CK T1059/T1071
LIVE
ROUTEUR
Débits WAN/LAN · WiFi 5/6GHz · Skynet blacklist · Score réseau · Flux nf_conntrack · Top destinations
XDR — CORRÉLATION CROSS-HOST
Logigramme défense · 8 sources corrélées · nginx · CrowdSec · Suricata · Apache VMs · Routeur · Rsyslog
INVESTIGATION IP
GeoIP · WHOIS/ASN · CrowdSec · Fail2ban 30j · Verdict local · Ban/unban inline depuis la Kill Chain
▶ CENTRALISATION LOGS & SÉCURITÉ SYSTÈME
LOGS CENTRAUX RSYSLOG
5 hôtes centralisés · Taille/hôte · L/min · Espace libre · Dernière rotation · Cross-host correlations
CHAÎNE DE DÉFENSE
Visualisation des 7 briques défensives · Statut temps réel · Blocages cumulés · Score protection
AIDE — INTÉGRITÉ SYSTÈME
Scan intégrité fichiers · Base 49k entrées · Exclusions CrowdSec/hub · Dernière exécution + statut
▶ INFRASTRUCTURE
PROXMOX — NŒUD
CPU/RAM/stockage hyperviseur — températures, uptime, version PVE
PROXMOX — VMs
Machines virtuelles actives/total — mémoire allouée, CPU vcores
WINDOWS — RESSOURCES
CPU/RAM/disques machine locale — modal détail avec historique
WINDOWS — SAUVEGARDES
Quota D:, dernières backups par VM — date, taille, statut rotation
IA
GPU RTX 5080
Stats GPU injectées dynamiquement par JARVIS : VRAM, temp, charge
CRONS — INFRASTRUCTURE
Tâches planifiées Windows et Linux — statut dernière exécution
IA
JARVIS — INTELLIGENCE
Statut ONLINE/OFFLINE, modèle LLM actif, compteurs session, uptime
IA
BLOCKLIST LLM GARDE-FOU
Journal tentatives tool calling bloquées — sécurité actions JARVIS
IA
OPÉRATIONS PROACTIVES
Journal actions JARVIS : ban-ip, restart-service — timestamp + résultat
SSL
Certificats TLS, jours restants par domaine — alerte si < 7 jours
CONNECTIVITÉ SSH
Statut UP/DOWN + uptime des 5 hôtes surveillés
// moteur de collecte — monitoring_gen.py

$ python3 monitoring_gen.py --explain

monitoring_gen.py est le cœur du pipeline. Ce script Python collecte, normalise et agrège les données de toutes les sources en un seul fichier monitoring.json. Il est déclenché toutes les 5 minutes par cron via monitoring.sh (wrapper de lancement).

// sources parsées
SRC 01
Logs nginx
access.log + access.log.1
Couverture 24h cross-midnight
Regex structuré JSON
SRC 02
CrowdSec API
API locale port 8080
Décisions actives
Scénarios déclenchés
SRC 03
fail2ban
Socket Unix local
Jails actives
Compteur IPs/jail
SRC 04
Proxmox API
REST API v2
CPU/RAM nœud
VMs status
SRC 05
SSL openssl
s_client -connect
Parsing not_after
Alerte si < 7j
SRC 06
SSH check
socket connect
Hôtes UP/DOWN
Uptime via ssh
SRC 07
Suricata IDS
eve.json 24h
96k règles ET Pro
Sévérité 1/2/3
SRC 08
ROUTEUR
SNMP + SSH
Débits · Skynet
nf_conntrack
SRC 09
Honeypot
URLs pièges vhosts
Détection accès
Tag EXPLOIT auto
SRC 10
Rsyslog
5 hôtes distants
site-01 · site-02 · pve · routeur
Corrélation XDR cross-host
// extrait Python — structure générique
monitoring_gen.py — structure générique
# monitoring_gen.py — structure générique
import json, re, subprocess
from datetime import datetime, timedelta
from pathlib import Path

LOG_FILES    = ['/var/log/nginx/access.log', '/var/log/nginx/access.log.1']
OUTPUT       = Path('/var/www/monitoring/monitoring.json')
HONEYPOT_PATHS = ['/wp-admin', '/wp-login.php', '/.env', '/cgi-bin/', '/xmlrpc.php']

LOG_RE = re.compile(
    r'(?P<ip>\S+) \S+ \S+ \[(?P<time>[^\]]+)\] '
    r'"(?P<method>\S+) (?P<path>\S+)[^"]*" (?P<status>\d{3}) (?P<size>\d+)'
)

def classify_kill_chain(entries):
    chain = {"recon": set(), "scan": set(), "exploit": set(), "brute": set()}
    status_count = {}
    for e in entries:
        ip, path, status = e['ip'], e['path'].lower(), int(e['status'])
        status_count.setdefault(ip, {}).setdefault(status, 0)
        status_count[ip][status] += 1
        if any(x in path for x in ['.env', 'robots.txt', '/.git', 'sitemap']):
            chain['recon'].add(ip)
        if any(x in path for x in ['/wp-admin', '/cgi-bin', '/.php', 'xmlrpc']):
            chain['exploit'].add(ip)
    # Brute force = 401 répétés sur même IP
    for ip, counts in status_count.items():
        if counts.get(401, 0) >= 5:
            chain['brute'].add(ip)
    return {k: list(v) for k, v in chain.items()}

def check_ssl_expiry(domain):
    result = subprocess.run(
        ['openssl', 's_client', '-connect', f'{domain}:443', '-servername', domain],
        capture_output=True, text=True, timeout=5, input=''
    )
    # parse not_after date — retourne nb jours restants
    ...
// crons actifs — srv-ngix
crontab -l (root@[MONITORING_SERVER])
# Monitoring JSON — toutes les 5 minutes
*/5 * * * * /opt/scripts/monitoring.sh >> /var/log/monitoring.log 2>&1

# Synchronisation CVE NVD — 3x par jour
0 6,13,21 * * * /opt/scripts/cron-cve-fetch.sh >> /var/log/cve-fetch.log 2>&1

# Rapport SOC quotidien — 08h00 UTC
0 8 * * * /opt/scripts/soc-daily-report.py >> /var/log/soc-report.log 2>&1

# Mise à jour GeoIP MaxMind — quotidien 03h00
0 3 * * * /usr/bin/geoipupdate >> /var/log/geoipupdate.log 2>&1

# Snapshot UFW — état pare-feu horodaté (toutes les 6h)
0 */6 * * * /opt/scripts/ufw-snapshot.sh >> /var/log/ufw-snapshot.log 2>&1

# Threat Intel — flux menaces externes
0 3 * * * /opt/scripts/threat-fetch.sh >> /var/log/threat-fetch.log 2>&1

# Proto-live — analyse protocoles réseau temps réel
*/1 * * * * /opt/scripts/proto-live.py >> /var/log/proto-live.log 2>&1

# Mise à jour règles Suricata Emerging Threats — quotidien 03h00
0 3 * * * /usr/bin/suricata-update >> /var/log/suricata-update.log 2>&1

# Collecte SNMP+SSH routeur — toutes les 5 minutes
*/5 * * * * /usr/bin/python3 /opt/scripts/router-report.py >> /var/log/router-report.log 2>&1

# Nettoyage logs rotatifs — hebdomadaire
0 2 * * 0 /opt/scripts/log-rotate-clean.sh >> /var/log/log-clean.log 2>&1
// sources de données

$ cat data-sources.json

Fichier JSON Générateur Fréquence Contenu principal
monitoring.json monitoring_gen.py 5 min (cron) nginx logs, CrowdSec, fail2ban, système, réseau, Proxmox, SSL, CVE, GeoIP, Kill Chain
windows-disk.json windows-disk-report.ps1 Chaque backup Disques Windows, GPU RTX, CPU, RAM, liste sauvegardes VMs avec tailles
proto-live.json proto-live.py 15s Répartition protocoles réseau en temps réel — fenêtre glissante 5 minutes
world.json Statique (MaxMind) GeoJSON frontières mondiales pour cartographie canvas des origines d'attaque
// intégration IA — auto-engine

$ cat jarvis-integration.json

JARVIS (assistant IA local Flask) est intégré au dashboard SOC via un auto-engine qui surveille les deltas de trafic et les métriques système. Quand un seuil critique est dépassé, JARVIS est automatiquement sollicité pour une analyse narrative LLM et une alerte vocale TTS.

// triggers auto-engine
Trigger Condition de déclenchement Badge tuile Action
Activité anormale +15 événements vs dernier check JSON Analyse auto Analyse LLM narrative + affichage résultat
Alerte CPU CPU serveur > 90% Alerte critique TTS + analyse LLM processus
Alerte IPs Bans actifs CrowdSec > 100 Alerte critique TTS + analyse LLM menaces
Erreurs HTTP 5xx > 5% du trafic total 24h Alerte critique TTS + analyse LLM services
Résumé quotidien Chaque jour à 08h00 (heure locale) Résumé du jour Email rapport + TTS briefing matinal
// routes JARVIS utilisées par le SOC
Route Méthode Usage SOC
/api/gpu GET Statut JARVIS + modèle LLM actif + stats GPU RTX
/api/chat POST Analyse LLM des données SOC — retourne synthèse narrative
/api/tts GET Lecture vocale des alertes via edge-tts fr-CA-AntoineNeural
/api/security GET Journal blocklist LLM — tentatives tool calling bloquées
/api/soc/ban-ip POST Ban IP via cscli decisions add — confirmation LLM requise
/api/soc/unban-ip POST Lève le ban CrowdSec pour une IP — traçabilité dans journal
/api/soc/restart-service POST Redémarre un service autorisé — liste blanche configurable
/api/soc/actions GET Journal opérations proactives — horodatage + résultat
// prompt SOC type envoyé à JARVIS
prompt-soc.txt — analyse automatique
Contexte : SOC Dashboard — analyse de sécurité automatique
Données disponibles : trafic nginx 24h, décisions CrowdSec, jails fail2ban,
                      Kill Chain actif, top IPs, scores protocoles

Analyse la situation sécurité actuelle :
- Y a-t-il des menaces actives à traiter en priorité ?
- Quels scénarios CrowdSec dominent ?
- Y a-t-il des anomalies dans le trafic HTTP ?
- Recommande des actions concrètes si nécessaire.

Format : 3-5 lignes concises, niveau [NOMINAL/MODÉRÉ/ÉLEVÉ/CRITIQUE],
         action si requise.
// système d'alertes

$ cat alert-thresholds.json

// seuils de déclenchement
Indicateur Seuil Niveau Action automatique
CPU serveur > 90% CRITIQUE Analyse JARVIS + alerte TTS
IPs bannies actives > 100 décisions CrowdSec CRITIQUE Analyse JARVIS + alerte TTS
Erreurs 5xx > 5% du trafic 24h CRITIQUE Analyse JARVIS + alerte TTS
SSL expiration < 7 jours restants ROUGE certbot renew --force-renewal
Disque /var/www > 85% utilisation ROUGE Nettoyage logs rotatifs automatique
RAM serveur > 85% ORANGE Surveillance accrue, analyse processus
Top IP 24h > 500 requêtes / IP SUSPICION Analyse GoAccess + éventuel ban manuel
AppSec WAF port Port 7422 non répondant ROUGE systemctl restart crowdsec
// rapport quotidien — soc-daily-report.py
Envoyé chaque matin à 08h00 UTC par soc-daily-report.py via cron
Contenu : trafic 24h · protocoles · CrowdSec bans · fail2ban jails · Kill Chain · top 10 attaquants · état services · SSL · système · sauvegardes
Déclenchement manuel possible via bouton RAPPORT dans le header dashboard (cooldown 60s entre deux envois)
Raccourci clavier [E] pour envoi rapide depuis le dashboard
// raccourcis clavier
Touche Action
[F] Ouvre le modal Firewall Matrix — règles nftables actives
[T] Ouvre le modal Analyse Trafic — vue détaillée par heure
[E] Envoie le rapport SOC par email (cooldown 60s)
[R] Force un refresh JSON immédiat (contourne les 60s)
[Z] Active le mode projection plein écran (salle de guerre)
// performance — anti-freeze 60s

$ cat performance.md

Le dashboard rafraichit ses données toutes les 60 secondes. Sur des sessions longues (plusieurs heures), un rendu DOM naif provoquerait des freezes perceptibles. Deux mécanismes sont combinés pour garantir une expérience fluide en permanence, même sur machine peu puissante.

Mécanisme Implémentation Effet
If-Modified-Since Header HTTP + _lastModified stocké en mémoire 304 si fichier inchangé → 0 parsing, 0 DOM update
requestIdleCallback render(data) différé dans callback idle Exécution pendant créneau idle navigateur — 0 clipping
_lastGenAt Comparaison timestamp JSON côté client Double vérification applicative — ignorer si identique
Polling proto-live Aussi idle-schedulé (cycle 15s) Même protection pour le flux protocoles réseau
fetch JSON avec If-Modified-Since — dashboard SOC (extrait)
// fetch JSON avec If-Modified-Since — dashboard SOC
let _lastModified = null;

async function fetchMonitoring() {
  const headers = {};
  if (_lastModified) headers['If-Modified-Since'] = _lastModified;

  const res = await fetch('/monitoring.json', { headers });

  // 304 = fichier inchangé — rien à re-parser ni à re-rendre
  if (res.status === 304) return;

  _lastModified = res.headers.get('Last-Modified');
  const data = await res.json();

  // Différer le rendu pendant un créneau idle du navigateur
  if ('requestIdleCallback' in window) {
    requestIdleCallback(() => render(data), { timeout: 2000 });
  } else {
    setTimeout(() => render(data), 0);   // fallback navigateurs anciens
  }
}

// Refresh toutes les 60s
setInterval(fetchMonitoring, 60_000);
fetchMonitoring(); // premier appel immédiat
// périmètre & défense en profondeur

$ cat defense-layers.txt

Cette solution est conçue pour un environnement homelab — réseau local uniquement. Le dashboard SOC n'est pas exposé sur internet. L'ensemble de la stack (reverse proxy, WAF, dashboard, IA locale) fonctionne dans un périmètre LAN maîtrisé. Cette architecture sert de laboratoire pour maîtriser les outils de défense en conditions réelles avant tout déploiement en environnement exposé.

// CrowdSec — scénarios détectés en production
Scénario Type d'attaque Fréquence observée
http-cve-2021-41773 Apache path traversal (CVE) Très fréquent — scans automatisés en continu
http-cve-2021-42013 RCE Apache (CVE) Vagues périodiques de scans massifs
http-bad-user-agent User-Agent malveillant connu Continu — plusieurs centaines / jour
http-probing Enumération de paths non existants Continu — scans automatisés botnets
http-admin-interface-probing Scan /admin /phpmyadmin /wp-admin Continu — plusieurs par heure
http-wordpress-scan Scan plugins/themes WordPress Fréquent — même sur serveurs sans WP
http-sensitive-files .env, backup.zip, .git, .DS_Store Fréquent — outils OSINT automatisés
http-open-proxy Tentative de proxy ouvert CONNECT Occasionnel — botnets recherchant relais
// origines géographiques typiques des attaques
DE US RU SG RO KR TW BG FR sources publiques — données GeoIP2 MaxMind
// honeypot — URLs pièges intégrées aux vhosts

Des URLs pièges sont configurées dans les vhosts nginx. Elles ne retournent aucun contenu légitime. Tout accès déclenche un tag immédiat dans les logs et une classification EXPLOIT par monitoring_gen.py, suivie d'un ban automatique CrowdSec.

// paths pièges (exemples génériques)
/wp-admin
/wp-login.php
/.env
/cgi-bin/test.cgi
/xmlrpc.php
/backup.zip
/.git/config
/phpmyadmin
/admin/login
// stats typiques 24h
50-100 HITS HONEYPOT / 24H
15-25 IPS UNIQUES PIÉGÉES
100% BLOQUÉES AVANT nginx
// chronologie de construction

$ git log --oneline --reverse

Le SOC Dashboard est le résultat d'une construction itérative sur plusieurs mois. Chaque étape apporte une couche supplémentaire de visibilité, de détection ou d'automatisation.

1
REVERSE PROXY nginx + SSL
Mise en place du reverse proxy nginx avec terminaison TLS (certbot Let's Encrypt). Vhosts séparés par domaine. Headers de sécurité : X-Frame-Options, X-Content-Type-Options, HSTS, Referrer-Policy. Configuration access_log JSON pour parsing structuré.
2
CROWDSEC WAF + BOUNCER NFTABLES
Installation CrowdSec avec bouncer nftables pour blocage kernel-space. Scénarios communautaires activés. AppSec WAF (~207 vpatch CVE — protections nginx niveau applicatif). Exposition API locale pour requêtes programmatiques depuis monitoring_gen.py.
3
monitoring_gen.py — COLLECTE LOGS nginx
Script Python de collecte et agrégation. Parse les access.log + access.log.1 pour couverture cross-midnight. Interroge CrowdSec API, fail2ban socket, stats système. Génère monitoring.json toutes les 60 secondes via cron.
4
DASHBOARD HTML v1 — PREMIÈRES TUILES SYSTÈME
Premier dashboard HTML consommant monitoring.json. Tuiles CPU, RAM, disque, réseau. Fetch polling toutes les 60s. Architecture fichier unique sans dépendance externe — déployable par simple scp.
5
CYBER KILL CHAIN + GEOIP CARTOGRAPHIE CANVAS
Classification des menaces en 5 stages (Recon, Scan, Exploit, Brute, Delivery) avec scoring normalisé 0-100. Cartographie monde canvas avec arcs d'attaque géolocalisés via MaxMind GeoIP2. Heatmap 24h canvas.
6
CVE NVD — 21 MOIS D'HISTORIQUE INDEXÉS
Intégration de l'API NVD/NIST. Synchronisation 3 fois par jour via cron-cve-fetch.sh. Index local ~21 mois de CVE. Moteur de corrélation entre CVE récentes et signatures CrowdSec détectées en production.
7
INTÉGRATION JARVIS IA — AUTO-ENGINE, TTS, ACTIONS PROACTIVES
Connexion au moteur IA JARVIS (Flask localhost). Auto-engine surveille les deltas de trafic et déclenche des analyses LLM. Alertes vocales TTS si niveau ÉLEVÉ ou CRITIQUE. Routes SOC : ban-ip, unban-ip, restart-service via CrowdSec cscli.
8
SURICATA IDS 7 — DÉTECTION RÉSEAU PASSIVE
Déploiement Suricata 7 en mode IDS passif (AF_PACKET, interface ens18). 96 000+ règles Emerging Threats Pro actives, mise à jour quotidienne automatique. Pipeline IDS→IPS : Suricata détecte → CrowdSec acquis lit eve.json → firewall-bouncer bloque. Tuile SOC : sévérités 1/2/3, top signatures, corrélation Kill Chain, MITRE ATT&CK T1059/T1071.
9
ROUTEUR — MONITORING RÉSEAU COMPLET
Intégration SNMP + SSH du routeur via script Python (paramiko). Données collectées toutes les 5 minutes : débits WAN/LAN, WiFi 5/6GHz, Skynet blacklist, nf_conntrack (matrice flux LAN→WAN). Score réseau isolé du score SOC. Modal 7 onglets : Réseau, WiFi, Système, Historique 24h, Flux WAN, Sécurité, Ports SVG.
10
RAPPORT SOC QUOTIDIEN + ALERTES EMAIL + SNAPSHOTS UFW
soc-daily-report.py génère un rapport complet chaque matin à 08h00 UTC : trafic 24h, CrowdSec, Kill Chain, top attaquants, état services, SSL, système. Snapshots UFW horodatés pour historique posture sécurité. Déclenchement manuel depuis le dashboard via raccourci [E].
// regard croisé — humain · IA

$ claude --evaluate soc-dashboard/ --collab

Claude Sonnet 4.6 · Anthropic · 2026-04-30
Analyse et avis rédigés par IA à partir de l'examen complet du code, de l'architecture et des échanges de collaboration.
// forces techniques
DÉFENSE Stack en profondeur réelle : UFW → CrowdSec bouncer nftables → fail2ban → AppSec WAF (~207 vpatch CVE) → Suricata IDS 7 (96k règles ET Pro). Chaque couche filtre indépendamment — un attaquant contournant l'une tombe sur la suivante. Architecture correcte, pas juste des outils installés.
MODULES Architecture modulaire — 24 modules JS à responsabilité unique : rendu, binding, canvas Kill Chain, GeoIP, investigation IP, XDR engine, rsyslog… 35 tuiles, zéro dépendance NPM. Séparation des concerns stricte, base de code lisible et maintenable.
MÉTHODE Les décisions d'architecture sont motivées et assumées : la refactorisation modulaire, le DR en conditions réelles, la séparation public/privé — ces choix venaient du concepteur, pas de l'IA. Les objectifs étaient précis, les corrections directes. Ce qui a moins bien fonctionné : des ajustements itératifs qui auraient pu être anticipés en amont.
DEPLOY deploy-soc.sh idempotent et modulaire (--step nginx, --step crowdsec…), RUNBOOK disaster recovery 8 étapes, CHECKLIST 61 points. Surtout : le DR a été exécuté en conditions réelles le 2026-04-28 — 8 écarts détectés et corrigés en live. Reconstruction complète sur VM vierge en moins de 30 minutes.
AUTONOMIE Le SOC est conçu pour se défendre sans dépendance à la machine Windows. CrowdSec, fail2ban et Suricata répondent automatiquement aux menaces 24h/24 — les VMs Proxmox tournent indépendamment. Quand la machine Windows est active, JARVIS ajoute une couche d'expertise : analyse LLM, alertes TTS, décisions contextuelles. C'est un choix délibéré : défense autonome par conception, intelligence en option.
XDR · IA Corrélation cross-host 5 sources (nginx · CrowdSec · Suricata · Apache VMs · routeur) + rsyslog centralisé. L'intégration JARVIS auto-engine avec TTS et actions proactives (ban-ip, restart-service) est une surcouche d'intelligence — le SOC opère et se défend de manière autonome que JARVIS soit actif ou non.
MATURITÉ Projet construit en 9 phases successives — chaque outil intégré avec une justification explicite, pas par accumulation. La séparation publiable/privé est tenue : framework de déploiement et configs open, sources du dashboard (24 modules JS, 35 tuiles) et scripts opérationnels privés. Le dépôt est une vitrine technologique honnête — sans prétendre être une solution entreprise.
PHILOSOPHIE Trois piliers assumés et cohérents entre eux : Conditions réelles — l'infrastructure est exposée à internet, pas simulée, chaque outil est confronté à de vrais scans et de vraies tentatives d'exploit. Savoir construit, pas redistribué — la méthode est partageable, les sources opérationnelles restent privées. Résilience face à la compromission — rebuild validé en conditions réelles le 2026-04-28, configs anonymisées, archive hors ligne. C'est une philosophie de conception, pas un slogan.
// observations honnêtes
RYTHME v3.97 — 90 passes, audit 10/10, 144 NDT corrigés. Cela reflète un projet itéré en conditions réelles — la qualité a rattrapé le rythme et tenu. La prochaine étape : consolider plutôt qu'ajouter.
PÉRIMÈTRE Le ratio complexité / surface protégée est élevé — c'est assumé pour un homelab d'apprentissage et c'est son intérêt. Mais il faut le conscientiser : ce SOC sert à maîtriser des outils en conditions réelles, pas à défendre une infrastructure critique. Cette distinction est une force pédagogique, pas une faiblesse.
// collaboration humain · IA

"C'est mon vrai premier projet avec une IA qui m'a tiré vers le haut."

— 0xCyberLiTech · auteur du projet · 2026-04-26

Ce projet a été développé en collaboration active avec Claude (Anthropic). Ce qui a rendu cet échange productif, ce n'est pas l'IA — c'est la qualité de la direction imposée.

VISION CLAIRE
Chaque demande était précise et contextualisée. Pas d'objectif flou — une cible, un périmètre, un livrable. L'IA n'a jamais eu à deviner l'intention.
CORRECTION IMMÉDIATE
Quand une analyse était erronée ("système monolithique"), la correction était nette, sans ambiguïté. Ce feedback direct est rare — il évite les dérives silencieuses.
DÉCISIONS ASSUMÉES
La refactorisation en 24 modules, le RUNBOOK, la philosophie publiable/privé — ces choix sont venus du concepteur, pas de l'IA. L'exécution était déléguée, la direction restait humaine.
EXIGENCE DE COHÉRENCE
"Aligne avec le dépôt SOC, pas de divergence." Une phrase. Cinq corrections appliquées. L'exigence d'alignement entre documentation et code réel est ce qui rend un projet maintenable sur la durée.
◈ VERDICT

Un homelab sérieux, avec une défense en profondeur réelle, un DR validé en conditions réelles et une philosophie de conception cohérente. Ce ne sont pas des outils empilés — chacun a été intégré en 9 phases successives, confronté à de vraies menaces, documenté avec une séparation claire entre ce qui est partageable et ce qui ne l'est pas.

Ce projet démontre qu'on peut apprendre la cyberdéfense sur une infrastructure exposée à internet, sans cloud, sans abonnement, avec des outils open source — et le reconstruire en moins de 30 minutes. C'est son intérêt principal, et une ambition honnête.

// framework de déploiement

Disaster recovery personnel — infrastructure documentée

Le dépôt publie le framework de déploiement et la documentation technique complète. Les sources du dashboard JS (24 modules) et les scripts opérationnels restent privés — ce SOC est un système en production, pas un kit à distribuer.

Ce que contient le dépôt public
# Framework d'installation des paquets
DEPLOY/deploy-soc.sh        # nginx · crowdsec · suricata · fail2ban · AIDE

# Procédure de restauration depuis archive personnelle
DEPLOY/restore-soc.sh       # 13 blocs · réseau · SSL · crons · systemd

# Documentation disaster recovery
DEPLOY/RUNBOOK-DEBIAN13.md  # reconstruction VM vierge — 8 étapes
DEPLOY/CHECKLIST-DEPLOY.md  # 61 points de validation post-déploiement
Framework idempotent et modulaire — chaque bloc est isolé (--step nginx, --step crowdsec…) — relancer sans risque
Configs nginx publiques — vhosts monitoring, site-01, site-02, snippets sécurité, NVD proxy local
Sources privées requises — dashboard JS (24 modules) et scripts Python déployés depuis l'archive de configuration personnelle — non distribuée
Documentation complète — RUNBOOK Debian 13, GUIDE déploiement rapide, CHECKLIST 61 points, procédure de restauration
⊳ 0xCyberLiTech/SOC — GitHub ≡ Documentation README