Kontrola oprogramowania – Software Restriction Policies

Być może dla bardziej doświadczonych administratorów czy bezpieczników kwestia kontroli oprogramowania poprzez GPO może wydawać się trywialna, natomiast ja od dłuższego już czasu zastanawiałem się w jaki sposób ograniczyć możliwość instalacji i wykorzystywania niedozwolonego oprogramowania użytkownikom. Co prawda bez konta czy uprawnień lokalnego administratora istnieje szereg innych zabezpieczeń uniemożliwiających użytkownikom instalację oprogramowania w standardowych katalogach (C:\Program Files oraz C:\Program Files (x86)) (chociażby UAC), lecz w wielu przypadkach takie ograniczenie nie jest wystarczające. Wiele różnego typu software’u instaluje się domyślnie w katalogu użytkownika, najczęściej w folderze „AppData”. Jednym z rozwiązań w takim przypadku jest odpowiednie skonfigurowanie „Software Restriction Policies” w GPO (choć warto tutaj nadmienić, że lepszym rozwiązaniem będzie wykorzystanie AppLocker’a, o którym pisałem tutaj).

Wstępna konfiguracja

„Software Restriction Policies” naturalnie możemy ustawić zarówno dla komputerów jak i użytkowników. W przypadku komputerów ustawienia te znajdziemy w następującym miejscu:

natomiast w przypadku użytkowników tutaj:

Sam proces konfiguracji reguł jest identyczny, więc przedstawię go tylko na przykładzie użytkowników. Aby zdefiniować domyślne ustawienia i móc przejść do ich modyfikacji początkowo klikamy PPM oraz wybieramy opcję „New Software Restriction Policies”:

W tym momencie zdefiniowany zostały pierwsze bazowe reguły. Teraz po przejściu do katalogu widzimy kilka różnych ustawień. Modyfikacje rozpocząć można od „Enforcement”. Ustawienia trzeba tutaj zdefiniować adekwatnie do swoich potrzeb. Jeżeli dokładnie wiemy jakie reguły chcemy zdefiniować możemy przestawić pierwsze ustawienie z domyślnego na „All software list”, nie potrzebujemy żadnych wyjątków, wszystko zostanie jasno określone. Poza tym zgodnie ze swoimi potrzebami zmieniam jeszcze ustawienia dotyczące użytkowników, na które mają być aplikowane reguły na „All users except local administrators” – w moim przypadku użytkownicy mają do dyspozycji jedynie zwykłe konta domenowe. Konta lokalnych administratorów pozostają pewnego rodzaju furtką dla działu IT, aby móc zainstalować dany software na komputerze.

Określenie rozszerzeń blokowanego oprogramowania

Następnym miejscem przy którym należy się zatrzymać jest „Designated File Types”. Tutaj mamy możliwość określenia rozszerzeń oprogramowania, które ma być blokowane przez GPO (przy ustawieniu odpowiedniego poziomu zabezpieczeń). Same ustawienia są bardzo intuicyjne, początkowo mamy domyślnie zdefiniowaną listę najpopularniejszych rozszerzeń, którą możemy dowolnie modyfikować:

Jeżeli nie mamy jeszcze dokładnie określonej listy dopuszczalnego oprogramowania warto zwrócić uwagę na rozszerzenie .lnk. Przy ustawieniu domyślnego blokowania wszystkich programów z rozszerzeniami na liście (o czym niżej) brak skonfigurowania odpowiednich reguł może skutkować błędami menu Start czy przypiętych elementów.

Dwa różne podejścia do blokady oprogramowania

Kolejnym krokiem w konfiguracji będzie ustawienie odpowiedniego poziomu zabezpieczeń. Tutaj nie ma jednego dobrego rozwiązania – wszystko zależy od naszych potrzeb, choć naturalnie zalecane są bardziej restrykcyjne ustawienia. Ja wykorzystuję tutaj tak naprawdę tylko 2 opcje – Disallowed lub Unrestricted, stąd wyróżniam dwa podejścia podczas konfiguracji tych ustawień

