З появою Windows Server 2008 і Windows Vista відбулися істотні зміни в аудиті Windows Server і журналі подій безпеки. І дуже обнадіює, що більшість змін - позитивні. Журнал Security став трохи акуратніше і зрозуміліше, але, щоб в ньому розібратися, все ж потрібні деякі знання про заходи безпеки Windows і досвід діагностики. Останні десять років я займався дослідженням механізмів безпеки і аудиту Windows, а з деяких пір заглибився в Windows 2008 і Vista і можу повідомити корисні відомості про змінену кодуванні подій, нових, більш деталізованих способах обробки політики аудиту, форматі XML-журналу та вдосконалення в оснащенні Event Viewer консолі Microsoft Management Console (MMC).

Нові коди подій

Адміністратори, знайомі з журналом Windows Security, в першу чергу помітять відсутність звичних кодів подій (ID) в програмі перегляду подій Windows 2008. Тобто якраз в той час, коли нарешті вдалося запам'ятати різницю між подіями ID 528 і ID 529, Microsoft змінила коди. Насправді багато подій Windows Server 2003 збереглися, але їх номери збільшилися на 4096. Наприклад, подія з ID 528 в Windows 2003 стало подією з ID 4624 в Windows 2008.

По суті, не так уже й погано, що всі коди подій змінені, так як фахівці Microsoft повністю переробили все поля в описі кожної події. У Windows 2003 були збережені коди подій, успадковані від Windows 2000 Server, але змінилися події, яким вони відповідали; деякі події були об'єднані, і змінився порядок полів в описах. Це призвело до плутанини в програмах автоматичного аналізу журналів. Завдяки новій нумерації можна розмістити на підприємстві комп'ютери Windows 2008 і збирати журнали, не змінюючи існуючих фільтрів, попереджень і визначень в звітах. Потрібно лише додати визначення для нових кодів подій.

Підкатегорії політики аудиту

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

Компанія Microsoft зробила невеликий крок назустріч адміністраторам, дозволивши зменшити потік зайвої інформації. Це зроблено не так, як вважав за краще б я, - за допомогою набору правил, аналогічного для брандмауера, в якому визначені критерії відбору записуються подій для кожного коду. Замість цього компанія Microsoft збільшила число політик аудиту (категорій) з 9 до Windows 2003 до 52 в Windows 2008.

По суті, 9 існуючих категорій збереглися, але були розбиті на підкатегорії, кожну з яких можна активізувати для вдалого і / або невдалого події. При бажанні політикою аудиту можна керувати за використанням 9 категорій верхнього рівня. На екрані 1 показані 9 категорій і 52 підкатегорії. За адресою http://www.ultimatewindowssecurity.com/newauditpol наведена таблиця розподілу 9 категорій на підкатегорії і дано короткий опис подій і дій, що відслідковуються за допомогою кожної категорії.

Все вищевикладене налаштовує на оптимістичний лад. За допомогою більш детальної політики аудиту можна виключити старі непотрібні події і деякі нові події, додані в Windows 2008, серед яких теж багато надлишкових. Наприклад, більшість адміністраторів віддасть перевагу відключити підкатегорії Filtering Platform Packet Drop і Filtering Platform Connection, які видають дуже багато зайвих подій, оскільки записують мережевий трафік на рівні пакетів.

