2 Linux Technical Review, Ausgabe 10

ExakteSystemkontrolle

Geht es um die Protokollierung auf Unix-Sy-

stemen, so fällt einem schnell der altgediente

Syslog-Daemon ein. Jedoch besitzt der Linux-

Kernel parallel dazu seit einiger Zeit ein sehr viel

leistungsstärkeres Auditing-System, das die

meisten Linux-Distributionen auch schon ver-

wenden können. Für die Auswertung der Proto-

kolle ist gibt es komfortable Tools. Thorsten Scherf

Rubrik

3Linux Technical Review, Ausgabe 10

Zum einen sind Audit-Systeme Voraussetzung für eine Sicherheits-Zertifizierung des Betriebs-systems nach einem Standard wie etwa Com-mon Criteria (siehe Kasten Common Criteria-Zertifizierung). Zum anderen aber ist dieses Feature auch für den regulären Systembetrieb nützlich, lassen sich doch so eine Vielzahl von interessanten Meldungen bequem festhalten und auswerten.Die Idee eines Audit-Systems ist im Linux-Um-feld nicht neu. Schon in den frühen Tagen der Linux-2.4er-Kernel-Reihe entstand die Soft-ware Snare. Sie versprach Auditing auf C2-Level („Orange Book“). Wegen diverser Unstimmig-keiten fand Snare allerdings nie großen Zu-spruch in der Kernel-Community. Der nächste Versuch, eingeleitet von Olaf Kirch und Thomas Biege, gründete sich auf LAuS, das Linux Audit Subsystem. LAuS benutzen einige ältere Linux-Systeme wie SLES9 und RHEL3 immer noch. Dank LAuS erhielten Linux-Systeme mit einem Kernel 2.4 die erste Zertifizierung nach Com-mon Criteria EAL3.

Alles neuAber auch hier gab es Probleme hinsichtlich der Code-Qualität und Stabilität. Schließlich be-gann Rik Faith mit der Entwicklung eines neuen Audit-Systems für den Linux-Kernel 2.6. Aktu-ell betreut Steve Grubb dieses Projekt. Dieser neue Audit-Daemon stellt sehr umfangreiche Protokoll-Möglichkeiten zur Verfügung. Unter anderem beobachtet ern die Linux-Security-Modules (LSM)/SELinux,n den Aufruf und die Beendigung von System-Aufrufen,n Dateioperationen,n die Prozess-Generierung.Zudem gibt es eine Reihe von Events die der »auditd« automatisch protokolliert. Hierzu zäh-len beispielsweise User-Logins und -Logoffs. Eine detaillierte Liste aller Events erhält man mittels »ausearch -m«.Das Audit-System besteht aus mehreren Kom-ponenten, die sich einzeln deaktivieren lassen:n dem eigentliche Framework im Kernel (»ker-

nel/audit.c« und »kernel/auditsc.c«),n dem Audit-Daemon im User-Space für die

Verarbeitung der Audit-Ereignisse,n einem Event-Dispatcher. Hiermit lassen

sich Audit-Events in Echtzeit an andere Pro-gramme, beispielsweise ein Intrusion Detec-tion System (IDS), weiterleiten,

n einigen weiteren Tools im User-Space zur Konfiguration und Verwaltung. Hierzu zäh-len »audtictl«, »ausearch«, »aureport«.

Ist der »auditd« im User-Space aktiviert, lauscht er auf einem Netlink-Socket auf Meldungen des Kernel Audit-Systems. Meldet das ein Ereignis, so schreibt der »auditd« einen entsprechenden Eintrag in die Logdatei »/var/log/audit/audit.log«. Wurde der Audit-Daemon beim System-start mit Hilfe des Bootparameters »audit=0« deaktiviert so ignoriert der Kernel alle vorhan-denen Audit-Regeln und schickt lediglich die