• Opcja Disallowed powoduje zablokowanie wykorzystania całego oprogramowania, którego rozszerzenia zostały zdefiniowane w „Designated File Types”. Ma ona oczywiście swoje wady i zalety – wymaga zdecydowanie mniej pracy (szczególnie przy utrzymywaniu)i jest bardziej uniwersalna (blokuje każde oprogramowanie niebędące na liście dopuszczonego oprogramowania). Z drugiej jednak strony wymaga bardzo dobrze przygotowanej listy dopuszczonego oprogramowania (zarówno by nie blokować plików systemowych jak i nie popsuć niczego w oprogramowaniu uruchamianym przez „biznes”). Sprawa jest o tyle złożona, że oprogramowanie z reguły instalowane jest nie tylko w różnych miejscach na samym urządzeniu użytkownika końcowego, ale może znajdować się w różnego typu folderach sieciowych. Warto zwrócić na to uwagę.
• Opcja Unrestricted domyślnie nie zmienia niczego, tzn. pozwala na uruchamianie każdego programu (chyba, że jest ono oczywiście blokowane przez inne ustawienia). Wybranie tej opcji wymaga dokładnie odwrotnego podejścia niż w przypadku opcji Disallowed. Skoro domyślnie wszystko jest dopuszczone trzeba określić konkretne reguły, które oprogramowanie będzie blokowane. Opcja ta jest przez to mniej inwazyjna i mniej naraża nas na błędy, które mogą powstać w wyniku zaaplikowania ustawień Disallowed. Kontrolujemy listę i od początku do końca dokładnie wiemy, co i gdzie będzie blokowane, a co dopuszczone. Wiąże się z tym oczywiście sporo więcej pracy, szczególnie przy utrzymywaniu aktualności stworzonej listy

Mimo, że opcja Unrestricted może być zdecydowanie lepszą opcją dla niedoświadczonych osób, w praktyce to właśnie podejście domyślnego blokowania oprogramowania, czyli opcja Disallowed, będzie zalecanym podejściem. Na potrzeby tego artykułu, z racji przedstawienia podejścia analogicznego do opcji Dissallowed przy okazji artykułu o AppLocker, skoncentruję się tutaj na pokazaniu konfiguracji reguł przy wybranej opcji Unrestricted.

Definiowanie konkretnych reguł

Chyba najważniejszym miejscem spośród omawianych ustawień jest folder „Additional Rules”. W środku możemy definiować różnego typu reguły, które mają fundamentalne znaczenie dla działania wszystkich pozostałych ustawień. Początkowo w środku powinny znajdować się 2 domyślnie utworzone reguły zapobiegające zablokowaniu uruchamiania programów znajdujących się w katalogu Windows oraz Program Files – co istotne, katalog „Program Files (x86)” nie jest ujęty w tych regułach, więc w przypadku wybrania opcji Disallowed w poprzednim punkcie warto mieć to na uwadze. Poniżej przedstawię definiowanie reguł blokujących przykładowe oprogramowanie, czyli wariant dla wybranej wcześniej opcji Unrestrited, jednak dla opcji Disallowed sam sposób definiowania reguł niczym się nie różni – jedynie wybraniem innych ścieżek oraz opcji Unrestricted zamiast Disallowed przy każdej z reguł.

Po kliknięciu PPM na pustą przestrzeń mamy do wyboru 4 typy reguł możliwych do utworzenia:

• Certificate Rule – pozwala na wskazanie certyfikatu, którym można podpisać oprogramowanie, aby dodać je do wyjątków. Jeżeli np. domyślnie blokujemy całe oprogramowanie z rozszerzeniem .exe oraz utworzymy regułę, która dopuszcza uruchomienie oprogramowania poprzez wskazanie odpowiedniego certyfikatu, to użytkownik będzie mógł uruchomić tylko to oprogramowanie, które zawiera rozszerzenie .exe, które są podpisane wskazanym przez nas certyfikatem, pozostałe będą zablokowane
• Hash Rule – pozwala na utworzenie reguły na podstawie hasha danego pliku. Taki plik wystarczy wskazać, aby po chwili wyciągnięty z niego został jego hash. Przykładowo, jeżeli zdefiniujemy regułę blokującą uruchomienie aplikacji Notepad na podstawie jego hasha, użytkownik nie będzie mógł uruchomić tej aplikacji niezależnie od tego, w którym miejscu się ona znajduje.
• Network Zone Rule – dotyczą tylko Windows Installera. Pozwalają określić możliwość pobierania oraz instalowania oprogramowania na podstawie wcześniej zdefiniowanych stref sieciowych
• Path Rule – pozwala na określenie konkretnej ścieżki, w której nie będzie można uruchamiać danego oprogramowania. Przykładowo można tutaj ustawić brak możliwości uruchamiania oprogramowania z rozszerzeniem .exe w folderze Downloads danego użytkownika

Najczęściej wykorzystywanymi przeze mnie regułami są Hash Rule oraz Path Rule, dlatego też zostaną one szerzej omówione poniżej.

