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.

Analyse de logs

Sommaire