Користувачі постійно завантажують і запускають додатки, з якими їм не належить працювати, в зв'язку з чим в мережі організації може встановлюватися шкідливе програмне забезпечення. Керувати тим, які програмні засоби користувачі встановлюють на своїх комп'ютерах, в середовищі Windows на подив непросто. Перший компонент вирішення цієї проблеми полягає в тому, щоб в більшості випадків користувачам надавався найменший обсяг повноважень, т. Е. Щоб вони не виступали в ролі адміністраторів або досвідчених користувачів. Другий елемент головоломки - контроль списку програм, які користувачі можуть запускати.

У багатьох рішеннях від незалежних постачальників реалізуються функції білих або чорних списків додатків. Інакше кажучи, створюються списки додатків, які можна (якщо вони внесені до білого списку) або не можна (якщо вони внесені в чорний список) запускати на виконання. Таким чином, важко застосування кінцевими користувачами програмних кодів з «непроханими гостями», які можуть завдати шкоди мережі організації. Однак з метою управління виконанням програм можна використовувати політику обмеженого застосування програм (SRP, відому також як Safer). Хоча в SRP не реалізовані деякі можливості рішень від незалежних постачальників, наприклад заздалегідь складені каталоги сигнатур додатків, що використовуються для блокування або дозволу запуску останніх, дана політика надає можливості, які в багатьох ІТ-підрозділах ще не реалізовані або застосовуються не в повному обсязі.

Як функціонує SRP

SRP застосовна в середовищах Windows Server 2008, Windows Vista, Windows Server 2003 і Windows XP. До цієї функції можна звернутися через редактор групових політик Group Policy Editor (GPE) або в разделеComputer ConfigurationWindows Settings Security Settings, як показано на екрані 1, або в розділі User ConfigurationWindows SettingsSecurity Settings. SRP доступна як локальний об'єкт групових політик (GPO), так і GPO доменів. Однак, як локальний GPO, ця функція доступна лише в якості засобу керування комп'ютерами. Вся міць політик SRP проявляється в тих випадках, коли вони розгортаються через доменні GPO на цілому ряді систем за допомогою вбудованих механізмів призначення групової політики.

SRP дає можливість визначати правила обмеженого використання додатків всередині GPO, і ці правила транслюються на клієнтську систему по звичайних каналах групової політики. Операційна система Windows зберігає ці правила в реєстрі і звертається до них щоразу при виконанні процесу. Якщо відповідне правило існує, під час запуску програми або блокується - в залежності від того, внесено воно в білий або в чорний список. SRP не застосовує санкцій до вже що виконуються додатків, навіть якщо групова політика застосувала відповідні правила. Щоб правило вступило в дію, необхідно перезапустити програму.

налаштування SRP

Проілюструвати можливості використання SRP найкраще на прикладі типового сценарію. Припустимо, на системі користувача виконується Microsoft Office і кілька ділових додатків. Я хочу, щоб цей користувач міг виконувати тільки санкціоновані мною додатки, і тому збираюся реалізувати в політиці SRP білий список.

Налаштування SRP найкраще зберігати в особливому об'єкті GPO, окремо від інших налаштувань політики, щоб у разі потреби їх можна було швидко відключити. Потрібно прийняти рішення: чи будуть обмеження використовуватися стосовно до комп'ютерів або стосовно користувачам. У першому випадку обмеження на запуск додатків стосуються будь-якого користувача, який застосовує облікові записи комп'ютерів в службі Active Directory (AD), які отримують дані обмеження; такий варіант прийнятний, наприклад, при використанні SRP на серверах терміналів. Обмеження «на користувача» застосовуються до даного набору об'єктів «користувач» в AD і накладаються на цих користувачів незалежно від того, з яких систем вони реєструються.

Отже, ми вирішили, до яких об'єктів будуть застосовуватися політики. Тепер потрібно активізувати політики і приступити до їх налаштування. Перш за все, запустимо консоль управління груповими політиками Group Policy Management Console (GPMC) і створимо новий об'єкт GPO програмних обмежень.

