Konfigurieren von Prüfdateien (Aufgaben)

Bevor Sie die Prüfung im Netzwerk aktivieren, können Sie die Prüfkonfigurationsdateien an die Prüfungsanforderungen Ihres Standorts anpassen. Außerdem können Sie den Prüfservice erneut starten oder das lokale System erneut booten, um die nach der Aktivierung des Prüfservice geänderten Konfigurationsdateien zu lesen. Es hat sich jedoch bewährt, die Prüfkonfiguration so weit wie möglich anzupassen, bevor der Prüfservice gestartet wird.

Wenn Sie Zonen implementiert haben, können Sie alle Zonen über die globale Zone prüfen. Um die Zonen in der Prüfungsausgabe zu unterscheiden, können Sie die Richtlinienoption zonename festlegen. Wenn Sie stattdessen die nicht globalen Zonen einzeln prüfen möchten, können Sie die Richtlinie perzone in der globalen Zone einstellen und die Prüfkonfigurationsdateien in den nicht globalen Zonen anpassen. Eine Übersicht finden Sie unter Prüfung und Oracle Solaris-Zonen. Informationen zur Planung erhalten Sie unter So planen Sie die Prüfung der Zonen. Informationen zu Verfahren erhalten Sie unter Konfigurieren des Prüfservice in Zonen (Aufgaben).

So ändern Sie die Datei `audit_control`

Die Konfiguration der systemweiten Prüfung erfolgt in der Datei /etc/security/audit_control. In der Datei werden die zu prüfenden Ereignisse, der Zeitpunkt für die Ausgabe von Prüfungswarnungen und der Speicherort der Prüfdateien festgelegt.

Nehmen Sie die Rolle "Primary Administrator" an, oder melden Sie sich als Superuser an.
Die Rolle "Primary Administrator" enthält das gleichnamige Profil. Informationen zum Erstellen von Rollen und Zuweisen von Rollen zu Benutzern finden Sie in Kapitel 2, Working With the Solaris Management Console (Tasks) in System Administration Guide: Basic Administration.

(Optional) Speichern Sie eine Backup-Kopie der Datei audit_control.

# cp /etc/security/audit_control /etc/security/audit_control.orig

Ändern Sie die Datei audit_control an Ihrem Standort.
Die Einträge liegen im folgenden Format vor:
```
keyword:value
```
keyword

Definiert den Zeilentyp. Es gibt folgende Typen: dir, flags, minfree, naflags und plugin. In der Version Solaris 10 sind die Zeilen dir und minfree veraltet und werden nicht mehr verwendet.
Eine Erläuterung der Schlüsselwörter finden Sie in den folgenden Beispielen.

value

Gibt die Daten an, die dem Zeilentyp zugewiesen sind.

Hinweis - Um die Speicherorte der Prüfverzeichnisse anzugeben, verwenden Sie das Attribut p_dir des Plugins audit_binfile.so. Um den mindestens verfügbaren freien Speicherplatz anzugeben, verwenden Sie das Attribut p_minfree.

(Optional) Überprüfen Sie die Syntax der Datei.

# audit -v /etc/security/audit_control
syntax ok

Beispiel 30-1 Vorauswahl der Prüfklassen für alle Benutzer

Die Zeile flags in der Datei audit_control bestimmt, welche Klassen der zuweisbaren Ereignisse für alle Benutzer im System geprüft werden. Die Klassen werden durch Kommata getrennt. Leerstellen sind zulässig. In diesem Beispiel werden die Ereignisse in den Klassen lo und ap für alle Benutzer geprüft.

## audit_control file
flags:lo,ap
naflags:lo
plugin:name=...

Die einer Klasse zugewiesenen Ereignisse können Sie in der Datei audit_event anzeigen. Stattdessen können Sie auch den Befehl bsmrecord verwenden (siehe Beispiel 30-27).

Beispiel 30-2 Vorauswahl der nicht zuweisbaren Ereignisse

In diesem Beispiel werden alle Ereignisse in der Klasse na und alle nicht zuweisbaren login-Ereignisse geprüft.

## audit_control file
flags:lo
naflags:lo,na
plugin:name=...

Beispiel 30-3 Angeben des Speicherorts für binäre Prüfdaten

