Akademia Windows 7 - Część 3: AppLocker

Autor: Łukasz Foks

Opublikowano: 20 marca 2009

Zawartość strony

	Dlaczego AppLocker a nie SRP?
	Patrząc w przeszłość – Software Restriction Policies
	AppLocker w praktyce
	Pierwsza konfiguracja
	Testujemy naszą konfigurację
	Blokowanie bez blokowania
	Automatyczne tworzenie zasad
	Podsumowanie
	Zasoby dodatkowe

 

Jednym z największych wyzwań działów IT w przedsiębiorstwach było od zawsze zabezpieczenie stacji klienckich przed możliwością uruchomienia nieautoryzowanych (a trafniej ujmując – niedozwolonych) aplikacji.

Dlaczego AppLocker a nie SRP?

Począwszy od Windows XP i Windows Server 2003 pojawiła się nowość – (SRP), czyli moduł umożliwiający administratorom na zezwalanie, które aplikacje może uruchomić użytkownik - poprzez Zasady Grupy (Group Policy).

Software Restriction Policies posiadały jedną wadę, która spowodowała, że to rozwiązanie nie było użytkowane w tak dużym stopniu, w jakim mogłoby funkcjonować – złożoność. Sama konfiguracja była skomplikowana, po drugie, konfiguracja musiała być okresowo weryfikowana i najczęściej zmieniana, jako, że każda aktualizacja programu powodowała „ciche” ominięcie restrykcji (w kontekście roli opartej na kryptograficznym odcisku, ang. Hash rule).

W Windows 7 i Windows Server 2008 wprowadzono AppLocker, czyli „ewolucję” Software Restriction Policies. AppLocker został stworzony, aby naprawić „niedogodności”, którymi charakteryzowały się Software Restriction Policies – celem była łatwość konfiguracji i łatwość działania, bez konieczności częstej rekonfiguracji.

Poniższy artykuł stanowi przegląd opcji oferowanych przez AppLocker oraz zawiera krótkie przypomnienie jakimi możliwościami charakteryzowały się Software Restriction Policies. W publikacji znalazły się nie tylko opisy nowych możliwości, ale wyjaśnienia zmian elementów wspólnych dla obu technologii.

Do początku strony

Patrząc w przeszłość – Software Restriction Policies

Software Restriction Policies zostały wprowadzone w Windows XP oraz w równoległej rodzinie systemów serwerowych Windows Server 2003. Celem wprowadzenia tej technologii było zapewnienie administratorom spójnego narzędzia do blokowania możliwości uruchomienia aplikacji, skryptów, plików instalacyjnych czy takich elementów, jak kontrolki ActiveX, co przekładało się na podwyższenie standardu bezpieczeństwa na stacjach końcowych, uniemożliwiając użytkownikom instalację nieznanego i niesprawdzonego oprogramowania.

Wprowadzanie restrykcji programowych mogło być wykonywane na podstawie czterech ról (celowo zachowano angielskie nazewnictwo):

• Hash rule – reguła bazująca na danych z kryptograficznego „odcisku palca” aplikacji. Zastosowanie restrykcji na bazie tej reguły, miało pewne zalety – rola obowiązywała niezależnie czy została zmieniona nazwa czy lokalizacja programu. Podstawowa wada – reguła obowiązywała tylko dla jednej wersji aplikacji.
• Certificate rule – reguła bazująca na certyfikacie, umożliwiała zdefiniowanie zasady, która zezwalała/blokowała uruchomienie tylko tej aplikacji, która była podpisana certyfikatem (własnym czy firm trzecich).
• Path rule – reguła opierająca się na lokalizacji. Zezwalała/blokowała dostęp tylko do tych aplikacji, które znajdowały się w konkretnym miejscu (folderze). Cenną funkcjonalnością tej reguły była możliwość odwołania się do systemowego rejestru.
• Internet Zone rule – reguła bazująca na strefie internetowej, z której została pobrana paczka Instalatora Windows (pliki .msi).

