Applocker vs Політика обмеження програмного забезпечення

Мета - не дати користувачам запускати небажані програми на термінальному сервері.

Я прочитав багато статей від Microsoft та інших, які говорять про те, що нова функція Applocker на 100% краща за стару політику щодо обмеження програмного забезпечення та рекомендується замінити її.

Я не впевнений, що розумію реальні переваги Applocker, крім виконання режиму ядра. Більшість його функціональних можливостей можна відтворити за допомогою політики обмеження програмного забезпечення.

При цьому у нього є один ВЕЛИЧИЙ недолік, який робить його досить марним: він не розширюється, і ви не можете додавати спеціальні розширення файлів, які ви хочете обмежити.

Які переваги Applocker над SRP і що б ви порадили для управління програмним забезпеченням?

Політика щодо обмеження програмного забезпечення Microsoft застаріла ( технологія, яка ефективно заявляє, що SRP не підтримується ), оскільки Windows 7 Enterprise / Ultimate представила AppLocker.

На практиці СРП має певні підводні камені як для помилкових негативів, так і для помилкових позитивів. AppLocker має перевагу в тому, що він все ще активно підтримується та підтримується. Якщо AppLocker є варіантом, то це може бути і дешевшим - після обліку свого часу та ризиків. Можливо також, є відповідна стороння альтернатива (але це питання не включало цей варіант :).

Сподіваємось, ви отримаєте ідеальне розуміння підводних каменів SRP, перш ніж потрапити в будь-яку з них </sarcasm>. Деякі з них описані в приємній статті про безпеку від Вадима Поданаса .

Відомі підводні камені

