Выборочный аудит пользователей

Полнота информации, предоставляемая при аудите событий в 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