За замовчуванням заборонити всі додатки (частина 2)

Якщо ви хочете ознайомитися з іншими частинами цієї статті, будь ласка, прочитайте:

З виходом операційної системи Windows XP у адміністраторів у всьому світі з'явилася можливість визначення політики обмеження програмного забезпечення (Software Restriction Policies SRP) для своїх клієнтських комп'ютерів, щоб контролювати дозволені і заборонені для запуску програми. Але лише деякі організації реалізували цю функціональність, незважаючи на той факт, що це дозволяє значно збільшити безпеку. У цій другій статті, присвяченій SRP, ми розповімо про те, як реалізувати те, що ще називають політикою фільтрів програмного забезпечення «software filter policies».

небезпечна зона

Перед тим, як ми продовжимо, дуже важливо вказати на те, що перед тим, як реалізувати SRP на ваших промислових комп'ютерах, ви повинні її ретельно спланувати і перевірити. Це можна зробити в Active Directory (AD) ізолювавши одну тестову машину або призначений для користувача об'єкт в організаційній одиниці (Organizational Unit або OU) або задавши дозвіл «Apply Group Policy» (застосувати політику групи) для об'єкта Group Policy Object (GPO) тільки для однієї тестової машини або користувальницької облікового запису. SRP можна використовувати навіть на окремо стоїть машині, якщо ви зовсім не хочете торкатися промислової середовища. Я рекомендую використовувати для основного тестування віртуальні комп'ютери і комп'ютери, максимально схожі на промислові, для остаточних тестів. Після ретельного тестування SRP необхідно реалізувати для досвідчених користувачів в групах, краще йти невеликими кроками, ніж відразу потрапити в біду!

весь процес

Помилки при проектуванні і реалізації SRP можуть привести до значних незадоволення з боку користувачів, і навіть до втрати грошей і продуктивності, тому будьте дуже уважні. Для цього необхідно все ретельно спланувати, перевірити і підтримувати з момент введення в промислову середу. Після цього ви зможете спати вночі спокійно ...

Наступний список являє собою короткий огляд того, про що необхідно пам'ятати при впровадженні SRP в середовищі Windows.

При проектуванні установки SRP необхідно прийняти різні рішення, наприклад:

Вибрати між об'єктами груп GPO користувачів або комп'ютерів - для яких об'єктів AD повинні бути застосовані політики SRP?
Вибрати між чорним списком (Blacklisting BL) і білим списком (Whitelisting (WL) (WL - рекомендується використовувати по можливості)
Якщо використовується підхід на основі BL, необхідно скласти список всього, що не повинно запускатися
Якщо використовується підхід на основі WL, необхідно скласти список всього, що має запускатися
Вибрати, як настройки SRP використовувати (форсування, певні типи файлів, виключення для адміністраторів)
Вибрати типи правил, які будуть використовуватися (шлях, HASH, сертифікат або зона інтернет)

При тестуванні установки SRP необхідно зробити різні кроки, наприклад:

Перевірити основну функціональність в віртуальної лабораторії (за допомогою Virtual PC / Server, VMware або інших)
Перевірити функціональність у вашому середовищі, використовуючи для цього умови максимально наближені до промислових.
Перевірити на невеликих групах досвідчених користувачів по 5-10 користувачів протягом кілька тижнів, потім збільшувати
Продовжити з наступною дослідної групою лише після успішної реалізації для попередньої групи досвідчених користувачів
Переконатися, що перевірені всі різні типи користувачів і типи комп'ютерів, які ви хочете убезпечити за допомогою SRP
Переконатися, що перевірені всі оновлення, патчі для операційних систем, оновлення програм сторонніх виробників і т.п.
Також сфокусуватися на продуктивності різного апаратного забезпечення у вашій організації. Реалізація SRP в більшості випадків впливає трохи на продуктивність, в залежності від того, як вона реалізована (дивіться розділ про Trusted Publishers)
Іноді додатки запускають інші програми, тому необхідно переконатися, що все це перебувати під контролем
За замовчуванням блокуються ярлики Desktop (робочий стіл) і Start (пуск) (.LNK), тому в разі необхідності це потрібно виправити
Переконайтеся, що виконуються сценарії адміністратора (в тому числі сценарій, що запускаються при вході login в SYSVOL / NETLOGON)

Перед впровадженням SRP в промисловому середовищі, необхідно визначити деякі процедури:

Різні шляхи до SRP

Налаштування політики обмеження програмного забезпечення (Software Restriction Policy) включає в себе кілька етапів:

Створення об'єкта політики груп для користувача (User GPO) або для комп'ютера (Computer GPO) та розміщення його на сайті (Site), домені (Domain) або організаційної одиниці OU (або як локальної політики) і підключення SRP для політики групи (Group Policy ). Налаштування SRP розташовані тут (дивіться малюнок 1): Computer Configuration | Windows Settings | Security Settings | Software Restriction Policies

User Configuration | Windows Settings | Security Settings | Software Restriction Policies

При першому зверненні до SRP в GPO буде доступна настройка «New Software Restriction Policies» (нова політика обмеження програмного забезпечення).

За замовчуванням заборонити всі додатки (частина 2)

Установка Default Security Level (рівень безпеки за замовчуванням). На малюнку 2 показано, як за допомогою натискання правої кнопки миші рівень встановлений на «Set as default» (встановити за замовчуванням).

За замовчуванням рівень «Unrestricted» (без обмежень), що означає, що програмне забезпечення може бути запущено, і що необхідно поставити додаткові правила для заборони певного програмного забезпечення (software) - такий підхід відомий, як чорний список Blacklisting.
Найбезпечніший рівень - це «Disallowed» (заборонений), що означає, що ніяке програмне забезпечення не може бути запущено, і що необхідно поставити додаткові правила для дозволу програмного забезпечення - такий підхід відомий, як білі списки Whitelisting.
За замовчуванням система створює кілька правил, які дозволяють операційній системі працювати без всякого незручного блокування NB! Якщо ці правила видалити або змінити не подумавши, то система може вийти з ладу.

В операційних системах Windows Vista і Longhorn у нас з'явився новий рівень під назвою «Basic User» (основний користувач), який дозволяє програмам запускатися від імені користувача, у якого немає прав адміністратора, тому користувач може отримати доступ лише до ресурсів, доступним для звичайних користувачів . Цього рівня ми більше не торкнемося в цій статті.

Типи файлів можна додавати і видаляти, що краще підлаштуватися під вашу середу, але список файлів за замовчуванням включає основні типи виконуваних файлів: BAT, CMD, COM, EXE, HTA, LNK, MSI, OCX, PIF, REG SCR і додатково такі розширення: ADE, ADP, BAS, CHM, CPL, CRT, HLP, INF, INS, ISP, MDB, MDE, MSC, MSP, MST, PCD, SHS, URL, VB WSC.
Примітка: Як то кажуть у вікні Designated Files Type Properties (властивості заданих типів файлів), список є доповненням до стандартних типів файлів, таким як EXE, DLL і VBS - я не зміг отримати їх повний список, але з'ясував, що VBS, VBE, JS і JSE блокуються, хоча вони і не в списку. Я б вважав за краще мати єдиний список, який адміністратори по всьому світу змогли б виправляти в разі потреби.

Визначення винятків (exception) для рівня безпеки за замовчуванням (Default Security Level). Вони також відомі, як «Additional Rules» (додаткові правила). Будь ласка, подивіться розділ «Additional Rules» (додаткові правила) в цій статті для докладної інформації.

Налаштування «Enforcement Properties» (форсують властивості). Подивіться на малюнок 4, вона включає:

«All software files» (всі файли програмного забезпечення): У нас також є налаштування для перевірки DLL (Dynamic Link Libraries), коли вони виконуються. Це не є налаштуванням за замовчуванням і впливає на продуктивність і завдання планування реалізації і підтримки.
«All users except local administrators» (всі користувачі за винятком локальних адміністраторів): Тут ми можемо вибрати, чи буде SRP стосуватися локальних адміністраторів (Local administrators). За замовчуванням SRP стосується всіх користувачів. Ця установка може бути застосована лише для політики для комп'ютера (computer policies).
«Enforce certificate rules» (форсування правил для сертифікатів): Налаштування дозволяє задати, чи будуть використовуватися правила для сертифікатів.
Примітка. Як говориться в діалоговому вікні, зображеному на малюнку 4 «Правила для сертифікатів негативно впливають на продуктивність вашого комп'ютера«.

Налаштування «Trusted Publishers Properties» (властивості довірчих видавців), також відомих, як настройки політики Authenticode policy (дивіться Малюнок 5). У цьому діалоговому вікні ми можемо вибрати, хто може вибирати Trusted Publisher (довірчих видавців) для правил сертифікатів. У нас є також можливість перевірки анулювання сертифіката.

додаткові правила

Під час налаштування додаткових правил (Additional Rules), необхідно визначитися з методом, або з парою методів щодо того, як ідентифікувати програмне забезпечення. У нас є 4 різних методи ідентифікації програмного забезпечення:

1. HASH правила HASH - це зашифрований відбиток, який залишається незалежно від зміни назви файлу і його розташування. Особливо гостро це при використанні WL, але не так ефективно при використанні BL (причина цього частково описана прикладом з використанням інструменту під назвою ProduKey в моїй першій статті про SRP): MD5 або SHA-1 HASH дозволяє чітко ідентифікувати двійковий файл програмного додатка «ProduKey. exe », тому, якщо дозволити запускати лише додатки з певним значенням HASH, дозволить гарантувати, що можна запускати лише певну версію виконуваного файлу. Однак, якщо заборонити файл з певним значенням HASH запускатися, ми лише введемо таке обмеження для однієї версії цього додатка і хитрі користувачі можуть досить просто змінити файл, і він вже не буде підходити під обмеження. Слово «unknown» (невідомий) дуже важливо в цьому випадку - воно є ключовим при виборі між білими списками BL і чорними списками WL - чи хочемо ми дозволити користувачам запускати невідоме програмне забезпечення? Якщо користувач не зможе запустити стару версію певної програми, припустимо, вона неробоча і призводить до порушення роботи системи, то використання правила «deny this HASH value» (заборонити це значення HASH) - буде хорошим рішенням. Будь ласка, пам'ятайте, що у новій версії того ж самого додатка буде нове значення HASH, яке необхідно буде вирішити або заборонити.

2. Правила для сертифікатів Правила для сертифікатів використовують підписані хеші і забезпечують дуже потужну ідентифікацію, але якщо ми довіряємо певного сертифікату, то ми довіряємо всім програмним продуктами, які підписані з використанням цього сертифіката. Це може бути і добре і погано. Це може бути добре, якщо ми, наприклад, отримуємо додаток від стороннього виробника, які підписав всі необхідні файли програми (може бути, включаючи DLL), тому замість того, щоб робити нові правила для HASH, ми просто створюємо одне правило, яке довіряє сертифікату , і продовжуємо працювати. Але якщо я довіряю цифровому сертифікату, який використовується для підпису деяких інструментів від Microsoft (або будь-якого іншого постачальника) - то тепер мої користувачі можуть запускати всі програми, які підписані цим сертифікатом ... Hmm, проблема в тому, щоб дізнатися, що саме підписано цим сертифікатом ? Без таких знань ми не знаємо, що у нас дозволено. Замість того, щоб дозволити один додаток, необхідне для наших користувачів, ми повинні дозволити сотні додатків цього виробника запускатися на наших сістемах.Тестірованіе правил для сертифікатів можна здійснити за допомогою цих інструментів: File Signing Tool (Signcode.exe) Certificate Creation Tool (Makecert.exe).

3. Правила для шляхів Правила для шляхів - це найпоширеніші і прості у використанні правила. Правила для шляхів дозволяють дозволити або заборонити запускати файл з певного місця (наприклад, «C: \ Scripts \ Script.VBS»), ім'я файлу (тобто «Script.VBS»), папки (тобто «C: \ Scripts »), шлях UNC (тобто.» \\ SERVER \ SHARE \ File.VBS ») або шлях в реєстрі (тобто«% [Registry Hive] \ [Registry Key Name] \ [Value Name] % »). Шляхи можуть використовувати змінні оточення (т.e. «% WINDIR%») і шаблони «?» = Один символ (тобто «\\ SERVER ?? \ Share \ Script.VBS») і «*» = будь-яку кількість символів (тобто «* .VBS»). Якщо ви використовуєте правила для шляхів, необхідно враховувати наступне:

Якщо заданий шлях до будь-якої папки, то правило буде зачіпати також всі виконувані файли в дочірніх папках
Якщо у користувача є доступ на запис для папки, для якої задано Unrestricted (без обмежень), то користувача може копіювати будь-який файл в цю директорію і виконати його звідти. При проектуванні необхідно врахувати це, може бути, завдяки використанню ACL (Access Control List або списків контролю доступу) при використанні політики груп Group Policies
Якщо у користувача є доступ на запис до теки, для якої задано Unrestricted, то користувач може переписати цей виконуваний іншим, щоб обдурити SRP
Якщо шлях до папки включає в себе змінні оточення, наприклад,% TEMP%, то навіть користувач з обмеженими правами може змінити змінну оточення, використовуючи команду SET, на інший шлях (SET TEMP = C: \ MyFolder) - і після цього користувач може контролювати цією програмою.

Як писалося вище, користувачі можуть спробувати перейменувати або перемістити заборонені файли - або переписати дозволені файли для того, щоб обдурити SRP - саме тому правила для HASH або для сертифікатів зазвичай розглядаються в якості кращого вибору.

4. Інтернет зона Зони безпеки Internet Explorer security zone можна використовувати для контролю установки програмного забезпечення, але це ставитися лише до настановних пакетів Windows Installer packages (.MSI), які запущені з однією з Інтернет зон за замовчуванням. Ці правила рідко іспользуются.Когда використовується кілька правил, то вони обробляються в порядку, про який вже згадувалося вище, правило за замовчуванням буде останнім.

обмеження SRP

Необхідно також врахувати деякі обмеження SRP. Область дії політики обмеження програмного забезпечення (Software Restriction Policies) - це не вся операційна система, як ви могли очікувати. SRP не застосовується для наступного коду:

Драйвера або інше встановлене програмне забезпечення в режимі ядра
Будь-яка програма, яка виконується під обліковим записом SYSTEM
Макрос всередині документів Microsoft Office (у нас є інші способи для їх блокування з використанням політик груп)
Програми, написані для common language runtime (ці програми використовують політику Code Access Security Policy)

висновок

Політики обмеження програмного забезпечення (Software Restriction Policies) вимагають особливого і довгого технологічного процесу при впровадженні нового програмного забезпечення та оновлення в середовищі, але крім цього за їх рахунок досягається рівень безпеки (security level) набагато вище, ніж при установці «default allow all» ( вирішити всі за замовчуванням). Деякі середовища можуть не підходити для SRP, як мені здається, більшість мереж мають комп'ютери і користувачів, для яких технологія SRP technology чудово підходить.

Необхідно призначення, розуміння і наполеглива робота для реалізації політики «Default Deny» (заборонити за умовчанням) - саме тому вона рідко реалізується ... Але одне безперечно, правильна реалізація таких політик дозволить адміністратору спати ночами спокійно.

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