Grundsätzliche Informationen zum Security Event Logging / Auditing

Hallo, Fabian am Apparat. Ab und an bearbeiten wir auch Anfragen, in denen wir auf ein Security Logging / Auditing angewiesen sind, so z.B. bei ungewollten Account Lockouts oder Rechteänderungen auf Objekten, die nachvollzogen werden sollen. Es gibt dabei einige Grundsätze, die man nach Möglichkeit bei einem Logging beachten sollte.

Dieser Eintrag behandelt (wie immer) nur einen Teil der Thematik und erhebt keinen Anspruch auf Vollständigkeit. Es wird in diesem Beitrag auf Windows Server 2003 eingegangen. Unter Windows Server 2008 haben sich einige Dinge geändert, auf die hier nicht weiter eingegangen wird. Interessierte können z.B. hier einen kurzen Blick in die Neuerungen werfen: https://blogs.technet.com/askds/archive/2007/10/19/introducing-auditing-changes-in-windows-2008.aspx
Größe der Logfiles / Serverperformance - Allgemeines

Bei einem Auditing von Objektänderungen im Active Directory als auch auf NTFS Filesystem Ebene z.B. auf Fileservern fallen je nach Nutzung der Dienste unter Umständen immense Datenmengen an, die durchaus zu Performanceproblemen auf den jeweiligen Servern führen können.

Hier spielen bei den DCs neben den Änderungen an Objekten auch weitere Prozesse hinein, so z.B. die An- und Abmeldungen von Benutzern oder ggf. der Zugriff auf Objekte wie Drucker o.ä. Schon bei Fileservern mit einer durchschnittlichen Zugriffsfrequentierung in kleineren Umgebungen kann ein Auditing eine große Menge an Audit-Daten generieren, da neben den Änderungen, Löschvorgängen o.ä. das Lesen von Attributen eines AD-Objekts, einer Datei oder eines Ordners (je nach Audit Setting) ebenfalls geloggt werden kann.

In beiden Fällen, also dem Loggen von zusätzlichen Auditing Security Events auf den DCs als auch auf den Fileservern, werden pro zu loggender Aktion mehrere Events geloggt. So kann ein einzelner Zugriff auf eine Datei oder einen Ordner mehr als 4 einzelne Events im Security Eventlog auslösen. Daraus ergibt sich neben dem benötigten Festplattenspeicher auch eine erhöhte I/O Last auf den Systemen, besonders wenn viele Events durch hohe Zugriffsfrequenzen oder kurze Änderungsintervalle geschrieben werden.

Neben der Auswahl der Events, die geloggt werden sollen (darauf wird später noch einmal gesondert eingegangen), sind also im Kern zwei Faktoren zu beachten:

  • die I/O Last auf den Servern; davon sind CPU, RAM und HDD betroffen
  • der Speicherplatz auf den Systemen, der für das Vorhalten der Logfiles bis zum Einsammeln der Logs ggf. durch eine Fremdapplikation bereitgestellt werden muß

Während einer längeren Testphase sollte daher nach Möglichkeit geprüft werden, nach welchem Zeitraum die Logfiles ohne manuelles Eingreifen überschrieben werden können. Somit kann sichergestellt werden, daß die festgesetzte Logfilegröße für jedes einzelne Applikationslog realistisch ist oder ob z.B. das Security Eventlog ggf. sogar größer gewählt werden muß.

Theoretisches Maximum für alle Eventlogs sind derzeit insgesamt ca. 300 MB, d.h. die Summe der Eventlog Größen kann ca. 300 MB nicht überschreiten, siehe 183097 Event log may not grow to configured size https://support.microsoft.com/default.aspx?scid=kb;EN-US;183097 .

Jedoch ist es nicht empfehlenswert, diese Grenze zu erreichen – allenfalls ein langsames Erhöhen der Logfilegröße im Zusammenhang mit einer einhergehenden Performancemessung wäre empfehlenswert, sollte man die Standard Logfilegröße verändern wollen.

Eine Möglichkeit, die Logfilegröße zu beschränken, besteht beispielsweise darin, das Löschintervall in den Security Eventlog Einstellungen auf „1 days“ umzustellen und die Security Logs nach dem Durchlauf eines Provisioningsystems bzw. dem Einsammeln der Daten über MOM o.ä. automatisiert per Batchjob oder ähnlichem zu löschen. Somit wäre sichergestellt, daß die Security Logs direkt nach dem Abholen der Daten wieder geleert werden.

