Проект «Розробка та впровадження типових рішень щодо комплексної системи захисту інформації в АІС НАНУ»

У табл. 3 представлений приклад таблиці фільтрації трафіку за допомогою IPSec.

                               Таблиця 3

Правило 1 вирішує взаємодію із службою Server Resolution Service, необхідною для визначення встановлених екземплярів сервера. Якщо використовується описаний вище метод настройки клієнтських бібліотек, це правило можна видалити.

У правилі 2 вирішується взаємодія всіх користувачів з портом 1433, на якому працює загальнодоступний екземпляр сервера SQL.

Правило 3 вимагає встановлення з портом 2433 захищені з'єднання. Цей порт використовується екземпляром сервера, який є основою для Web-програми. З'єднання з ним можливо тільки з комп'ютерів, що успішно пройшли аутентифікацію IPSec і наділених правом Access this computer from network. В даному випадку це Web-сервер і робочі станції адміністраторів.

Правила 4,5 і 6 вирішують взаємодію з сервером по протоколах NetBIOS/CIFS. Дані протоколи використовуються мережевою бібліотекою Named Pipes. Якщо застосовується аутентифікація Kerberos або NTLMv2, ці правила можна виключити.

Правило 7 вирішує захищену взаємодію по протоколу RDP, використовуваному сервером терміналів.

Правило 8 дає можливість взаємодії з контролером домена для аутентифікації і застосування групових політик.

Шифрування  трафіку. Для шифрування трафіку сервера SQL можна задіювати протоколи IPSec і SSL v 3.0. У врізанні “IPSec або SSL v 3.0?” приводиться порівняння даних протоколів.

Для використання SSL, згідно рекомендаціям статті бази знань Microsoft KB276553, необхідно отримати сертифікат X.509v3, виданий для аутентифікації сервера на його доменне ім'я, і встановити його в локальне сховище комп'ютера. Після цього потрібно включити шифрування трафіку в мережевих утилітах сервера і перевірити з'єднання з боку клієнта.

Рядок настройки  з'єднання ODBC в цьому випадку виглядатиме  таким чином:

Driver=SQLServer;Server=ServerName;  
Network=DBNETLIB.DLL;Encrypt=YES

Можливе використання шифрування не на всіх клієнтських комп'ютерах. Для цього настройка Force Protocol Encryption включається не на сервері SQL, а в настройках клієнтської бібліотеки.

4.2. Захист  операційної системи

При підвищенні рівня захисту базової операційної  системи необхідно вирішити наступні завдання:

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

Настройка системних служб і прав користувачів. Microsoft SQL Server встановлюється і функціонує як декілька системних служб. Для кожного екземпляра бази даних створюється служба з ім'ям, утвореним по схемі MSSQL$<имя екземпляра>. Так само створюються екземпляри SQL Server Agent (SQLAgent$< ім'я екземпляра>), що відповідають за виконання періодичних завдань, таких як автоматична архівація, підтримка бази даних і так далі.

Крім того, для  сервера в цілому створюються  служби Microsoft Search (відповідає за індексування і пошук документів в тому випадку, якщо включена підтримка повнотекстового  пошуку) і DTS (служба, що відповідає за підтримку розподілених транзакцій).

Служба MSSQL може працювати в контексті облікового запису Local System або від імені облікового запису користувача (доменного або  локального). Дуже небажано застосовувати  для запуску служб обліковий  запис LocalSystem, як і будь-який інший обліковий запис з адміністративними повноваженнями. Це пов'язано з тим, що у разі компрометації сервера всі дії в системі проводитимуться від імені цього запису, тобто зловмисник працюватиме з адміністративними привілеями.

Рекомендується запускати служби від імені облікового запису (локальною або доменною), що має обмежені привілеї. Локальний обліковий запис доцільно використовувати, якщо в завдання сервера SQL Server не входить мережева взаємодія з іншими службами. У зворотному випадку застосовується доменний обліковий запис.

На сервері  бажано відключити служби, які для  роботи SQL Server не потрібні. Їх список приведений в табл. 4.

                                  Таблиця 4

Обліковому запису, від  імені якого працюють служби сервера, привласнюються наступні призначені для  користувача права і привілеї:

Act as part of operating system

Lock pages in memory

Bypass traverse checking

Log on as service

Increase quotas

Replace а process level token

Deny logon locally

Deny log on through Terminal Services

Заборона локальній  реєстрації в системі і з'єднання  за допомогою сервера терміналу  обмежують можливості зловмисника  у разі компрометації системи. Також необхідно видалити групу Domain Users у користувачів, що мають право Logon Locally.