Durch das Flag p_dir des Plugins audit_binfile.so wird angegeben, welche Prüfdateisysteme für die binären Prüfdaten verwendet werden sollen. In diesem Beispiel werden drei Speicherorte für binäre Prüfdaten definiert. Die Verzeichnisse sind vom primären Verzeichnis bis zum Reserveverzeichnis der Reihe nach aufgeführt. Die Zeile plugin enthält keinen Zeilenumbruch.

## audit_control file
##
flags:lo
naflags:lo,na
plugin:name=audit_binfile.so; p_dir=/var/audit/egret.1/files,
/var/audit/egret.2/files,/var/audit

Weitere Informationen zum Einrichten von Dateisystemen für binäre Prüfdaten finden Sie unter So erstellen Sie Partitionen für Prüfdateien.

Beispiel 30-4 Ändern der unteren Grenzwerte für Warnungen

In diesem Beispiel wird der mindestens verfügbare Speicherplatz für alle Prüfdateisysteme festgelegt, sodass eine Warnung ausgegeben wird, wenn nur 10 Prozent des Dateisystems verfügbar sind.

Die Zeile plugin enthält keinen Zeilenumbruch.

## audit_control file
#
flags:lo
naflags:lo,na
plugin:name=audit_binfile.so; p_dir=/var/audit/examplehost.1/files,
/var/audit/examplehost.2/files,/var/audit/localhost/files; p_minfree=10

Der Alias audit_warn erhält die Warnung. Weitere Informationen zum Einrichten des Alias erhalten Sie unter So konfigurieren Sie den E-Mail-Alias audit_warn.

So konfigurieren Sie `syslog`-Prüfprotokolle

Sie können den Prüfservice so anweisen, dass einige oder alle der erfassten Prüfdatensätze in die Prüfwarteschlange für syslog kopiert werden. Im folgenden Verfahren wird beschrieben, wie Prüfungsdaten im Text- und binären Format gespeichert werden. Die erfassten Prüfungsdaten im Textformat sind ein untergeordneter Satz der binären Daten.

Bevor Sie beginnen

Sie müssen die Prüfklassen im Voraus auswählen. Die im Voraus ausgewählten Prüfklassen werden in der Zeile flags und der Zeile naflags der Datei audit_control angegeben. Außerdem können Sie Klassen für einzelne Benutzer in der Datei audit_user im Voraus auswählen und Prüfklassen mit dem Befehl auditconfig dynamisch hinzufügen.

Nehmen Sie die Rolle "Primary Administrator" an, oder melden Sie sich als Superuser an.
Die Rolle "Primary Administrator" enthält das gleichnamige Profil. Informationen zum Erstellen von Rollen und Zuweisen von Rollen zu Benutzern finden Sie in Kapitel 2, Working With the Solaris Management Console (Tasks) in System Administration Guide: Basic Administration.

(Optional) Speichern Sie eine Backup-Kopie der Datei audit_control.

# cp /etc/security/audit_control /etc/security/audit_control.save

Fügen Sie einen Plugin-Eintrag audit_syslog.so hinzu.
```
## audit_control file
flags:lo,ss
naflags:lo,na
plugin:name=audit_binfile.so;p_dir=/var/audit; p_minfree=20;
plugin:name=audit_syslog.so;p_flags=+lo,-ss
```
Ein Eintrag plugin weist das folgende Format auf:
```
plugin:name=name; qsize=max-queued-records;p_*=value
```
- name=name: Führt den Namen des Plugins auf. Die gültigen Werte sind audit_binfile.so und audit_syslog.so.
- qsize=max-queued-records: Gibt die maximale Anzahl der in die Warteschlange zu stellenden Datensätze für Prüfdaten an, die an das Plugin gesendet werden. Dieses Attribut ist optional.
- p_*= value: Gibt Plugin-spezifische Attribute an. Das Plugin audit_syslog.so akzeptiert p_flags. Das Plugin audit_binfile.so akzeptiert p_dir, p_minfree und p_fsize. Das Attribut p_fsize ist seit der Version Solaris 10 10/08 verfügbar.
Weitere Informationen zu Plugin-spezifischen Attributen finden Sie im Abschnitt OBJECT ATTRIBUTES der Manpages audit_binfile(5) und audit_syslog(5).
Fügen Sie einen Eintrag audit.notice zur Datei syslog.conf hinzu.
Der Eintrag enthält den Speicherort der Protokolldatei.
```
# cat /etc/syslog.conf
…
audit.notice       /var/adm/auditlog
```
Speichern Sie keine Protokolle im Textformat am gleichen Speicherort wie binäre Prüfdateien. Der Befehl auditreduce, durch den binäre Prüfdateien gelesen werden, nimmt an, dass alle Dateien in einer Prüfpartition binäre Prüfdateien sind.
Erstellen Sie die Protokolldatei.
```
# touch /var/adm/auditlog
```
Aktualisieren Sie die Konfigurationsinformationen für den Service syslog.
```
# svcadm refresh system/system-log
```
Archivieren Sie die syslog-Protokolldateien in regelmäßigen Abständen.
Die durch den Prüfservice generierte Ausgabe kann sehr umfangreich sein. Weitere Informationen zum Verwalten der Protokolle finden Sie auf der Manpage logadm(1M).

