Product SiteDocumentation Site

14.3. Supervision : prévention, détection, dissuasion

La supervision fait partie intégrante d'une politique de sécurité. Elle est nécessaire à plusieurs titres : l'objectif de la sécurité n'est pas uniquement de garantir la confidentialité des données, mais aussi d'assurer le bon fonctionnement des services. Il est donc impératif de veiller à ce que tout fonctionne comme prévu et de détecter au plus tôt les comportements inhabituels et les changements dans la qualité du service fourni. Surveiller l'activité peut permettre de détecter des tentatives d'intrusion et donc de s'en protéger avant que cela ne porte à conséquences. Ce chapitre va passer en revue des outils servant à surveiller différents aspects d'un système Debian. Il complète la Section 12.4, « Supervision ».

14.3.1. Surveillance des logs avec logcheck

Le programme logcheck scrute par défaut les fichiers de logs toutes les heures et envoie par courrier électronique à root les messages les plus inhabituels pour aider à détecter tout nouveau problème.
La liste des fichiers scrutés se trouve dans le fichier /etc/logcheck/logcheck.logfiles ; les choix par défaut conviendront si le fichier /etc/rsyslog.conf n'a pas été complètement remodelé.
logcheck peut fonctionner en 3 modes plus ou moins détaillés : paranoid (paranoïaque), server (serveur) et workstation (station de travail). Le premier étant le plus verbeux, on le réservera aux serveurs spécialisés (comme les pare-feu). Le deuxième mode, choisi par défaut, est recommandé pour les serveurs. Le dernier, prévu pour les stations de travail, élimine encore plus de messages.
Dans tous les cas, il faudra probablement paramétrer logcheck pour exclure des messages supplémentaires (selon les services installés) sous peine d'être envahi chaque heure par une multitude de messages inintéressants. Leur mécanisme de sélection étant relativement complexe, il faut lire à tête reposée le document /usr/share/doc/logcheck-database/README.logcheck-database.gz pour bien le comprendre.
Plusieurs types de règles sont appliqués :
  • celles qui qualifient un message comme résultant d'une tentative d'attaque (elles sont stockées dans un fichier du répertoire /etc/logcheck/cracking.d/) ;
  • celles qui annulent cette qualification (/etc/logcheck/cracking.ignore.d/) ;
  • celles qui qualifient un message comme une alerte de sécurité (/etc/logcheck/violations.d/) ;
  • celles qui annulent cette qualification (/etc/logcheck/violations.ignore.d/) ;
  • et enfin celles qui s'appliquent à tous les messages restants (les System Events, ou événements système).
Un événement système sera systématiquement signalé, sauf si une règle de l'un des répertoires /etc/logcheck/ignore.d.{paranoid,server,workstation}/ dicte de l'ignorer. Évidemment, seuls les répertoires correspondant à des niveaux de verbosité supérieurs ou égaux au niveau sélectionné sont pris en compte.

14.3.2. Surveillance de l'activité

14.3.2.1. En temps réel

top est un utilitaire interactif qui affiche la liste des processus en cours d'exécution. Par défaut, son critère de tri est l'utilisation actuelle du processeur (touche P), mais on peut opter pour la mémoire occupée (touche M), le temps processeur consommé (touche T) ou le numéro de processus ou PID (touche N). La touche k (comme kill) nécessite un numéro de processus à tuer. r (comme renice) change la priorité d'un processus.
Si le processeur semble être surchargé, il est ainsi possible d'observer quels processus se battent pour son contrôle ou consomment toute la mémoire disponible. Il est intéressant en particulier de vérifier si les processus qui consomment des ressources correspondent effectivement aux services réels que la machine héberge. Un processus au nom inconnu tournant sous l'utilisateur www-data doit immédiatement attirer l'attention : la probabilité est forte que cela corresponde à un logiciel installé et exécuté sur la machine en exploitant une faille de sécurité d'une application web…
top est un outil de base très souple et sa page de manuel explique comment en personnaliser l'affichage pour l'adapter aux besoins et aux habitudes de chacun.
L'outil graphique gnome-system-monitor est similaire à top, et il propose sensiblement les mêmes fonctionnalités.

