Une note de Zima
Merci, Jacko888888, de créer des outils qui aident les utilisateurs de ZimaOS à comprendre ce qui se passe réellement dans leurs systèmes. Des diagnostics fondés sur les faits avec ZimaBrain CE à l’analyse contrôlée des logiciels malveillants avec ClamAV, en passant par la surveillance des terminaux avec Wazuh, tes projets transforment sans cesse des couches système complexes en éléments que chacun peut examiner, questionner et exploiter avec davantage de discernement.
Nous apprécions tout particulièrement de voir ces idées se développer au fil de dépannages concrets, de tests et des retours de la communauté. Elles nous rappellent que rendre un serveur personnel plus facile à utiliser ne consiste pas seulement à ajouter davantage de fonctionnalités — il s’agit parfois simplement de rendre le système plus facile à comprendre.
— Zima
Découvrez Jacko88888
Jacko88888 crée et documente des outils pratiques pour ZimaOS, en se concentrant souvent sur une question récurrente : comment aider les utilisateurs de serveurs personnels à comprendre ce qui se passe réellement dans leur système ?
Ses projets publics abordent cette question sous plusieurs angles. ZimaBrain CE explore le diagnostic local fondé sur les faits. Le tableau de bord de sécurité ClamAV facilite l’inspection et le contrôle de l’analyse des logiciels malveillants et de leur mise en quarantaine. Et Wazuh sur ZimaOS intègre la surveillance des terminaux, l’état des agents et les alertes de sécurité.
Ce sont des projets différents, mais ils s’inscrivent dans une direction étonnamment cohérente : diagnostiquer ce qui se passe, rendre l’activité de sécurité visible et fournir à la personne qui gère le serveur suffisamment d’éléments pour décider de la suite.
Créer un assistant de diagnostic local pour ZimaOS
L’un des projets ZimaOS les plus ambitieux de Jacko88888 est ZimaBrain CE, un assistant de diagnostic local fondé sur un principe simple : vérifier les faits avant de suggérer ce qui pourrait être en cause.
Les problèmes liés aux serveurs domestiques concernent rarement une seule couche. Un avertissement de stockage peut impliquer les données SMART, les systèmes de fichiers, les points de montage ou le matériel. Une application qui ne s’ouvre pas peut en réalité fonctionner correctement, tandis que son port, sa règle de pare-feu ou son exposition réseau constitue le véritable problème. L’état de Docker, les services en échec, l’état des disques et la configuration de ZimaOS peuvent tous se chevaucher.
ZimaBrain CE a été conçu pour rendre ce processus de dépannage plus structuré. Plutôt que de partir d’une hypothèse et de recommander immédiatement une solution, il recueille des preuves auprès de l’hôte ZimaOS et tente d’établir ce qui peut réellement être vérifié.
Cela signifie qu’il faut aller au-delà des simples états de niveau supérieur. Les diagnostics des disques peuvent prendre en compte des éléments SMART tels que les secteurs en attente ou incorrigibles, les compteurs CRC, les délais d’expiration des commandes et les informations relatives aux arrêts non sécurisés des disques NVMe. D’autres couches de diagnostic peuvent examiner l’état de Docker, les ports publiés, la configuration du pare-feu, les services en échec, les points de montage, les chemins AppData et d’autres signaux de l’hôte.
Vérifié, partiellement vérifié ou pas encore démontré
Un aspect important de ZimaBrain CE est qu’il ne cherche pas à donner à toutes ses réponses le même degré de certitude.
Le projet distingue les conclusions qui peuvent être vérifiées à partir des preuves disponibles, les résultats qui ne sont que partiellement vérifiés et les recommandations pour les situations où le système ne peut pas encore démontrer suffisamment d’éléments en toute sécurité.
Cette distinction est importante lors du dépannage d’un serveur auto-hébergé. Les conseils concernant les disques, les systèmes de fichiers, les conteneurs, les règles de pare-feu ou les services système peuvent rapidement devenir destructeurs si le diagnostic initial est erroné. Une approche fondée d’abord sur la vérification place délibérément les preuves avant l’action.
Le projet peut également générer un rapport d’assistance expurgé, permettant aux utilisateurs de partager des informations de diagnostic utiles lorsqu’ils demandent de l’aide, sans publier simplement toutes les données brutes du système.
Conçu autour de l’hôte ZimaOS
ZimaBrain CE est conçu pour fonctionner localement comme une application personnalisée ZimaOS. Son rôle de diagnostic dépend de sa capacité à examiner certaines informations sélectionnées de l’hôte, notamment l’état du système et les informations Docker, plutôt que de s’appuyer uniquement sur les détails saisis manuellement par l’utilisateur.
C’est ce qui distingue le projet d’un chatbot générique de dépannage. L’intérêt ne réside pas simplement dans la production d’une réponse, mais dans le fait de relier cette réponse aux preuves issues du système ZimaOS analysé.
Évoluer grâce aux retours de la communauté
ZimaBrain CE montre également comment les logiciels communautaires peuvent évoluer grâce à la collaboration. Jacko remercie Holger / Lintux pour son aide dans l’élaboration d’idées autour des diagnostics privilégiant le vérificateur, des niveaux de preuve, de la sensibilisation à la sécurité, des vérifications du pare-feu, de l’interprétation de SMART et de flux de diagnostic plus sûrs.
Les utilisateurs de ZimaOS ont poursuivi ce processus en testant le projet sur leurs propres systèmes et en signalant les cas où une réponse était utile, ceux où elle restait trop technique et ceux où le vérificateur avait besoin de davantage de preuves avant de tirer une conclusion.
Cela fait de ZimaBrain CE bien plus qu’un simple utilitaire posé au-dessus de ZimaOS. Il s’agit d’une expérience visant à rendre le dépannage des serveurs domestiques plus compréhensible : montrer ce que le système peut vérifier, indiquer ce qui reste incertain et éviter de transformer un diagnostic incertain en action dangereuse.
Transformer ClamAV en tableau de bord de sécurité pour ZimaOS
Avec le tableau de bord de sécurité ClamAV, Jacko s’appuie sur le moteur d’analyse des logiciels malveillants ClamAV et construit autour de lui un flux de travail ZimaOS plus réfléchi.
Le projet commence par le stockage plutôt que par la ligne de commande. Il détecte les disques et les dossiers de ZimaOS, permet à l’utilisateur d’approuver explicitement les emplacements à analyser et tient les emplacements sensibles des applications et du système à l’écart des analyses effectuées à la légère.
Une fois l’analyse lancée, le tableau de bord rend le processus visible. Au lieu d’attendre simplement la fin d’une tâche en arrière-plan, l’utilisateur peut suivre des informations telles que le fichier actuel, la quantité de données déjà analysée, les données restantes, la vitesse d’analyse, le temps écoulé et le temps restant estimé.
Cette visibilité est bien plus importante sur un NAS que dans un petit dossier local. Un serveur domestique peut contenir des photos, des sauvegardes, des téléchargements, des bibliothèques multimédias, des données d’applications et plusieurs téraoctets d’autres fichiers. Savoir ce qui est analysé — et ce qui ne l’est pas — devient un élément essentiel pour comprendre l’état de sécurité du système.
Séparer la détection de la remédiation
L’un des aspects les plus réfléchis du flux de travail ClamAV de Jacko est ce que le scanner ne fait pas automatiquement. Une analyse normale ne modifie pas les fichiers, et la détection d’un fichier suspect ne l’efface pas immédiatement.
Au contraire, la détection et la remédiation restent des actions distinctes. Lorsque ClamAV identifie une menace, le tableau de bord peut afficher le chemin du fichier et la signature de détection. Le déplacement de ce fichier en quarantaine nécessite une autre action confirmée de l’utilisateur.
Une fois un fichier placé en quarantaine, l’application enregistre notamment des informations telles que son emplacement d’origine, sa taille, la signature du logiciel malveillant et son condensat SHA-256. Si le fichier est ensuite restauré, ces informations enregistrées peuvent être vérifiées avant qu’il ne soit renvoyé à son emplacement d’origine.
La suppression définitive constitue à nouveau une décision distincte. Le résultat est un processus de sécurité où l’analyse, la vérification, la mise en quarantaine, la restauration et la suppression restent des actions visibles plutôt que de devenir une chaîne automatisée irréversible.
Tester l’ensemble du cycle de vie d’une menace
Jacko a également documenté une validation de bout en bout du processus à l’aide du fichier de test antivirus inoffensif EICAR.
Le test a suivi le cycle de vie depuis la détection jusqu’à la mise en quarantaine, en enregistrant le chemin d’origine du fichier et son condensat SHA-256, puis en le restaurant, en le plaçant de nouveau en quarantaine et, enfin, en le supprimant définitivement.
L’aspect intéressant n’est pas simplement que ClamAV a détecté le fichier de test. Jacko a également réfléchi à ce qui se passe avant et après la détection — l’aspect de la gestion antivirus qui compte lorsque les fichiers protégés vous appartiennent réellement.
Intégrer la surveillance de sécurité Wazuh à ZimaOS
Le guide de Jacko sur Wazuh sur ZimaOS aborde la sécurité sous un autre angle. Plutôt que de se concentrer sur des fichiers individuels, il explique comment intégrer le modèle de surveillance des points de terminaison de Wazuh dans un environnement Docker ZimaOS.
Le projet suit les étapes concrètes nécessaires pour faire fonctionner cet environnement : vérifier le gestionnaire Wazuh, résoudre les problèmes d’inscription via 1515/TCP, en connectant l’agent au réseau Docker du gestionnaire, en inscrivant un agent dédié zimaos-docker-agent, et maintenir le canal de communication continu entre l’agent et le gestionnaire via 1514/TCP.
Comme pour le projet ClamAV, l’objectif final n’est pas simplement d’exécuter un conteneur supplémentaire. L’état du système de sécurité doit être visible. Le bon fonctionnement de l’agent peut être confirmé dans l’interface Wazuh, puis les événements de sécurité associés à ce point de terminaison surveillé peuvent être consultés depuis le tableau de bord.
Rendre le système plus facile à comprendre
ZimaBrain CE, le tableau de bord de sécurité ClamAV et Wazuh répondent à des problèmes très différents, mais l’approche de Jacko présente un fil conducteur commun.
ZimaBrain se demande ce qui peut réellement être vérifié avant de présenter une conclusion de diagnostic. ClamAV transforme l’analyse et la remédiation des logiciels malveillants en une suite de décisions visibles. Wazuh fait de l’état des agents et des événements de sécurité des éléments que l’on peut vérifier plutôt que supposer.
Ce schéma est important dans l’auto-hébergement, car la personne qui stocke les fichiers est souvent aussi celle qui exécute les conteneurs, entretient le réseau, vérifie l’état des disques, consulte les alertes et décide si une solution proposée est sûre.
Dans cet environnement, un outil devient plus utile lorsqu’il fait plus que d’accomplir une tâche. Il doit également aider la personne qui gère le serveur à comprendre ce que le système sait, ce qu’il ne sait pas et ce qui va se passer ensuite.
Des outils différents, une même direction
Pris ensemble, les projets de Jacko interviennent à trois moments différents de la vie d’un système auto-hébergé.
ZimaBrain CE aide à diagnostiquer. Il s’appuie sur les éléments disponibles localement pour contribuer à expliquer les problèmes et les incertitudes du système.
Le tableau de bord de sécurité ClamAV aide à analyser et à intervenir. Il rend la détection des logiciels malveillants, la mise en quarantaine, la restauration et la suppression plus visibles et plus réfléchies.
Wazuh sur ZimaOS aide à surveiller. Il rassemble l’état des terminaux et les alertes de sécurité dans une interface où ils peuvent être examinés au fil du temps.
Diagnostiquer, analyser, surveiller — différentes couches d’un même objectif plus vaste : donner à la personne qui gère un serveur domestique une meilleure visibilité sur ce qui se passe réellement.
L’histoire est toujours en train de s’écrire
L’histoire de Jacko88888 et de Zima est toujours en train de s’écrire. ZimaBrain CE, le tableau de bord de sécurité ClamAV et Wazuh sur ZimaOS abordent déjà trois aspects différents de l’exploitation d’un système auto-hébergé, mais ensemble, ils renvoient à la même idée : les systèmes deviennent plus faciles à gérer lorsque les diagnostics, l’activité de sécurité et les éléments qui les étayent sont plus faciles à consulter.
À mesure que ces projets continuent d’évoluer — et que de nouvelles expérimentations apparaissent — cette page peut continuer à grandir avec eux. Si vous voulez voir ce que Jacko construira ensuite, suivez le travail de Jacko88888 en cours sur GitHub.