Beispiel 30-5 Angeben der Prüfklassen für die syslog-Ausgabe

Im folgenden Beispiel wird vom Dienstprogramm syslog ein untergeordneter Satz der im Voraus ausgewählten Prüfklassen erfasst.

## audit_user file
jdoe:pf

## audit_control file
flags:lo,ss
naflags:lo,na
plugin:name=audit_binfile.so; p_dir=/var/audit/host.1/files,
/var/audit/host.2/files,/var/audit/localhost/files; p_minfree=10
plugin:name=audit_syslog.so; p_flags=-lo,-na,-ss,+pf

Durch die Einträge flags und naflags wird das System angewiesen, alle Prüfdatensätze für Anmelden/Abmelden, Nichtzuweisung und Systemstatusänderung im binären Format zu erfassen. Der Plugin-Eintrag audit_syslog.so weist das Dienstprogramm syslog an, nur fehlgeschlagene Anmeldungen, fehlgeschlagene nicht zuweisbare Ereignisse und fehlgeschlagene Systemstatusänderungen zu erfassen. Für den Benutzer jdoe enthält der binäre Prüfdatensatz alle Verwendungen einer die Profile erkennenden Shell. Das Dienstprogramm syslog erfasst die erfolgreichen der Profile erkennenden Befehle. Das Erstellen der Klasse pf wird unter Beispiel 30-10 beschrieben.

Beispiel 30-6 Einfügen der syslog-Prüfdatensätze auf einem Remote-System

Sie können den Eintrag audit.notice in der Datei syslog.conf so ändern, dass er auf ein Remote-System verweist. In diesem Beispiel lautet der Name des lokalen Systems example1. Das Remote-System lautet remote1.

example1 # cat /etc/syslog.conf
…
audit.notice       @remote1

Der Eintrag audit.notice in der Datei syslog.conf auf dem System remote1 verweist auf die Protokolldatei.

remote1 # cat /etc/syslog.conf
…
audit.notice       /var/adm/auditlog

Beispiel 30-7 Verwenden von Plugins in der Datei audit_control

Die bevorzugte Methode zum Angeben von Informationen ohne Flags in der Datei audit_control ist die Verwendung des Eintrags plugin. In diesem Beispiel werden die Prüf-Flags ausgewählt und anschließend die Plugin-Informationen aufgeführt.

## audit_control file
flags:lo,ss
naflags:lo,na
plugin:name=audit_binfile.so;p_minfree=10; p_dir=/var/audit
plugin:name=audit_syslog.so; p_flags=+lo

So ändern Sie die Prüfmerkmale eines Benutzers

Definitionen für die Benutzer werden in der Datenbank audit_user gespeichert. Durch diese Definitionen werden für den jeweiligen Benutzer die im Voraus ausgewählten Klassen in der Datei audit_control geändert. In der Datei nsswitch.conf wird festgelegt, ob eine lokale Datei oder eine Naming Service-Datenbank verwendet wird. Weitere Informationen zur Berechnung der endgültigen Prüfungsvorauswahlmaske eines Benutzers finden Sie unter Verarbeiten der Prüfungsmerkmale.

Nehmen Sie die Rolle "Primary Administrator" an, oder melden Sie sich als Superuser an.
Die Rolle "Primary Administrator" enthält das gleichnamige Profil. Informationen zum Erstellen von Rollen und Zuweisen von Rollen zu Benutzern finden Sie in Kapitel 2, Working With the Solaris Management Console (Tasks) in System Administration Guide: Basic Administration.
(Optional) Speichern Sie eine Backup-Kopie der Datenbank audit_user.
```
# cp /etc/security/audit_user /etc/security/audit_user.orig
```
Fügen Sie neue Einträge zur Datenbank audit_user hinzu.
In der lokalen Datenbank weist jeder Eintrag das folgende Format auf:
```
username:always-audit:never-audit
```
username

