Monitoring is an integral part of any security policy for several reasons. Among them, that the goal of security is usually not restricted to guaranteeing data confidentiality, but it also includes ensuring availability of the services. It is therefore imperative to check that everything works as expected, and to detect in a timely manner any deviant behavior or change in quality of the service(s) rendered. Monitoring activity can help detecting intrusion attempts and enable a swift reaction before they cause grave consequences. This section reviews some tools that can be used to monitor several aspects of a Debian system. As such, it completes
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.
The list of monitored files is stored in /etc/logcheck/logcheck.logfiles
; the default values work fine if the /etc/rsyslog.conf
file has not been completely overhauled.
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.
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.
The gnome-system-monitor
graphical tool is similar to top
and it provides roughly the same features.
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. Auditing Packages with dpkg --verify
dpkg --verify
(or dpkg -V
) is an interesting tool since it allows finding what installed files have been modified (potentially by an attacker), but this should be taken with a grain of salt. To do its job it relies on checksums stored in dpkg's own database which is stored on the hard disk (they can be found in /var/lib/dpkg/info/package.md5sums
); a thorough attacker will therefore update these files so they contain the new checksums for the subverted files.
Running dpkg -V
will verify all installed packages and will print out a line for each file with a failing test. The output format is the same as the one of rpm -V
where each character denotes a test on some specific meta-data. Unfortunately dpkg
does not store the meta-data needed for most tests and will thus output question marks for them. Currently only the checksum test can yield a "5" on the third character (when it fails).
#
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
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.3.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 work-arounds).
Since the data on the disk cannot be trusted, debsums
offers to do its checks based on .deb
files instead of relying on dpkg's database. To download trusted .deb
files of all the packages installed, we can rely on APT's authenticated downloads. This operation can be slow and tedious, and should therefore not be considered a proactive technique to be used on a regular basis.
#
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 grep-dctrl, 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
(in the Debian package of the same name) is a 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-debian.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 /etc/default/suricata
to define the network interface to monitor and to enable the init script (by setting RUN=yes
). 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 behaviour, 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. Unfortunately that package is missing from Debian Jessie and should be retrieved from another Debian release like Testing or Unstable.
Alternatively, oinkmaster
(in the package of the same name) can be used to download Snort rulesets from external sources.