Sur le plan de la configuration initiale, Nuxeo est aussi en tête. Une fois l'application lancée, on s'y connecte, et on personnalise les réglages via l'interface web directement. Du côté d'Alfresco, rien n'est prévu pour faciliter la configuration au moment du déploiement. Il faut éditer un fichier de configuration à la main dans le quel on indique des chemins de fichiers, des informations de connexions pour le serveur de bases de données, etc. De même seul Nuxeo prévoit un menu d'administration complet gérant entre autres choses les patch de mises à jour, et le redémarrage de l'application.

Mais tout ça n'est pas grand chose. Finalement, on ne passe pas son temps à installer et configurer une application. La différence se fait sur l'usage.

En terme d'ergonomie, c'est Nuxeo qui remporte la palme. L'interface est enrichie de fonctions en AJAX, qui permettent par exemple de déplacer un document d'une catégorie à une autre par glisser-déposer, ou bien d'envoyer des documents directement à partir de votre ordinateur vers Nuxeo. Alfresco quant à lui est très en dessous. Tout d'abord il est livré sous la forme de deux applications Alfresco d'un côté, et Share de l'autre. La première se rapproche un peu de Nuxeo DM, mais sans l'AJAX. Pour faire la moindre choses il faut multiplier les clics, c'est assez pénible. La seconde, Share, est plutôt orientée utilisateur final, publication, média "sociaux". Elle propose l'import de documents par glissé-déposé comme Nuxeo, mais elle manque de sobriété. Les documents sont présentés par défaut sous forme de liste de grosses icones aussi inélégantes qu'encombrantes. De nombreuses actions peuvent être faites aussi bien dans Alfresco que dans Share, mais pas toutes. Par exemple je peux utiliser des noms de tags dans le champs de recherche de Share, alors que cela ne fonctionne pas dans Alfresco. Finalement quand on veut faire quelque chose, il faut d'abord se souvenir dans la quelle des deux applications c'est possible (et le plus simple) et s'y connecter. C'est juste n'importe quoi.

La recherche des documents est aussi une dimension importante de la GED. Elle repose sur une indexation du contenu des documents, sur des métadonnées, sur une organisation. J'ai tendance à considérer que l'organisation physique des documents ne doit pas trop peser dans la balance. Il n'y a qu'une manière de classer une facture médicale. Doit-on la ranger dans le dossier "facture", dans le dossier "facture" du dossier "santé" ou dans le dossier "santé" du dossier "facture" ?
Je préfère de loin un système de tags ou de catégories qui me permette d'accoler plus d'une étiquette à un document, et surtout de retrouver tel ou tel document en combinant ces étiquettes dans un champ de recherche. Les tags dans Nuxeo sont assez accessibles. On en ajoute facilement, mais je ne peux pas chercher un document en tapant un ou plusieurs tags dans le champs de recherche. Les tags sont très bien cachés dans Alfresco, et ils sont inutilisables par défaut. A contrario, sans Share les tags sont accessibles, et on peut les utiliser facilement pour une recherche. Malheureusement, il est alors impossible de préciser qu'on souhaite chercher uniquement dans les tags, ce qui réduit l'intérêt de la chose.

La gestion des sauvegardes d'un entrepôt de données est primordiale. Nuxeo étant par défaut entièrement inclus dans un répertoire unique, il n'y a que deux choses importantes à sauvegarder pour que l'application puisse repartir rapidement en cas de désastre : le répertoire de l'application, et la base de données. J'ai déjà un script qui sauvegarde automatiquement mes bases MySQL, mais comme expliqué plus haut, MySQL n'est pas une option. Garder Nuxeo impliquerait donc d'apprendre à gérer des sauvegardes PostgreSQL (dump, rétention, archivage, et restauration), en plus de l'administration courante.
Alfresco est fragmenté, et nécessite un peu plus de préparation pour gérer les sauvegardes, en contrepartie, son support de MySQL m'assure une sauvegarde fonctionnelle immédiatement, et des archives que je sais restaurer sans lire le manuel. Alfresco bénéficie aussi d'un mécanisme de réplication, ce qui permet de bénéficier d'un second serveur de secours (ou de proximité) en cas de panne du serveur habituel.

