Все про журнал безпеки Windows 2000, Windows, Операційні системи, статті

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


Контролювати виконання програм можна за допомогою категорії Audit process tracking (аудит запуску процесу) Windows 2000. Можуть нагоді і категорії аудиту дій операційної системи Audit privilege use (аудит використання привілеїв), Audit policy change (Аудит зміни політики) і Audit system events (аудит системних подій). Поряд з іншими категоріями аудиту, представленими в даній серії статей про журнал безпеки Windows 2000, ці події допоможуть зрозуміти, які дії робив зломщик, який намагався порушити цілісність мережі.


Audit process tracking


Audit process tracking не відстежує невдалих подій, але коли категорія налаштована на контроль успішних дій, то фіксуються два події: з ID 592 (створений новий процес) і з ID 593 (процес завершено). Категорія Audit process tracking вказана як Detailed tracking в списку Category оснащення Event Viewer консолі Microsoft Management Console
(MMC).


Коли користувач запускає виконуваний файл, такий, як Microsoft Excel, Windows 2000 реєструє подію з ID 592. Дана подія вказує, яка програма була запущена і коли. Приклад повідомлення про подію показаний на Екрані 1; поля Time, User та Image File Name вказують, що користувач Білл запустив Excel в 5 год 51 хв пополудні. Слід звернути увагу, що Windows 2000 реєструє повний шлях до виконуваному файлу, на відміну від NT, що реєструє тільки ім’я файлу.


Поле Logon ID відповідає ID реєстрації, який був призначений Біллу при вході в систему. Даний ідентифікатор дозволяє зв’язати подія створення процесу з подією успішної реєстрації з ID 528.


Починаючи новий процес, Windows 2000 присвоює йому унікальний номер, Process ID. Цей номер показаний в поле New Process ID події з ID 592. Зазвичай таким дією після запуску програми є відкриття користувачем цієї програми будь-якого файлу. У статті «Аудит доступу до об’єктів »(опублікованій у попередньому номері – прим. ред.) я зазначав, що в описі події з ID 560 також є поле Process ID, яке можна використовувати для ідентифікації пов’язаних подій з ID 560 і ID 592. Однак у події з ID 592 Windows 2000 реєструє інший ID процесу, ніж у події з ID 560 або будь-якому іншому. Подія з ID 592 відображає ID процесу як десятизначні числа, тоді як інші події (І закладка Processes діалогового вікна Task Manager) показують ID процесу як трьох-або чотиризначний число. За деякими відомостями, розробники Microsoft усунули це протиріччя в операційних системах Windows 2002 і Windows XP.


Для ідентифікації процесу, що запустив новий процес, можна скористатися полем Creator Process ID події з ID 592. Досить відшукати попереднє подія з ID 592 з ідентифікатором Process ID, збігається з полем Creator Process ID обраного події. Обидва поля події з ID 592 мають десятизначний формат.


У програмі Event Viewer немає фільтра для сортування подій журналу безпеки по ID реєстрації або ID процесу, але можна відшукувати події з конкретним ID. Щоб знайти події, що містять певні ID, слід відкрити оснастку Event Viewer, клацнути правою кнопкою миші на журналі Security і вибрати пункти View, Find. Потім потрібно ввести ідентифікатор у полі Description і клацнути на кнопці Find Next.


Коли користувач закриває додаток, Windows 2000 реєструє подію з ID 593. Подія з ID 593 розпорядженні полем Process ID, але, як зазначено вище, цей ідентифікатор не збігається з ID процесу відповідної події 592, зареєстрованого операційною системою, коли користувач відкрив прикладну програму.


