Utwardzanie serwera NetCrunch
Jak wdrożyć NetCrunch tak, aby sam serwer był małym celem — co serwer powinien, a czego nie powinien robić, na jakim koncie działa oraz dlaczego monitorowanie powinno odbywać się na sondzie, a nie na serwerze.
NetCrunch Security Features opisuje, co chroni dane przechowywane przez NetCrunch. Ten temat dotyczy wdrożenia wokół niego: jak uruchomić serwer tak, aby od samego początku było mniej elementów, do których można uzyskać dostęp.
Uzasadnienie jest zawsze takie samo. Serwer monitorowania przechowuje dane uwierzytelniające dotyczące znacznej części infrastruktury i może uzyskiwać dostęp do maszyn, do których nic innego nie ma dostępu. Wszystko, co działa na tej maszynie, dziedziczy tę pozycję.
Poniższe informacje to wskazówki, a nie mechanizmy wymuszające. NetCrunch obecnie niczego z tego nie blokuje — nic w tym dokumencie nie uniemożliwia monitorowania z server probe ani uruchamiania script sensor na tym serwerze. Są to wybory, które sprawiają, że instalację można uzasadnić pod względem bezpieczeństwa, a ich zastosowanie należy do Ciebie.
Jedno zadanie dla serwera
Uruchamiaj na serwerze NetCrunch i nic więcej. Żadnych innych usług, żadnych innych aplikacji ani zastosowań ogólnego przeznaczenia.
Nie chodzi tu o zasoby. Serwer monitorowania to maszyna, która już posiada dane uwierzytelniające do Twojej infrastruktury; każdy dodatkowy proces na tej maszynie to kolejny sposób uzyskania dostępu do tych danych.
Monitorowanie z sondy, a nie z serwera
Zalecamy zainstalowanie Monitoring Probe na osobnej maszynie i monitorowanie z jej poziomu środowiska. Zobacz Monitorowanie rozproszone.
Server probe powinien monitorować samego NetCrunch i nic więcej.
To rozdzielenie sprawia, że powyższe zalecenia są możliwe do zastosowania. Monitorowanie łączy się z urządzeniami, analizuje zwracane przez nie dane, a w niektórych konfiguracjach uruchamia kod, aby to zrobić. Wykonywanie tych czynności z poziomu sondy pozwala przenieść tę pracę — oraz wszystko, co może pójść nie tak — poza maszynę przechowującą bazę danych uwierzytelniających.
service-account
Konto usługi
NetCrunch nie może działać jako Local Service. Nie jest to preferencja dotycząca utwardzania zabezpieczeń — produkt nie działa w ten sposób.
Istnieją dwa powody, z których każdy jest wystarczający sam w sobie:
- Konto Local Service nie ma tożsamości sieciowej, więc nie może uwierzytelniać się na innych maszynach z systemem Windows. Monitorowanie systemu Windows i monitorowanie Active Directory przestają działać.
- NetCrunch przechowuje konfigurację w
HKEY_LOCAL_MACHINE, a to konto nie może w niej zapisywać.
Jeśli powodem, dla którego chcesz używać Local Service, jest ograniczenie dostępu procesu monitorowania, obsługiwanym sposobem osiągnięcia tego celu jest sonda: uruchom probe na osobnej maszynie z uprawnieniami rzeczywiście wymaganymi przez monitorowanie, a serwer pozostaw poza tym procesem.
Ograniczenie wymagań dotyczących konta serwera jest aktywnie rozwijanym obszarem, dlatego oczekuje się, że sytuacja poprawi się w przyszłej wersji. Obecnie można to osiągnąć za pomocą sondy.
Konto, na którym działa NetCrunch, określa również dostęp do folderu danych. Jeśli usługa nie działa jako LocalSystem, temu kontu przyznawany jest dostęp do drzewa danych obok kont SYSTEM i lokalnej grupy Administrators. Zobacz NetCrunch Security Features.
startup-script
Skrypt uruchamiany podczas startu
NetCrunch uruchamia skrypt startowy podczas uruchamiania serwera, przed rozpoczęciem monitorowania — jest to przydatne do przygotowania wszystkiego, od czego zależy monitorowanie, na przykład mapowania dysków sieciowych.
SettingsNetCrunch SystemServerStartup Script
Skryptu nie można wybrać z konsoli. Jest to jeden, stały plik, który należy samodzielnie umieścić na maszynie serwera:
StartupScript.cmd- W katalogu installation NetCrunch — nie w katalogu danych. Nazwa jest dokładna i nie ma mechanizmu wyszukiwania: jeden plik, jedna odpowiedź na pytanie, dlaczego skrypt został lub nie został uruchomiony. Jeśli pliku nie ma w tym miejscu, uruchamianie jest po prostu kontynuowane.
Jest to działanie zamierzone i właśnie tę właściwość zabezpieczeń należy zrozumieć. Określenie, co zostanie uruchomione podczas startu serwera, wymaga teraz dostępu do zapisu w katalogu instalacyjnym, co już oznacza posiadanie lokalnych uprawnień administratora na tej maszynie. Nie może tego ustawić zdalny użytkownik.
Zostało to zmienione w tej wersji. We wcześniejszych wydaniach skrypt można było wybrać zdalnie, co oznaczało, że klient administracyjny mógł wybrać, co uruchomi serwer. Obecnie jedyną informacją przesyłaną przez sieć jest czas oczekiwania.
Czas oczekiwania
Jedyne ustawienie określa, jak długo NetCrunch czeka na zakończenie skryptu, zanim będzie kontynuować uruchamianie — maksymalnie 300 sekund, domyślnie 30.
Ustaw wartość 0, aby uruchomić skrypt i natychmiast kontynuować bez oczekiwania. Jeśli po upływie czasu oczekiwania skrypt nadal działa, NetCrunch wznawia uruchamianie i pozostawia skrypt działający.
Dane wyjściowe są zapisywane w pliku StartupScript.log — ale nie obok skryptu. Dziennik jest zapisywany w folderze Logs katalogu danych NetCrunch, który w przypadku domyślnej instalacji znajduje się w C:\ProgramData\AdRem\NetCrunch\.
Skrypt i jego dziennik znajdują się w dwóch różnych miejscach: skrypt w katalogu installation, a dziennik w katalogu data. Ten podział wynika z tej samej zasady co cała reszta — katalog instalacyjny jest uprzywilejowanym katalogiem, do którego zapisu wymaga się uprawnień administratora, a NetCrunch nie zapisuje w nim dzienników.
code-execution
Kod uruchamiany na serwerze
Niektóre funkcje monitorowania uruchamiają kod zamiast tylko odczytywać wartości — na przykład script sensors oraz działania alertów uruchamiające program. Na server probe taki kod działa na serwerze NetCrunch, z uprawnieniami serwera.
W przypadku utwardzonej instalacji:
- Nie uruchamiaj script sensors względem server probe
- Nie konfiguruj na serwerze actions that execute programs
Żadne z tych ograniczeń nie wynika z ograniczeń funkcji — obie funkcje są przydatne i obie powinny być używane na sondzie znajdującej się na innej maszynie, gdzie ten sam skrypt wykonuje to samo zadanie, ale nie działa obok bazy danych uwierzytelniających.