On va être honnête deux secondes. Un SIEM, ça sonne souvent comme « gros budget », « gros projet », « gros tableau de bord qui fait peur ». Et pourtant, si votre besoin c’est surtout de centraliser des logs Linux, de les garder proprement, de chercher vite quand ça sent le cramé, et de poser deux ou trois alertes simples… on peut faire beaucoup avec très peu.
Dans cet article, je te montre une approche « SIEM léger » qui marche vraiment pour un petit parc (ou même un homelab sérieux), avec des briques open source, une VM modeste, et un peu de méthode. Pas un tunnel de 3 mois. Plutôt un truc que tu peux monter sur un week end, puis améliorer au fil de l’eau.
Petit clin d’œil aussi : si tu aimes ce genre de contenus SysAdmin et Linux pragmatiques, il y en a d’autres sur Le Blog Tech Pro de Samyn-Antoy ABASSE (https://monblog-sa-abasse.blogspot.com). Je publie aussi des ressources productivité et business en ligne, parce que bon, on vit rarement que de journalctl.
Pourquoi centraliser les logs Linux, même « petit budget »
Parce que le jour où tu as un incident, tu n’as pas envie de te connecter sur 7 machines, de faire des grep dans tous les sens, et de réaliser que l’une d’elles a tourné ses logs la veille.
Centraliser, ça te donne :
- une recherche unique : une seule barre de recherche, tous les serveurs
- une rétention cohérente : 7 jours, 30 jours, 90 jours… ce que tu décides
- une base d’alerting : SSH bruteforce, sudo suspect, erreurs Nginx, etc.
- un début de conformité : même si tu n’es pas « ISO », au moins tu archives
Et non, tu n’as pas besoin d’un monstre. Pour beaucoup de cas, un serveur 2 vCPU, 4 à 8 Go de RAM, et un disque correct, c’est déjà très acceptable si tu règles bien la rétention et l’indexation.
Pour t'aider à mieux gérer ces logs Linux et optimiser ton système, voici quelques articles utiles sur 25 commandes Linux qui sauvent en cas d'urgence ou encore sur comment obtenir une certification Linux en 2026. Ces ressources pourraient également t'intéresser si tu souhaites maîtriser Linux pour booster ta carrière ou monétiser tes compétences Linux. Si tu es également en train de choisir entre différents systèmes d
Ce qu’on veut faire exactement (le cahier des charges simple)
Un « SIEM léger », dans cet esprit, c’est :
- collecter journald et/ou /var/log/ (auth.log, syslog, nginx, etc.)
- centraliser sur 1 machine
- pouvoir chercher par hôte, service, utilisateur, IP, etc.
- avoir 2 ou 3 dashboards utiles
- déclencher quelques alertes basiques
On va éviter les usines à gaz. Mais on va rester sérieux, surtout sur la sécurité de la chaîne de logs.
Trois stacks possibles (et laquelle je recommande)
Tu as plusieurs chemins. Voilà les plus réalistes en 2026 pour du Linux à petit budget.
Option A : Loki + Promtail + Grafana (simple, efficace)
- stockage orienté logs, coûts raisonnables
- recherche correcte, surtout si tu structures un minimum
- Grafana pour dashboards et alertes
C’est souvent mon choix « budget + rapidité ». Par contre, Loki n’est pas un SIEM au sens strict. C’est une solution de logs, et tu peux construire une démarche SIEM légère dessus.
Option B : OpenSearch + Dashboards + Fluent Bit (plus SIEM-like)
- plus lourd, mais plus proche « Elastic style »
- plus puissant en recherche, agrégations, filtres
- peut coûter plus cher en RAM et disque
Si tu as plus de volume, ou besoin d’analyses plus poussées, c’est une bonne route. Mais pour « petit budget », ça peut être limite selon le matériel.
Option C : Wazuh (HIDS) + indexation (très sécurité)
Wazuh est excellent si tu veux du monitoring sécurité, conformité, détection. Ça peut devenir plus lourd aussi, mais si ton but principal est « sécurité » avant « observabilité », c'est pertinent.
Dans cet article, je pars sur Option A : Loki. Parce que c'est rapide à déployer, vraiment pas cher à faire tourner, et tu peux déjà faire énormément.
Architecture cible (très concrète)
Serveur central : logs01
- Grafana
- Loki
Sur chaque serveur Linux : Promtail (ou Fluent Bit, mais on reste simple)
- Lit journald et fichiers log
- Envoie vers Loki en HTTPS (ou réseau privé)
Tu peux héberger ce setup sur un VPS, une VM Proxmox, ou une petite machine dédiée.
Idéalement, le serveur de logs est sur un réseau auquel les machines peuvent parler en privé. Si tu passes par internet, chiffre et authentifie correctement, sinon c'est non.
Déploiement rapide sur le serveur central (Docker Compose)
Sur logs01, installe Docker et Docker Compose, puis crée un docker-compose.yml.
docker-compose.yml
yaml services: loki: image: grafana/loki:2.9.8 command: -config.file=/etc/loki/config.yml volumes: - ./loki-config.yml:/etc/loki/config.yml:ro - loki-data:/loki ports: - "3100:3100" restart: unless-stopped
grafana: image: grafana/grafana:11.1.0 environment: - GF_SECURITY_ADMIN_USER=admin - GF_SECURITY_ADMIN_PASSWORD=change-me-now volumes: - grafana-data:/var/lib/grafana ports: - "3000:3000" restart: unless-stopped depends_on: - loki
volumes: loki-data: grafana-data:
Pour gérer efficacement ces serveurs Linux et optimiser leur performance dans le cadre de ce projet, il pourrait être utile de suivre une roadmap pour devenir expert Linux freelance.
loki-config.yml (minimal, rétention simple)
yaml auth_enabled: false
server: http_listen_port: 3100
common: path_prefix: /loki storage: filesystem: chunks_directory: /loki/chunks rules_directory: /loki/rules replication_factor: 1 ring: instance_addr: 127.0.0.1 kvstore: store: inmemory
schema_config: configs: - from: 2024-01-01 store: tsdb object_store: filesystem schema: v13 index: prefix: index_ period: 24h
limits_config: retention_period: 168h
compactor: retention_enabled: true working_directory: /loki/compactor delete_request_store: filesystem
Tu lances :
bash docker compose up -d
Ensuite, les interfaces sont disponibles aux adresses suivantes :
- Grafana :
http://logs01:3000 - Loki :
http://logs01:3100
Dans Grafana, ajoute une source de données Loki (URL : http://loki:3100 si Grafana est dans le même compose).
Déploiement Promtail sur un serveur Linux (client)
Sur chaque serveur Linux, installe Promtail.
Si tu veux aller vite : binaire officiel ou package selon distrib. Sinon, tu peux aussi le dockeriser. Je te donne une config simple en mode service, en lisant journald + fichiers.
promtail-config.yml (journald + /var/log/auth.log)
yaml server: http_listen_port: 9080 grpc_listen_port: 0
positions: filename: /var/lib/promtail/positions.yaml
clients: url: http://logs01:3100/loki/api/v1/push
Job : journald
job_name: journald — Lit le journal systemd avec un max_age de 12h. Labels appliqués : job: journald, host: ${HOSTNAME}. Relabeling : la source __journal__systemd_unit est mappée vers le label unit.
Job : authlog
job_name: authlog — Lit le fichier de log d'authentification en statique depuis localhost. Labels appliqués : job: authlog, host: ${HOSTNAME}, path: /var/log/auth.log.
Tu adaptes le chemin du fichier selon ta distribution :
- Debian/Ubuntu :
auth.log - RHEL/CentOS/Rocky : souvent
/var/log/secure
Important : assure toi que Promtail a accès à journald. Souvent il faut l'ajouter au groupe systemd-journal.
Sécurité minimale (mais réelle)
Là, on ne rigole pas. Un serveur de logs, c’est une mine d’or.
À faire au minimum :
- firewall : seul
logs01reçoit 3100 depuis tes IPs serveurs - Grafana : mot de passe fort, idéalement SSO ou au moins 2FA si exposé
- si trafic sur réseau non sûr : TLS entre Promtail et Loki
- accès admin limité : pas tout le monde sur Grafana
Dans l’idéal, tu mets Loki derrière un reverse proxy (Nginx, Caddy) avec TLS et authentification. Oui, même si c’est « petit budget ».
Les dashboards utiles (sans se perdre)
Au début, ne fais pas 12 dashboards. Fais 3 vues.
Dashboard 1 : authentification et SSH
Requêtes Loki utiles (LogQL), par exemple :
- connexions SSH réussies : logql {job="authlog"} |= "Accepted password"
- bruteforce probable : logql {job="authlog"} |= "Failed password"
- tentatives sur utilisateurs inexistants : logql {job="authlog"} |= "Invalid user"
Dashboard 2 : sudo, escalade, commandes sensibles
logql {job="authlog"} |= "sudo:"
Tu peux filtrer par utilisateur :
logql {job="authlog"} |= "sudo:" |= "USER=deploy"
Dashboard 3 : erreurs applicatives (Nginx, systemd units)
Si tu collectes Nginx :
logql {job="nginx"} |= " 500 "
Ou côté journald :
logql {job="journald", unit="nginx.service"} |= "error"
Alertes simples qui valent de l’or
Grafana permet de créer des alertes sur des requêtes Loki. Tu peux démarrer avec 4 alertes.
- pic de « Failed password » sur 5 minutes
- détection de « Invalid user » répétée
- apparition de « sudo: session opened » pour un compte sensible
- erreurs 500 qui explosent sur une app
Exemple logique : alerte si plus de X échecs SSH en 5 minutes sur un hôte.
LogQL de comptage (à ajuster) :
logql sum by (host) (count_over_time({job="authlog"} |= "Failed password" [5m]))
Tu déclenches si > 20, par exemple.
Rétention et budget disque (le vrai nerf de la guerre)
Le piège classique : « je garde tout ». Puis disque plein. Puis Loki en PLS. Puis plus de logs au moment où tu en as besoin.
Quelques repères :
- petit parc (5 à 20 serveurs) : rétention 7 à 30 jours
- si tu veux 90 jours : compresse, filtre, et dimensionne le disque
- logs applicatifs verbeux : à limiter à la source
Astuce simple : commence avec 7 jours. Puis augmente quand tu connais ton volume réel.
Un truc souvent oublié : normaliser un minimum
Un SIEM, même léger, devient utile quand tu peux filtrer proprement. Donc :
- ajoute le label
host - ajoute
jobpar type de log - récupère
unitsystemd - pour Nginx, ajoute un format log plus structuré si possible (JSON)
Ce n’est pas sexy, mais ça change tout.
Par ailleurs, pour améliorer tes compétences en gestion des systèmes et optimiser l'utilisation des outils comme Grafana et Loki, il pourrait être bénéfique d'envisager certaines certifications Linux. Ces certifications peuvent vraiment booster ta carrière et te donner les compétences nécessaires pour gérer efficacement ton infrastructure IT.
Et si tu veux un cran plus « SIEM »
Deux évolutions très naturelles :
- ajouter fail2ban metrics et corrélation basique : tu vois les IP bannies et tu les retrouves dans les logs
- ajouter Wazuh sur les machines critiques : tu gardes Loki pour la centralisation, et Wazuh pour la détection endpoint
Oui, ça fait deux outils. Mais tu évites de forcer Loki à faire ce qu’il n’est pas.
Checklist de mise en prod (rapide)
logs01sauvegardé (au moins le volume Loki et Grafana)- firewall en place
- mot de passe Grafana changé, accès restreint
- rétention définie
- 3 dashboards créés
- 4 alertes configurées
- test incident : tu simules 10 échecs SSH et tu vérifies l’alerte
Conclusion
Un « SIEM léger » pour centraliser des logs Linux, c’est vraiment faisable sans exploser le budget. Et surtout, ça apporte vite de la valeur. Tu passes de « je crois que ça s’est passé hier » à « je vois exactement l’IP, l’heure, l’hôte, et le service ».
Si tu veux approfondir tes connaissances sur les distributions Linux à suivre ou envisager une carrière en tant que consultant Linux freelance, n'hésite pas à consulter mes articles. Je couvre également les certifications Linux essentielles et fais une comparaison approfondie entre Linux et Windows.
Et si tu lis ça sur mon site, pense à faire un tour sur Le Blog Tech Pro de Samyn-Antoy ABASSE (https://monblog-sa-abasse.blogspot.com) : j’y poste aussi des articles orientés productivité, SEO, et travail à distance, en plus des sujets Linux. Parce que oui, on peut aimer les logs et aimer optimiser son business. Les deux vont bien ensemble.
Questions fréquemment posées
Pourquoi centraliser les logs Linux même avec un petit budget ?
Centraliser les logs Linux permet d'avoir une recherche unique sur tous les serveurs, une rétention cohérente des données, une base pour déclencher des alertes simples (comme SSH bruteforce ou erreurs Nginx) et un début de conformité en archivant les logs, tout cela sans nécessiter un investissement massif.
Qu'est-ce qu'un SIEM léger adapté à un petit parc ou homelab ?
Un SIEM léger se concentre sur la collecte des logs journald et /var/log/, la centralisation sur une seule machine modeste, la possibilité de rechercher par hôte, service ou utilisateur, quelques dashboards utiles et le déclenchement d'alertes basiques, tout en évitant les solutions complexes et coûteuses.
Quelles sont les ressources matérielles recommandées pour un SIEM léger ?
Pour un SIEM léger efficace, un serveur avec 2 vCPU, 4 à 8 Go de RAM et un disque performant suffit largement si la rétention et l'indexation des logs sont bien réglées.
Quels sont les avantages d'utiliser Loki + Promtail + Grafana pour la gestion des logs ?
Cette stack est simple, efficace et économique. Loki offre un stockage orienté logs avec des coûts raisonnables, une recherche correcte si les logs sont bien structurés, tandis que Grafana permet de créer des dashboards personnalisés et de configurer des alertes facilement.
Quand opter pour OpenSearch + Dashboards + Fluent Bit dans une solution SIEM ?
Cette option est plus lourde mais plus proche du style Elastic. Elle offre des capacités avancées de recherche, d'agrégation et de filtrage. Elle est recommandée si vous avez un volume important de logs ou besoin d'analyses poussées, mais peut être trop gourmande en ressources pour un petit budget.
Où trouver plus de contenus pratiques sur l'administration système Linux et la productivité ?
Vous pouvez consulter Le Blog Tech Pro de Samyn-Antoy ABASSE (https://monblog-sa-abasse.blogspot.com) qui propose des articles pragmatiques sur SysAdmin Linux, ainsi que des ressources sur la productivité et le business en ligne adaptées aux professionnels IT.
0 Commentaires