Terminologie und Konzepte der Prüfung

Die folgenden Begriffe werden zur Beschreibung des Prüfservice verwendet. Einige Definitionen enthalten Verweise auf weitere ausführlichere Beschreibungen.

Tabelle 28-1 Begriffe der Oracle Solaris-Prüfung

Prüfereignisse

Sicherheitsrelevante Systemaktionen können geprüft werden. Die prüfbaren Aktionen werden als Prüfereignisse bezeichnet. Prüfereignisse werden in der Datei /etc/security/audit_event aufgeführt. Jedes Prüfereignis wird in der Datei durch eine Ereignisnummer, einen symbolischen Namen, eine Kurzbeschreibung und den Satz der Prüfklassen, zu denen das Ereignis gehört, definiert. Weitere Informationen zur Datei audit_event erhalten Sie auf der Manpage audit_event(4).

Durch den folgenden Eintrag wird beispielsweise das Prüfereignis für den Systemaufruf exec() definiert:

7:AUE_EXEC:exec(2):ps,ex

Wenn Sie für die Prüfung entweder die Prüfklasse ps oder ex im Voraus auswählen, werden die exec()-Systemaufrufe im Prüfpfad aufgezeichnet.

Bei der Oracle Solaris-Prüfung werden zuweisbare und nicht zuweisbare Ereignisse verarbeitet. Durch die Prüfrichtlinie werden Ereignisse in synchrone und asynchrone Ereignisse unterteilt. Dies wird im Folgenden beschrieben:

• Zuweisbare Ereignisse: Ereignisse, die einem Benutzer zugewiesen werden können. Da der Systemaufruf exec() einem Benutzer zugewiesen werden kann, wird er als zuweisbares Ereignis bezeichnet. Alle zuweisbaren Ereignisse werden als synchrone Ereignisse bezeichnet.

• Nicht zuweisbare Ereignisse: Ereignisse, die auf der Kernel-Interrupt-Ebene oder vor der Authentifizierung eines Benutzers auftreten. Durch die Prüfklasse na werden nicht zuweisbare Prüfereignisse verarbeitet. Das Booten des Systems ist beispielsweise ein nicht zuweisbares Ereignis. Die meisten nicht zuweisbaren Ereignisse sind asynchrone Ereignisse. Nicht zuweisbare Ereignisse, die über zugewiesene Prozesse verfügen, beispielsweise eine fehlgeschlagene Anmeldung, werden als synchrone Ereignisse bezeichnet.

• Synchrone Ereignisse: Ereignisse, die einem Prozess im System zugewiesen sind. Synchrone Ereignisse sind die Mehrzahl der Systemereignisse.

• Asynchrone Ereignisse: Ereignisse, die keinem Prozess zugewiesen sind. Daher sind keine Prozesse verfügbar, die blockiert oder zu einem späteren Zeitpunkt reaktiviert werden können. Das erstmalige Booten des Systems und Aufrufen bzw. Beenden von PROM sind Beispiele für asynchrone Ereignisse.

Wenn die Klasse, zu der ein Prüfereignis gehört, für die Prüfung im Voraus ausgewählt wird, wird das Ereignis im Prüfpfad aufgezeichnet. Beispiel: Wenn Sie die Prüfklassen ps und na für die Prüfung im Voraus auswählen, werden unter anderem die Ereignisse der exec()-Systemaufrufe und der System-Bootvorgänge im Prüfpfad aufgezeichnet.

Zusätzlich zu den durch den Oracle Solaris-Prüfservice definierten Prüfereignissen können auch Drittanbieteranwendungen Prüfereignisse generieren. Prüfereignisnummern von 32768 bis 65535 sind für Drittanbieteranwendungen verfügbar.

Prüfklassen und Vorauswahl

Jedes Prüfereignis gehört zu mindestens einer Prüfklasse. In Prüfklassen kann eine große Anzahl von Prüfereignissen zusammengefasst werden. Bei der Vorauswahl einer zu prüfenden Klasse geben Sie an, dass alle Ereignisse in dieser Klasse im Prüfpfad aufgezeichnet werden sollen. Die Vorauswahl kann für Ereignisse auf einem System und für die von einem bestimmten Benutzer eingeleiteten Ereignisse getroffen werden. Nachdem die Ausführung des Prüfservices gestartet wurde, können Sie Prüfklassen zu den im Voraus ausgewählten Klassen dynamisch hinzufügen oder von diesen entfernen.