14.3.2.2. Historique

La charge du processeur, le trafic réseau et l'espace disque disponible sont des informations qui varient en permanence. Il est souvent intéressant de garder une trace de leur évolution pour mieux cerner l'usage qui est fait de l'ordinateur.
Il existe de nombreux outils dédié à cette tâche. La plupart peuvent récupérer des données via SNMP (Simple Network Management Protocol, ou protocole simple de gestion du réseau) afin de centraliser ces informations. Cela permet en outre de récupérer des informations sur des éléments du réseau qui ne sont pas nécessairement des ordinateurs (comme des routeurs).
Ce livre traite en détail de Munin (voir Section 12.4.1, « Mise en œuvre de Munin ») dans le cadre du Chapitre 12, Administration avancée. Debian dispose également de cacti. Il est un peu plus complexe à mettre en œuvre : l'usage de SNMP est inévitable et malgré une interface web, les concepts de configuration restent difficiles à appréhender. La lecture de la documentation HTML (/usr/share/doc/cacti/html/index.html) sera indispensable si l'on souhaite le mettre en œuvre.

14.3.3. Détection des changements

Une fois le système installé et configuré, l'état de la majorité des fichiers et répertoires (hors données) n'a pas de raison d'évoluer (sauf mises à jour de sécurité). Il est donc intéressant de s'assurer que c'est bien le cas : tout changement inattendu est alors suspect. Les outils présentés dans cette section permettent de surveiller tous les fichiers et de prévenir les administrateurs en cas d'altération inattendue, ou alors simplement de diagnostiquer l'étendue des altérations.

14.3.3.1. Audit des paquets avec dpkg --verify

dpkg --verify (ou dpkg -V) est un outil intéressant qui permet de trouver quels fichiers installés ont été modifiés (potentiellement par un attaquant), mais cette information est à prendre avec précaution. Pour faire son travail, dpkg utilise les sommes de contrôle stockée dans sa propre base de données, qui est elle-même stockée sur le disque dur (dans le fichier /var/lib/dpkg/info/paquet.md5sums) ; un attaquant minutieux pourra donc mettre à jour ces fichiers pour qu'ils correspondent aux nouvelles sommes de contrôle des fichiers corrompus.
La commande dpkg -V vérifie tous les paquets installés, et affiche une ligne pour chaque fichier qui échoue au test d'intégrité. Le format de sortie est le même que celui de rpm -V, où chaque caractère correspond à un test sur une métadonnée spécifique. Malheureusement, dpkg ne stocke pas toutes les métadonnées requises pour tous les tests, et n'affichera donc que des points d'interrogation pour la plupart. À l'heure actuelle, seul le test de somme de contrôle peut afficher un « 5 » (en troisième colonne) en cas d'échec.
# dpkg -V
??5??????   /lib/systemd/system/ssh.service
??5?????? c /etc/libvirt/qemu/networks/default.xml
??5?????? c /etc/lvm/lvm.conf
??5?????? c /etc/salt/roster
Dans l'exemple ci-dessus, dpkg signale un changement dans le fichier de service de SSH que l'administrateur a effectué dans le fichier du paquet au lieu de modifier la configuration avec un fichier /etc/systemd/system/ssh.service (stocké dans /etc comme tout fichier de configuration qui se respecte). dpkg liste également plusieurs fichiers de configuration (identifiés par la lettre « c » du deuxième champ) qui ont été (légitimement) modifiés.

14.3.3.2. Audit des paquets : l'outil debsums et ses limites

debsums est l'ancêtre de dpkg -V, et ce dernier l'a rendu quasiment obsolète. Il souffre des mêmes restrictions que dpkg. Heureusement, il est possible de passer outre une partie de ces restrictions (ce que ne permet pas dpkg).
Comme il n'est pas possible de faire confiance aux fichiers stockés sur le disque, debsums permet d'effectuer ses vérifications à partir de fichiers .deb plutôt qu'à partir de la base de données de dpkg. Pour télécharger les fichiers .deb de confiance de tous les paquets installés, on peut utiliser les téléchargements authentifiés d'APT. Mais cette opération peut être longue et pénible, et n'est donc pas à envisager dans le cadre d'une technique proactive à utiliser de manière routinière.
# apt-get --reinstall -d install `grep-status -e 'Status: install ok installed' -n -s Package`
[ ... ]
# debsums -p /var/cache/apt/archives --generate=all
Attention, cet exemple a employé la commande grep-status du paquet dctrl-tools, qui n'est pas installé en standard.

