L'art de centraliser et d'exploiter les messages journaux (logs) de manière sécuritaire avec Syslog-NG & LogZilla By Elie MABO IT Security Professional CCNA, CCNA Sec., Security+ http://www.matael.info Février 2012 C'est quoi un message journal? Un message journal (log en anglais) est une information générée par un programme suite à un événement (erreur, warning, etc.) survenu. L'évènement peut être par exemple la suppression d'un répertoire. En fonction des types de programmes, les messages journaux sont stockés dans des fichiers spéciaux destinés à contenir ceux ci. La structure d'un message journal est découpée en trois grandes parties: Header: contient des informations sur la priorité, la version du protocole syslog, l'id du processus, etc. Structured-data: contient des méta informations telles que les adresses, le trafic, etc. MSG: contient le texte du message. Je n'entrerai pas plus dans les détails de la structure d'un message journal, car ce n'est pas l'objectif de cet article. Si vous souhaitez en savoir plus, référez vous au RFC 5424. Pourquoi centraliser les messages journaux? J'ai rédigé cet article avec une vision orientée plus vers des problématiques de sécurité dans un système d'information. Les messages journaux sont créés et stockés dans des fichiers appelés fichiers journaux, par des programmes. Ces messages sont gérés par une application de gestion des logs. Par défaut, les fichiers journaux sont stockés localement sur chacune des ressources. Cependant, en cas d'incident (attaque, panne, effets bizarres, etc.), il est important d'analyser ceux-ci afin de détecter les causes possibles de l'incident. Hors l'une des premières actions d'un bon pirate une fois introduit dans le système, c'est d'effacer rapidement les traces afin de rendre son identification difficile, voire impossible. Les messages journaux étant très importants non seulement pour la gestion proactive des incidents (pannes, problèmes, etc.), mais aussi pour l'audit sécurité (cas d'incident sécurité par exemple), il convient de mettre en place des mesures visant à les protéger. Une des mesures de protection passe par l'implémentation d'un système de centralisation des messages journaux vers un serveur. D'où cet article. Présentation de Syslog-NG Syslog-NG (Syslog New Generation) est une application permettant de gérer des messages journaux générés par des programmes suite aux évènements survenus. Il s'agit d'une implémentation Open Source du protocole syslog (normalisé par l'ietf, RFC 5424). Il permet d'enregistrer des informations sur des évènements (systèmes, réseaux, sécurités, applications, etc.) dans des fichiers spécifiques appelés des fichiers journaux. Syslog-NG permet également de centraliser des messages journaux au niveau d'un point unique du réseau (serveur de logs par exemple), ce qui allège et facilite les tâches de gestion des logs d'un ensemble de ressources systèmes, réseaux et sécurité. Syslog-NG est une alternative évoluée de «syslog», qui est le programme de gestion des logs retrouvé par défaut sur la plupart des ressources (serveurs Unix/Linux par exemple). Un article sur la sécurité informatique de Elie MABO, CCNA, CCNA Sec., Security+ (IT Security Professional) 1/7
Syslog-NG est développé aujourd'hui par la société Balabit IT Security Ltd, Fonctionnalités de Syslog-NG Par rapport à «syslog», syslog-ng offre en plus des fonctionnalités déjà offertes par syslog: la possibilité d'envoi et de réception des messages via le protocole TCP (très bien pour la fiabilité) le filtrage et la répartition des messages avec des expressions régulières (super pour la flexibilité) la possibilité de chiffrer les échanges de messages entre les ressources via le protocole TLS (très important d'un point de vue sécurité) la compatibilité avec IPv6 (génial pour l'avenir) la compatible avec les bases SQL (Mysql, PostgreSQL, Oracle, etc.) Architecture de Syslog-NG Syslog-NG peut fonctionner comme client (envoi des logs), comme serveur (réception des logs), comme relay (relayage des messages), ou à la fois comme client et serveur. Dans le cadre de la centralisation et de l'exploitation des messages journaux dans un contexte sécurité, son architecture peut être étendue avec l'intégration de certains modules ou composants. Vous pourriez par exemple avoir: une base de données pour le stockage des logs une interface Web pour l'exploitation facilitée des logs une PKI (Public Key Infrastructure) pour la gestion des certificats et clés un ou plusieurs serveurs un ou plusieurs clients Installation de syslog-ng L'installation de syslog-ng peut créer des conflits avec certains fichiers utilisés par d'autres programmes de logs déjà présents sur la machine. C'est le cas du fichier "/etc/logrotate.d/syslog" de «rsyslog». Si c'est le cas, déinstallez «rsyslog» avant d'installer «syslog-ng». Dans cet article, je me suis basé sur une installation faite sur deux machines linux (architecture CPU 64bits) utilisant la distribution Scientific Linux en version 6.1. En faisant un yum search syslog-ng, vous avez des paquets disponibles pour une installation via le gestionnaire de packages «yum». yum search syslog-ng output : syslog-ng-devel.x86_64 : Development files for syslog-ng eventlog.x86_64 : Syslog-ng v2 support library eventlog-devel.x86_64 : Syslog-ng v2 support library development files eventlog-static.x86_64 : Syslog-ng v2 support static library files : Next-generation syslog server Pour le fonctionnement de syslog-ng, vous avez besoin juste d'installer les packages syslog-ng.x86_64 et eventlog.x86_64 [Je vous recommande tout de même de mettre à jour vos systèmes avant l'installation de Syslog- NG. Un yum update fera l'affaire.] L'installation se fait à l'aide de la commande suivante: [root@sixfeet ~]# yum install syslog-ng.x86_64 Cette commande installe également le package «eventlog.x86_64» et les dépendances nécessaires. Configuration étape par étape de Syslog-NG Syslog-NG utilise plusieurs types d'objets à savoir: source, destination, log, parser, rewrite, template, etc. Dans cet article, j'aborde jusque quelques uns de ses objets. Le fichier de configuration de syslog-ng se Un article sur la sécurité informatique de Elie MABO, CCNA, CCNA Sec., Security+ (IT Security Professional) 2/7
trouve par défaut dans le répertoire «/etc/syslog-ng/» et se nomme «syslogng.conf». Il se compose de cinq (5) sections, à savoir: 1. Options globales de configuration 2. Sources 3. Filtres 4. Destinations 5. Routes (application des sources, filtres et destinations précédemment définis). Ainsi, la configuration de syslog-ng consiste à modifier les paramètres de chacune de ces sections. Elle peut se faire suivants les 5 étapes ci-après: Etape1: Définition des options globales de configuration Cette étape permet de configurer les paramètres globaux qui s'appliqueront à tous les autres niveaux de configuration de syslog-ng. Voici quelques exemples de paramètres globaux: use_dns(yes) use_fqdn(yes) keep_hostname(yes) log_msg_size(12345) Etape2: Définition des sources Cette étape permet de définir des sources de provenance des messages. Les messages proviennent des ressources (serveurs, firewalls, routeurs, etc.). La définition des sources se fait à l'aide du mot clé «source» et des drivers sources. Une source est identifiée par un nom et se compose d'un ou de plusieurs driver(s). Quelques exemples de drivers sources: unix-stream(): messages arrivant d'une socket unix internal(): messages générés pas syslog- NG tcp(): messages arrivant sur un port d'une interface réseau program(): messages générés par un programme file(): messages lus depuis un fichier Pour avoir la liste complète des drivers sources, consultez le guide d'administration de syslog-ng. Le lien est donné dans les références de cet article. Voici un exemple de définition d'une source: source svr_log_src { internal(); unix-stream("/dev/log/"); tcp(ip(0.0.0.0) port(5000) maxconnections(250)); L adresse IP 0.0.0.0 permet au serveur d'écouter sur toutes les interfaces réseaux opérationnelles. Etape3: Définition des filtres Cette étape permet de définir des filtres à appliquer sur des messages, afin d'exploiter uniquement les logs dont on a besoin. Les filtres permettent d'éviter des messages polluant, c'est à dire non utiles à la supervision des ressources. Il existe plusieurs types de filtres. Voici quelques uns: facility: permet de filtrer sur la base des parties du système qui envoient des messages (kernel par exemple) level: permet de filtrer à partir des niveaux d'importance (emergency, alert, critical, etc.) program: permet de filtrer à partir des programmes host: permet de filtrer à partir de l'adresse IP, d'un drapeau, d'un port d'une machine match: permet de filtrer à partir des motifs définis filter: permet d'appeler d'autres filtres et d'évaluer leurs valeurs netmask: permet de déterminer si l'adresse IP source fait bien partie d'un Un article sur la sécurité informatique de Elie MABO, CCNA, CCNA Sec., Security+ (IT Security Professional) 3/7
sous réseau IP Voici un exemple de définition d'un filtre : filter svr_log_filter1 { host("system" flags (ignorecase)) and level(warning); Etape4: Définition des destinations Cette étape permet de déterminer les destinations des messages. Dans le cadre de la centralisation des logs, les messages sont généralement destinés aux serveurs de centralisation. Ils peuvent être stockés dans des fichiers, des pipes, sur des sockets, etc. La définition des destinations se fait à l'aide du mot clé «destination» et des drivers destinations. Une destination est identifiée par un nom et se compose d'un ou de plusieurs driver(s). Quelques exemples de drivers destinations: file(): les messages sont écrits dans un fichier spécifique pipe(): les messages sont écrits dans un pipe spécifié sql(): les messages sont envoyés dans une base de données SQL usertty(): les messages sont envoyés sur le terminal d'un utilisateur spécifié Pour avoir la liste complète des drivers destinations, consultez le guide d'administration de syslog-ng. Le lien est donné dans les références de cet article. Voici un exemple de définition d'une destination: destination svr_log_dst { file("/var/log/messages " ); template("$date <$FACILITY.$PRIORITY> $HOST $MSGHDR $MSG\n") La déclaration «template» permet de définir le format d'affichage des messages. Les paramètres d'un template utilisent des macros. Etape5: Création des routes Cette étape permet de connecter des sources aux destinations précédemment définies. La création des routes se fait à l'aide du mot clé «log». Voici un exemple de création d'une route connectant une source et une destination: log svr_sphinx_log { source (svr_log_src); filter( svr_log_filter1); destination (svr_log_dst); Configuration des autres postes pour l'envoi des logs vers le serveur de logs -> Cas avec «syslogd» Sur chacun des postes depuis lequel vous souhaitez envoyé des logs vers le serveur de logs, suivez les étapes suivantes: - Editez le fichier «/etc/sysconfig/syslog» [root@sixfeet ~]# vim /etc/sysconfig/syslog - Ajoutez l'option «-r». Ainsi, la ligne SYSLOGD_OPTIONS="-m 0 " devient: SYSLOGD_OPTIONS="-m 0 -r" - Editez le fichier «/etc/syslog.conf» [root@sixfeet ~]# vim /etc/syslog.conf - Ajoutez la ligne suivante: *.* @sixfeet.lix.polytechnique.fr - Redémarrez le démon «syslogd» [root@sixfeet ~]# service syslodg restart Notez ici que les messages seront envoyés en clair sur le réseau, ce qui n'est pas conseillé en matière de sécurité réseau. Je vous recommande à cet effet d'installer «syslog-ng» sur les postes clients afin d'exploiter les fonctionnalités de chiffrement des échanges via le protocole TLS. Un article sur la sécurité informatique de Elie MABO, CCNA, CCNA Sec., Security+ (IT Security Professional) 4/7
-> Cas des stations Windows Pour les postes Windows, vous avez la possibilité d'installer des agents syslog-ng pour Windows. Une fois l'installation faite, vous devez configurer l'agent de manière à ce qu'il puisse envoyer des messages journaux vers le serveur de centralisation des messages. La configuration de syslog-ng sur des postes Windows ne fait pas partie des objectifs de cet article. Sécurisation des échanges de messages entre les machines via TLS Syslog-NG permet de sécuriser les échanges de messages journaux entre les différentes ressources réseaux. Il s'appuie sur le protocole TLS (Transport Layer Security) pour chiffrer les communications et authentifier les deux parties impliquées. Cela permet de garantir la confidentialité et l'authenticité des messages journaux échangés. Le schéma ci après présente les étapes préliminaires entre le serveur et le client: Source: The syslog-ng Administrator Guide Ce qu'il faut remarquer dans ce schéma, c'est l'authentification mutuelle entre le serveur et le client (pas obligatoire). Création du certificat et de la clé du serveur (sixfeet) Nous allons créer et utiliser un certificat (format X.509) côté serveur pour le chiffrement des échanges de logs et l'authentification du serveur. La distribution Scientific Linux, tout comme d'autres distributions Linux comprennent généralement une PKI installée et prête à l'utilisation. Suivez les étapes suivantes pour créer le certificat et les clés du serveur et ensuite configurer «syslog-ng» pour prendre en compte le chiffrement des communications et l'authentification du serveur. Sur le serveur (sixfeet) Etape1: En tant que root, accédez au répertoire «certs» [root@sixfeet ~]# cd /etc/pki/tls/certs/ Etape2: Utilisez la commande «make» pour créer le fichier «.pem» du serveur [root@sixfeet certs]# make syslog-ng.pem Cette étape est interactive. Ce qui veut dire que vous devez répondre aux questions posées lors de celle-ci. Etape3: Créez deux répertoires «cert.d» et «key.d» dans le répertoire «/opt/syslogng/etc» [root@sixfeet certs]# mkdir /opt/syslogng/etc/cert.d [root@sixfeet certs]# mkdir /opt/syslogng/etc/key.d Etape4: Duppiquez le fichier «syslog-ng.pem» en «syslog-ng.cert» et «syslog-ng.key» [root@sixfeet certs]# cp syslog-ng.pem syslog-ng.cert [root@sixfeet certs]# cp syslog-ng.pem syslog-ng.key Etape5: Editez le fichier «syslog-ng.cert» et supprimez le bloc comprenant la clé privée --- --BEGIN PRIVATE KEY----- xxxxxxxxx -----END PRIVATE KEY----- [root@sixfeet certs]# vim syslog-ng.cert Editez le fichier «syslog-ng.key» et supprimez le bloc comprenant le certificat -----BEGIN CERTIFICATE----- xxxxxxxxx -----END CERTIFICATE----- Un article sur la sécurité informatique de Elie MABO, CCNA, CCNA Sec., Security+ (IT Security Professional) 5/7
[root@sixfeet certs]# vim syslog-ng.cert Supprimez le fichier «syslog-ng.pem» créé à l'étape 2 [root@sixfeet certs]# rm -f syslog-ng.pem Déplacez les fichiers «syslog-ng.cert» et «syslog-ng.key» dans les répertoires créés à l'étape 3 [root@sixfeet certs]# mv syslog-ng.cert /opt/syslog-ng/etc/cert.d/ [root@sixfeet certs]# mv syslog-ng.key /opt/syslog-ng/etc/key.d/ Sur le client (sphinx) Etape7: Copiez le certificat du serveur et coller le dans le répertoire «cert.d» [root@sphinx]# cd /opt/syslog-ng/etc/cert.d [root@sphinx cert.d]#scp root@sixfeet: /opt/syslog-ng/etc/cert.d/syslog-ng.cert. Etape8: Créez un hash du certificat et un lien symbolique entre ce certificat et le hash créé. [root@sphinx cert.d]# openssl x509 -noout - hash -in syslog-ng.cert root@sphinx cert.d]# ln -s syslog-ng.cert 9a2982c8.0 Modification du fichier de configuration de syslog-ng sur le serveur Etape6: Créez un répertoire «cert.d» dans le répertoire «/opt/syslog-ng/etc» [root@sphinx]# mkdir /opt/syslogng/etc/cert.d Editez le fichier de configuration de syslog-ng (vim /etc/syslog-ng/syslogng.conf ) et ajoutez les lignes ci-après (en gras) dans la section «source» pour indiquer au serveur que le certificat doit être utilisé pour le chiffrement des messages journaux et l'authentification du serveur. source svr_log_src_tls { tcp(ip(129.104.11.63) port(514) maxconnections(250)); tls( key_file("/opt/syslog-ng/etc/key.d/syslogng.key") cert_file("/opt/syslog-ng/etc/cert.d/syslogng.cert") peer_verify(optional-untrusted)) ); N'oubliez pas de remplacer l'adresse IP ci-dessus par la vôtre. N'oubliez pas également de créer une connexion (log) dans le fichier de configuration de syslog- NG entre vos sources et cette nouvelle destination, puis de redémarrer le démon «syslog-ng». Modification du fichier de configuration de syslog-ng sur le client Editez le fichier de configuration de syslog-ng (vim /etc/syslog-ng/syslogng.conf ) et ajoutez les lignes ci-après (en gras) dans la section «destination» pour indiquer au client que le certificat doit être utilisé pour le chiffrement des messages journaux et l'authentification du serveur. destination svr_log_dst_tls { tcp(129.104.11.63 port(514) tls( ca_dir("/opt/syslog-ng/etc/cert.d/))) ; ); N'oubliez pas de remplacer l'adresse IP ci-dessus par la vôtre. N'oubliez pas également de créer une connexion (log) dans le fichier de configuration de syslog- NG entre vos sources et cette nouvelle destination, puis de redémarrer le démon «syslog-ng». Exploitation des logs avec LogZilla Une fois les messages centralisés, il faut les analyser. L'analyse des messages bruts peut être fastidieuse. C'est là qu'intervient des outils d'analyse et d'exploitation des messages journaux. Parmi ces outils, vous avez LogWatch, GrayLog, LogZilla, etc. Dans cet article, j'ai choisi de présenter LogZilla, bien qu'il ne soit pas gratuit. Mon choix étant délibéré. Présentation de LogZilla LogZilla (anciennement Php-syslog-ng) est une solution logicielle de monitoring des messages Un article sur la sécurité informatique de Elie MABO, CCNA, CCNA Sec., Security+ (IT Security Professional) 6/7
journaux générés par des programmes et centralisés sur un serveur. Il permet d'exploiter des messages stockés dans une base de données grâce aux interfaces graphiques. Vous comprenez donc pourquoi il est important de centraliser les logs générés par des ressources. Il permet également de faire une supervision proactive des ressources, ce qui permet d'anticiper sur certains incidents (pannes, problèmes, etc.). Quelques fonctionnalités de LogZilla Détection en temps réel des évènements (erreur, warning, etc.) Identification rapide de la dégradation du réseau et des serveurs Alerte en temps réel par mail Possibilité d'intégration avec LDAP ou Active Directory Installation de LogZilla sous Linux L'installation de LogZilla sur un poste Linux diffère en fonction la distribution (RedHat, Ubuntu, SUSE, etc.) que vous utilisée. je vous recommande d'aller sur ce site: http://nms.gdd.net/index.php/install_guide_for_ LogZilla_v3.1 En fonction de votre distribution, vous s'y trouverez une procédure bien élaborée et complète détaillant les étapes d'installation de LogZilla. Sachez que l'installation fait appel à l'installation des nombreux autres packages indispensables pour le fonctionnement de LogZilla. Configuration de LogZilla Normalement, au cours de l'installation, la configuration (base de données, rotation des logs, etc.) est faite en même temps. Une fois de plus, référez vous à la procédure d'installation. Par défaut, les fichiers de configuration de LogZilla se trouvent dans le répertoire «/var/www/logzilla». Utilisation de LogZilla Une fois de plus, je ne vais pas réinventer la roue. Pour l'utilisation de l interface Web de LogZilla, je vous recommande d'aller sur ce site: http://nms.gdd.net/index.php/logzilla_3.1_user _Guide Vous s'y trouverez une documentation bien élaborée qui vous permettra d'utiliser facilement LogZilla. Sur ce, il ne me reste plus qu'à vous souhaiter bon courage et bonne utilisation de cet article. N'hésitez surtout pas de m'envoyer votre feedback par mail à mon adresse perso (elie.mabo@gmail.com) Références 1. Official syslog-ng website http://www.balabit.com/network-security/syslog-ng/ 2. The syslog-ng Administrator Guide http://www.balabit.com/support/documentation/ 3. Syslog-ng mailing list https://lists.balabit.hu/mailman/listinfo/syslog-ng 4. BalaBit Documentation Blog http://robert.blogs.balabit.com 5. official logzilla website http://www.logzilla.pro 6. LogZilla user Guide http://nms.gdd.net/index.php/logzilla_3.1_user_gu ide 7. Install Guide for LogZilla v3.1 http://www.gdd.net/index.php/install_guide_for_lo gzilla_v3.1 Un article sur la sécurité informatique de Elie MABO, CCNA, CCNA Sec., Security+ (IT Security Professional) 7/7