Правою кнопкою миші на новоствореному GPO всередині контейнера Group Policy Objects консолі GPMC і в меню виберіть пункт Edit. На екрані з'явиться вікно редактора GPE з виділенням цікавить нас об'єкта GPO.

Перейдіть на вузол Software Restriction Policies в розділ Computer Configuration, щоб визначати політики стосовно комп'ютерів, або в розділ User Configurations - для визначення політик «на користувача». Правою кнопкою миші на вузлі Software Restriction Policies і в контекстному меню виберіть пункт New Software Restriction Policies. На правій панелі екрана з'явиться група папок і елементів політик (див. Екран 1). Можливо, ви отримаєте повідомлення про те, що політики вступлять в силу тільки після перезавантаження системи (це вірно для Windows Server 2008). Дане повідомлення не повною мірою відповідає дійсності, так як для того, щоб почати завантаження цих політик, не потрібно перезавантаження ні клієнта, ні сервера.

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

Двічі клацніть на папці Security Levels, розташованої на правій панелі редактора GPE. У системах Windows 2003 і Windows XP ця папка містить два вузли: Disallowed і Unrestricted. У Windows Server і Vista додається третій вузол - Basic User. Вузол Unrestricted (режим чорного списку) має невелику позначку, яка вказує на те, що даний режим застосовується за умовчанням. Щоб перейти в режим білого списку, двічі клацніть на вузлі Disallowed і натисніть кнопку Set as Default. На екрані з'явиться запит на підтвердження; підтвердіть ваш вибір і закрийте діалогове вікно, щоб продовжити роботу.

Basic User - це функція, додана в версії Windows Vista. У режимі Basic User у користувачів, які є адміністраторами своїх робочих станцій або доменів AD, з усіх додатків, які виконуються на їх системах, видаляються адміністративні маркери. По суті, вони позбавляються можливості виконувати будь-які програми з повноваженнями адміністраторів. Непомітно для користувачів функція SRP модифікує маркер процесу в кожному додатку, запущеному користувачем, додаючи інструкцію про скасування дозволу представникам таких груп безпеки:

• адміністратори;
• адміністратори сертифікатів;
• адміністратори схеми;
• адміністратори підприємства;
• адміністратори доменів.

Basic User можна уявити як механізм для виявлення ситуацій, коли адміністратори дійсно виступають в ролі адміністраторів. Можливо, у вашій організації є ряд комп'ютерів, що містять конфіденційні дані про клієнтів, і адміністраторам час від часу доводиться реєструватися на цих системах. У таких випадках ви можете встановити режим Basic User як режим за замовчуванням для згаданих систем, щоб користувачі не могли виконувати додатки з розширеними повноваженнями.

Вказівка параметрів SRP

Прийшов час встановити деякі загальні параметри. Якщо ви перейдете назад в папку верхнього рівня всередині даної політики, то побачите три вузла: Enforcement, Designated File Types і Trusted Publishers. Двічі клацніть на вузлі Enforcement. На екрані з'явиться діалогове вікно Enforcement Properties, показане на екрані 2. Це вікно дає можливість вибрати режим SRP при обробці її правил.

Перший параметр діалогового вікна дозволяє вибрати одну з двох можливостей: SRP реалізує правила стосовно додатків або до додатків і всім залежним від них бібліотекам DLL. За замовчуванням (перш за все, з міркувань швидкодії) використовується варіант з реалізацією правил тільки стосовно до викликає додатком. Однак, якщо у вас викликають занепокоєння файли DLL як можливі канали для атаки, можете поширити дію правил і на них, вибравши пункт All Software Files.

Параметр Enforcement Properties дозволяє вказувати, чи застосовувати політики SRP, перераховані в даному об'єкті GPO, до всіх користувачів взагалі, або до всіх, за винятком членів локальної групи адміністраторів. За замовчуванням адміністратори виключаються, а значить, не піддаються заданим обмеженням. Використовуйте цей режим за замовчуванням, якщо тільки не виникне потреба в тому, щоб до адміністраторів застосовувалися ті ж правила, що і до звичайних користувачів.

