Voir ce qui se passe
sur mon serveur, et réagir.
Un serveur exposé sur Internet est scanné en permanence par des robots qui cherchent une faille. Je voulais un endroit unique pour superviser la machine (processeur, mémoire, disque, températures, consommation électrique) et détecter les attaques : un appareil inconnu sur le Wi-Fi, une tentative de connexion forcée, une requête d'exploitation, un fichier système modifié.
Plutôt que d'installer une solution toute faite, j'ai construit chaque brique moi-même pour comprendre le fonctionnement d'un SOC (centre opérationnel de sécurité) : collecte, détection, corrélation, alerte et réponse. Chaque onglet du panel contient aussi une page « Fonctionnement » qui explique sa technologie.
Une interface d'admin
qu'on ne trouve pas.
La meilleure protection d'une page d'administration, c'est de ne pas l'exposer. Le panel écoute uniquement sur la machine elle-même et n'est publié que sur mon réseau privé Tailscale (VPN WireGuard), en HTTPS. Depuis Internet ou le Wi-Fi de la maison, il n'existe pas.
- Double authentification TOTP (RFC 6238), compatible avec toutes les applications d'authentification : QR code à l'activation, protection contre le rejeu, et 10 codes de secours à usage unique, hachés en base.
- Mot de passe haché avec scrypt, une fonction volontairement lente et gourmande en mémoire, comparée en temps constant.
- Anti-bruteforce : attente croissante puis blocage après plusieurs échecs, et chaque échec remonte dans le SIEM.
- Sessions durcies : cookies
__Host-HttpOnly, Secure, SameSite=Strict, jeton anti-CSRF, expiration après inactivité. - Politique de sécurité du contenu stricte : aucun script externe ni en ligne.
- Les opérations sensibles (désactiver la MFA, changer le mot de passe) redemandent le mot de passe et un code.
Séparer les privilèges :
l'exposé n'a aucun droit.
Scanner le réseau, écouter les paquets ou modifier le pare-feu demande des droits élevés. Je ne voulais pas les donner à la partie web, la seule joignable. Le projet est donc découpé en trois conteneurs Docker :
- Le panel webAucune capacité Linux, système de fichiers en lecture seule. Il lit une base SQLite partagée et y dépose des demandes (« scanner ce poste », « bannir cette adresse »).
- Le capteur de sécuritéIl a juste les droits utiles (socket brut, pare-feu, lecture seule des fichiers de l'hôte) et n'écoute sur aucun port. Il re-vérifie chaque demande du panel avant d'agir.
- SuricataLe moteur de détection d'intrusion, dans son conteneur officiel, analyse le trafic et écrit ses alertes dans un fichier que lit le capteur.
Même si quelqu'un prenait le contrôle du panel, il ne pourrait ni lire les fichiers du serveur, ni toucher au pare-feu, ni écouter le réseau.
Supervision
Les métriques sont lues toutes les 2 secondes directement dans le noyau Linux (/proc, /sys), sans agent. L'historique est gardé 30 jours. La consommation électrique est estimée en euros à partir du compteur d'énergie du processeur (RAPL).
Un onglet
par technologie.
- Réseauinventaire
- Scan ARP du réseau local avec un socket brut écrit en Python, base des fabricants IEEE, résolution des noms. Tout nouvel appareil déclenche une alerte et un scan de ses ports ; les services risqués (Telnet, SMB, RDP…) sont signalés.
- Anti-usurpationARP spoofing
- Écoute passive des annonces ARP pour détecter l'attaque de l'homme du milieu : MAC de la box qui change, conflit d'adresses, machine qui répond pour plusieurs IP, balayage du réseau.
- Expositionsurface d'attaque
- Ports en écoute lus dans le noyau et classés selon d'où ils sont joignables. Audit de la configuration SSH, du pare-feu et des réglages de sécurité du noyau ; alerte sur tout nouveau port.
- JournauxSIEM
- Collecte de journald (SSH, sudo, comptes), du journal d'accès du portfolio et des connexions au panel, puis corrélation : force brute, connexion réussie après échecs, création de compte, robots qui cherchent des failles.
- DétectionIDS Suricata
- Analyse du trafic avec ~50 000 signatures Emerging Threats mises à jour chaque jour, classées par gravité et reliées à MITRE ATT&CK.
- BlocageIPS nftables
- Les attaquants sont bannis au pare-feu du noyau, avant même d'atteindre un service. La durée double à chaque récidive, et une liste blanche m'empêche de me bloquer moi-même.
- IntégritéHIDS
- Empreintes SHA-256 des fichiers qu'un attaquant modifie pour rester sur la machine (clés SSH, comptes, sudo, cron, services), contrôles des comptes et suivi des mises à jour de sécurité Debian.
- AlertesSOC
- Une file unique, dédoublonnée, avec un statut « nouvelle », « en cours » ou « résolue ». Les alertes importantes arrivent sur mon téléphone via Telegram.
Ce que j'en retiens.
- Le moindre privilège se conçoit dès le départ : séparer la partie exposée de la partie privilégiée a structuré tout le projet.
- Détecter, c'est surtout trier : un serveur public reçoit du bruit en continu. Le travail consiste à classer par gravité, regrouper les doublons et ne notifier que ce qui compte.
- Connaître les limites de ses outils : en Wi-Fi, un IDS ne voit que le trafic de sa machine ; un HIDS ne protège pas d'un attaquant déjà root. Chaque module documente ses angles morts.
Pistes
- Brancher l'IDS sur un port miroir pour surveiller tout le réseau de la maison.
- Ajouter un pare-feu en liste blanche stricte et des listes de réputation d'adresses IP.
Compétences mobilisées
- MFA / TOTP
- Tailscale · WireGuard
- Suricata
- nftables
- SIEM & corrélation
- HIDS
- ARP · réseau
- Python
- Docker
- MITRE ATT&CK