Au bout du compte, j'ai l'impression que Nuxeo reste une solution intéressante. Ses points faibles ne sont pas si dramatiques, même si pour moi une bonne recherche par tags est primordiale. Alfresco propose des fonctionnalités appétissantes comme la réplication de serveur, une interface orientée utilisateur permettant la recherche par tags (Share). Mais le manque de glisser-déposer et glisser-déplacer, ainsi que le très grand nombre de clics pour la moindre action sont de vrais handicaps dans la phase de remplissage.
Malheureusement pour Nuxeo, je n'ai pas une minute à consacrer à l'apprentissage de PostgreSQL, ce qui laisse une chance à Alfresco de se faire une place sur mon serveur. Comme la migration d'un système à l'autre est totalement illusoire, voire impossible, je vais me laisser encore le temps de la réflexion, avant de charger et classer des centaines de documents dans l'un ou l'autre.

C'est Noël ! Dommage que mes congés soient terminés...

#!/bin/sh

# PROVIDE: nuxeo
# REQUIRE: DAEMON
# BEFORE: LOGIN

# Define these nuxeo_* variables in one of these files:
#       /etc/rc.conf
#       /etc/rc.conf.local
#
# DO NOT CHANGE THESE DEFAULT VALUES HERE
#
nuxeo_enable="${nuxeo_enable-NO}"
nuxeo_user="${nuxeo_user-nuxeo}"
nuxeo_home="/CHEMIN/DE/nuxeo"

. /etc/rc.subr

name="nuxeo"
rcvar=`set_rcvar`
start_cmd=${name}_start
stop_cmd=${name}_stop

nuxeo_start()
{
cd $nuxeo_home
$nuxeo_auditflags sudo -u $nuxeo_user ./bin/nuxeoctl startbg
}

nuxeo_stop()
{
cd $nuxeo_home
sudo -u $nuxeo_user ./bin/nuxeoctl stop
}

load_rc_config $name

run_rc_command "$1"

Une fois le fichier créé, rempli, et rendu exécutable, il faut ajouter ces quelques lignes à votre fichier /etc/rc.conf :

nuxeo_enable="YES"
nuxeo_user="NUXEO_USER"

Vous remplacerez bien sûr NUXEO_USER par le nom du compte utilisateur qui fera tourner l'application Nuxeo DM. Après cela, les commandes /usr/local/etc/rc.d/nuxeo restart, /usr/local/etc/rc.d/nuxeo stop et /usr/local/etc/rc.d/nuxeo start doivent fonctionner.
Attention, suivant la puissance de votre machine, et l'état de remplissage de Nuxeo, le temps de lancement peut varier énormément.

Côté mise à jour, vous pouvez accéder aux "hotfix" officiels, gratuitement pendant 30 jours, moyennant une inscription sur le site web de Nuxeo. L'inscription se passe facilement, par contre les mise à jour sont délicates et nécessitent de suivre scrupuleusement les instructions du support Nuxeo. Notamment, relancez bien l'application entre chaque mise à jour.

Il existe plusieurs moyens de présenter Nuxeo DM au travers d'un proxy Apache. J'ai choisi d'utiliser mod_proxy. Avec mod_proxy, la configuration est assez standard. Tout, ou presque, est réglé en 3 lignes si on se contente de l'HTTP. Mais pour sécuriser mes connexions à Nuxeo, qui contiendra mes documents personnels et confidentiels, j'ai décidé d'utiliser HTTPS.
J'ai donc un virtual host Apache, et un certificat SSL associé, dans le quel j'inclue les directives de mod_proxy.

<VirtualHost IP.DU.SER.VEUR:443>
   ServerName DOMAINE.TLD:443
   UseCanonicalName On
   DocumentRoot "/chemin/de/nuxeo/"

   SSLEngine on
   #... config SSL ...

   RequestHeader append nuxeo-virtual-host "https://DOMAINE.TLD/"
   <IfModule proxy_module>
     ProxyRequests Off
     <Proxy *>
        Order deny,allow
        Allow from all
     </Proxy>
     ProxyPass /nuxeo/ http://localhost:8080/nuxeo/
     ProxyPassReverse /nuxeo/ http://localhost:8080/nuxeo/
     ProxyPreserveHost On
   </IfModule>