Визначте розширення файлів, які SRP розглядатиме як виконувані типи в вузлі Designated File Types. Спочатку ви побачите очікувані розширення файлів: .exe, .bat, .msi і т. Д. До цього списку можна додавати розширення інших типів файлів, якими належить управляти. Але якщо, наприклад, ви вже створюєте правило, що блокує роботу програми Microsoft Excel, включати в список розширення .xls не має сенсу.

Третій параметр вузла Software Restriction Policies - це параметр Trusted Publishers. Даний вузол дає можливість управляти характеристиками елементів управління ActiveX. Ви можете надати або не надавати користувачам право визначати видавця того чи іншого елемента управління ActiveX як надійного. Якщо таке право отримують звичайні користувачі, ви в результаті позбавляєте себе можливості відслідковувати, які видавці елементів ActiveX заслуговують довіри.

Крім того, параметр Trusted Publishers дозволяє визначати, чи повинна система Windows перевіряти, чи не відкликані чи сертифікати і чи дійсні позначки часу перед тим, як встановлювати елемент керування ActiveX, підписаний тим чи іншим користувачем. Якщо видавці ваших законних елементів управління ActiveX сумлінно підтримують актуальність своїх сертифікатів, задіяти цей параметр, мабуть, не варто.

Типи правил для управління виконанням програм

Тепер давайте заглянемо в саме серце SRP - а саме розглянемо правила, що регулюють виконання реального додатки. У SRP передбачено чотири типи правил:

• правила для хешу;
• правила для шляху;
• правила сертифіката;
• правила для мережевої зони.

Ймовірно, в 99% випадків ви будете використовувати в своїх цілях правила для хешу або правила для шляху. Правила сертифіката дають можливість санкціонувати або обмежувати виконання в залежності від того, чи підписаний код тим чи іншим видавцем. На жаль, багато творців легітимних додатків не підписують свій код, тому сфера застосування даного правила обмежена.

Правила для мережевої зони дозволяють адміністратору контролювати використання файлів Windows Installer; по суті, мова йде про можливість визначення, з якої зони браузера Internet Explorer повинні надходити файли .msi, які може виконувати користувач. На жаль, як правило, шкідливі програми не надходять до нас з зручними файлами Windows Installer, тому дана функція має досить обмежене застосування. Але якщо з якоїсь причини у вас виникне потреба обмежити можливість установки файлів .msi, це правило стане вам у пригоді.

Ми ще не торкалися правил для хешу і правил для шляху. Давайте подивимося, як вони працюють і як ми можемо використовувати їх.

Правила для хешу

Як вже говорилося, при використанні білих списків блокується запуск всіх здійсненних файлів, крім тих, які отримують явну санкцію на виконання. Існує два способи формування правил, які санкціонують запуск здійсненних файлів. Правило для хешу - це спосіб ідентифікації додатка за унікальним хешу, згенеровані засобами SRP. Спочатку в якості застосовуваного за замовчуванням алгоритму хешування фахівці Microsoft використовували алгоритм MD5, але у версії Windows Vista переключилися на більш новий алгоритм SHA-256. При створенні правила хешу в середовищах Server 2008 або Windows Vista операційна система зберігає обидві версії хешу для забезпечення зворотної сумісності.

При використанні правил для хешу адміністратор отримує можливість керувати програмами, незважаючи на всі хитрощі, що вживаються користувачами для обходу обмежень. Це означає, що правила для хешу, мабуть, найбільш корисні в сценаріях з чорними списками. Уявімо собі таку ситуацію. Ви хочете, щоб користувачі не могли запускати гру Solitaire (sol.exe) в середовищі Windows XP. Вам потрібно в редакторі GPE створити нове правило для хешу. Правою кнопкою миші на вузлі Additional Rules, розташованому на правій панелі, і в меню, що розкрилося виберіть пункт New Hash Rule. У діалоговому вікні New Hash Rule натисніть кнопку Browse і виберіть елемент C: WindowsSystem32sol.exe. Після цього клацніть ОК. Як показано на екрані 3, тепер можна для рівня безпеки викликати настройку Disallowed, щоб користувачі не могли запускати цю програму.