Wählt den Namen des zu prüfenden Benutzers

always-audit

Wählt die Liste der Prüfklassen, die immer für den angegebenen Benutzer geprüft werden sollen

never-audit

Wählt die Liste der Prüfklassen, die nie für den angegebenen Benutzer geprüft werden sollen

Sie können mehrere Klassen angeben, indem Sie die Prüfklassen durch Kommata trennen.
Die Einträge audit_user gelten ab der nächsten Anmeldung des Benutzers.

Beispiel 30-8 Ändern der für einen Benutzer geprüften Ereignisse

In diesem Beispiel enthält die Datei audit_control die im Voraus ausgewählten Prüfklassen für das System:

## audit_control file
…
flags:lo,ss
naflags:lo,na

Die Datei audit_user zeigt eine Ausnahme. Wenn der Benutzer jdoe eine Profil-Shell verwendet, wird diese Verwendung geprüft:

## audit_user file
jdoe:pf

Die Prüfungsvorauswahlmaske für jdoe ist eine Kombination aus den Einstellungen audit_user und audit_control. Der Befehl auditconfig -getaudit zeigt die Vorauswahlmaske für jdoe:

# auditconfig -getaudit
audit id = jdoe(1234567)
process preselection mask = ss,pf,lo(0x13000,0x13000)
terminal id (maj,min,host) = 242,511,example1(192.168.160.171)
audit session id = 2138517656

Beispiel 30-9 Nur Prüfung von Benutzern und nicht dem System

In diesem Beispiel werden nur Anmelde- und Rollenaktivitäten von vier Benutzern in diesem System geprüft. Durch die Datei audit_control werden keine Prüfklassen für das System im Voraus ausgewählt.

## audit_control file
…
flags:
naflags:

Durch die Datei audit_user werden zwei Prüfklassen für vier Benutzer wie folgt im Voraus ausgewählt:

## audit_user file
jdoe:lo,pf
kdoe:lo,pf
pdoe:lo,pf
sdoe:lo,pf

In der folgenden Datei audit_control wird ein unbefugtes Eindringen aufgezeichnet. In Kombination mit der Datei audit_user wird durch diese Datei das System besser geschützt als durch die erste Datei audit_control in diesem Beispiel.

## audit_control file
…
flags:
naflags:lo
plugin:name=...

So fügen Sie eine Prüfklasse hinzu

Beim Erstellen einer eigenen Prüfklasse können Sie nur die Prüfereignisse zur Klasse hinzufügen, die Sie an Ihrem Standort prüfen möchten. Wenn Sie die Klasse auf einem System hinzufügen, kopieren Sie die Änderung auf alle zu prüfenden Systeme.

Nehmen Sie die Rolle "Primary Administrator" an, oder melden Sie sich als Superuser an.
Die Rolle "Primary Administrator" enthält das gleichnamige Profil. Informationen zum Erstellen von Rollen und Zuweisen von Rollen zu Benutzern finden Sie in Kapitel 2, Working With the Solaris Management Console (Tasks) in System Administration Guide: Basic Administration.
(Optional) Speichern Sie eine Backup-Kopie der Datei audit_class.
```
# cp /etc/security/audit_class /etc/security/audit_class.orig
```
Fügen Sie neue Einträge zur Datei audit_class hinzu.
Die Einträge liegen im folgenden Format vor:
```
0xnumber:name:description
```
0x

Identifiziert number als hexadezimal

number

Definiert eine eindeutige Prüfungsklassenmaske

name

Definiert den Buchstabennamen der Prüfklasse

description

Definiert den beschreibenden Namen der Prüfklasse

Der Eintrag in der Datei muss eindeutig sein. Verwenden Sie keine vorhandenen Prüfklassenmasken.

Beispiel 30-10 Erstellen einer neuen Prüfklasse

In diesem Beispiel wird eine Klasse für einen kleinen Satz an Prüfereignissen erstellt. Der zur Datei audit_class hinzugefügte Eintrag lautet wie folgt:

0x10000000:pf:profile command

Der Eintrag erstellt eine neue Prüfklasse mit dem Namen pf. In Beispiel 30-11 wird beschrieben, wie Einträge zur neuen Prüfklasse hinzugefügt werden.

Allgemeine Fehler

Vergewissern Sie sich nach dem Anpassen der Datei audit_class, dass die an audit_user durchgeführten Änderungen mit den neuen Prüfklassen übereinstimmen. Es treten Fehler auf, wenn die Prüfklassen in audit_user kein untergeordneter Satz der Datenbank audit_class sind.

So ändern Sie die Klassenmitgliedschaft eines Prüfereignisses

Sie können die Klassenmitgliedschaft eines Prüfereignisses ändern, um die Größe einer vorhandenen Prüfklasse zu verringern oder das Ereignis in eine eigene Klasse hinzuzufügen. Wenn Sie die Zuordnungen zwischen Ereignissen und Klassen in einem System erneut konfigurieren, kopieren Sie die Änderung auf alle zu prüfenden Systeme.

Nehmen Sie die Rolle "Primary Administrator" an, oder melden Sie sich als Superuser an.
Die Rolle "Primary Administrator" enthält das gleichnamige Profil. Informationen zum Erstellen von Rollen und Zuweisen von Rollen zu Benutzern finden Sie in Kapitel 2, Working With the Solaris Management Console (Tasks) in System Administration Guide: Basic Administration.
(Optional) Speichern Sie eine Backup-Kopie der Datei audit_event.
```
# cp /etc/security/audit_event /etc/security/audit_event.orig
```
Ändern Sie die Klasse, zu der bestimmte Ereignisse gehören, indem Sie class-list der Ereignisse ändern.
Die Einträge liegen im folgenden Format vor:
```
number:name:description:class-list
```
number

Entspricht der Prüfereignis-ID

name

Entspricht dem Namen des Prüfereignisses

description

Normalerweise der Systemaufruf oder die ausführbare Datei, durch den/die die Erstellung eines Prüfdatensatzes ausgelöst wird

class-list

Entspricht einer durch Kommata getrennten Liste von Prüfklassen

Beispiel 30-11 Zuordnen vorhandener Prüfereignisse zu einer neuen Klasse

In diesem Beispiel wird ein vorhandenes Prüfereignis der neuen Klasse zugewiesen, deren Erstellung unter Beispiel 30-10 beschrieben ist. In der Datei audit_control werden vom binären Prüfdatensatz erfolgreiche und fehlerhafte Ereignisse in der Klasse pf aufgezeichnet. Das Prüfprotokoll syslog enthält nur fehlerhafte Ereignisse in der Klasse pf.

# grep pf | /etc/security/audit_class
0x10000000:pf:profile command
# vi /etc/security/audit_event
6180:AUE_prof_cmd:profile command:ua,as,pf
# vi audit_control
...
flags:lo,pf
plugin:name=audit_binfile.so; p_dir=/var/audit; p_minfree=10
plugin:name=audit_syslog.so; p_flags=-lo,-pf

Beispiel 30-12 Prüfung der Verwendung von setuid-Programmen

In diesem Beispiel wird eine Klasse erstellt, in der Ereignisse gespeichert werden, die Aufrufe der Programme setuid und setgid überwachen. Im binären Prüfdatensatz werden erfolgreiche und fehlerhafte Ereignisse in den Klassen lo und na und erfolgreiche Ereignisse in der Klasse st erfasst. Das Prüfprotokoll syslog enthält nur erfolgreiche Ereignisse in der Klasse st.

# vi /etc/security/audit_class
0x00000800:st:setuid class
# vi /etc/security/audit_event
26:AUE_SETGROUPS:setgroups(2):st
27:AUE_SETPGRP:setpgrp(2):st
40:AUE_SETREUID:setreuid(2):st
41:AUE_SETREGID:setregid(2):st
214:AUE_SETEGID:setegid(2):st
215:AUE_SETEUID:seteuid(2):st

# vi audit_control
## audit_control file
flags:lo,+st
naflags:lo,na
plugin:name=audit_binfile.so; p_dir=/var/audit; p_minfree=10
plugin:name=audit_syslog.so; p_flags=-lo,+st

Navigationslinks �berspringen
Druckansicht beenden
	Systemverwaltungshandbuch: Sicherheitsservices