• Systemweite Vorauswahl: Systemweite Standardeinstellungen für die Prüfung können Sie in den Zeilen flags, naflags und plugin der Datei audit_control angeben. Die Datei audit_control wird unter Datei audit_control beschrieben. Weitere Informationen erhalten Sie auf der Manpage audit_control(4).

• Benutzerspezifische Vorauswahl: Ergänzungen zu den systemweiten Standardeinstellungen für Prüfungen können Sie für bestimmte Benutzer in der Datenbank audit_user angeben.

  In der Maske für die Vorauswahl der Prüfung können Sie angeben, welche Klassen von Ereignissen für einen Benutzer geprüft werden. Die Maske für die Vorauswahl der Prüfung ist eine Kombination der systemweiten Standardeinstellungen und den für den Benutzer angegebenen Prüfklassen. Eine ausführliche Beschreibung erhalten Sie unter Verarbeiten der Prüfungsmerkmale.

  Die Datenbank audit_user kann lokal oder durch einen Naming Service verwaltet werden. Die Solaris Management Console bietet eine grafische Benutzeroberfläche für die Verwaltung der Datenbank. Weitere Informationen erhalten Sie auf der Manpage audit_user(4).

• Dynamische Vorauswahl: Geben Sie Prüfklassen als Argumente zum Befehl auditconfig an, um diese Prüfklassen zu einem Prozess oder einer Sitzung hinzuzufügen oder sie von dort zu entfernen. Weitere Informationen erhalten Sie auf der Manpage auditconfig(1M).

Durch einen Befehl für die Nachauswahl wie auditreduce können Sie Datensätze aus den im Voraus ausgewählten Prüfdatensätzen auswählen. Weitere Informationen finden Sie unter Untersuchen des Prüfpfads und auf der Manpage auditreduce(1M).

Prüfklassen werden in der Datei /etc/security/audit_class definiert. Ein Eintrag gibt für die Klasse die Prüfmaske, den Namen und beschreibenden Namen an. Die Klassendefinitionen ps und na werden beispielsweise in der Datei audit_class wie folgt angezeigt:

0x00100000:ps:process start/stop
0x00000400:na:non-attribute

Es gibt 32 mögliche Prüfklassen. Zu den Klassen zählen zwei globale Klassen: all und no. Die Prüfklassen werden auf der Manpage audit_class(4) beschrieben.

Die Zuordnung von Prüfereignissen zu Klassen kann konfiguriert werden. Sie können Ereignisse von einer Klasse entfernen, zu einer Klasse hinzufügen und eine neue Klasse für ausgewählte Ereignisse erstellen. Weitere Informationen zur Vorgehensweise erhalten Sie unter So ändern Sie die Klassenmitgliedschaft eines Prüfereignisses.

Prüfdatensätze und Prüf-Token

In einem Prüfdatensatz wird das Auftreten eines geprüften Ereignisses aufgezeichnet. Der Datensatz enthält Informationen wie die Person der durchgeführten Aktion, die betroffenen Dateien, die versuchte Aktion sowie Ort und Zeitpunkt der aufgetretenen Aktion. Das folgende Beispiel zeigt einen login-Prüfdatensatz:

header,81,2,login - local,,2003-10-13 11:23:31.050 -07:00
subject,root,root,other,root,other,378,378,0 0 example_system
text,successful login
return,success,0

Die Art der für ein Prüfereignis gespeicherten Informationen wird durch einen Satz von Prüf-Token definiert. Wenn ein Prüfdatensatz für ein Ereignis erstellt wird, enthält der Datensatz einige oder alle der für das Ereignis definierten Token. Der Ereignistyp bestimmt, welche Token aufgezeichnet werden. Im folgenden Beispiel beginnt jede Zeile mit dem Namen des Prüf-Tokens. Der Inhalt des Prüf-Tokens wird nach dem Namen angezeigt. Die vier Prüf-Token bilden zusammen den Prüfdatensatz login.

