Audit eines OS X Systems

Audit eines OS X Systems

Rocco Gagliardi
von Rocco Gagliardi
Lesezeit: 17 Minuten

Ein Mac ist ein Mac und er funktioniert. Vor einem Macbook Retina werden Sie sich wohl fühlen, so lange sie sich mit OS X zurecht finden.

OS X

Was passiert aber hinter dem wunderschönen Sonnenuntergang in Yosemite? Werden die Aktionen eines Users oder einer Applikation geloggt? Kann OS X in einer zertifizierten Umgebung gebraucht werden, wenn ein komplettes Audit notwendig ist?

Das Problem

Unter OS X besteht die Möglichkeit mit Console.app einen Blick auf die standardmässig generierten Logfiles des Systems zu werfen. Wenn Sie Superuserberechtigungen haben, dann können Sie die geschützten Logfiles des Systems ansehen und somit authd wie auch andere spezifische Logs in der Apple System Log Facility (ASL) einsehen.

Aber das ist nur das Logging und das reicht für eine zertifizierte Umgebung einfach nicht aus. Denn in solchen Umgebungen ist auditing zwingend notwendig.

Auditing einer Infrastruktur, andererseits, rapportiert jede Instanz eines Low-Level-Events, egal von welchem Programm ausgelöst. – Security Log, Part 1: Experience with Log Management – What is a log

Security Auditing beinhaltet das Erkennen, das Aufzeichnen, das Abspeichern und die Analyse von Informationen im Zusammenhang mit sicherheitsrelevanten Aktivitäten. Der daraus resultierende Auditreport kann Aufschluss darüber geben, welche sicherheitsrelevanten Aktivitäten wo stattgefunden haben und welcher User dafür verantwortlich ist – Common Criteria, Class Family Audit: Security Audit

Mit OS X Panther (10.03.6, 2004) ist Apple dem Audit-Problem begegnet, indem sie sowohl die Server- wie auch die Desktop-Version an NIAP überreicht haben um die Common Criteria Certification zu erhalten. Common Criteria ist ein international anerkanntes Set von Security Standards und stellt eine klare und verlässliche Evaluation der Sicherheitsmöglichkeiten eines IT-Produkts dar. Sicherheitsbewusste Konsumenten beachten die Common Criteria Certification als einen entscheidenden Faktor beim Kauf.

Die Lösung

Im Jahre 2004 hat Apple die neue Software openBSM veröffentlicht. Das Programm wurde von McAfee Research, der Security-Research-Abteilung McAfees, geschrieben. Zudem waren Wayne Salamon, Robert Watson und SPARTA Inc. Involviert. Das Basic Security Module (BSM) Interface und das Audit Event Stream Format wurden von Sun Microsystems definiert. Um alle Involvierten zu sehen, können Sie die komplette Liste ansehen.

Gleichzeitig wurde der Common Criteria Configuration and Administration Guide veröffentlicht, der Security Administratoren helfen sollte, das OS richtig zu konfigurieren.

Etwas ältere Leser werden BSM kennen. Es ist nicht wirklich neu. Es ist das Solaris Basic Security Module, ein von Sun Microsystems geschaffenes Tool, das die DoD _C2-Level_-Zertifizierung von Solaris 2.5.1 sicherstellt. Das war anno 1996. Das Tool kann jeden sys-Call zurückverfolgen indem die Ausführung jeden laufenden Prozesses abgefangen wird, die Informationen in einer Binary gespeichert und bei Bedarf rapportiert wird.

OpenBSM: Was wo geloggt wird

Die Hauptkonfigurationsdatei für Auditing ist /etc/security/audit_control. In dieser Datei setzen wir die Classes der Events, für die wir Audit-Records erstellen wollen und wo wir diese abgespeichert haben wollen.

Die standardmässige Konfiguration unter Yosemite /etc/security/audit_control lautet:

#
# $P4: //depot/projects/trustedbsd/openbsm/etc/audit_control#8 $
#
dir:/var/audit
flags:lo,aa
minfree:5
naflags:lo,aa
policy:cnt,argv
filesz:2M
expire-after:10M
superuser-set-sflags-mask:has_authenticated,has_console_access
superuser-clear-sflags-mask:has_authenticated,has_console_access
member-set-sflags-mask:
member-clear-sflags-mask:has_authenticated

Einige Parameter sind selbsterklärend. Für eine komplette Liste verweise ich Sie an die audit_control(5)-Seite. Die folgenden Parameter sind interessant:

Parameter Beschreibung
flags Spezifiziert, welche Audit-Event-Klassen auditiert für alle User auditiert werden.
naflags Beinhaltet die Audit Flags, die definieren, welche Event-Classes auditiert werden und was passiert, wenn eine Action nicht einem spezifischen User zugeordnet werden kann.
policy Eine Liste globaler Audit-Policy-Flags, die verschiedene Verhaltensweisen spezifizieren, zum Beispiel Fail Stop, Auditing von Pfaden und Argumenten, etc.

Was auditiert werden kann wird mit flags festgesetzt. Die folgende Tabelle listet auf, welche Event classes auditiert werden können.

Code Class Beschreibung der Class
0×00000000 no invalid class
0×00000001 fr file read
0×00000002 fw file write
0×00000004 fa file attribute access
0×00000008 fm file attribute modify
0×00000010 fc file create
0×00000020 fd file delete
0×00000040 cl file close
0×00000080 pc process
0×00000100 nt network
0×00000200 ip ipc
0×00000400 na non attributable
0×00000800 ad administrative
0×00001000 lo login_logout
0×00002000 aa authentication and authorization
0×00004000 ap application
0×20000000 io ioctl
0×40000000 ex exec
0×80000000 ot miscellaneous
0xffffffff all all flags set

Die Audit Policy Flags spezifizieren wie das System auf einige Events reagiert soll oder welche Details geloggt werden sollen.

Policy Flag Beschreibung
cnt Erlaubt es Prozessen, weiter zu laufen auch wenn Events nicht einem Audit unterzogen werden. Aktuell ist das not recoverable
ahlt Fail Stop_-Befehl für das System wenn ein Event keinem Audit unterzogen werden kann. Das beinhaltet, dass noch offene Aufzeichnungen auf eine Disk gespült werden und das Operating System dann angehalten wird.
argv Audit command line arguments für execve(2).
arge Audit environmental variable arguments für execve(2).
seq Fügt den generierten Audit Records ein _unique audit sequence number token hinzu. (Nicht in FreeBSD und Darwin enthalten)
group Fügt den generierten Audit Records weitere Gruppen hinzu. Das geht nicht in FreeBSD und Darwin, wo weitere Gruppen nie in Records inkludiert werden.
trail Fügt den Audit Records ein Trailer Token hinzu. Das geht nicht in FreeBSD und Darwin, wo Trailer Tokens immer inkludiert sind
path Beinhaltet sekundäre Dateipfade in den Audit Records. Das geht nicht in FreeBSD und Darwin, wo weitere Gruppen nie in Records inkludiert werden.
zonename Fügt den Records ein Zone ID Token hinzu. Diese Funktion ist nicht in FreeBSD und Darwin implementiert. FreeBSD Audit Records inkludiert aktuell weder jail ID noch Name.
perzone Aktiviert Auditing für jede lokale Zone. Dies ist nicht in FreeBSD oder Darwin implementiert. Dort werden Audit Records aller Jails gesammelt und in einem global trail platziert. In einem Jail werden nur limitierte Audit Controls zugelassen.

Welche Systeme sollen auditiert werden?

Alle! Das ist die Standardantwort. Wenn Sie das tun, dann werden Sie jede Information, die das System generiert, sammeln. Aber diese Sammlung hat einen grossen Einfluss auf das System selbst:

Auf einem Server-System muss die Policy so angepasst werden, damit Sicherheit und Availability des Systems gewahrt werden.

Minimal empfohlene Classes: lo, ad, na. Das beinhaltet:

OpenBSM Audit System aus der CC Perspektive

FAU_ARP: Security Audit Automatic Response

Die TSF soll alle Actions auflisten, sobald diese eine potentielle Verletzung der Sicherheitsrichtlinien erkennen. Das openBSM-Paket hat ein Tool namens auditfilterd, das aber, als Standard, weder kompiliert noch auf OS X installiert ist, da es nie den Status experimental verlassen hat. Dennoch ist der Source Code erhältlich und, mit einigen Fixes, sogar auf OS X lauffähig sein. Damit kann mit einem Live Log herumgespielt werden. Zudem kann auch /dev/auditpipe angebunden werden.

Starten Sie praudit in /dev/auditpipe um das Audit Log in Echtzeit zu dekodieren.

rcc@mpb~$ sudo praudit /dev/auditpipe
header,88,11,SecSrvr AuthEngine,0,Tue Dec 16 11:20:06 2014, + 119 msec
subject,-1,root,wheel,root,wheel,40,100000,41,0.0.0.0
text,begin evaluation
return,success,0
trailer,88
...

Lassen Sie auditreduce laufen um die Records zu filtern. Die Resultate sind immer noch in Binary und müssen mit praudit konvertiert werden.

rcc@mpb~$ sudo auditreduce -cfd /dev/auditpipe
T:I#O/Users/rcc/Library/Application Support

Starten Sie praudit um den Binary Record in von Menschen lesbarer Form darzustellen.

rcc@mpb~$ sudo auditreduce -cfd /dev/auditpipe | praudit
header,311,11,rename(2),0,Tue Dec 16 11:26:48 2014, + 572 msec
path,/Users/rcc/Library/Application Support/TextMate/Session/.dat29f8.0b3
path,/Users/rcc/Library/Application Support/TextMate/Session/.dat29f8.0b3
attribute,100644,rcc,staff,16777220,10648235,0
path,/Users/rcc/Library/Application Support/TextMate/Session/Info.plist
subject,rcc,rcc,staff,rcc,staff,10744,100005,50331650,0.0.0.0
return,success,0
trailer,311

Zusammenfassung

Auditing ist aus zwei Gründen wichtig:

  1. Regelmässige Analyse der Logs geben uns frühzeitig Hinweise auf verdächtige Aktivität.
  2. Wenn die Logs sicher abgelegt werden, kann die Log-Analyse kann zur Beweislage beitragen, wenn es darum geht, nach einem Breach in der Security Policy herauszufinden, was während des Breaches falsch gelaufen ist.

Es gibt weitere Felder, in denen Auditing ebenfalls hilft. Da wäre unter anderem die Analyse der Security Policies in Bezug auf korrekte Implementation oder Debug Auditing, das wichtige Auskunft über unser Security-Modell geben kann.

openBSM bietet ein Auditingsystem an, das Teil des Core OS X ist.

Die Security Event Auditing Facility ist in der Lage, detaillierte Logs der Systemaktivität zu generieren. In einem sehr beschäftigten System können Trail-File-Daten sehr gross werden, wenn sie sehr detailliert konfiguriert werden. Das kann zu Datenmengen von mehreren Gigabyte pro Woche führen. Administratoren sollten die Anforderungen an den Speicherbedarf von grossen Audit-Konfigurationen stets beachten.

En Passant

Während der Recherche zu diesem Artikel ist ein LoL Boundary Check aufgetaucht: openbsm/sys/bsm/audit_kevents.h

/*
 * The reserved event numbers for kernel events are 1...2047 and 43001..44900.
 */
#define     AUE_IS_A_KEVENT(e)     (((e) > 0 && (e) < 2048) ||      \
                         ((e) > 43000 && (e) < 45000))

Das Problem liegt entgegen den Angaben der Datei openbsm/etc/audit_event im Kommentar, nicht im Code.

# Allocation of BSM event identifier ranges:
#
# 0                    Reserved and invalid
# 1     - 2047         Reserved for Solaris kernel events
# 2048  - 5999         Reserved and unallocated
# 6000  - 9999         Reserved for Solaris user events
# 10000 - 32767        Reserved and unallocated
# 32768 - 65535        Available for third party applications
#
# Of the third party range, OpenBSM allocates from the following ranges:
#
# 43000 - 44999        Reserved for OpenBSM kernel events
# 45000 - 46999        Reserved for OpenBSM application events

Über den Autor

Rocco Gagliardi

Rocco Gagliardi ist seit den 1980er Jahren im Bereich der Informationstechnologie tätig. In den 1990er Jahren hat er sich ganz der Informationssicherheit verschrieben. Die Schwerpunkte seiner Arbeit liegen im Bereich Routing, Firewalling und Log Management.

Links

Sie wollen Ihr Log und Monitoring auf das nächste Level bringen?

Unsere Spezialisten kontaktieren Sie gern!

×
Schutz vor Phishing

Schutz vor Phishing

Rocco Gagliardi

Logging

Logging

Rocco Gagliardi

IT Security Policies

IT Security Policies

Rocco Gagliardi

Sie wollen mehr?

Weitere Artikel im Archiv

Sie brauchen Unterstützung bei einem solchen Projekt?

Unsere Spezialisten kontaktieren Sie gern!

Sie wollen mehr?

Weitere Artikel im Archiv