Zbieranie i analizowanie logów od zawsze stanowiło problem w organizacjach. Tysiące serwerów, stacji roboczych i innych urządzeń, a każde z nich generujące dziennie setki tysięcy wpisów w dzienniku zdarzeń. W rozległych organizacjach często pojawiają się, takie problemy jak:
- brak scentralizowanego logowania zdarzeń,
- brak monitorowania endpoint’ów (często tylko kontrolery domeny),
- zapełnianie dzienników niepotrzebnymi danymi,
- brak rejestracji kluczowych pod kątem bezpieczeństwa zdarzeń,
- pliki dzienników nadpisują się zbyt szybko i nie są archiwizowane,
- wygenerowanie raportu/analiza logów zajmuje zbyt wiele czasu.
Zarządzanie i monitorowanie infrastruktury Windows jest niemałym wyzwaniem i często kończy się zakupem niewydajnych systemów, aby tylko spełnić wymagania stawiane przez audyt. Prowadzi to do sytuacji, że dzienniki zdarzeń na systemach Windows są zupełnie nieprzydatne, i tym samym niewykorzystywane do detekcji i zapobiegania incydentom bezpieczeństwa.
Wcale tak być nie musi. Rozwiązanie jest bardzo proste, a co więcej darmowe i wbudowane w systemy Windows. Jeśli o nim nie słyszałeś, to nie masz się co przejmować, ponieważ z pewnością nie jesteś jedyny. Informacji i popularyzacji tego mechanizmu jest zdecydowanie za mało. Niniejszym postanawiamy to zmienić!
Wprowadzenie do Windows Event Forwarding (WEF)
Mechanizm Windows Event Forwarding, czyli inaczej Przesyłanie Zdarzeń w systemach Windows opiera się na zasadzie, tzw. subskrypcji. Wbudowana usługa (o nazwie windows event collection) pozwala na skonfigurowanie jednego lub więcej serwerów, aby działały jako kolektory logów. Kolektory, zwane także menadżerami subskrypcji, pozwalają zdefiniować, które dzienniki zdarzeń mają być zbierane z serwerów źródłowych, zwanych subskrybentami lub forwarder’ami. Zebrane dzienniki odkładane są na kolektorach w plikach *.evt lub *.evtx i możliwe jest lokalne ich przeglądanie lub przesyłanie dalej do analizy. Zdarzenia przesyłane są natywnie poprzez usługę Windows Remote Management (WinRM). Na kolektorze rejestrowany jest listener http lub https, który nasłuchuje na zdefiniowanych portach i odbiera logi od forwarder’ów. Dzięki temu, nie trzeba martwić się o instalowanie jakiegokolwiek oprogramowania na końcówkach. Mechanizm działa na wszystkich systemach Windows począwszy od Windows Server 2008 oraz Windows 7.
Poza oczywistą korzyścią wynikającą z braku konieczności instalowania dodatkowego oprogramowania, WEF przynosi następujące korzyści:
- przesyłane zdarzenia są domyślnie szyfrowane za pomocą Kerberos,
- subskrypcje są proste w konfiguracji, mogą być zaimplementowane za pomocą pojedynczego pliku XML lub z pomocą wizarda,
- nowe hosty są automatycznie dodawane do subskrypcji za pomocą członkostwa w grupie w Active Directory,
- mechanizm może korzystać z metody przesyłania PUSH lub PULL,
- interwał pobierania zdarzeń jest konfigurowalny,
- możliwe jest filtrowanie zdarzeń u źródła.
Przygotowanie środowiska pod przesyłanie zdarzeń
Istnieje wiele instrukcji jak poprawnie skonfigurować mechanizm przesyłania zdarzeń, na przykład dokumentacja Microsoft, tak więc nie będziemy tutaj zbytnio się rozwodzić.
Podstawowe komponenty i ustawienia, które należy wdrożyć to:
- Na przynajmniej jednym serwerze, wybranym na kolektor, uruchomić usługę „Windows Event Collection”. Można to zrobić używając linii komend i polecenia: wecutil quick-config.
- Uruchomić usługę WinRM na wszystkich komputerach będących forwarder’ami. Można to wdrożyć poprzez ustawienie wystartowania serwisu w GPO.
- 3Ustawić poprzez GPO adres do którego hosty źródłowe będą subskrybować logi. Przedstawiono to poniżej. Parametr „Refresh” pozwala na podanie interwału w sekundach, według którego forwarder’y będą sprawdzać ustawienia subskrypcji i aktualizować ewentualne zmiany.
- Utworzyć grupę w Active Directory i dodać do niej konta wszystkich komputerów, które mają subskrybować logi do kolektora.
- Dodać lokalne konto „Network Service” na komputerach źródłowych do lokalnej grupy „Event Log Readers”. Tutaj też najłatwiej wprowadzić to ustawienie poprzez GPO. W przypadku subskrybowania logu Security, należy dodatkowo ustawić ACL dla grupy „Event Log Readers” z uprawnieniami „read”. Domyślnie nie jest to ustawione w żadnej polityce. Więcej informacji pod tym linkiem.
- Przemyśleć, które kategorie logów i konkretnie jakie zdarzenia chcemy zbierać.
Te kilka powyższych kroków brzmi prosto i intuicyjnie, ale niestety mało wprawiony administrator będzie miał z tym trochę problemów. Łatwo się tutaj pomylić oraz wymagana jest wiedza z zasad grupy, list ACL, dzienników zdarzeń oraz Active Directory. W razie problemów, pierwszym miejscem, gdzie powinno się zajrzeć jest log operacyjny znajdujący się pod ścieżką: Microsoft-Windows-Eventlog-ForwardingPlugin/Operational.
Tworzenie subskrypcji
Gdy wszystkie powyższe kroki zostały przeprowadzone to czas na stworzenie pierwszej subskrypcji zdarzeń na kolektorze.
Na serwerze, który został namaszczony do roli kolektora, wchodzimy w dziennik zdarzeń. Z lewej strony wybieramy katalog „Subskrypcje”, klikamy i wybieramy „Utwórz subskrypcje”.
- Nazwa subskrypcji,
- Opis subskrypcji,
- Dziennik docelowy (gdzie mają być zapisywane zdarzenia),
- Typ subskrypcji (określenie czy ma być to mechanizm typu PULL czy PUSH, dla dużych środowisk powyżej 100 hostów polecamy PUSH, czyli „Zainicjowane przez komputer źródłowy”),
- Grupę komputerów (wskazujemy tutaj naszą nową utworzoną grupę z AD),
- Zdarzenia do zbierania (po kliknięciu ukaże się nowe okno z wyborem filtrów),
- Zaawansowane (kilka parametrów związanych z połączeniem oraz kontem do czytania logów).
Wybór logów, które mają być dostarczane do kolektora polega na zdefiniowaniu filtru, identycznego jak w przypadku filtrowania zdarzeń w dziennikach lokalnych w celu wyświetlania tylko interesujących wpisów.
Wybieramy więc filtr i klikamy OK.
Pod przyciskiem „Zaawansowane” kryje się ustawienie czasu dostarczenia zdarzeń. Z poziomu kreatora subskrypcji mamy do wyboru trzy profile: Normalny, Minimalizuj przepustowość, Minimalizuj czas oczekiwania. Oznaczają one mniej więcej tyle, że w normalnym na zdarzenia będziemy czekać maksymalnie 15 minut, w oszczędzającym nasze łącze – 6 godzin, a w szybkim 1 minutę. Opcję te można bardziej dostroić do własnych potrzeb w pliku konfiguracyjnym usługi WinRM.
Podsumowanie
Właściwe administrowanie usługą Windows Event Forwarding wymaga sporych umiejętności. Początkowa konfiguracja i doprowadzenie wszystkich subskrypcji do stabilnego stanu może być problematyczne w rozbudowanych środowiskach Windows. Wymaga to instalacji i konfiguracji kilku kolektorów oraz odpowiednie filtrowanie eventów u źródła. Zalety WEF z pewnością przekonają wiele osób do tego, że drogi system zbierający logi niekoniecznie jest potrzebny. Microsoft dostarczył wystarczająco solidne i porządne rozwiązanie, więc jeśli masz domenę Windows zastanów się nad przetestowaniem i wdrożeniem tego mechanizmu.