</VirtualHost>

Ça c'est d'après la documentation. En réalité, ce n'est pas suffisant. Tout d'abord, il faut bien placer la directive RequestHeader à l'extérieur du bloc proxy_module, sinon elle est juste ignorée par le serveur. Il ne m'a pas fallu moins qu'un tcpdump pour localiser le problème.
J'ai aussi constaté qu'avec ces directives, la première connexion à l'application se fait bien, puis on est immédiatement redirigé vers le même virtual host mais sur le port 80. Je règle le problème avec une directive de redirection dans le vhost http :

<VirtualHost *>
    ServerName DOMAINE.TLD
    DocumentRoot /chemin/de/nuxeo
    Redirect / https://DOMAINE.TLD/
</VirtualHost>

Ce n'est pas totalement satisfaisant, mais faute de mieux, cela fonctionne parfaitement.
En relançant Apache à ce stade, on obtient un proxy fonctionnel et sécurisé par SSL pour Nuxeo.

Avant d'aller plus loin, on peut prendre quelques minutes pour créer une base de données MySQL (ou autre) et un utilisateur MySQL associé à cette base. C'est ce compte de base de données qu'il faudra fournir au moment de la configuration de Nuxeo.

Je fais totalement l'impasse sur la configuration de Nuxeo DM dans le "wizard", elle est bien documentée, et plutôt simple. Il suffit de lancer l'application par la commande ad-hoc si ce n'est pas déjà fait :

# cd /chemin/du/répertoire/nuxeo
# sudo -u nuxeo_user ./bin/nuxeoctl startbg

Ensuite on se connecte à l'adresse https://DOMAINE.TLD/nuxeo et on peut entamer la configuration.

Côté pré-requis, il faut tout d'abord installer le Java Runtime Environment, et le Java Development Kit. Sous FreeBSD, il faut donc installer les ports java/diablo-jdk16 et java/diablo-jre16. Pour une question de licence, il faut télécharger à la main les packages nécessaires chez Oracle. Il suffit simplement de suivre les instructions obtenues pour chaque port au moment du make. Par exemple :

$ cd /usr/ports/java/diablo-jdk16/
$ make
===>  License check disabled, port has not defined LICENSE
===>  Found saved configuration for diablo-jdk-1.6.0.07.02_12

 Because of licensing restrictions, you must fetch the distribution
 manually.

 Please open http://www.oracle.com/technetwork/java/javase/downloads/index.html
 in a web browser and follow the "Download" link for
 "JDK DST Timezone Update Tool - 1_3_42" to obtain the
 time zone update file, tzupdater-1_3_42-2011k.zip.

 Please place the downloaded file(s) in /usr/ports/distfiles.
 ...

Une fois les ports java/diablo-jdk16 et java/diablo-jre16 installés, il faut installer un serveur web comme Apache 2.2, un serveur de bases de données (MySQL ou PostgreSQL par exemple), et à minima pdftohtml. Il est aussi possible d'installer OpenOffice, mais comme il n'existe pas de version "headless" dans les ports de FreeBSD, cela vous embarque dans l'installation complète avec gestionnaire de fenêtre et tutti quanti. Une calamité.
Pour utiliser l'application sur une connexion sécurisée (HTTPS), il faut qu'Apache dispose d'un certificat SSL adéquat.

Quand tout ceci est installé et configuré, il faut encore ajouter un compte utilisateur pour l'application Nuxeo. Les paresseux pourront la faire tourner sous le compte www. J'ai préféré un utilisateur indépendant, plus facile à tracer via auditd et l'accounting.

On peut alors télécharger et décompresser le package multiplateforme à partir du site internet de Nuxeo. On obtient un répertoire nommé nuxeo-dm-5.4.2-tomcat. J'ai pour habitude d'exploiter une application à partir d'un répertoire ne portant pas de numéro de version. On aura intérêt à renommer ce répertoire en nuxeo, car ici, faire un lien symbolique de nuxeo-dm-5.4.2-tomcat vers nuxeo ne donne pas vraiment satisfaction.
Pour en finir avec les fichiers, il faut faire un chown -R sur le répertoire nuxeo pour que les fichiers appartiennent tous à l'utilisateur non privilégié que l'on a créé plus haut.