Однак не всі новини приємні: політиками аудиту не можна управляти на рівні підкатегорій з використанням групової політики. Компанія Microsoft додала 52 нових підкатегорії, але не доповнила групову політику новими політиками, щоб ввімкнути або вимкнути підкатегорії. До речі, підкатегорії недоступні з інтерфейсу користувача. Єдиний спосіб включати і вимикати події на рівні підкатегорій забезпечує команда Auditpol. У статті Microsoft «Security auditing settings are not applied to Windows Vista client computers when you deploy a domain-based policy» ( http://support.microsoft.com/kb/921468 ) Описаний метод настройки підкатегорій аудиту через сценарії запуску, визначені за допомогою групових політик, але цей спосіб досить незграбний.

Працюємо з політикою аудиту

Познайомимося ближче з командою Auditpol і способами вирішення можливих конфліктів між політикою аудиту, налаштованої в об'єктах групової політики (GPO), і політикою підкатегорії, заданої з використанням Auditpol. Щоб з'ясувати поточний стан 52 підкатегорій аудиту, досить звернутися до потрібного комп'ютера і ввести команду

auditpol / get / category: *

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

Щоб змінити аудит для підкатегорії, досить запустити команду auditpol з параметром / set, вказати підкатегорію і включити або виключити успішні події і / або відмови. наприклад,

auditpol / set

/ Subcategory: «System Integrity»

/ Failure: enable / success: enable

активізує підкатегорію System Integrity як для успішних подій, так і для відмов.

Що відбувається, якщо політики аудиту для 9 категорій верхнього рівня, налаштовані в використанням групової політики, конфліктують з політиками, призначеними для 52 підкатегорій в Auditpol, або навпаки? Наприклад, комп'ютер W08-YHWH розташований в організаційній одиниці (OU) Servers в Active Directory (AD). Адміністратор змінює об'єкт GPO, пов'язаний з цією OU, відключаючи категорію верхнього рівня Audit logon events (або Logon / Logoff) як для успішних подій, так і для неуспішних. Потім адміністратор реєструється на комп'ютері W08-YHWH і включає підкатегорію Logon для успішних і неуспішних подій за допомогою команди Auditpol. Яким буде результат?

За замовчуванням, якщо визначити значення для однієї з 9 категорій верхнього рівня в локальній політиці безпеки комп'ютера або право застосовується об'єкті GPO, політика верхнього рівня буде мати пріоритет перед налаштуваннями на рівні підкатегорій. За замовчуванням політики підкатегорій в Windows діють тільки в тих випадках, якщо категорія верхнього рівня не визначена в локальній політиці безпеки та всіх об'єктах GPO. Необхідно підкреслити, що такий порядок за замовчуванням, так як в редакторі Group Policy Object Editor (GPE), в розділі Computer ConfigurationWindows SettingsSecurity SettingsLocal PoliciesSecurity Options, з'явився новий параметр з назвою Audit: Force audit policy subcategory settings (Windows Vista or later) to override audit policy category settings. Будучи активізований, параметр змінює порядок застосування політики аудиту на протилежний, і будь-які настройки підкатегорій, зроблені за допомогою Auditpol, скасовують 9 політик верхнього рівня, задані з використанням групової політики.

Важко уявити, яким чином компанія Microsoft випустила Vista і тим більше Windows 2008, не забезпечивши управління цією надзвичайно важливою областю безпеки через групову політику, але тим не менше це сталося. А рішення, запропоноване в згаданій вище статті Microsoft, ненадійно і схильне збоїв. Крім того, вражає, що неможливо застосувати команду Auditpol до віддалених комп'ютерів; вона діє тільки локально.

Як би там не було, в якості відправної точки при формуванні політики аудиту на верхньому рівні рекомендується включити System, Policy Change, Logon / Logoff, Account Logon, Account Management і, на контролерах домену (DC), DS Access, що дозволить відстежувати важливі зміни в організаційних одиницях та об'єктах GPO. Активізація цих категорій для успішних подій і відмов дозволить зібрати найбільш важливі відомості, виключивши основні джерела надлишкової інформації, такі як Privilege Use і Object Access. Якщо потрібно виконати аудит системних файлів, включіть підкатегорію File System категорії Object Access.

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

Вибіркове відключення підкатегорій дозволяє виключити зайві події. Щоб знайти і підтвердити скасовуються підкатегорії, потрібно відшукати надлишкові події в програмі перегляду подій і визначити ім'я їх підкатегорії (Task Category в програмі перегляду подій). Перш ніж відключити підкатегорію, переконайтеся, що не потребуєте в інших подіях, що належать цій підкатегорії і типу успіх / відмова. Прийняти рішення простіше, якщо відфільтрувати записи журналу в програмі перегляду подій, показавши тільки події даної підкатегорії. Крім того, список подій кожної категорії наведено в безкоштовній енциклопедії Windows Server 2008 Security Log Encyclopedia за адресою http://www.ultimatewindowssecurity.com/encyclopedia.apx . Якщо в підкатегорії немає важливих подій для даного типу успіх / відмова, то вимкніть підкатегорію для успішних подій, відмов або подій обох типів (в залежності від конкретної ситуації).

Не забудьте: щоб настройки підкатегорії вступили в силу, потрібно змінити параметр групової політики Audit: Force audit policy subcategory settings (в Windows Vista і більш пізніх версіях), скасувавши настройки категорії політики аудиту, як описано вище.

формат подій

Компанія Microsoft використовує новий формат подій в Windows 2008. Змінено як фізичний формат файлу журналів подій Windows, так і логічні поля, які складають кожну подію, що пересилається в журнал. Ентузіасти XML знайдуть XML-схему для журналів подій за адресою http://schemas.microsoft.com/win/2004/08/events/event ; в іншому новий формат мало зачіпає інтереси адміністраторів. Для програмістів, які працюють з журналами подій, в Windows збережені старі інтерфейси Win32 Event API; познайомитися з новими можна за адресою http://msdn2.microsoft.com/en-us/library/aa382610.aspx .

Набагато важливіше логічний формат подій (представлений у вікні властивостей події програми перегляду подій). На екрані 2 показано подія з ID 4625. У кожній події як і раніше є кілька стандартних полів і текстовий опис. У стандартних полях міститься інформація, застосовна до будь-якої події, незалежно від його коду, в тому числі відомості про дату і час, джерело, категорії і результаті - успіх / відмова. Повідомлення і дані в текстовому описі різні в подій з різними кодами.

Опис кожної події є комбінацією статичного тексту і динамічно рядків, що вставляються. У наведеному нижче тексті показані перші кілька рядків опису події з ID 4625. Статичний текст виділений чорним; червоні значення індивідуальні для конкретного екземпляра події.

An account was successfully logged on.

Subject:

Security ID:

SYSTEM

Account Name:

WIN-K2SF4WMIK17 $

Account Domain:

ACME

Logon ID:

0x3e7

Таким чином, концепція стандартних полів і індивідуального опису події залишилася колишньою. Змінилися окремі стандартні поля і вставляються рядки для подій з різними кодами. Порівняйте подія з ID 4625 (екран 2) з його попередником, подією ID з 529 в Windows 2003 (екран 3). Зрозуміти більшість змін стандартних полів неважко, наприклад заміну Date and Time на Logged, але в деяких випадках необхідні додаткові пояснення. По-перше, зверніть увагу, що в подіях Windows 2008 не відображається стара категорія верхнього рівня, так як в Windows 2008 категорії аудиту верхнього рівня відносяться тільки до політики аудиту (тобто записуються чи ні події з даними кодами). Події, що записуються в журнал Windows 2008, розподіляються по підкатегоріями, що має назву Task Category, в програмі перегляду подій. Очевидно, розробникам здалося занадто нудним узгоджувати команду Auditpol з використанням Subcategory.

Type більше не існує. Замість нього з'явилися Level і Keywords. Схоже, всі події в журналі безпеки мають рівень Information і ключове слово Audit Failure або Audit Success.

Значно змінилися опису подій. Windows 2008 вставляє в опису багато динамічних значень, і компанія Microsoft забезпечила деякий рівень однаковості в описах подій з різними кодами. Описи подій - хороший приклад того, як завдяки продуманій XML-схемі спрощується обробка записів даних зі схожою структурою, але динамічними змінами між екземплярами.

В описах багатьох подій є загальні елементи даних. Наприклад, майже кожної події необхідно записувати інформацію про суб'єкта ( «хто»). Як показано з екрані 2 і випливає зі сказаного вище, в інформацію про суб'єкта входять SID, ім'я облікового запису, домен і код реєстрації. Історично внесення цієї інформації для різних подій не було уніфіковано в Windows. Дані часом пропускалися або відзначалися різними способами.

Як приклад порівняйте дані про суб'єкта в події Account Logon операційної системи Windows 2003. Ім'я облікового запису зазначено декількома способами, і в деяких подіях частина даних відсутня.

У Windows 2008 з'явилося кілька загальних розділів для більшості подій, зокрема вже згаданий розділ Subject. Події, які відстежують дії з об'єктами певного типу, наприклад доступ до файлу, мають у своєму розпорядженні розділом Object з усіма полями, необхідними для ідентифікації об'єкта, такими як тип і повне ім'я об'єкта. У всіх подіях, які відзначають участь системного процесу, є розділ Process Information, що містить ідентифікатор процесу (PID) і ім'я файлу, що виконується.

І нарешті, в нижній частині деяких описів розширено пояснювальний текст про подію або значеннях, наведених в описі. Однак додаткові відомості є не скрізь і часто неповні. Енциклопедія Security Log Encyclopedia як і раніше знадобиться адміністраторам.

Нова програма перегляду подій

Нова оснащення Event Viewer консолі Microsoft Management Console (MMC) все ще не стала повноцінним рішенням для управління журналами подій, але набагато краще підходить для швидкого перегляду подій безпеки.

Перша примітна особливість Event Viewer - нова панель завдань (праворуч на екрані 4), завдяки якій істотно зменшується число клацань при виконанні типових задач, таких як установка і подальше видалення фільтра. Event Viewer у своєму розпорядженні ті ж основними фільтрами для журналу безпеки, що і в минулому, але з рядом поліпшень.

В результаті клацання на Filter Current Log в панелі завдань з'являється вікно, показане на екрані 5. У спадному поле Logged набагато простіше визначити часовий діапазон аналізу, вказавши періоди Last hour, Last 12 hours, Last 24 hours, Last 7 days, Last 30 days та , звичайно, призначений для користувача діапазон Custom. Це значне поліпшення в порівнянні з Windows 2003 і колишніми версіями, в яких потрібно вказати точну дату і період часу.

Подання можна обмежити успішними подіями або відмовами за допомогою розкривається поля Keywords і фільтрувати події по підкатегоріями з використанням розкривається поля Task category. Поле Task category не заповнено 52 підкатегоріями аудиту до тих пір, поки не обраний пункт Microsoft Windows security auditing в списку Event sources. Щоб побачити результати застосування фільтра, досить натиснути OK.

Вдале нововведення: після того як фільтр налаштований, його можна зберегти для подальшого використання за допомогою функції Save Filter to Custom View в панелі завдань. У діалоговому вікні Save Filter to Custom View потрібно ввести ім'я, опис і місцезнаходження в папці Custom Views (екран 4).

Вперше за допомогою Event Viewer легко зв'язати події з завданнями, які автоматично виконуються при виникненні події. Припустимо, старшим керівникам компанії виділено спеціалізований сервер Microsoft SharePoint. Адміністратора необхідно повідомляти про всі випадки блокування облікового запису, щоб допомогти керівнику отримати доступ до сервера з мінімальними незручностями (по крайней мере, для керівника). Можна передавати повідомлення по електронній пошті, виводити його на консоль або запускати команду або сценарій всякий раз при виникненні події блокування облікового запису.

Найпростіший спосіб зв'язати завдання з подією - вибрати потрібну подію в Event Viewer і клацнути на функції Attach Task To This Event в панелі завдань. При цьому запускається майстер Create Basic Task. Майстер запитує ім'я завдання і просить визначити програму, повідомлення електронної пошти або екранне повідомлення. Після закінчення роботи майстра можна переглянути подію, його властивості та історію, відкривши оснащення Task Scheduler консолі MMC, яка знаходиться в меню StartAll ProgramsAccessoriesSystem Tools.

Однак нерідко необхідний більш точний критерій спрацьовування, ніж просте зазначення коду події. На щастя, будь-який критерій, який можна задати в фільтрі спеціального уявлення, можна вказати і в тригері події. Це відноситься і до складних фільтрів, складеним мовами XML. На жаль, тригер можна побудувати в програмі перегляду подій, необхідно використовувати планувальник завдань. Відкрийте планувальник завдань і клацніть на Create Task. Вкажіть ім'я та опис події, а також обліковий запис для виконання завдання на вкладці General.

Потім нужно вібрато вкладку Trigger и натіснуті кнопку New. У діалоговому вікні New Trigger віберіть пункт On an event Із списку Begin the task. Віберіть Custom спадному поля Settings, а потім натісніть New Event Filter. На екрані з'являється тієї ж діалогове вікно, что и при створенні спеціального уявлення в Event Viewer. Можна вказаті крітерій фільтра на вкладці Filter або побудуваті складаний фільтр з Використання синтаксису XML на вкладці XML. Після того як критерій запуску готовий, можна перейти на вкладку Actions і вказати одне або декілька дій, які виконуються планувальником завдань.

Ще одна перевага Event Viewer - оновлені параметри політики збереження журналів, які відображаються, коли користувач відкриває властивості журналу безпеки. Старий параметр Overwrite events older than ... days замінений на Archive the log when full, do not overwrite events, який відкриває доступ до функції, що існувала давно, але перш за доступною тільки через розділ реєстру HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesEventLogServiceAutoBackupLogFiles. Якщо вибрати режим Archive the log when full option, то журнал безпеки автоматично архівується в каталозі C: ​​WindowsSystem32winevtLogs.

Попередження: Windows продовжить записувати та архівувати події до заповнення диска, тому необхідно автоматизувати процес переміщення журналів. В кінцевому підсумку не існує повноцінної заміни цього рішення управління журналами від стороннього виробника. Можна, наприклад, звернутися до статті на сайті журналу Windows IT Pro «Технології управління журналами подій» ( http://www.osp.ru/win2000/2007/06/4473876/ ).

Приступаємо до роботи

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

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

Ще одне важливе нововведення, пов'язане з журналами подій Windows 2008 і Vista, - функція перенаправлення подій, завдяки якій в Windows вперше з'являється можливість автоматично пересилати події на інші сервери, де теоретично можна централізовано керувати подіями. Збір журналів з багатьох комп'ютерів - гігантська завдання, і метод на основі HTTP, застосовуваний в Windows 2008 для перенаправлення подій, годиться тільки для малих масивів подій, визначених дуже вузькими критеріями.

Слід якомога швидше приступити до вивчення нового журналу подій Windows 2008, щоб забезпечити безперервний моніторинг безпеки та відповідності вимогам законодавчих актів при переході на нову платформу.

Ренді Франклін Сміт ( [email protected] ) - редактор Windows IT Pro, консультант з питань інформаційної безпеки, головний керуючий компанії Monterey Technology Group. Викладає на курсах Ultimate Windows Security і має сертифікати SSCP, CISA і MVP