Auditing Exchange

Exchange ist natürlich eine "wichtige" Applikation und hier gibt es eine ganze Menge an Quelle, die angezapft werden können:

Überwachung von Client Zugriffen für Internet Protokolle

Exchange stellt seine Dienste über verschiedene Internetprotokolle bereit, welche ebenfalls protokolliert und entsprechend ausgewertet werden können.

  • IMAP4/POP3
    Abruf bzw. Zugriff auf Mails per IMAP4 oder POP3 kann über die entsprechenden Protokolldateien nachvollzogen werden, sofern das Logging aktiviert ist (Default aus)
  • SMTP
    Wenn Client per SMTP ihre Mails zustellen, dann sollte die nur nach erfolgter Authentifizierung erfolgen. Auch dies kann in den SMTP-Logs nachgeschaut werden, sofern das Logging aktiviert ist (Default aus)
  • IIS (OWA, ActiveSync, WebService)
    Die Zugriffe per Outlook WebAccess, Webservices und in gewissen Grenzen auch ActiveSync können über das IIS-Log nachvollzogen werden.
  • Exchange Store
    Leider schreibt der Exchange Store beim direkten Zugriff der Client per MAPI/RPC oder RPC/HTTP keine vergleichbaren Logs. Drittprogramme wie ExInsight oder ExMon zeigen, dass es technisch durchaus entsprechende APIs gibt.

Überwachung per Eventlog und Diagnoseprotokoll

Es gibt allerdings schon Möglichkeiten, die Zugriffe der Benutzer auf Postfächer zu überwachen. Der Exchange Informationsspeicher kennt verschiedene Diagnosefunktionen, mit denen man bestimmte Zugriffe im Eventlog protokollieren lassen kann. Je nach Version sind die Daten an anderen

  • Exchange 2003
    Hier können Sie das Diagnoseprotokoll über den Exchange System Manager grafisch aktivieren
  • Exchange 2007
    Mangels entsprechender grafischer Möglichkeiten ist hier die PowerShell das Mittel der Wahl. Es reicht schon einen Eintrag von "Lowest" auf "Low" zu stellen

Set-EventLogLevel -Identity "MSExchangeIS\9000 Private\Access Control" -Level low

Beide Einträge bewirken, dass Exchange nun Zugriffe der Anwender im Eventlog ablegt

Ereignistyp:       Warnung
Ereignisquelle:    MSExchangeIS Mailbox Store
Ereigniskategorie: Zugriffssteuerung
Ereigniskennung:   1029
Datum:             28.10.2007
Zeit:              10:48:00
Benutzer:          Nicht zutreffend
Computer:          SRV01
Beschreibung:
user1@msxfaq.local konnte einen Vorgang nicht ausführen, da der Benutzer die folgenden Zugriffsrechte nicht besitzt:
 
'Delete' 'Read Property' 'Write Property' 'Create Message' 'View Item'
'Create Subfolder' 'Write Security Descriptor' 'Write Owner' 'Read Security Descriptor' 'Contact'
 
Der DN des zugehörigen Postfachs lautet /O=MSXFAQ/OU=EXCHANGE ADMINISTRATIVE GROUP (FYDIBOHF23SPDLT)/CN=RECIPIENTS/CN=USER2. Die Ordner-ID befindet sich in dem Datenabschnitt dieses Ereignisses.
 
