Protégez votre serveur. Toutes les attaques et modifications dans un seul tableau de bord.

Fail2ban lit les journaux des services et bannit les adresses qui échouent à l'authentification. Le tableau de bord affiche toutes les jails sur un seul écran : combien d'adresses sont bloquées actuellement, combien depuis le démarrage du service et quelle jail les a interceptées. Une jail qui n'a rien intercepté du tout est aussi visible qu'une jail active — le plus souvent, cela signifie qu'elle lit le mauvais fichier journal.

IPSUM — liste d'adresses mise à jour quotidiennement, repérées lors d'attaques contre d'autres serveurs. Ipset la garde en mémoire du noyau : vérifier des centaines de milliers d'adresses ne charge donc pas le pare-feu. Le panneau affiche la taille de la liste et l'heure de la dernière mise à jour : c'est une protection dès la première tentative — l'adresse est bloquée avant même d'atteindre le service.

Lynis exécute des centaines de vérifications de configuration et produit un hardening index — une note sur 100. Le tableau de bord analyse le rapport et affiche avertissements et recommandations avec l'identifiant du test, pour comprendre la signification de chacun. 100 sur 100 n'est pas un objectif : certaines recommandations visent des scénarios absents de votre serveur.

ModSecurity avec le jeu de règles OWASP CRS filtre les requêtes HTTP à l'intérieur du serveur web — après le déchiffrement, là où le contenu de la requête est visible. Le panneau lit le journal d'audit : quelle requête a été bloquée, quelle règle s'est déclenchée, quel était le score d'anomalie et d'où provenait la requête. On le consulte avant tout pour les faux positifs : une même règle qui intercepte encore et encore votre propre formulaire.

Suricata analyse le trafic réseau selon des signatures et écrit ses détections dans eve.json. Le panneau lit ce fichier directement sur le serveur et affiche les alertes des dernières 24 h, regroupées par catégorie — sans Elasticsearch ni Kibana, qui, sur un seul VPS, pèsent plus lourd que la machine surveillée. Une installation neuve reste muette tant que suricata-update n'a pas tourné au moins une fois : elle ne contient encore aucune règle.

CrowdSec analyse les journaux selon des scénarios et prend des décisions de blocage en s'appuyant aussi sur les adresses signalées par les autres membres du réseau — l'attaquant arrive souvent déjà connu. Le panneau affiche les décisions actives avec leur scénario et le temps restant, et à côté les bouncers enregistrés qui appliquent ces décisions. Si la seconde liste est vide, CrowdSec se contente d'alerter sans rien bloquer.

Falco surveille les appels système et déclenche une alerte quand un processus fait ce qui ne le regarde pas : il lance un shell depuis le serveur web, écrit dans le répertoire des binaires système, ouvre une connexion sortante inattendue. Le tableau de bord affiche les alertes avec leur priorité, la règle déclenchée et la ligne de commande du processus. Kubernetes n'est pas requis — sur un serveur ordinaire, Falco fonctionne de la même façon.

Sur Linux, l'antivirus ne protège pas ses propres binaires, mais ce qui arrive sur le serveur depuis l'extérieur : web-shells via un formulaire d'envoi, pièces jointes via le serveur de messagerie, charges utiles dans les répertoires temporaires. Le tableau de bord affiche l'heure de la dernière analyse, ce qu'elle a trouvé et — champ crucial — l'âge de la base de signatures. Avec des signatures vieilles d'une semaine, ClamAV crée une illusion de protection et rien de plus.

AIDE prend une empreinte cryptographique du système de fichiers et signale ce qui a changé depuis la dernière vérification — il répond à la question que les autres outils esquivent : à quoi ont-ils touché. Le panneau affiche trois listes : fichiers ajoutés, modifiés et supprimés, ainsi que les attributs divergents. Le rapport matinal le plus fréquent s'explique par les mises à jour de paquets nocturnes — vérifiez l'heure et reconstruisez la base.

Le démon d'audit consigne exactement les événements demandés : modifications de /etc/passwd et /etc/shadow, changements dans sshd_config, exécution de binaires d'élévation de privilèges. Le panneau affiche les règles actuellement chargées, les chemins surveillés et les événements récents avec leur processus et leur résultat. Voir les règles importe autant que les événements : un ensemble vide est la cause la plus fréquente d'un auditd qui semble fonctionner sans rien consigner d'utile.

UFW évite la syntaxe d'iptables, mais ne vous aide pas à relire un jeu de règles des mois plus tard. Le tableau de bord affiche chaque règle avec son action, son port, son protocole et sa source, et met en avant les politiques par défaut pour le trafic entrant et sortant — celles qu'on oublie justement. Un jeu de règles d'apparence stricte ne veut rien dire si la politique par défaut est restée sur allow.

