Auditez la sécurité d'un système d'exploitation

Je vous propose, dans ce chapitre, de vérifier que les principaux fichiers de trace du système sont bien présents, que le processus qui les gère est cloisonné et qu'il existe bien un processus supervisant le contenu de ces fichiers.

Vérifiez la présence des principaux fichiers de trace

Avant toute chose, il est nécessaire de vérifier la présence des fichiers de trace, critiques pour le système. Vous pouvez suivre pas à pas cette vérification, dans la vidéo suivante. :)

La commande suivante permet de nous en assurer :

[root@fichesproduits ~]# ls -lrtha /var/log/
...
-rw-r--r-- 1 root root 28K 13 mai 07:39 dmesg
-rw-------. 1 root root 8,5K 13 mai 07:39 boot.log
-rw------- 1 root root 416 13 mai 07:39 maillog
-rw------- 1 root root 7,1K 13 mai 07:42 secure
-rw-rw-r--. 1 root utmp 23K 13 mai 07:42 wtmp
-rw-r--r--. 1 root root 287K 13 mai 07:42 lastlog
-rw-------. 1 root root 4,9K 13 mai 09:26 yum.log
-rw------- 1 root root 139K 13 mai 10:01 messages
-rw------- 1 root root 6,9K 13 mai 10:01 cron

Les derniers fichiers de cette liste sont les derniers fichiers mis à jour. On y retrouve notamment :

• messages : ce fichier contient toutes les informations génériques sur l'activité du système. C'est souvent le premier fichier consulté lorsque qu'un problème survient ;

• secure : ce fichier contient toutes les informations sur le processus d'authentification. Il est très important de consulter le contenu de ce fichier régulièrement pour se tenir au courant des élévations de privilèges ou des tentatives de connexion ;

• boot.log : ce fichier contient toutes les informations tracées lors du processus de démarrage. Dans ce fichier, les informations concernent souvent les procédures de redémarrage afin de détecter d'éventuels échecs lors d'opérations associées ;

  dmesg : c'est le fichier de trace du noyau. Toutes les interactions entre le système d'exploitation et le matériel sont stockées dans ce fichier.

Chacun de ces fichiers joue un rôle important dans la supervision du système d'exploitation. Ils doivent donc être présents et modifiables uniquement par root.

Effectuez le cloisonnement du service Syslog

Le service Syslog est utilisé par chaque processus pour écrire des informations dans les fichiers de trace évoqués ci-dessus. Ce service est indispensable pour vérifier le fonctionnement du serveur. Les attaquants cherchant à effacer les traces de leur passage, ils vont essayer de compromettre ce service ou de modifier les fichiers associés. Regardons cela dans la vidéo suivante ! 

Le fichier de configuration de ce service est /etc/rsyslog.conf.

[root@fichesproduits ~]# grep ^[^#] /etc/rsyslog.conf
$ModLoad imuxsock # provides support for local system logging (e.g. via logger command)
$ModLoad imjournal # provides access to the systemd journal
$WorkDirectory /var/lib/rsyslog
$ActionFileDefaultTemplate RSYSLOG_TraditionalFileFormat
$IncludeConfig /etc/rsyslog.d/*.conf
$OmitLocalLogging on
$IMJournalStateFile imjournal.state
*.info;mail.none;authpriv.none;cron.none /var/log/messages
authpriv.* /var/log/secure
mail.* -/var/log/maillog
cron.* /var/log/cron
*.emerg :omusrmsg:*
uucp,news.crit /var/log/spooler
local7.* /var/log/boot.log

Chaque canal de trace est défini en indiquant le fichier destinataire des traces. Par exemple, le canal mail.* est défini dans le fichier destinataire -/var/log/maillog.

Ce cloisonnement passe par plusieurs opérations distinctes :

• privilégier une partition spécifique pour les fichiers de trace, afin de vous assurer qu'un processus tiers ne viendra pas saturer la partition des fichiers de trace ;

• instaurer un processus de rotation des fichiers de trace en les compressant. Les fichiers de trace sont souvent volumineux et la création de nouveaux fichiers de manière régulière permet une maintenance plus simple des archives. Cette configuration est stockée dans le fichier /etc/logrotate.conf :

[root@fichesproduits ~]# grep ^[^#] /etc/logrotate.conf
weekly
rotate 4
create
dateext
include /etc/logrotate.d
/var/log/wtmp {
monthly
create 0664 root utmp
minsize 1M
rotate 1
}
/var/log/btmp {
missingok
monthly
create 0600 root utmp
rotate 1
}

• externaliser et centraliser les fichiers de trace. Dans la mesure du possible, écrivez les traces dans les fichiers de l'arborescence locale, mais aussi dans des fichiers distants, en passant par le service réseau d'un serveur de centralisation des logs. Pour cela, il suffit d'indiquer, dans le fichier de configuration /etc/rsyslog.conf, la destination réseau du fichier distant (via UDP ou TCP) :

# Log anything (except mail) of level info or higher.
# Don't log private authentication messages!
*.info;mail.none;authpriv.none;cron.none /var/log/messages
*.info;mail.none;authpriv.none;cron.none @@remote-server:port

Supervisez les fichiers de trace

Il est important de mettre en place un service cloisonné et sécurisé de gestion des traces. Cependant, les évènements critiques, les tentatives de connexion échouées, les requêtes vers des ressources Web inexistantes figureront toujours dans les fichiers de trace. Il est primordial de superviser ces fichiers car, si vous ne les lisez pas, vous ne saurez pas ce qu'il se passe sur le serveur.

Je vous montre comment faire cela, dans la vidéo suivante !

On en tire donc la recommandation suivante :

Il existe plusieurs façons de connaître le contenu de ces fichiers :

• dégager du temps pour consulter manuellement le contenu des fichiers. C'est la technique la plus simple, mais la plus coûteuse en termes de temps ;

• installer un processus de supervision automatique du contenu des fichiers. Par exemple des sondes Nagios qui viendraient consulter, à intervalle de temps régulier, les lignes des fichiers, afin de lever des alertes lorsque nécessaire ;

• installer un parseur de fichiers de trace. Celui-ci permet notamment de recevoir, par mail, un résumé des lignes jugées critiques dans tous les fichiers parsés. Logwatch est très efficace en la matière : https://doc.ubuntu-fr.org/logwatch.

En résumé

Dans ce chapitre, nous avons vu en détail les fichiers de trace et les programmes qui les gèrent ou qui les alimentent. Nous avons aussi abordé la notion de supervision et découvert qu'il était possible de recevoir une alerte quand une anomalie ou un message d'erreur était détecté dans les fichiers. Dans le prochain chapitre, je vous propose d'étudier les accès réseau.

Résumé des recommandations pour cette partie :