Pierwszym krokiem, który należało wykonać w celu definicji restrykcji było utworzenie nowej polityki, następnie konfiguracja konkretnych elementów składających się na Software Restriction Policies – Enforcement, Designated File Types czy Trusted Publisher.

Czy to jest wygodne? Software Restriction Policies jest rozwiązaniem przydatnym, aczkolwiek trudnym w konfiguracji, dlatego warto zainteresować się nowym AppLocker w Windows 7 i Windows Server 2008 R2.

Do początku strony

AppLocker w praktyce

Wraz z Windows 7 i Windows Server 2008 R2 zmieniono podejście do tworzenia i definicji ustawień restrykcji aplikacji – narzędzie musi być łatwe w obsłudze. Co ważne, AppLocker nie zastępuje Software Restriction Policies, jest ich „ewolucją”, jest dostępny w wybranych edycjach systemu Windows 7 – Enterprise oraz Ultimate.

Posiadacze niższych edycji (które wspierają Group Policy) mogą nadal korzystać z Software Restriction Policies.

AppLocker jest konfigurowany, podobnie jak SRP, poprzez Group Policy. Aby uruchomić interfejs konfiguracji AppLocker, należy uruchomić konsolę Local Group Policy Editor, w celu edycji polityk lokalnych. W sekcji Computer Configuration należy rozwinąć węzeł Windows Settings, następnie Application Control Policies, aż w końcu AppLocker.

Rysunek 1. Konsola Local Group Policy Editor - AppLocker.

Już na pierwszy rzut oka da sie zauważyć, iż interfejs AppLocker jest dużo bardziej przyjazny użytkownikowi, niż SRP. Główną stronę funkcjonalności podzielono na trzy części: Getting Started opisuje AppLocker i zawiera łącza do zasobów dodatkowych, druga – Overview – wyświetla podsumowanie dot. reguł, trzecia – opcje związane z egzekwowaniem danych kolekcji reguł oraz opcja włączenia kolekcji reguł DLL.

Restrykcje mogą być tworzone w obrębie czterech kolekcji reguł:

• Executable Rules – pozwala tworzyć reguły odnoszące się do aplikacji bądź ich zbiorów (plików .exe i folderów zawierających pliki wykonywalne).
• Windows Installer Rules – umożliwia tworzenie reguł związanych z plikami instalatora Windows (.msp oraz .msi).
• Script Rules – umożliwia tworzenie reguł odnoszących się do plików-skryptów (.ps1; .bat; .cmd; .vbs; .js).
• DLL Rules – umożliwia tworzenie reguł nawiązujących do bibliotek DLL bądź kontrolek ActiveX.

 

Nim przystąpimy do pierwszych konfiguracji, należy zapamiętać, że tworząc nowe reguły należy opierać się na zasadach:

• „białych list” – tworząc nowe reguły należy tworzyć zasady „zezwolenia”, i w przypadku konieczności blokady danej aplikacji utworzyć wyjątek w ramach tej zasady;
• „czarnych list”, czyli zasada gdzie blokuje się konkretne obszary, chcąc zezwolić na uruchomienie aplikacji, tworzy się dla niej wyjątek.

AppLocker umożliwia uruchomienie tych elementów, które zostały „dozwolone”, dlatego administrator powinien stale pilnować listy reguł Co istotne, stworzone reguły możemy importować oraz eksportować z/do pliku XML. Aby zaimportować/wyeksportować stworzone reguł, należy wybrać opcję Import Policy... bądź Export Policy..., z poziomu menu kontekstowego, dostępnego z poziomu AppLocker, jak zaprezentowano na poniższym zrzucie.

Rysunek 2. Importowanie/eksportowanie polityk.

Z tego samego menu możemy wskazać opcję Clear Policy, która spowoduje usunięcie wszystkich zdefiniowanych reguł. Wybranie tej opcji to powrócenie do opcji „domyślnych”, przy których AppLocker nie jest aktywny.

Na samym wstępie do konfiguracji należy zaznaczyć, że stworzenie roli nie spowoduje jej natychmiastowego zastosowania – nim nowe zasady zostaną wprowadzone, należy uruchomić usługę AppID Service. Bez jej uruchomienia, tuż po wprowadzeniu reguł i pierwszych testach może spotkać nas niespodzianka – „nie działa”.