Тепер, навіть якщо користувачі перенесуть здійсненний файл sol.exe в інше місце або дадуть йому інше ім'я, правило для хешу забезпечить дотримання накладеного вами обмеження. Правила для хешу корисні при використанні з додатками, які змінюються не дуже часто; потрібно мати на увазі, що, якщо додаток змінюється внаслідок застосування оновлення або програмного виправлення, змінюється і значення хешу додатки, так що вам доведеться знову формулювати правило для хешу. Зазначу, що при вказівці виконуваного файлу, який слід контролювати, потрібно використовувати ту версію програми, яка встановлена ​​на цільових системах. Так, якщо ви хочете обмежити використання гри Solitaire на системах Windows XP SP3, знайдіть в списку відповідну версію виконуваного файлу, що виконується на системі Windows XP SP3, і нехай SRP обчислює хеш на її основі.

Правила для шляху

Правила для шляху - найкорисніші та потужні з усіх чотирьох типів правил SRP. Використовуючи їх, ви можете вказати шлях до файлів з метою дозволити або заборонити їх виконання (або перевести систему в режим Basic User), і всі програми, розташовані за цією адресою, переводяться під управління SRP. Створити правило для шляху просто, достатньо в редакторі GPE правою кнопкою миші клацнути на папці Additional Rules і в меню, що розкрилося вибрати пункт New Path Rule, а потім ввести шлях до каталогу, де потрібно створити правило.

Головне достоїнство правил для шляху полягає в тому, що вони можуть приймати безліч форм. Правило для шляху може бути вельми простим, наприклад:

Sol.exe or Sol. * Or S *. *

Це правило позбавляє користувачів можливості виконання файлу sol.exe, здійсненних файлів з ім'ям Sol і будь-якими файловими розширеннями, а також всіх, хто знаходиться в папці Designated File Types програм, назви яких починаються з літери s. Зрозуміло, правило для шляху може містити і фактичний шлях до файлу, наприклад C: Program FilesMicrosoft Office. У цьому прикладі правило регулюватиме використання всіх додатків, розміщених всередині папки Microsoft Office, включаючи дочірні папки. У правилах для шляху можна також вказувати шляхи відповідно до положень угоди про іменування UNC. Так, ви можете вказати, що виконуватися будуть тільки програми, які містяться за адресою MyServerApps. Зазначу, що правило для шляху MyServerApps дозволяється в будь-яке представлення цього ж шляху (наприклад, 10.5.1.1Apps, або P :, де P вказує на MyServerApps).

Нарешті - і, можливо, це найефективніший спосіб роботи з правилами - ви можете створювати правила шляху для реєстру. Ми не завжди знаємо, де саме встановлено ту чи іншу програму. Наприклад, за замовчуванням програма Yahoo! Messenger встановлюється в каталозі C: ​​Program FilesYahoo! Messenger, але користувач міг зберегти її в іншому місці. Як створити правило, яке застосовується до додатка незалежно від того, в якому каталозі воно встановлено? Ось тут-то нам на допомогу і приходять правила шляхи реєстру.

Правило шляхи реєстру - це посилання на адресу в реєстрі, який вказує на шлях в файлової системі. У нашому прикладі при установці додатка Messenger це додаток створює в розділі HKEY_LOCAL_MACHINESOFTWAREYahoo Essentials параметр реєстру MainDir, який містить шлях до каталогу, де розміщується Messenger. Правило шляхи реєстру створюється для того, щоб додаток Yahoo! Messenger не могло запускатися, т. Е. З тією ж метою, з якою створюються інші правила для шляху. На екрані 4 показано, як буде виглядати таке правило.

