
- •Завдання
- •1 Огляд об’єкту дослідження
- •1.1 Опис предметної області
- •1.2 Постановка завдання
- •2 Монітор файлової системи Process Monitor
- •2.1 Опис утиліти
- •2.2 Практичне застосування Process Monitor
- •3 Аудит безпеки в ос Windows та Linux
- •3.1 Загальні поняття
- •3.2 Управління аудитом в ос Windows
- •3.3 Управління аудитом в ос Linux
- •Висновки
- •Список литератури
3 Аудит безпеки в ос Windows та Linux
3.1 Загальні поняття
Аудит - це один з основних засобів захисту ОС. Аудит дозволяє відстежувати і реєструвати події, пов'язані з безпекою. Прикладами подій для аудиту можна назвати доступ до файлу, вхід в систему або зміна системної конфігурації.
Журнал безпеки являє собою базу даних або файл, у якому реєструються події, пов'язані з безпекою системи.
Завдяки системі аудиту, адміністратор може дізнатися, хто, яким чином і коли скористався (або намагався скористатися, але отримав відмову в доступі) цікавими для нього ресурсами.
Налаштування засобів аудиту дозволяє вибрати типи подій, що підлягають реєстрації, і визначити, які саме параметри будуть реєструватися.
Найбільш загальними типами подій для аудиту безпеки є:
доступ до файлів і каталогів;
управління обліковими записами користувачів і груп;
вхід користувачів в систему і вихід з неї.
Як правило, фіксуються наступні параметри, що стосуються дій, що здійснюються користувачами:
виконану дію;
ідентифікатори користувачів і груп, які виконали дію;
дата і час виконання.
Аудит приводить до додаткового навантаження на систему, тому необхідно реєструвати лише події, дійсно представляють значення з точки зору безпеки.
3.2 Управління аудитом в ос Windows
Політика аудиту
Перед виконанням аудиту необхідно вибрати політику аудиту. Політика аудиту вказує типи подій, які будуть реєструватися в журналі безпеки. При першій установці Windows XP SP2 всі категорії аудиту вимкнені. Включаючи аудит різних категорій подій, можна створювати політику аудиту, що задовольняє необхідним вимогам.
Налаштування політик аудиту доступна в оснащенні Групова політика. Існують наступні категорії аудиту:
Аудит подій входу в систему відстежує події, пов'язані з входом користувача у систему і виходом з неї;
Аудит управління обліковими записами відстежує всі події, пов'язані з управлінням обліковими записами. Записи аудиту з'являються при створенні, зміні або видаленні облікових записів користувача або групи;
Аудит доступу до служби каталогів відстежує події доступу до каталогу Active Directory. Записи аудиту створюються кожен раз при доступі користувачів або комп'ютерів до каталогу;
Аудит входу в систему відстежує події входу в систему або виходу з неї, а також вилучені мережеві підключення;
Аудит доступу до об'єктів відстежує використання системних ресурсів файлами, каталогами, загальними ресурсами, і об'єктами Active Directory;
Аудит зміни політики відстежує зміни політик призначення прав користувачів, політик аудиту або політик довірчих відносин;
Аудит використання привілеїв відстежує кожну спробу застосування користувачем наданого йому права або привілеї,
Аудит відстеження процесів відстежує системні процеси і ресурси, використовувані ними,
Аудит системних подій відстежує події включення, перезавантаження або виключення комп'ютера, а також події, що впливають на системну безпеку або відбивані в журналі безпеки.
Розглянемо більш докладно політики які безпосередньо стосуються безпеки файлової системи.
Аудит доступу до служби каталогів
Категорія Аудит доступу до служби каталогів забезпечує низькорівневий аудит об'єктів ActiveDirectory (AD) та їх властивостей. Оскільки дана категорія має безпосереднє відношення до AD, то активувати аудит подібних подій на системах, які не є контролерами домену, не має ні найменшого сенсу.
Аудит доступу до об'єктів
Сам по собі цей параметр політики не запускає аудиту яких-небудь подій. Параметр Аудит доступу до об'єктів визначає необхідність аудиту подій доступу до об'єкта (наприклад до файлу, папки, розділу реєстру або принтеру), для якого заданий системний список управління доступом (SACL).
System Access-Control List (SACL) - список, схожий на ACL, але що відповідає не за дозвіл або заборону на доступ, а за аудит (протоколювання в журналі безпеки) успішних і безуспішних спроб доступу до об'єкта. SACL складається із записів управління доступом. Кожен запис управління доступом включає відомості трьох типів:
учасник безпеки (користувач, комп'ютер або група), для якого буде виконуватися аудит;
певний тип доступу, для якого буде виконуватися аудит (маска доступу);
прапор, який вказує на необхідність аудиту подій збою доступу, успішного доступу або того й іншого виду подій.
Якщо параметр Аудит доступу до об'єктів налаштований для реєстрації значень Успіх, запис аудиту створюється кожного разу, коли користувач успішно отримує доступ до об'єкту з вказаним системним списком керування доступом. Якщо цей параметр налаштований для реєстрації значень Відмова, запис аудиту створюється кожного разу, коли користувач безуспішно намагається отримати доступ до об'єкта з вказаним системним списком керування доступом.
При налаштуванні системних списків управління доступом організації повинні визначати тільки ті дії, які необхідно включити. Наприклад, може знадобитися включити параметр Аудит запису і додавання даних для EXE-файлів, щоб відслідковувати їх зміну або заміну, так як віруси, «черв'яки» і «троянські коні» зазвичай впливають на EXE-файли. Крім того, може знадобитися відстеження доступу до конфіденційних документів і їх зміни.
В принципі за допомогою категорії Аудит доступу до об'єктів можна стежити за доступом до файлів, папок, принтерів, розділами реєстру та системних служб, але в більшості випадків дана категорія використовується для відстеження доступу до файлів і папок. Як тільки буде включений аудит по даній категорії, в журналі безпеки відразу ж відобразиться деяку кількість подій, що стосуються доступу до об'єктів в базі безпеки SAM. Однак будь-яких інших подій, пов'язаних з доступом до файлів або іншим об'єктам, ви тут не побачите, оскільки кожен об'єкт має свої налаштування параметрів аудиту, а за замовчуванням майже у всіх об'єктів аудит відключений. Це правильна практика, оскільки, якщо в системі буде включений аудит спроб доступу до кожного файлу або об'єкта, то дана система до своєї повної зупинки буде займатися тільки обробкою цих подій, а її журнал безпеки швидко переповниться, незалежно від призначеного йому об'єму. Рекомендується застосовувати цю категорію лише до критично важливих файлів, дійсно вимагає механізмів стеження за доступом до них.
Події аудиту
Як уже згадувалося раніше, Windows XP реєструє в журналах відбуваються події, які відслідковуються політикою аудиту. Користуючись інформацією журналів подій, можна отримати відомості про неполадки апаратного та програмного забезпечення, а також спостерігати за подіями безпеки Windows. Управляти і переглядати вміст журналів подій можна за допомогою утиліти Перегляд подій (Event Viewer).Windows XP записує події в три журнали:
Системний журнал (system log) містить повідомлення про помилки, попередження і іншу інформацію, витікаючу від операційної системи і компонентів сторонніх виробників. Список подій, що реєструються в цьому журналі, зумовлений операційною системою і компонентами сторонніх виробників і не може бути змінений користувачем. Журнал знаходиться в файлі Sysevent.evt.
Журнал безпеки (Security Log) містить інформацію про успішні і невдалі спроби виконання дій, що реєструються засобами аудиту. Події, які реєструються в цьому журналі, визначаються заданою вами стратегією аудиту. Журнал знаходиться в файлі Secevent.evt.
Журнал додатків (Application Log) містить повідомлення про помилки, попередження і іншу інформацію, що видається різними додатками. Список подій, що реєструються в цьому журналі, визначається розробниками додатків. Журнал знаходиться в файлі Appevent.evt.
Всі журнали розміщені в папці %Systemroot%\System32\Config. Журнали подій можна переглядати з будь-якого комп'ютера локальної мережі, за наявності прав адміністратора на комп'ютері, де розташований журнал. Нас буде цікавити насамперед Журнал безпеки, тому саме в ньому реєструються події аудиту безпеки.
У таблиці 1 наведені основні події безпеки, які реєструються в журналі безпеки, якщо задана політика аудиту подій доступу до об'єктів.
Таблиця 1
Код події |
Опис події |
560 |
Надано доступ до існуючого об'єкту. |
562 |
Закрито дескриптор об'єкту. |
563 |
Виконана спроба відкрити об'єкт з метою його видалення. |
564 |
Вилучений захищений об'єкт. |
565 |
Наданий доступ до існуючого типу об'єкта. |
567 |
Використано дозвіл, пов'язане з дескриптором. Дескриптор створюється з певними дозволами (наприклад дозволами на читання і запис). При використанні дескриптора для кожного з використаних дозволів може бути створена запис аудиту. |
570 |
Клієнт спробував отримати доступ до об'єкта. Ця подія формується при кожній спробі виконання операції над об'єктом. |
У таблиці 2 наведені основні події безпеки, які реєструються в журналі безпеки, якщо задана політика аудиту подій зміни політики безпеки.
Таблиця 2
Код події |
Опис події |
608 |
Надано право користувача. |
609 |
Вилучено право користувача. |
612 |
Змінена політика аудиту. |
618 |
Змінена політика відновлення зашифрованих даних. |
621 |
Облікового запису надано доступ до системи. |
622 |
Для облікового запису заблокований доступ до системи. |
623 |
Політика аудиту задана для кожного користувача. |
Керування аудитом
Якщо політика аудиту не задана, визначити, що відбулося при інциденті в сфері безпеки, буде складно або неможливо. Якщо ж налаштувати параметри аудиту так, щоб події реєструвалися при багатьох санкціонованих діях, журнал безпеки може бути заповнений марними даними.
У мережах з мінімальним вимогам до безпеки піддавайте аудиту:
успішне використання ресурсів, тільки в тому випадку, якщо ця інформація вам необхідна для планування;
успішне використання важливої і конфіденційної інформації.
У мережах зі середніми вимогами до безпеки піддавайте аудиту:
успішне використання важливих ресурсів;
вдалі і невдалі спроби зміни стратегії безпеки і адміністративної політики;
успішне використання важливої і конфіденційної інформації.
У мережах з високими вимогами до безпеки піддавайте аудиту:• вдалі і невдалі спроби реєстрації користувачів;
вдале і невдале використання будь-яких ресурсів;
вдалі і невдалі спроби зміни стратегії безпеки і адміністративної політики.
Журнали збоїв часто виявляються більш інформативними, ніж журнали успішного виконання операцій, тому що збої зазвичай свідчать про помилки. Наприклад, успішний вхід користувача в систему зазвичай вважається нормальним розвитком подій. Якщо хтось безуспішно намагається кілька разів увійти в систему, це може бути ознакою використання чужих облікових даних. Події, що відбуваються на комп'ютері, реєструються в журналах подій.
Перед реалізацією політики аудиту в організації слід визначити способи збору, організації та аналізу даних. Від великого обсягу даних аудиту мало користі, якщо відсутній план їх використання. Крім того, аудит комп'ютерних мереж може негативно позначатися на продуктивності систем. Навіть якщо вплив певного поєднання параметрів на комп'ютер кінцевого користувача практично непомітно, на сервері з високим навантаженням воно може виявитися істотним. Таким чином, перед завданням нових параметрів аудиту в робочому середовищі слід перевірити, чи не погіршить це продуктивність систем.