Analyse de logs

Définitions

Analyse de logs

L’activité d’un processus, d’une application ou d’un réseau informatique est une série d’événements. Tracer l'activité d'une application c'est enregistrer chronologiquement ses événements dans un fichier ou dans une base de données, on parlera alors de fichier de traces, ou de logs ou de journal d’événements.

Fichier de logs ou journal d'évènements

regroupe l'ensemble des événements survenus sur un logiciel, une application, un serveur ou tout autre système informatique. Un fichier de logs se présente sous la forme d'un fichier texte classique, reprenant de façon chronologique, l'ensemble des événements qui ont affecté un système informatique et l'ensemble des actions qui ont résulté de ces événements. Par exemple, pour un serveur Web, un fichier de logs regroupe les demandes d'accès à chacun des fichiers du serveur, l'horodatage de la session, l'ip du client, la réponse du serveur (code retour HTTP) ...

Journalisation (logging)

Les événements enregistrés sont les accès au système, les déconnexions, les modifications de fichiers, les envois et réceptions de messages, etc. On consacre typiquement une ligne par événement, en commençant par le moment exact (date, heure, minute, seconde) où il a eu lieu.

Analyse des logs

Elle permet d'effectuer des rapports statistiques, de faire des hypothèses sur les dysfonctionnements ou les pertes de performance d'un système.

Corrélation des logs

Permet d’étudier la causalité, la dépendance, le lien, le rapport ou la relation entre plusieurs événements.

Archivage des logs

Peut également avoir un intérêt légal. Par exemple un fournisseur d'accès à Internet est tenu de fournir un historique des connexions de ses clients (Loi du 15 Novembre 2001 "LSQ", Loi du 21 juin 2004 "LCEN", Loi HADOPI du 12 juin 2009).

Pourquoi tout enregistrer et analyser ?

Pourquoi enregistrer?