Поряд з вирішенням проблеми відповідності Process ID, користувачам належить пов’язати події освіти процесів, доступу до об’єктів і реєстрації – з документом, з огляду на необхідність перевірки часу, коли користувач зареєструвався; додатки, відкритого користувачем; файлів та інших об’єктів, до яких користувач звертався з кожної програми. Знайти зв’язок між подіями неважко при роботі на автономному комп’ютері, де користувач реєструється, запускає програми і звертається до файлів тільки на одній системі. Але в реальній мережі завдання не настільки проста. Windows 2000 реєструє події освіти процесів на комп’ютері, що виконує програму (на локальній станції користувача), а події доступу до об’єктів реєструються на комп’ютері, на якому зберігається об’єкт. Наприклад, якщо користувач через мережу відкриває файл на файл-сервері FS1, то служба Server відкриває файл на FS1 від імені користувача. Тому неможливо безпосередньо ідентифікувати програми, за допомогою яких користувач відкрив файли, що зберігаються на віддаленому файл-сервері.


Наприклад, користувач реєструється на робочій станції, запускає Excel і редагує електронну таблицю, розташовану на файл-сервері. Windows 2000 реєструє подію з ID 592 в журналі безпеки робочої станції, а подія з ID 560 – в журналі безпеки сервера. Ідентифікатори процесів цих двох подій не збігаються (і не співпали б, навіть якби Windows 2000 використовувала один і той же ID процесу для обох подій). Необхідно відшукати подію з ID 592 в журналі безпеки робочої станції, відповідне події з ID 560 у журналі безпеки сервера.


Активізація на сервері категорії Audit process tracking не допоможе отримати додаткові відомості про додатки, які виконуються на робочій станції користувача. Однак завдяки подіям цієї категорії можна стежить за використанням серверних програм, таких, як Microsoft SQL Server і Microsoft Exchange Server, і будь-яких програм, виконуваних адміністраторами та операторами при локальній реєстрації на сервері. Активізація даної категорії створює навантаження на ресурси сервера, тому необхідно уважно стежити за її впливом на продуктивність.


Відстеження процедур реєстрації та використання процесів і об’єктів допоможе контролювати дії ймовірного зломщика. А спостерігаючи за спробами використання повноважень, можна вчасно помітити підозрілі дії. Подібні дії допомагає виявити категорія
Audit privilege use.


Audit privilege use


Категорія Audit privilege use відстежує успішні і невдалі спроби використання повноважень, наданих користувачеві (в статтях та документації Microsoft не вироблено єдиної термінології, і терміни privileges і rights використовуються як рівнозначні). Існує більше 34 повноважень: від потужних, таких, як Act as part of the operating system (працювати як частина операційної системи), до досить нешкідливих прав, як Bypass traverse checking (обійти перехресну перевірку). Після активізації категорії Audit privilege use в журналі безпеки починають реєструватися три події: з ID 577 (виклик привілейованої служби), ID 578 (привілейована операція з об’єктом) і ID 576 (Спеціальна привілей, надана нового облікового запису).


Коли користувач намагається застосувати повноваження, Windows 2000 реєструє подію з ID 577 або ID 578, в залежності від типу повноважень (Windows 2000 контролює одні повноваження по службам, а інші – по об’єктах). В обох випадках в поле Privileges вказується використане повноваження. Windows 2000 реєструє коротке ім’я повноваження, яке завжди починається з Se і закінчується на Privilege. Але ці короткі імена не можна побачити, оперуючи повноваженнями в оснащенні MMC Group Policy Editor (GPE). Замість них наводяться повні описи повноважень. Наприклад, на Екрані 2 показано подію з ID 577, зареєстроване операційною системою, коли я перевів годинник комп’ютера. Повноваження SeSystemtimePrivilege відповідає повноваженням Change the system time в редакторі GPE.


Якщо користувачеві дозволено застосовувати повноваження, то операційна система реєструє успішне подію з ID 577 або подія ID 578. Якщо користувач намагається виконати дію, не маючи відповідних прав, то Windows 2000 реєструє невдале подія. Для деяких повноважень поля Primary User Name і Primary Domain Name ідентифікують користувача, що викликав подію. Однак для повноважень, які використовує серверний процес, ці поля відповідають профілю даного комп’ютера. Відмітна ознака таких повноважень – збіг поля Primary User Name з полем Computer зі знаком «$» в кінці.


У таких випадках визначити користувача, застосував повноваження, можна за даними полів Client User Name і Client Domain. Поля Primary Logon ID і Client Logon ID відповідають полю Logon ID події з ID 528 або ID 540, зафіксованого операційною системою при реєстрації користувача.


Поле Process ID події з ID 578 ідентифікує процес, безпосередньо викликав подія. Наприклад, при перегляді журналу безпеки процес Services від імені адміністратора використовує повноваження Se-SecurityPrivilege (тобто Manage auditing and security log). Відповідний ідентифікатор процесу в події з ID 578 належить процесу Services.


Категорія Audit logon events містить спеціальні ідентифікатори подій для дій при реєстрації користувачів, тому за замовчуванням Windows 2000 не записує успішні і невдалі спроби застосування повноважень на реєстрацію. Ці повноваження – за винятком Access this computer from the network і Deny access to this computer from the network – починаються словами Logon as або Deny logon. Windows 2000 також не заносить в журнал інформацію про деякі інші повноваження – наприклад, SeBackupPrivilege (резервне копіювання файлів і каталогів) і SeRestorePrivilege (відновлення файлів і каталогів), – викликаються так часто, що вони швидко переповнили б журнал безпеки. Щоб система виконувала аудит використання цих повноважень, слід змінити параметр реєстру HKEY_LO-CAL_MACHINE \ SYSTEM \ CurrentControlSet \ Control \ Lsa: Set the FullPri-vilegeAuditing, що має тип REG_DWORD, і присвоїти йому значення 1.


Windows 2000 ніколи не реєструє використання повноважень SeAudit-Privilege (Generate security audits – генерувати перевірку безпеки), SeCreateTokenPrivilege (Create a token object – створити маркерний об’єкт), SeDebugPrivilege (Debug programs – налагодження програм), SeChangeNotify-Privilege (Bypass traverse checking – пропуск перевірки) і SeAssignPrimary-TokenPrivilege (Replace a process level token – змінити маркер рівня процесу). Але якщо реєструється користувач, що володіє одним або кількома з цих повноважень, то Windows 2000 записує в журнал подію з ID 576 (нового облікового запису призначені спеціальні повноваження; дана подія зазвичай близько слід за успішним подією реєстрації з ID 528 або ID 540). Щоб визначити, якими повноваженнями володіє користувач під час реєстрації, слід звернути увагу на поле Logon ID події з ID 576, яка ідентифікує користувача, і поле Assigned, де перераховані короткі імена повноважень.


Audit Policy Change


За допомогою категорії Audit privilege use можна простежити, хто і коли використовує повноваження, а категорія Audit policy change дозволяє дізнатися про зміни, що вносяться адміністраторами в призначені повноваження. Дана категорія забезпечує контроль декількох типів змін політики.


По-перше, Audit policy change повідомляє, коли були змінені призначені привілеї. Коли адміністратор надає користувачеві повноваження, Windows 2000 реєструє подію з ID 608 (користувачеві призначені повноваження). У поле User Right перераховані скорочені імена призначених повноважень (одного чи кількох). Поле Assigned to ідентифікує користувача або групу, якій адміністратор призначив повноваження. На Екрані 3 показано подію з ID 608, зареєстроване Win-dows 2000, коли я призначив групі Administrators повноваження SeCreate-TokenPrivilege (Create a token object) і SeCreatePermanentPrivilege (Create permanent shared objects – створювати постійні колективні об’єкти).


Поля User Name, Domain і Logon ID під заголовком Assigned By явно вказують, хто призначив повноваження. Але якщо адміністратори NT призначають повноваження безпосередньо через User Manager, то адміністратори Windows 2000 надають або відкликають повноваження не прямо, а через об’єкти групової політики (Group Policy Objects, GPO). В силу цих відмінностей, а також оскільки локальна система користувача читає Group Policy і вносить відповідні зміни в призначені повноваження, подія з ID 608 вказує в поле Assigned By обліковий запис локального комп’ютера. Щоб з’ясувати, яким чином адміністратор змінив повноваження, необхідно активізувати категорію Audit directory service для перевірки змін в об’єктах GPO в Active Directory (AD). Більш детальна інформація про аудит таких змін наведена в статті «Заглянемо в журнал безпеки Windows 2000 ».


