Dans cette procédure, vous devez configurer un système distant, le serveur d'audit à distance (ARS), pour recevoir et stocker des enregistrements d'audit à partir d'un ou de plusieurs systèmes audités. Vous devez ensuite activer le démon d'audit sur le serveur distant.
La configuration se fait en deux temps. Tout d'abord, vous configurez les mécanismes de sécurité sous-jacents pour transporter les données d'audit en toute sécurité, et ce en configurant le KDC. Vous configurez ensuite le service d'audit sur le système d'audit et le serveur ARS. Cette procédure illustre un scénario avec un client audité et un serveur ARS, où ce dernier et le KDC se trouvent sur le même serveur. Des scénarios plus complexes peuvent être configurés de la même manière. Les quatre premières étapes décrivent la configuration du KDC, alors que la dernière étape décrit la configuration du service d'audit.
Avant de commencer
Assurez-vous d'avoir effectué les opérations suivantes. Vous devez prendre le rôle root.
Vous avez pris le rôle root.
Vous avez installé les packages Kerberos, comme décrit à la section Préparation de la diffusion des enregistrements d'audit vers le stockage distant.
Vous travaillez avec un administrateur qui a configuré le système audité, comme décrit à la section Envoi des fichiers d'audit à un référentiel distant.
Vous avez besoin d'un KDC sur un système que le système audité et le serveur ARS peuvent utiliser, d'un hôte principal pour chaque système et d'un principal de service audit. L'exemple ci-dessous illustre une stratégie de configuration de KDC :
arstore # kdcmgr -a audr/admin -r EXAMPLE.COM create master
Cette commande utilise le principal d'administration audr/admin pour créer un KDC maître dans le domaine EXAMPLE.COM, active le KDC maître et démarre le service Kerberos.
Pour plus d'informations, reportez-vous à la page de manuel kdcmgr(1M).
# kdcmgr status KDC Status Information -------------------------------------------- svc:/network/security/krb5kdc:default (Kerberos key distribution center) State: online since Wed Feb 29 01:59:27 2012 See: man -M /usr/share/man -s 1M krb5kdc See: /var/svc/log/network-security-krb5kdc:default.log Impact: None. KDC Master Status Information -------------------------------------------- svc:/network/security/kadmin:default (Kerberos administration daemon) State: online since Wed Feb 29 01:59:28 2012 See: man -M /usr/share/man -s 1M kadmind See: /var/svc/log/network-security-kadmin:default.log Impact: None. Transaction Log Information -------------------------------------------- Kerberos update log (/var/krb5/principal.ulog) Update log dump : Log version # : 1 Log state : Stable Entry block size : 2048 Number of entries : 13 First serial # : 1 Last serial # : 13 First time stamp : Wed Feb 29 01:59:27 2012 Last time stamp : Mon Mar 5 19:29:28 2012 Kerberos Related File Information -------------------------------------------- (Displays any missing files)
Vous pouvez ajouter le principal en tapant la commande kadmin.local sur le système KDC. Vous pouvez également ajouter le principal à distance en tapant la commande kadmin et en fournissant un mot de passe. Dans cet exemple, le système arstore exécute le KDC.
# kadmin -p audr/admin kadmin: addprinc -randkey audit/arstore.example.com@EXAMPLE.COM kadmin: ktadd audit/arstore.example.com@EXAMPLE.COM
Le récepteur et l'expéditeur doivent disposer de clés.
enigma # kclient .. Enter the Kerberos realm: EXAMPLE.COM .. KDC hostname for the above realm: arstore.example.com .. Will this client need service keys ? [y/n]: y
# auditconfig -setremote group create Bank_A
Bank_A est un groupe de connexion. Dans la mesure où l'attribut hosts n'est pas défini, ce groupe accepte toutes les connexions, ce qui signifie qu'il s'agit d'un groupe de caractères génériques. Dans le domaine Kerberos, tous les systèmes audités peuvent atteindre ce serveur ARS à condition que leur plug-in audit_remote soit correctement configuré.
# auditconfig -setremote group Bank_A "hosts=enigma.example.com"
Le groupe de connexion Bank_A accepte désormais uniquement les connexions à partir du système enigma. Une connexion depuis tout autre hôte est refusée.
# auditconfig -setremote group Bank_A "binfile_fsize=4GB" # auditconfig -getremote Audit Remote Server Attributes: listen_address=;login_grace_time=30;max_startups=10;listen_port=0; Connection group: Bank_A (inactive) Attributes: binfile_dir=/var/audit;binfile_fsize=4GB;binfile_minfree=1; hosts=enigma.example.com;
Pour spécifier le serveur ARS, utilisez l'attribut p_hosts.
enigma # auditconfig -setplugin audit_remote \
active p_hosts=arstore.example.com
enigma # auditconfig -getplugin audit_remote
Plugin: audit_remote
Attributes: p_retries=3;p_timeout=5;p_hosts=arstore.example.com;
Le service d'audit lit la modification du plug-in d'audit lors de l'actualisation.
# audit -s
Le KDC gère désormais la connexion entre le système audité enigma et le serveur ARS.
Cet exemple complète l'exemple présenté dans la procédure. L'administrateur sépare les enregistrements d'audit par hôte sur le serveur ARS en créant deux groupes de connexion.
Les fichiers d'audit de audsys1 sont transmis au groupe de connexion Bank_A sur ce serveur ARS.
arstore # auditconfig -setremote group create Bank_A arstore # auditconfig -setremote group active Bank_A "hosts=audsys1" \ "hosts=audsys1;binfile_dir=/var/audit/audsys1;binfile_fsize=4M;"
Les fichiers d'audit de audsys2 sont transmis au groupe de connexion Bank_B.
arstore # auditconfig -setremote group create Bank_B arstore # auditconfig -setremote group active Bank_B \ "hosts=audsys2;binfile_dir=/var/audit/audsys2;binfile_fsize=4M;"
Pour simplifier la maintenance, l'administrateur définit les autres valeurs d'attribut de manière identique.
arstore # auditconfig -getremote Audit Remote Server Attributes: listen_address=;login_grace_time=30;max_startups=10;listen_port=0; Connection group: Bank_A Attributes: binfile_dir=/var/audit/audsys1;binfile_fsize=4M;binfile_minfree=1; hosts=audsys1 Connection group: Bank_B Attributes: binfile_dir=/var/audit/audsys2;binfile_fsize=4M;binfile_minfree=1; hosts=audsys2Exemple 4-10 Placement du serveur ARS sur un système autre que le KDC
Dans cet exemple, l'administrateur place le serveur ARS sur un système autre que le KDC. Tout d'abord, l'administrateur crée et configure le KDC maître.
kserv # kdcmgr -a audr/admin -r EXAMPLE.COM create master
kserv # kadmin.local -p audr/admin
kadmin: addprinc -randkey \
audit/arstore.example.com@EXAMPLE.COM
kadmin: ktadd -t /tmp/krb5.keytab.audit \
audit/arstore.example.com@EXAMPLE.COM
Après avoir transmis le fichier /tmp/krb5.keytab.audit au serveur ARS de manière sécurisée, arstore, l'administrateur déplace le fichier vers l'emplacement approprié.
arstore # chown root:root krb5.keytab.audit arstore # chmod 600 krb5.keytab.audit arstore # mv krb5.keytab.audit /etc/krb5/krb5.keytab
Au lieu de réécrire le fichier, l'administrateur a également la possibilité d'utiliser la commande ktutil sur le serveur ARS pour fusionner le fichier krb5.keytab.audit du KDC avec les clés existantes du fichier /etc/krb5/krb5.keytab de arstore.
Enfin, l'administrateur génère les clés sur le système audité.
enigma # kclient .. Enter the Kerberos realm: EXAMPLE.COM .. KDC hostname for the above realm: kserv.example.com .. Will this client need service keys ? [y/n]: y