Für bestimmte, besonders sensible Umgebungen ist eine Prüfung der dort einzusetzenden Computersysteme nach Common Criteria (CC) [1] notwendig. Dabei handelt es sich um einen internationalen Standard (ISO 15408) für die Bewertung und Zertifizierung der Sicherheit von Com-putersystemen. Common Criteria hat das Ziel, ältere, länderspezifische Standards, wie ITSEC (Europa) und TCSEC (Amerika) abzulösen.Die Bewertung eines Systems erfolgt nach dessen Funktionalität und Vertrauenswürdigkeit. Hierfür stehen sieben hierarchisch gegliederte Stufen zur Verfügung (Evaluation Assurance Level, EAL1-7). Die Art der Untersuchung ist über Funktionalitätsklassen definiert. Dabei lässt sich Funktionalitätsklassen zu so genannten Schutzprofilen zusammenfassen die dann den typischen Funktionsumfang bestimmter Produkte (Be-triebssysteme, Smartcards und so weiter) beschreiben. Red Hat Enter-prise Linux Version 5 (RHEL5) hat beispielsweise eine Zertifizierung nach EAL4+ erhalten, was die folgendne Funktionsklassen einschließt:n Controlled Access Protection Profile (CAPP)n Labeled Security Protection Profile (LSPP)n Role Based Access Control Protection Profile (RBAC)Die entspricht eine Zertifizierung nach dem alten B2 TCSEC- beziehungs-weise E4 ITSEC-Standard.

Common Criteria Zertifizierung

Audit-Events

Remote Logging setroubleshoot IDS/IPS

Audit-Daemon

Event-Dispatcher

Kernel Space

User Space

Abbildung 1: Über diesen Multiplexer lassen sich Events in Echtzeit an an-dere Programme weiterleiten.

4 Linux Technical Review, Ausgabe 10

Rubrik

Eintrag »num_logs« bestimmt die maximale Anzahl der Archiv-Logs bei einer Rotation (bis zu 99). Eine solche Rotation findet statt, wenn der »auditd« ein Signal USR1 empfängt. Dieses Signallöst beispielsweise »/etc/init.d/auditd ro-tate« aus.Die Einstellung »dispatcher« gibt den Namen des Event-Multiplexers an. Die Option »disp_qos« kann entweder »lossy« oder »lossless« enthalten. Im Ergebnis wird damit festgelegt, wie sich der »auditd« verhalten soll, wenn der 128-KByte-Puffer überläuft, den er und der Dispatcher für ihre Kommunikation verwenden. Im Falle von »lossy« (Default) gelangen neue Events in das Log, aber eventuell nicht zum Dispatcher. Im Falle von »lossless« wartet der »auditd« bis der Dispatcher alle Events entgegengenommen hat. Dabei besteht die Gefahr, das nicht alle Events den Weg ins Log finden.

Log-HandlingDie nächsten Anweisungen beziehen sich aus-schließlich auf die Log-Dateien: »name_format« legt fest, ob Rechner über Ihren Namen (oder den Fully Qualified Name, FQN) oder ihre IP-Adresse im Log vermerkt werden. Bei der Angabe von »hostname« oder »fqn« wird der Syscall »gethostname« verwendet, um den Na-men des Rechners zu ermitteln. »max_log_file« bestimmt die maximale Größe einer Logdatei in Megabyte und »max_log_file_action« was passieren soll, wenn diese maximale Dateigröße erreicht ist.Sinnvolle Einstellungen sind hier »syslog« und »rotate«. Im ersten Fall wird eine Warnung über den »syslogd« ausgegeben und »rotate« rotiert das Log und legt ein neues an. Sobald weniger Platz auf der Logpartition zur Verfügung steht als in »space_left« abgegeben, warnt der Au-ditd. Wie diese Warnung aussieht, lässt sich in »space_left_action« definieren. Mögliche Opti-onen hier sind »syslog« und »email«. Bei »sys-log« wird wieder über den Syslog-Daemon ge-warnt, »email« schickt eine Warnung per Mail an den in »action_mail_acct« definierten Ac-count.Die letzten beiden Anweisungen bestimmen das Verhalten des Auditd, sobald er keinen Schreib-zugriff mehr auf seine Logdatei bekommt, sei es weil die Festplatte voll ist (»disk_full_action«) oder ein anderer Fehler (»disk_error_action«) aufgetreten ist. Steht hier »suspend« meint das, dass der Daemon alle Schreibaktivitäten ein-