Ensuite, comme nous sommes sur FreeBSD et pas Linux, il faut revoir certains scripts shell. Ces derniers ont un shebang qui pointe vers /bin/bash alors que notre bash est dans /usr/local/bin/. Les scripts à modifier sont les suivants : bin/monitorctl.sh, bin/nuxeoctl, bin/pack.

Arrivé là, il est intéressant de lancer l'application via la ligne de commande pour tester qu'au moins elle se lance et répond sur le port 8080 :

# cd nuxeo
# sudo -u nuxeo_user ./bin/nuxeoctl startbg
...
No current configuration, generating files...
Configuration files generated.
Server started with process ID 1438.

Le serveur est lancé, et il écoute bien sur le port 8080 :

# netstat -alnf inet | grep 8080
tcp4       0      0  *.8080                 *.*                    LISTEN

Ce que l'on peut aisément vérifier avec un client HTTP en ligne de commande, ou un coup de telnet :

$ curl http://127.0.0.1:8080
<META HTTP-EQUIV="refresh" CONTENT="0;URL=/nuxeo">

On a maintenant une application Tomcat/Java qui tourne sur notre serveur FreeBSD, sous un compte utilisateur dédié. Il reste à brancher devant un proxy Apache HTTPS, créer un script de démarrage automatique pour l'application, et configurer cette dernière.

La suite au prochain épisode :)

Exploiter les résultats de l'audit

Dans le premier article j'ai mentionné très succinctement une commande qui permet de lire les logs d'audit en temps réel. Et finalement la consultation de ces logs est sans doute la chose la plus intéressante. Personne n'a envie d'activer l'audit sur une machine pour le simple plaisir de remplir son disque dur. Tout ceci doit avoir une raison d'être : pouvoir ensuite (ou en temps réel) exploiter les logs d'auditd.
Comme précisé par défaut dans le fichier audit_control, la taille maximale d'un fichier de log d'audit est 2Mo, et les anciens fichiers sont supprimés pour que le volume total ne dépasse pas 10 Mo :

filesz:2M
expire-after:10M

Il existe plusieurs options intéressantes pour expire-after que je vous laisse découvrir dans le man audit_control. Sachez seulement qu'en fonction de ce que vous choisirez de surveiller, vous allez devoir modifier ces paramètres. Sur une machine assez sollicitée, 10 Mo de log peuvent représenter moins d'une heure d'audit. Si vous avez besoin d'enquêter sur un événement de la veille, il vous sera alors impossible d'en retrouver la trace.

Il y a deux moyens immédiats d'exploiter les logs d'audit. Vous pouvez soit les suivre en direct comme je l'ai montré dans le premier article via la commande praudit /dev/auditpipe, soit les étudier a posteriori. C'est sans doute cette option qui sera le plus souvent utilisée. Vous pouvez ainsi utiliser praudit pour lire les fichiers de logs enregistrés dans /var/audit/.
Comme les logs d'audit peuvent grossir très vite, et qu'on cherche souvent l'aiguille dans la meule de foin, il est bon de pouvoir réduire les logs à ce que l'on cherche avant de les afficher. C'est le rôle de la commande auditreduce. Cette commande permet de filtrer les logs selon une série de critères tels que la date, le ou les flags d'évènement (fc, ex, ...), l'UID, le ou les évènements précis (tels qu'ils sont répertoriés dans le fichier audit_event), et d'autres encore.
auditreduce s'utilise sous la forme générale suivante :

auditreduce paramètres fichiers_de_log | praudit

Comme les logs sont binaires, il est impératif de les traduire via praudit.
Sur Mac OS X, voici un exemple de ce que l'on peut obtenir avec la configuration par défaut d'auditd. Je cherche ici tous les événements pour l'UID réelle patpro ayant eu lieu après le 5 juin 2011 à 12h. Je fais cette recherche dans le fichier de log ouvert par auditd.

# auditreduce -a 2011060512 -r patpro /var/audit/current | praudit
header,68,11,logout - local,0,Sun Jun  5 15:47:35 2011, + 877 msec
subject,patpro,root,patpro,patpro,patpro,10485,10485,0,0.0.0.0
return,success,0
trailer,68
header,68,11,logout - local,0,Sun Jun  5 15:57:05 2011, + 718 msec
subject,patpro,root,patpro,patpro,patpro,10948,10948,0,0.0.0.0
return,success,0
trailer,68

Ces deux évènements correspondent à la fermeture d'une fenêtre de terminal. On voit que chacun d'eux commence par "header" et termine par "trailer". Je ne vais pas couvrir l'intégralité des champs d'un enregistrement de log d'audit, il y a beaucoup trop de possibilités. Reportez-vous au man audit.log pour le détail. Ceux qui ont un intérêt sinon universel, au moins relativement général, sont subject qui décrit le sujet qui a généré les évènements, path qui décrit le chemin du fichier concerné, et return qui indique si l'opération a réussi ou non.
Le champ subject contient les UID et GID (audit UID, effective UID et GID, real UID et GID), le PID, et le port et l'IP de la machine connectée.
Le champ path donne par exemple le chemin d'un exécutable lancé, ou le chemin d'un fichier créé/modifié/détruit.
Le champ return indique success ou failure.

Voici un second exemple, pour un serveur Apache sur Mac OS X, lancé via l'utilitaire setaudit :

header,127,11,execve(2),0,Wed Jun  1 14:50:44 2011, + 667 msec
exec arg,ls
path,/bin/ls
path,/bin/ls
attribute,100555,root,wheel,234881026,24767,0
subject,_www,_www,_www,_www,_www,26696,100031,0,0.0.0.0
return,success,0
trailer,127
header,131,11,open(2) - write,creat,trunc,0,Wed Jun  1 14:50:44 2011, + 735 msec
argument,3,0x1a4,mode
argument,2,0x601,flags
path,/Users/patpro/Sites/testFile.txt
subject,_www,_www,_www,_www,_www,26694,100031,0,0.0.0.0
return,failure : Permission denied,4294967295
trailer,131

La requête http s'est faite sur la machine locale (http://localhost/...) vers un fichier PHP dont le code exécute la commande system("ls"); puis tente d'écrire un fichier testFile.txt.
Le premier évènement enregistré montre le lancement de la commande ls, avec succès. Le second évènement montre la tentative d'écriture du fichier testFile.txt qui échoue.
Cet exemple montre donc clairement comment les logs d'audit peuvent permettre, par exemple, de remonter la trace d'une compromission d'un serveur web. Notez que si j'avais lancé le serveur web normalement, sans utiliser setaudit, la ligne subject aurait indiqué subject,patpro,_www,_www,_www,_www..., patpro étant l'UID suivi par auditd. Il aurait donc fallu que le fichier audit_user indique les flags ex et fc pour le login patpro, sans quoi les évènements pour le serveur web n'auraient pas été enregistrés.

auditreduce permet de filtrer les évènements selon un critère beaucoup plus fin que le simple flag (fc, fd, ex, ...). Il vous autorise à différencier chaque évènement avec la granularité du fichier audit_event. Si vous avez eu la curiosité d'ouvrir ce fichier, vous savez qu'il contient plus de 600 lignes de ce genre :

0:AUE_NULL:indir system call:no
1:AUE_EXIT:exit(2):pc
2:AUE_FORK:fork(2):pc
3:AUE_OPEN:open(2) - attr only:fa
4:AUE_CREAT:creat(2):fc
5:AUE_LINK:link(2):fc
6:AUE_UNLINK:unlink(2):fd
7:AUE_EXEC:exec(2):pc,ex
8:AUE_CHDIR:chdir(2):pc
9:AUE_MKNOD:mknod(2):fc

La nomenclature est simple. Chaque colonne est séparée des autres par ":". La première donne le numéro de référence d'un événement, la seconde donne son nom, la troisième le nom de la fonction correspondante, avec éventuellement un complément d'information, et la dernière indique le ou les flags correspondants.
Sur les 10 lignes citées au dessus, vous notez qu'il y a déjà 4 évènements correspondants au flag pc, et 3 au flag fc. Donc si on se contente de faire un filtrage sur pc ou fc, on peut remontrer beaucoup trop d'évènements par rapport à ce que l'on cherche vraiment. Par ailleurs, dans certains cas, un même évènement peut correspondre à plusieurs flags contradictoires. Par exemple :