Ich empfehle in jedem Fall das Datenaufkommen und die Serverlast bei einem testweisen Einschalten des Auditings genau zu untersuchen und ggf. entsprechende Schalter und Größen den eigenen Bedingungen anzupassen. Nur so kann eine gute Balance zwischen Aufbewahrungszeiten, Speicherplatz und Systembelastung etc. erreicht werden.

Für diese Tests kann beispielsweise der Server Performance Advisor (SPA) (siehe 5) genutzt werden. Mit diesem Advisor kann man eine Basislinie für die Serverauslastung erzeugen, um diese mit der Basislinie nach testweise eingeschaltetem Logging zu vergleichen. Hier können sich ggf. direkte Auswirkungen auf die Serverperformance und ggf. Engpasse zeigen.

Auditing auf Domänencontrollern

Standardmäßig ist auf Domänencontrollern das Auditing (für Active Directory als auch für das NTFS Filesystem der DCs) über die Default Domain Controllers GPO schon eingeschaltet, d.h. die Einstellungen müssen ggf. lediglich nach den eigenen Bedürfnissen angepasst werden.

Man findet die Audit-Settings in der „Default Domain Controllers” Policy unter „Computer Configuration“ --> „Windows Settings” --> “Security Settings” --> “Local Policies” --> “Audit Policies” (siehe 2).

Da die „Default Domain Controllers“ Policy standardmäßig auf allen DCs einer Domäne greift, sind allenfalls Anpassungen notwendig und keine erstmalige Aktivierung.

Ohne weitere Bearbeitung werden in fast allen Kategorien alle „Success“ Events geloggt. Es kann bei entsprechenden Anforderungen Sinn machen, auch fehlgeschlagene Events zu loggen. Hierdurch kann sich jedoch die anfallende Datenmenge stark erhöhen.

In den meisten Umgebungen werden die beiden Settings „Audit privilage use“ und „Audit process tracking“ nicht benötigt, daher werden diese nur bei Bedarf eingeschaltet.

Eine Beschreibung der Security Event Kategorien findet man unter (3), Absatz „Audit Log Management“, „Table 4.8 Audit Management Settings“ .

Zu Beachten ist beim Auditing der Objekte auf Domänencontrollern, daß ein Event immer nur auf dem DC geloggt wird, auf dem eine Aktion ausgelöst wurde. Meldet sich beispielsweise ein Benutzer an DC „A“ an, wird das Logon Event nur auf DC „A“ geloggt, nicht auf anderen DCs. Gleiches gilt für das Account Management oder ähnliches.

Es ist zu empfehlen beim Logging auf Domänencontrollern ebenfalls zu prüfen, welche Events überhaupt geloggt werden sollen und welche nicht. Es macht nur sehr selten Sinn, alle Eventkategorien zu loggen bzw. alle Eventkategorien auf „Success“ und „Failure“ zu setzen. Als Best Practice hat sich erwiesen, daß ein zusätzliche zu den Standardeinstellungen aktiviertes Logging bei folgenden Kategorien mit dem Ergebnis „Failure“ Sinn machen kann:

  • Audit account logon events
  • Audit account management
  • Audit object access
  • Audit policy change

Wie oben angemerkt muß diese Evaluierung jedoch nach den eigenen Ansprüchen durchgeführt werden und ggf. Anpassung erfahren.

Ein Hinweis noch zu den Inhalten der Meldungen: Bis Windows Server 2003 werden bei Eventlogs / Security Logs nicht die veränderten Werte geloggt. D.h. für die Praxis, daß zwar nachvollzogen werden kann wer, wann, auf welchem Objekt eine Änderung durchgeführt hat. Es kann bis Windows Server 2003 jedoch nicht so einfach geloggt werden, was genau verändert wurde. So wird etwa bei einer Änderung eines Benutzerobjekt (z.B. dem Profilpfad) nicht geloggt, daß sich der Profilpfad geändert hat. Dieses Verhalten läßt sich ab Windows Server 2008 granularer festlegen. Es ist damit möglich, sich auch die geänderten Attributwerte anzeigen zu lassen.

Auditing auf Fileservern

