Applocker vs. Polityka ograniczeń oprogramowania

Celem jest uniemożliwienie użytkownikom uruchamiania niepożądanych programów na serwerze terminali.

Przeczytałem wiele artykułów od Microsoft i innych, które mówią, że nowa funkcja Applocker jest o 100% lepsza niż stara Polityka ograniczeń oprogramowania i jest zalecana jako zamiennik tej ostatniej.

Nie jestem pewien, czy rozumiem prawdziwe zalety Applocker oprócz wykonywania trybu jądra. Większość jego funkcji można odtworzyć w Polityce ograniczeń oprogramowania.

Jednocześnie ma jedną WIELKĄ wadę, która czyni ją dość bezużyteczną: nie jest rozszerzalna i nie można dodawać niestandardowych rozszerzeń plików, które chcesz ograniczyć.

Jakie są zalety Applocker nad SRP i co poleciłbyś do kontroli oprogramowania?

Zasady ograniczeń oprogramowania są przestarzałe przez Microsoft ( technet skutecznie twierdzi, że SRP nie jest obsługiwane ), ponieważ Windows 7 Enterprise / Ultimate wprowadził funkcję AppLocker.

W praktyce SRP ma pewne pułapki, zarówno dla fałszywych negatywów, jak i fałszywie pozytywnych. Zaletą AppLocker jest to, że wciąż jest aktywnie utrzymywana i wspierana. Jeśli AppLocker jest opcją, może być tańszy - po uwzględnieniu czasu i ryzyka. Możliwe jest również, że istnieje odpowiednia alternatywa strony trzeciej (ale to pytanie nie zawierało tej opcji :).

Mamy nadzieję, że doskonale zrozumiesz pułapki SRP, zanim wpadniesz w którekolwiek z nich </sarcasm>. Niektóre z nich zostały opisane w ładnym artykule dotyczącym bezpieczeństwa autorstwa Vadims Podāns .

Znane pułapki