LSM/ SELinux-Meldungen über einen »printk«-Aufruf an den Syslog-Daemon. Der speichert die Mel-dungen dann anhand sei-ner Konfiguration, übli-cherweise in der Logdatei »/var/log/messages«.

Der Audit-Daemon lässt sich grundsätzlich über

zwei Dateien in »/etc/audit/« konfigurieren. »auditd.conf«

(Listing 1) und »audit.rules«. Er-stere legt allgemeine Informationen

über den Dienst fest, letztere enthält die ei-gentlichen Regeln, die bestimmen was auf dem lokalen System zu protokollieren ist.Über »log_format«lässt sich die Art der Proto-kollierung einstellen. Als default kommt »RAW« zum Zug – »NOLOG« sorgte stattdessen dafür, dass der »auditd« selbst keine Logs erzeugt, die Events aber an den Dispatcher weiterleitet. Die Option »log_group« bestimmt fest, welche Gruppe die Rechte an der Logdatei erhält. Über »priority_boost« wird eine Prioritätsstufe für den Daemon definiert. Hier besagen »flush« und »freq«, nach wievielen Einträgen ein Flush der Audit-Daten auf die Festplatte erfolgen soll. Der

01 #02 # This file controls the configuration of the audit daemon03 #04 05 log_file = /var/log/audit/audit.log06 log_format = RAW07 log_group = root08 priority_boost = 409 flush = INCREMENTAL10 freq = 2011 num_logs = 412 disp_qos = lossy13 dispatcher = /sbin/audispd14 name_format = NONE15 max_log_file = 516 max_log_file_action = ROTATE17 space_left = 7518 space_left_action = SYSLOG19 action_mail_acct = root20 disk_full_action = SUSPEND21 disk_error_action = SUSPEND

Listing 1: /etc/ audit/ auditd.conf

Rubrik

5Linux Technical Review, Ausgabe 10

Neben diesen einfachen Dateiüberwachungen lassen sich auch Regeln für komplexere Ereig-nisse erstellen. Dafür stehen fünf Listen zur Ver-fügung, die Ereignisse protokollieren, nämlichn task – nimmt Meldungen über neue Prozesse

auf, die »fork()« oder »clone()« erzeugen,n entry – für alle Aufrufe von System-Calls,n exit – für das Beenden eines System-Calls, .n user – als Filter für Meldungen, die Ihren Ur-

sprung im User-Space habenn exclude – um bestimmte Ereignisse vom Pro-

tokoll auszuschließen

Komplexe RegelnEine Audit-Regel einer solchen Liste besteht aus mehreren Teilen: Neben dem Namen der gewünschten Liste ist auch der fragliche Syste-maufruf und ein weiteres Regelfeld anzugeben. Eine Übersicht aller verfügbaren Systemaufrufe zeigt die Hilfe-Seite zu »syscalls«. In der Hilfe-Seite zu »auditctl« wird fündig, wer eine Aufli-stung der weiteren Regelfelder sucht.Möchte man beispielsweise alle Aktivitäten eines bestimmten Benutzers überwachen, so reicht folgende Regel:

[root@tiffy ~]# auditctl ‑a exit,alwaysU

‑S all ‑F auid=500

Sobald nun der Benutzer mit der Login-UID 500 etwa eine Datei öffnet, wird dieser Zugriff unmittelbar im Log festgehalten:

stellt. Mittels »exec /path/to/script« lässt sich in solch einem Fall aber auch ein Skript ausführen, um weitere Maßnahmen einzuleiten.

Einfache RegelsätzeDie zweite Konfigurationsdatei, »audit.rules«, enthält die eigentlichen Regelsätze. Sie las-sen sich entweder manuell hinzufügen oder aber mit Hilfe des Programms »auditctl« de-finieren. In dem Dokumentationsordner »/usr/share/doc/audit-version« finden sich be-reits vorgefertigte Regeln, die dem Audit-Level bestimmter CC-Schutzprofile (CAPP, LSPP, NI-SPOM) entsprechen. Diese Dateien lassen sich bei Bedarf einfach nach »/etc/audit/« kopieren und anschließend dort in »audit.rules« umben-nen.Mit dem Befehl »auditctl -s« sieht man die aktu-ellen Einstellungen des Audit-Systems:

[root@tiffy ~]# auditctl ‑sAUDIT_STATUS: enabled=1 flag=1 pid=2108 U

rate_limit=0 backlog_limit=1024 lost=0 U

backlog=0

Möchte man nun zum Beispoiel eine einfache Datei-Überwachungen (so genannte File-Wat-ches) festlegen, bewerkstelligt das folgendes Kommando:

[root@tiffy ~]# auditctl ‑w /etc/auditU

/auditd.conf ‑p wa ‑k CFG_auditd.conf

Der Schalter »-w« gibt hier die zu überwa-chende Datei an, Die Opion »-p« bestimmt die Art des Zugriffs auf die Datei (dabei steht »w« für write, »r« für read, »x« für execute und »a« für eine Attributänderung). Mit Hilfe von »-k« kann der Answender einen Filter-Key mit der jeweiligen Regel verknüpfen. Dank seiner Hilfe sind die Audit-Meldungen später sehr leicht im Log auffindbar.Ändert der Anwender nun beispielsweise die Zugriffsrechte an der beobachteten Datei, so er-zeugt das einen entsprechenden Audit-Eintrag im Log:

type=SYSCALL msg=audit(1218578553.587:U 8099): arch=40000003 syscall=306U

success=yes exit=0 a0=ffffff9 a1=90e48d8U

a2=1b4 a3=90e48d8 items=1 ppid=3431U

pid=9603 auid=500 uid=0 gid=0 euid=0U suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 U

tty=pts0 ses=1 comm=„chmod“ exe=“/ bin/U

chmod“ key=„CFG_auditd.conf“Abbildung 2: Der audit-Daemon kennt fünf unterschiedliche Listen zum Protokollieren von System-Ereignissen.

6 Linux Technical Review, Ausgabe 10

Rubrik

type=SYSCALL msg=audit(1218580825.U

598:447527): arch=40000003 syscall=5success=yes exit=3 a0=bfb96520 a1=8000U

a2=0 a3=8000 items=1 ppid=3910pid=12030 auid=500 uid=500 gid=500 U

euid=500 suid=500 fsuid=500 egid=500sgid=500 fsgid=500 tty=pts5 ses=1 U

comm=“cat“ exe=“/bin/cat“ key=(null)type=CWD msg=audit(1218580825.U

598:447527):cwd=“/home/tscherf/cvs/artikel/auditd“type=PATH msg=audit(1218580825.598:U

447527): item=0 name=“/etc/hosts“inode=154141 dev=08:06 mode=0100644 U

ouid=0 ogid=0 rdev=00:00

Anhand dieses Log-Eintrages lässt sich nicht nur erkennen, welche Datei geöffnet wurde (»name=“/etc/hosts“«), man sieht darüber hi-naus, welches Programm dafür benutzt wurde (»exe=“/bin/cat“«) und sogar aus welchem Verzeichnis der Zugriff auf das Files stattgefun-den hat (»cwd=“/home/tscherf/cvs/artikel/au-ditd“«).Möchte man einige der automatisch geloggten Events, wie beispielsweise ein User-Login, nicht protokollieren, so lässt sich dafür eine Regel in die Exclude-Liste schreiben:

[root@tiffy ~]# auditctl ‑a exclude,U

always ‑F msgtype=USER_LOGIN

Durch diesen Eintrag bekommt der »auditd« mitgeteilt, dass er den Event-Type 1112, User-Login, nicht protokollieren soll. Eine Zuord-nung zwischen dem Namen und der Nummer des Audit-Event findet sich in der Datei »/usr/include/libaudit.h« aus dem Audit-libs-devel-RPM-Paket.

Tools für die Log-Auswertung

