Tom Rhodes Geschrieben von Robert Watson Daniel Seuffert Übersetzt von AUDIT Security Event Auditing MAC FreeBSD 6.2-RELEASE und folgende Versionen verfügen über Unterstützung für 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-Auditing. 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 Nutzer 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 Mechanisemen der Kernel-Konfiguration und -Kompilierung vertraut sein (). Einige Vertrautheit mit Sicherheit haben, wie dies zu &os; gehört (). Die Audit-Funktionalität in &os; 6.2 ist experimentell. Ihre Anwendung auf produktiven Systemen sollte nach sorgfältiger Abwägung der Risiken des Einsatzes experimenteller Software erfolgen. Bekannte Beschränkungen schliessen ein, dass zur Zeit nicht alle sicherheitsrelevanten System-Ereignisse auditierbar sind und dass einige Anmelde-Mechanismen, wie z.B. X11-basierte Bildschirm-Manager und Daemons 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 Gigabyte pro Woche in einigen Konfigurationen übersteigen. Administratoren sollten den benötigten Plattenplatz berücksichtigen in Verbindung mit umfangreichen Audit-Konfigurationen. Zum Beispiel 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. Vor dem Lesen dieses Kapitels müssen einige Audit-bezogene Schlüsselbegriffe erläutert werden: event: Ein auditierbares Ereignis ist ein selbiges, welches mit dem Audit-Subsystem aufgezeichnet werden kann. Beispiele für sicherheitsrelevante Systemereignisse schliessen das Anlegen von Dateien, die Erstellung einer Netzwerkverbindung oder eine Benutzeranmeldung ein. Ereignisse sind entweder attributierbar, können also auf einen authentifizierten Nutzer zurückverfolgt werden, oder sind nicht-attributierbar falls nicht. Beispiele für nicht-attributierbare Ereignisse sind alle, welche geschehen vor einer Authentifizierung im Anmeldeprozess, wie z.B. falsche Passworteingaben. class: Ereignisklassen sind benannte Zusammenstellungen von zusammengehörenden Ereignissen und werden benutzt in Auswahl-Ausdrücken. Häufig genutzte Klassen von Ereignissen schliessen 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 (Nutzer), 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 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 Nutzer 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 und nach dieser Frist kann der Pfad z.B. reduziert werden auf die Anmeldeinformationen für archivarische Zwecke. Die Unterstützung des Ereignis-Audit für den Nutzerbereich wird installiert als Teil der Basis von &os; seit 6.2-RELEASE. Allerdings muss die Audit-Unterstützung extra in den Kernel kompiliert werden durch Hinzufügen folgender Zeile in die Kernel-Konfigurationsdatei: options AUDIT Bauen und installieren Sie den Kernel wieder über den üblichen Prozess, welcher in beschrieben ist. Sobald der Kernel gebaut und installiert ist und das System neu gestartet wurde, aktivieren Sie den Audit-Daemon durch Hinzufügung folgender Zeile zu &man.rc.conf.5;: auditd_enable="YES" Die Audit-Unterstützung muss nun ausgeführt werden durch einen Neustart oder das manuelle Starten des Audit-Daemon: /etc/rc.d/auditd start Alle Konfigurationsdateien für das Sicherheits-Audit finden sich in /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 - Nutzerspezifische 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. Auswahlausdrücke werden an einigen Stellen benützt in der Audit-Konfiguration, 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 Nutzer 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 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 Nutzern verwandt werden. 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 dir wird genutzt, um eines oder mehrere Verzeichnisse festzulegen, in welchen Audit-Protokolle gespeichert werden. Falls mehr als ein Verzeichniseintrag erscheint, dann werden sie 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 flags-Feld legt die systemweite Standard Vorauswahl-Maske für attributierbare (direkt einem Nutzer zuordnungsfähige) Ereignisse fest. Im obigen Beispiel werden alle gescheiterten und erfolgreichen Anmelde- und Abmelde-Ereignisse für alle Nutzer aufgezeichnet. Die Option minfree 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 naflags-Option bestimmt diejenigen Audit-Klassen, für die nicht-attributierbare Ereignisse aufgezeichnet werden sollen, wie der Anmelde-Prozess und System-Daemons. Die Option policy 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 filesz-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 audit_user-Datei erlaubt es dem Administrator weitere Audit-Erfordernisse für bestimmte Nutzer festzulegen. Jede Zeile konfiguriert das Auditing für einen Nutzer über zwei Felder: Das erste Feld ist alwaysaudit, welches eine Ansammlung von Ereignissen vorgibt, welche immer für diesen Nutzer aufgezeichnet werden. Das zweite Feld neveraudit legt eine Menge an Ereignissen fest, die niemals für diesen Nutzer auditiert werden sollen. Das folgende Beispiel einer audit_user-Datei zeichnet Anmelde/Abmelde-Ereignisse, erfolgreiche Befehlsausführungen für den Nutzer root, Anlegen von Dateien und erfolgreiche Befehlsausführungen für den Nutzer www auf. Falls das Beispiel zusammen mit der vorstehend als Beispiel gezeigten Datei audit_control benutzt wird, dann ist der Eintrag lo für Nutzer root überflüssig und Anmelde/Abmelde-Ereignisse werden für den Nutzer www ebenfalls aufgezeichnet. root:lo,+ex:no www:fc,+ex:no Audit-Pfade werden gespeichert im binären BSM-Format, daher müssen Werkzeuge verwandt werden, um die Daten zu ändern oder in Text 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, Archvierung oder andere Zwecke zu reduzieren. auditreduce unterstützt eine Reihe von Auswahl-Parametern einschliesslich Ereignistyp, Ereignisklasse, Nutzer, 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 bestehend aus Kürzeln (token), 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-Ereigniesses: 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 und besonderes 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-Nutzer ID, effektive Nutzer-ID und Gruppen-ID, wirkliche Nutzer-ID und Grppen-ID, Process-ID, Session- ID, Port-ID und Anmelde-Adresse. Beachten Sie, dass Audit-Nutzer-ID und wirkliche Nutzer-ID abweichen: Der Nutzer robert hat gewechselt zum Nutzer root, bevor er diesen Befehl ausführte, aber er wird auditiert mit dem ursprünglich authentifizierten Nutzer. Schliesslich zeigt das Kürzel return die erfolgreiche Ausführung an und trailer schliesst den Datensatz ab. 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 zugehörig zu einem bestimmten Nutzer: &prompt.root; auditreduce -u trhodes /var/audit/AUDITFILE | praudit Dies wird alle Audit-Datensätze auswählen für den Nutzer trhodes, die in der Datei AUDITFILE gespeichert sind. Mitglieder der Gruppe audit haben die Erlaubnis Audit-Pfade in /var/audit zu lesen; standardmässig ist diese Gruppe leer, daher kann nur der Nutzer root die Audit-Pfade lesen. Nutzer 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 Nutzern und Prozessen erlaubt, wird empfohlen, dass die Gewährung von Rechten für Audit-Reviews mit Bedacht erfolgt. Audit-Pipes sind nachgebildete (geklonte) Pseudo-Geräte im Dateisystem des Gerätes, welche 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 Standardmässig kann nur der Nutzer 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. 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. Automatische Rotation der Audit-Pfad-Datei in Abhängigkeit von der Dateigröße ist möglich mit der Option filesz in &man.audit.control.5; und ist im Abschnitt Konfigurationsdateien dieses Kapitels beschrieben. 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 das Folgende zum audit_warn-Skript hinzufügen, um Audit-Pfade beim Beenden zu komprimieren: # # Compress audit trail files on close. # if [ "$1" = closefile ]; then gzip -9 $2 fi Andere Archvierungsaktivitäten könnten das Kopieren zu einem zentralen Server, Löschung der alten Pfad-Dateien oder 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 unbeendet sind durch ein unsauberes Herunterfahren des Systems.