Paweł Goleń, blog

Rozmiar dzienników

W standardowej konfiguracji wielkość dzienników zdarzeń jest niewielka. Szczerze mówiąc nawet nie wiem ile to dokładnie jest domyślnie, bo zawsze te parametry zwiększam. Trzeba jednak pamiętać, by z wielkościami dzienników nie przesadzić, co wynika z architektury tego mechanizmu. Jedną z pojawiających się często granicznych wartości jest 300MiB. Można przyjąć podział typu:

• Security - 196 MiB,
• System - 32 MiB,
• Application - 32 MiB,

Wielkościami tymi można manipulować, zwłaszcza jeśli w logach System i Application zapisywane są interesujące wpisy.

Co jednak ze starszymi wpisami? Na szczęście istnieje parametr AutoBackupLogFiles (patrz: Eventlog Key), który powoduje, że system może dokonać rotacji dziennika zdarzeń, dzięki czemu do analizy dostępna będzie historia zdarzeń z czasu dłuższego, niż tylko ten, na jaki wystarczy aktualnie aktywny dziennik.

Śledzone zdarzenia

Drugą istotną kwestią jest to, jakie zdarzenia związane z bezpieczeństwem (i zapisywane w dzienniku Security) są śledzone. Znów - w konfiguracji domyślnej ilość śledzonych zdarzeń jest dalece niewystarczająca. Na stacjach roboczych zwykle ustawiam następujące ustawienia śledzenia zdarzeń:

• Audit account logon events: Success, Failure
• Audit account management: Success, Failure
• Audit directory service access: No auditing
• Audit logon events: Success, Failure
• Audit object access: Success, Failure
• Audit policy change: Success, Failure
• Audit privilege use: Failure
• Audit process tracking: Success, Failure
• Audit system events: Success, Failure

Co można wyczytać z logów Security (i nie tylko)

Dzięki tego typu konfiguracji, zdarzenia odnotowane w dzienniku pozwalają na dość dokładne odtworzenie aktywności użytkownika komputera. Tu przedstawię przykłady kilku zdarzeń.

Włączenie/wyłączenie komputera

Zdarzenia 512 i 513 odpowiadają odpowiednio włączeniu i wyłączeniu systemu. Trzeba jednak zwrócić uwagę, że zdarzenia te nie są do końca "godne zaufania". Na moim laptopie nie ma na przykład odnotowanego ani jednego zdarzenia 512, są natomiast zdarzenia 513. W przypadku braku zdarzenia 512 można posłużyć się zdarzeniami 514, 515 i 518, które zwykle są logowane w trakcie startu systemu (pełnego!).

Poza wskazaniami z dziennika Security, pomocne mogą być również zdarzenia odnotowane w dzienniku System, a dotyczące samego mechanizmu śledzenia zdarzeń. W szczególności zdarzenia o identyfikator 6005 i 6009 dla startu maszyny oraz 6006 dla operacji jej zamknięcia.

Większy problem jest z hibernacją i wstrzymaniem systemu - brak jest zdarzeń, które w prosty sposób można powiązać z rozpoczęciem tego stanu. W zasadzie jedynym wskaźnikiem tego, że system został uśpiony/zahibernowany jest brak rejestrowanych zdarzeń. Chwilę wyjścia z tego stanu można w przybliżeniu ustalić poprzez określenie chwili, gdy zdarzenia zaczynają być ponownie rejestrowane.

Jeśli system wymaga odblokowania konsoli po wyjściu ze stanu wstrzymania/hibernacji, w chwili odblokowania konsoli pojawią się w logach zdarzenia 528 i 538 z LogonType 7. Warto zwrócić uwagę, że zdarzenia te mają praktycznie taki sam TimeGenerated.

Przy okazji: przy analizie logów duże znaczenie może mieć... statystyka. Na przykład określenie okresów czasu, gdy system (użytkownik) był bardziej, lub mniej aktywny. Do tego może posłużyć oczywiście mój ulubiony LogParser. Przykładowo zapytanie typu (wcześniej przerzuciłem zawartość dziennika do pliku CSV): SELECT QUANTIZE(TimeGenerated, 3600) AS Slot, Count(*) FROM Data.csv GROUP BY Slot ORDER BY Slot DESC zwróci coś w stylu:

2009-02-08 14:00:00 102
2009-02-08 13:00:00 53 
2009-02-08 12:00:00 63 
2009-02-08 11:00:00 69 
2009-02-08 10:00:00 69 
2009-02-07 23:00:00 113 
2009-02-07 22:00:00 123 
2009-02-07 21:00:00 114 
2009-02-07 20:00:00 168 
2009-02-07 19:00:00 294

Na tego podstawie można na przykład zauważyć, że między godziną 23 i 10 w systemie nie pojawiły się żadne zdarzenia. Zwiększając rozdzielczość można z większą dokładnością ustalić okres przestoju:

2009-02-08 10:20:00 52 
2009-02-07 23:30:00 16

Oczywiście takie statystyki można zawęzić też do konkretnego typu zdarzeń, na przykład do rozpoczęcia/zakończenia procesów (zdarzenia 592 i 593).

Logowanie/wylogowanie użytkownika

W przypadku śledzenia zdarzeń związanych z logowaniem/wylogowaniem użytkownika można zwrócić uwagę na zdarzenia 528, 538, 540 oraz 551.

