Teil I Übersicht über die Sicherheit
1. Sicherheitsservices (Überblick)
Teil II System-, Datei- und Gerätesicherheit
2. Verwalten von Rechnersicherheit (Übersicht)
3. Steuern des Zugriffs auf Systeme (Aufgaben)
4. Steuern des Zugriffs auf Geräte (Aufgaben)
5. Verwenden von Basic Audit Reporting Tool (Aufgaben)
6. Steuern des Zugriffs auf Dateien (Aufgaben)
7. Verwenden von Automated Security Enhancement Tool (Aufgaben)
Teil III Rollen, Berechtigungsprofile und Berechtigungen
8. Verwenden von Rollen und Berechtigungen (Übersicht)
9. Rollenbasierte Zugriffssteuerung (Aufgaben)
10. Rollenbasierte Zugriffssteuerung (Übersicht)
Teil IV Kryptografische Services
13. Oracle Solaris Cryptographic Framework (Übersicht)
14. Oracle Solaris Cryptographic Framework (Aufgaben)
15. Oracle Solaris Key Management Framework
Teil V Authentifizierungsservices und sichere Kommunikation
16. Verwenden von Authentifizierungsservices (Aufgaben)
19. Verwenden von Oracle Solaris Secure Shell (Aufgaben)
20. Oracle Solaris Secure Shell (Referenz)
21. Einführung zum Kerberos-Service
22. Planen des Kerberos-Service
23. Konfigurieren des Kerberos-Service (Aufgaben)
24. Kerberos-Fehlermeldungen und -Fehlerbehebung
25. Verwalten von Kerberos-Hauptelementen und Richtlinien (Aufgaben)
26. Verwenden von Kerberos-Anwendungen (Aufgaben)
27. Der Kerberos-Service (Referenz)
Teil VII Prüfung bei Oracle Solaris
28. Prüfung bei Oracle Solaris (Übersicht)
29. Planen der Oracle Solaris-Prüfung
30. Verwalten der Oracle Solaris-Prüfung (Aufgaben)
Prüfung bei Oracle Solaris (Übersicht der Schritte)
Konfigurieren der Prüfdateien (Übersicht der Schritte)
Konfigurieren von Prüfdateien (Aufgaben)
So ändern Sie die Datei audit_control
So konfigurieren Sie syslog-Prüfprotokolle
So ändern Sie die Prüfmerkmale eines Benutzers
So fügen Sie eine Prüfklasse hinzu
So ändern Sie die Klassenmitgliedschaft eines Prüfereignisses
Konfigurieren und Aktivieren des Prüfservice (Übersicht der Schritte)
Konfigurieren und Aktivieren des Prüfservice (Aufgaben)
So erstellen Sie Partitionen für Prüfdateien
So konfigurieren Sie den E-Mail-Alias audit_warn
So konfigurieren Sie die Prüfrichtlinie
So aktivieren Sie den Prüfservice
So deaktivieren Sie den Prüfservice
So aktualisieren Sie den Prüfservice
Konfigurieren des Prüfservice in Zonen (Aufgaben)
So können Sie alle Zonen für die Prüfung identisch konfigurieren
So konfigurieren Sie eine zonenweise Prüfung
Verwalten der Prüfdatensätze (Übersicht der Schritte)
So zeigen Sie Prüfdatensatzformate an
So führen Sie Prüfdateien aus dem Prüfpfad zusammen
So wählen Sie Prüfereignisse aus dem Prüfpfad aus
So zeigen Sie den Inhalt der binären Prüfdateien an
So bereinigen Sie eine Prüfdatei des Typs not_terminated
So verhindern Sie eine Prüfpfadüberlauf
Fehlerbehebung bei der Oracle Solaris-Prüfung (Aufgaben)
Fehlerbehebung bei der Oracle Solaris-Prüfung (Übersicht der Schritte)
So können Sie die Ausführung der Oracle Solaris-Prüfung feststellen
So verringern Sie den Umfang der erstellten Prüfdatensätze
So prüfen Sie alle Befehle der Benutzer
So suchen Sie nach Prüfdatensätzen der Änderungen an bestimmten Dateien
So ändern Sie die Vorauswahlmaske eines Benutzers
So verhindern Sie die Prüfung bestimmter Ereignisse
So beschränken Sie die Größe binärer Prüfdateien
So prüfen Sie Anmeldungen von anderen Betriebssystemen
So prüfen Sie FTP- und SFTP-Dateiübertragungen
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).
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.
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.
# cp /etc/security/audit_control /etc/security/audit_control.orig
Die Einträge liegen im folgenden Format vor:
keyword:value
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.
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.
# 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.
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.
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.
# cp /etc/security/audit_control /etc/security/audit_control.save
## 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).
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.
# touch /var/adm/auditlog
# svcadm refresh system/system-log
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
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.
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.
# cp /etc/security/audit_user /etc/security/audit_user.orig
In der lokalen Datenbank weist jeder Eintrag das folgende Format auf:
username:always-audit:never-audit
Wählt den Namen des zu prüfenden Benutzers
Wählt die Liste der Prüfklassen, die immer für den angegebenen Benutzer geprüft werden sollen
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=...
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.
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.
# cp /etc/security/audit_class /etc/security/audit_class.orig
Die Einträge liegen im folgenden Format vor:
0xnumber:name:description
Identifiziert number als hexadezimal
Definiert eine eindeutige Prüfungsklassenmaske
Definiert den Buchstabennamen der Prüfklasse
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.
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.
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.
# cp /etc/security/audit_event /etc/security/audit_event.orig
Die Einträge liegen im folgenden Format vor:
number:name:description:class-list
Entspricht der Prüfereignis-ID
Entspricht dem Namen des Prüfereignisses
Normalerweise der Systemaufruf oder die ausführbare Datei, durch den/die die Erstellung eines Prüfdatensatzes ausgelöst wird
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