Celui qui balaie les ports ne laisse aucune tentative de connexion échouée : Fail2ban ne le voit donc pas. PSAD comble cette lacune : il lit les entrées du pare-feu sur le trafic rejeté et évalue les résultats. Le tableau de bord affiche les adresses signalées, le niveau de danger de 1 à 5, le nombre de paquets et les ports. Sans règle de journalisation dans le pare-feu, PSAD reste muet — c'est la cause habituelle d'une page vide après l'installation.

Le renouvellement automatique a résolu l'essentiel du problème tout en en créant une version plus silencieuse : les certificats se renouvellent d'eux-mêmes — jusqu'au jour où ils cessent de le faire, et c'est le visiteur qui le découvre en premier. Le tableau de bord liste les certificats servis par le serveur : émetteur, date d'expiration, jours restants. Moins de trente jours sur un certificat à renouvellement automatique signifie que le renouvellement échoue déjà en silence depuis quelque temps.

La carte affiche les adresses bloquées par votre propre serveur, résolues au niveau des pays et dimensionnées selon le nombre de coups. Ce n'est pas un flux de données sur les menaces acheté ailleurs : chaque point représente un trafic parvenu jusqu'à cette machine. La carte devient utile dans la durée : une concentration issue d'un même réseau signale en général un acteur unique parcourant une liste, tandis qu'une dispersion régulière traduit le bruit habituel d'Internet.

Logwatch condense les journaux d'une journée en un seul rapport et l'envoie par courriel — où, deux semaines plus tard, il finit dans un dossier que personne ne consulte. Le problème n'a jamais été l'information, mais sa distribution. Le tableau de bord conserve les rapports sur le serveur et les affiche page par page, avec l'archive des jours précédents : un jour indique ce qui s'est passé, une semaine ce qui a changé.

Monit surveille les processus, fichiers, systèmes de fichiers et hôtes, et redémarre ce qu'il trouve défaillant. Le tableau de bord affiche chaque vérification avec son état actuel, l'objet surveillé et le nombre d'interventions. Le compteur de redémarrages est le champ le plus révélateur : un service redémarré quarante fois n'est pas sain, il tombe en panne encore et encore, et les redémarrages ne font que le masquer.

Connexion au panneau par clé matérielle, Touch ID ou Face ID au lieu d'un second mot de passe. La clé valide le domaine au niveau du protocole : une copie de la page de connexion sur une adresse similaire ne fonctionnera donc pas — le phishing n'a rien à intercepter. Vous pouvez enregistrer plusieurs clés, chacune avec son nom et sa date de dernière utilisation, et révoquer chacune d'elles individuellement.

Ce qui, sur cette machine, est accessible depuis l'extérieur reste la question de sécurité la plus utile, et la sortie de ss doit être relue à l'œil à chaque fois. Le panneau affiche les sockets en écoute avec leur port, leur protocole, leur adresse de liaison et leur processus, puis, en dessous, les connexions établies. Lisez d'abord l'adresse de liaison : un service sur 127.0.0.1 n'est accessible que depuis la machine elle-même, alors que le même service sur 0.0.0.0 l'est pour tout l'internet.

Top répond à la question de la seconde présente, alors qu'on s'interroge généralement sur la nuit passée. Toutes les cinq minutes, le collecteur ajoute une ligne à la base, et la page en trace les dernières 24 heures : load average, CPU et I/O wait séparément, mémoire et swap, réseau, disque, connexions TCP, descripteurs de fichiers. Les graphiques se lisent par paires : un I/O wait élevé avec un CPU au repos signifie que le serveur attend le disque, et ajouter des cœurs n'y changera rien.

Il existe deux catégories de problèmes de disque, bien distinctes : un support de stockage qui commence à défaillir, et un système de fichiers qui se remplit et entraîne les services avec lui. Le tableau de bord couvre les deux : occupation des partitions, attributs SMART et température. Trois attributs annoncent une défaillance : secteurs réalloués, secteurs en attente et secteurs irrécupérables hors ligne. Les inodes sont affichés séparément : ils s'épuisent avant l'espace libre et expliquent les écritures qui échouent alors que le disque dispose encore d'espace.

Le contrôle d'accès obligatoire décide de ce qui est permis à un programme, indépendamment des droits de l'utilisateur qui l'a lancé. AppArmor est présent sur la plupart des serveurs Ubuntu et Debian et, sur beaucoup d'entre eux, ne restreint presque rien. Le tableau de bord affiche les profils chargés avec leur mode, les processus sous restriction et — la moitié la plus intéressante — les processus sans aucun profil. Un profil en mode complain se contente d'enregistrer ce qu'il bloquerait ; seul enforce restreint réellement.