• pour respecter les obligations légales et être à même de fournir des preuves en cas de réquisition judiciaire
• pour détecter les défaillances et les anomalies de sécurité (accidentelles ou volontaires)
• pour s'assurer que les règles de sécurité sont correctement appliquées (respect de la PSSI)
• pour la métrologie (mesures de l'utilisation des ressources informatiques tels que trafic réseau, utilisation des espaces disques, etc).

L'enregistrement des traces est une obligation légale pour certains domaines (FAI, éditeurs de contenus, hébergeurs...). On peut citer un grand nombre de lois (Godfrain, LCEN, DADVSI, HADOPI 2, LOPPSI...).

Quoi qu'il en soit :

• Permet de détecter et comprendre les erreurs et les plantages
• Permet de détecter les anomalies de sécurité
• L'enregistrement des traces peut permettre de mesurer l'activité du SI

Durée de conservation

Elle est variable :

• EU : 1 à 2 ans
• LCEN art. 6 : 1 an
• Loi anti-terrorisme : 1 an
• CNIL : 6 mois

Les recommandations à ce sujet sont :

• 3 mois en clair
• Suivis de 9 mois en accès restreint en cas de réquisition

Informations à enregistrer

Sur tous les équipements :

• identité de l’émetteur de la requête (en fonction, cela peut-être un identifiant utilisateur et/ou une adresse IP et/ou une adresse MAC)
• date et heure
• résultat de la tentative
• volumes de données transférées
• commandes passées

Pour la messagerie :

• adresse de l’expéditeur
• adresses des destinataires
• date et heure
• Machines traversées
• le traitement (accepté ou rejeté)
• la taille du message
• certaines en-têtes (identifiant numérique de message)
• résultat du traitement des spams
• résultat du traitement antiviral
• validation ou rejet par les modérateurs si nécessaire

Ni le contenu ni l'objet du message ne sont sauvegardés

Serveurs web:

• noms ou adresses IP source et destination
• données d’authentification si pertinent (intranet par exemple)
• URL de la page consultée
• informations fournies par le client (type et version du navigateur, de l'OS)
• type de la requête
• date et heure
• volume de données transférées
• paramètres passés

Proxies web:

• noms ou adresses IP source et destination et les différentes données d’identification
• l'URL de la page consultée le type de la requête
• date et heure
• volume de données transférées

Équipements réseau:

• noms ou adresses IP source et destination
• numéros de port source et destination et protocole (pour déterminer le service demandé)
• date et l’heure
• traitement du paquet (transmis ou filtré)
• nombre de paquets
• nombre d’octets transférés
• messages d’alerte

Qui a accès aux traces et pourquoi ?

Seuls les admins et les responsables du SI ont accès aux traces. Les admins ont un accès de moins de 3 mois pour surveiller le SI et détecter toute anomalie.

Matériel et applications

Systèmes et applications

La plupart des systèmes enregistrent des traces : Linux, Windows, Pare-feux, routeurs, antivirus, etc

Traces à enregistrer

Les traces à enregistrer de façon systématique :

• Les événements des serveurs (événements matériels, arrêts/démarrages, connexions, modifications de fichiers systèmes, et autres en fonction du rôle du serveur - DHCP, DNS, Kerberos, bases de données, apache/nginx, etc)
• Les événements des équipements réseau
• Les événements des équipements de sécurité (pare-feu, antivirus, IDS/HIDS/NIDS)
• Les applications spécifiques

Déontologie de la collecte de traces

Il faut s'assurer que:

• La collecte des informations n'est ni frauduleuse, ni déloyale, ni illicite et qu'elle s'accompagne d'une bonne information des personnes ;
• Les informations ne sont pas conservées au-delà de la durée prévue ;
• Les informations ne sont pas communiquées à des personnes non autorisées ;
• Le traitement ne fait pas l'objet d'un détournement de finalité ;
• L’accès aux résultats des traitements et aux données collectées fait l'objet d'une sécurité optimale, afin qu'aucun détournement de la finalité ne puisse avoir lieu.
• Les applications à caractère nominatif font l’objet de demandes d’avis préalables à la CNIL.

Syslog : protocole & format

Une RFC encadre le format des logs : SYSLOG D'autres formats existent, comme le Common Event Format (CEF), le LEEF (Log Event Extended Format) ou encore GELF (Graylog Extended Log Format) mais ne font pas l'objet de RFC. Syslog est utilisé par tous les démons Unix, mais aussi par tous les routeurs, switch, pare-feu pour enregistrer et transmettre les événements. Syslog est à la fois un format et un protocole (respectivement RFC 5424 et RFC 5426)

Le format syslog (RFC5424)

Sévérité Syslog

La sévérité d'un message Syslog correspond au degré d'urgence du message. Les 8 sévérités existantes sont définies par les RFC :

Numéro de sévérité	Usage
0 	Emergency : system is unusable
1 	Alert : action must be taken immediately
2 	Critical : critical conditions
3 	Error : error conditions
4 	Warning : warning conditions
5 	Notice : normal but significant condition
6 	Informational : informational messages
7 	Debug : debug-level messages

Plus grande est la sévérité, moins le message est "grave".

Il faut garder à l'esprit que la sévérité des messages émis par l'application est un choix fait par les concepteurs de la dite application. C'est toujours l'application "qui décide" du niveau de sévérité des messages enregistrés.

Catégories Syslog

Outre les niveaux de gravité, les messages sont orientés en fonction de leur origine, dont les codes sont regroupés suivant 24 types :

  Numéro de catégorie  	Usage
0 	kernel messages
1 	user-level messages
2 	mail system
3 	system daemons
4 	security/authorization messages
5 	messages generated internally by syslogd
6 	line printer subsystem
7 	network news subsystem
8 	UUCP subsystem
9 	clock daemon
10 	security/authorization messages
11 	FTP daemon
12 	NTP subsystem
13 	log audit
14 	log alert
15 	clock daemon (cron)
16 	local use 0
17 	local use 1
18 	local use 2
19 	local use 3
20 	local use 4
21 	local use 5
22 	local use 6
23 	local use 7

Les catégories n° 16 à 23 (local use) sont "personnalisables". On pourra par exemple définir que les logs d'un site apache en particulier utilise la facilité local4. C'est en somme une sorte de raccourci d'écriture, on sait que local4 = site machin.

Là encore, il faut bien comprendre que le choix de la catégorie est dépendante de l'application. La catégorie est choisie par les développeurs, en aucun cas imposée par Syslog.

Priorité Syslog

La priorité regroupe la sévérité et la catégorie.

Pour calculer la priorité, il faut multiplier la valeur de la catégorie par huit et y ajouter la valeur de la sévérité.

Priorité = 8 * catégorie + sévérité

Pour calculer la catégorie et la sévérité à partir de la priorité :

Catégorie = résultat entier de (priorité/8) Sévérité = priorité - (8 * catégorie)

Format des messages

La valeur nulle est représentée par le symbole -

Un enregistrement au format syslog doit comporter les informations suivantes

la partie HEADER

• la priorité : regroupe entre <> la catégorie et la sévérité
• la date à laquelle s'est produit l'événement (au format TIMESTAMP - RFC3339)
• le nom de la machine ayant produit l'événement (FQDN, hostname, IP, ou valeur nulle)
• le nom de l'application ayant produit l'événement
• Le PROCID : souvent utilisé pour placer le PID du processus syslog. Cela permet de détecter une discontinuité du service syslog. La valeur nulle '-' doit être utilisée si le PID n'est pas disponible.
• Le MSGID :identifie le type de message. Par exemple TCPIN ou TCPOUT pour un

La partie STRUCTURED-DATA

Ce champ peut contenir la valeur nulle '-'. Il contient la description structurée de l'événement au format ASCII, les différentes parties du message sont identifiées sous la forme nom="valeur". Par exemple, la partie STRUCTURED-DATA peut ressembler à ça [exemple@12345 source="MonAppli" eventID="123" signature="..."]

La partie MSG

contient la description de l'événement. Le format est libre mais les caractères doivent être encodés avec UTF-8

Exemple de message syslog :

• avec la partie STRUCTURED-DATA : <34>1 2003-10-11T22:14:15.003Z mymachine.example.com su - ID47 [exampleSDID@32473 iut="3" eventSource= "Application" eventID="1011"] 'su root' failed for lonvick on /dev/pts/8
• sans la partie STRUCTURED-DATA : <34>1 2003-10-11T22:14:15.003Z mymachine.example.com su - ID47 - 'su root' failed for lonvick on /dev/pts/8

Dans l'exemple ci-dessus,

• la priorité est 34, ce qui correspond à une catégorie de valeur 4 et une sévérité de valeur 2. ( 4*8 + 2 = 34). Soit un message critique avec la catégorie security/authorization.
• la version de Syslog est la version 1
• l'événement s'est produit le 11 octobre 2003 à 22H14mm15s et 3 millisecondes du temps universel UTC
• l'événement a eu lieu sur la machine mymachine.example.com
• l'application est su
• le PROCID est inconnu : valeur nulle '-'
• le MSGID est : ID47

on trouve ensuite la partie STRUCTURED-DATA d'un côté et la valeur nulle '-' de l'autre

• le message au format libre : 'su root' failed for lonvick on /dev/pts/8

Le protocole syslog

'Par défaut, syslog utilise le port UDP 514' La RFC5426 décrit le transport des messages Syslog au travers UDP. Cette description n'a pas d'intérêt pour ce cours. Ce qui nous intéresse ici, c'est le format des messages Syslog, pas vraiment son transport au travers UDP (on verra par la suite qu'il vaut mieux privilégier TCP pour des raisons de fiabilité).

Les logs sous Linux

Emplacements

À ajouter, mais je peux déjà citer de tête /var/log

Logrotate

Le service logrotate permet de faire une rotation des logs. Suivant les paramètres, les logs sont archivés pendant un certain temps, puis supprimés au-delà.

On retrouve un fichier par application dont les logs doivent tournés. Par exemple, pour mysqld, le fichier de rotation des logs sera celui-ci : /etc/logrotate.d/mysql-server

/var/log/mysql.log /var/log/mysql/mysql.log /var/log/mysql/mysql-slow.log {
    daily!#Le script est exécuté tous les jours
    rotate 7! #7 fichiers seront gardés, soit 7 jours de log
    missingok! #Ne pas tenir compte des fichiers manquants
    create 640 mysql adm! #Des fichiers seront créés avec mysql comme proprio, adm comme groupe et des droit à 640 (lecture-écriture pour le proprio; lecture pour le groupe)
    compress #compresser les fichiers créés (autre que le fichier de log du jour)
    sharedscripts #Permet d’executer qu’une seule fois le script logrotate par rotation

    postrotate #Script post rotation // Commande externe
        test -x /usr/bin/mysqladmin || exit 0
        # If this fails, check debian.conf!

        MYADMIN="/usr/bin/mysqladmin --defaults-file=/etc/mysql/debian.cnf"

        if [ -z "`$MYADMIN ping 2>/dev/null`" ]; then
            # Really no mysqld or rather a missing debian-sys-maint user?
            # If this occurs and is not a error please report a bug.
            if killall -q -s0 -umysql mysqld; then
                exit 1
            fi
        else
            $MYADMIN flush-logs
        fi
    endscript
}

La première ligne de ce fichier précise quels sont les fichiers à traiter pour la rotation(/var/log/mysql.log ; /var/log/mysql/mysql.log et /var/log/mysql/mysql-slow.log). Chaque ligne est accompagnée de son explication.

Le daemon Syslog-NG

Documentation officielle

Syslog-ng est le syslog nouvelle génération. Il offre plus de souplesse et permet de rediriger les journaux vers une autre machine. Son utilisation est très répandue.

Syslog-ng fonctionne sur le modèle suivant : source des logs > filtre > destination.

Les messages sont traités par source et envoyés à destination en fonction de filtres.

Sources des logs

Les sources de syslog-ng peuvent être :

• un pipe unix
• un fichier spécial tel que /proc/kmsg sous linux
• un fichier
• un port tcp ou udp

Elles sont écrites de la manière suivante dans le fichier de configuration de syslog-ng (/etc/syslog-ng/syslog-ng.conf) :

source s_all {
    # message generated by Syslog-NG
    internal();
    # standard Linux log source (this is the default place for the syslog()
    # function to send logs to)
    unix-stream("/dev/log");
    # messages from the kernel
    file("/proc/kmsg" log_prefix("kernel: "));
    # use the following line if you want to receive remote UDP logging messages
    # (this is equivalent to the "-r" syslogd flag)
    # udp();
}

Filtres

Les filtres permettent de trier les journaux en fonction de divers paramètres tels que le programme qui émet les logs, des expressions régulières, la facilité ou encore le niveau de gravité. Ils sʼécrivent de la façon suivante :

filter f_cron { facility(cron); };
filter f_daemon { facility(daemon); };
filter f_kern { facility(kern); };
filter f_lpr { facility(lpr); };
filter f_mail { facility(mail); };
filter f_news { facility(news); };
filter f_user { facility(user); };
filter f_uucp { facility(uucp); };
filter f_duser { match(user) and host(zarafa); };

La dernière ligne récupère les messages de lʼhôte zarafa contenant le mot user.

Destination des logs

Les destinations dans syslog-ng peuvent être de diverses formes :

• un fichier
• un pipe
• une socket unix
• une commande
• un port udp ou tcp
• et même un terminal

destination df_syslog { file("/var/log/syslog"); };
destination df_cron { file("/var/log/cron.log"); };
destination df_daemon { file("/var/log/daemon.log"); };
destination df_kern { file("/var/log/kern.log"); };
destination df_lpr { file("/var/log/lpr.log"); };
destination df_mail { file("/var/log/mail.log"); };
destination df_user { file("/var/log/user.log"); };
destination dp_xconsole { pipe("/dev/xconsole"); };
destination d_user { file("/home/elerf/user.log" owner("root")); };

Règles d'enregistrement

Syslog-ng-ose-guide-admin.pdf Les règles dʼenregistrement dans syslog-ng sont préfixées par log. Elles permettent de traiter les messages de bout en bout. Source ; filtre ; destination.

log { source(s_all); filter(f_duser); destination(d_user); };
log { source(s_all); filter(f_auth); destination(df_auth); };

On retrouvera par exemple dans le fichier /home/elerf/user.log, les messages provenant de lʼhôte zarafa contenant la chaîne de caractères user.

Les logs sous Windows

Encyclopédie des logs Windows

Centralisation et analyse des logs

Principes

Centraliser les logs, c'est :

1. collecter les évènements des différents équipements en un point unique
2. Analyser et corréler les logs de l'ensemble du SI
3. Mettre en place des tableau de bord/alertes pour résoudre les pannes/améliorer les performances du SI
4. Archiver les logs/anonymiser à des fins de conservations (obligations légales, etc)

La collecte des logs

Les logs peuvent être envoyés au serveur central par le daemon syslog au format syslog, mais certaines solutions d'analyse de log s'appuie sur un agent spécialisé à déployer sur chaque équipement à collecter.

Les logs peuvent être alors "préparés directement" à la source. Les messages peuvent être remis en forme selon des critères personnels et inclure des informations complémentaires.

Quelque soit la méthode (syslog ou agent), il est possible de filtrer les messages transmis depuis la source, et ainsi choisir de ne pas transmettre certains messages inutiles (synchronisation DFS-R réussie par exemple, il n'est pas utile de savoir qu'un fichier créé par un agent sur le serveur A a correctement été répliqué sur le serveur B. Le nombre de message de réussite de synchronisation peut être conséquent - plusieurs milliers par heure -, occuper de la place inutilement sur les serveurs de logs, accaparer de la bande passante et des ressources serveurs. Il est plus utile de savoir quand la réplication s'est mal passée).

Analyser et corréler

Pour pouvoir analyser et corréler les logs, il est souvent nécessaire d'extraire les parties intéressantes des messages, comme l'identifiant (nom d'utilisateur, adresse IP, adresse MAC, etc)

Extraction des champs d'intérêt

L'extraction des champs peut se faire par différentes méthodes (expressions régulières, filtres Grok, etc). L'utilisation d'un grand nombre de ces filtres peut provoquer des baisses significatives de performance.

Les agents collecteurs permettent aussi de préparer les messages à la source et de les formater sous la forme ATTRIBUT : VALEUR. L'extraction des champs est alors automatique à la réception et le traitement est accéléré.

Analyse des évènements

Avant l'analyse des messages, il est nécessaire de :

• extraire les champs d'intérêt
• tagguer/catégoriser les messages
• supprimer les messages inutiles

L'analyse des événements consiste à mettre en place des rapports regroupant un ensemble d'indicateurs. Ces rapports seront regroupés dans des tableaux de bord.

La production des rapports couvre cinq domaines majeurs :

• Analyse de la Sécurité du Réseau (qui tente d’accéder au réseau?)
• Analyse des Événements Systèmes (qui reconfigure le firewall ? Qu’est ce qui a changé?)
• Productivité des employés (quels sont les sites les plus visités, à quelle heure?)
• Performance du réseau (qui ou quelle application utilise, le plus, la bande passante?)
• Respect des lois et règlements (est-t-on conforme à CNIL, LSF, HADOPI, SOX, etc?)

LEs intérêts de ces rapports :

• Résolution d’incidents et Audits des systèmes informatiques
• Diminution du nombre des incidents
• Amélioration du délai de traitement des incidents
• Sécurisation, Fiabilisation, et meilleure disponibilité du SI
• Respect du cadre législatif en vigueur :
  • Obligation de rétention des traces d’utilisation des services internet.
  • Obligation de communiquer les traces sur réquisition judiciaire (PSA)
  • Responsabilité pénale de la personne morale et des dirigeants de l’entreprise : Pénalement sanctionnée (Art. 226-17 C. pénal) La mise en œuvre d’un traitement sans précautions utiles est passible de cinq ans d'emprisonnement et de 300 000 euros d'amende (amende quintuplée pour les sociétés)

Exemples :

Alertes et tableaux de bord

Alertes

• Notifications par email, snmp trap, ...
• Selon des critères tels que mot-clef, regex, source, nb de répétitions, …

Ex : envoi d'un mail lorsque 10 tentatives de connexion ont échoué avec le compte root

Reporting/Tableaux de bord Un tableau de bord est un ensemble de rapports, comme on a par exemple avec Graylog.

Recommandations

Techniques

• Lors du dimensionnement des serveurs d'analyse de logs (rôle stockage des logs), l’estimation de l’espace de stockage nécessaire à la conservation des journaux est indispensable
• Il est recommandé de ne pas effectuer de traitement sur les journaux avant leur transfert
• Les horloges des équipements doivent être synchronisées
• Il est recommandé d’utiliser des protocoles d’envoi de journaux basés sur TCP pour fiabiliser le transfert de données entre les machines émettrices et les serveurs centraux

Sécurité

• Les journaux doivent être automatiquement exportés sur une machine physique différente de celle qui les a générés, en temps réel de préférence
• La transmission des logs doit être chiffrée (voir par exemple le rfc5425 - TLS Transport Mapping for Syslog)
• Signer et horodater les journaux dès leur création permet d’assurer leur intégrité et d’accroître leur valeur probatoire
• Il faut conserver une copie des traces brutes pour garder leur valeur juridique

Usage

• Il est recommandé d’adopter une arborescence pour le stockage des journaux d’événements
• Si la taille ou la typologie du système d’information le nécessite, une approche hiérarchique pour l’organisation des serveurs de collecte doit être retenue
• Une politique de rotation des journaux d’évènements doit être formalisée et mise en œuvre sur l’ensemble des équipements du système de journalisation
• La durée de conservation des fichiers de journaux étant soumise à des contraintes légales et réglementaires, il convient d’en prendre connaissance pour définir les moyens techniques nécessaire à l’archivage des journaux
• A la réception des messages :
  • Normalisation de la date (ex : JJ/MM/AAAA HH:mm:ss)
  • Indexation des champs d'intérêts : extraction de l'adresse IP grâce à une regex par exemple
  • Classification : application d'un tag. Ex : application du tag authentification portail captif pour les messages de l'hôte portail-captif.local avec la catégorie syslog auth
  • Mise à la corbeille des messages connus sans intérêts (définis préalablement)

PowerShell

Connaître les commandes PowerShell de base servant à analyser les logs peut être utile :

<syntaxhighlight lang="powershell"> Get-Eventlog <journal> #Voir l'intégralité du journal Get-Eventlog -Index 123456 # Voir un message particulier Get-Eventlog -Message "*erreur*" #Chercher dans le contenu des messages Get-Eventlog -Newest 100 -LogName "Application" -EntryType Error #Un peu plus pratique </syntaxhighlight>