С появлением 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, чтобы обеспечить непрерывный мониторинг безопасности и соответствия требованиям законодательных актов при переходе на новую платформу.
Рэнди Франклин Смит (rdsmith@ultimatewindowssecurity.com ) — редактор Windows IT Pro, консультант по вопросам информационной безопасности, главный управляющий компании Monterey Technology Group. Преподает на курсах Ultimate Windows Security и имеет сертификаты SSCP, CISA и MVP