Управление аудитом и журналом безопасности. Виндовс журнал безопасности


Информация о событиях Windows в журнале безопасности | Windows IT Pro/RE

С появлением 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

www.osp.ru

Журнал безопасности Windows NT — Windows ИНФО

Анализируем журнал безопасности Windows NT

Журнал безопасности Security Log может использоваться для отслеживания (аудита) большинства действий пользователей в системе. Существует три основные категории такого аудита — это аудит сеансов работы пользователей, аудит доступа к объектам системы и аудит выполняющихся задач. Эти категории дают основную информацию при наблюдении за действиями пользователей. Системная политика аудита настраивается в меню Policies-Audit-Audit Policy, вызываемом из программы User Manager (см. Экран 1). Данное диалоговое окно позволяет выбрать, какие из семи категорий фиксировать в локальном журнале безопасности, а какие нет.

Сеансы работы пользователей

ЭКРАН 1. Настройка аудита системы.

Многие администраторы просматривают журнал безопасности Windows NT и видят события входа пользователей в систему и выхода из нее, однако часто не могут правильно оценить увиденное. Здесь следует обращать внимание на отдельные параметры событий. Так, событие успешной регистрации пользователя в системе имеет номер (ID) 528 (см. Рисунок 1). При отказе в регистрации пользователя фиксируется событие с другим номером, который зависит от причины отказа. Полный список событий можно найти в документе Microsoft «Описание событий аутентификации» (см.http://support.microsoft.com/support/kb/ar…s/q174/0/74.asp). Событие с номером 538 означает завершение сеанса, начало которого зафиксировано событием 528. Событие номер 528 имеет несколько очень важных дополнительных параметров. Имя пользователя и домен определяют вошедшего в систему пользователя или то, чья учетная запись была при этом задействована. Номер сеанса пользователя Logon ID — это уникальный для системы код, присваиваемый любому активному сеансу работы пользователя с системой. Именно он будет записан в событии завершения сеанса. Это позволяет определить общее время работы пользователя при анализе событий 528 и 538 с одним и тем же номером сеанса.

РИСУНОК 1. Событие номер 528.

Событие входа в систему также фиксирует информацию о типе входа Logon Type, т. е. то, как пользователь вошел в систему. Тип входа 2 соответствует интерактивному входу с консоли, например, с помощью монитора и клавиатуры. Если пользователь подключается к диску на другом компьютере или как-либо еще использует сетевой ресурс, то выполняется сетевой вход с типом 3. Так, если был зафиксирован тип входа 2, то кто-то вошел в систему с локальной консоли именно этого компьютера, а если тип 3, значит, кто-то подключился к системе по сети. Тип входа 5 фиксируется при запуске службы с указанием конкретной учетной записи пользователя. При использовании планировщика задач производства независимых компаний, например Argent Queue Manager компании Argent Software, система фиксирует событие номер 528 с типом входа 4, что соответствует заданию на выполнение командного файла. При разблокировании рабочей станции записывается событие с типом входа 7.

Фиксируются также все неудачные попытки входа в систему Logon Failure. При этом чаще всего записывается системное событие 529, соответствующее указанию неверного имени пользователя или пароля — Unknown user name or bad password.

ЭКРАН 2. Выбор рабочих станций, с которых пользователь имеет право войти в систему.

Если учетная запись пользователя недоступна или заблокирована, то попытка входа отвергается, и записывается событие с номером соответственно 531 или 539. Событие номер 530 указывает, что пользователь пытался войти в систему в недозволенное ему время или день недели. Если учетная запись пользователя просрочена или устарел пароль, то фиксируется соответственно событие 532 или 535. Если пользователь ограничен входом лишь на некоторые рабочие станции (см. Экран 2), а он пытается войти с другого компьютера, то запишется событие номер 533. Можно ограничить права пользователя на выполнение определенных типов входа в различные системы. Если пользователь, которому запрещен доступ к какому-то компьютеру по сети, все же пытается обратиться к его ресурсу или реестру, то он получит отказ, а в журнал безопасности запишется событие с номером 534. Такое же событие будет зафиксировано при попытке пользователя войти в систему с консоли, если это ему запрещено. При попытке запустить службу с использованием учетной записи пользователя, не имеющей права на запуск служб (права Logon as a service), также будет зафиксировано событие номер 534. Кроме того, событие 534 запишется и при попытке запуска задания с исполнением командного файла от имени учетной записи без права Logon as a batch job. При всех других отказах в аутентификации фиксируется событие с номером 537, т. е. An unexpected error occurred during logon — отказ по неизвестной причине. Тип входа фиксируется при всех попытках входа в систему, независимо от их результата. Более подробную информацию можно найти в документе Microsoft «Аудит аутентификации пользователей» (см.http://support.microsoft.com/support/kb/ar…s/q174/0/73.asp).

Аутентификация в Windows NT имеет распределенную природу. Особенно ярко это проявляется при слежении за входом в систему и выходом из нее. Зачастую аудит на рабочей станции, имеющей учетную запись в домене, воспринимается уже как «вход в домен», вместо настоящего момента входа в домен или же входа на контроллер домена с использованием учетной записи домена. Аудит на рабочей станции означает лишь регистрацию на рабочей станции. Но поскольку используется учетная запись домена, сама рабочая станция не может аутентифицировать пользователя. Рабочая станция лишь посылает сведения о пользователе на контроллер домена по протоколу NTLM (NT LAN Manager). Контроллер домена проверяет правильность пароля и сразу же забывает о пользователе. Сеанс работы пользователя поддерживает сама рабочая станция до самого момента выхода из системы. Разумеется, именно рабочая станция и записывает в свой журнал системы безопасности информацию о сессии пользователя.

Для получения общей картины работы пользователей домена зачастую можно обойтись без анализа журналов безопасности на всех без исключения рабочих станциях. Дело в том, что сразу же после успешного входа пользователя обычно выполняется автоматическое подключение сетевых дисков, расположенных на файл-серверах. Именно журналы безопасности файл-серверов и следует просматривать, отслеживая события входа в систему с типом 3. Из-за отсутствия централизованной фиксации входов в систему для домена бывает трудно отследить попытки несанкционированного доступа. Однако, хотя контроллеры домена и не фиксируют все неудавшиеся попытки входа, они записывают все блокировки учетной записи (событие номер 644), которые являются следствием нескольких безуспешных попыток входа подряд. Подробнее о блокировках учетных записей рассказано в документе Microsoft «События при блокировках учетных записей хранятся в журнале безопасности контроллера домена» (см. http://support.microsoft.com/support/kb/ar…s/q182/9/18.asp).

Необходимо отслеживать использование локальных учетных записей на отдельных системах. Входящие в домен рабочие станции и обычные серверы аутентифицируют пользователей на контроллерах доменов, а также ведут собственные локальные базы пользователей (SAM). И пользователи, и взломщики могут задействовать эти локальные учетные записи, чтобы попытаться войти в систему локально или через сеть. Во всех системах существует встроенная административная учетная запись Administrator. О том, как предотвратить нежелательные попытки ее использования, рассказано в мартовском номере Windows NT Magazine/RE в статье Франклина Р. Смита «Защитим права администратора!».

Для эффективного наблюдения за сеансами работы пользователей нужно хорошо знать, что и где проверять. Для отслеживания входа в систему в первую очередь следует просматривать журналы безопасности на рабочих станциях и простых серверах и искать в них события с номерами 528 и 538. Возможные попытки незаконного проникновения в систему отслеживаются среди событий с номерами от 529 до 537, а также 539 на всех потенциально доступных для нападения компьютерах.

Доступ к объектам системы

Аудит доступа к объектам включает в себя всего три события, однако он очень важен, поскольку позволяет отслеживать обращения к любым объектам, включая каталоги, файлы, принтеры и ключи реестра. Для использования перечисленных возможностей необходимо включить опцию регистрации доступа к объектам в меню настройки аудита системы, а также указать все объекты, доступ к которым требуется регистрировать. Список регистрируемых действий для объекта очень напоминает список прав доступа к этому объекту (ACL). В таком списке указаны пользователи и их действия, подлежащие регистрации.

Аудит доступа к объектам ведется в журнале событий, а не в журнале транзакций. Поэтому Windows NT не фиксирует, что именно сделал пользователь с объектом, а указывает только тип доступа к данному объекту. Так, например, можно проследить, что пользователь Иванов открыл файл Зарплата.xls для чтения, записи, выполнения и удаления, однако совершенно невозможно выяснить, внес ли он какие-то изменения, а если да, то какие именно. К тому же при аудите доступа к объектам в журнал может быть записано неоправданно много событий. Так, при активизации двойным щелчком текстового файла из программы Windows Explorer происходит запуск программы WordPad. При этом фиксируется более 20 событий, связанных с доступом к данному файлу и к каталогу, где он находится.

Аудит объектов обычно используется применительно к обычным приложениям, которые работают с отдельными файлами, например к приложениям из комплекта Microsoft Office. Специальные клиент-серверные приложения, такие, как SAP, работают с таблицами, расположенными в нескольких больших файлах базы данных SQL Server. Аудит таких файлов обычно сводится к записи одного события при запуске информационной службы и одного — при ее остановке. При этом не остается сведений о том, какой пользователь выполнял те или иные транзакции или в каких таблицах он менял данные. Эту информацию могут сохранять только сами приложения. Зато аудит таких монолитных файлов помогает выяснить, не пытался ли кто-то заменить файлы базы данных в тот момент, когда SQL Server был остановлен. Это вполне возможно, а перезапущенная прикладная служба не способна заметить подмену.

РИСУНОК 2. Событие номер 560.

Основные два события аудита доступа к объектам: object opened и handle closed. Первое фиксирует открытие объекта (номер 560) , а второе — его закрытие (событие 562). Это взаимодополняющие друг друга события, подобные событиям входа и выхода из системы. Успешное событие номер 560 (см. Рисунок 2) записывает информацию об открытом объекте, а также имя пользователя и название приложения, которое воспользовалось объектом, тип доступа и дескриптор Handle ID.

Handle ID является уникальным кодом для контроля операционной системы за каждым объектом. Он напоминает описанный выше номер сессии пользователя. Найдя пару событий открытия и закрытия (560 и 562) с одним и тем же значением Handle ID, можно выяснить время работы пользователя с данным объектом. Вместе с этим дескриптором событие номер 560 записывает и номер сессии пользователя (см. Рисунок 2), что позволяет выяснить, в какой именно сессии тот обращался к объекту.

События хранят информацию о двух пользователях — об основном и о клиенте. При открытии файла на локальном компьютере с помощью обычного приложения, такого, как Microsoft Word, существенна только информация об основном пользователе. Однако при доступе к объекту из клиент-серверных приложений, которые разграничивают доступ к данным на основе базы пользователей системы, фиксируются оба типа пользователей: основной — соответствует учетной записи клиент-серверного приложения, а клиентский — соответствует пользователю, от имени которого работает сервер. Типичным примером является доступ к файловым ресурсам сервера. Так, при доступе к файлу на другом компьютере через сеть служба Workstation обращающегося к файлу компьютера соединяется со службой Server компьютера с предоставляемым ресурсом, при этом происходит тип 3 входа в систему. Перед обработкой любого запроса сервер аутентифицирует пользователя и записывает события доступа к объекту с указанием основного пользователя и клиента. В этом случае основным пользователем будет SYSTEM, поскольку именно под данной учетной записью запускается служба Server. Информация о клиенте соответствует имени пользователя, которое применялось для доступа к ресурсу; обычно это одна из учетных записей пользователей домена.

Поле типа доступа Accesses в событии номер 560 хранит вид использованного метода доступа к объекту. Значения этого поля соответствуют возможным типам полномочий доступа к объектам ACL. Так, при редактировании текстового файла в редакторе WordPad Windows NT фиксирует событие 560 с типом доступа для чтения ReadData, записи WriteData и добавления AppendData.

Событие 560 также сохраняет информацию о номере процесса Process ID. Этот номер позволяет определить, какая именно программа обратилась к объекту. Например, можно точно выяснить, использовалось ли при редактировании текстового файла приложение Word, WordPad или Notepad. Однако это при условии, что редактировался локальный файл. Если же пользователь обращался к объекту через сеть, фиксируется номер процесса, соответствующий серверному приложению.

Третьим важным событием в категории аудита объектов является событие номер 564, удаление объекта — object deleted. Оно записывает только дескриптор и номер процесса. Чтобы разобраться, какой именно объект и каким пользователем был удален, необходимо отыскать по значению Handle ID соответствующее событие 560 открытия объекта. В событии номер 560 есть вся необходимая информация о пользователе, так что событие 564 удаления объекта следует связывать именно с ним.

Аудит и анализ доступа к объектам представляется очень мощным средством. Однако анализ — процесс весьма трудоемкий, а аудит может снизить быстродействие системы при активном использовании и большом количестве регистрируемых объектов. Не следует злоупотреблять этим типом аудита. Кроме защиты особо важных ресурсов он часто используется службой безопасности предприятия для сбора сведений о неблагонадежных пользователях. Известны случаи, когда аудит ставился на специально подбрасываемые пользователям файлы типа Зарплата.xls только лишь с целью выявить потенциальных злоумышленников. Подобный подход требует строгой проработки. Ну и, конечно, не надо забывать включать аудит доступа к объектам системы в приложении User Manager на той системе, где эти объекты находятся, а не только на рабочей станции пользователя.

Аудит выполняющихся задач

РИСУНОК 3. Событие номер 592.

Эта категория аудита в приложении User Manager называется аудитом выполняющихся задач — process tracking, а в документации по Windows NT и в программе Event Viewer используется термин «детальный аудит» — detailed tracking. Как бы то ни было, данная категория позволяет проследить за тем, какие именно программы были запущены на рабочей станции и какие программы выполнялись на сервере. В этой категории также существуют два основных события — создание нового процесса, событие номер 592, и завершение процесса, событие номер 593. Найдя пару событий 592 и 593, имеющих один и тот же номер процесса Process ID, можно определить общее время работы того или иного приложения. Поле названия исполнительного модуля Image File Name хранит имя файла, соответствующего приложению. Так, при запуске WordPad это поле будет содержать значение WORDPAD.EXE (см. Рисунок 3). К сожалению, событие не записывает полный путь, и судить о точном размещении исполняемого файла нельзя. В поле имени пользователя User Name хранится информация о том, кто запустил приложение. Кроме того, по значению поля номера сеанса Logon ID пользователя можно отыскать соответствующее событие номер 528 и выяснить все подробности о сеансе, в котором запускалось приложение. С помощью поля номера запустившего приложение процесса Creator Process ID можно найти соответствующее событие номер 592, из которого выяснить, какая программа инициировала запуск нового процесса.

Аудит выполняющихся задач может оказаться очень полезным на рабочих станциях, в особенности при изучении активности тех или иных пользователей. Если при этом задействовать аудит доступа к объектам на серверах, то можно построить довольно четкую картину работы пользователей.

Аудит сеансов работы пользователей, аудит доступа к объектам системы и аудит выполняющихся задач являются тремя важнейшими категориями в журнале безопасности Windows NT. Можно связать сеансы работы пользователей, процессы и доступ к объектам и построить точную картину деятельности пользователей. К сожалению, Event Viewer не способен фильтровать события по значениям их параметров, так что использовать номера Logon ID, Process ID и Handle ID весьма трудно. Однако можно применить функцию поиска по значению параметра и вручную составить необходимые цепочки событий. Можно также воспользоваться другими программами обработки журнала безопасности Windows NT, которые позволяют отфильтровывать события по различным критериям.

При настройке аудита журнала для этих трех категорий нужно знать, какие компьютеры (рабочие станции, серверы, контроллеры домена) в какие журналы будут записывать те или иные события. Следует помнить, что аудит доступа к объектам системы и аудит выполняющихся задач могут существенно понизить быстродействие системы. В следующий раз мы рассмотрим остальные категории аудита, как-то: аудит управления учетными записями пользователей, изменения системной политики, использования полномочий и системных событий. 

wininfo.org.ua

Как защитить журнал событий Windows? Защита журнала событий

Что такое журнал событий в Widnows?

Журнал событий (Event Log) в ОС Windows — стандартный метод для программ и операционной системы записи и централизованного хранения данных о важных программных и аппаратных событиях. Служба журналов событий хранит события от разных источников в общем журнале событий, приложение просмотра событий дает возможность пользователю наблюдать за журналом событий, программный интерфейс (API) дает возможность программа вести запись в журнал событий и просматривать имеющиеся там записи.

Как просмотреть журнал событий?

Чтобы просмотреть журнал событий в Windows XP, зайдите в «Панель управления -> Администрирование -> Просмотр событий».

Также для просмотра журнала событий можно использовать 2 программы:

  • Eventlogsourcesview — простая утилита которая отображает все данные из журнала событий.
  • LastActivityView — утилита которая показывает журнал активности пользователя

Защита файлов журнала событий Windows

Операционная система Windows имеет очень мощные возможности протоколирования. Но к сожалению, по умолчанию журнал событий(Event Viewer) не защищен от несанкционированного доступа или изменения. Несмотря на то что события просматриваются с помощью Event Viewer, журнал событий представляет собой обычный файл такой же, как и остальные. Для их защиты от доступа необходимо лишь найти эти файлы и применить к ним соответствующие списки ACL(список контроля доступа).

Все записи журнала событий находятся в ключе реестра

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\EventLog

Данный ключ содержит подключи, которые называются файлами журнала.

  • AppEvent.Evt — файл журнала приложений для событий приложений и служб;
  • SecEvent.Evt — файл журнала безопасности для событий системы аудита;
  • SysEvent.Evt — файл системного журнала для событий драйверов устройств.

Если только расположение файлов не было изменено с помощью реестра, то они должны быть в каталоге %SystemRoot%\system32\config.

Следует отметить, что журналы Windows нее занимают много системного места. Не следует считать, что их надо постоянно чистить.

С журналом приложения, безопасности и системным протоколом сопоставлены файлы SysEvent.Evt, AppEvent.Evt и  соответственно SecEvent.Evt . Для ограничения доступа к ним только с помощью учетной записи администратора примените к ним ACL. Это можно выполнить с помощью диалогового окна свойств файла. Перейдя на вкладку Безопасность (Security), удалите на ней всех пользователей и группы, кроме Administrators и SYSTEM.

www.spy-soft.net

Журнал безопасности в Windows 2003 | Windows IT Pro/RE

событий (ID) и кодами, по-прежнему остаются весьма туманными, а соответствующие описания в документации — неточными. К тому же здесь мы вновь сталкиваемся с теми же проблемами построения отчетов, архивирования, оповещения и объединения данных, которые имели место в Windows NT Server. Дополнительные трудности также связаны со страстью Microsoft к внесению в продукты множественных изменений в интерпретацию ID от версии к версии. Однако, если иметь под рукой необходимые инструменты и знать, что именно следует искать, из журнала безопасности можно почерпнуть очень много ценной информации.

В этой первой статье из планируемой серии материалов, посвященных журналам безопасности Windows 2003, я представлю общий обзор политики аудита и структуры самого журнала безопасности, что наверняка будет полезно для новичков в данной области. Более продвинутых «следопытов» журналов безопасности может заинтересовать информация, содержащаяся в примечаниях «Новое в Windows 2003» по каждой из рассматриваемых здесь категорий. В примечаниях содержится обзор тех существенных изменений, которые претерпел журнал безопасности системы Windows 2003. На экране 1 показана закладка Filter диалогового окна Event Viewer?s Security Properties, из которой следует, что все события, связанные с системой безопасности, делятся на девять категорий аудита. В последующих статьях будет более подробно рассмотрена каждая из этих категорий, а также будет показано, как можно извлечь из этих ценных ресурсов максимальное количество информации.

Экран 1. Категории системы безопасности в Event Viewer

Event Viewer

Журнал безопасности можно просматривать с помощью оснастки Event Viewer консоли Microsoft Management Console (MMC). События отображаются в виде некоторого набора стандартных полей, и каждый ID имеет уникальное описание. Стандартными являются поля идентификатора (ID), даты (date), времени (time), имени пользователя (username), имени компьютера (computer name), источника (source), категории (category) и типа (type). Для многих ID, в соответствии с архитектурой системы безопасности Windows, поле имени пользователя отображается как not useful (не используется), соответственно в таких случаях нужно в описании события просматривать поля, содержащие относящуюся к пользователю информацию. В поле имени компьютера всегда содержится имя локальной системы, поэтому информация из этого поля может быть полезной в основном в тех случаях, когда в общую базу данных объединяется информация из журналов нескольких разных компьютеров. Поле источника служит для того, чтобы отображать информацию о том, какой компонент системы или приложение послужили причиной данного события, но при этом для всех событий, занесенных в журнал безопасности, в данном поле будет установлено значение Security. В поле категории отображается одна из девяти категорий аудита, а поле типа может содержать значение Success Audit (аудит был успешен) или Failure Audit (неудачная попытка аудита). Таким образом, по этому полю можно отделить, например, события успешной регистрации в системе от отказов в регистрации. Описание события представляет собой совокупность статического текста на обычном языке и изменяемого списка динамических строк, вставляемых в определенные позиции в этом статическом тексте. Наиболее важная информация по многим событиям содержится именно в строках описания, существуют и программные инструменты для анализа этих данных и построения соответствующих отчетов.

В утилите Event Viewer имеется ряд механизмов поиска и фильтрации, но их возможности весьма ограниченны. Посредством данной утилиты можно выполнять сохранение и/или очистку журнала безопасности. Для сохранения копии журнала (после щелчка правой кнопкой и выбора пункта Save Event Log As) можно выбрать один из трех предлагаемых форматов: «родной» формат Event Viewer (файл с расширением .evt), формат данных, разделяемых запятой (Comma-Separated Value CSV), или формат с разделителем в виде табуляции.

С помощью Event Viewer можно просматривать как сохраненные копии, так и действующие журналы на удаленных системах, и обычно все это работает хорошо до тех пор, пока вы не попытаетесь просмотреть журнал системы с другим языком по умолчанию или другой версией Windows. В подобных случаях при просмотре описания события может оказаться, что в данном поле отсутствует статический текст, а есть только вставки из динамических строк. Еще надо отметить, что просмотр объемного журнала событий через соединение по распределенной сети может происходить весьма медленно. При этом, если в процессе просмотра журнала будет осуществляться запись в него новых событий, система будет выдавать сообщения об ошибках, информирующие о регистрации новых событий.

В Event Viewer можно задать максимально допустимый размер журнала безопасности и предопределить те действия, которые система Windows должна выполнить при достижении журналом максимального размера. Чтобы увидеть окно установки этих параметров, следует щелкнуть правой кнопкой мыши на соответствующем журнале и выбрать пункт Properties («Свойства»). Здесь можно предписать Windows при необходимости перезаписывать более ранние события, прекращать дальнейшую регистрацию до тех пор, пока кто-либо не очистит журнал, или перезаписывать события, произошедшие ранее заданного количества дней. В последнем случае при заполнении журнала дальнейшая запись событий будет временно прекращена, пока не пройдет достаточно времени для того, чтобы в журнале появились события, удовлетворяющие установленным временным критериям и, соответственно, допускающие удаление.

Категории аудита

Можно настроить Windows 2003 таким образом, чтобы в журнал безопасности записывались только те события, которые соответствуют заданным категориям аудита. Для этого в списке из девяти категорий политики аудита нужно выбрать только те, что представляют интерес для занесения соответствующих им событий в журнал. Чтобы просмотреть действующие в данный момент настройки политики аудита компьютера, запустите, как показано на экране 2, редактор групповых политик (Group Policy Editor, GPE) и раскройте следующую ветвь: Local Computer PolicyComputer ConfigurationWindows SettingsSecurity SettingsLocal PoliciesAudit Policy. Обратите внимание, что порядок перечисления и наименования категорий журнала безопасности (экран 1) и соответствующих им политик аудита (экран 2) слегка различаются. Если посмотреть на экран 2, увидим, что для каждой категории можно включить аудит событий с успешным и/или неудачным результатом либо вообще отключить аудит для данной категории событий. Например, можно для категории Audit account logon events (выполнять аудит попыток регистрации с учетной записью в системе) включить аудит только для неудачных попыток, в результате чего в журнале событий Windows будут фиксироваться только те попытки регистрации в системе, которые по каким-либо причинам закончились неудачей.

Экран 2. Политики аудита системы безопасности

Упомянутые девять категорий аудита охватывают весьма широкий круг действий. Можно наблюдать за процедурами регистрации в системе и аутентификацией, за работой администратора, за поддержкой пользователей, групп и компьютеров, за действиями пользователей, связанными с доступом к файлам, за изменениями важных настроек параметров безопасности, за выполнением тех или иных программ, за изменениями свойств в Active Directory (AD) и т. д. Ниже приводятся краткие описания для каждой категории событий.

Регистрация и аутентификация

Одним из наиболее эффективных методов контроля действий пользователей и выявления атак на системы являются наблюдения за событиями регистрации в системе. Поскольку среда Windows имеет доменную архитектуру, для процессов регистрации в системе и аутентификации применяются различные подходы: если пользователь осуществляет регистрацию на своем компьютере при помощи доменной учетной записи, то данная система должна пройти процедуру аутентификации в AD на соответствующем контроллере домена (DC). Для отслеживания каждого из типов этих действий (или обоих вместе) в системе безопасности используются две категории событий: с помощью категории Logon/Logoff выполняется аудит событий, связанных с регистрацией, а категория Account Logon позволяет отслеживать события аутентификации.

Если мы вспомним эпоху Windows NT, то там категория Account Logon отсутствовала, а была только категория Logon/Logoff, что создавало значительные проблемы при необходимости отслеживать попытки аутентификации в домене. Информация о событиях категории Logon/Logoff записывалась в журналы тех компьютеров, где эти события произошли, т. е. в журналы рабочих станций и серверов домена, но не контроллеров домена. Поэтому, если требовалось отследить неудачные попытки регистрации в системах, приходилось просматривать журналы событий на каждой рабочей станции и сервере домена. Но еще хуже, что не было возможности отслеживать попытки регистрации с неавторизованных компьютеров.

Ситуация изменилась с появлением семейства продуктов Windows 2000, в них уже была предусмотрена категория Account Logon (хотя, на мой взгляд, название для нее было выбрано неудачно — правильнее было бы назвать эту категорию Authentication). Теперь стало возможным регистрировать все происходящие в домене события категории Account Logon на контроллере домена. Правда, при этом все равно требовалось отслеживать события на всех контроллерах домена, но, согласитесь, это намного лучше, чем просматривать журналы безопасности на каждом компьютере сети.

Несмотря на появление категории Account Logon, сохранилась и существовавшая категория событий Logon/Logoff. Причина этого заключается в том, что данная категория может помочь при необходимости проконтролировать весь сеанс регистрации в целом. При этом события категории Account Logon информируют о том, кем, где и когда предпринимались попытки регистрации в системе, а события категории Logoff/Logon сообщают о продолжительности этих сеансов. Кроме того, события типа Logon/Logoff содержат более подробную информацию о причинах неудачи той или иной попытки регистрации в системе.

Новое в Windows 2003. В Windows 2000 имеется набор идентификаторов для событий успешной аутентификации и еще один набор ID для событий неудачной аутентификации. В Windows XP события категории Account Logon не претерпели каких-либо изменений, но в системе Windows 2003 события этой категории содержат некоторые дополнительные данные. Следует также отметить, что разработчики Microsoft, по совершенно необъяснимым причинам, удалили некоторые ID для определенных событий неудачной аутентификации и объединили их с соответствующими событиями успешной аутентификации.

Управление учетными записями и доступ к службе каталогов

С помощью категории Account Management можно отслеживать изменения в учетных записях пользователей, групп и компьютеров, кроме того, она незаменима при наблюдении за некоторыми видами действий. Наилучший подход к управлению доступом состоит в том, чтобы предоставлять доступ группам, а не отдельным пользователям. С помощью категории событий Account Management можно легко идентифицировать случаи изменения членства в группах. Во многих случаях злоумышленники, получившие права административного доступа к системе, сначала создают новую учетную запись, а затем используют ее для дальнейших атак. С помощью событий категории Account Management факт создания новой учетной записи может быть легко выявлен. Использование категории Account Management может также помочь заставить администратора более ответственно относиться к своей работе. Если кем-то была случайно удалена учетная запись пользователя или внесены некорректные изменения в настройки пользователя или группы, то с помощью аудита событий категории Account Management подобные действия можно отследить.

Категория Directory Service Access обеспечивает низкоуровневый аудит объектов AD и их свойств. Поскольку данная категория имеет непосредственное отношение к AD, то активировать аудит подобных событий на системах, которые не являются контроллерами домена, не имеет ни малейшего смысла. Данная категория в значительной степени пересекается с Account Management, поскольку пользователи, группы и компьютеры тоже являются объектами AD. Но если отчеты Account Management содержат данные по высокоуровневым изменениям для пользователей, групп и компьютеров, то, применяя категорию Directory Service Access, можно обеспечить аудит объектов AD (в том числе пользователей, групп и компьютеров) на очень низком уровне. В категории Account Management каждому типу объектов и каждому событию доступа к объекту соответствует уникальный идентификатор ID. С другой стороны, в категории Directory Service Access для всех типов действий существует единственный идентификатор с ID 566. К ID 566 относятся тип объекта, имя объекта, имя пользователя, получившего доступ к объекту, а также тип доступа. В примере события, показанном на экране 3, администратор изменил в учетной записи Susan параметр job title.

Хотя категория Directory Service Access обладает весьма богатыми возможностями, тем не менее использоваться может лишь небольшая их часть. На контроллерах доменов Windows 2000 политика аудита событий Directory Service Access настроена по умолчанию таким образом, чтобы в журнал записывались как удачные, так и неудачные попытки изменений объектов AD, что приводит к наличию огромного количества событий. Отметим также, что названия типов объектов и свойств поступают в события с ID 566 непосредственно из схемы AD и могут при этом выглядеть весьма загадочно. Например, поле user?s city (город) отображается в виде «/» (местонахождение) а поле last name (фамилия) представлено в виде sn (surname). Обычно для обеспечения аудита событий, связанных с пользователями, группами и компьютерами, наибольший практический интерес представляет категория Account Management. Однако при этом следует понимать, что выполнять аудит изменений, вносимых в другие важнейшие объекты AD, такие как групповые политики (GPO) или организационные подразделения (organizational unit, OU), можно только с помощью категории Directory Service Access.

Новое в Windows 2003. В Windows 2003 исправлена имевшаяся в Windows 2000 ошибка, связанная с изменениями и сбросом пользовательского пароля. В документации на Windows 2000 указывается, что сбросу пароля в журнале событий соответствует ID 628, хотя на самом деле процедурам как сброса, так и изменения пароля в системном журнале соответствует один и тот же ID 627 и они всегда отображаются в отчетах как события смены пароля. В Windows 2003 смене пароля соответствует ID 627, а сбросу пароля — ID 628.

Аудит доступа к файлам

В принципе с помощью категории Object Access можно следить за доступом к файлам, папкам, принтерам, разделам реестра и системным службам, но в большинстве случаев данная категория используется для отслеживания доступа к файлам и папкам. Как только будет включен аудит по данной категории, в журнале безопасности сразу же отобразится некоторое количество событий, касающихся доступа к объектам в базе безопасности SAM. Однако каких-либо других событий, связанных с доступом к файлам или другим объектам, вы здесь, вероятнее всего, не увидите, поскольку каждый объект имеет свои настройки параметров аудита, а по умолчанию почти у всех объектов аудит отключен. Это правильная практика, поскольку, если в системе будет включен аудит попыток доступа к каждому файлу или объекту, то данная система до своей полной остановки будет заниматься только обработкой этих событий, а ее журнал безопасности быстро переполнится, вне зависимости от назначенного ему объема. Я рекомендую применять эту категорию только к критически важным файлам, действительно требующим механизмов слежения за доступом к ним.

Для того чтобы активизировать аудит событий для выбранного объекта, нужно открыть его диалоговое окно свойств, выбрать закладку Security, нажать кнопку Advanced, выбрать закладку Auditing, после чего нажать кнопку Add. Например, на экране 4 можно увидеть настройку параметров аудита для файла 1st Quarter Cost Centers.xls, который я открыл из Windows Explorer. Обратите внимание, что можно указывать конкретных пользователей или группы, доступ которых к данному файлу необходимо отслеживать, можно назначать аудит лишь для конкретного типа доступа либо аудит только успешных (или неудачных) попыток доступа к данному объекту. Как только будет включен аудит для соответствующего объекта, Windows начнет регистрировать события открытия, закрытия и другие типы событий для данного объекта согласно выбранной для него политике аудита.

Экран 4. Настройки аудита для объекта

Новое в Windows 2003. Безусловно, журнал безопасности в Windows 2000 выполняет очень важную функцию, информируя о том типе доступа к объекту, который имеет пользователь или приложение, но при этом остается неизвестным, что в действительности пользователь или приложение делают с этим объектом. Предположим, что пользователь А открыл документ, на который у него есть разрешения на чтение и запись. При этом в журнал Windows 2000 записывается событие с ID 560, которое говорит о том, что пользователь, имеющий разрешения доступа List Folder / Read Data и Create Files / Write Data, открыл файл. Когда А закроет файл, в журнал Windows 2000 будет занесено событие с ID 562, означающее, что пользователь закрыл файл. В Windows 2003 добавлено новое событие с ID 567. Если пользователь А изменит содержимое файла на компьютере с Windows 2003, в журнале между событиями открытия и закрытия соответствующего файла будет зарегистрировано событие с ID 567. В нем содержится информация о названии объекта, пользователе и том типе доступа, который этот пользователь в действительности применял. Если в данном месте журнала событие с ID 567 не зарегистрировано, это говорит о том, что пользователь не изменял содержимое файла.

Слежение за выполнением программ

Категория Detailed Tracking предоставляет администратору возможность мониторинга каждой программы, запущенной на системе. Можно контролировать запуск (ID 592) и закрытие (ID 593) пользователями любых приложений. Эти два события могут быть связаны друг с другом через идентификатор процесса (process ID), который можно найти в описаниях обоих событий. Для того чтобы получить полное представление о сеансе работы пользователя, можно задействовать механизмы слежения за процессами с аудитом процедур входа/выхода (logon/logoff), а также открытия/закрытия файлов (file open/close). При этом будет видно, когда пользователь регистрировался в системе, какие запускал программы и к каким файлам из этих программ обращался.

Новое в Windows 2003. В Windows 2003 в категорию Detailed Tracking добавлено два новых события. Событие с ID 601 позволяет отслеживать моменты установки в систему новых служб, что может пригодиться для контроля установки служб на серверах и рабочих станциях с целью проверки их легитимности и выявления наличия несанкционированных служб. При этом нужно понимать, что данное событие может применяться только к системным службам, но не к приложениям, запущенным пользователем на компьютере. Кроме того, для выявления «троянцев» и шпионских программ данное событие также неприменимо, поскольку подобного рода программы обычно не устанавливают себя на системы в качестве служб. Событие с ID 602 информирует о фактах создания задач для службы планировщика, но при этом не отслеживаются моменты внесения изменений, удаления или попыток запуска кем-либо этих задач.

Права пользователей

Для обеспечения контроля возможностей выполнения пользователями функций системного уровня, таких как изменение системного времени или выключение, в Windows применяется система прав пользователей (привилегий). Контроль использования этих прав может быть реализован с помощью категории Privilege Use. Для большинства прав в журнале Windows регистрируются события Privilege Use (ID 577 или 578), однако некоторые виды прав используются настолько часто, что разработчики Microsoft предпочли не регистрировать каждый факт их применения. Вместо этого, когда реализуется какое-либо из этих прав, в журнале Windows просто отражается факт использования права с ID 576.

Новое в Windows 2003. В системе Windows 2000 при попытках просмотреть либо снять содержимое дампа памяти в журнал безопасности заносится событие с ID 578, но в Windows 2003 этого почему-то не происходит. И аналогично, когда кто-то хочет стать владельцем файла или другого объекта, система Windows 2003 не регистрирует никакого события (в Windows 2000 и в этом случае происходит запись события в журнал). Возможно, эти ошибки будут исправлены в первом пакете обновления системы Windows 2003, поскольку в Windows 2000 некоторые ошибки, связанные с аудитом, в выпущенных для данной системы пакетах обновления были устранены.

Изменения политик

В тех журналах безопасности, которые мне довелось просматривать, я так и не обнаружил нескольких событий категории Policy Changes, которые, в соответствии с документацией Microsoft, должны записываться в журнал. Так, одни события, связанные с протоколом IP Security (IPSec), похоже, никогда не регистрируются в журнале (например, ID 613, 614 и 616), в то время как другие (ID 615) регистрируются. И тем не менее категория Policy Changes предназначена для регистрации событий, связанных с изменениями конфигурации параметров безопасности, включая изменения доверительных отношений, политики Kerberos, шифрующей файловой системы EFS и параметров QoS.

Новое в Windows 2003. В системе Windows 2000 событие с ID 615 относилось к категории Detailed Tracking, но в Windows 2003 оно перекочевало в категорию Policy Change. И это всего лишь один из примеров тех загадочных и ненужных изменений, которые мне удалось выявить при сравнении событий в системах Windows 2000 и Windows 2003. А вот еще одно интересное изменение: в документации утверждается, что при назначении и аннулировании пользовательских прав в журнал Windows заносятся события, имеющие соответственно ID 608 и 609. Однако в журнале Windows 2000 ни одно из этих событий не регистрируется. Что касается системы Windows 2003, то здесь при изменениях в правах пользователей происходит запись в журнал событий с ID 608 и 609, за исключением тех случаев, когда это связано с изменениями прав регистрации, таких как Allow logon locally и Access this computer from the network. В Windows 2003 для такого рода событий, в отличие от заявленных в документации ID 608 и 609, используются идентификаторы ID 621 и 622 (соответственно для предоставления и лишения прав). Подобные необъяснимые и недокументированные изменения приводят к нарушениям работы программ мониторинга и построения отчетов, которые выполняют фильтрацию и анализ событий, основываясь на категориях, ID, или на поле, расположенном в определенном месте в описании события.

Системные события

Категория System Events является вместилищем для разнообразных событий, касающихся системы безопасности. В данной категории система предоставляет информацию о процессах начальной загрузки (ID 512) и выключения (ID 513), а также о работе различных компонентов системы безопасности (в частности, о процессах регистрации и процедурах аутентификации) во время начальной загрузки системы. Здесь есть два чрезвычайно полезных события, а именно: событие с ID 517, информирующее пользователя об очистке журнала событий и о том, кто это сделал, и событие с ID 520, которое присутствует только в Windows 2003.

Новое в Windows 2003. При тестировании Windows 2003 в категории System Events единственным новым событием, которое мне действительно удалось обнаружить, было событие с ID 520. Наличие данного события в журнале говорит о том, что системные время и дата были изменены, здесь же в его описании приводятся новое и старое значения даты и времени.

Журнал безопасности является чрезвычайно мощным средством контроля действий пользователей и персонала подразделений ИТ, а также обнаружения вторжений, но при этом весьма непростым средством. Чем более глубоко удастся вникнуть в особенности его структуры, тем больших успехов можно добиться при работе с ним и тем больше данных можно извлечь из любых журналов безопасности с помощью имеющихся средств построения отчетов и выдачи оповещений.

Примечание автора

Данная серия статей построена на базе курса Security Log Secrets компании Monterey Technology Group.

Редактор Windows IT Pro и ведущий инструктор и разработчик курсов для программы по безопасности Windows NT/2000 института MIS Training. Его компания, Monterey Technology Group, занимается консалтингом в области информационной безопасности. Связаться с ним можно по адресу: [email protected] techgroup.com

www.osp.ru

Анализируем журнал безопасности Windows NT | Windows IT Pro/RE

24.04.2000 Франклин Р. Смит

Существует три основные категории такого аудита — это аудит сеансов работы пользователей, аудит доступа к объектам системы и аудит выполняющихся задач. Эти категории дают основную информацию при наблюдении за действиями пользователей. Системная политика аудита настраивается в меню Policies-Audit-Audit Policy, вызываемом из программы User Manager (см. Экран 1). Данное диалоговое окно позволяет выбрать, какие из семи категорий фиксировать в локальном журнале безопасности, а какие нет.

Сеансы работы пользователей

ЭКРАН 1. Настройка аудита системы.

Многие администраторы просматривают журнал безопасности Windows NT и видят события входа пользователей в систему и выхода из нее, однако часто не могут правильно оценить увиденное. Здесь следует обращать внимание на отдельные параметры событий. Так, событие успешной регистрации пользователя в системе имеет номер (ID) 528 (см. Рисунок 1). При отказе в регистрации пользователя фиксируется событие с другим номером, который зависит от причины отказа. Полный список событий можно найти в документе Microsoft «Описание событий аутентификации» (см. http://support.microsoft.com/support/kb/articles/q174/0/74.asp). Событие с номером 538 означает завершение сеанса, начало которого зафиксировано событием 528. Событие номер 528 имеет несколько очень важных дополнительных параметров. Имя пользователя и домен определяют вошедшего в систему пользователя или то, чья учетная запись была при этом задействована. Номер сеанса пользователя Logon ID — это уникальный для системы код, присваиваемый любому активному сеансу работы пользователя с системой. Именно он будет записан в событии завершения сеанса. Это позволяет определить общее время работы пользователя при анализе событий 528 и 538 с одним и тем же номером сеанса.

РИСУНОК 1. Событие номер 528.

Событие входа в систему также фиксирует информацию о типе входа Logon Type, т. е. то, как пользователь вошел в систему. Тип входа 2 соответствует интерактивному входу с консоли, например, с помощью монитора и клавиатуры. Если пользователь подключается к диску на другом компьютере или как-либо еще использует сетевой ресурс, то выполняется сетевой вход с типом 3. Так, если был зафиксирован тип входа 2, то кто-то вошел в систему с локальной консоли именно этого компьютера, а если тип 3, значит, кто-то подключился к системе по сети. Тип входа 5 фиксируется при запуске службы с указанием конкретной учетной записи пользователя. При использовании планировщика задач производства независимых компаний, например Argent Queue Manager компании Argent Software, система фиксирует событие номер 528 с типом входа 4, что соответствует заданию на выполнение командного файла. При разблокировании рабочей станции записывается событие с типом входа 7.

Фиксируются также все неудачные попытки входа в систему Logon Failure. При этом чаще всего записывается системное событие 529, соответствующее указанию неверного имени пользователя или пароля — Unknown user name or bad password.

ЭКРАН 2. Выбор рабочих станций, с которых пользователь имеет право войти в систему.

Если учетная запись пользователя недоступна или заблокирована, то попытка входа отвергается, и записывается событие с номером соответственно 531 или 539. Событие номер 530 указывает, что пользователь пытался войти в систему в недозволенное ему время или день недели. Если учетная запись пользователя просрочена или устарел пароль, то фиксируется соответственно событие 532 или 535. Если пользователь ограничен входом лишь на некоторые рабочие станции (см. Экран 2), а он пытается войти с другого компьютера, то запишется событие номер 533. Можно ограничить права пользователя на выполнение определенных типов входа в различные системы. Если пользователь, которому запрещен доступ к какому-то компьютеру по сети, все же пытается обратиться к его ресурсу или реестру, то он получит отказ, а в журнал безопасности запишется событие с номером 534. Такое же событие будет зафиксировано при попытке пользователя войти в систему с консоли, если это ему запрещено. При попытке запустить службу с использованием учетной записи пользователя, не имеющей права на запуск служб (права Logon as a service), также будет зафиксировано событие номер 534. Кроме того, событие 534 запишется и при попытке запуска задания с исполнением командного файла от имени учетной записи без права Logon as a batch job. При всех других отказах в аутентификации фиксируется событие с номером 537, т. е. An unexpected error occurred during logon — отказ по неизвестной причине. Тип входа фиксируется при всех попытках входа в систему, независимо от их результата. Более подробную информацию можно найти в документе Microsoft «Аудит аутентификации пользователей» (см. http://support.microsoft.com/support/kb/articles/q174/0/73.asp).

Аутентификация в Windows NT имеет распределенную природу. Особенно ярко это проявляется при слежении за входом в систему и выходом из нее. Зачастую аудит на рабочей станции, имеющей учетную запись в домене, воспринимается уже как «вход в домен», вместо настоящего момента входа в домен или же входа на контроллер домена с использованием учетной записи домена. Аудит на рабочей станции означает лишь регистрацию на рабочей станции. Но поскольку используется учетная запись домена, сама рабочая станция не может аутентифицировать пользователя. Рабочая станция лишь посылает сведения о пользователе на контроллер домена по протоколу NTLM (NT LAN Manager). Контроллер домена проверяет правильность пароля и сразу же забывает о пользователе. Сеанс работы пользователя поддерживает сама рабочая станция до самого момента выхода из системы. Разумеется, именно рабочая станция и записывает в свой журнал системы безопасности информацию о сессии пользователя.

Для получения общей картины работы пользователей домена зачастую можно обойтись без анализа журналов безопасности на всех без исключения рабочих станциях. Дело в том, что сразу же после успешного входа пользователя обычно выполняется автоматическое подключение сетевых дисков, расположенных на файл-серверах. Именно журналы безопасности файл-серверов и следует просматривать, отслеживая события входа в систему с типом 3. Из-за отсутствия централизованной фиксации входов в систему для домена бывает трудно отследить попытки несанкционированного доступа. Однако, хотя контроллеры домена и не фиксируют все неудавшиеся попытки входа, они записывают все блокировки учетной записи (событие номер 644), которые являются следствием нескольких безуспешных попыток входа подряд. Подробнее о блокировках учетных записей рассказано в документе Microsoft «События при блокировках учетных записей хранятся в журнале безопасности контроллера домена» (см. http://support.microsoft.com/support/kb/articles/q182/9/18.asp).

Необходимо отслеживать использование локальных учетных записей на отдельных системах. Входящие в домен рабочие станции и обычные серверы аутентифицируют пользователей на контроллерах доменов, а также ведут собственные локальные базы пользователей (SAM). И пользователи, и взломщики могут задействовать эти локальные учетные записи, чтобы попытаться войти в систему локально или через сеть. Во всех системах существует встроенная административная учетная запись Administrator. О том, как предотвратить нежелательные попытки ее использования, рассказано в мартовском номере Windows NT Magazine/RE в статье Франклина Р. Смита «Защитим права администратора!».

Для эффективного наблюдения за сеансами работы пользователей нужно хорошо знать, что и где проверять. Для отслеживания входа в систему в первую очередь следует просматривать журналы безопасности на рабочих станциях и простых серверах и искать в них события с номерами 528 и 538. Возможные попытки незаконного проникновения в систему отслеживаются среди событий с номерами от 529 до 537, а также 539 на всех потенциально доступных для нападения компьютерах.

Доступ к объектам системы

Аудит доступа к объектам включает в себя всего три события, однако он очень важен, поскольку позволяет отслеживать обращения к любым объектам, включая каталоги, файлы, принтеры и ключи реестра. Для использования перечисленных возможностей необходимо включить опцию регистрации доступа к объектам в меню настройки аудита системы, а также указать все объекты, доступ к которым требуется регистрировать. Список регистрируемых действий для объекта очень напоминает список прав доступа к этому объекту (ACL). В таком списке указаны пользователи и их действия, подлежащие регистрации.

Аудит доступа к объектам ведется в журнале событий, а не в журнале транзакций. Поэтому Windows NT не фиксирует, что именно сделал пользователь с объектом, а указывает только тип доступа к данному объекту. Так, например, можно проследить, что пользователь Иванов открыл файл Зарплата.xls для чтения, записи, выполнения и удаления, однако совершенно невозможно выяснить, внес ли он какие-то изменения, а если да, то какие именно. К тому же при аудите доступа к объектам в журнал может быть записано неоправданно много событий. Так, при активизации двойным щелчком текстового файла из программы Windows Explorer происходит запуск программы WordPad. При этом фиксируется более 20 событий, связанных с доступом к данному файлу и к каталогу, где он находится.

Аудит объектов обычно используется применительно к обычным приложениям, которые работают с отдельными файлами, например к приложениям из комплекта Microsoft Office. Специальные клиент-серверные приложения, такие, как SAP, работают с таблицами, расположенными в нескольких больших файлах базы данных SQL Server. Аудит таких файлов обычно сводится к записи одного события при запуске информационной службы и одного — при ее остановке. При этом не остается сведений о том, какой пользователь выполнял те или иные транзакции или в каких таблицах он менял данные. Эту информацию могут сохранять только сами приложения. Зато аудит таких монолитных файлов помогает выяснить, не пытался ли кто-то заменить файлы базы данных в тот момент, когда SQL Server был остановлен. Это вполне возможно, а перезапущенная прикладная служба не способна заметить подмену.

РИСУНОК 2. Событие номер 560.

Основные два события аудита доступа к объектам: object opened и handle closed. Первое фиксирует открытие объекта (номер 560) , а второе — его закрытие (событие 562). Это взаимодополняющие друг друга события, подобные событиям входа и выхода из системы. Успешное событие номер 560 (см. Рисунок 2) записывает информацию об открытом объекте, а также имя пользователя и название приложения, которое воспользовалось объектом, тип доступа и дескриптор Handle ID.

Handle ID является уникальным кодом для контроля операционной системы за каждым объектом. Он напоминает описанный выше номер сессии пользователя. Найдя пару событий открытия и закрытия (560 и 562) с одним и тем же значением Handle ID, можно выяснить время работы пользователя с данным объектом. Вместе с этим дескриптором событие номер 560 записывает и номер сессии пользователя (см. Рисунок 2), что позволяет выяснить, в какой именно сессии тот обращался к объекту.

События хранят информацию о двух пользователях — об основном и о клиенте. При открытии файла на локальном компьютере с помощью обычного приложения, такого, как Microsoft Word, существенна только информация об основном пользователе. Однако при доступе к объекту из клиент-серверных приложений, которые разграничивают доступ к данным на основе базы пользователей системы, фиксируются оба типа пользователей: основной — соответствует учетной записи клиент-серверного приложения, а клиентский — соответствует пользователю, от имени которого работает сервер. Типичным примером является доступ к файловым ресурсам сервера. Так, при доступе к файлу на другом компьютере через сеть служба Workstation обращающегося к файлу компьютера соединяется со службой Server компьютера с предоставляемым ресурсом, при этом происходит тип 3 входа в систему. Перед обработкой любого запроса сервер аутентифицирует пользователя и записывает события доступа к объекту с указанием основного пользователя и клиента. В этом случае основным пользователем будет SYSTEM, поскольку именно под данной учетной записью запускается служба Server. Информация о клиенте соответствует имени пользователя, которое применялось для доступа к ресурсу; обычно это одна из учетных записей пользователей домена.

Поле типа доступа Accesses в событии номер 560 хранит вид использованного метода доступа к объекту. Значения этого поля соответствуют возможным типам полномочий доступа к объектам ACL. Так, при редактировании текстового файла в редакторе WordPad Windows NT фиксирует событие 560 с типом доступа для чтения ReadData, записи WriteData и добавления AppendData.

Событие 560 также сохраняет информацию о номере процесса Process ID. Этот номер позволяет определить, какая именно программа обратилась к объекту. Например, можно точно выяснить, использовалось ли при редактировании текстового файла приложение Word, WordPad или Notepad. Однако это при условии, что редактировался локальный файл. Если же пользователь обращался к объекту через сеть, фиксируется номер процесса, соответствующий серверному приложению.

Третьим важным событием в категории аудита объектов является событие номер 564, удаление объекта — object deleted. Оно записывает только дескриптор и номер процесса. Чтобы разобраться, какой именно объект и каким пользователем был удален, необходимо отыскать по значению Handle ID соответствующее событие 560 открытия объекта. В событии номер 560 есть вся необходимая информация о пользователе, так что событие 564 удаления объекта следует связывать именно с ним.

Аудит и анализ доступа к объектам представляется очень мощным средством. Однако анализ — процесс весьма трудоемкий, а аудит может снизить быстродействие системы при активном использовании и большом количестве регистрируемых объектов. Не следует злоупотреблять этим типом аудита. Кроме защиты особо важных ресурсов он часто используется службой безопасности предприятия для сбора сведений о неблагонадежных пользователях. Известны случаи, когда аудит ставился на специально подбрасываемые пользователям файлы типа Зарплата.xls только лишь с целью выявить потенциальных злоумышленников. Подобный подход требует строгой проработки. Ну и, конечно, не надо забывать включать аудит доступа к объектам системы в приложении User Manager на той системе, где эти объекты находятся, а не только на рабочей станции пользователя.

Аудит выполняющихся задач

РИСУНОК 3. Событие номер 592.

Эта категория аудита в приложении User Manager называется аудитом выполняющихся задач — process tracking, а в документации по Windows NT и в программе Event Viewer используется термин «детальный аудит» — detailed tracking. Как бы то ни было, данная категория позволяет проследить за тем, какие именно программы были запущены на рабочей станции и какие программы выполнялись на сервере. В этой категории также существуют два основных события — создание нового процесса, событие номер 592, и завершение процесса, событие номер 593. Найдя пару событий 592 и 593, имеющих один и тот же номер процесса Process ID, можно определить общее время работы того или иного приложения. Поле названия исполнительного модуля Image File Name хранит имя файла, соответствующего приложению. Так, при запуске WordPad это поле будет содержать значение WORDPAD.EXE (см. Рисунок 3). К сожалению, событие не записывает полный путь, и судить о точном размещении исполняемого файла нельзя. В поле имени пользователя User Name хранится информация о том, кто запустил приложение. Кроме того, по значению поля номера сеанса Logon ID пользователя можно отыскать соответствующее событие номер 528 и выяснить все подробности о сеансе, в котором запускалось приложение. С помощью поля номера запустившего приложение процесса Creator Process ID можно найти соответствующее событие номер 592, из которого выяснить, какая программа инициировала запуск нового процесса.

Аудит выполняющихся задач может оказаться очень полезным на рабочих станциях, в особенности при изучении активности тех или иных пользователей. Если при этом задействовать аудит доступа к объектам на серверах, то можно построить довольно четкую картину работы пользователей.

Аудит сеансов работы пользователей, аудит доступа к объектам системы и аудит выполняющихся задач являются тремя важнейшими категориями в журнале безопасности Windows NT. Можно связать сеансы работы пользователей, процессы и доступ к объектам и построить точную картину деятельности пользователей (см. Рисунок 4). К сожалению, Event Viewer не способен фильтровать события по значениям их параметров, так что использовать номера Logon ID, Process ID и Handle ID весьма трудно. Однако можно применить функцию поиска по значению параметра и вручную составить необходимые цепочки событий. Можно также воспользоваться другими программами обработки журнала безопасности Windows NT, которые позволяют отфильтровывать события по различным критериям.

При настройке аудита журнала для этих трех категорий нужно знать, какие компьютеры (рабочие станции, серверы, контроллеры домена) в какие журналы будут записывать те или иные события. Следует помнить, что аудит доступа к объектам системы и аудит выполняющихся задач могут существенно понизить быстродействие системы. В следующий раз мы рассмотрим остальные категории аудита, как-то: аудит управления учетными записями пользователей, изменения системной политики, использования полномочий и системных событий.

www.osp.ru

Все о журнале безопасности Windows 2000 | Windows IT Pro/RE

Информация о программах, запускавшихся взломщиком, нередко помогает восстановить полную картину действий постороннего лица, проникшего в сеть. Другими свидетельствами могут служить изменения полномочий и политик или несанкционированная перезагрузка системы.

Контролировать выполнение программ можно с помощью категории Audit process tracking (аудит запуска процесса) Windows 2000. Могут пригодиться и категории аудита действий операционной системы Audit privilege use (аудит использования привилегий), Audit policy change (аудит изменения политики) и Audit system events (аудит системных событий). Наряду с другими категориями аудита, представленными в данной серии статей о журнале безопасности Windows 2000, эти события помогут понять, какие действия предпринимал взломщик, пытавшийся нарушить целостность сети. Список предыдущих статей данной серии о журнале Windows NT Security приведен во врезке «В предыдущих выпусках».

Audit process tracking

Audit process tracking не отслеживает неудачных событий, но когда категория настроена на контроль успешных действий, то фиксируются два события: с ID 592 (создан новый процесс) и с ID 593 (процесс завершен). Категория Audit process tracking указана как Detailed tracking в списке Category оснастки Event Viewer консоли Microsoft Management Console (MMC). Подробнее о том, как активизировать категории аудита, настроить системный журнал Security и использовать оснастку Event Viewer для просмотра журнала безопасности, рассказано в статье «Контроль событий регистрации в Windows 2000» на http://www.osp.ru/win2000/worknt/2001/03/302.htm.

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

Поле Logon ID соответствует ID регистрации, который был назначен Биллу при входе в систему. Данный идентификатор позволяет связать событие создания процесса с событием успешной регистрации с ID 528. Справочный список событий журнала безопасности, упоминаемых в данной серии статей, приведен в Таблице 1. Подробное объяснение событий регистрации дано в статье «Контроль событий регистрации в Windows 2000» (см. ссылку).

Начиная новый процесс, 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_MACHINESYSTEMCurrentControlSetControlLsa: 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 (по адресу: http://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 Maga-zine/RE, № 2, 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.

Рэнди Франклин Смит — редактор Windows 2000 Magazine и президент компании Monterey Technology Group. Он автор публикуемой два раза в месяц колонки Win2K Security для электронного издания Windows IT Security Channel в сети Windows 2000 Magazine Network. Связаться с ним можно по адресу: [email protected]

В предыдущих выпусках

Это пятая статья Рэнди Франклина Смита из серии, посвященной журналу безопасности Windows 2000. Информацию о журнале безопасности Windows NT можно найти в предыдущей серии статей. Ниже приведен список статей обеих серий.

Статьи, посвященные журналу безопасности Windows 2000:

«Контроль событий регистрации в Windows 2000» - http://www.osp.ru/win2000/worknt/2001/03/302.htm

«Аудит событий регистрации пользователя» - Windows 2000 Magazine, 03/2001

«Заглянем в журнал безопасности Windows 2000» - Windows 2000 Magazine, 04/2001

«Аудит доступа к объектам» - Windows 2000 Magazine, 05/2001

Статьи, посвященные журналу безопасности Windows NT:

«Анализируем журнал безопасности Windows NT» - Windows 2000 Magazine, 03/2000

«Контроль использования административных привилегий» - Windows 2000 Magazine, 04/2000

«Инструменты для работы с журналами безопасности» - Windows 2000 Magazine, 06/2000

назад

www.osp.ru

Управление аудитом и журналом безопасности (Windows)

Содержит описание рекомендаций, расположения, значений, управления политикой и вопросов безопасности для параметра политики безопасности Управление аудитом и журналом безопасности.

Справка

Этот параметр политики определяет, какие пользователи могут задавать параметры аудита доступа к объектам для отдельных ресурсов, таких как файлы, объекты Active Directory и разделы реестра. Эти объекты определяют их системные списки управления доступом (SACL). Пользователь, которому назначено это право, может просматривать и очищать журнал безопасности в средстве просмотра событий. Подробнее о политике аудита доступа к объектам можно узнать в разделе Аудит доступа к объектам.

Константа: SeSecurityPrivilege

Возможные значения

  • Пользовательский список учетных записей

  • Администраторы

  • Не определено

Рекомендации

  1. Прежде чем удалять это право для группы, проверьте, зависят какие-либо ли приложения от него.

  2. Обычно не требуется назначать это право группам, кроме группы "Администраторы".

Расположение

Конфигурация компьютера\Параметры Windows\Параметры безопасности\Локальные политики\Назначение прав пользователя

Значения по умолчанию

Значение по умолчанию для этого параметра на контроллерах домена и автономных серверах — «Администраторы».

В следующей таблице приведены фактические и действующие значения по умолчанию политики для последних поддерживаемых версий Windows. Значения по умолчанию также указаны на странице свойств политики.

Тип сервера или объект групповой политикиЗначение по умолчанию

Политика домена по умолчанию

Не определено

Политика контроллера домена по умолчанию

Администраторы

Параметры автономного сервера по умолчанию

Администраторы

Действующие параметры контроллера домена по умолчанию

Администраторы

Действующие параметры рядового сервера по умолчанию

Администраторы

Действующие параметры клиентского компьютера по умолчанию

Администраторы

 

Управление политикой

В этом разделе описаны компоненты, средства и рекомендации, которые помогут в управлении этой политикой.

Чтобы этот параметр политики вступил в силу, перезагружать компьютер не требуется.

Изменения прав пользователя вступают в силу при его следующем входе в учетную запись.

Аудит доступа к объектам не выполняется, если его не включить с помощью редактора локальной групповой политики, консоли управления групповыми политиками (GPMC) или программы командной строки Auditpol.

Подробнее о политике аудита доступа к объектам можно узнать в разделе Аудит доступа к объектам.

Групповая политика

Параметры применяются к объекту групповой политики (GPO) в следующем порядке, что переопределяет параметры на локальном компьютере при следующем обновлении групповой политики.

  1. Параметры локальной политики

  2. Параметры политики сайта

  3. Параметры политики домена

  4. Параметры политики подразделений

Если локальный параметр неактивен (выделен серым цветом), это значит, что в настоящий момент его контролирует объект групповой политики.

Соображения безопасности

В этом разделе описывается, каким образом злоумышленник может воспользоваться компонентом или его конфигурацией, как применить меры противодействия и каковы возможные негативные последствия реализации этих мер.

Уязвимость

Любой пользователь с правом Управление аудитом и журналом безопасности может очистить журнал безопасности, чтобы удалить важные свидетельства несанкционированных действий.

Меры противодействия

Убедитесь, что только у локальной группы "Администраторы" есть право Управление аудитом и журналом безопасности.

Возможные последствия

По умолчанию право Управление аудитом и журналом безопасности назначено только локальной группе "Администраторы".

Предупреждение  

Если его назначить другим группам, удаление этого права может привести к проблемам с производительностью других приложений. Прежде чем удалять это право для группы, проверьте, зависят какие-либо ли приложения от него.

 

Связанные разделы

Назначение прав пользователя

 

 

technet.microsoft.com