Gestion des logs rsyslog Linux

Qu’est-ce que Syslog ?

Syslog est un protocole standardisé utilisé pour la gestion des journaux de manière centralisée dans les systèmes Unix et Linux. Il permet aux systèmes, applications et périphériques réseau de générer des messages de log et de les envoyer à un serveur central pour stockage et analyse. Syslog est crucial pour la surveillance de la sécurité, le dépannage, et la gestion des systèmes.

Il existe trois principales versions de Syslog, chacune offrant des fonctionnalités et des améliorations spécifiques :

1. Syslog : La version initiale du protocole, utilisée pour la collecte de logs basiques. Elle établit les fondements du système de journaux, mais reste limitée en termes de fonctionnalités avancées.
2. Syslog-ng : Une version améliorée de Syslog qui ajoute des capacités telles que le filtrage des logs basé sur le contenu, le support de la transmission via TCP pour plus de fiabilité, et le chiffrement TLS pour sécuriser les communications de logs.
3. Rsyslog : La version la plus récente et la plus largement utilisée. Rsyslog étend les fonctionnalités de Syslog-ng en offrant une meilleure performance, une prise en charge améliorée des protocoles réseau, et des options de configuration avancées. Rsyslog est aujourd’hui le choix de prédilection pour la plupart des administrateurs système.

Le modèle client/serveur de Rsyslog

Rsyslog fonctionne selon un modèle client/serveur. Par défaut, il gère les logs localement sur chaque machine, mais il peut être configuré pour centraliser les logs en envoyant ceux des clients vers un serveur Rsyslog central. Ce serveur devient alors un point unique de collecte et d’analyse des logs.

Classification des logs

Comment configurer rsyslog sous Linux pour une collecte efficace des logs ?

1. Installation de rsyslog

Sur la plupart des distributions Linux, rsyslog est déjà installé par défaut. Cependant, si ce n’est pas le cas, vous pouvez l’installer via le gestionnaire de paquets de votre distribution. Par exemple :

Sur Debian/Ubuntu :

sudo apt-get update sudo
apt-get install rsyslog 

Sur CentOS/RHEL :

sudo yum install rsyslog

Assurez-vous que le service rsyslog est activé et démarre automatiquement au démarrage du système :

sudo systemctl enable rsyslog  sudo systemctl start rsyslog

2. Configuration de base de rsyslog

Le fichier de configuration principal de rsyslog est situé à /etc/rsyslog.conf. Ce fichier contrôle les paramètres globaux et la manière dont les logs sont traités. Voici un aperçu des éléments clés à configurer :

2.1. Modules de rsyslog

Les modules permettent d’ajouter des fonctionnalités spécifiques à rsyslog. Par exemple, pour activer la réception de logs via UDP ou TCP, vous devez décommenter ou ajouter les lignes suivantes dans /etc/rsyslog.conf :

# Pour activer la réception des logs via UDP  module(load="imudp")  input(type="imudp" port="514")  # Pour activer la réception des logs via TCP  module(load="imtcp")  input(type="imtcp" port="514")

Ces directives permettent à rsyslog d’écouter sur le port 514 pour recevoir des logs envoyés par d’autres appareils via UDP ou TCP.

2.2. Formats de log

Vous pouvez configurer le format des logs dans /etc/rsyslog.conf. Par exemple, pour utiliser le format traditionnel ou un format plus détaillé comme JSON :

# Utilisation du format traditionnel  $ActionFileDefaultTemplate RSYSLOG_TraditionalFileFormat  # Ou, pour JSON  module(load="mmjsonparse")  template(name="jsonFormat" type="string" string="%TIMESTAMP:::date-rfc3339% %HOSTNAME% %APP-NAME% %PROCID% %MSGID% %STRUCTURED-DATA% %msg:::json%\n")

2.3. Règles de filtrage

Les règles de filtrage vous permettent de sélectionner les types de logs que vous souhaitez capturer et leur destination. Par exemple, pour envoyer les logs du système à un fichier spécifique :