Hash Rule

Do utworzenia Hash Rule musimy posiadać konkretny program, który będziemy mogli wskazać w celu wyciągnięcia hasha. Przykładową regułę tworzę dla instalatora Notepada ++. Z racji ustawienia poziomu zabezpieczeń na Unrestricted wskazuję odpowiedni plik, z którego ma zostać wyciągnięty hash oraz pozostawiam opcję Disallowed:

Reguła została utworzona prawidłowo:

Sprawdźmy teraz jak reguła działa z punktu widzenia użytkownika. W tym celu początkowo na kontrolerze domeny (gdzie definiuję powyższą regułę – GPO na poziomie domeny) uruchamiam Command Line i wykonuję polecenie „gpupdate /force”, aby reguły zostały natychmiastowo zaaplikowane:

Po kilkunastu sekundach polityki zostały zaktualizowane. Teraz przechodzę na maszynę klienta i loguje się na konto zwykłego użytkownika domenowego (jeżeli maszyna była uruchomiona warto ja zrestartować). Teraz próbuję uruchomić instalator notepada na komputerze. Jak widać reguła zadziałała prawidłowo, system wykrył, że użytkownik uruchamia plik o określonym w regule hashu i uniemożliwił mu uruchomienie programu:

Małe case study:

• Hash danego programu przeważnie będzie różny np. dla różnych wersji danego oprogramowania. Ma to swoje plusy oraz minusy. Minusem niewątpliwie jest to, że jeżeli chcemy blokować dane oprogramowanie, musimy stworzyć oddzielne reguły dla każdej wersji tego oprogramowania oraz aktualizować listę wraz z wyjściem każdej nowej aktualizacji (wspominałem wcześniej, że przy takiej metodzie będzie sporo pracy także przy utrzymaniu aktualnej listy?).

Na powyższym przykładzie wyciągnięty został hash notepada ++ dla wersji 7.8.9. Gdy teraz spróbuję uruchomić wersję 7.8.4 pokaże się UAC (ze względu na specyfikę npp akurat i tak zwykły użytkownik nie będzie mógł uruchomić instalatora). Sam fakt pojawienia się UAC świadczy o tym, że inna wersja Notepada ++ ze względu na inny hash „przeszła” weryfikację i nie została zablokowana przez wcześniej zdefiniowaną regułę:

• Hash Rule teoretycznie można wykorzystać do wymuszania aktualizacji oprogramowania przez użytkowników. Zakładając, że nie w organizacji znajduje się raptem kilka sztuk jakiegoś niestandardowego oprogramowania, może ono nie być włączone do automatycznego procesu aktualizacji np. przez SCCM i wymagać kontrolowania aktualizacji przez użytkownika. W takim przypadku możemy niejako wymuszać utrzymywanie aktualnej wersji oprogramowania u użytkowników blokując starsze wersje (co wiąże się naturalnie z odpowiednią komunikacją i wyjaśnieniem jak działa ten proces i dlaczego „mam to zablokowane a działało”).

Path Rule

Utworzenie Path Rule ma nieco szersze zastosowanie niż Hash Rule. Część oprogramowania, szczególnie tego instalowanego w katalogu AppData danego użytkownika, instaluje się w jednym konkretnym miejscu bez możliwości zmiany lokalizacji podczas procesu instalacji. Przykładem takiego oprogramowania może być np. Zoom, którego instalacja kończy się na uruchomieniu instalatora, a sam program zawsze instaluje się na domyślnej ścieżce i nie ma możliwości, aby zmienić to w trakcie trwania instalacji. W takim przypadku bardzo łatwo jest wskazać ścieżkę do konkretnego programu, na którego uruchomienie nie chcemy zezwalać. Tak zdefiniowana reguła nie pozwoli oczywiście na uruchomienie programu, natomiast zezwoli na jego instalację, co jest tylko częściowym „zwycięstwem”.

Można oczywiście blokować za pomocą różnych reguł dane aplikacje oraz ich instalatory, ale warto też zastanowić się nad zablokowaniem możliwości uruchamiania oprogramowania w newralgicznych punktach. W moim przypadku nie znalazłem żadnej sytuacji, gdzie zachodziłaby konieczność uruchamiania plików z rozszerzeniem .exe w folderze Downloads. Stąd pomysł na w miarę uniwersalną walkę z instalatorami – blokowanie wszystkich plików .exe w tym folderze. Może nie jest to specjalnie zaawansowana metoda, ale dla szarych użytkowników wystarczająca dla dużego grona użytkowników – mało który zwykły użytkownik sprawdza, czy może odpalić instalator z innego katalogu, a przecież zazwyczaj są one przez nich pobierane i trafiają do folderu Downloads.