Um das Auditing auf Filesystemebene einzuschalten, müssen folgende Einstellungen vorgenommen werden (siehe 4):

  1. Es muß in einem Group Policy Objekt, welches oberhalb des zu überwachenden Systems verlinkt ist, die Audit Policy Kategorie „Audit object access“ definiert werden. Standardmäßig ist das nur in der „Default Domain Controllers“ GPO der Fall.

    Möchte man dieses Setting auch für Fileserver außerhalb dieser Domain Controller OU definieren, kann hierfür eine neue oder bestehende GPO definiert werden.

    Diese GPO verlinkt man bestenfalls auf eine OU mit den zu überwachenden Fileservern.

    Da es um das gleiche Setting handelt wie oben schon für die DCs erwähnt, finden Sie die Einstellung ebenfalls in der entsprechenden GPO unter „Computer Configuration“ --> „Windows Settings” --> “Security Settings” --> “Local Policies” --> “Audit Policies” -->“Audit object access“ (siehe 2).

    Ein „gpupdate /force“ auf dem Fileserver überträgt die Policy zeitnah auf den Fileserver.

  2. Der zu überwachende Ordner muß definiert werden. Dazu navigiert man im NTFS Filesystem zum gewünschten Ordner, wählt die „Properties“ --> Reiter „Security“ --> “Advanced“ --> Reiter „Auditing“. Hier werden über „Add“ zu überwachenden Benutzer oder Gruppen angegeben. Sollen die Zugriffe aller Benutzer protokolliert werden, wählt man hier beispielsweise „Everyone“.

  3. Im nächsten Schritt wird festgelegt, ob das Auditing für Ordner und Unterordner, Dateien etc. gelten soll. Weiterhin kann hier festgelegt werden, welche Aktionen tatsächlich ins Security Eventlog geschrieben werden sollen. So kann etwa nur das Löschen von Dateien oder Ordnern geloggt werden oder aber alle Aktionen. Auch hier kann zwischen erfolgreichen und fehlgeschlagenen Zugriffsversuchen unterschieden werden.

Werden nicht nur ausgewählte Aktionen geloggt, sondern etwa „Full control“, fallen sehr viele Daten schon beim Browsen durch die Ordner an. Allein das Öffnen eines Ordners kann zu mehr als 6 Events führen. Es gilt hier zu beachten, daß schon in kleineren Umgebungen sehr viele Daten anfallen können, wenn das Auditing auf Dateisystem Ebene aktiviert wurde.

Meine Empfehlung ist daher

  • nur die Ordner zu überwachen, deren Daten tatsächlich einem Monitoring unterliegen sollen.

    Nicht jede Datei / nicht jeder Ordner ist gleichermaßen „wichtig“ in Bezug auf die Überwachung. Oftmals können einige Ordner aus der Überwachung entfernt werden oder auch nur einige wenige Ordner zur Überwachung festgelegt werden. Die letztere Variante ist in Bezug auf die anfallenden Daten und die damit entstehenden Fragestellungen (Speicherplatz, Systembelastung etc.) die präferierte Variante.

  • die zu überwachenden Dateiaktionen einzugrenzen.

    Das bedeutet in der Praxis beispielsweise nur das Löschen einer Ressource zu überwachen, nicht das Lesen von Datei- oder Ordnerattributen. Hier muß vor dem Einführen des Auditings genau definiert werden, welche Aktionen ggf. auf welchem Ordner / auf welcher Datei geloggt werden sollen. Dies kann sich anforderungsspezifisch von Ordner / Freigabe zu Ordner / Freigabe unterscheiden.

In beiden Fällen kann ein Leitspruch sein: „So viel wie nötig, so wenig wie möglich.“ Nur durch granulares festlegen und dokumentieren der Audit-Settings kann eine übersichtliche Auswertung möglich sein.

Wichtig ist hierbei noch einmal zu verdeutlichen, daß das Group Policy Setting lediglich das Security Eventlogging aktiviert. Welche Ordner oder Dateien letztendlich überwacht werden, ist damit noch nicht festgelegt. Dies geschieht wie gerade beschrieben auf den Ordnern oder Dateien selbst in den „Auditing“ Security Settings des Ordners oder der Datei.

Kurzer Hinweis zum „Einsammeln“ einzelner Events:

Gerade bei der Suche nach den Gründen für Account Lockouts ist es immer wieder wichtig, die Account Lockout Events aller DCs einzusammeln, da (wie oben schon erwähnt) die Events nur auf dem DC geloggt werden, auf dem das Objekt gesperrt wurde.