Бажано встановлювати SQL Server на розділ, відмінний від розділу  з операційною системою. Це зменшить вплив сервера бази даних на операційну систему і полегшить настройку ряду параметрів безпеки.

Настройка дозволів файлової системи і реєстру. При настройці дозволів файлової системи із списків контролю доступу сервера необхідно видалити обліковий запис Everyone. Замість неї можна використовувати групу Users або Authenticated Users. Для нормального функціонування сервера необхідно встановити дозволу на каталоги файлової системи і розділи реєстру, описані в табл. 5. Запис в інші каталоги системи, включаючи кореневі розділи, повинен бути доступний тільки для адміністраторів і облікового запису System.

Таблиця 5

Каталог/розділ реєстру Користувач/група Дозволи Каталог сервера SQL (D:\Program Files\Microsoft SQL Server) Administrators System SQLserver Full Control Full Control Full Control Каталог баз даних (D:\SQLData) Administrators System SQLserver Full Control Full Control Full Control C:\WINNT\System32 Administrators System Authenticated Users Full Control Full Control Read & Exec HKLM\Software\Microsoft\MSSQLServer HKLM\Software\Microsoft\Windows NT\Current Version\Perflib System   SQLserver Full Control Query Value, Set Value, Create Subkey, Enumerate, Notify, Read Control HKLM\Software\Microsoft\ MSSQLServer\$InstanceName HKLM\Software\Microsoft\System\ CurrentControlset\Services\SQLSERVERAGENT HKLM\Software\Microsoft\System\ CurrentControlset\Services\MSSQLSERVER HKLM\Software\Microsoft\System\ CurrentControlset\Services\MSSQL$InstanceName System   SQLserver Full Control Query Value, Enumerate, Notify, Read Control

Для обмеження  можливостей зловмисника у разі компрометації сервера баз даних необхідно або видалити з системи, або встановити дозвіл SQLServer — Deny Full Access на системні утиліти, такі як: explorer.exe, regedit.exe, poledit.exe, taskman.exe, at.exe, cacls.exe, cmd.exe, finger.exe, ftp.exe, nbstat.exe, net.exe, net1.exe, netsh.exe, rcp.exe, regedt32.exe, regini.exe, regsvr32.exe, rexec.exe, rsh.exe, runas.exe, runonce.exe, svrmgr.exe, sysedit.exe, telnet.exe, tftp.exe, tracert.exe, usrmgr.exe, wscript.exe, xcopy.exe

Шифрування  баз даних. Для захисту файлів бази даних на фізичному рівні має сенс зашифрувати їх. У операційній системі Windows 2000/2003 передбачена можливість шифрування бази даних за допомогою шифруючої файлової системи. Encrypting File System — надбудова над NTFS, що дозволяє в прозорому для користувача режимі шифрувати і розшифровувати файли на жорсткому диску комп'ютера.

Для використання цієї можливості необхідно:

1. Налаштувати службу SQL Server на запуск від імені облікового запису користувача.
2. Увійти до системи, використовуючи даний обліковий запис.
3. Використовуючи “Провідник”, відкрити властивості теки Program Files\microsoft sql server\<имя экземпляра>\Data або інший, де збережені бази даних.
4. Встановити для каталогу атрибут (Properties — Advanced — Encrypt contents to secure data).

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

Шифрування  за допомогою Encrypting File System є ефективним засобом захисту даних, але тільки за умови дотримання всіх рекомендацій по її настройці. Зокрема, необхідно видаляти з системи секретний ключ агента відновлення. Також бажано видалити всі локальні облікові записи з бази користувачів сервера SQL Server (особливо це стосується локального адміністратора), оскільки при фізичному доступі паролі цих облікових записів легко можуть перепризначувати.

Для підвищення рівня захисту можна застосувати  шифрування LSA за допомогою утиліти Syskey. Краще всього використовувати  як ключ шифрування парольну фразу.

4.3. Захист компонентів бази даних

Першим етапом настройки безпеки SQL Server як програми є вибір використовуваної моделі аутентифікації. Рекомендується застосовувати метод Windows викладеними вище проблемами методу SQL Server (пересилка пароля в закодованому вигляді).

Потім необхідно  вирішити, чи будуть члени групи  локальних адміністраторів мати доступ до сервера бази даних з  привілеями системних адміністраторів. Автоматично створюваний серверний  обліковий запис Bultin/Administrators рекомендується видалити. Ця рекомендація зв'язана, перш за все, з обов'язковою присутністю в даній групі облікового запису локального адміністратора, чий пароль може бути вмить змінений у разі наявності у зловмисника фізичного доступу або підібраний по мережі. Після того, як зловмисник дістане доступ до системи від імені цього облікового запису, він зможе обійти всі захисні механізми, включаючи шифрування баз даних за допомогою EFS.