75:AUE_OPEN_RTC:open(2) - read,creat,trunc:fc,fd,fr,fa,fm

Cet évènement peut être détecté si on souhaite suivre les flags fc, fd, fr, fa ou fm !
C'est ici qu'intervient le contenu de la ligne header des logs d'audit. En effet, l'entête indique clairement l'évènement qui est capturé. Par exemple open(2) - write,creat,trunc. Il suffit alors de chercher son nom dans le fichier audit_event pour pouvoir s'en servir de clé de filtrage :

grep 'open(2) - write,creat,trunc' /etc/security/audit_event
79:AUE_OPEN_WTC:open(2) - write,creat,trunc:fc,fd,fw,fa,fm

Il est alors possible d'utiliser AUE_OPEN_WTC comme ceci pour obtenir en sortie une sélection parfaite des évènements qu'on recherche :

auditreduce -m AUE_OPEN_WTC -r www -o file=".*/bd/.*" /var/audit/current | praudit

Cette commande permet de trouver tous les évènements AUE_OPEN_WTC pour l'utilisateur www qui ont eu pour cible des fichiers dont le chemin contient la chaîne "/bd/" dans le fichier de log d'audit courant.
Il ne vous reste plus qu'à essayer par vous même !

Bibliographie sommaire

http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/audit-config.html
https://ssl.apple.com/support/security/commoncriteria/CommonCriteriaAdminGuide.pdf
man auditreduce
man auditd
man audit_user
man audit_control
man audit_event
man audit.log
http://forums.freebsd.org/showthread.php?t=23716

Configuration : quid des utilisateurs comme www ?

J'expliquais précédemment que le système d'audit ne peut suivre un utilisateur que si ce dernier se connecte à la machine (par ssh par exemple), et que quelques soient les ruses utilisées (su, sudo...) c'est toujours l'UID réelle de l'utilisateur qui est suivie.

À cause de cela, il est totalement impossible de traquer des évènements appartenant à des utilisateurs qui ne peuvent pas se connecter au système. Ainsi, une ligne comme celle-ci dans audit_user ne permettra de traquer aucun évènement :

# pour freebsd remplacer _www par www
_www:fc,fd,ex:

Il serait pourtant très intéressant de savoir ce que fait Apache dans votre dos, parfois sous la direction de méchants pirates.
De nos jours, La plupart des serveurs utilisent des protocoles comme l'HTTP qui permettent aux utilisateurs d'accéder aux ressources sans être authentifiés au niveau du système. Les utilisateurs en question n'existent d'ailleurs pas au niveau du système. Néanmoins, les applications web permettent de faire énormément de choses via les langages comme le PHP, y compris d'interagir avec le système, en lançant des commandes, en créant des fichiers, etc.

Si on souhaite qu'auditd puisse contrôler les actions de www, il faut recourir à un artifice. Attention tout de même, ce qui suit est plus proche d'un hack que d'une méthode vraiment propre, et je ne peux pas garantir son fonctionnement correct dans un environnement de production.

En premier lieu il faut installer un programme spécifique, qui va permettre de forcer auditd à suivre les actions pour une UID donnée, sans que l'utilisateur correspondant ait besoin de se connecter à la machine.

curl -LO http://www.freebsd.org/~csjp/setaudit.c
cc -o setaudit -lbsm setaudit.c 

Cela vous donne, si tout se passe bien, le binaire setaudit, que l'on va utiliser sous cette forme :

setaudit -a UID_WWW -m FLAGS /programme/de/lancement/d/apache

Pour suivre les évènements d'exécution de commande sous respectivement FreeBSD et Mac OS X, cela donnera :

setaudit -a www -m ex /usr/local/etc/rc.d/apache22 restart
setaudit -a _www -m ex /usr/sbin/apachectl restart