W celu uruchomienia usługi należy uruchomić konsolę Services, wpisując Services.msc w polu wyszukiwania w ramach menu Start. Zaleca się, aby – zwłaszcza przy pierwszym spotkaniu z AppLocker – tę usługę uruchamiać manualnie.

Rysunek 3. Uruchamianie usługi AppID

Do początku strony

Pierwsza konfiguracja

Przystąpmy do pierwszej konfiguracji AppLocker. W celu zablokowania bądź dozwolenia uruchomienia danej aplikacji, należy wybrać kolekcję Executable Rules.

Następnie z menu kontekstowego należy wybrać opcję Create Default Rules, w wyniku czego zostaną stworzone następujące, domyślne reguły:

• (Default Rule) Microsoft Windows Program Files Rule dla grupy/użytkownika Everyone – ta reguła zezwala wskazanej grupie użytkowników, na wykonywanie aplikacji znajdujących się w folderze Program Files i jego podfolderach.
• (Default Rule) Microsoft Windows dla grupy/użytkownika Everyone – ta reguła zezwala wskazanej grupie użytkowników, wykonywanie aplikacji znajdujących się w folderze Windows i jego podfolderach. Podsumowując: umożliwia uruchamianie aplikacji systemowych.
• (Default Rule) Administrators dla grupy/użytkownika BUILTIN\Administrators – ta reguła umożliwia grupie lokalnych administratorów wykonywanie wszystkich aplikacji, niezależnie od ich lokalizacji.

 

Aby stworzyć własną, nową politykę, należy wybrać opcję Create New Rule.... Po chwili uruchamia się kreator Create Executable Rules. Należy zapoznać się z prezentowanymi informacjami, następnie wskazać opcję Next.

Rysunek 4. Pierwszy etap kreatora Create Executable Rules.

Na drugiej stronie kreatora, zatytułowanej Permissions, wybieramy czy reguła będzie „dozwalać” (Allow) czy też „zabraniać” (Deny).

Na tym etapie warto zaznaczyć, iż wyższy priorytet mają reguły „zabraniające”. Możemy przypisać regułę Deny dla aplikacji X przypisując ją do wszystkich użytkowników, później stworzyć Allow dla aplikacji X przypisując do użytkownika Y, mimo to, użytkownik Y nie będzie miał możliwości uruchomienia aplikacji X.

Po drugie, regułę przypisujemy do konkretnego użytkownika bądź grupy. Nie istnieje możliwość „przypięcia” jej do danej strefy sieci Internet, wpisu rejestru czy komputera.

Rysunek 5. Drugi etap kreatora – strona „Permissions”.

Kolejna, trzecia strona kreatora została nazwana „Condidtions”. Na tym etapie należy wskazać podstawową regułę restrykcji (na podstawie której będzie odbywać się identyfikacja pliku wykonywalnego). Dostępne są trzy metody:

• File hash – umożliwia identyfikację aplikacji po kryptograficznym „odcisku palca” danego programu. Metoda znana z Software Restriction Policies, podstawowa wada – każda aktualizacja aplikacji wymusza rekonfigurację roli.
• Path – umożliwia wskazanie konkretnej aplikacji bądź folderu i podfolderów w celu zezwolenia bądź zabronienia uruchamiania plików wykonywalnych w nich się znajdujących. Kolejna rola znana z Software Restriction Policies, podstawowa, ale oczywista wada – reguła jest związana ściśle z lokalizacją – program może być nadal uruchomiony, jeżeli znajdzie się w innej lokalizacji.
• Publisher – kluczowa nowość oferowana przez AppLocker. Umożliwia tworzenie reguł w oparciu o dane z podpisu cyfrowego aplikacji. Administrator ma możliwość utworzenia reguły w oparciu o regułę Publisher wybierając odpowiedni dla środowiska zakres – wydawcy, nazwy produktu, nazwy pliku i wersji pliku. Funkcja podobna do Certificate rule z Software Restriction Policies, aczkolwiek udoskonalona i bardziej użyteczna, zwłaszcza, iż zdecydowana większość programów „komaptybilne” podpisy cyfrowe posiada.

 

