L’audit consiste à collecter des données sur l’utilisation des ressources système. Ces données, enregistrées sous forme d’événements, peuvent être utilisées pour déterminer la responsabilité quand aux actions survenues sur ce système.

Il y a un double avantage à activer l’audit sur les systèmes. D’un point de vue sécuritaire, cela ajoute notamment une brique complémentaire à votre « arsenal ». D’un point de vue exploitation, cela permet d’améliorer votre diagnostic, en traçant notamment l’ensemble des actions exécutées sur vos systèmes.

Chez plusieurs clients, l’activation de l’audit m’a permis d’analyser plus efficacement des événements survenus sur des serveurs sur lesquels j’opérais des actions.

Sans être exhaustif, il est important d’évoquer les concepts suivants :

• La stratégie d’audit détermine les caractéristiques d’enregistrement d’audit,
• Les événements (d’audit) sont regroupés en classe d’audit,
• Les enregistrements d’audit sont collectés dans les journaux d’audit,
• Les classes d’audit peuvent être collecter en cas de réussite, d’échec ou les deux,
• Les classes d’audit sont modifiables (ajout de préfix par exemple),
• Des nouvelles classes d’audit peuvent être créées (besoin spécifique),
• Les événements attribuables proviennent des utilisateurs,
• Les événements non attribuables proviennent soit du noyau (interruption) soit avant l’authentification d’un utilisateur,
• Les événements synchrones sont associés à un processus dans le système.

La configuration de l’audit peut s’avérer complexe. C’est pourquoi l’étude de la configuration par défaut permet d’appréhender plus rapidement cette fonctionnalité offerte dans le système Solaris.

Let’s go !!

L’audit est configuré via un service SMF cependant pour piloter ce service il est préférable d’utiliser la commande audit(1M). Par défaut ce service est déjà activé dans Solaris, la commande auditconfig(1M) permet de le vérifier rapidement.

# auditconfig -getcond
audit condition = auditing

Dans le cas contraire, il suffit d’activer le service via la commande audit(1M).

# audit -s

La stratégie d’audit par défaut est « minimale » : afin de minimiser les exigences en matière de stockage et de réduire le nombre de demandes de traitement du système, la plupart des options de la stratégie d’audit ont donc été désactivées. Ce qui peut être judicieux lorsque la disponibilité du système est plus importante que la sécurité (attention votre RSSI dira certainement l’inverse).

# auditconfig -getpolicy
configured audit policies = cnt
active audit policies = cnt

Selon le système installé et vos besoins, la stratégie d’audit devra vraisemblablement  être adaptée. Par exemple dans un environnement exécutant des Zones non Globales (aka containers), il est judicieux de mettre en place une stratégie d’audit permettant d’enregistrer les événements de chaque Zone non Globale. La description des stratégies d’audit est consultable via l’aide mémoire de la commande auditconfig(1M).

Tout comme la stratégie d’audit, il n’y a qu’une seule classe d’audit configurée par défaut. Celle-ci enregistre uniquement les événements liés aux connexions des utilisateurs. Aussi bien pour les événements attribuables…

# auditconfig -getflags
active user default audit flags = lo(0x1000,0x1000)
configured user default audit flags = lo(0x1000,0x1000)

…que pour les événements non attribuables.

# auditconfig -getnaflags
active non-attributable audit flags = lo(0x1000,0x1000)
configured non-attributable audit flags = lo(0x1000,0x1000)

Les programmes pouvant faire l’objet d’un enregistrement liés aux connexions des utilisateurs sont consultables via la commande auditrecord(1M).

# auditrecord -c lo

Admin Server Authentication
  program     admin (various)      See SMC, WBEM, or AdminSuite
  event ID    6213                 AUE_admin_authenticate
  class       lo                   (0x0000000000001000)
      header
      subject
      [text]                       error message
      return
[...]

Il est aussi possible de vérifier à partir d’un programme que celui-ci est bien compris dans une classe d’audit. Par exemple pour vérifier si le programme « su » est lié aux connexions des utilisateurs il suffit saisir la commande suivante et de vérifier la classe d’audit.

# auditrecord -p su

su
  program     /usr/bin/su          See su(1M)
  event ID    6229                 AUE_role_logout
  class       lo                   (0x0000000000001000)
      header
      subject
      return
[...]

Les classes d’audit disponibles par défaut sont consultables directement dans le fichier audit_class. Ci-dessous une liste non exhaustif des classes d’audit configurés sur un système Solaris (version 11.3).

0x0000000000000100:nt:network
0x0000000000000200:ip:ipc
0x0000000000001000:lo:login or logout
0x0000000000008000:cy:cryptographic
0x0000000000100000:ps:process start/stop
0x0000000080000000:ex:exec

Par défaut, les journaux d’audit sont des fichiers binaires stockés sur le serveur (3 modes sont disponibles pour stocker ces journaux d’audit : en local, en remote ou via le service syslog). La configuration des ces 3 modes s’effectuent via les 3 plugins suivants.

# auditconfig -getplugin audit_binfile
Plugin: audit_binfile (active)
        Attributes: p_age=0h;p_dir=/var/audit;p_fsize=0;p_minfree=1

# auditconfig -getplugin audit_syslog
Plugin: audit_syslog (inactive)
        Attributes: p_flags=

# auditconfig -getplugin audit_remote
Plugin: audit_remote (inactive)
        Attributes: p_hosts=;p_retries=3;p_timeout=5

L’analyse des journaux d’audit (dans le cas de fichiers binaires) s’effectue via la commande praudit(1M) qu’il est judicieux de coupler avec la commande auditreduce(1M).

Par exemple, les informations concernant l’enregistrement d’une tentative de connexion root (via le programme su) sont les suivantes.

header,69,2,su,,compile,2016-08-29 18:27:57.063 +02:00
subject,bruno,root,root,root,root,2035,548799308,12281 136704 gw.homeunix.org
return,success,0

Les informations enregistrées pour chaque événements d’audit est défini par un ensemble de jetons d’audit. Chaque classe d’audit défini un certain nombre (modifiable) de jetons d’audit. Dans l’exemple ci-dessus, il y a 3 jetons d’audit pour cet enregistrement

• header : marque le début d’un enregistrement d’audit)
• subject : décrit un utilisateur qui exécute ou tente d’effectuer une opération
• return : contient l’état de retour de l’appel système et la valeur de retour du processus

Pour obtenir le descriptif de chaque élément de chaque jeton d’audit, il suffit d’utiliser la commande praudit(1M).

# praudit -x 20160828220542.not_terminated.compile
[...]
<record version="2" event="su" host="compile" iso8601="2016-08-29 18:27:57.063 +02:00">
<subject audit-uid="bruno" uid="root" gid="root" ruid="root" rgid="root" pid="2035" sid="548799308" tid="12281 136704 gw.homeunix.org"/>
<return errval="success" retval="0"/>
</record>
[...]

A travers cet article, j’espère que vous vous êtes familiarisé avec cette fonctionnalité fort intéressante disponible dans Solaris. Dans un prochain article, j’aborderai la configuration de l’audit pour un système hébergeant des Zones non Globales en utilisant des classes d’audit complémentaires.

 

 

• Security
• Solaris