Eine ausführliche Beschreibung der Struktur der einzelnen Prüf-Token sowie ein Beispiel der Ausgabe praudit finden Sie unter Formate der Prüf-Token. Eine Beschreibung des binären Stream von Prüf-Token finden Sie auf der Manpage audit.log(4).

Prüf-Plugin-Module

Sie können Prüf-Plugin-Module für die Verarbeitung der Datensätze angeben, die durch die Vorauswahl in die Prüfwarteschlange gestellt wurden. Die Plugins sind Einträge in der Datei audit_control.

• Plugin audit_binfile.so: Verarbeitet die Bereitstellung der Prüfwarteschlange an die binären Prüfdateien. Wenn in der Datei audit_control kein Plugin und für den Eintrag dir ein Wert angegeben wurde, verwendet der Prüfdämon dieses Plugin.

• Plugin audit_syslog.so: Verarbeitet die Bereitstellung der ausgewählten Datensätze von der Prüfwarteschlange an die Protokolle syslog

Weitere Informationen zur Syntax der Datei audit_control finden Sie auf der Manpage audit_control(4). Beispiele erhalten Sie in den Aufgaben unter Konfigurieren der Prüfdateien (Übersicht der Schritte).

Weitere Informationen zu den Plugins erhalten Sie auf den Manpages audit_binfile(5), audit_syslog(5) und audit_control(4).

Prüfprotokolle

Die Prüfdatensätze werden in Prüfprotokollen erfasst. Die Oracle Solaris-Prüfung bietet zwei Ausgabemethoden für Prüfprotokolle. Protokolle, die als Prüfdateien bezeichnet werden, speichern Prüfdatensätze im binären Format. Der Satz an Prüfdateien von einem System oder Standort enthält einen vollständigen Prüfdatensatz. Der vollständige Prüfdatensatz wird als Prüfpfad bezeichnet.

Durch das Dienstprogramm syslog werden Zusammenfassungen in Textversion des Prüfdatensatzes erfasst und gespeichert. Ein syslog-Datensatz ist nicht vollständig. Das folgende Beispiel zeigt einen syslog-Eintrag für einen login-Prüfdatensatz:

Oct 13  11:24:11 example_system auditd: [ID 6472 audit.notice] \
        login - login ok session 378 by root as root:other

Die Prüfdatensätze können in beiden Formaten an einem Standort gespeichert werden. Sie können die Systeme an Ihrem Standort so konfigurieren, dass der binäre Modus, der syslog-Modus oder beide Modi verwendet werden. In der folgenden Tabelle werden die binären Prüfdatensätze mit den syslog-Prüfdatensätzen verglichen.

Tabelle 28-2 Vergleich zwischen binären Prüfdatensätzen und syslog-Prüfdatensätzen

Die binären Datensätze gewährleisten die höchstmögliche Sicherheit. Die binäre Ausgabe erfüllt die Anforderungen der Sicherheitszertifikate wie CAPP (Common Criteria Controlled Access Protection Profile). Die Datensätze werden in ein Dateisystem geschrieben, das Sie vor Lesezugriff von anderen Personen schützen. Auf einem einzelnen System werden alle binären Datensätze erfasst und in der entsprechenden Reihenfolge angezeigt. Der GMT-Zeitstempel in binären Protokollen ermöglicht einen präzisen Vergleich, wenn Systeme in einem Prüfpfad über verschiedene Zeitzonen verteilt sind. Durch den Befehl praudit -x können Sie die Datensätze in einem Browser im XML-Format anzeigen. Außerdem können Sie mithilfe von Skripten die XML-Ausgabe analysieren.

Die syslog-Datensätze bieten stattdessen eine höhere Benutzerfreundlichkeit und Flexibilität. Beispielsweise können Sie die syslog-Daten aus verschiedenen Quellen erfassen. Wenn Sie die Ereignisse audit.notice in der Datei syslog.conf überwachen, wird durch das Dienstprogramm syslog eine Prüfdatensatz-Zusammenfassung mit dem aktuellen Zeitstempel gespeichert. Sie können die gleichen Tools für die Verwaltung und Analyse verwenden, die Sie für syslog-Meldungen aus verschiedenen Quellen entwickelt haben, beispielsweise Workstations, Server, Firewalls und Router. Die Datensätze können in Echtzeit angezeigt und auf einem Remote-System gespeichert werden.