Якщо повноваження користувача скасовані, то в наступний раз, коли Win-dows 2000 застосує групову політику, буде зареєстровано подію з ID 609 (скасування права користувача). Поле User Right цього події схоже на поле User Right події з ID 608. Поле Removed From вказує користувачів та групи, позбавлені одного або декількох повноважень. Поля User Name, Domain і Logon ID в розділі Removed By вказують обліковий запис локального комп’ютера точно так само, як поля Assigned By події з ID 608. Обидві події реєструються на комп’ютерах, на яких був застосований GPO, що містить призначені повноваження. Однак зміни, зроблені в об’єктах GPO, реєструються на контролері домену (DC), до якого під’єднувався адміністратор, редагував
GPO.


Audit policy change дозволяє відстежувати зміни в довірчих відносинах з іншими доменами. Якщо адміністратор додає новий довірений домен за допомогою оснащення Active Directory Domains and Trusts, то Windows 2000 реєструє два ідентичних події з ID 610 (новий довірений домен) на DC, до якого під’єднувався адміністратор. Поле Do-main Name події з ID 610 ідентифікує новий довірений домен. Щоб з’ясувати, хто встановив довірче відношення, потрібно подивитися на поля User Name, Domain і Lo-gon ID під заголовком Established By.


Windows 2000 також реєструє на DC один примірник події з ID 620 (Змінена інформація про довірену домені). Однак дана подія не містить ніякої додаткової інформації. При видаленні довіреної домену Windows 2000 реєструє дві події з ID 611 (видалення довіреної домену). Дана подія містить ті ж поля, що й подію з ID 610, але поля User Name, Domain і Logon ID знаходяться під заголовком Removed By замість Established By.


У подіях з ID 610, ID 611 і ID 620 проявляється ще одна вада системи аудиту Windows 2000: події реєструються при видаленні і додаванні як довіряють, так і довірених доменів. Подія говорить лише про те, що було встановлено або припинено довірче відношення, але не вказує, чи був домен довіреною або довіряє.


Windows 2000 реєструє подію з ID 612 (зміна політики аудиту) всякий раз, коли застосування Group Policy призводить до зміни політики аудиту комп’ютера. Поле New Policy даної події вказує, які категорії аудиту були активізовані для реєстрації успішних і невдалих дій. Наприклад, на Екрані 4 показано, що активізований аудит успішних і невдалих змін політики. Як і в події з ID 608, в полях User Name, Domain і Logon ID в підрозділі Changed By події з ID 612 не зазначено, який адміністратор змінив політику аудита, так як Windows 2000 не виявляє зміни до тих пір, поки групова політика не застосована. Проте подія з ID 612 корисно для пошуку змін в політиці аудиту.


Категорією Audit policy change можна скористатися і для відстеження деяких інших змін політики. Подія з ID 617 свідчить про зміну політики Kerberos, що визначає термін дії і оновлення квитка. Windows 2000 не обмежується реєстрацією події з ID 617 при явних зміни політики Kerberos, а записує подію в журнал всякий раз, коли DC застосовує Group Policy. При зміні розділу Encrypted Data Recovery Agents групової політики, в якому визначені особи, уповноважені відновлювати файли, зашифровані за допомогою EFS (Encrypting File System), Windows 2000 реєструє подію з ID 618 (зміна політики відновлення даних). І знову, в полях User Name, Domain і Logon ID в підрозділі Changed By немає інформації про те, хто насправді зрадив політику; в них просто вказана обліковий запис локального комп’ютера.


