Zaufanie przez sprawdzanie

Jeżeli ustawienia zostały zdefiniowane jedynie na stacjach, jako ustawienia efektywne traktowane będą ich ustawienia lokale. Jeżeli zdefiniowane zostaną ustawienia będące wyżej w hierarchii, ustawienia te będą mieć pierwszeństwo przed ustawieniami lokalnymi stacji, co w praktyce oznacza nadpisanie ustawień lokalnych. W przypadku domeny do konfiguracji należy wykorzystać narzędzia Active Directory Users and Computers udostępniane przez Microsoft Management Console (MMC). Za ich pomocą można konfigurować następujące parametry inspekcji logów:

  • Account logon events - uwierzytelnienie (walidacja kont) dla lokalnego komputera poprzez sieć. Funkcja działa tylko w przypadku kont aktywnych.

  • Account management - tworzenie, modyfikowanie oraz kasowanie użytkowników i grup, zmiana haseł.

  • Directory service access - dostęp do Active Directory. Opcja ta musi być włączona, aby móc stosować inspekcję konkretnych obiektów katalogu.

  • Logon events - interaktywne zdarzenia logowania bądź sieciowe połączenia do lokalnej maszyny. Zdarzenia te są generowane w momencie logowania.

  • Object access - ta opcja musi zostać włączona, aby możliwe było wykonywanie audytu bezpieczeństwa dla poszczególnych obiektów.

  • Policy change - zmiany w politykach bezpieczeństwa, w tym privilege assignments, audit policy modifications i trust modifications.

  • Privilege use - wykorzystuje przywileje, nadawanie konkretnych uprawnień.

  • Process tracking - szczegółowe śledzenie procesów, duplikowanie uchwytów (handles) procesów i zamykanie procesów.

  • System events - zdarzenia podobne do zdarzeń bezpieczeństwa, takie jak zamknięcie systemu, restart i inne zdarzenia zmieniające security log.

Gdy nie ma na czym pisać

Zaufanie przez sprawdzanie

Konfiguracja analizy na stacji roboczej

Oprócz konfigurowania analiz ważne jest odpowiednie skonfigurowanie dzienników, do których są zapisywane wszystkie zachodzące w systemie zdarzenia. Czynności można wykonać za pomocą systemowych narzędzi do definiowania polityk grupowych - Group Policy. Przechowywanie dzienników zdarzeń wymaga zarezerwowania dla każdego z nich konkretnej przestrzeni dyskowej. Standardowo każdy z nich ma wielkość 512 KB, co w większości przypadków jest wielkością zdecydowanie za małą. Narzędzia Group Policy pozwalają określić maksymalną wielkość pliku dziennika oraz co ma się stać, gdy plik log osiągnie swoją maksymalną objętość. Oto ważniejsze opcje działania dzienników w takich przypadkach:

  • Overwrite events as needed - usuwa stare zdarzenie z logu w chwili, gdy dopisywane jest nowe. Takie ustawienie pozwala utrzymywać log w jego maksymalnej skonfigurowanej wielkości - wybranie tej opcji wymaga znajomości tempa przyrostu logów w systemie.

  • Overwrite events older than x days - kasuje zdarzenia z logu, które są starsze niż "x" dni. Jeśli log zapełni się, zanim najstarsze zdarzenia przekroczą skonfigurowany czas ważności, przestaną być dopisywane nowe zdarzenia. To ustawienie jest pożądane w momencie, gdy chce się archiwizować logi co "x" dni, ale niedobre w przypadku, jeśli takiej archiwizacji się nie wykonuje, ponieważ niektóre zdarzenia przepadną.

  • Don't overwrite events - przestaje zapisywać zdarzenia do dzienników w chwili zapełnienia się konkretnego dziennika. W tym przypadku zawartość dziennika trzeba wyczyścić ręcznie.

  • Shut down system immediately if unable to log security audits - wykorzystanie tej opcji można rozważyć w środowiskach wymagających wysokiego poziomu bezpieczeństwa, w których logowanie zdarzeń jest wymogiem bezwzględnym zgodnie z zasadą: lepiej zatrzymać udostępniany serwis, niż go udostępniać bez logowania.
Uwaga: Jeżeli po wybraniu tej opcji dojdzie do całkowitego zapełnienia dziennika logów, serwer zaserwuje nam niebieski ekran z odpowiednim komunikatem i zostanie wyłączony. W takim przypadku ważne jest, aby zaraz po ponownym uruchomieniu serwera zalogować się jako lokalny administrator, zarchiwizować dzienniki, wyczyścić je, po czym ponownie włączyć omówioną opcję, która w powyższych warunkach (po zapełnieniu logu i nieoczekiwanym zamknięciu systemu) jest wyłączana automatycznie.

Zdarzenia zakończone sukcesem

Zaufanie przez sprawdzanie

Zdarzenie o ID 528 sygnalizuje poprawne logowanie lokalne (Logon Type = 2)

Na potrzeby inspekcji logów system Windows 2000 rozróżnia kilka typów logowania, które w polu Logon Type logu zdarzenia są reprezentowane przez odpowiednie wartości.

Oto one: (2) logowanie interaktywne - bezpośrednio do konsoli, (3) logowanie sieciowe - logowanie do domeny, mapowanie dysków, (4) logowanie typu batch zarezerwowane dla procesów wsadowych, (5) logowanie usług systemowych, (7) logowanie "puste" do nie zabezpieczonej stacji roboczej, (8) logowanie z użyciem prostego hasła typu cleartext oraz (9) tzw. impersonated logons.

W systemie Windows NT zdarzenie o identyfikatorze ID 528 opisuje poprawnie wykonane logowanie bez względu na jego typ. W systemie Windows 2000 zostało to zmienione i np. przy mapowaniu dysku serwera, łączeniu się z jego rejestrami bądź jakimkolwiek innym logowaniu sieciowym, oprócz zdarzenia ID 528, jest generowane także zdarzenie ID 540. Dzięki temu podczas analizy logów z wielu systemów jednocześnie można łatwo odróżnić logowania lokalne od logowań dokonanych poprzez sieć.


TOP 200