Indem Sie Prüfdatensätze mithilfe von syslog.conf an entfernten Speicherorten speichern, können Sie verhindern, dass die Protokolldaten von Angreifern geändert oder gelöscht werden. Andererseits sind die an einem entfernten Standort gespeicherten Prüfdatensätze anfällig für Netzwerkangriffe wie Denial-of-Service-Angriffe und gefälschte Quelladressen. Außerdem kann UDP Pakete ablegen oder Pakete in einer anderen Reihenfolge übermitteln. Die syslog-Einträge sind auf 1024 Zeichen beschränkt, daher können einige Prüfdatensätze im Protokoll abgeschnitten werden. Bei einem einzelnen System werden nicht alle Prüfdatensätze erfasst. Die Datensätze werden möglicherweise nicht in der richtigen Reihenfolge angezeigt. Da jeder Prüfdatensatz mit einem Zeitstempel aus Datum und Uhrzeit des lokalen Systems versehen ist, können Sie durch den Zeitstempel keinen Prüfpfad für mehrere Systeme erstellen.

Weitere Informationen zu Prüfprotokollen erhalten Sie in der folgenden Dokumentation:

• Manpage audit_syslog(5)

• Manpage audit.log(4)

• So konfigurieren Sie syslog-Prüfprotokolle

Speichern des Prüfpfads

In einem Prüfverzeichnis sind die Prüfdateien im binären Format gespeichert. Normalerweise werden bei einer Installation mehrere Prüfverzeichnisse verwendet. Der Inhalt aller Prüfverzeichnisse bildet den Prüfpfad. Prüfdatensätze werden in Prüfverzeichnissen in der folgenden Reihenfolge gespeichert:

• Primäres Prüfverzeichnis: Ein Verzeichnis, in dem Prüfdateien für ein System normalerweise gespeichert werden

• Sekundäres Prüfverzeichnis: Ein Verzeichnis, in dem Prüfdateien für ein System gespeichert werden, wenn das primäre Prüfverzeichnis voll oder nicht verfügbar ist

• Reserveverzeichnis: Ein lokales Prüfverzeichnis, das verwendet wird, wenn das primäre Prüfverzeichnis und alle sekundären Prüfverzeichnisse nicht verfügbar sind

Die Verzeichnisse werden in der Datei audit_control angegeben. Nur wenn ein in der Liste zuerst genanntes Verzeichnis voll ist, wird das nächste Verzeichnis verwendet. Eine mit Anmerkungen versehene audit_control-Datei, die eine Liste der Verzeichniseinträge enthält, finden Sie unter Beispiel 30-3.

Indem Sie die Prüfdateien im standardmäßigen Stammverzeichnis für die Prüfung ablegen, erleichtern Sie die Aufgaben des Prüfers ("Audit Review") beim Prüfen des Prüfpfads. Der Befehl auditreduce verwendet das Stammverzeichnis für die Prüfung, um nach allen Dateien im Prüfpfad zu suchen. Das standardmäßige Stammverzeichnis für die Prüfung lautet /etc/security/audit. Dieses Verzeichnis ist symbolisch verknüpft mit /var/audit. Prüfdateien in Verzeichnissen mit dem Namen /var/audit/ hostname/files können über den Befehl auditreduce einfach gefunden werden. Weitere Informationen erhalten Sie unter Befehl auditreduce.

Untersuchen des Prüfpfads

Der Prüfservice bietet Befehle, mit denen Sie die Dateien im Prüfpfad kombinieren und entfernen können. Mit dem Befehl auditreduce können Sie Prüfdateien im Prüfpfad kombinieren. Außerdem können Sie mit dem Befehl Dateien filtern, um nach bestimmten Ereignissen zu suchen. Durch den Befehl praudit werden die binären Dateien gelesen. Mit den Optionen für den Befehl praudit erhalten Sie eine Ausgabe, die sich für Skripten und Browseranzeige eignet.