1. За замовчуванням виконання з \Windowsпапки дозволено. Деякі підпапки можуть писати користувачі. Applocker - це те саме, але принаймні офіційна документація згадує це обмеження .

   EDIT: "Для перерахування всіх папок з доступом для запису користувачів можна використовувати, наприклад, утиліту AccessEnum з пакета Sysinternals." (або AccessChk ).

   Технічно документація також застерігає вас від зміни правил за замовчуванням . EDIT: Документ NSA містить 16 прикладів папок до чорного списку з SRP , хоча правила траєкторії реєстру використовують зворотні косої риси, тому їх слід виправити (див. Пункт про шляхи до реєстру нижче) та попереджає про загальну загальну запис чорного списку.

   Очевидне питання, чому ми не ставимо ретельно білі списки окремих маршрутів \Windows. (Включаючи \Windows\*.exeспадщину System32\*.exeтощо). Відповідей на це я ніде не помітив :(.

2. Використовуючи змінні середовища, такі як %systemroot%SRP, можна обійти користувачами, очистивши змінну середовища. EDIT: Вони не використовуються у запропонованих типових настройках. Однак вони можуть бути спокусливими для використання. Цей пістолет зафіксований у AppLocker, оскільки він ніколи не переглядає змінні середовища.

3. Запропоновані налаштування за замовчуванням нехтують, щоб дозволити два різних, що \Program Filesвикористовуються в сучасних 64-бітних установках. Вирішуючи це за допомогою більш захищених "шляхів до реєстру", з'являються повідомлення про помилкові відмови у випадкових ситуаціях, які легко пропустити при тестуванні. наприклад, дивіться коментарі до Howto SpiceWorks SRP . EDIT: Це стосується 32-розрядних додатків, що читають відповідні шляхи з WOW6432Node реєстру: роздільна здатність полягає в тому, щоб додати обидва ці шляхи до SRP, щоб всі програми могли працювати на 32-бітних і 64-бітних машинах як необмежене, починаючи з процес хосту x64 або x86:%HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\ProgramFilesDir (x86)% %HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\ProgramW6432Dir%
4. Розширення за замовчуванням нехтують забороною скриптів PowerShell (* .PS1), що підтримуються Windows . (Дивіться відео ). І APPX теж ... також за таблицею порівняння Microsoft, SRP не може керувати "пакетованими програмами" в Windows 8, я не маю поняття, що це означає.
5. Правила шляхи реєстру не повинні бути слеш відразу після останнього знака відсотка (незважаючи на те , включені в Microsoft власного вбудованих правил для XP / Server 2003) і всіх зворотних косих рис повинні бути замінено forwardslashes для того , щоб правила до роботи ( 1 / 2 / 3 ).
6. З джерел, які я знайшов для SRP, жодне не склало для вас повний список вище. І статтю Вадима Поданса я відкрив лише випадково. Що ще там ховається?
7. Багато джерел рекомендують просто видалити файли LNK зі списку. (І веб-ярлики, щоб не зламати вибране ?!). Тривожно, схоже, що жодні джерела не обговорюють вразливості LNK ... або змушення інтерпретаторів скриптів для запуску файлів з несподіваним розширенням, наприкладwscript /e ... або, можливо, заповнення достатнього оболонки в параметр вбудованого сценарію ...
8. Якщо ви спробуєте піти на компроміс, дозволяючи файли LNK на робочому столі, і ви залишаєте користувачам доступ для запису на робочий стіл, вони тепер можуть повністю обійти вашу політику. Прекрасна порада від Вадима Подана знову. Зауважте, що пояснення стосується використання будь-якого розширення в правилі шляху. Microsoft представляє кілька прикладів цього, включаючи *.Extension, без попередження. Таким чином, ви не можете довіряти офіційній документації , і, здається, зараз це неможливо виправити.
9. [Потенційний недолік AppLocker]. Вадим Поданс повідомляє, що записи SRP, використовувані зіставлені диски, не працюють. Натомість слід використовувати шлях UNC. Може, тоді вони звернуться до доступу через картографічний диск? це не на 100% зрозуміло. Мабуть, AppLocker був іншим: він не працював ні з :( "" Через невідому причину, UNC-шляхи не працюють в Applocker! Це означає, що якщо ваша програма встановлена ​​в мережі, ви повинні створити або хеш, або правила видавця . "

Прагматичний підхід

Білий список програмного забезпечення - це потенційно дуже потужна захист. Якщо ми стаємо цинічними: саме тому Microsoft знецінює версії з нижчими цінами і винайшов більш складні.

Можливо, інший варіант недоступний (включіть сторонні рішення). Тоді прагматичним підходом було б спробувати налаштувати SRP максимально просто. Трактуйте це як додатковий шар захисту, з відомими отворами. Відповідні підводні камені вище:

1. Почніть з правил за замовчуванням (з епохи до Win7 :).
2. Віддайте перевагу не використовувати змінні середовища, наприклад %systemroot%.
3. Додайте правила, щоб переконатися, що обидва \Program Files\каталоги дозволені на сучасних 64-бітних машинах. Додаткові "контури до реєстру", які потрібно буде додати \Program Files\на 64-бітних комп'ютерах, є %HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\ProgramFilesDir (x86)%і %HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\ProgramW6432Dir%.
4. Додаючи до правил контуру реєстру, залиште будь-яку зворотну косу рису одразу після знаку відсотка та замініть будь-які подальші наклони риски \наперед /(1 %HKEY_LOCAL_MACHINE\Software\CompanyName\CustomApps%App/Bin/start.exe)
5. Додайте PS1 до списку керованих розширень.
6. Зрозумійте, що керована конфігурація SRP не захищена від користувача, який налаштований перемогти її. Метою є допомогти / заохотити користувачів працювати в рамках політики, захистити їх від атак, таких як "завантаження за допомогою диска".
7. Дозволити файли LNK. (Переважно, видаливши його зі списку розширень, а не через якесь правило шляху).
8. Дивись вище :).
9. Переконайтеся, що ваша папка скриптів для входу дозволена. Документ АНБ пропонує додати \\%USERDNSDOMAIN%\Sysvol\. (Див. Пункт №2, зітхніть, потім див. Пункт № 6).

Я погоджуюся, що SRP має деякі додаткові функції, від яких AppLocker дійсно може отримати користь.

Попри це, я бачу великі переваги AppLocker (як це зафіксовано цим порівнянням ) як:

• Правила AppLocker можуть бути націлені на конкретного користувача або групу користувачів, тоді як SRP застосовується на всьому комп'ютері.
• AppLocker підтримує режим аудиту, так що правила можуть бути протестовані у виробництві перед їх застосуванням. SRP не має еквівалентного режиму лише журналу.

Найбільшою перевагою для мене є можливість видати список довірених файлів з підписом від видавця. Погляньте на цей http://technet.microsoft.com/en-us/library/ee460943(v=ws.10).aspx

Немає переваг AppLocker, Microsoft опублікувала кричущі брехні: 1. Групи користувачів із правилами SAFER можуть бути приєднані до користувачів та груп користувачів; 2. Windows Vista представила кілька локальних GPO, які досягають однакового результату без контролера домену; 3. Режим аудиту доступний через розширену функцію ведення журналу без примусового застосування.

Я використовую Applocker у своїй компанії. Ми використовуємо стратегію: Заборонити все як базову лінію (насправді: параметри Applocker за замовчуванням), а потім робити те, що було запропоновано: скласти правило, яке допускає лише підписані програми (office, Adobe, Wintools, ax тощо). Більшість, можливо, все зловмисне програмне забезпечення не підписане програмним забезпеченням, тому не виконуватиметься. Це навряд чи будь-яке обслуговування. Мені довелося лише дозволити 3 додаткові застарілі програми.

Далі я не можу підтвердити, що не можна використовувати контури UNC. У деяких додаткових правилах заперечення безпеки я успішно використовую UNC-шлях. Проблема полягає у використанні змінних умов середовища: вони не працюють для Applocker. Використовуйте * підстановку. Я використовую його на Windows 2008 R2 та Windows 2012 R2.

Мені це дуже подобається: майже не спостерігається падіння продуктивності. Як зазначено в документації: Applocker покладається на службу ідентифікації програми (переконайтеся, що вона запускається автоматично).