Зверніть увагу, що вводити потрібно весь шлях реєстру аж до значення, що містить шлях до файлу, на який ви хочете накласти обмеження; при цьому шлях реєстру повинен бути укладений в символи відсотка (%). У реєстрі це значення відображається як C: Program FilesYahoo !. При оцінці правила для шляху SRP переглядає реєстр в пошуках шляху до додатка Messenger і управляє всіма додатками, розташованими на цьому шляху.

Ще одна чудова сфера! Застосування правил шляхи реєстру - Блокування Виконання коду, Який користувач завантажено у виде прієднаного файлу або с помощью Web-браузера. Приклад: ви хочете, щоб користувачі не виконували додатки всередині браузера Internet Explorer без попереднього збереження відповідного файлу. Коли користувач натискає кнопку Open в діалоговому вікні завантаження, IE використовує шлях до тимчасового каталогу завантаження в розділі реєстру HKEY_LOCAL_MACHINESOFTWAREMicrosoft WindowsCurrentVersionInternet SettingsCachePathsDirectory. Якщо ви створите правило шляхи реєстру до даного каталогу і присвоїти йому значення Disallowed, жоден з типів програм, що знаходяться в папці Designated File Types, не зможе виконуватися з цього запрошення Open.

Правила для шляху, створені Microsoft

Коли ви будете вперше створювати нову політику SRP всередині об'єкта GPO, то помітите, що операційна система Windows автоматично створює правила шляхи реєстру на вузлі Additional Rules всередині редактора GPE. Ці заздалегідь створені правила шляхи реєстру визначають всі програми всередині каталогів C: Windows, а також C: Program Files (або по всьому маршруту на шляху до цих добре відомим папок) як що не піддаються обмеженням. Думаю, фахівці Microsoft зробили це для того, щоб адміністратори, вперше складаючи білий список, не здійснювали ненавмисної помилки і не перешкоджали коректному виконанню компонентів операційної системи.

Проте вам все-таки краще не випускати з уваги ці заздалегідь складені правила, бо, якщо ви спробуєте створити справжній білий список, то навряд чи захочете дати санкцію на виконання всіх програм, які перебувають в каталогах C: Windows і C: Program Files. Якщо ви вирішите видалити ці заздалегідь задані правила, обов'язково проведіть ретельне тестування. Більш того, якщо ви хочете змінити їх, я рекомендую видаляти тільки правило Program Files і залишити без зміни правило C: Windows; таким чином ви виключіть можливість блокування додатків, які відіграють ключову роль у функціонуванні операційної системи.

Взаємодія політик SRP

Якщо ви визначаєте політики SRP в декількох об'єктах GPO, необхідно знати, як вони будуть взаємодіяти один з одним. Якщо говорити про загальні параметри (застосовується модель білий список або чорний список, які типи файлів використовуються, які настройки надійних видавців і т. Д.), Важливо мати на увазі, що фактично буде застосовуватися та настройка, яка обробляється останньої в процесі обробки груповий політики на клієнтській системі. Однак, по суті, відбувається злиття правил. Ситуація може виявитися досить заплутаною: наприклад, правило для шляху і правило для хешу можуть увійти в суперечність один з одним. В цьому випадку в силу вступає більш конкретне правило.

Розглянемо приклад. Припустимо, у нас є правило для хешу, що блокує запуск файлу C: Windows egedit.exe, і правило для шляху, що санкціонує виконання всіх програм, розміщених в каталозі C: ​​Windows. Застосовуватися буде правило для хешу: воно більш конкретно, бо вказує на певний файл. Таким чином, файл regedit.exe буде заблокований, навіть якщо всі інші файли каталогу C: Windows отримають санкцію на виконання. Головний висновок: намагайтеся уникати «накладення» правил при роботі з декількома GPO.

Включіть в арсенал SRP

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

Даррен Мар-Еліа ( [email protected] ) - редактор Windows IT Pro, технічний директор і засновник компанії SDM Software