Rysunek 6. Etap „Condidations” – wskazywanie „metody” rozpoznawania aplikacji.

Dla celów pokazowych, wybierzemy opcje Publisher, w celu zaprezentowana działania nowej funkcjonalności. Przyjmijmy, że administrator chce udostępnić możliwość uruchamiania wszystkich składników pakietu Microsoft Office, z wyjątkiem programu PowerPoint.

Aby wykonać to zadanie należy wskazać plik .exe dowolnej aplikacji z rodziny Microsoft Office, wybierając przycisk Browse..., a następnie konkretny plik, jak to zostało pokazane poniżej.

Rysunek 7. Etap „Publisher” – aplikacja Word, składnik pakietu Microsoft Office.

Jako, że naszym celem jest restrykcja na poziomie rodziny produktów (pakiet Microsoft Office), musimy zmienić zakres na Product name:, gdzie w wartościach znajduje się 2007 MICROSOFT OFFICE SYSTEM. Takie ustawienie spowoduje, że będą uruchamiane pliki, które zostały podpisane przez wydawcę MICROSOFT CORPORATION wraz z adnotacją o nazwie produktu 2007 MICROSOFT OFFICE SYSTEM. Gdy wykonaliśmy wszystkie niezbędne kroki, możemy nasz wybór zatwierdzić przyciskiem Next, tym samym przechodząc do następnego etapu.

Kolejna strona – Exceptions – pozwala wskazać wyjątki dla tworzonej reguły. W naszym przypadku, chcemy z reguły wyłączyć program PowerPoint. Aby wykorzystać potencjał AppLocker, z listy rozwijanej wybieramy Publisher, następnie przycisk Add. W nowym oknie, po wskazaniu kontrolki Browse..., wybieramy plik POWERPNT.EXE. Jako, że celem ćwiczenia jest zablokowanie możliwości uruchomienia PowerPoint, czytelnik musi zmienić zakres na File name: POWERPNT.EXE. Po zdefiniowaniu takich ustawień, zatwierdzamy przyciskiem OK., następnie, gdy powrócimy do kreatora, wskazujemy Next.

Rysunek 8. Tworzenie wyjątków dla definiowanej roli.

W ramach ostatniego etapu opcjonalnie dodajemy opis nowej reguły, pracę kreatora finalizujemy wybierając przycisk Create.

Nim przetestujemy działanie utworzonej reguły, należy upewnić się, że – o ile tworzyliśmy – usunęliśmy dwie, spośród trzech domyślnych reguł: (Default Rule) Microsoft Windows Program Files Rule oraz jeżeli pracujemy na koncie należącego do grupy lokalnych administratorów: (Default Rule) Administrators . Należy upewnić się również, że działa usługa AppID Service.

Do początku strony

Testujemy naszą konfigurację

Spróbujmy uruchomić aplikację Word, wchodzącą w skład Microsoft Office – uruchomienie się powiodło. Teraz spróbujmy uruchomić program PowerPoint – pojawia się komunikat z informacją, że uruchomienie aplikacji zostało zablokowane przez Group Policy. Podsumowując: stworzona reguła działa!

Rysunek 9. Testy stworzonej reguły – Word 2007 działa, PowerPoint – zgodnie z ustawieniami – nie.

Po implementacji rozwiązania AppLocker należy się spodziewać zwiększonej liczby telefonów do działu wsparcia technicznego, aczkolwiek najważniejsze problemy w konfiguracji można rozpoznać poprzez dziennik zdarzeń dla AppLocker, dostępnego z poziomu Event Viewer, jak to zostało pokazane na zrzucie ekranu.

Rysunek 10. Dziennik zdarzeń dla AppLocker.

Do początku strony

Blokowanie bez blokowania