Das Abrufen von Events von verschiedenen Servern z.B. über die Kommandozeile oder die MMC kann sehr aufwändig sein, sollte keine zentrale Monitoringlösung eingesetzt werden. Eine recht einfache „quick & dirty“ Lösung können die folgenden Zeilen sein, die man z.B. über eine Batch-Datei hintereinander ausführt. Es wird das Vorhandensein des Verzeichnisses „C:\TEMP“ geprüft und es ggf. angelegt, danach werden die DCs der Domäne ausgelesen, die sich standardmäßig unterhalb der OU „Domain Controllers“ befinden. Zuletzt liest man dann mittels „PsLogList“ (siehe 1) die entsprechenden Events aus. PsLogList muß dazu in einem, Pfad des %PATH% eingetragen sein oder als vollqualifizierter Pfad zum Programm in der Befehlszeile angegeben werden:

IF EXIST C:\TEMP GOTO weiter
MKDIR C:\TEMP

:weiter
dsquery computer „OU=Domain Controllers,DC=domain,DC=de“ > C:\TEMP\DC_LIST.TXT

FOR /F “tokens=2 delims==,” %%i in (C:\TEMP\DC_LIST.TXT) do psloglist.exe \\%%~i -I 529,644,675,676,681 security >> C:\TEMP\DC_LOCKOUT_EVENTS.TXT

Werden die Befehle direkt über die Kommandozeile ausgeführt, muß anstatt "%%i% nur "%i" (ohne Anführungszeichen) angegeben werden.

So sieht man recht schnell, auf welchem DC Lockouts stattfanden und hat z.B. im Gegensatz zum Additional Account Info Tool nicht nur einen Account im Blick, sondern alle gesperrten Accounts auf allen DCs.

Hierbei ist zu beachten, daß diese Abfrage je nach Netzwerkanbindung, Anzahl der vorhandenen DCs und DC Auslastung sehr lange dauern kann. Auch kann die Systemlast auf den DCs für den Abfragezeitraum steigen bzw. die Netzwerkauslastung generell. Auch hier gilt wie immer: Vor dem Produktiveinsatz testen!

Viele Grüße, Fabian.

Links:

(1) PsLogList: https://www.microsoft.com/germany/technet/sysinternals/utilities/PsLogList.mspx

(2) Auditing: https://www.microsoft.com/technet/prodtechnol/windows2000serv/reskit/deploy/dgbe_sec_cspz.mspx

(3) Microsoft Windows 2000 Security Hardening Guide: https://www.microsoft.com/technet/security/prodtech/Windows2000/win2khg/05sconfg.mspx

(4) How to enable and apply security auditing in Windows 2000: https://support.microsoft.com/kb/300549/en-US

(5) Microsoft Windows Server 2003 Performance Advisor: https://www.microsoft.com/downloads/details.aspx?FamilyID=09115420-8c9d-46b9-a9a5-9bffcd237da2&DisplayLang=en

(6) Best Practice Guide for Securing Active Directory Installations and Day-to-Day Operations: Part I: https://technet.microsoft.com/de-de/library/Bb727065.aspx

(7) Checklist: Setting up object access auditing: https://technet2.microsoft.com/windowsserver/en/library/e035f443-9c94-48d1-8dda-3bd243ca5f1d1033.mspx

(8) Auditing Security Events Concepts: https://technet2.microsoft.com/windowsserver/en/library/4de972ea-50f9-492a-aacf-c0b7d0b8e0961033.mspx

(9) Auditing Security Events How To: https://technet2.microsoft.com/windowsserver/en/library/1940e00e-93eb-445d-90c7-285e0391eebb1033.mspx

(10) Auditing Security Events Best practices: https://technet2.microsoft.com/windowsserver/en/library/5658fae8-985f-48cc-b1bf-bd47dc2109161033.mspx

Weitere Links:

Description of security events in Windows Vista and in Windows Server 2008 https://support.microsoft.com/kb/947226/en-us

https://support.microsoft.com/kb/921469/en-us 921469 How to use Group Policy to configure detailed security auditing settings for Windows Vista client computers in a Windows Server 2003 domain or in a Windows 2000 domain

https://support.microsoft.com/default.aspx?scid=kb;EN-US;921468 921468 Security auditing settings are not applied to Windows Vista client computers when you deploy a domain-based policy

https://www.microsoft.com/technet/solutionaccelerators/cits/dsd/wsrvdep/wsrvdc05.mspx https://www.microsoft.com/technet/security/guidance/auditingandmonitoring/securitymonitoring/smpgch03.mspx https://www.microsoft.com/technet/security/guidance/auditingandmonitoring/securitymonitoring/smpgch04.mspx https://technet2.microsoft.com/WindowsServer/en/library/5658fae8-985f-48cc-b1bf-bd47dc2109161033.mspx?mfr=true

https://technet.microsoft.com/en-us/library/bb727065.aspx