Zdarzenie 528 świadczy o logowaniu użytkownika. Istotny jest typ logowania (Logon Type):

• 2 - Interactive
• 3 - Network
• 4 - Batch
• 5 - Service
• 7 - Unlock
• 8 - NetworkCleartext
• 9 - NewCredentials
• 10 - RemoteInteractive
• 11 - CachedInteractive

Bardziej precyzyjne wyjaśnienie co oznaczają poszczególne typy logowania dostępne jest na przykład tu: Logon Type Codes Revealed.

W przypadku analizy stacji roboczej głównie istotne będą zdarzenia związane z typami 2, 7 oraz 11 (jeśli stacja jest podłączona do domeny). Przynajmniej jeśli chodzi o ustalenie działań, jakie wykonał ktoś, kto siedział bezpośrednio przy konsoli.

Warto zwrócić uwagę również na wartość Logon ID odnotowaną w zdarzeniu 528. Po prostu można się zalogować do systemu więcej niż raz, ta wartość pozwala wiązać zdarzenia logowania i wylogowania oraz na przykład uruchamiania procesów (zdarzenie 592 dotyczące uruchomienia procesu zawiera informację o Logon ID, w kontekście którego zostało zarejestrowane).

Zdarzenia 538 oraz 551 są zdarzeniami związanymi z wylogowaniem użytkownika. Która konkretnie sesja została zakończona, można zidentyfikować na podstawie parametru Logon ID. Wystąpienie zdarzenia 551 świadczy o tym, że użytkownik wylogował się lub wyłączył komputer. Zdarzenie 538 można często obserwować, jeśli ktoś korzysta z RunAs. Wówczas zakończenie (zamknięcie) aplikacji uruchomionej przy jego pomocy generuje właśnie zdarzenie 538. Oczywiście zdarzenie 538, tym razem z Logon Type 7, jest generowane również przy odblokowaniu stacji roboczej.

Blokowanie/odblokowanie konsoli

W Windows XP/2003 nie ma zdarzenia odnotowującego fakt zablokowania konsoli. Godzinę takiego zdarzenia można co najwyżej estymować wyszukując godzinę uruchomienia wygaszacza ekranu. Zdarzenie to jest odnotowane jako uruchomienie procesu (zdarzenie 592). Ponieważ zwyczajowo wygaszacz ekranu ma rozszerzenie *.scr, znalezienie zdarzeń tego typu można wykonać choćby przy pomocy zapytania (znów LogParser): SELECT * FROM Data.csv WHERE EventID = 592 AND TO_LOWERCASE(EXTRACT_TOKEN(Strings,1,'|')) LIKE '%.scr'. W analogiczny sposób można również wyszukać zdarzenia zakończenia się wygaszacza ekranu, przy czym wówczas badane będą zdarzenia 593.

Fakt odblokowania konsoli jest odnotowywany przez zdarzenia 528 i 538 z Logon Type 7. Data generowania tych zdarzeń odpowiada chwili odblokowania konsoli.

Uruchamiane programy

Uruchamianie programów to przede wszystkim zdarzenie 592 (uruchomienie) oraz 593 (zamknięcie). W niektórych przypadkach może być pomocne również zdarzenie o identyfikatorze 600. Na przykład w trakcie logowania użytkownika generowane jest zdarzenie 592 typu:

Event Type: Success Audit 
Event Source: Security 
Event Category: Detailed Tracking 
Event ID: 592 
Date: 2009-02-07 
Time: 11:32:19 
User: NT AUTHORITY\SYSTEM 
Computer: KOMPUTER 
Description: A new process has been created: 
New Process ID: 2508 
Image File Name: C:\WINDOWS\system32\userinit.exe 
Creator Process ID: 924 
User Name: KOMPUTER$ 
Domain: Domena 
Logon ID: (0x0,0x3E7)

Proces ten dopiero za chwilę otrzymuje główny token, o czym świadczy kolejne zdarzenie 600:

Event Type: Success 
Audit Event Source: Security 
Event Category: Detailed Tracking 
Event ID: 600 
Date: 2009-02-07 
Time: 11:32:19 
User: NT AUTHORITY\SYSTEM 
Computer: KOMPUTER 
Description: A process was assigned a primary token. Assigning Process Information: 
Process ID: 924 
Image File Name: C:\WINDOWS\system32\winlogon.exe 
User Name: KOMPUTER$ 
Domain: Domena Logon ID: (0x0,0x3E7) 
New Process Information: 
Process ID: 2508 
Image File Name: C:\WINDOWS\system32\userinit.exe 
User Name: user 
Domain: Domena Logon ID: (0x0,0x286A71)

Na podstawie zdarzeń 592 i 593 można odtworzyć drzewo procesów w systemie w danej chwili. Nie jest to zadanie wyjątkowo trudne, choć wymaga cierpliwości, lub narzędzia, które zadanie to wykona.

Informacje zawarte w zdarzeniach 592/593 pozwalają na określenie kto, w jakiej sesji uruchomił jaki program i ile czasu ten program był aktywny. Nie ma natomiast żadnych informacji choćby o parametrach wywołania procesu. Nie ma również żadnych informacji ile użytkownik pracował z/w danym programie. Próby ustalenia czasu pracy użytkownika (pracownika) przy pomocy określenia ile czasu aktywny był Word a ile Internet Explorer są po prostu naiwne.