Path Rule możemy przygotowywać na różne sposoby. Warto pamiętać o przygotowaniu reguł w uniwersalny sposób, tak aby miały one swoje zastosowanie wobec zmiennych elementów ścieżki, np. nazwy użytkownika. Z tego względu warto zapamiętać dwa znaki, które możemy zastosować podczas wskazywania ścieżki:

• ’?’ – który reprezentuje dowolny jeden znak znajdujący się na tym miejscu. Inaczej, reguła będzie działała niezależnie od znaku, który znajdzie się w miejscu występowania ’?’ w ścieżce. Tj. reguła „C:\?bc.exe” będzie działała zarówno dla „C:\abc.exe” jak i „C:\zbc.exe”. Jeżeli jednak zmianie ulegnie którykolwiek inny znak reguła ta oczywiście nie zadziała (np. „C:\acc.exe”)
• ’*’ – który reprezentuje dowolny ciąg znaków znajdujący się w danym miejscu. Czyli przykładowa ścieżka utworzona na bazie '*’ może wyglądać następująco „C:\*.exe” i będzie ona miała swoje zastosowanie zarówno dla „C:\a.exe” jak i dla „C:\abcde.exe”. Liczba znaków nie ma tutaj większego znaczenia, istotne jest aby wystąpił dokładnie taki sam ciąg znaków przed oraz po '*’.

W ten sposób, dla wspomnianej wcześniej reguły blokującej wykonanie programów z rozszerzeniem .exe w folderze „Downloads” ścieżka będzie wyglądała następująco:

Pierwsza '*’ w ścieżce odnosi się oczywiście do zmiennej nazwy użytkownika, przez co niezależnie od niej reguła będzie działać. Druga '*’ odnosi się tutaj do dowolnej nazwy oprogramowania, tak by działała ona dla każdego programu z rozszerzeniem „.exe” niezależnie od nazwy takiego programu.

Inną metodą określania reguł w uniwersalny sposób jest wykorzystanie wbudowanych odnośników do charakterystycznych miejsc w systemie. Poniżej kilka najczęściej wykorzystywanych przeze mnie przykładów:

• %PROGRAMDATA% – odnoszący się do folderu Program Data na dysku C:
• %USERPROFILE% – odnoszący się do bazowego katalogu danego użytkownika
• %APPDATA% – odnoszący się do folderu Roaming, znajdującego się w AppData w katalogu użytkownika
• %PROGRAMFILES% – odnoszący się do folderu Program Files na dysku C:
• %WINDIR% – odnoszący się do głównego katalogu Windows

Ścieżka o dokładnie analogicznym działaniu jak w poprzednim przypadku może więc równie dobrze wyglądać następująco:

Sposobów zapewne jest jeszcze więcej – dla mnie te dwa są w zupełności wystarczające, aby pokryć wszystkie potrzeby jeżeli chodzi o reguły bazujące na ścieżkach plików. Po zaaplikowaniu reguł i wymuszeniu zaaplikowania ich przez Command Line przechodzę na stację klienta i próbuję uruchomić dowolny program .exe. W folderze znajdują się aktualnie dwa takie programy:

Przy okazji każdego z nich próba uruchomienia kończy się dokładnie tym samym skutkiem:

Case Study

1. Co w przypadku, gdy ustawienia pokrywają się – jedno z nich zezwala na wykorzystanie danego oprogramowania, a drugie nie?

Opcja Deny zawsze będzie „na wierzchu”, tzn. jeżeli coś jest jednocześnie dozwolone i zabronione, to będzie traktowane jako zabronione

2. Co w przypadku, gdy GPO ustawione na poziomie domeny zdefiniowane jest na Deny, a GPO ustawione na poziomie OU (Organizational Unit) odnosi się do tego samego „elementu” i zdefiniowane jest na Unrestricted?

Teoretycznie GPO jest hierarchiczne. Oznacza to, że najpierw sprawdzane są lokalne ustawienia GPO, następnie GPO na poziomie lasu, potem na poziomie domeny i na końcu na poziomie danego OU, gdzie każde następne powinno nadpisywać ustawienia na wyższym poziomie. W przypadku, gdy dowolne ustawienie skonfigurowane jest na poziomie domeny na Allow, a na poziomie OU na Deny do ustawienie zostanie nadpisane dla obiektów znajdujących się w danym OU, natomiast dla pozostałych zostanie ono oczywiście tak jak jest to określone na poziomie domeny. W odwrotnym przypadku, jeżeli na poziomie domeny mamy ustawione Deny, a na poziomie OU Unrestricted, w dalszym ciągu będzie to traktowane jako Deny. Przykładowa struktura może wyglądać następująco:

Przy okazji warto tu nadmienić, że dobrą praktyką jest nie ruszanie „Default Domain Policy”, a tworzenie nowych GPO i odpowiednie linkowanie ich w strukturze. Po zaaplikowaniu GPO przechodzimy na stację klienta i weryfikujemy jakie ustawienia spłynęły na klienta. Możemy to łatwo podejrzeć uruchamiając (Win+R) rsop.msc:

Podczas ładowania może wystąpić komunikat o błędzie przy odczytywaniu ustawień mających wpływ bezpośrednio na komputer. Wynika to zwyczajnie z braku uprawnień (konto użytkownika domenowego, brak uprawnień lokalnego administratora) i nie należy się tym przejmować. Interesują nas w tym przypadku ustawienia dla konkretnego użytkownika, które będziemy w stanie podejrzeć:

Po załadowaniu mamy możliwość podejrzeć ustawienia mające wpływ na użytkownika. Widzimy, że na użytkownika spłynęły zarówno ustawienia z GPO ustawionego na poziomie domeny zabraniające wykonania plików .exe w folderze Downloads jak i te ustawione na poziomie OU, które na to zezwalają:

Zgodnie z tym co zostało opisane powyżej, ustawienie Disallowed czy Deny jest zawsze ważniejsze, więc użytkownik nie będzie w stanie uruchomić programów w folderze Downloads:

3. Co w przypadku, gdy chciałbym zabronić danej aktywności tylko konkretnej grupie użytkowników?

Tutaj rozwiązań będzie bardzo dużo. Moją propozycją jest ustawienie GPO na użytkowników, a następnie podzielenie ich na 2 grupy (koniecznie grupy nie OU! Obiekt może w danym momencie znajdować się tylko w jednym OU, więc nie będzie to wygodne rozwiązanie dla stosowania wielu różnych zasad). W ten sposób tworzymy dwa GPO (np. na poziomie domeny) – jedno zabraniające, drugie zezwalające. Do każdego GPO przypisujemy odpowiednią grupę. W ten sposób bardzo wygodnie możemy zarządzać możliwością blokowania i odblokowywania danego oprogramowania dla konkretnego użytkownika przerzucając go pomiędzy grupami. W praktyce może to wyglądać następująco – dla konkretnego oprogramowania, np. Zoom tworzę 2 GPO:

Oraz dwie grupy, do których przypisuję odpowiednich użytkowników:

Następnie dla każdego GPO przypisuję odpowiednią grupę. Domyślnie GPO aplikowane jest na grupę Authenticated Users, więc de facto na wszystkie obiekty w domenie. Grupy tej nie należy w tym miejscu usuwać, gdyż aplikowane na użytkowników GPO nie będzie działało!

Przechodzimy do zakładki Delegation a następnie do ustawień zaawansowanych – Advanced:

Dla grupy Authenticated Users odznaczamy opcję Allow przy Apply Group Policy:

Następnie dodajemy odpowiednią grupę i zaznaczamy dla niej tą opcję:

Finalnie zakres działania GPO powinien wyglądać następująco:

Analogicznie postępujemy dla drugiego GPO oraz drugiej grupy. Finalnie wygląda to następująco:

Przy takim ustawieniu GPO (oraz oczywiście określeniu odpowiednich reguł blokujących wykorzystanie tego oprogramowania) każdy użytkownik znajdujący się w grupie ZoomDeny nie będzie mógł uruchomić tego oprogramowania. Aby zezwolić mu na jego wykorzystanie wystarczy przerzucić go do grupy ZoomAllow, gdzie odpowiednio zdefiniowane reguły nie będą blokowały wykorzystania oprogramowania.

Słowo końcowe

Po skonfigurowaniu odpowiedniego GPO oraz grup dla każdego oprogramowania, które chcielibyśmy blokować pozostaje nam jedynie dbać o aktualność listy (jeżeli używamy Hash Rule aktualizowanie listy o nowe wersje oprogramowania) oraz w prosty sposób zarządzać użytkownikami przenosząc ich pomiędzy grupami adekwatnie do posiadanych lub nabywanych przez nich uprawnień do wykorzystania danego oprogramowania.

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!