1. Domyślnie wykonywanie z \Windowsfolderu jest dozwolone. Użytkownicy mogą zapisywać niektóre podfoldery. Applocker jest taki sam, ale przynajmniej oficjalna dokumentacja wspomina o tym ograniczeniu .

   EDYCJA: „Aby wyliczyć wszystkie foldery z dostępem użytkowników do zapisu , możesz użyć na przykład narzędzia AccessEnum z pakietu Sysinternals.” (lub AccessChk ).

   Z technicznego punktu widzenia dokumentacja przestrzega również przed nadpisywaniem domyślnych reguł . EDYCJA: Dokument NSA podaje 16 przykładów folderów na czarnej liście za pomocą SRP , chociaż reguły ścieżki rejestru nieprawidłowo używają ukośników odwrotnych, więc należy je poprawić (patrz punkt na ścieżkach rejestru poniżej) i ostrzega przed powszechnym szerokim wpisem na czarnej liście.

   Oczywistym pytaniem jest, dlaczego \Windowszamiast tego nie umieszczamy ostrożnie na białej liście poszczególnych ścieżek . (W tym \Windows\*.exedziedzictwo System32\*.exe, itp.). Nigdzie nie zauważyłem żadnych odpowiedzi :(.

2. Używając zmiennych środowiskowych, takich jak %systemroot%, SRP może być ominięty przez użytkowników poprzez wyczyszczenie zmiennej środowiskowej. EDYCJA: Nie są one używane w sugerowanych ustawieniach domyślnych. Jednak mogą być kuszące w użyciu. Ten pistolet jest naprawiony w AppLocker, ponieważ nigdy nie patrzy na zmienne środowiskowe.

3. Sugerowane wartości domyślne nie uwzględniają dwóch różnych opcji \Program Filesużywanych w nowoczesnych instalacjach 64-bitowych. Podczas rozwiązywania tego problemu przy użyciu bezpieczniejszych „ścieżek rejestru” pojawiają się doniesienia o fałszywych odmowach w przypadkowych sytuacjach, których łatwo można pominąć w testach. np. zobacz komentarze na temat SpiceWorks SRP . EDYCJA: Ma to związek z 32-bitowymi aplikacjami odczytującymi odpowiednie ścieżki z WOW6432Node rejestru: rozwiązaniem jest dodanie obu tych ścieżek do SRP, aby umożliwić wszystkim programom działanie na komputerach 32-bitowych i 64-bitowych jako nieograniczone, czy uruchamiane z proces hosta x64 lub x86:%HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\ProgramFilesDir (x86)% %HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\ProgramW6432Dir%
4. Domyślne rozszerzenia pomijają skrypty PowerShell (* .PS1) obsługiwane przez system Windows . (Zobacz wideo ). I APPX też ... również zgodnie z tabelą porównawczą Microsoftu, SRP nie może zarządzać „pakietami aplikacji” w Windows 8, nie mam pojęcia co to oznacza.
5. Zasady ścieżka rejestru nie musi mieć ukośników natychmiast po ostatnim znakiem procentu (pomimo, że zawarte w Microsoft własnego wbudowaną zasad XP / Server 2003) oraz wszelkie ukośniki muszą być zastąpione forwardslashes w celu regułę do pracy ( 1 / 2 / 3 ).
6. Ze źródeł, które znalazłem dla SRP, żadne nie zestawiło dla ciebie pełnej powyższej listy. I przypadkiem odkryłem artykuł Vadimsa Podānsa. Co jeszcze się tam czai?
7. Wiele źródeł zaleca po prostu usunięcie plików LNK z listy. (Oraz skróty internetowe, aby uniknąć łamania Ulubionych ?!). Niepokojące wydaje się, że żadne źródła nie dyskutują o lukach w LNK ... lub zmuszają interpreterów skryptów do uruchamiania plików z nieoczekiwanym rozszerzeniem, np.wscript /e ... lub może upychają wystarczającą ilość kodu powłoki w wbudowanym parametrze skryptu ... itd.
8. Jeśli spróbujesz pójść na kompromis, zezwalając na pliki LNK na pulpicie i pozostawisz użytkownikom dostęp do zapisu na pulpicie, mogą oni całkowicie ominąć twoje zasady. Piękna wskazówka od Vadims Podāns ponownie. Zauważ, że wyjaśnienie dotyczy użycia dowolnego rozszerzenia w regule ścieżki. Microsoft przedstawia wiele takich przykładów, w tym *.Extensionbez ostrzeżenia. Więc nie możesz ufać oficjalnej dokumentacji i wydaje się, że jest mało prawdopodobne, aby ją teraz naprawić.
9. [Potencjalna wada AppLocker]. Vadims Podāns informuje, że wpisy SRP korzystające z mapowanych dysków nie działają. Zamiast tego należy użyć ścieżki UNC. Może wtedy ubiegaliby się o dostęp za pośrednictwem zmapowanego dysku? nie jest w 100% jasne. Najwyraźniej AppLocker był inny: nie działał z żadnym z :(. "Z nieznanego powodu ścieżki UNC nie działają w Applocker! Oznacza to, że jeśli twoja aplikacja jest zainstalowana w sieci, musisz utworzyć reguły skrótu lub wydawcy . ”

Pragmatyczne podejście

Biała lista oprogramowania jest potencjalnie bardzo potężną obroną. Jeśli staniemy się cyniczni: właśnie z tego powodu Microsoft deprecjonuje tańsze wersje i wymyśla bardziej złożone.

Być może żadna inna opcja nie jest dostępna (w tym rozwiązania innych firm). Następnie pragmatycznym podejściem byłoby próba skonfigurowania SRP tak prosto, jak to możliwe. Potraktuj to jako dodatkową warstwę obrony ze znanymi dziurami. Dopasowywanie pułapek powyżej:

1. Zacznij od domyślnych reguł (z okresu sprzed Win7 :).
2. Wolę nie używać zmiennych środowiskowych, np %systemroot%.
3. Dodaj reguły, aby upewnić się, że oba \Program Files\katalogi są dozwolone na nowoczesnych komputerach 64-bitowych. Dodatkowe „ścieżki rejestru”, które należy dodać \Program Files\na komputerach 64-bitowych, to %HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\ProgramFilesDir (x86)%i %HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\ProgramW6432Dir%.
4. Po dodaniu do zasad ścieżki rejestru, opuścić żadnego backslash natychmiast po znaku procent, a zastępuje żadnych dalszych backslashy \z forwardslashes /(np %HKEY_LOCAL_MACHINE\Software\CompanyName\CustomApps%App/Bin/start.exe)
5. Dodaj PS1 do listy kontrolowanych rozszerzeń.
6. Zrozum, że konfigurowalna konfiguracja SRP nie jest bezpieczna dla użytkownika, który chce ją pokonać. Ma to na celu pomóc / zachęcić użytkowników do pracy w ramach zasad, aby chronić ich przed atakami takimi jak „ściąganie z dysku”.
7. Zezwalaj na pliki LNK. (Najlepiej, usuwając go z listy rozszerzeń, a nie przez jakąś regułę ścieżki).
8. Patrz wyżej :).
9. Upewnij się, że folder skryptu logowania jest dozwolony. Dokument NSA sugeruje dodanie \\%USERDNSDOMAIN%\Sysvol\. (Patrz punkt 2, westchnienie, a następnie punkt 6).

Zgadzam się, że SRP ma dodatkowe funkcje, z których AppLocker mógłby naprawdę skorzystać.

Biorąc to pod uwagę, widzę duże zalety AppLocker (udokumentowane przez to porównanie ) jako:

• Reguły funkcji AppLocker mogą być kierowane do określonego użytkownika lub grupy użytkowników, podczas gdy SRP jest egzekwowane na całym komputerze.
• AppLocker obsługuje tryb inspekcji, dzięki czemu reguły mogą być testowane w środowisku produkcyjnym przed wymuszeniem. SRP nie ma równoważnego trybu tylko do logowania.

Największą zaletą jest dla mnie możliwość dodania do listy podpisanych plików wykonywalnych przez wydawcę. Zajrzyj na ten http://technet.microsoft.com/en-us/library/ee460943(v=ws.10).aspx

AppLocker nie ma żadnych korzyści, Microsoft opublikował rażące kłamstwa: 1. Obiekty GPO z regułami SAFER mogą być dołączane do użytkowników i grup użytkowników; 2. Windows Vista wprowadził wiele lokalnych obiektów GPO, które osiągają ten sam wynik bez kontrolera domeny; 3. Tryb audytu jest dostępny poprzez funkcję rozszerzonego logowania bez wymuszania.

Używam Applocker w mojej firmie. Stosujemy strategię: odrzuć wszystko jako punkt odniesienia (w rzeczywistości: domyślnie Applocker), a następnie zrób to, co zostało zasugerowane: utwórz regułę, która zezwala tylko na podpisane aplikacje (biuro, Adobe, wintools, ax itp.). Większość, być może całe złośliwe oprogramowanie nie jest oprogramowaniem podpisanym, więc się nie uruchomi. To prawie żadna konserwacja. Musiałem tylko pozwolić na 3 dodatkowe starsze aplikacje.

Ponadto nie mogę potwierdzić, że nie można używać ścieżek UNC. W niektórych dodatkowych zasadach odmowy bezpieczeństwa z powodzeniem używam ścieżki UNC. Problem polega na użyciu zmiennych środowiskowych: nie działają one dla Applocker. Użyj * symboli wieloznacznych. Używam go w systemie Windows 2008 R2 i Windows 2012 R2.

Bardzo mi się podoba: prawie nie ma spadku wydajności. Zgodnie z dokumentacją: Applocker polega na usłudze tożsamości aplikacji (upewnij się, że uruchamia się automatycznie).