Unix est un système d'exploitation conçu dès le départ pour accueillir plusieurs utilisateurs simultanément. Linux a bien évidemment hérité de cette propriété. Il est donc tout à fait possible que plusieurs comptes exécutent plusieurs tâches simultanément sur un serveur Linux (service web, service FTP, service mail, etc.).

Du coup, l'exercice d'analyse de l'activité du système pourrait paraître un peu compliqué. Mais il n'en est rien, en réalité, c'est même assez simple : Linux vous fournit tous les outils nécessaires pour auditer l'activité des utilisateurs ou des processus.

Les audits systèmes sont très utiles notamment dans le cadre de supervision de service : l’exemple le plus commun est le service de messagerie, qui est souvent très sensible !

Si vous souhaitez vous pencher sur l'activité passée sur le système, alors vous allez consulter les fichiers de traces, comme nous allons le voir dans la première section de ce chapitre avec les fichiers contenus dans le répertoire /var/log.

Mais si vous vous demandez qui fait quoi à l'instant “t” sur le système, alors vous pourrez également profiter des nombreuses commandes à votre disposition. Je vous détaillerai les plus couramment utilisées comme w, ou encore who.

Comme nous avons pu l'évoquer dans le chapitre “Adoptez l'arborescence des systèmes Linux”, le répertoire /var contient toutes les données variables du système et notamment les fichiers de traces dans le sous-répertoire /var/log.

Ce comportement est normalisé et sera commun aux distributions RedHat ou Debian et leurs dérivées. Cependant quelques différences mineures vont tout de même apparaître dans la gestion des fichiers de traces entre ces deux familles de distributions. Je ne manquerai pas de vous le signaler lorsqu'elles se présenteront.

Chacun des processus du système proposant au noyau Linux de tracer ses activités déclenche le traitement de ses informations par un service particulier : rsyslog.

Ce dernier présente l'avantage de centraliser la configuration des fichiers de traces et de regrouper dans les fichiers concernés les informations de même nature.

Par exemple :

• Toutes les traces émises par le noyau Linux (que l'on appelle “kernel ring buffer”) seront stockées dans un fichier particulier,
• Toutes les traces concernant l'authentification des utilisateurs seront dans un autre fichier.

Par ailleurs, rsyslog dispose également de fonctionnalités supplémentaires intéressantes.

Elles permettent notamment :

• D'envoyer ces traces sur le réseau afin de centraliser toutes celles d'un parc de machines sur un même serveur de logs ;
• De gérer la rotation automatique des fichiers ;
• D'utiliser des formats de dates très précis (jusqu'au millième de seconde).

Comme tout bon processus système sous Linux, rsyslog se paramètre à l'aide d'un fichier de configuration, en l'occurrence : le fichier /etc/rsyslog.conf.

La redirection des traces sur une machine tierce est une opération recommandée dans notamment par le guide d’administration sécurisée des serveurs Linux de l’ANSSI.

Ceci peut s'activer facilement dans la configuration de rsyslog :

1. Activer le module de réception par UDP sur le serveur rsyslog qui centralisera les logs ;
2. Paramétrer sur le serveur envoyant ses logs, les canaux à transmettre en UDP

# Transmission par UDP des traces de connexions
# le caractère '@' spécifie l'utilisation du protocole UDP 
authpriv.* @logserver.local:514

En s’appuyant sur la configuration de rsyslog vu précédemment, je vous propose d’effectuer un petit audit des fichiers

• /var/log/auth.log(pour Debian)
• /var/log/secure(pour RedHat)

…afin de relever les traces d’authentification sur le serveur. vous pourrez constater qu’il est finalement assez simple de relever :

• Toutes les connexions aux terminaux physiques de la machine ;
• Toutes les connexions via le serveur SSH ;
• Toutes les élévations de privilèges (qui sont bien des opérations d’authentification).

# Filtrer et afficher les lignes contenant le mot clé LOGIN
# dans le fichier auth.log
grep LOGIN /var/log/auth.log
 
# Ouverture de session SSH
grep sshd /var/log/auth.log

Sur les versions récentes, les logs sont conservés sous forme binaire. Dans ce cas il faudra utiliser l'utilitaire journalctl.

journalctl --no-pager | grep LOGIN
journalctl --no-pager | grep sshd

Second exemple d'informations très utiles disponibles dans les fichiers de traces : l'initialisation des cartes réseau.

Souvenez-vous, dans le chapitre “Configurez les cartes réseaux”, nous avions lancé la commande suivante pour vérifier la détection du matériel par le noyau :

dmesg | grep e1000

Et je vous avais indiqué que :

 "La commande dmesg(pour display message) permet d'afficher les messages du noyau pendant le processus de démarrage et notamment lorsque ce dernier charge les pilotes des périphériques qui vérifient si un matériel connecté leur est compatible".

Et bien, cette commande s'appuie sur les fichiers syslog pour Debian et messages pour CentOS en filtrant leur contenu sur les messages du noyau pendant le processus de démarrage de la machine.

Voyons donc comment utiliser ces deux fichiers pour relever l’initialisation des cartes réseau du serveur directement dans les traces du système :

# kern.log pour traces noyau et détection de matériels
grep e1000 /var/log/kern.log
 
# syslog pour traces de configuration des matériels
grep enp0s8 /var/log/syslog

En consultant la norme Filesystem Hierarchy Standard, vous pourrez constater qu’elle définit un fichier de traces un peu particulier : /var/log/wtmp. Ce fichier contient l'ensemble des connexions et déconnexions de tous les utilisateurs.

Pour des raisons de sécurité, ce fichier est maintenu au format binaire par le noyau, car c'est beaucoup plus difficile d'effacer ses traces dans un fichier binaire !

Mais il permet également de relever tous les redémarrages du système via un pseudo-compte nommé reboot.

Dans la prochaine vidéo, je vous propose de :

• Relever dans le fichier /var/log/wtmp les traces des connexions des comptes utilisateurs, et des redémarrages du système via le fameux compte reboot;
• Voir les commandes last et lastb qui permettent de lire ce fichier.

# wtmp est un binaire, la commande last peut le relire
last

On peut utiliser ce fichier pour déterminer quand le système a été redémarré. Un utilisateur spécial reboot est alors enregistré :

last | grep reboot

Enfin, dernières commandes très utiles : w(comme “work”) et who. Ces commandes permettent de relever qui sont les utilisateurs connectés à l’instant “t” et quelles sont leurs activités.

La commande who permet de visualiser qui sont les comptes connectés à l’instant “t”, elle dispose de certaines options intéressantes permettant de relever par exemple la date du dernier redémarrage.

La commande w effectue en fait un condensé de plusieurs autres commandes permettant de relever notamment l'activité du processeur.

• Le répertoire des traces sous Linux est /var/log ;
• rsyslog est le processus de gestion et de centralisation des traces sous Linux ;
• Chaque type d'activité peut être tracé sous Linux (connexion, authentification, exécution, etc.) ;
• La commande dmesg permet d'afficher les traces du noyau ;
• Les commandes who et w permettant de relever les comptes connectés

Dans le chapitre suivant, je vous propose d'approfondir ce petit audit du système en nous penchant notamment sur les processus et la mémoire.

◁ Précédent | ⌂ Retour au sommaire | Suivant ▷