AccueilTechniqueStockage → Syslog-ng

    Syslog-ng

    Fonctionnement🔗

    Le logiciel syslog-ng permet d’envoyer et recevoir des journaux par le réseau. Nous l’utilisons notamment pour réceptionner et centraliser les journaux d’accès à nos services, que nous utilisons à des fins de statistiques et de sécurité.

    Historique🔗

    La mise en place de ce service remonte au 7 mars 2022. Lors du déploiement de l’infrastructure V2, lorsque nous commencions à envisager de faire fonctionner des services sur différents serveurs en parallèle (plutôt que sur un seul serveur « monolithique »), nous avons recherché différents moyens de centraliser les journaux sur une seule machine pour faciliter leur traitement par la suite. Nous avons choisi syslog-ng plutôt que rsyslog pour sa syntaxe plus lisible et sa documentation assez fournie (bien qu’elle soit assez « fouillis » également).

    Installation🔗

    Nous utilisons notre propre image pour ce service, basée sur une image Debian. Notre Dockerfile est disponible sur le dépôt Core.

    Notre instance de syslog-ng reçoit des journaux de trois sources distinctes, séparées sur trois ports différents :

    • Les hôtes de chacun de nos serveurs, qui transitent leur syslog ou d’autres informations spécifiques comme les journaux d’exécution de nfs-sync (généralement à travers l’instance rsyslog de chaque serveur installée par défaut) ;
    • Les dæmons Docker de chaque serveur qui transmettent les journaux de certains services ;
    • Nos reverse-proxies répartis sur nos différents serveurs.

    Ces journaux sont ensuite transmis au service Matomo et enregistrés dans un volume et lus par fail2ban. Une routine utilise le programme logrotate pour faire tourner les fichiers journal chaque semaine.

    Une rotation des journaux doit etre suivie d’un rechargement du dæmon syslog-ng, par exemple en lui envoyant le signal SIGHUP dans son conteneur :

    kill -HUP `cat /var/lib/syslog-ng/syslog-ng.pid`
    

    Tests🔗

    La meilleure façon de tester si les journaux sont bien enregistrés est de paramétrer un reverse-proxy pour écrire des journaux avec et de vérifier si les journaux sont bien enregistrés dans le volume de syslog-ng.

    Pour nginx :

    access_log syslog:server=IP_DE_LA_MACHINE_SYSLOG:PORT,facility=local7,tag=NOM_DU_SERVICE,severity=info main;
    

    Pour Caddy : consultez la documentation du plugin transform-encoder.

    Pour vérifier si les journaux sont bien enregistrés dans le volume en continu : tail -f NOM_DU_FICHIER_JOURNAL.log.

    Consommation de ressources🔗

    Le logiciel syslog-ng consomme relativement peu de ressources : en production, il consomme environ 200 MB de RAM et très peu de CPU, pour environ 20 GB de journaux transités par semaine.

    Précautions🔗

    Sécurité du transit🔗

    Par défaut, syslog-ng utilise le port UDP 514 pour recevoir les journaux. Cette transmission n’est ni chiffrée (et peut donc être interceptée par les conteneurs ou machines dans le même réseau) ni authentifiée, ce qui permettrait à un programme tiers qui accèderait à ce port d’envoyer de faux journaux.

    Il est possible d’utiliser TCP+TLS en spécifiant un certificat dans la configuration pour sécuriser le transfert de ces données.

    Utilisation de TCP🔗

    Si vous choisissez TCP pour envoyer les journaux sur la machine de stockage, les logiciels qui envoient ces journaux − dont le reverse-proxy − pourraient cesser de fonctionner correctement si la machine de stockage (ou le dæmon syslog-ng) devient inaccessible.

    UDP a l’avantage de ne pas envoyer d’accusé de réception des requêtes : si syslog-ng est inaccessible, les programmes qui l’utilisent enverront simplement des journaux dans le vide et cela n’aura pas de conséquence sur leur fonctionnement.

    Rotation des journaux🔗

    Le logiciel syslog-ng n’effectue pas de rotation ou de suppression des journaux ; il existe logrotate (installé par défaut sur Debian) pour cet usage, qu’il convient d’utiliser conjointement à syslog-ng pour éviter une saturation de l’espace disque.

    Entretien🔗

    Au-delà de la mise en place de logrotate (et de la vérification de son fonctionnement), syslog-ng fonctionne de manière relativement autonome. L’utilisation d’un tail -f sur les journaux de temps à autre permet de vérifier le flux des requêtes et de s’assurer qu’elles relèvent d’un usage légitime du service.

    Mise à jour🔗

    S’agissant d’une image Docker « maison » à partir d’une image Debian, la mise à jour de syslog-ng s’effectue avec la commande docker build --no-cache (ou manager build syslog-ng --no-cache avec le dépôt Core) pour forcer la reconstruction de l’image, et notamment l’exécution de la commande apt update dans l’image.

    Le script import_logs.py en provenance des dépôts de Matomo doit être également mis à jour et utiliser une version du script compatible avec la version du service Matomo en production.