Comme évoqué lors de mon précédent article, je vais détailler un cas pratique de configuration de l’audit. Le contexte technique est le suivant : enregistrer l’ensemble des exécutions provenant des utilisateurs. Le système Solaris (11.3) héberge des Zones non  Globales.

La configuration de l’audit dans les Zones non Globales s’effectue de deux manières. Soit la stratégie est opérée par la Zone Globale : la configuration est alors identique à chaque Zone non Globale, les enregistrements d’audit sont disponibles sur la Zone non Globale. Soit la stratégie est opérée pour chaque Zone non Globale : la configuration peut être adaptée à chaque environnement, les enregistrements d’audit sont disponibles sur chacun des environnements.

Un point important à spécifier, si vous exécutez des BrandZ (Solaris 10) sur la Zone Globale, la stratégie opérée par la Zone Globale ne fonctionnera pas pour les BrandZ. Seule la configuration par Zone non Globale fonctionnera dans ce contexte.

Dans ce cas pratique, j’applique la stratégie pour chaque Zone non Globale. Il faut donc ajouter la stratégie suivante sur la Zone Globale du système.

# auditconfig -setpolicy +perzone

Sur chaque Zone non Globale de ce système, le service d’audit doit être activé.

# audit -s
# auditconfig -getcond
audit condition = auditing

Le but est d’enregistrer l’ensemble des exécutions des utilisateurs. Pour obtenir des enregistrements pertinents, il est intéressant d’ajouter la stratégie argv (cela permet d’associer les arguments d’une commande). L’ajout de cette stratégie est à positionner dans chaque Zone non Globale. Sa mise en place dans la Zone Globale peut avoir sont intérêt notamment si certaines commandes (ou connexion) s’exécutent depuis celle-ci via zlogin(1M).

# auditconfig -setpolicy +argv

La stratégie d’audit sur la Zone Globale doit être la suivante.

# auditconfig -getpolicy
configured audit policies = argv,cnt,perzone
active audit policies = argv,cnt,perzone

La stratégie d’audit par Zone non Globale doit être la suivante.

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

La classe d’audit gérant les exécutions se nomme ex. Elle prend en compte tous les événements execve(2M) (incluant pfexec(1M) si celui est actif sur votre système).

0x0000000080000000:ex:exec

# auditrecord -c ex

execve
  system call execve               See execve(2)
  event ID    23                   AUE_EXECVE
  class       ps,ex                (0x0000000080100000)
      header
      path
      [attribute]                  omitted on error
      [exec_arguments]             output if argv policy is set
      [exec_environment]           output if arge policy is set
      subject
      [use_of_privilege]
      return

pfexec
  system call pfexec               See execve(2) with pfexec enabled
  event ID    116                  AUE_PFEXEC
  class       ps,ex,ua,as          (0x0000000080160000)
      header
      path                         pathname of the executable
      path                         pathname of working directory
      [privilege]                  privileges if the limit or inheritable                                     set are changed
      [privilege]                  privileges if the limit or inheritable
                                   set are changed
      [process]                    process if ruid, euid, rgid or egid is
                                   changed
      exec_arguments
      [exec_environment]           output if arge policy is set
      subject
      [use_of_privilege]
      return

On associe la classe d’audit « ex » à la classe d’audit « lo » (gestion des connexions utilisateurs) aussi bien pour les événements provenants d’utilisateurs que des événements provenant du système (événements attribuables et non-attribuables).

# auditconfig -setflags lo,ex
user default audit flags = ex,lo(0x80001000,0x80001000)

# auditconfig -setnaflags lo,ex
non-attributable audit flags = ex,lo(0x80001000,0x80001000)

Les classes d’audit activées sur la Zone Globale sont les suivantes.

# auditconfig -getnaflags -getflags
active non-attributable audit flags = ex,lo(0x80001000,0x80001000)
configured non-attributable audit flags = ex,lo(0x80001000,0x80001000)
active user default audit flags = ex,lo(0x80001000,0x80001000)
configured user default audit flags = ex,lo(0x80001000,0x80001000)

Les classes d’audit activées sur chaque Zone non Globale sont les suivantes.

# auditconfig -getnaflags -getflags
active non-attributable audit flags = ex,lo(0x80001000,0x80001000)
configured non-attributable audit flags = ex,lo(0x80001000,0x80001000)
active user default audit flags = ex,lo(0x80001000,0x80001000)
configured user default audit flags = ex,lo(0x80001000,0x80001000)

Pour appliquer les modifications des classes d’audit, il est nécessaire de l’indiquer au système et d’exécuter les commandes suivantes sur chaque environnement (sur la Zone Globale et sur toutes les Zones non Globales).

# auditconfig -conf
Configured 283 kernel events.

# auditconfig -aconf
Configured non-attributable event mask.

Par défaut, l’ensemble des enregistrements sont écrits via le plugin audit_binfile(5M). Un seul fichier est généré pour l’ensemble des enregistrements. A vous de voir selon votre activité, si vous devez limiter ce fichier selon sa taille ou la périodicité. J’opte souvent pour les deux.

# auditconfig -setplugin audit_binfile p_age=1d

# auditconfig -setplugin audit_binfile p_fsize=512M

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

Cette modification est à faire sur chaque environnement (sur Zone Globale et sur toutes les Zones non Globales). Pensez tout de même à mettre en place une suppression de ces fichiers (une fois qu’ils sont sauvegardés) sinon vous risquez de saturer votre pool ZFS.

# crontab –l root | grep audit
0 5 * * * find /var/share/audit -type f -mtime +4 -exec /usr/bin/rm {} \;

Il vous est maintenant possible de suivre l’activité des utilisateurs sur le(s) système(s). Par exemple, vous pouvez diagnostiquer facilement ce genre d’événement dans votre journal d’audit.

<record version="2" event="execve(2)" host="compile" iso8601="2016-09-04 16:31:31.235 +02:00">
<path>/usr/bin/rm</path>
<attribute mode="100555" uid="root" gid="bin" fsid="65538" nodeid="49437" device="18446744073709551615"/>
<exec_args><arg>rm</arg><arg>/etc/hosts
</arg></exec_args>
<subject audit-uid="bruno" uid="bruno" gid="grpadm" ruid="bruno" rgid="grpadm" pid="1062" sid="3492816039" tid="11705 136704 gw.homeunix.org"/>
<return errval="success" retval="0"/>
</record>

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.