Index: head/de_DE.ISO8859-1/books/handbook/audit/chapter.xml =================================================================== --- head/de_DE.ISO8859-1/books/handbook/audit/chapter.xml (revision 46765) +++ head/de_DE.ISO8859-1/books/handbook/audit/chapter.xml (revision 46766) @@ -1,826 +1,828 @@ Security Event Auditing TomRhodesGeschrieben von RobertWatson DanielSeuffertÜbersetzt von Einleitung AUDIT Security Event Auditing MAC Das &os;-Betriebssystem unterstützt ein feingranuliertes Sicherheits-Auditing. Ereignis-Auditing erlaubt die zuverlässige, feingranulierte und konfigurierbare Aufzeichnung einer Vielzahl von sicherheitsrelevanten Systemereignissen einschliesslich Benutzereingaben, Konfigurationsänderungen sowie Datei- und Netzwerkzugriffen. Diese Log-Datensätze können unschätzbar wertvoll sein für direkte Systemüberwachung, Einbruchserkennung und Post-Mortem-Analyse. &os; implementiert &sun;s öffentlich zugängliche BSM API und Dateiformat. Die &os;-Implementierung kann mit den Audit-Implementierungen von &sun; &solaris; und &apple; &macos; X zusammenarbeiten. Dieses Kapitel konzentriert sich auf die Installation und Konfiguration des Ereignis-Auditings. Es erklärt Audit-Richtlinien und stellt ein Beispiel einer Audit-Konfiguration vor. Nach dem Lesen dieses Kapitels werden Sie Folgendes wissen: Was Ereignis-Auditing ist und wie es arbeitet. Wie man Ereignis-Auditing in &os; für Benutzer und Prozesse konfiguriert. Wie man den Audit-Pfad mittels Audit-Reduktion und Revisionswerkzeugen überprüft. Vor dem Lesen dieses Kapitels sollten Sie: Sowohl &unix; als auch &os;-Basismechanismen beherrschen (). Mit den grundlegenden Mechanismen der Kernel-Konfiguration und -Kompilierung vertraut sein (). Mit den Maßnahmen zur Sicherung von &os; vertraut sein (). Die Audit-Funktionalität in &os; besitzt die Einschränkungen, dass zur Zeit nicht alle sicherheitsrelevanten System-Ereignisse auditierbar sind und dass einige Anmelde-Mechanismen, wie z.B. X11-basierte Bildschirm-Manager und Daemonen von Drittanbietern, das Auditing für Benutzeranmeldungen nicht korrekt konfigurieren. Das Sicherheits-Auditing ist in der Lage, sehr - detaillierte Log-Dateien von Systemaktivitäten zu - erzeugen. Auf einem ausgelasteten System kann die Pfad-Datei - sehr groß werden, wenn sie für hohe Auflösung - konfiguriert ist, und im Extremfall pro Woche um mehrere - Gigabyte anwachsen. Administratoren sollten daher den - benötigten Plattenplatz in Verbindung mit umfangreichen - Audit-Konfigurationen berücksichtigen. So kann es - wünschenswert sein, ein eigenes - Dateisystem für /var/audit - einzusetzen, damit andere Dateisysteme nicht betoffen sind, - wenn das Dateisystem des Audit voll läuft. + detaillierte Log-Dateien von Systemaktivitäten zu erzeugen. + Auf einem ausgelasteten System kann die Pfad-Datei sehr groß + werden, wenn sie für hohe Auflösung konfiguriert ist, und im + Extremfall pro Woche um mehrere Gigabyte anwachsen. + Administratoren sollten daher den benötigten Plattenplatz in + Verbindung mit umfangreichen Audit-Konfigurationen + berücksichtigen. So kann es wünschenswert sein, ein eigenes + Dateisystem für /var/audit einzusetzen, damit + andere Dateisysteme nicht betoffen sind, wenn das Dateisystem + des Audit voll läuft. Schlüsselbegriffe Vor dem Lesen dieses Kapitels müssen einige Audit-bezogene Schlüsselbegriffe erläutert werden: event: Ein auditierbares Ereignis ist ein Ereignis, das mit dem Audit-Subsystem aufgezeichnet werden kann. Beispiele für sicherheitsrelevante Systemereignisse sind etwa das Anlegen von Dateien, das Erstellen einer Netzwerkverbindung oder eine Benutzeranmeldung. Ereignisse sind entweder attributierbar, können also zu einen authentifizierten Benutzer zurückverfolgt werden, oder sind nicht-attributierbar, falls dies nicht möglich ist. Nicht-attributierbare Ereignisse erfolgen daher vor der Authentifizierung im Anmeldeprozess (beispielsweise die Eingabe eines falschen Passworts). class: Ereignisklassen sind benannte Zusammenstellungen von zusammengehörenden Ereignissen und werden in Auswahl-Ausdrücken benutzt. Häufig genutzte Klassen von Ereignissen schließen file creation (fc, Anlegen von Dateien), exec (ex, Ausführung) und login_logout (lo, Anmeldung-Abmeldung) ein. record: Ein Datensatz ist ein Audit-Logeintrag, welcher ein Sicherheitsereignis enthält. Jeder Datensatz enthält einen Ereignistyp, Informationen über den Gegenstand (Benutzer), welcher die Aktion durchführt, Datums- und Zeitinformationen, Informationen über jedes Objekt oder Argument sowie den Zustand hinsichtlich Erfolg oder Scheitern der Operation. trail: Ein Audit-Pfad (audit trail) oder eine Log-Datei besteht aus einer Reihe von Audit-Datensätzen, die Sicherheitsereignisse beschreiben. Normalerweise sind die Pfade in grober zeitlicher Reihenfolge bezüglich des Zeitpunktes, an welchem ein Ereignis beendet wurde. Nur authorisierte Prozesse dürfen Datensätze zum Audit-Pfad hinzufügen. selection expression: Ein Auswahlausdruck ist eine Zeichenkette, welche eine Liste von Präfixen und Audit-Ereignisklassennamen enthält, um Ereignisse abzugleichen. preselection: Die Vorauswahl ist der Prozess, durch den das System erkennt, welche Ereignisse von Interesse für den Administrator sind, um die Erzeugung von Datensätze zu verhindern, welche nicht von Belang sind. Die Konfiguration der Vorauswahl benutzt eine Reihe von Auswahl-Ausdrücken, um zu erkennen, welche Klassen von Ereignissen für welche Benutzer aufgezeichnet werden sollen sowie globale Einstellungen, welche sowohl auf authorisierte als auch unauthorisierte Prozesse angewendet werden. reduction: Die Reduzierung ist der Prozess, durch den Datensätze von bestehenden Audit-Pfaden ausgewählt werden für Speicherung, Ausdruck oder Analyse. Ebenso der Prozess, durch den unerwünschte Datensätze aus dem Audit-Pfad entfernt werden. Mittels Reduzierung können Administratoren Richtlinien für die Speicherung von Audit-Daten vorgeben. Zum Beispiel können ausführliche Audit-Pfade für einen Monat gespeichert werden, um danach den Pfad für archivarische Zwecke auf die Anmeldeinformationen zu reduzieren. Installation der Audit-Unterstützung Die Unterstützung des Ereignis-Auditings für den Benutzerbereich wird bereits als Teil des Basissystems installiert. Die Audit-Unterstützung ist bereits im &os;-Standardkernel enthalten, jedoch müssen Sie die folgende Zeile explizit in Ihre Kernelkonfigurationsdatei aufnehmen und den Kernel neu bauen: options AUDIT Bauen und installieren Sie den Kernel wie in beschrieben ist. Nachdem der Kernel mit Audit-Unterstützung gebaut und installiert ist und das System neu gestartet wurde, aktivieren Sie den Audit-Daemon durch das Einfügen der folgenden Zeile in die Datei &man.rc.conf.5;: auditd_enable="YES" Die Audit-Unterstützung kann nun durch einen Neustart des Systems oder durch das manuelle Starten des Audit-Daemon aktiviert werden: service auditd start Die Konfiguration des Audit Alle Konfigurationsdateien für das Sicherheits-Audit finden sich unter /etc/security. Die folgenden Dateien müssen vorhanden sein, bevor der Audit-Daemon gestartet wird: audit_class – Enthält die Definitionen der Audit-Klassen. audit_control – Steuert Teile des Audit-Subsystems wie Audit-Klassen, minimaler Plattenplatz auf dem Audit-Log-Datenträger, maximale Größe des Audit-Pfades usw. audit_event – Wörtliche Namen und Beschreibungen von System-Audit-Ereignissen sowie eine Liste, welche Klassen welches Ereignis aufzeichnen. audit_user – Benutzerspezifische Audit-Erfordernisse, welche mit den globalen Vorgaben bei der Anmeldung kombiniert werden. audit_warn – Ein anpassbares Shell-Skript, welches von auditd benutzt wird, um Warnhinweise in aussergewöhnlichen Situationen zu erzeugen, z.B. wenn der Platz für die Audit-Datensätze knapp wird oder wenn die Datei des Audit-Pfades rotiert wurde. Audit-Konfigurationsdateien sollten vorsichtig gewartet und bearbeitet werden, da Fehler in der Konfiguration zu falscher Aufzeichnung von Ereignissen führen könnten. Ereignis-Auswahlausdrücke Auswahlausdrücke werden an einigen Stellen der Audit-Konfiguration benützt, um zu bestimmen, welche Ereignisse auditiert werden sollen. Die Ausdrücke enthalten eine Liste der Ereignisklassen, welche verglichen werden sollen, jede mit einem Präfix, welches anzeigt, ob verglichene Datensätze akzeptiert oder ignoriert werden sollen und optional, um anzuzeigen, ob der Eintrag beabsichtigt, erfolgreiche oder fehlgeschlagene Operationen zu vergleichen. Auswahlausdrücke werden von links nach rechts ausgewertet und zwei Ausdrücke werden durch Aneinanderhängen miteinander kombiniert. Die folgende Liste enthält die Standard-Ereignisklassen für das Audit und ist in audit_class festgehalten: all – all – Vergleiche alle Ereignisklassen. ad – administrative – Administrative Aktionen ausgeführt auf dem System als Ganzes. ap – application – Aktionen definiert für Applikationen. cl – file close – Audit-Aufrufe für den Systemaufruf close. ex – exec – Ausführung des Audit-Programms. Auditierung von Befehlszeilen-Argumenten und Umgebungsvariablen wird gesteuert durch &man.audit.control.5; mittels der argv und envv-Parametergemäss der Richtlinien-Einstellungen. fa – file attribute access – Auditierung des Zugriffs auf Objektattribute wie &man.stat.1;, &man.pathconf.2; und ähnlichen Ereignissen. fc – file create – Audit-Ereignisse, bei denen eine Datei als Ergebnis angelegt wird. fd – file delete – Audit-Ereignisse, bei denen Dateilöschungen vorkommen. fm – file attribute modify – Audit-Ereignisse, bei welchen Dateiattribute geändert werden, wie &man.chown.8;, &man.chflags.1;, &man.flock.2; etc. fr – file read – Audit-Ereignisse, bei denen Daten gelesen oder Dateien zum lesen geöffnet werden usw. fw – file write – Audit-Ereignisse, bei welchen Daten geschrieben oder Dateien geschrieben oder verändert werden usw. io – ioctl – Nutzung des Systemaufrufes &man.ioctl.2; durch Audit. ip – ipc – Auditierung verschiedener Formen von Inter-Prozess-Kommunikation einschliesslich POSIX-Pipes und System V IPC-Operationen. lo – login_logout – Audit-Ereignisse betreffend &man.login.1; und &man.logout.1;, welche auf dem System auftreten. na – non attributable – Auditierung nicht-attributierbarer Ereignisse (Ereignisse, die nicht auf einen bestimmten Benutzer zurückgeführt werden können). no – invalid class – Kein Abgleich von Audit-Ereignissen. nt – network – Audit-Ereignisse in Zusammenhang mit Netzwerkaktivitäten wie z.B. &man.connect.2; und &man.accept.2;. ot – other – Auditierung verschiedener Ereignisse. pc – process – Auditierung von Prozess-Operationen wie &man.exec.3; und &man.exit.3;. Diese Ereignisklassen können angepasst werden durch Modifizierung der Konfigurationsdateien audit_class und audit_event. Jede Audit-Klasse in dieser Liste ist kombiniert mit einem Präfix, welches anzeigt, ob erfolgreiche/gescheiterte Operationen abgebildet werden, und ob der Eintrag den Abgleich hinzufügt oder entfernt für die Klasse und den Typ. (none) Kein Präfix, sowohl erfolgreiche als auch gescheiterte Vorkommen eines Ereignisses werden auditiert. + Auditiere nur erfolgreiche Ereignisse in dieser Klasse. - Auditiere nur gescheiterte Operationen in dieser Klasse. ^ Auditiere weder erfolgreiche noch gescheiterte Ereignisse in dieser Klasse. ^+ Auditiere keine erfolgreichen Ereignisse in dieser Klasse. ^- Auditiere keine gescheiterten Ereignisse in dieser Klasse. Das folgende Beispiel einer Auswahl-Zeichenkette wählt erfolgreiche und gescheiterte Anmelde/Abmelde-Ereignisse aus, aber nur erfolgreich beendete Ausführungs-Ereignisse: lo,+ex Konfigurationsdateien In den meisten Fällen müssen Administratoren nur zwei Dateien ändern, wenn sie das Audit-System konfigurieren: audit_control und audit_user. Die erste Datei steuert systemweite Audit-Eigenschaften und -Richtlinien; die zweite Datei kann für die Feinanpassung der Auditierung von Benutzern verwendet werden. Die <filename>audit_control</filename>-Datei Die audit_control-Datei legt eine Anzahl Vorgabewerte fest. Beim Betrachten des Inhaltes der Datei sehen wir Folgendes: dir:/var/audit flags:lo minfree:20 naflags:lo policy:cnt filesz:0 Die Option wird genutzt, um eines oder mehrere Verzeichnisse festzulegen, in welchen Audit-Protokolle gespeichert werden. Gibt es mehrere Verzeichniseinträge, werden diese in der angegebenen Reihenfolge genutzt, bis sie jeweils gefüllt sind. Es ist üblich, Audit so zu konfigurieren, dass die Audit-Logs auf einem dedizierten Dateisystem abgelegt werden, um Wechselwirkungen zwischen dem Audit-Subsystem und anderen Subsystemen zu verhindern, falls das Dateisystem voll läuft. Das -Feld legt die systemweite Standard-Vorauswahl-Maske für attributierbare (direkt einem Benutzer zuordenbare) Ereignisse fest. Im obigen Beispiel werden alle gescheiterten und erfolgreichen Anmelde- und Abmelde-Ereignisse für alle Benutzer aufgezeichnet. Die Option definiert den minimalen Prozentsatz an freiem Plattenplatz für das Dateisystem, in welchem der Audit-Pfad abgespeichert wird. Wenn diese Schwelle überschritten ist, wird ein Warnhinweis erzeugt. Das obige Beispiel legt den minimalen freien Platz auf zwanzig Prozent fest. Die -Option bestimmt diejenigen Audit-Klassen, für die nicht-attributierbare Ereignisse aufgezeichnet werden sollen (beispielsweise Anmeldeprozesse und System-Daemonen. Die Option legt eine durch Kommata getrennte Liste von policy-Flags fest, welche verschiedene Aspekte des Audit-Verhaltens steuern. Der vorgegebene Flag cnt zeigt an, dass das System trotz eines Audit-Fehlers weiterlaufen soll (dieses Flag wird dringend angeraten). Ein anderes, häufig genutztes Flag ist argv, welches dazu führt, dass Befehlszeilen-Argumente für den Systemauruf &man.execve.2; als Teil der Befehlsausführung aufgezeichnet werden. Die -Option spezifiziert die maximale Größe in Bytes, welche eine Audit-Pfad-Datei wachsen darf, bevor sie automatisch beendet und rotiert wird. Die Standardvorgabe 0 setzt die automatische Log-Rotation ausser Kraft. Falls die angeforderte Dateigröße größer Null und gleichzeitig unterhalb des Minimums von 512K ist, dann wird die Angabe verworfen und ein Log-Hinweis wird erzeugt. Die Datei <filename>audit_user</filename> Die audit_user-Datei erlaubt es dem Administrator, weitere Audit-Erfordernisse für bestimmte Benutzer festzulegen. Jede Zeile konfiguriert das Auditing für einen Benutzer über zwei Felder: Das erste Feld ist alwaysaudit, welches eine Ansammlung von Ereignissen vorgibt, welche immer für diesen Benutzer aufgezeichnet werden. Das zweite Feld neveraudit legt eine Menge an Ereignissen fest, die niemals für diesen Benutzer auditiert werden sollen. Das folgende Beispiel einer audit_user-Datei zeichnet Anmelde/Abmelde-Ereignisse, erfolgreiche Befehlsausführungen für den Benutzer root, Anlegen von Dateien und erfolgreiche Befehlsausführungen für den Benutzer www auf. Falls das Beispiel zusammen mit der vorstehend als Beispiel gezeigten Datei audit_control benutzt wird, dann ist der Eintrag lo für Benutzer root überflüssig und Anmelde/Abmelde-Ereignisse werden für den Benutzer www ebenfalls aufgezeichnet. root:lo,+ex:no www:fc,+ex:no Administration des Audit-Subsystems Audit-Pfade betrachten Audit-Pfade werden im binären BSM-Format gespeichert, daher benötigen Sie spezielle Werkzeuge, um derartige Dateien zu ändern oder Sie in Textdateien zu konvertieren. Der Befehl &man.praudit.1; wandelt alle Pfad-Dateien in ein einfaches Textformat um. Der Befehl &man.auditreduce.1; kann genutzt werden, um die Pfad-Dateien für Analyse, Ausdruck, Archivierung oder andere Zwecke zu reduzieren. auditreduce unterstützt eine Reihe von Auswahl-Parametern einschliesslich Ereignistyp, Ereignisklasse, Benutzer, Datum oder Uhrzeit des Ereignisses und den Dateipfad oder das Objekt, mit dem gearbeitet wurde. Das Dienstprogramm praudit schreibt zum Beispiel den gesamten Inhalt einer angegebenen Audit-Protokolldatei in eine simple Textdatei: &prompt.root; praudit /var/audit/AUDITFILE AUDITFILE ist hier die zu schreibende Protokolldatei. Audit-Pfade bestehen aus einer Reihe von Datensätzen, die wiederum aus Kürzeln (token) gebildet werden, die von praudit fortlaufend zeilenweise ausgegeben werden. Jedes Kürzel ist von einem bestimmten Typ, z.B. enthält header einen audit-Datensatz-Header oder path enthält einen Dateipfad von einer Suche. Hier ein Beispiel eines execve-Ereignisses: header,133,10,execve(2),0,Mon Sep 25 15:58:03 2006, + 384 msec exec arg,finger,doug path,/usr/bin/finger attribute,555,root,wheel,90,24918,104944 subject,robert,root,wheel,root,wheel,38439,38032,42086,128.232.9.100 return,success,0 trailer,133 Dieser Audit stellt einen erfolgreichen execve-Aufruf dar, in welchem der Befehl finger doug ausgeführt wurde. Das Kürzel des Argumentes enthält die Befehlszeile, welche die Shell an den Kernel weiterleitet. Das Kürzel path enthält den Pfad zur ausführbaren Datei (wie vom Kernel wahrgenommen). Das Kürzel attribute beschreibt die Binärdatei (insbesondere den Datei-Modus, der genutzt werden kann, um zu bestimmen, ob setuid auf die Applikation angewendet wurde). Das Kürzel subject beschreibt den untergeordneten Prozess und speichert daher in Aufeinanderfolge Audit-Benutzer-ID, effektive Benutzer-ID und Gruppen-ID, wirkliche Benutzer-ID und Grppen-ID, Process-ID, Session- ID, Port-ID und Anmelde-Adresse. Beachten Sie, dass Audit-Benutzer-ID und wirkliche Benutzer-ID abweichen: Der Benutzer robert wurde zum Benutzer root, bevor er diesen Befehl ausführte, aber er wird auditiert mit dem ursprünglich authentifizierten Benutzer. Schließlich zeigt das Kürzel return die erfolgreiche Ausführung an und trailer schließt den Datensatz ab. praudit unterstützt auch die Ausgabe im XML-Format (die sie über die Option auswählen können). Audit-Pfade reduzieren Da Audit-Protokolldateien sehr groß sein können, wird ein Administrator höchstwahrscheinlich eine Auswahl an Datensätzen verwenden, wie z.B. alle Datensätze zu einem bestimmten Benutzer: &prompt.root; auditreduce -u trhodes /var/audit/AUDITFILE | praudit Dies wird alle Audit-Datensätze des Benutzers trhodes auswählen, die in der Datei AUDITFILE gespeichert sind. Delegation von Rechten für Audit-Reviews - Mitglieder der Gruppe audit haben - die Erlaubnis, Audit-Pfade in /var/audit - zu lesen; standardmässig ist diese Gruppe leer, daher + Mitglieder der Gruppe audit haben die Erlaubnis, + Audit-Pfade in /var/audit zu lesen; + standardmässig ist diese Gruppe leer, daher kann nur der Benutzer root die Audit-Pfade lesen. Benutzer können der Gruppe audit hinzugefügt werden, um Rechte für Audit-Reviews zu gewähren. Da die Fähigkeit, Inhalte von Audit-Protokolldateien zu verfolgen, tiefgreifende Einblicke in das Verhalten von Benutzern und Prozessen erlaubt, wird empfohlen, dass die Gewährung von Rechten für Audit-Reviews mit Bedacht erfolgt. Aktive Überwachung mittles Audit-Pipes Audit-Pipes sind nachgebildete (geklonte) Pseudo-Geräte im Dateisystem des Gerätes, welche es Applikationen erlauben, die laufenden Audit-Datensätze anzuzapfen. Dies ist vorrangig für Autoren von Intrusion Detection Software und Systemüberwachungsprogrammen von Bedeutung. Allerdings ist für den Administrator das Audit-Pipe-Gerät ein angenehmer Weg, aktive Überwachung zu gestatten, ohne Gefahr von Problemen durch Besitzerrechte der Audit-Pfad-Datei oder Unterbrechung des Stroms von Ereignissen durch Log-Rotation. Um den laufenden Audit-Ereignisstrom zu verfolgen, geben Sie bitte folgende Befehlszeile ein: &prompt.root; praudit /dev/auditpipe In der Voreinstellung kann nur der Benutzer root auf die Audit-Pipe-Geräte-Knotenpunkte zugreifen. Um sie allen Mitgliedern der Gruppe audit zugänglich zu machen, fügen Sie eine devfs-Regel in devfs.rules hinzu: add path 'auditpipe*' mode 0440 group audit Lesen Sie &man.devfs.rules.5; für weitere Informationen, wie das devfs-Dateisystem konfiguriert wird. Es ist sehr leicht, Rückmeldungszyklen von Audit-Ereignissen hervorzurufen, in welcher das Betrachten des Resultates eines Audit-Ereignisses in die Erzeugung von mehr Audit-Ereignissen mündet. Wenn zum Beispiel der gesamte Netzwerk-I/O auditiert wird, während &man.praudit.1; in einer SSH-Sitzung gestartet wurde, dann wird ein kontinuierlicher, mächtiger Strom von Audit-Ereignissen erzeugt, da jedes ausgegebene Ereignis wiederum neue Ereignisse erzeugt. Es ist anzuraten, praudit an einem Audit-Pipe-Gerät nur von Sitzungen anzuwenden (ohne feingranuliertes I/O-Auditing), um dies zu vermeiden. Rotation von Audit-Pfad-Dateien Audit-Pfade werden nur vom Kernel geschrieben und nur vom Audit-Daemon auditd verwaltet. Administratoren sollten nicht versuchen, &man.newsyslog.conf.5; oder andere Werkzeuge zu benutzen, um Audit-Protokolldateien direkt zu rotieren. Stattdessen sollte das audit Management-Werkzeug benutzt werden, um die Auditierung zu beenden, das Audit-System neu zu konfigurieren und eine Log-Rotation durchzuführen. Der folgende Befehl veranlasst den Audit-Daemon, eine neue Protokolldatei anzulegen und dem Kernel zu signalisieren, die neue Datei zu nutzen. Die alte Datei wird beendet und umbenannt. Ab diesem Zeitpunkt kann sie vom Administrator bearbeitet werden. &prompt.root; audit -n Falls der auditd-Daemon gegenwärtig nicht läuft, wird dieser Befehl scheitern und eine Fehlermeldung wird ausgegeben. Das Hinzufügen der folgenden Zeile in /etc/crontab wird die Log-Rotation alle zwölf Stunden durch &man.cron.8; erzwingen: 0 */12 * * * root /usr/sbin/audit -n Die Änderung wird wirksam, sobald Sie die neue /etc/crontab gespeichert haben. Die automatische Rotation der Audit-Pfad-Datei in Abhängigkeit von der Dateigröße ist möglich durch die Angabe der Option in &man.audit.control.5;. Dieser Vorgang ist im Abschnitt Konfigurationsdateien dieses Kapitels beschrieben. Komprimierung von Audit-Pfaden Da Audit-Pfad-Dateien sehr groß werden können, ist es oft wünschenswert, Pfade zu komprimieren oder anderweitig zu archivieren, sobald sie vom Audit-Daemon geschlossen wurden. Das Skript audit_warn kann genutzt werden, um angepasste Aktionen für eine Vielzahl von audit-bezogenen Ereignissen auszuführen, einschliesslich der sauberen Beendigung von Audit-Pfaden, wenn diese geschlossen werden. Zum Beispiel kann man die folgenden Zeilen in das audit_warn-Skript aufnehmen, um Audit-Pfade beim Beenden zu komprimieren: # # Compress audit trail files on close. # if [ "$1" = closefile ]; then gzip -9 $2 fi Andere Archivierungsaktivitäten können das Kopieren zu einem zentralen Server, die Löschung der alten Pfad-Dateien oder die Reduzierung des alten Audit-Pfades durch Entfernung nicht benötigter Datensätze einschliessen. Das Skript wird nur dann ausgeführt, wenn die Audit-Pfad-Dateien sauber beendet wurden, daher wird es nicht auf Pfaden laufen, welche durch ein unsauberes Herunterfahren des Systems nicht beendet wurden.