# Envoyer les logs d'erreurs (niveau "error") du système dans un fichier dédié if $syslogseverity-text == 'error' then /var/log/system_errors.log

Vous pouvez également rediriger certains types de logs vers un serveur Syslog distant :

# Rediriger tous les logs vers un serveur distant  *.* @@192.168.1.100:514

Ici, @@ signifie que les logs seront envoyés via TCP (utilisez @ pour UDP), et 192.168.1.100:514 est l’adresse IP et le port du serveur Syslog.

3. Configurer la collecte de logs spécifiques

Supposons que vous souhaitiez centraliser les logs Apache pour une surveillance spécifique :

1. Créez un fichier de configuration dédié dans /etc/rsyslog.d/ (par exemple, apache.conf).
2. Ajoutez une configuration pour surveiller les logs Apache et les envoyer à un fichier spécifique :

# Surveiller les logs d'accès d'Apache  if $programname == 'apache2' then /var/log/apache2_access.log

3. Redémarrez le service rsyslog pour appliquer les changements :

sudo systemctl restart rsyslog

4. Configurer rsyslog pour un environnement distribué

Pour les environnements complexes où vous avez plusieurs serveurs, il est courant de configurer un serveur rsyslog centralisé qui recueille les logs de plusieurs clients.

• Côté serveur (centralisateur de logs) : Configurez le serveur pour recevoir les logs via UDP/TCP comme indiqué précédemment.
• Côté client (appareils envoyant des logs) : Modifiez le fichier /etc/rsyslog.conf pour diriger les logs vers le serveur central :

*.* @@logs.example.com:514

Interprétez et analysez les logs remontés

Une fois que vos logs sont collectés via rsyslog, il est important de savoir comment les interpréter pour identifier rapidement tout problème potentiel. Voici un cas basique d’analyse de logs :

Cas d’usage : Tentatives de connexion SSH échouées

Prenons l’exemple où vous souhaitez surveiller les tentatives de connexion SSH échouées sur votre serveur. Ces événements sont souvent un signe de tentatives d’intrusion, par exemple via une attaque par force brute.

Exemple de log :

Aug 22 14:01:23 server1 sshd[12345]: Failed password for invalid user root from 192.168.1.5 port 22 ssh2

Interprétation :

• Date et heure : Aug 22 14:01:23 indique le moment exact où l’événement s’est produit.
• Nom du serveur : server1 montre quel serveur a enregistré l’événement.
• Service : sshd fait référence au service SSH sur le serveur.
• Message : Failed password for invalid user root indique qu’une tentative de connexion avec le compte « root » a échoué.
• Adresse IP : 192.168.1.5 est l’adresse IP source de la tentative de connexion, utile pour identifier l’origine de l’attaque.

Analyse : Une série de logs similaires pourrait indiquer une tentative d’intrusion via une attaque par force brute. Si cette adresse IP apparaît de manière répétée avec des échecs de connexion, il pourrait être nécessaire de la bloquer via un pare-feu ou de renforcer la sécurité de votre serveur (par exemple, en désactivant l’accès root via SSH).

Action :

• Surveiller les tentatives : Utilisez des outils comme fail2ban pour bloquer automatiquement les adresses IP après un certain nombre de tentatives échouées.
• Investiguer davantage : Consultez les logs réseau pour voir si cette IP tente d’accéder à d’autres services sur le réseau.

Conclusion

En résumé, Syslog et ses évolutions, notamment Rsyslog, constituent des outils essentiels pour la gestion et l’analyse centralisées des journaux système. Grâce à Rsyslog, il est possible de configurer une infrastructure de logs robuste, adaptée aux besoins spécifiques de votre environnement, que ce soit pour la surveillance de la sécurité, le dépannage ou la gestion des performances. La compréhension des thématiques et des niveaux de log, ainsi que la configuration précise des règles de filtrage, permettent de tirer le meilleur parti des logs collectés, facilitant ainsi une gestion proactive de vos systèmes et réseaux. En fin de compte, maîtriser Rsyslog est un atout indispensable pour tout administrateur système souhaitant garantir la stabilité et la sécurité de son infrastructure informatique.