Utiliser auditd sur Mac OS X et FreeBSD – 1

FreeBSD et les versions récentes de Mac OS X sont livrées avec un système d'audit intégré, dérivé du Basic Security Module de SUN, et disponible en logiciel libre sous le nom d'OpenBSM. Ce système d'audit se décompose en deux parties : un ensemble d'appels systèmes dédiés et de librairies d'un côté, et des logiciels "utilisateur" de l'autre. Sauf précision contraire, les explications présentées ici sont valables à la fois pour FreeBSD 7 et 8, et Mac OS X 10.6. Dans cette série d'articles je ne vais aborder que l'aspect "utilisateur" du système d'audit : comment l'activer, comment le configurer, comment exploiter les résultats.
Le système d'audit fourni par OpenBSM a pour but la surveillante des actions des utilisateurs. Un certain nombre d'évènements peuvent être mis sous surveillance, pour tout ou partie des utilisateurs. Quand le système d'exploitation détecte qu'un utilisateur sous surveillance génère un des évènements à surveiller, il averti le démon auditd qui se charge de reporter cet évènement dans un fichier de log.
On parle ici d'évènements de bas niveau, c'est à dire que le système d'audit ne peut pas dire que tel utilisateur à envoyé un email ou passé quinze minutes à coder en AppleScript. Par contre, il est capable de dire qu'un utilisateur à ouvert un fichier en écriture, ou juste en lecture, ou qu'il a exécuté un programme, etc.
On parle donc d'un système d'audit de sécurité, totalement sans rapport avec des logiciels comme SLife.

Activation du système d'audit
Configuration
Configuration : quid des utilisateurs comme www ?
Exploiter les résultats de l'audit

Activation du système d'audit

Sous FreeBSD 7 et 8, le noyau est déjà compilé avec options AUDIT, il ne reste donc qu'à lancer le démon auditd en ajoutant la ligne suivante au fichier /etc/rc.conf :

auditd_enable="YES"

puis en lançant le démon à la main :

sudo /etc/rc.d/auditd start

Sous Mac OS X 10.6, auditd est lancé d'office par launchd, il n'y a rien à faire.

Configuration

Une fois lancé, le système d'audit va enregistrer très peu d'évènements par défaut. Il convient donc de faire quelques réglages en fonction de ce que l'on cherche à accomplir.
Les fichiers de configuration d'auditd se trouvent dans le répertoire /etc/security où seul root peut écrire.

audit_class : décrit les différentes classes d'évènements qu'il est possible de surveiller. Il est sage de ne pas éditer ce fichier.
audit_control : lisible seulement par root, ce fichier défini la politique d'audit par défaut.
audit_event : le grand frère de audit_class, on ne le modifie pas.
audit_user : le fichier de réglages par utilisateur. Il complète audit_control et n'est lisible que par root.
audit_warn : un fichier exécutable qui est lancé quand auditd manque de place sur le disque pour écrire les logs.

Pour un usage courant, seuls les fichiers audit_control et audit_user sont intéressants. La première chose à faire est d'aller lire leur page man respective.

Par défaut, le contenu du fichier audit_control est le suivant :

dir:/var/audit
flags:lo,aa
minfree:5
naflags:lo,aa
policy:cnt,argv
filesz:2M
expire-after:10M

Avec ces valeurs, auditd ne va répertorier que les évènements des classes "lo" (login/logout) et "aa" (authentification/autorisation). Et il va le faire pour l'ensemble des utilisateurs.
Attention : après avoir lu le man audit_control, vous serez peut être tenté d'ajouter le champs "host" pour compléter la configuration. N'en faites rien. Cela peut perturber les outils utilisateur et rendre l'exploitation des résultats hasardeuse, voire impossible.
Le contenu de audit_user quant à lui nous permet de préciser des flags en se basant sur le login des utilisateurs. Par défaut, le fichier audit_user contient :

root:lo:no

C'est à dire que, quelque soit la liste des flags audit_control, les évènements de la classe "lo" seront suivis pour l'utilisateur root, et les évènements de la classe "no" (invalides) ne seront jamais suivis.
Vous pouvez immédiatement vérifier que votre système d'audit fonctionne en lisant en direct les évènements qu'il enregistre. Il suffit pour cela de taper la commande suivante en root (ou via sudo) :

# praudit /dev/auditpipe

Utilisez alors une autre fenêtre de terminal pour gérer des traces. Sous Mac OS X vous pouvez faire un sudo, ou simplement fermer la fenêtre de terminal, par exemple. Vous pourrez alors lire des choses comme cela :

header,104,11,user authentication,0,Wed Jun  1 14:53:39 2011, + 965 msec
subject,root,root,wheel,root,wheel,26712,0,0,0.0.0.0
text,Authentication for user <patpro>
return,success,0
trailer,104
header,68,11,logout - local,0,Wed Jun  1 15:36:12 2011, + 554 msec
subject,patpro,root,patpro,patpro,patpro,28079,28079,0,0.0.0.0
return,success,0
trailer,68

Nous en reparlerons dans le dernier article de la série.

Faites bien attention aux flags que vous allez régler. Dans certains cas, le nombre d'évènements enregistrés par le système d'audit peut être extrêmement élevé. Par défaut peu de choses sont soumises à l'audit, si bien qu'en 18 mois sur une station de travail, le contenu de /var/audit représente moins de 10 Mo. A contrario, sur un serveur web assez actif, où les classes d'audit sont "fd,^fc,ex:no,fc", on dépasse les 43 Mo en a peine 4 heures d'audit.

Il faut bien comprendre que l'activation de l'audit pour un utilisateur ne se produit qu'au moment de la première connexion de l'utilisateur au système. Prenons un exemple. Le fichier audit_user contient :

root:lo:no
patpro:fc,fd,ex:

Donc pour l'utilisateur patpro, les créations, ouvertures, suppression de fichier, ou exécutions de programmes doivent être suivis. Cet utilisateur a une crontab qui tourne toutes les nuits et télécharge un fichier. Pourtant, auditd ne capturera aucun de ces évènements tant que l'utilisateur patpro ne se sera pas connecté à la machine, alors même que de nombreux évènements correspondants aux critères de l'audit se produisent.
Dès que l'utilisateur patpro se sera connecté à la machine, auditd se mettra à enregistrer toutes les actions correspondant aux classes fc, fd et ex exécutées sous l'UID patpro. Cet audit se poursuivra même après la déconnexion de l'utilisateur.
Par ailleurs, l'UID qui est traquée par auditd n'est pas l'UID apparente, mais l'UID d'origine de l'utilisateur. Si je me connecte en tant que patpro, et que je fais un su - ou un sudo -Es, je deviens root dans le shell (UID apparente), mais je reste patpro aux yeux d'auditd.
Nous verrons dans un second article pourquoi ces deux contraintes sont importantes. D'ici là, vous pouvez approfondir les aspects simples de la configuration en lisant ces différents documents :

http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/audit-config.html
https://ssl.apple.com/support/security/commoncriteria/CommonCriteriaAdminGuide.pdf

Deuxième partie ->

Cognitive Overhead