W prezentowanym wcześniej ćwiczeniu wprowadzane polityki, „wchodziły w życie” tuż po utworzeniu reguł. Jedną z ciekawszych opcji dostępnych w AppLocker jest tryb Audit Only, który po aktywacji umożliwia administratorom sprawdzenie, które aplikacje nie uruchomiłby się, jeżeli dana reguła zostałaby uaktywniona.

Aby włączyć tryb Audit Only, należy w ustawieniach AppLocker, wskazać tryb na liście rozwijanej dla danej kolekcji restrykcji – w opisanym przypadku dotyczy to Executable rules. Gdy użytkownik zainicjuje program, którego dotyczy rola (w trybie Audit Only) zostanie stworzony odpowiedni wpis w dzienniku zdarzeń.

Rysunek 11. Włączanie trybu Audit Only dla kolekcji restrykcji Executable rules.

Do początku strony

Automatyczne tworzenie zasad

Ostatnią z zaprezentowanych w artykule opcji funkcjonalności AppLocker będzie kreator Automatically Generate Executable Rules. Kreator umożliwia automatyczne utworzenie reguł dla aplikacji znajdujących się w danej lokalizacji (np. folderze Program Files).

Gdzie ta opcja znajdzie swoje zastosowanie? Na komputerach wzorcowych, gdzie tworzymy konfigurację wzorcową, w celu dalszego wdrożenia.

Aby utworzyć regułę automatycznie, należy w ramach sekcji ról wskazać z menu opcję Automatically Generate Rules... W nowym oknie wprowadzić dane: 1) Folder do analizy 2) Użytkownika bądź grupę, dla których reguły są tworzone 3) Nazwę dla zestawu reguł.

Rysunek 12. Automatyczne tworzenie ról.

W kolejnym kroku wskazujemy preferencje dot. metody restrykcji. Domyślną jest Publisher, aczkolwiek należy pamiętać, iż nie wszystkie programy posiadają zgodny podpis cyfrowy, z którego AppLocker mógłby skorzystać – w tym celu wskazujemy metodę alternatywną.

Chwilę później następuje szacowanie ile reguł musi zostać stworzonych, zapoznajemy się z podsumowaniem i wybieramy przycisk Create, który rozpocznie proces tworzenia polityk. Tak stworzone zasady na komputerze wzorcowym, mogą zostać wyeksportowane wcześniej opisanym sposobem, w celu dalszej implementacji.

Do początku strony

Podsumowanie

AppLocker to interesujące rozwiązanie podnoszące poziom bezpieczeństwa na stacjach klienckich, które jest rozwinięciem funkcjonalności Software Restriction Policies wprowadzonych w Windows XP i Windows Server 2003.

AppLocker jest dostępny w dwóch edycjach Windows 7: Enterprise oraz Ultimate, jak również we wszystkich edycjach Windows Server 2008 R2.

Do AppLocker wprowadzono kilka znaczących usprawnień, które powodują, że zarządzanie restrykcjami dot. oprogramowania, pakietów instalatora Windows, skryptów czy bibliotek DLL, jest łatwiejsze i bardziej spójne.

Jeżeli zetknąłeś się z Software Restriction Policies i zrezygnowałeś z tej funkcjonalności, z powodu trudności konfiguracji, powinieneś sięgnąć po AppLocker, który nie posiada minusów SRP.

Do początku strony

Zasoby dodatkowe

Microsoft TechNet: What's New in AppLocker

---

Łukasz Foks (MCTS, MCITP) Pasjonat technologii Microsoft. W swoim portfolio posiada kilkadziesiąt artykułów i porad technicznych związanych z systemami Microsoft Windows. Zastępca redaktora naczelnego największego portalu technicznego o serwerowych rozwiązaniach Microsoft - http://wss.pl, z którym związany jest już od kilku lat. Aktywnie udziela się również prowadząc liczne prezentacje oraz wspierając Warszawską Grupę Użytkowników i Specjalistów Windows od początku jej istnienia, będąc współtwórcą tej grupy. Szczególnie preferowanymi obszarami tematycznymi są Windows Desktop Experience oraz Windows Deployment.

Do początku strony

 

---