Ainsi, toutes les commandes lancées par Apache (donc sous l'UID www) sont enregistrées par auditd.
Comme le masque des évènements (les flags de l'argument -m) décrit ce que l'on doit suivre, il est même inutile de renseigner le fichier audit_user.

Pour résumer :

• Si vous souhaitez que l'audit suive les utilisateurs qui se connectent à la machine, vous pouvez régler les classes d'évènements qui seront soumises à l'audit pour l'ensemble des utilisateurs dans le fichier audit_control, et gérer les cas particuliers dans audit_user.
• Si vous souhaitez que l'audit suive des UID "interne", pour traquer tout signe de compromission sur un serveur web, un serveur de mail, etc. il faudra recourir à setaudit pour activer l'audit au moment du lancement du service correspondant.
• Faites attention à la liste de flags que vous choisissez. Le volume des logs d'audit peut grossir très rapidement.

Troisième partie de l'article ->

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 ->

Quand vous avez un millier de chaînes de caractères, dont vous souhaitez retrouver toutes les occurrences dans un gros fichier de 685000 lignes, vous pouvez utiliser grep de deux manières :

1. vous dites à votre ami grep de chercher toutes les chaînes en même temps dans le gros fichier,
2. vous utilisez une boucle pour dire à grep de chercher une chaîne dans le fichier, puis de passer à la chaîne suivante, …

La solution 1 semble la plus intéressante. Une seule commande, pas de boucle, on se dit naturellement que c'est plus économique, et donc plus rapide. La solution 2, on se dit qu'elle est moche, complexe, et que les performances vont être mauvaises.

Petit test grandeur nature sur un serveur FreeBSD 7.x virtualisé, 2 CPU, 2Go de RAM :

Méthode 1 :
grep -i -f liste_emails maillog
opération terminée en 370 min environ.
Méthode 2 :
while read email; do grep -i $email maillog ; done<liste_emails
opération terminée en 1 min 32 s.

Bien sûr, le résultat est le même en terme de contenu, la seule différence est l'ordre des lignes. La méthode moche et supposée lente est juste 240 fois plus rapide que la méthode académique. Shame on you grep. Shame on you.

L'environnement est aussi important. On pourrait se dire qu'avec plus de CPU (en puissance, pas en nombre), plus de RAM, tout irait tellement plus vite. Essayons la même chose sur un Mac Pro Xeon quad-core, avec 12 Go de RAM, sous Mac OS X 10.6.

Méthode 1 : 223 min.
Méthode 2 : 35 min 45 s.

Ce qui prouve une fois de plus que Mac OS X est un gros tromblon quand il s'agit de fork. Comprendre que le coût du lancement d'un programme, en terme de ressources système, est beaucoup plus fort que sur d'autres OS, comme FreeBSD par exemple. Ce qui fait de Mac OS X un très mauvais candidat pour les scripts shell utilisant des boucles de manière très intensive.
On voit aussi que la vitesse d'exécution de la méthode 1 est essentiellement liée à la puissance de calcul du CPU, alors que la vitesse de la méthode 2 est essentiellement liée à la capacité du système d'exploitation de créer des process rapidement.

Pour conclure, j'ai fait un petit test avec awk, sur les mêmes fichiers. Moyennant quelques aménagements triviaux pour transformer le fichier liste_emails en programme awk, j'ai pu lancer la commande awk -f liste_emails maillog qui est l'équivalent de la méthode 1 pour grep. Le temps d'exécution est tombé à moins de 15 minutes sur Mac OS X, et moins de 30 minutes sur le FreeBSD.

* ceux qui ont fait 5 ans d'études dans une autre branche, avant de passer à l'informatique, par exemple.

Dans un premier temps il faut activer, si ce n'est déjà fait, la compatibilité Linux dans le noyau de FreeBSD :

# chargement manuel du module
kldload /boot/kernel/linux.ko
# activation du chargement automatique au démarrage
echo 'linux_enable="YES"' >> /etc/rc.conf 

Ensuite (et pas avant), on peut installer les librairies Linux. Pour FreeBSD 8, il faut installer la version f10 :

portinstall -PP linux_base-f10

Attention, si vous êtes en FreeBSD 64 bits (amd64), le package refusera de s'installer, il faudra alors utiliser :

portinstall linux_base-f10

On termine de préparer l'environnement de compatibilité Linux en montant le système de fichier procfs. Il faut ajouter la ligne suivante au fichier /etc/fstab

linproc         /compat/linux/proc      linprocfs       rw 0 0

puis faire un

mount -a

Enfin, on peut installer le client steam :

portinstall linux-steam

En réalité, c'est seulement un logiciel de mise à jour du client steam qui est installé, il faut lancer la mise à jour pour que la vraie commande steam soit installée. Je fais cette étape deux fois :

cd /usr/local/steam/
./steam
# on attend la fin de l'exécution
# puis on recommence
./steam

Le binaire steam est maintenant installé, à jour, et totalement fonctionnel. Via ce client, il est possible d'installer n'importe quel jeu compatible. Voilà comment procéder pour installer Left 4 Dead 2 :

./steam -command update -game left4dead2 -dir /chemin/du/jeu

On remplacera /chemin/du/jeu par le chemin du répertoire dans le quel on souhaite stocker les fichiers du jeu. Attention, pour Left 4 Dead 2 il y a environ 8 Go à télécharger. Si vous êtes sur de l'UFS, c'est donc 8 Go de stockage qui seront consommés. Si vous êtes sur un volume ZFS avec compression GZip, il faut compter environ 4,2 Go d'espace disque consommé. Le téléchargement est assez long, faites une pause, voire même, lancez la commande avant d'aller vous coucher.

Après cela, le répertoire /chemin/du/jeu contiendra un répertoire left4dead2. Dans ce dernier se trouve un script de lancement qui permet de démarrer le serveur dédié Source : srcds_run.
Voici un exemple de lancement :

cd /chemin/du/jeu/left4dead2
./srcds_run -ip 192.168.1.1 +sv_lan 1

L'option -ip permet d'imposer l'IP sur la quelle le serveur écoute. C'est très utile car le script est d'une bêtise monumentale. En effet, pour une raison que j'ignore, le serveur dédié se lance par défaut en utilisant la toute première IP configurée dans le fichier /etc/rc.conf même si la ligne est commentée !
C'est à dire que si votre rc.conf contient les lignes suivantes :

#ifconfig_em0="inet 192.168.128.201  netmask 255.255.255.0"
ifconfig_em0="inet 193.30.227.216  netmask 255.255.255.192"

et bien cet abruti de serveur tente de se lancer sur l'IP 192.168.128.201, alors que, bien sûr, l'IP n'est pas active. Épargnez votre santé mentale, imposez dès le départ une IP à srcds.
L'option +sv_lan 1 quant à elle impose un fonctionnement sur le LAN uniquement, ce qui permet aisément de tester le fonctionnement du serveur sans l'ouvrir sur le monde.

Vous devrez veiller à quelques points de détail :

• le firewall doit autoriser les connexions TCP et UDP sur les ports 26901 et 27015.
• le jeu peut (doit) être lancé avec un utilisateur non privilégié. Créez un compte pour l'occasion, avec un shell /bin/nologin, et toute autre mesure de protection que vous jugerez nécessaire.
  Attention, faire tourner le jeu avec un utilisateur non privilégié n'est pas forcément très simple, surtout si vous l'avez installé en root. J'ai découvert que lancer le jeu une première fois en root peut régler certains problèmes.
• l'utilisateur en question devra notamment pouvoir écrire dans les répertoires /chemin/du/jeu/left4dead2/update, /chemin/du/jeu/left4dead2/left4dead2 et /chemin/du/jeu/left4dead2/left4dead2/{downloads,logs} et dans les fichiers /chemin/du/jeu/left4dead2/left4dead2/*.cache
• il devra aussi pouvoir exécuter les fichiers /chemin/du/jeu/left4dead2/srcds_run /chemin/du/jeu/left4dead2/srcds_linux

Pour un utilisateur non privilégié, en "nologin", le moyen fiable de lancer le serveur est d'utiliser sudo, dans un screen pour être tranquille :

cd /chemin/du/jeu/left4dead2/
screen nice -n -5 sudo -u utilisateur_steam ./srcds_run -ip 192.168.1.1

Avec tout ceci, votre serveur doit être fonctionnel, et permet déjà de jouer. Le plus dur reste à faire, puisque de toute l'histoire de l'informatique, ce sont les serveurs de jeu qui détiennent la triste palme des logiciels les moins bien documentés au monde. Créez un fichier /chemin/du/jeu/left4dead2/left4dead2/cfg/server.cfg et testez des combinaisons jusqu'à obtenir le résultat souhaité.