14.3.3.3. Surveillance des fichiers : AIDE

AIDE (Advanced Intrusion Detection Environment) est un outil qui sert à vérifier l'intégrité des fichiers et à détecter toute altération par rapport à une image du système préalablement enregistrée et validée. Cette dernière prend la forme d'une base de données (/var/lib/aide/aide.db) contenant les caractéristiques de tous les fichiers du système (permissions, horodatages, empreintes numériques, etc.). Cette base de données est initialisée une première fois par aideinit ; elle est ensuite employée pour vérifier quotidiennement (script /etc/cron.daily/aide) que rien n'a changé. Si des changements sont détectés, le logiciel les enregistre dans des fichiers de journalisation (/var/log/aide/*.log) et envoie un courrier à l'administrateur avec ses découvertes.
Le comportement du paquet aide se paramètre grâce à de nombreuses options dans /etc/default/aide. La configuration du logiciel proprement dit se trouve dans /etc/aide/aide.conf et /etc/aide/aide.conf.d/ (en réalité, ces fichiers servent de base à update-aide.conf pour créer /var/lib/aide/aide.conf.autogenerated). La configuration indique quelles propriétés de chaque fichier il faut vérifier. Ainsi, le contenu des fichiers de logs peut varier tant que les permissions associées ne varient pas, mais le contenu et les permissions d'un exécutable doivent être fixes. La syntaxe n'est pas très compliquée, mais elle n'est pas forcément intuitive pour autant. La lecture de la page de manuel aide.conf(5) est donc bénéfique.
Une nouvelle version de la base de données est générée chaque jour dans /var/lib/aide/aide.db.new et peut être utilisée pour remplacer la base officielle si tous les changements constatés étaient légitimes.

14.3.4. Détection d'intrusion (IDS/NIDS)

suricata (du paquet Debian éponyme) est un outil de détection d'intrusions (NIDS — Network Intrusion Detection System) : il écoute en permanence le réseau pour repérer les tentatives d'infiltration et/ou les actes malveillants (notamment les dénis de service). Tous ces événements sont enregistrés dans des fichiers stockés dans /var/log/suricata. Des outils tiers (Kibana/Logstash) permettent de naviguer de manière pratique dans les données collectées.
La configuration de Suricata se fait par le biais du fichier /etc/suricata/suricata-debian.yaml, qui est très long puisque chaque paramètre y est abondamment décrit. A minima, il faudra configurer la plage d'adresses couverte par le réseau local (le paramètre HOME_NET). En pratique, il s'agit de l'ensemble de toutes les cibles d'attaques potentielles. Mais pour tirer le meilleur parti de l'outil, il faudra lire ce fichier dans son intégralité et l'adapter au mieux à la situation locale.
Il faudra également modifier /etc/default/suricata pour y déclarer l'interface réseau à superviser, et y activer le script d'initialisation (en réglant RUN=yes). On pourra aussi régler LISTENMODE=pcap, parce que la valeur par défaut (nfqueue) ne fonctionne pas sans une configuration supplémentaire (le pare-feu netfilter doit être configuré pour passer les paquets à une file d'attente en espace utilisateur gérée par Suricata, via la cible NFQUEUE).
suricata détecte les comportements anormaux sur la foi d'un ensemble de règles de supervision. Un ensemble de ces règles est disponible dans le paquet snort-rules-default. snort est la référence de l'écosystème IDS, et suricata peut réutiliser les règles écrites pour snort. Malheureusement, ce paquet n'est pas disponible dans Debian Jessie, et il faudra se le procurer depuis une autre version de Debian, comme Testing ou Unstable.
Une autre possibilité est d'utiliser oinkmaster (dans le paquet du même nom), qui est capable de télécharger des ensembles de règles Snort depuis des sources externes.