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é
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.
When the system seems to be overloaded, top is a great tool to see which processes are competing for processor time or consume too much memory. In particular, it is often interesting to check if the processes consuming resources match the real services that the machine is known to host. An unknown process running as the www-data user should really stand out and be investigated, since it is probably an instance of software installed and executed on the system through a vulnerability in a web application.
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.
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).
This book deals with Munin in some detail (see
Section 12.4.1, « Mise en œuvre de Munin ») as part of
Chapitre 12: « Administration avancée ». Debian also provides a similar tool,
cacti. Its deployment is slightly more complex, since it is based solely on SNMP. Despite having a web interface, grasping the concepts involved in configuration still requires some effort. Reading the HTML documentation (
/usr/share/doc/cacti/html/Table-of-Contents.html) should be considered a prerequisite.
14.3.3. Avoiding Intrusion
Attackers try to get access to servers by guessing passwords, which is why strong passwords must always be used. Even then, you should also establish measures against brute-force attacks. A brute-force attack is an attempt to log into an unauthorized software system by performing multiple login attempts in a short period of time.
The best way to stop a brute-force attack is to limit the number of login attempts coming from the same origin, usually by temporarily banning an IP address.
Fail2Ban is an intrusion prevention software suite that can be configured to monitor any service that writes login attempts to a log file. It can be found in the package fail2ban.
Fail2Ban is configured through a simple protocol by fail2ban-client, which also reads configuration files and issues corresponding configuration commands to the server, fail2ban-server. It has four configuration file types, all stored in /etc/fail2ban/:
fail2ban.conf. Global configuration (such as logging).
filter.d/*.conf. Filters specifying how to detect authentication failures. The Debian package already contains filters for many common programs.
action.d/*.conf. Actions defining the commands for banning and “unbanning“ of IP addresses.
jail.conf. It is where jails, the combinations of filters and actions, are defined.
Let us have a look at the configuration of sshd in /etc/fail2ban/jail.conf to better understand how Fail2Ban works...
[...]
[DEFAULT]
[...]
bantime = 10m
[...]
findtime = 10m
[...]
maxretry = 5
[...]
[sshd]
port = ssh
logpath = %(sshd_log)s
backend = %(sshd_backend)s
Fail2Ban will check for failed login attempts for sshd using Python regular expressions defined in /etc/fail2ban/filter.d/sshd.conf against the log file of sshd, which is defined in the variable sshd_log in the file /etc/fail2ban/paths-common.conf. If Fail2Ban detects five failed login attempts within 10 minutes, it will ban the IP address where those attempts originated for 10 minutes.
To enable, disable, or configure “jails“, the main configuration file /etc/fail2ban/jail.conf is not supposed to be altered. Instead this is supposed to be done in /etc/fail2ban/jail.d/defaults-debian.conf or files within the same directory.
Fail2Ban is a very simple and effective way to protect against the most common brute-force attacks, but it cannot protect against distributed brute-force attacks, which is when an attacker uses a large number of machines spread around the Internet.
A good way to provide extra protection against distributed brute force attacks is to artificially increase the login time after each failed attempt.
14.3.4. Détection des changements
Once the system is installed and configured, and barring security upgrades, there is usually no reason for most of the files and directories to evolve, data excepted. It is therefore interesting to make sure that files actually do not change: any unexpected change would therefore be worth investigating. This section presents a few tools able to monitor files and to warn the administrator when an unexpected change occurs (or simply to list such changes).
14.3.4.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
In the sample above, dpkg reports a change to SSH's service file that the administrator made to the packaged file instead of using an appropriate /etc/systemd/system/ssh.service.d/override.conf override (which would be stored below /etc like any configuration change should be). It also lists multiple configuration files (identified by the "c" letter on the second field) that had been legitimately modified.
14.3.4.2. Audit des paquets : l'outil debsums et ses limites
debsums is the ancestor of dpkg -V and is thus mostly obsolete. It suffers from the same limitations than dpkg. Fortunately, some of the limitations can be worked-around (whereas dpkg does not offer similar workarounds).
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.
debsums can be run frequently as a cronjob setting CRON_CHECK in /etc/default/debsums. To ignore certain files outside the /etc directory, which have been altered on purpose or which are expected to change (like /usr/share/misc/pci.ids) you can add them to /etc/debsums-ignore.
14.3.4.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.5. Détection d'intrusion (IDS/NIDS)
suricata (in the Debian package of the same name) is an NIDS — a
Network Intrusion Detection System. Its function is to listen to the network and try to detect infiltration attempts and/or hostile acts (including denial of service attacks). All these events are logged in multiple files in
/var/log/suricata. There are third party tools (Kibana/logstash) to better browse all the data collected.
Configuring suricata involves reviewing and editing /etc/suricata/suricata.yaml, which is very long because each parameter is abundantly commented. A minimal configuration requires describing the range of addresses that the local network covers (HOME_NET parameter). In practice, this means the set of all potential attack targets. But getting the most of it requires reading it in full and adapting it to the local situation.
On top of this, you should also edit it to define the network interface. You might also want to set LISTENMODE=pcap because the default LISTENMODE=nfqueue requires further configuration to work properly (the netfilter firewall must be configured to pass packets to some user-space queue handled by suricata via the NFQUEUE target).
To detect bad behavior, suricata needs a set of monitoring rules: you can find such rules in the snort-rules-default package. snort is the historical reference in the IDS ecosystem and suricata is able to reuse rules written for it.
Alternatively, oinkmaster (in the package of the same name) can be used to download Snort rule sets from external sources.
