Niedawno opisywałem w jaki sposób można poradzić sobie z kontrolą i blokowaniem oprogramowania na komputerach użytkowników za pomocą Software Restriction Policies. Na tym przykładzie pokazywałem w jaki sposób „bezpiecznie” podejść do tematu blokowania oprogramowania, pozostawiając domyślne dopuszczanie wszystkiego, a blokowanie tylko konkretnych, wskazanych w regułach aplikacji. Opisywałem tam także krótko wady i zalety takiego podejścia. W tym wpisie pokażę w jaki sposób zabrać się do kontroli w dokładnie odwrotny sposób – blokując domyślnie wszystko oraz tworząc tzw. whitelistę dopuszczalnego oprogramowania. Do realizacji właśnie takiego podejścia przystosowany został znajdujący się w GPO AppLocker – następca Software Restriction Policies, który przy okazji swojej publikacji zlikwidował znane błędy pozwalające na ominięcie ustawionych reguł.
Samo podejście domyślnego blokowania wszystkiego jest dużo lepsze z punktu widzenia bezpieczeństwa oraz dużo bardziej uniwersalne. Nie musimy tutaj na bieżąco kontrolować nowych aplikacji pojawiających się na komputerach użytkowników i tworzyć odpowiednie reguły (co w przypadku ochrony przed uruchomienia malware’u będzie zupełnie nieefektywnym podejściem). To użytkownik chcąc skorzystać z innego oprogramowania niż do dotychczas dozwolone, musi zgłosić taki fakt do rozpatrzenia, aby można było przygotować odpowiednią regułę, które mu na to pozwoli. Samej pracy przy monitorowaniu aktualnego stanu software’u na maszynach użytkowników w teorii też jest istotnie mniej.
Application Identity – podstawa działania AppLocker’a
AppLocker działa w oparciu o usługę systemową Application Identity. Naturalnie gdy usługa nie jest więc włączona, żadne reguły czy ustawienia AppLockera nie będą działać. Stan usługi możemy podejrzeć uruchamiając services.msc (Win+R -> services.msc). Jeżeli nie zostało to skonfigurowane inaczej, usługa domyślnie będzie wyłączona, a jej włączenie, zgodnie z domyślną konfiguracją, będzie musiało być wykonane ręcznie przez administratora:
Automatyczny start usługi Application Identity możemy skonfigurować na różne sposoby. W przypadku GPO konfigurowanego na poziomie domeny, w System Services mamy możliwość konfiguracji wspomnianej usługi:
Po dwukrotnym kliknięciu na Application Identity zaznaczamy Define this policy setting a następnie wybieramy opcję Automatic
Application Identity – lokalne GPO
W przypadku lokalnego GPO zakładka System Services nie będzie dla nas dostępna:
W tej sytuacji automatyczny start usługi zdefiniować możemy w rejestrze. Przechodzimy więc do rejestru np. poprzez uruchomienie regedit:
Następnie, zgodnie z oznaczeniami na poniższym zrzucie ekranu, odnajdujemy Services:
Następnie odnajdujemy AppIDSvc, a w nim opcję Start:
Po dwukrotnym kliknięci na Start zmieniamy jego wartość na „2”:
Jak widać w Services.msc status Application Identity został zmieniony na Automatic:
Oznacza to, że usługa będzie od teraz uruchamiana wraz ze startem systemu.
Konfiguracja AppLocker’a
Teraz możemy przejść do właściwej konfiguracji AppLockera. W tym celu odnajdujemy go w GPO (zarówno w GPO na poziomie domeny jak i w lokalnym GPO znajduje się on w dokładnie tym samym miejscu):
Mamy tutaj możliwość skonfigurowania 4 rodzajów reguł:
- Executable Rules – odpowiadają za blokowanie plików wykonywalnych z rozszerzeniem .exe oraz .com
- Windows Installer Rules – odpowiadają za blokowanie instalatorów z rozszerzeniem .msi. .msp oraz .mst
- Script Rules – odpowiadaj za blokowanie wszelkiego rodzaju skryptów, np. .ps1 (PowerShell) czy .cmd
- Packaged app Rules – odpowiadają za blokowanie wybranych z listy paczek aplikacji
W zakładce Advanced możemy dodatkowo znaleźć piąty typ blokowanych reguł – DLL Rules pozwalających na blokowanie różnego rodzaju bibliotek. Opcja ta jednak, z tego co mi wiadomo, jest bardzo rzadko konfigurowana w środowiskach produkcyjnych.
Oczywiście zależnie od swoich potrzeb, każdy będzie konfigurował różne typy reguł, jak również różne reguły. W moim przypadku chodzi głównie o kontrolę oprogramowania, więc skoncentruję się na Executable Rules. Przechodzę, więc do odpowiedniej zakładki, klikam PPM, a następnie w Create New Rule.. :
W pierwszym kroku określam typ reguły – czy będzie ona zezwalała na wykorzystanie wskazanej aplikacji, czy tego zabraniała. W tym miejscu wybierana jest również grupa docelowa – zwykle pozostawiam tutaj domyślnie wybraną grupę Everyone – jak sama nazwa wskazuje, działa ona dla wszystkich (wliczając w to administratorów!). Sam proces określania dla kogo mają być aplikowane te reguły, oprócz omawianego miejsca, można przeprowadzić na poziomie aplikowania GPO dla konkretnych OU lub grup. Można także w późniejszym kroku dodać odpowiednie wyjątki np. dla Administratorów:
W kolejnym kroku określamy typ wybranej reguły. Do wyboru mamy tutaj 3 opcje, od których zależeć będą dalsze kroki kreatora:
Publisher pozwoli nam na blokowanie oprogramowania na podstawie min. jego twórcy. Opcja ta sczytuje podstawowe dane o oprogramowaniu z właściwości pliku. W zależności od potrzeb pozwala również na zawężanie/rozszerzanie zakresu jaki ma objąć reguła na 4 poziomy:
- Publisher – wybranie tego poziomu spowoduje blokadę całego oprogramowanie pochodzącego od danego wydawcy/twórcy
- Product Name – wybranie tego poziomu spowoduje blokadę całego oprogramowania wchodzącego w skład wybranego produktu
- File Name – pozwala na blokowanie konkretnego oprogramowania, niezależnie od jego wersji
- File Version – pozwala na blokowanie konkretnej wersji wybranego oprogramowania
Wartości pól wypełniane są automatycznie na podstawie wskazanego przez nas pliku lub mogą zostać wypełnione ręcznie po wybraniu opcji Use custom values:
Path pozwoli na utworzenie reguł blokowania oprogramowania na podstawie jego ścieżki. Przy wyborze konkretnego pliku lub folderu fragmenty jego ścieżki będą w miarę możliwości domyślnie zamieniane na zmienne środowiskowe, co pozwoli na większą elastyczność stosowanych reguł. Na poniższym przykładzie fragment ścieżki – C:\Windows został zamieniony na zmienną środowiskową %WINDIR% odnoszącą się do lokalizacji tego folderu w aktualnym środowisku. Dzięki temu, nawet gdyby system zainstalowany był na dysku oznaczonym inną literą, reguła zadziała poprawnie.
Ostatnią z typów reguł jest File Hash. Reguła tego typu blokuje wybrane oprogramowanie na podstawie hasha danego pliku – nawet jeżeli nastąpi zmiana pliku, która w przypadku chociażby Path Rule mogłaby spowodować ominięcie danej reguły, hash pliku pozostanie bez zmian i File Hash Rule zadziała poprawnie. Warto mieć tutaj na uwadze, że niekiedy inna wersja danego oprogramowania może zmienić hash, przez co dana reguła może przestać działać!
W przypadku Publisher oraz Path mamy jeszcze możliwość wskazania wyjątków, dla których tworzona reguła nie będzie działała:
Po utworzeniu reguły otrzymujemy komunikat o utworzeniu domyślnych reguł. Póki co, na potrzeby prezentacji pominę tą opcję, choć normalnie stanowczo zalecam utworzyć je zgodnie z sugestią:
Obecna konfiguracja zawiera więc tylko jedną regułę i wygląda następująco:
Brak reguł domyślnych przy jednocześnie uruchomionej usłudze Application Identity spowoduje w tym przypadku zablokowanie wszystkich plików wykonywalnych, łącznie z tymi systemowymi. Od tej pory, przy obecnej konfiguracji, nie będziemy w stanie odpalić żadnej aplikacji niezależnie od posiadanych przez dane konto uprawnień – mało tego, jeżeli zamkniemy wszystkie obecnie otwarte okna nie będziemy w stanie ich ponownie otworzyć i zmienić obecną konfigurację! Zablokowany zostanie również podstawowy proces explorer.exe odpowiadający za wyświetlanie pulpitu użytkownika, przez co nie zostanie on uruchomiony po zatrzymaniu (np. po restarcie komputera zalogowany użytkownik nie zobaczy już swojego pulpitu):
Jak widać pominięcie domyślnych reguł bądź nieuważna konfiguracja AppLocker’a może prowadzić do poważnych konsekwencji w kwestii używalności komputera. Aby to naprawić klikamy PPM na Executable Rules, a następnie na Create Default Rules
W ten sposób utworzone zostają 3 domyślne reguły:
- Możliwość uruchamiania programów zlokalizowanych w folderze Program Files dla wszystkich użytkowników
- Możliwość uruchamiania programów zlokalizowanych w folderze Windows, czyli wszystkich aplikacji systemowych
- Możliwość uruchamiania wszystkich plików dla wbudowanych kont z uprawnieniami administratora
W obecnej sytuacji mamy 4 reguły. Mamy tutaj do czynienia z sytuacją, gdzie reguły nakładają się na siebie. Z jednej strony plik notepad.exe znajduje się w folderze C:\Windows, więc działa na niego 2 w kolejności reguła domyślna, która ze zwala na jego uruchomienie. Z drugiej strony jest utworzona przez nas na początku reguła, również wskazująca na plik notepad.exe, która takiego uruchomienia zabrania. Naturalnie w takim przypadku Deny ma wyższy priorytet niż Allow, więc uruchomienie pliku nie będzie możliwe. Natomiast dzięki ustawionym domyślnym regułom pozostałe aplikacje będą możliwe do uruchomienia:
Jeżeli sytuacja byłaby odwrotna – blokujemy domyślnie np. cały katalog, ale chcemy zezwolić na uruchamianie jednego konkretnego pliku ? Deny dalej będzie miało wyższy priorytet niż Allow, więc do tego właśnie celu stworzona została możliwość dodawania wyjątków. Przykładowo blokuję więc testowy folder:
W kolejnym kroku dodaję jeden z plików znajdujący się w tym katalogu jako wyjątek w zakładce Exceptions np. jako Path Rule ze ścieżką do tego pliku:
W ten sposób przeprowadziliśmy bazową konfigurację AppLockera. Tworzenie kolejnych reguł jest już kwestią indywidualną, zależną od oprogramowania wykorzystywanego w danym środowisku. Do poprawnego działania AppLockera niezbędne jest więc sporządzenie dokładnej listy dozwolonych aplikacji i dodanie ich jako odpowiednie reguły.
Weryfikowanie skonfigurowanych reguł AppLockera – Audit Mode
Ostatnią kwestią, którą chciałbym omówić to możliwość wdrażania AppLockera w trybie Audit Mode. Ten tryb pozwala nam na przetestowanie w jaki sposób skonfigurowane reguły zadziałają na produkcyjnym środowisku (na którym działają inne ustawienia skonfigurowane w GPO). Co prawda zawsze mówi się, żeby nigdy nie testować na środowisku produkcyjnym, ale Audit Mode pozwala na przetestowanie ustawień w sposób całkowicie bezpieczny, bez wpływu na środowisko czy stacje końcowe. Mimo wszystko optymalnym rozwiązaniem wydaje się być przetestowanie ustawień na środowisku testowym i potraktowanie tego trybu jako dodatkowy etap testów przed ostatecznym wdrożeniem. Tryb działania AppLockera możemy ustawić po opcją Configure rule enforcement znajdującą się w „głównej zakładce” AppLockera:
We właściwościach, dla każdego typu reguł możemy wybrać 2 tryby:
- Enforce rules – który najzwyczajniej w świecie powoduje zastosowanie danych ustawionych reguł
- Audit only – który nie zmienia nic z punktu widzenia użytkownika, ale generuje eventy widoczne dla Administratora, dzięki którym można sprawdzić jak dane reguły zachowają się w praktyce.
Wybieramy, więc tryb audytu i ponownie ustawiamy regułę blokującą możliwość uruchamiania notepad.exe. Z punktu widzenia użytkownika zupełnie nic się nie zmienia, jest on w stanie uruchomić plik:
W Event Viewer znajdujemy logi dla stosowanych ustawień:
Jak widać, mimo że użytkownik nie odczuł zmian, w logach zdarzenia, które w tym przypadku normalnie zostały by zablokowane przez AppLocker’a widnieją jako Warning:
Jak widać taki event zawiera również dokładny opis zachowania AppLocker’a w przypadku przełączenia go w normalny tryb. Jak widać jest to idealne rozwiązanie do testowania zachowania utworzonych reguł w środowisku przy okazji minimalizują ryzyko jakiegokolwiek wpływu „na biznes”.
Coś jest dla Ciebie niezrozumiałe? Chciałbyś wyrazić opinię na temat artykułu? Znalazłeś jakiś błąd? Koniecznie daj mi o tym znać wysyłając maila lub wypełniając formularz!
