Zaufanie przez sprawdzanie

System Windows 2000 zapisuje do dziennika bezpieczeństwa wiele zdarzeń z identyfikatorem ID 540, jednak z punktu widzenia bezpieczeństwa większość z nich nie ma znaczenia.

Aby odróżnić te zdarzenia od tych naprawdę ważnych, należy zwrócić uwagę na pole User Name. Zdarzenia zawierające wartość SYSTEM można zignorować, oznaczają one bowiem, że jakaś usługa systemowa została podłączona do innej usługi. Można pominąć również zdarzenia, których wartość pola User Name zawiera nazwę komputera zakończoną znakiem "$". Oznacza to jedynie tyle, że usługa działająca na zdalnym komputerze została podłączona do komputera, którego zdarzenie dotyczy. Dla przykładu, wpis UZYTKOWNIK$ powstanie w logu serwera wtedy, gdy komputer o nazwie UZYTKOWNIK zarejestruje się w domenie.

Najbardziej interesujące z punktu bezpieczeństwa wpisy w polu User Name zawierają samą nazwę użytkownika - to one powinny być poddawane szczegółowej analizie. Rekordy zdarzeń ID 528 i 540 zawierają także nazwę domeny - Domain Name, do której przynależy konto logującego się użytkownika. Jeśli użytkownik wykorzystuje do logowania sieciowego lokalne konto, w polu Domain zostanie wpisana NetBIOS-owa nazwa komputera pracującego zdalnie. Lokalne konta administratorów na poszczególnych stacjach roboczych są najczęstszymi obiektami ataku, dlatego szczególną uwagę należy zwracać na zdarzenia o ID 528 i 540, w których w polu Domain występuje nazwa lokalnego komputera.

Zdarzenie o identyfikatorze ID 540 pozwala na stwierdzenie, jakiego rodzaju protokół był wykorzystywany do uwierzytelnienia użytkownika. Kiedy użytkownik podłącza się ze zdalnego komputera z systemem z Windows 2000 do lokalnego komputera z tym samym systemem, negocjowany jest protokół, za pomocą którego zostanie przeprowadzone uwierzytelnienie. Wchodzą w grę trzy protokoły: NTLAN Manager, NTLM oraz Kerberos. Ten ostatni protokół jest uważany za najbezpieczniejszy i w domenach zarządzanych przez Active Directory jest on preferowany.

Uwierzytelnienie za pomocą protokołu Kerberos 5.0 jest możliwe głównie pomiędzy komputerami z systemem Windows 2000 (systemy należące do tego samego tzw. lasu Active Directory lub domeny). Obsługę tego protokołu można jednak zainstalować także na komputerach z innymi systemami. Jeżeli komputer z systemem Windows 2000 nie należy do domeny bądź jest to system Windows NT 4.0, system Windows 2000 zmienia protokół uwierzytelnienia na starszy i słabszy NTLM, który może być podsłuchany i względnie łatwo złamany przez potencjalnego włamywacza. Jednym z pilniejszych działań jest więc wykonanie analizy logów pod kątem wykorzystywanych protokołów logowania. Jeżeli wszystkie stacje w domenie działają pod kontrolą Windows 2000, zdarzenia ID 540 można wykorzystać do sprawdzenia, czy rzeczywiście wszystkie stacje wykorzystują Kerberosa.

Rozważając problem logowania, nie można zapomnieć o wylogowaniu. Zdarzenia oznaczone jako ID 528 i ID 538 są ze sobą ściśle powiązane za pomocą identyfikatora Logon ID. Dla przykładu, jeśli chcemy się dowiedzieć, kiedy wylogował się użytkownik Kowalski, którego Logon ID przy logowaniu był następujący 0x0,0xD4AF, należy kliknąć prawym klawiszem myszy na dzienniku bezpieczeństwa i wybrać opcję View/Find w celu poszukiwania tej konkretnej wartości Logon ID. Każdemu zdarzeniu o ID 528 powinno odpowiadać jedno zdarzenie o ID 538. Powinno, ponieważ system czasem "zaniedbuje" tworzenie tego wpisu. Błąd ten występował już w Windows NT 4.0 i Windows 2000 i nie został usunięty.

Zdarzenia zakończone błędem

Zdarzenie o ID 540 - logowanie zdalne (Logon Type = 3), w tym przypadku z użyciem protokołu Kerberos

Zdarzenie o ID 540 - logowanie zdalne (Logon Type = 3), w tym przypadku z użyciem protokołu Kerberos

Obsługa błędnego logowania jest w Windows 2000 dokładnie taka sama jak w przypadku systemu Windows NT 4.0. Gdy użytkownik próbuje się zalogować, podając błędny identyfikator bądź hasło, Windows 2000 generuje zdarzenie o identyfikatorze ID 529. Próba logowania przez użytkownika, którego konto jest zablokowane bądź wyłączone, powoduje powstawanie zdarzeń oznaczanych jako ID 531 i ID 539.

Dla użytkowników, co do których obowiązują ograniczenia czasu logowania, podczas próby logowania poza dozwolonym okresem generowane jest zdarzenie z identyfikatorem ID 530. W przypadku wygaśnięcia czasu ważności konta lub ważności hasła generowane są zdarzenia ID 532 albo ID 535, zaś w przypadku próby obejścia ograniczeń co do stacji roboczych, z których dany użytkownik może się logować, system tworzy w dzienniku bezpieczeństwa zdarzenie ID 533.

Gdy użytkownik, któremu odebrano prawo do zdalnego logowania do komputera próbuje mimo to zalogować się zdalnie, system Windows 2000 zapisuje to jako zdarzenie ID 534. To samo zdarzenie jest również zapisywane w momencie lokalnego logowania danego użytkownika, jeśli nie ma on do tego uprawnień. Zdarzenie ID 534 jest również generowane podczas próby uruchomienia usługi, z konta nie posiadającego prawa do logowania jako usługa. Jeśli logowanie zostanie przeprowadzone niepoprawnie z jakiegoś innego powodu, tworzone jest zdarzenie ID 537 z następującym wyjaśnieniem, że podczas logowania wystąpiły nieoczekiwane błędy.

Zabezpieczanie dzienników

Dla pewności, że zdarzenia zapisywane w dziennikach są bezpieczne i w przyszłości będzie można z nich skorzystać, dzienniki należy zabezpieczyć.

Podstawową czynnością do wykonania w tym zakresie jest zdefiniowanie polis składowania, nadpisywania i log. Założenia systemowe powinny zawierać wszystkie wymagane ustawienia i być wymuszane przez politykę Group Policy.

Oprócz tego założenia systemowe powinny wskazywać, jakie czynności mają być podejmowane przez system w przypadku zapełnienia dziennika zdarzeń, a zwłaszcza dziennika bezpieczeństwa. Zalecanym ustawieniem jest zamknięcie systemu w przypadku zapełnienia tego dziennika. W niektórych środowiskach może okazać się niemożliwe, niemniej, możliwość taka powinna być rozważona.

Zapisywanie zdarzeń powinno być skonfigurowane w taki sposób, aby rejestracji podlegały także czynności związane z zarządzaniem plikami log, np. ich czyszczeniem. Ważną rzeczą jest także, aby dostęp do dzienników zdarzeń z grup application, system i security zabezpieczyć przed użytkownikami wykorzystującymi konto gościa.

Maciej Piekulski jest inżynierem w firmie Securing


TOP 200