Адміністратор може контролювати зміни політики IP Security (IPSec) комп’ютера, однак існують різночитання щодо подій, забезпечують цю можливість. У документації Windows 2000 (за адресою:
www.microsoft.com/technet/security/monito.asp) наводиться список подій аудиту IPSec – з ID 615 і ID 616 – входять до категорію Audit policy change, але Event Viewer відносить ці події до Detail tracking (категорія Audit process tracking). Крім того, Windows 2000 реєструє подібні події, навіть якщо категорії Audit policy change і Audit process tracking не активізовані. У будь-якому випадку, при призначення політики IPSec через GPO в AD або через локальний GPO комп’ютера, Win-dows 2000 заносить в журнал подію з ID 615. Якщо використовується GPO в AD, то в описі події з ID 615 зазначається: IPSec
PolicyAgent Service: Using the Active Local Registry policy, as (i)
there’s no Active Directory Storage policy or (ii) the Active Directory
Storage policy couldn’t be applied successfully and there’s no Cached policy (використовується локальна політика Active Local Re-gistry, так як (I) не існує політики Active Directory або (ii) політика Active Directory не може успішно застосовуватися і немає збереженої політики). Якщо при застосуванні політики Windows 2000 стикається з труднощами, вона реєструє подію з ID 616 (агент політики IPSec зустрів потенційно серйозну проблему).


Контроль змін у груповій політиці – важлива умова збереження цілісності мережі. Але необхідно бути уважним і при контролі за фізичним доступом до систем по мережі. Windows 2000 допоможе вирішити цю задачу.


Audit system events


Категорія Audit system events містить кілька корисних подій. Всякий раз при початковому завантаженні Windows 2000 реєструє подію з ID 512 (початок роботи Windows NT). За допомогою даної події можна виявити несанкціоновані спроби перезавантаження системи, які потенційно небезпечні, так як Windows 2000 вразлива, коли роботу завершують користувачі, які мають фізичний доступ до машини.


У документації Windows 2000 вказується, що операційна система реєструє подію з ID 513 кожен раз при завершенні роботи, але це твердження невірне. Щоб визначити, як довго система була в неробочому стані, потрібно порівняти час і дату події з ID 512 і попереднього події, зареєстрованого Windows 2000.


Windows 2000 зазначає в журналі подію з ID 517 (журнал аудиту очищений) завжди, коли хто-небудь очищає журнал безпеки. Windows 2000 записує цю подію в новому журналі. Подія з ID 517 може вказати на зломщика, який намагався замести сліди.


У процесі початкового завантаження Win-dows 2000 реєструє і кілька інших подій. Операційна система фіксує подія c ID 515 (Довірений процес Logon зареєстрований в LSA) для кожної запущеної процедури входу в систему (процедури входу в систему обслуговуються процесом Logon, компонентом підсистеми безпеки Windows 2000). Windows 2000 також реєструє подію з ID 514 (пакет аутентифікації, завантажений LSA) для кожного пакета аутентифікації, що завантажується операційною системою (пакети аутентифікації сумісні з різними протоколами аутентифікації, такими, як Kerberos, NT LAN Manager (NTLM) і Secure sockets Layer (SSL)). Операційна система записує подію з ID 518 (SAM завантажила пакет оповіщення) для кожного пакета оповіщення, завантаженого Windows 2000; стандартні пакети оповіщення – scecli, kdcsvc і rassfm. Пакети оповіщення – це спеціальні DLL, які проектуються та встановлюються для синхронізації паролів з іншими системами або реалізують спеціальні правила застосування паролів. Однак зломщики можуть використовувати пакети оповіщення для крадіжки паролів. В будь-якому випадку до нестандартних пакетам оповіщення слід ставитися з обережністю.


Повний арсенал


Windows 2000 надає вражаючий набір функцій аудиту, вдосконалених в порівнянні з можливостями Windows NT. Однак в системі аудиту Windows 2000 є і значні недоліки, а застосування політик Group Policy не завжди дозволяє ідентифікувати користувача, який змінив політику, тому що адміністратори більше не змінюють політики безпосередньо. Хочеться вірити, що надалі розробники Microsoft усунуть подібні недоліки і забезпечать більш повний аудит змін політик, що вносяться через GPO.

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*