Zum Auswerten der umfangreichen Protokoll-informationen stehen eine Vielzahl von Tools zur Verfügung. Zwei davon gehören zur Grund-ausstattung: Da ist zum einen »aureport«, mit dessen Hilfe sich umfangreiche Berichte erstel-len lassen. Der Aufruf ohne Optionen zeigt eine Zusammenfassung aller bislang erfassten Events an (Listing 2)Durch eine Vielzahl von Optionen ist der Report nahezu beliebig an eigene Bedürfnisse anpass-bar. So lässt sich beispielsweise der zu durchsu-chende Zeitraum einschränken oder eine Event-

01 [root@tiffy ~]# aureport02 03 Summary Report04 ======================05 Range of time in logs: 05/01/2008 00:42:51.366 ‑ 08/13/2008

12:42:43.69306 Selected time for report: 05/01/2008 00:42:51 ‑ 08/13/2008

12:42:43.69307 Number of changes in configuration: 3908 Number of changes to accounts, groups, or roles: 9809 Number of logins: 14210 Number of failed logins: 14611 Number of authentications: 75512 Number of failed authentications: 5313 Number of users: 614 Number of terminals: 4315 Number of host names: 616 Number of executables: 4317 Number of files: 6418 Number of AVC‘s: 17819 Number of MAC events: 19820 Number of failed syscalls: 10721 Number of anomaly events: 14322 Number of responses to anomaly events: 023 Number of crypto events: 024 Number of keys: 025 Number of process IDs: 376326 Number of events: 20247

Listing 2: »aureport«

Abbildung 3: Über »mkbar« und »gnuplot« lassen sich recht ansprechende Grafiken automatisch erzeugen.

Rubrik

7Linux Technical Review, Ausgabe 10

Komplexe RegelnMit Hilfe des Tools »ausearch« lassen sich in der Protokolldatei (oder in via Stdin übergegebenen rohen Logdaten) bestimmte Events suchen und auf dem Terminal ausgeben. Als Suchkriterien können dabei etwa die User-, Gruppen- oder Prozess-ID dienen, Hostnamen, Systmaufrufe, Return-Codes, Message-Typen oder Zeitstem-pel. Gibt der Anwender mehrere Krierien an, verknüpft sie die Kommandozeile automatisch mit »und«. Wer zum Beispiel alle Protokoll-Einträge sehen möchte, die auf einen Zugriff auf die Auditd-Konfigurationsdatei hindeuten können, der sucht einfach nach dem Schlüsselwort das im Beispiel weiter oben beim Anlegen der Regel de-finiert wurde:

Nummer vorgeben, nach der man sucht. Möchte man einen Bericht über alle Anmeldungen des aktuellen Tages sehen, so erledigt das der fol-gende Befehl:

[root@tiffy audit]# aureport ‑‑start U

today ‑‑login

Login Report========================================#date time auid host term exe succ event========================================1. 08/13/2008 12:04:41 500 ? tty1 /bin/U

login yes 4485342. 08/13/2008 12:05:46 500 localhost.U

localdomain /dev/pts/6 /usr/sbin/sshd U

yes 448543

Abbildung 5: Wählt man einen Eintrag aus, so erhält man genaue Informationen zu diesem Event.

Abbildung 4: Über »prewikka« erhält man eine schöne Übersicht aller Events.

8 Linux Technical Review, Ausgabe 10

Rubrik

Einträge zu erhalten die auf den File-Typen »unlabeled_t« verweisen, werden diese einfach aus der Grafik verbannt:

[root@tiffy ~]# aureport ‑a ‑i ‑‑summaryU

| egrep ‑vi ‚unlabeled_t‘ | ./mkbar

Im Ergebnis entsteht die Grafikdatei »chart.png« im aktuellen Verzeichnis, die Abbildung 3 darstellt..Wer Protokolldaten von mehreren Systemen zu verwalten und auszuwerten hat, der wünscht sich eine zentrale Lösung. In Fedora 9 exitiert für das hybride Intrusion-Detection-System Pre-lude [3] ein Auditd-Dispatcher-Plugin. Mit dem Dispatcher ist es möglich, Events in Echtzeit an ein anderes Programm, in diesem Fall an das Prelude-IDS, weiterzuleiten. Prelude basiert auf einer Vielzahl von Sensoren von denen es Infor-mationen sammelt. Zu diesen Sensoren zählen so bekannte Intrusion-Detection-Systeme wie Snort oder auch Samhain. Steve Grubb hat für das hier vorgestellte Auditing-System ebenfalls einen Prelude-Sensor geschrieben. Dieser steht ab Fedora 9 über das Paket »audispd-plugins« zur Verfügung. Ein sehr ausführliches Howto zur Installation von Prelude findet man im Web unter [4].