З обліковим  записом локального адміністратора зв'язані і інші проблеми, дізнатися  про яких докладніше можна із статті “Локальная угроза” опублікованою в Windows & .NET Magazine/RE №3 за 2003 рік. Перед видаленням облікового запису Bultin/Administrators необхідно створити серверний обліковий запис на основі доменної групи і привласнити їй роль System Administrator.

Наступним етапом є видалення стандартних баз  даних, що входять в дистрибутив  як приклади. До них відносяться  бази даних NorthWind і pubs. Дані бази містять  ряд помилок, мають слабкі дозволи і часто використовуються зловмисниками для атак.

Потім необхідно  заборонити виконання запитів типу AdHoc. Такі запити (OPENROWSET, OPENQUERY і OPENDATASOURCE) дозволяють серверу встановлювати  з'єднання із зовнішнім сервером і зберігати на нім свої дані. Вони дуже рідко використовуються в програмах, але можуть бути застосовані зловмисником для видаленого отримання інформації з баз даних сервера. Прикладом застосування подібної техніки є програма Data Thief, що використовує метод впровадження SQL-кода (SQL Injection) для виконання запитів AdHoc.

Для відключення  можливості виконання запитів AdHoc необхідно  встановити значення параметра системного реєстру DisallowAdhocAccess рівним 1 для кожної мережевої бібліотеки сервера. Нижче перераховані розділи реєстру, в яких розташовуються настройки мережевих бібліотек:

HKLM\Software\Microsoft\MSSQLServer\Providers\ MSDAORA; HKLM\Software\Microsoft\MSSQLServer\Providers\ ADSDSOObject; HKLM\Software\Microsoft\MSSQLServer\Providers\ DB2OLEDB; HKLM\Software\Microsoft\MSSQLServer\Providers\ MSIDXS; HKLM\Software\Microsoft\MSSQLServer\Providers\ MSQLImpProv; HKLM\Software\Microsoft\MSSQLServer\Providers\ MSSEARCHSQL; HKLM\Software\Microsoft\MSSQLServer\Providers\ MSDASQL.

Розширеними процедурами, що зберігаються, є програми на мовах низького рівня, що мають доступ до ресурсів операційної системи в контексті безпеки того облікового запису, від імені якого запущена служба SQL Server.

Зазвичай такі процедури розширюють функціональність бази даних, додаючи в неї, наприклад, можливість виконувати довільні команди операційної системи, можливість читання реєстру, відправки поштових повідомлень і так далі. Трапляється, що подібні процедури містять помилки (наприклад, впровадження коди в sp_msdropretry або переповнюванні буфера в ms_makewebtask), що може бути використане для підвищення привілеїв.

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

Список розширених процедур, що зберігаються, доступ до яких необхідно обмежувати, можна узяти  з рекомендацій по настройці безпеки  сервера SQL, наприклад, з рекомендацій центру SNAC NSA (http://www.compdoc.ru/go.php?http://www.nsa.gov/).

Виконання описаних настройок можна автоматизувати за допомогою сценаріїв на мові T-SQL. Приклад подібного сценарію наводиться на сервері http://www.compdoc.ru/go.php?http://www.sqlsecurity.com. Як завжди, перед застосуванням сценарію у виробничому середовищі його слід ретельно протестувати.

4.4. Аудит сервера  SQL Server

Існує декілька різних методів настройки аудиту в базах даних SQL Server. Кращим рішенням є використання комбінацій даних методів залежно від вирішуваних завдань. За умовчанням аудит на сервері не активізований.

Аудит аутентифікації сервера дозволяє відстежувати спроби аутентифікації на сервері SQL. Включити його можна через Enterprise Manager або шляхом модифікації параметра реєстру HKLM\Software\Microsoft\MSSQLServer\MSSQLServer\ Audit Level. Можливі значення 0...3.

Нульове значення параметра означає відключення  аудиту, 1 — запис вдалих спроб аутентифікації, 2 — невдалих. При значенні параметра 3 включається аудит всіх спроб реєстрації.

Події зберігаються в журналі Application операційної системи. Додаткові настройки дозволяють зберігати події в журналі  помилок SQL Server. Настройка даного типу аудиту припускає включення відстежування невдалих спроб аутентифікації (значення 2) з подальшим аналізом на предмет виявлення спроб несанкціонованого доступу або підбору паролів.

Інший тип аудиту відноситься до подій сервера  баз даних. Настроювати і відстежувати їх можна за допомогою утиліти SQL Profiler.

Включення будь-яка  з даних категорій подій аудиту приведе до збереження наступної  інформації про події: