Linux Attitude

Niveau :      
Résumé : trap DEBUG ; PROMPT_COMMAND

Voici comment loguer l'activité d'un utilisateur.

Mais tout d'abord, commençons par apprendre comment envoyer une ligne dans syslog. C'est simple, il suffit d'appeler logger avec les options qui vous intéressent (toutes optionnelles) et un message :

$ logger -i -p local5.info -t bash "$(tty): Bonjour syslog"

On enregistre le pid (option -i) pour permettre la corrélation avec d'autres lignes de logs.

On utilise la facility local5 qui est une sorte de tag utilisé par syslog pour savoir dans quelle catégorie mettre les logs. Les facilities servent essentiellement à faire des règles de tri des logs (par exemple il y a une facility authpriv pour tout ce qui est authentification). Il y a 8 facilities disponible pour les administrateur qui voudraient utiliser des valeurs qui ne sont pas standard. J'ai choisi local5.

On utilise le niveau de log info qui est quelque chose de standard parmi les systèmes de logs en général et permet de filtrer facilement.

On en profite pour loguer le tty en cours pour permettre une corrélation avec la commande last (on ne sait jamais).

Nous avons aussi besoin de la commande capable de nous donner la dernière commande tapée :

# lister la dernière commande sans son numéro
$ fc -ln -1

Il n'y a plus qu'à mettre l'une de ces lignes dans le fichier /etc/profile qui est lu par bash au lancement de sessions interactives :

# envoyer la commande dans syslog pour chaque commande AVANT exécution
$ trap 'logger -i -p local5.info -t bash "$USER $(tty): $(fc -ln -1)"' DEBUG

# envoyer la commande dans syslog pour chaque commande APRES exécution
$ PROMPT_COMMAND='logger -i -p local5.info -t bash "$USER $(tty): $(history 1)"'
# fc ne marche pas correctement dans PROMPT_COMMAND

Pourquoi

Enregistrer cette info peut être utile puisque les logs ne sont pas modifiables par un utilisateur simple. Et si vous avez un serveur syslog centralisé, ils ne le sont même pas par root depuis la machine d'origine.

Mais ceci ne doit pas vous faire oublier eux choses.

Tout d'abord le shell est un processus lancé par l'utilisateur, ce qui veut dire que l'enregistrement de cette information est nécessairement soumis à la bonne volonté de l'utilisateur. Un utilisateur peut supprimer le trap ou remplacer le PROMPT_COMMAND. Et supposons que vous trouviez un moyen pour l'en empêcher, l'utilisateur peut toujours tuer son propre shell, lui faire faire un exec vers un autre shell n'ayant pas de logs, tracer son shell pour modifier son activité etc.

Ensuite il faut être bien conscient de ce qu'on enregistre. On enregistre l'activité interactive d'un shell. Ceci exclue les transferts de fichiers (scp,...), les exécutions automatiques (cron, ...), les exécutions via un code (vi script; ./script). Et si on regarde bien ce dernier cas, on comprend qu'à moins de loguer tous les appels systèmes avec tous leurs paramètres, il est impossible de garantir qu'un utilisateur malveillant n'a pas exécuté une commande.

En conclusion ce système n'est pas là pour garantir l'enregistrement de toute activité d'un utilisateur plus ou moins malveillant, mais ça peut être une piste de recherche parmi d'autres lorsqu'un problème survient (qui a supprimé ma libc ?).

Niveau :      
Résumé : debsums ; dpkg -S ; apt-get install --reinstall

Si vous avez bidouillé une debian en installant un logiciel sans passer par dpkg par exemple, ou si quelqu'un vous a fait une mauvaise blague et qu'il y a des problèmes dans les logiciels installés, alors il y a un moyen pour vérifier si le problème vient d'un fichier modifié :

$ apt-get install debsums
$ debsums -c

Debsums est un outil debian qui fait un hash de tous les fichiers installés par des paquets debian et le compare au hash provenant du paquet original. L'option -c permet de lister tous les fichiers qui posent problème. Cela ne vous prémunit pas des attaquants qui pourraient aussi modifier la base des paquets, mais c'est utile pour toute manipulation plus ou moins volontaire du système.

Une fois la liste des fichiers modifiés récupérée, il nous reste à trouver dans quel paquet se trouvait le fichier en question :

$ dpkg -S /bin/ls # nous indique que ls est dans le paquet coreutils

Et maintenant passons à l'étape réparation :

# retélécharge et réinstalle tous les binaires d'un paquet déjà installé
$ apt-get install --reinstall lepaquet

Et pour ceux qui voudraient faire une réinstallation complète de leur distribution :

$ dpkg --get-selections | grep install | awk '{print $1}' | xargs  apt-get install --reinstall --yes

Mais comme dit le commentaire ci-dessous cela ne marche que si vous ne faite pas de pinning et si votre distribution est à jour. La commande suivante permet de ne pas changer les versions des paquets :

$ dpkg -l | grep ^ii | awk ‘{print $2″="$3}’ | xargs apt-get install -reinstall -s -t release-cible