1. Точна настройка політики аудиту
2. Використання Auditusr
3. Зниження рівня шумів
4. застереження
5. Таблиця 1: Команди включення і виключення утиліти Auditusr

Повнота інформації, що надається при аудиті подій в Windows, найчастіше - палиця з двома кінцями, оскільки некритичні повідомлення (іншими словами, «шуми») можуть маскувати від адміністратора ті події, на які дійсно варто звернути увагу. Однак не слід дорікати Microsoft в надлишку таких шумових повідомлень в журналах аудиту. Справа в тому, що існує класичний стандарт оцінки типових критеріїв захищеності Common Criteria ( http://www.commoncriteriaportal.org ), Відповідно до якого операційні системи повинні передбачати можливості аудиту будь-яких виконуваних в них дій. Це пов'язано з тим, що якщо будь-які події неможливо фіксувати в журналах, може виявитися, що в деяких випадках саме ці події становлять найбільший інтерес для адміністраторів. Звичайно, в більшості випадків немає необхідності фіксувати всі події, що відбуваються в системі, тому для зниження рівня шуму в журналах подій слід виконувати ретельну настройку політики аудиту відповідно до вимог конкретної інформаційного середовища. Розгромна замовна стаття в Windows нова функція - вибірковий аудит користувачів - допомагає впоратися з цим завданням.

Точна настройка політики аудиту

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

• System Event (Системне подія)
• Policy Change (Зміна політики)
• Logon / Logoff (Реєстрація / Вихід із)
• Account Management (Служба захисту)
• Object Access (Доступ до об'єктів)
• Directory Service Access (Доступ до служби каталогів)
• Privilege Use (Використання привілеїв)
• Account Logon (Реєстрація з обліковим записом)
• Detailed Tracking (Детальний відстеження)

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

Але як бути в тому випадку, якщо потрібно організувати аудит тільки для певних користувачів, виключивши всіх інших? Для вирішення даної проблеми, а також з огляду на доповнення стандартних критеріїв, Microsoft включила кошти вибіркового аудиту користувачів в пакет оновлення Windows XP Service Pack 2 (SP2), а потім і в Windows Server 2003 SP1. Дана технологія аудиту дозволяє включати або відключати аудит потрібних категорій подій для тих чи інших учасників безпеки. Таким чином, тепер можна реєструвати в журналах тільки ті події, які пов'язані з діями певних користувачів, а також отримувати звіти тільки по певним користувачам. Наприклад, можна організувати аудит по всім спробам перезапису системних файлів Windows для всіх учасників безпеки, за винятком облікового запису, що використовується антивірусною програмою, і системної облікового запису. Або можна відключити аудит спроб реєстрації / завершення сеансу роботи з системою для всіх користувачів, але вибірково реєструвати спроби цих дій для облікового запису Administrator. Тобто тепер можна глобально відключати аудит і, тим не менш, реєструвати події безпеки для окремих користувачів. ЗАУВАЖЕННЯ: в даній статті під глобальним аудитом (global auditing) розуміються ті настройки ефективної політики аудиту, які задаються через групову політику або локальну політику комп'ютера Local Computer Policy.

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

Використання Auditusr

Налаштування параметрів вибіркового аудиту можна переглядати, змінювати або видаляти за допомогою утиліти auditusr.exe (вона знаходиться в каталозі% windows% system32). Щоб побачити список поточних налаштувань, потрібно набрати в командному рядку (як показано на рис. 1):

auditusr

Перш ніж створювати нові політики вибіркового аудиту, потрібно зібрати наступну інформацію:

• які категорії аудиту вже включені локально
• в налаштування облікових записів яких учасників безпеки передбачається внести зміни
• чи збираєтеся ви додавати учасників в категорії або виключати їх звідти

Тепер можна створювати виключення для загальних параметрів аудиту за допомогою утиліти Auditusr. Синтаксис запуску цієї програми для включення або виключення користувачів по тим чи іншим категоріям має наступний вигляд:

auditusr /:

Команди, які можуть використовуватися в даній утиліті для включення і виключення, наведені в таблиці 1 . Якщо при введенні імен учасників безпеки не вказується в якості префікса ім'я домену або робочої групи, програма Auditusr буде спочатку шукати обліковий запис локального користувача, а потім спробує знайти зазначену обліковий запис в домені. Як доменного імені можна вводити імена NetBIOS або імена FQDN (Fully Qualified Domain Name), які при відображенні будуть перетворені в короткі імена.

Назви категорій аудиту слід вказувати повністю. Якщо в назві категорії є прогалина, наприклад, Privilege Use, воно повинно полягати в подвійні лапки ( "Privilege Use"), причому чутливості до регістру тут немає. За словами фахівців Microsoft, можна послідовно вказати відразу кілька категорій аудиту, розділивши їх символом крапки з комою (;), проте мені в процесі тестування так і не вдалося ввести кілька категорій за один раз.

Нижче наведена пара прикладів додавання і виключення категорій аудиту для деякого користувача:

auditusr / if joeuser: Logon / Logoff auditusr / es joeuser: "Privilege Use"

На жаль, на момент написання даної статті Microsoft надавала вкрай мізерну документацію по утиліті Auditusr, тому я не зміг перевірити синтаксис і очікувані результати.

Як показано на рис. 1, утиліта Auditusr по кожному користувачеві виводить в окремому рядку список успішно доданих (include-success), невдало доданих (include-failure), успішно виключених (exclude-success) і невдало виключених (exclude-failure) категорій. За допомогою показаної нижче команди можна скинути всі налаштування для всіх користувачів:

auditusr / ra

Якщо ж потрібно очистити настройки тільки для заданого учасника безпеки, необхідно використовувати наступну команду:

auditusr / r

Для автоматизації процесу настройки вибіркового аудиту в утиліті Auditusr передбачено два ключа, / i і / e, призначені, відповідно, для імпорту та експорту списків з файлів. Для отримання довідки по повному синтаксису даної утиліти наберіть в командному рядку:

auditusr /?

Зниження рівня шумів

Налаштування параметрів вибіркового аудиту користувачів нагадує процес призначення політик обмеження для програм (software restriction policies). Спочатку визначається загальна стратегія, потім створюються виключення для глобальної політики.

Вибірковий аудит користувачів може бути корисний як засіб зниження рівня шумів в журналах аудиту. Більшість адміністраторів вичищають контрольовані ними файли журналів з метою відсіювання деяких повторюваних подій, ініційованих службами (наприклад, запуск резервного копіювання на стрічку, антивірусних програм або засобів адміністрування). Дані служби або працюють безперервно, або регулярно запускаються, що, відповідно, призводить до появи непотрібного шуму в журналах подій.

Сам по собі процес аудиту може утруднити боротьбу з шумами. З міркувань безпеки я зазвичай включаю для категорій аудиту Detailed Tracking (детальне відстеження) (тобто відстеження процесів) і Object Access (доступ до об'єктів) відстеження будь-яких шкідливих дій зловмисників. Можна подумати, що включення аудиту по категорії Detailed Tracking призводить до появи високого рівня шуму в журналах, проте на виділених контролерах домену (DC) цей компонент зазвичай не вносить вирішальний вклад в цей шум, оскільки на таких комп'ютерах, як правило, запускається значна кількість різних програм і процесів. Я регулярно переглядаю файли журналів на контролерах домену, використовуючи для цього віддалене підключення через Remote Desktop. Звичайно, кожне моє віддалене підключення до комп'ютера і відкриття на ньому файлів журналів саме по собі генерує нові події. Наприклад, коли відбувається оновлення екрану з журналом, генеруються два повідомлення про події. Але тепер, з виходом пакета Windows 2003 SP1 і включеними в нього можливостями вибіркового аудиту користувачів, я можу додати в сценарій реєстрації простий командний файл, за допомогою якого буде обмежений потік генеруються повідомлень, що відносяться безпосередньо до мене і моїм діям, пов'язаним з віддаленим моніторингом.

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

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

Зміна налаштувань вибіркового аудиту користувачів реєструється двома подіями: оновленням політики вибіркового аудиту користувачів з ID 806 (Per User Audit Policy was refreshed), яке показано на рис. 2, і подією з ID 807, що означає, що для користувача встановлена ​​політика вибіркового аудиту (Per user auditing policy set for user), див. Рис. 3. Само по собі подія 806 не несе будь-якої конкретної інформації, але його наявність в журналі вказує на факт включення або зміни налаштувань політики вибіркового аудиту. Що стосується події 807, то воно містить, як мінімум, інформацію про конкретного користувача, до якого була застосована дана політика. На жаль, категорії аудиту, наведені в розділі опису Description події 807, не можуть бути модифіковані.

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

застереження

Незважаючи на те, що вибірковий аудит користувачів відповідає актуальним вимогам, що пред'являються до процедури аудиту, проте, відзначу, що дана технологія недосконала. Утиліта Auditusr знаходиться в каталозі System32, в який будь-який авторизований користувачів зазвичай має права на читання (Read) і виконання (Execute). Відповідно, будь-який з цих користувачів може запустити цю програму і вважати поточні настройки параметрів вибіркового аудиту для будь-якого заданого користувача. Звичайно, звичайні користувачі, як правило, не мають прав на внесення змін в ці настройки, і, тим не менш, наявність у зловмисника, який зміг зареєструватися в системі, інформації про те, для яких учасників безпеки включені процедури відстеження їх дій, може допомогти йому при спробах сканування системи.

Крім цього, не слід розраховувати на те, що при вибірковому аудиті будуть прийматися або відсіюватися всі повідомлення про події, пов'язані з конкретним користувачем. Вибірковий аудит фільтрує тільки ті повідомлення, які містять в своєму полі User задане ім'я учасника безпеки. А між тим, у багатьох випадках повідомлення про події можуть містити в поле User інше ім'я, і, тим не менш, мати посилання на відповідного користувача в описі Description цього повідомлення. Розглянемо, наприклад, подія з ID 682. Воно фіксує факт успішної реєстрації користувача. При цьому в полі User, як правило, міститься ім'я System, відповідне системної облікового запису, а ім'я реального користувача, для якого, можливо, встановлена ​​політика вибіркового аудиту, знаходиться в полі Description. Також слід зазначити, що хоча наявність вибіркового аудиту користувачів додає ще більшу ступінь деталізації в уже деталізовану систему, проте, така технологія не може використовуватися для відсіювання повідомлень з окремих папок по даному учаснику безпеки - в межах обраної категорії аудиту як і раніше діє принцип " все або нічого".

І, нарешті, вибірковий аудит користувачів може стати причиною взаємовпливу між різними категоріями аудиту. Припустимо, я на глобальному рівні відключив категорію Logon / Logoff, включивши при цьому вибірковий аудит для користувачів з адміністративними правами, причому для деяких з них також включена реєстрація дій по категорії Privilege Use. В даному випадку якщо я відключаю для користувачів з адміністративними правами категорію аудиту Logon / Logoff, це призведе до того, що для них не будуть фіксуватися в журналі і дії категорії Privilege Use. Я припускаю, що виникнення даної ситуації обумовлено способом використання механізму відстеження різними категоріями аудиту. Висновок очевидний: перед застосуванням вибіркового аудиту користувачів необхідно все ретельно протестувати.

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

Тому деякі адміністратори вважають за краще реєструвати всі події, що відбуваються, а потім фільтрують шуми в уже сформованих журналах. Це випробуваний підхід до процедури аудиту, який при необхідності може бути модифікований. При цьому для фільтрації подій можуть бути використані можливості програми Event Viewer або будь-якого із засобів аналізу журналів від Microsoft (Microsoft Systems Management Server (SMS), Microsoft Operations Manager (MOM), EventCombMT, Microsoft Audit Collection System (MACS)), а також який -либо из множества пакетов независимых фирм, предназначенных для мониторинга журналов.

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

Таблиця 1: Команди включення і виключення утиліти Auditusr

/ is Включає (із занесенням до звіту) успішні події для даного учасника безпеки, навіть в тому випадку, якщо на глобальному рівні аудит для даної категорії відключений / es Виключає (без занесення до звіту) успішні події для даного учасника безпеки, навіть в тому випадку, якщо на глобальному рівні аудит для даної категорії включений / if Включає (із занесенням до звіту) завершилися невдачею події для даного учасника безпеки, навіть в тому випадку, якщо на глобальному рівні аудит для даної категорії відключений / ef викл ає (без занесення до звіту) завершилися невдачею події для даного учасника безпеки, навіть в тому випадку, якщо на глобальному рівні аудит для даної категорії включений.