FazitMit dem neuen Auditing-Daemon steht unter Linux ein sehr leistungsstarkes Protokollie-rungs-System zur Verfügung. Vielfältige Aus-wertungstool bearbeiten und visualisieren auf Wunsch seine Informationen. Mit dem Prelude-Sensor besteht außerdem die Möglichkeit, alle Audit-Events an zentraler Stelle zu speichern, zusammen mit allen ande-ren sicherheitsrelevanten Meldungen, Schließ-lich kommt um den Einsatz des Audit-Daemon ebenfalls kaum herum, wer seine Systeme nach Common Criteria LSPP zertifizieren möchte, kommt um den. (jcb) nnn

Infos[1] CommonCriteria:

[http:// www. commoncriteriaportal. org][2] mkbar:[http:// people. redhat. com/ sgrubb/

audit/ visualize/ mkbar][3] Prelude-Intro:[http:// people. redhat. com/ tscherf/

articles/ IDS/ Prelude. pdf][4] Prelude-/ Auditd-Howto:[http:// people. redhat.

com/ sgrubb/ audit/ prelude. txt]

[root@tiffy audit]# ausearch ‑k U

CFG_auditd.conf ‑‑start today‑‑‑‑time‑>Wed Aug 13 12:56:32 2008type=PATH msg=audit(1218624992.U

217:448633): item=0name=“/etc/audit/auditd.conf“ U

inode=154712 dev=08:06 mode=U

0100664 ouid=0 ogid=0 rdev=00:00type=CWD msg=audit(1218624992.217U

:448633): cwd=“/var/log/audit“type=SYSCALL msg=audit(1218624992.U

217:448633): arch=40000003 syscall=306success=yes exit=0 a0=ffffff9c U

a1=994f8d8 a2=1b0 a3=994f8d8 U

items=1 ppid=3431pid=7473 auid=500 uid=0 gid=0 U

euid=0 suid=0 fsuid=0 egid=0 U

sgid=0 fsgid=0tty=pts0 ses=1 comm=“chmod“ U

exe=“/bin/chmod“ key=“CFG_auditd.conf“

Fahndet man nach allen SELinux-Einträgen des aktuellen Tages, die durch Prozesse aus der Do-mäne »xgps_t« entstanden sind, so hilft der fol-gende Befehl weiter:

[root@tiffy ~]# ausearch ‑‑start today U

‑se xgps_t

Zu beiden Tools stehen eine Vielzahl von wei-teren Optionen zur Verfügung, mit denen sich Inhalt und Form der Berichte sehr genau be-schreiben lassen. Ein Blick in die Hilfe-Seiten von »ausearch« und »aureport« hilft hier weiter.Hat man nur die Protokolldateien einer einzel-nen Maschine auszuwerten, so reichen die Re-port-Möglichkeiten von »aureport« sicherlich vollkommen, zumal sich diese auch sehr schön visualisieren lassen. Hierfür stellt Steve Grubb auf einer Homepage [2] ein kleines Skript na-mens »mkbar« zu Verfügung. Mit dessen Hilfe lassen sich via Gnuplot sehr ansprechende Gra-fiken aus den Aureport-Ausgaben erzeugen. Eine Übersicht sämtlicher SELinux-Meldungen erhält man beispielsweise durch den folgenden Befehl:

[root@tiffy ~]# aureport ‑a U

‑i ‑‑summary

Um aus der Textausgabe eine ansprechende Gra-fik zu erzeugen schickt man die Ausgabe einfach durch das Skript »mkbar«. Um nicht ein ver-fälschtes Ergebnis durch die zahlreichen Deny-

Rubrik

9Linux Technical Review, Ausgabe 10