1. Аналізуємо журнал безпеки Windows NT
2. Сеанси роботи користувачів
3. Доступ до об'єктів системи
4. Аудит виконуються завдань

2000 р

Аналізуємо журнал безпеки Windows NT

Журнал "Windows 2000 Magazine" , # 03/2000

Франклін Р. Сміт

Журнал безпеки Security Log може використовуватися для відстеження (аудиту) більшості дій користувачів в системі. Існує три основні категорії такого аудиту - це аудит сеансів роботи користувачів, аудит доступу до об'єктів системи і аудит виконуються завдань. Ці категорії дають основну інформацію при спостереженні за діями користувачів. Системна політика аудиту налаштовується в меню Policies-Audit-Audit Policy, що викликається з програми User Manager (див. Екран 1). Дане діалогове вікно дозволяє вибрати, які з семи категорій фіксувати в локальному журналі безпеки, а які ні.

Сеанси роботи користувачів

ЕКРАН 1. Налаштування аудиту системи.

Багато адміністратори переглядають журнал безпеки Windows NT і бачать події входу користувачів в систему і виходу з неї, однак часто не можуть правильно оцінити побачене. Тут слід звертати увагу на окремі параметри подій. Так, подія успішної реєстрації користувача в системі має номер (ID) 528 (див. Малюнок 1). При відмові в реєстрації користувача фіксується подія з іншим номером, який залежить від причини відмови. Повний список подій можна знайти в документі Microsoft "Опис подій аутентифікації" (див. http://support.microsoft.com/support/kb/articles/q174/0/74.asp ). Подія з номером 538 означає завершення сеансу, початок якого зафіксовано подією 528. Подія номер 528 має кілька дуже важливих додаткових параметрів. Ім'я користувача і домен визначають увійшов в систему користувача або те, чия обліковий запис була при цьому задіяна. Номер сеансу користувача Logon ID - це унікальний для системи код, який присвоюється кожному з активною розмовою роботи користувача з системою. Саме він буде записаний в подію завершення сеансу. Це дозволяє визначити загальний час роботи користувача при аналізі подій 528 і 538 з одним і тим же номером сеансу.

МАЛЮНОК 1. Подія номер 528.

Подія входу в систему також фіксує інформацію про тип входу Logon Type, т. Е. Те, як ви увійшли в систему. Тип входу 2 відповідає інтерактивного входу з консолі, наприклад, за допомогою монітора і клавіатури. Якщо користувач підключається до диска на іншому комп'ютері або як-небудь ще використовує мережевий ресурс, то виконується мережевий вхід з типом 3. Так, якщо був зафіксований тип входу 2, то хтось увійшов в систему з локальної консолі саме цього комп'ютера, а якщо тип 3, значить, хтось підключився до системи через мережу. Тип входу 5 фіксується при запуску служби із зазначенням конкретної облікового запису користувача. При використанні планувальника завдань виробництва незалежних компаній, наприклад Argent Queue Manager компанії Argent Software, система фіксує подія номер 528 з типом входу 4, що відповідає завданням на виконання командного файлу. При розблокуванні робочої станції записується подія з типом входу 7.

Фіксуються також всі невдалі спроби входу в систему Logon Failure. При цьому найчастіше записується системна подія 529, відповідне вказівкою невірного імені користувача або пароля - Unknown user name or bad password.

ЕКРАН 2. Вибір робочих станцій, з яких користувач має право увійти в систему.

Якщо обліковий запис користувача недоступна або заблокована, то спроба входу відкидається, і записується подія з номером відповідно 531 або 539. Подія номер 530 вказує, що користувач намагався увійти в систему в недозволене йому час або день тижня. Якщо обліковий запис користувача прострочена або застарів пароль, то фіксується відповідно подія 532 або 535. Якщо користувач обмежений входом лише на деякі робочі станції (див. Екран 2), а він намагається увійти з іншого комп'ютера, то запишеться подія номер 533. Можна обмежити права користувача на виконання певних типів входу в різні системи. Якщо користувач, якому заборонений доступ до якогось комп'ютера по мережі, все ж намагається звернутися до його ресурсу або реєстру, то він отримає відмову, а в журнал безпеки запишеться подія з номером 534. Таке ж подія буде зафіксовано при спробі користувача увійти в систему з консолі, якщо це йому заборонено. При спробі запустити службу з використанням облікового запису користувача, що не має права на запуск служб (права Logon as a service), також буде зафіксовано подія номер 534. Крім того, подія 534 запишеться і при спробі запуску завдання з виконанням командного файлу від імені облікового запису без права Logon as a batch job. При всіх інших відмовах в аутентифікації фіксується подія з номером 537, т. Е. An unexpected error occurred during logon - відмова з невідомої причини. Тип входу фіксується при всіх спробах входу в систему, незалежно від їх результату. Більш детальну інформацію можна знайти в документі Microsoft "Аудит аутентифікації користувачів" (див. http://support.microsoft.com/support/kb/articles/q174/0/73.asp ).

Аутентифікація в Windows NT має розподілену природу. Особливо яскраво це проявляється під час стеження за входом в систему і виходом з неї. Найчастіше аудит на робочої станції, що має обліковий запис в домені, сприймається вже як "вхід в домен", замість справжнього моменту входу в домен або ж входу на контролер домену з використанням облікового запису домену. Аудит на робочої станції означає лише реєстрацію на робочої станції. Але оскільки використовується обліковий запис домену, сама робоча станція не може аутентифицировать користувача. Робоча станція лише посилає відомості про користувача на контролер домену по протоколу NTLM (NT LAN Manager). Контролер домену перевіряє правильність пароля і відразу ж забуває про користувача. Сеанс роботи користувача підтримує сама робоча станція до самого моменту виходу з системи. Зрозуміло, саме робоча станція і записує в свій журнал системи безпеки інформацію про сесії користувача.

Для отримання загальної картини роботи користувачів домену часто можна обійтися без аналізу журналів безпеки на всіх без винятку робочих станціях. Справа в тому, що відразу ж після успішного входу користувача зазвичай автоматично з'єднує мережевих дисків, розташованих на файл-серверах. Саме журнали безпеки файл-серверів і слід переглядати, відстежуючи події входу в систему з типом 3. Через відсутність централізованої фіксації входів в систему для домену буває важко відстежити спроби несанкціонованого доступу. Однак, хоча контролери домену і не фіксують все невдалі спроби входу, вони записують все блокування облікового запису (подія номер 644), які є наслідком декількох безуспішних спроб входу поспіль. Детальніше про блокування облікових записів розказано в документі Microsoft "Події при блокування облікових записів зберігаються в журналі безпеки контролера домену" (див. http://support.microsoft.com/support/kb/articles/q182/9/18.asp ).

Необхідно здійснювати контроль за використанням локальних облікових записів на окремих системах. Вхідні в домен робочі станції і звичайні сервери аутентифицируют користувачів на контролерах доменів, а також ведуть власні локальні бази користувачів (SAM). І користувачі, і зломщики можуть задіяти ці локальні облікові записи, щоб спробувати увійти в систему локально або через мережу. У всіх системах існує вбудована адміністративна обліковий запис Administrator. Про те, як запобігти небажаним спроби її використання, розказано в березневому номері Windows NT Magazine / RE в статті Франкліна Р. Сміта "Захистимо права адміністратора!".

Для ефективного спостереження за сеансами роботи користувачів потрібно добре знати, що і де перевіряти. Для відстеження входу в систему в першу чергу слід переглядати журнали безпеки на робочих станціях і простих серверах і шукати в них події з номерами 528 і 538. Можливі спроби незаконного проникнення в систему відслідковуються серед подій з номерами від 529 до 537, а також 539 на всіх потенційно доступних для нападу комп'ютерах.

Доступ до об'єктів системи

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

Аудит доступу до об'єктів ведеться в журналі подій, а не в журналі транзакцій. Тому Windows NT не фіксує, що саме зробив користувач з об'єктом, а вказує лише тип доступу до даного об'єкта. Так, наприклад, можна простежити, що користувач Іванов відкрив файл Зарплата.xls для читання, записи, виконання і видалення, однак зовсім неможливо з'ясувати, чи вніс він якісь зміни, а якщо так, то які саме. До того ж при аудиті доступу до об'єктів в журнал може бути записано невиправдано багато подій. Так, при активізації подвійним клацанням текстового файлу з програми Windows Explorer відбувається запуск програми WordPad. При цьому фіксується більше 20 подій, пов'язаних з доступом до даного файлу і до каталогу, де він знаходиться.

Аудит об'єктів зазвичай використовується стосовно до звичайних додатків, які працюють з окремими файлами, наприклад до додатків з комплекту Microsoft Office. Спеціальні клієнт-серверні додатки, такі, як SAP, працюють з таблицями, розташованими в декількох великих файлах бази даних SQL Server. Аудит таких файлів зазвичай зводиться до запису однієї події під час запуску інформаційної служби і одного - при її зупинці. При цьому не залишається відомостей про те, який користувач виконував ті чи інші транзакції або в яких таблицях він міняв дані. Цю інформацію можуть зберігати лише самі додатки. Зате аудит таких монолітних файлів допомагає з'ясувати, чи не намагався хтось замінити файли бази даних в той момент, коли SQL Server був зупинений. Це цілком можливо, а перезапущена прикладна служба не здатна помітити підміну.

МАЛЮНОК 2. Подія номер 560.

Основні дві події аудиту доступу до об'єктів: object opened і handle closed. Перше фіксує відкриття об'єкта (номер 560), а друге - його закриття (подія 562). Це взаємодоповнюючі один одного події, подібні до подій входу і виходу з системи. Успішне подія номер 560 (див. Малюнок 2) записує інформацію про відкрите об'єкті, а також ім'я користувача і назву програми, яка скористалася об'єктом, тип доступу і дескриптор Handle ID.

Handle ID є унікальним кодом для контролю операційної системи за кожним об'єктом. Він нагадує описаний вище номер сесії користувача. Знайшовши пару подій відкриття і закриття (560 і 562) з одним і тим же значенням Handle ID, можна з'ясувати час роботи користувача з даним об'єктом. Разом з цим дескриптором подія номер 560 записує і номер сесії користувача (див. Малюнок 2), що дозволяє з'ясувати, в який саме сесії той звертався до об'єкта.

Події зберігають інформацію про двох користувачів - про основне і про клієнта. При відкритті файлу на локальному комп'ютері за допомогою звичайного застосування, такого, як Microsoft Word, істотна тільки інформація про основне користувача. Однак при доступі до об'єкта з клієнт-серверних додатків, які розмежовують доступ до даних на основі бази користувачів системи, фіксуються обидва типи користувачів: основний - відповідає облікового запису клієнт-серверного додатка, а клієнтський - відповідає користувачеві, від імені якого працює сервер. Типовим прикладом є доступ до файлових ресурсів сервера. Так, при доступі до файлу на іншому комп'ютері через мережу служба Workstation звертається до файлу комп'ютера з'єднується зі службою Server комп'ютера з наданих ресурсом, при цьому відбувається тип 3 входу в систему. Перед обробкою будь-якого запиту сервер аутентифікує користувача і записує події доступу до об'єкта з зазначенням основного користувача і клієнта. У цьому випадку основним користувачем буде SYSTEM, оскільки саме під цією обліковим записом запускається служба Server. Інформація про клієнта відповідає імені користувача, яке застосовувалося для доступу до ресурсу; зазвичай це одна з облікових записів користувачів домену.

Поле типу доступу Accesses в подію номер 560 зберігає вид використаного методу доступу до об'єкта. Значення цього поля відповідають можливим типам повноважень доступу до об'єктів ACL. Так, при редагуванні текстового файлу в редакторі WordPad Windows NT фіксує подія 560 з типом доступу для читання ReadData, записи WriteData і додавання AppendData.

Подія 560 також зберігає інформацію про номер процесу Process ID. Цей номер дозволяє визначити, яка саме програма звернулася до об'єкта. Наприклад, можна точно з'ясувати, чи використовувалася при редагуванні текстового файлу додаток Word, WordPad або Notepad. Однак це за умови, що редагувався локальний файл. Якщо ж користувач звертався до об'єкта через мережу, фіксується номер процесу, відповідний серверного додатку.

Третім важливим подією в категорії аудиту об'єктів є подія номер 564, видалення об'єкта - object deleted. Воно записує тільки дескриптор і номер процесу. Щоб розібратися, який саме об'єкт і хто з користувачів був видалений, необхідно відшукати за значенням Handle ID відповідна подія 560 відкриття об'єкта. У події номер 560 є вся необхідна інформація про користувача, так що подія 564 видалення об'єкта слід пов'язувати саме з ним.

Аудит і аналіз доступу до об'єктів представляється дуже потужним засобом. Однак аналіз - процес досить трудомісткий, а аудит може знизити швидкодію системи при активному використанні і великій кількості реєстрованих об'єктів. Не слід зловживати цим типом аудиту. Крім захисту особливо важливих ресурсів він часто використовується службою безпеки підприємства для збору відомостей про неблагонадійних користувачів. Відомі випадки, коли аудит ставилося на спеціально підкидання користувачам файли типу Зарплата.xls тільки з метою виявити потенційних зловмисників. Подібний підхід вимагає суворої опрацювання. Ну і, звичайно, не треба забувати включати аудит доступу до об'єктів системи в додатку User Manager на тій системі, де ці об'єкти знаходяться, а не тільки на робочій станції користувача.

Аудит виконуються завдань

МАЛЮНОК 3. Подія номер 592.

Ця категорія аудиту в додатку User Manager називається аудитом виконуються завдань - process tracking, а в документації по Windows NT і в програмі Event Viewer використовується термін "детальний аудит" - detailed tracking. Як би там не було, дана категорія дозволяє простежити за тим, які саме програми були запущені на робочої станції і які програми виконувалися на сервері. У цій категорії також існують два основних події - створення нового процесу, подія номер 592, і завершення процесу, подія номер 593. Знайшовши пару подій 592 і 593, що мають один і той же номер процесу Process ID, можна визначити загальний час роботи того чи іншого додатки. Поле назви виконавчого модуля Image File Name зберігає ім'я файлу, відповідного додатку. Так, при запуску WordPad це поле буде містити значення WORDPAD.EXE (див. Малюнок 3). На жаль, подія не записує повний шлях, і судити про точному розміщенні виконуваного файлу не можна. В поле імені користувача User Name зберігається інформація про те, хто запустив додаток. Крім того, за значенням поля номера сеансу Logon ID користувача можна відшукати відповідне подія номер 528 і з'ясувати всі подробиці про сеанс, в якому запускалося додаток. За допомогою поля номера запустив додаток процесу Creator Process ID можна знайти відповідне подія номер 592, з якого з'ясувати, яка програма ініціювала запуск нового процесу.

Аудит виконуються завдань може виявитися дуже корисним на робочих станціях, особливо при вивченні активності тих чи інших користувачів. Якщо при цьому задіяти аудит доступу до об'єктів на серверах, то можна побудувати досить чітку картину роботи користувачів.

Аудит сеансів роботи користувачів, аудит доступу до об'єктів системи і аудит виконуються завдань є трьома найважливішими категоріями в журналі безпеки Windows NT. Можна пов'язати сеанси роботи користувачів, процеси і доступ до об'єктів і побудувати точну картину діяльності користувачів (див. малюнок 4 ). На жаль, Event Viewer не здатний фільтрувати події за значеннями їх параметрів, так що використовувати номери Logon ID, Process ID і Handle ID вельми важко. Однак можна застосувати функцію пошуку за значенням параметра і вручну скласти необхідні ланцюжка подій. Можна також скористатися іншими програмами обробки журналу безпеки Windows NT, які дозволяють фільтрувати події за різними критеріями.

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