Weitere Informationen über die Hilfe- und Supportdienste erhalten Sie unter http://go.microsoft.com/fwlink/events.asp.
Daten:
0000: 01 00 00 00 5c 5b f7 f9   ....\[÷ù

Generell muss natürlich auch beobachtet werden, welche zusätzliche Last solche eine Überwachung an das System stellt. Schließlich landen die Einträge im Application Log und könnten andere wichtige Einträge quasi schon verdecken.

Eventlog auswerten

Die Protokollierung im Eventlog ist natürlich nur der erste Schritt. Zum einen kommen nun natürlich sehr viele Events dort an, die über die klassische Eventlog Anzeige nicht mehr sinnvoll auszuwerten sind und zum anderen wird natürlich ein entsprechender "Angreifer" versuchen seine Spuren zu verwischen.

Daher ist es wichtig, diese Events möglichst schnell an ein anderes abgetrenntes System zu übermitteln, z.B. per Syslog Überwachung. Mit einer einfachen Kopie des Events ist es aber nicht getan, da alle Zugriffe auf Ordner protokolliert werden. Eine entsprechende Software muss also aus dem Event auch den Benutzer, das Zielpostfach und vielleicht anhand der Ordner-ID auch den entsprechenden auslesen.

Exchange 2010 "Administrator Audit Logging"

Exchange 2010 nutzt wie Exchange 2007 die PowerShell zur Administration der Konfiguration. Allerdings arbeitet Exchange 2010 mit RBAC. Die PowerShell Befehle werden "remote" durch einen Agenten ausgeführt und dieser kann die ausgeführten Befehle auch protokollieren.

Das Logging muss ebenfalls über die PowerShell aktiviert werden. Die Einstellungen landen dann im Active Directory und nachdem die AD-Replikation diese Einstellung auch überall verfügbar gemacht hat, werten die Exchange 2010 Server diese Konfiguration auch aus.

Die Logs landen in einem eigens anzulegenden Postfach. Damit ist zwar eine zentrale Ablage gegeben, aber ein Postfach wird ein Exchange Admin natürlich auch einfach öffnen und seine Spuren verwischen. Ich hätte hier ein Exchange Audit-Eventlog vorgezogen, was auch einfacher zentralisiert werden kann.

Eine Überwachung von Änderungen am Inhalt ist damit aber nicht abgedeckt.

Exchange 2007 SP2

Mit Exchange 2007 SP2 gibt es nun auch eine Überwachungsfunktion auf Änderungen . Im Eventlog finden Sie ein neues Eventlog, in welchem Änderungen nun auch mit gespeichert werden.

Mein Log ist erst mal leer, weil ich noch keine Überwachung aktiviert habe. Auch diese Überwachung wird über das Diagnoseprotokoll konfiguriert.

Set-EventLogLevel -Identity "MSExchangeIS\9000 Private\Message Access" -Level low
Set-EventLogLevel -Identity "MSExchangeIS\9000 Private\Folder Access" -Level low
Set-EventLogLevel -Identity "MSExchangeIS\9000 Private\Extended Send As" -Level low
Set-EventLogLevel -Identity "MSExchangeIS\9000 Private\Extended Send On Behalf Of" -Level low

Es sind die unterschiedlichen Level möglich, um mehr Details zu erhalten. Seit Exchange 2007 können die Parameter auch per GUI auf den Eigenschaften der Server eingestellt werden.

Eventlog Level für Auditing

Die Ausgabe erfolgt dann im Exchange Audit Eventlog.

Audit Software

Aufgrund dieser Komplexität ist es mir nicht einfach möglich, ein passendes Skript zu erstellen, welches in allen Fällen zuverlässig erlaubte, "irrtümliche" und illegal versuchte Zugriffe unterscheiden kann. Eine Lösung müsste schon über Häufigkeiten und natürlich den angesprochenen Ordner gehen.

Aber eines kann die Überwachung sehr einfach leisten: Es gibt oft Postfächer, auf die sicher nur eine handverlesene Anzahl von Benutzern Zugriff haben darf. So ist ein "Journalpostfach", in welchem letztlich die gesamte Kommunikation liegt.

Und dann muss es diese Zugriffsmuster noch auf "erlaubt" und "verboten" unterscheiden. Es ist natürlich legitim, dass ein Stellvertreter oder Sekretariat ein anderes Postfach öffnet. Es ist auch normal, dass z.B. ein Archivprozess oder Blackberry Server mit einem Dienstkonto sogar sehr viele Postfächer und Elemente liest. Eine Überwachung muss also nicht nur glücklicherweise "fehlgeschlagene" Zugriffsversuche sondern auch leider erfolgreiche Zugriffe in der Flut der normalen Fehler und OK-Meldungen heraus finden. Keine einfache Aufgabe.

Frage:'
Wie lösen Sie das Problem "Auditing" in ihrer Firma? Einfach totschweigen oder mit Drittsoftware ? Schreiben Sie mir!

Weitere Links