Журнал аудита

Аудит в Windows

Журнал аудита

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

В Windows журнал аудита представляет собой файл с именем SecEvent.evt (Security.evtx в Windows 7) – т.н. журнал безопасности (security log), в который заносятся события, сгенерированные системой безопасности во время проверки защиты системы, эти события содержат сведения о входе в систему, доступе к объектам, изменения политики безопасности и другую информацию, связанную с безопасностью. Кстати, кроме этого журнала в системе есть еще два:

SysEvent.evt (System.evtx в Windows 7) - системный журнал (system log) содержит информацию о событиях, относящихся к драйверам устройств и другим компонентам Windows NT. Типы событий, записываемых в системный журнал, задаются самой Windows NT.

AppEvent.evt (Application.evtx в Windows 7) - журнал приложений (application log) содержит события, записываемые приложениями и службами. Какие события будут зафиксированы в этом журнале, решают разработчики соответствующих приложений.

Есть еще и четвертый журнал (в Windows XP) - internet.evt (для Internet Explorer).

Все эти журналы (в Windows 7 относятся к группе «Журналы Windows») расположены

- в Windows XP в поддиректории system32\config (здесь же и файлы реестра)

- в Windows 7 в папке system32\winevt\logs

Каждому журнальному файлу соответствует свой ключ в реестре, эти ключи лежат в ветви реестра (слева в окне редактора реестра): HKLM\system\Current Control Set\services\eventlog). Ведение этих журналов автоматически начинается при запуске Windows (если аудит не выключен).

Формат файла для хранения журналов не документирован фирмой Микрософт. Информация о событиях хранится в файле журнала в бинарном (неформатированном) виде. Ее (информацию о событиях из журнала) можно просмотреть:

- используя стандартную программу просмотра Event Viewer

а) …\system32\Eventvwr.exe

б) Eventvwr.msc (оснастка консоли управления в Win 2000 и Win XP)

- через графический интерфейс (Мой Компьютер—Управление—Просмотр событий Журналы Windows—выбрать журнал)

а командой «Действие — Экспортировать список» можно сохранить данные из реестра в текстовом виде (*.txt) для переноса содержимого в другие программы, такие как электронные таблицы и базы данных.

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

Все пользователи, которые могут читать журнал аудита, могут и очищать его. Факт очистки журнала регистрируется сразу после очистки.

Пользователи, не имеющие возможности читать журнал аудита с помощью утилиты Event Viewer, но обладающие правом чтения файла SecEvent.evt, могут читать этот файл с помощью других программных средств. Поэтому права доступа субъектов к этому файлу должны быть принудительно ограничены, например, так:

Замечание: надо помнить, что действует принцип – запрещено все, что явно не разрешено.

Здесь Auditors - это группа аудиторов, являющаяся подмножеством группы администраторов. Сделать группы аудиторов и администраторов непересекающимися в Windows NT практически невозможно (см. дальше п. " Администраторы и аудиторы").

Размер каждого журнала по умолчанию ограничен (Администратор может изменять - свойствах журнала). Администратор может определить поведение операционной системы при переполнении журнала аудита. Возможны три варианта реакции на эту ситуацию (в WinXP: Мой компьютер à Управление à Просмотр событий à Безопасность (можно и для других журналов) à Свойства (правая кнопка)):

Overwrite Events as Needed (затирать (перезаписывать) старые события по необходимости) — в случае заполнения журнала при записи новых событий операционная система уничтожает самые старые события (по умолчанию);

Overwrite Events Older than N Days (затирать (перезаписывать) события старее N дней) — в случае заполнения журнала при записи новых событий уничтожаются самые старые события, но только если они старше N дней (число N выбирает администратор), иначе новые события игнорируются (не регистрируются) до тех пор, пока не пройдет N дней с момента регистрации самого старого события;

Замечание1: при этом остается невыясненным вопрос – что будет делать система эти N дней: работать (без регистрации событий) или стоять

Замечание2: вместо данной возможности в Windows 7 используется другая: «Архивировать журнал при заполнении, не перезаписвать события»

Do Not Overwrite Events (не затирать (не перезаписывать) события (очистить журнал вручную)) — новые события не регистрируются (до тех пор, пока журнал не будет очищен (в WinXP: Мой компьютер à Управление à Просмотр событий à Безопасность (можно и для других журналов) à Свойства (правая кн.) à Кнопка «Очистить журнал»).

В Windows 7 в настройках групповых политик (gpedit.msc) есть параметр:

Конфигурация компьютера - Конфигурация Windows - Параметры безопасности - Локальные политики - Параметры безопасности ----- параметр Аудит: немедленное отключение системы, если невозможно вести в журнал записи об аудите безопасности.

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

Добавлять записи в журнал аудита может лишь субъект доступа, обладающий соответствующей привилегией. По умолчанию эта привилегия предоставляется только псевдопользователю SYSTEM, эту установку не следует изменять ни в коем случае. Если эта привилегия предоставляется какому-то физическому пользователю, этот пользователь тем самым получает возможность записывать в журнал аудита произвольную информацию, в том числе и информацию, компрометирующую других пользователей. Обычно новые записи в журнал аудита добавляют ядро, подсистема Win32 и подсистема аутентификации Windows NT.

3.5.2 Политика аудита

Чтобы включить регистрацию событий аудита, надо сделать следующее:

1) Включить нужные категории аудита (9 категорий) через локальные политики аудита:

а)

Панель управления à Администрирование à Локальные политики безопасности à Локальные политики à Политика аудита à Нужное включить (выбрать).

б)

Необходимо запустить редактор групповых политик (gpedit.msc) и раскрыть следующую ветвь: Политика лоальный компьютер - Конфигурация компьютера - Конфигурация Windows - Параметры безопасности - Локальные политики - Политика аудита

Конфигурация расширенной политики аудита - политика аудита системы

в) включить службу Журнал событий (в Windows XP) или Журнал событий Windows (в Windows 7). В Windows XP журнал событий можно безболезненно (для системы) отключить (остановить службу) и после перезагрузки ведение журнала прекратится. В Windows 7 Журнал событий Windows также можно остановить, но вместе с ней остановит ся и Планировщик заданий, через который запускаются (при старте Windows) многие важные задачи.

Существуют следующие категории событий аудита:

аудит входа в систему (событий входа в систему)(audit logon events); этот параметр безопасности определяет, подлежит ли аудиту каждая попытка пользователя войти в систему с локальной учетной записью (с того же компьютера, куда входят и на котором находится БД SAM, или с другого по сети) или выйти из системы. Событие регистрируется в локальном журнале безопасности (того же компьютера, куда входят и на котором находится БД SAM).

аудит доступа к объектам; этот параметр безопасности определяет, подлежит ли аудиту событие доступа пользователя к объекту — например к файлу, папке, разделу реестра, принтеру и т.п., — для которого задана собственная системная таблица управления доступом (SACL).

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

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

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

аудит отслеживания процессов (активация программы, завершение процесса); этот параметр безопасности определяет, подлежат ли аудиту такие события, как активизация программы, завершение процесса, повторение дескрипторов и косвенный доступ к объекту

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

аудит событий входа в систему (с [доменной] учетной записью); События этой категории формируются при проверке подлинности учетной записи пользователя домена, выполняемой контроллером домена. Событие регистрируется в журнале безопасности контроллера домена. События выхода из системы не формируются.

аудит управления учетными записями (создания и удаление пользователя, переименование или вкл/выкл учетной записи пользователя, задание или изменение пароля)); этот параметр безопасности определяет, подлежат ли аудиту все события, связанные с управлением учетными записями на компьютере. К таким событиям относятся, в частности, следующие: а) создание, изменение или удаление учетной записи пользователя или группы; б) переименование, отключение или включение учетной записи пользователя; в) задание или изменение пароля.

В Windows XP, Windows Server 2003, Windows Vista, Windpws 7, Windows Server 2008 определено всего 9 категорий аудита. Начиная с Windows Vista и Windows Server 2008 количество подкатегорий событий, выступающих объектами аудита, расширено до 52. Кроме того, если в той же Windows XP параметры аудита можно было задавать лишь через локальные политики, то в Windows Server 2008 R2 и Windows 7 все возможности аудита объединены с групповой политикой. Это позволяет администраторам настраивать и развертывать эти параметры и управлять ими в консоли управления групповыми политиками (GPMC) и оснастке «Локальная политика безопасности» для домена, сайта или подразделения.

2) Для ведения аудита доступа к объектам в дексрипторе защиты объектов (для которых еадо вести аудит доступа) задать (на закладке «Безопасность» (Свойства à Безопасность à Дополнительно à Аудит à Добавить à Пользователь (Выбрать) à Выбрать вид доступа à Отметить успех/отказ) для каких пользователей какие события надо регистрировать.

Множество событий, информация о которых записывается в журнал аудита, определяется политикой аудита, которую определяют пользователи-аудиторы.

Для каждой категории событий могут регистрироваться:

- только успешные (success) события (соответствующая операция выполнена успешно),

- только неуспешные (failed) (при выполнении операции произошла ошибка),

- и те и другие,

- никакие (не регистрироваться).

Для Windows NT считаются опасными следующие привилегии (см. Хорев «Методы и средства ЗИ в компьютерных системах, с.78-79) субъектов доступа (эти привилегии в основном наследуются от групп, к которым приписан пользователь):

добавлять записи в журнал аудита;

создавать маркеры доступа;

назначать маркеры доступа процессам;

создавать резервные копии информации, хранящейся на жестких дисках;

восстанавливать информацию на жестких дисках с резервных копий;

отлаживать программы.

Порядок (необходимость) регистрации событий при доступе субъектов к объектам определяется не только политикой аудита, но и атрибутами защиты объекта. Как ранее было сказано, доступ к объектам, защищенных операционной системой, контролирует Монитор безопасности (SRM), сравнивая дискреционный список контроля доступа (DACL), связанный с объектом, с маркером доступа, связанным с субъектом. В результате сравнения принимается решение открыть или запретить доступ. К моменту принятия решения об открытии или запрете доступа Windows NT обладает:

набором идентификаторов безопасности (SID) субъекта, пожелавшего получить доступ к объекту;

маской доступа (запрошенных прав) субъекта, когда все родовые типы доступа выражены через специфичные и стандартные;

положительным или отрицательным решением Монитора безопасности (SRM) о запрете требуемого доступа;

системным списком прав доступа (SACL), указатель на который имеется в дескрипторе безопасности, связанным с объектом.

Как уже говорилось в п.3.3.6.1 (Структура дескриптора защиты), в состав дескриптора защиты объекта входит указатель на системный список контроля доступа (SACL), определяющий правила регистрации событий аудита при доступе субъектов к данному объекту. Если у объекта SACL отсутствует, обращения субъектов к этому объекту не регистрируются.

Так же как и DACL, SACL представляет собой список переменной длины, элементами которого являются АСЕ, имеющие следующий формат:

В DACL и SACL каждый АСЕ содержит:

ACE

В отличие от АСЕ из DACL АСЕ в SACL всегда имеют только один тип " регистрирующий АСЕ" (system audit АСЕ). Разработчики Windows NT зарезервировали еще один тип АСЕ - " тревожный" АСЕ (system alarm АСЕ), предназначенный для интерактивного оповещения администраторов операционной системы, однако этот механизм до сих пор не реализован.

АСЕ, входящий в SACL, имеет все флаги, которые имеет АСЕ, входящий в DACL. Кроме того, АСЕ для SACL имеют еще два флага:

SUCCESSFUL_ACCESS_ACE_FLAG (s – флаг, succeess) - если этот флаг установлен, будут регистрироваться в журнале аудита все успешные обращения к объекту субъекта, идентификатор которого записан в АСЕ, по любому из методов доступа, перечисленных в маске доступа АСЕ;

FAILED_ACCESS_ACE_FLAG (f – флаг, fail) - если этот флаг установлен, будут регистрироваться в журнале аудита все неуспешные обращения к объекту субъекта, идентификатор которого записан в АСЕ, по любому из методов доступа, перечисленных в маске доступа АСЕ.

Если в АСЕ установлены оба флага – S и F - то регистрируются любые обращения субъекта к объекту по перечисленным методам доступа, как успешные, так и неуспешные.

Если в АСЕ установлен флаг i (INHERIT_ONLY_ACE), то при доступе субъектов к объекту данный АСЕ игнорируется.

При создании нового объекта SACL назначается объекту по тем же правилам, что и DACL. При наследовании АСЕ флаги (s) и (f) остаются неизменными.

Для того чтобы событие, связанное с доступом субъекта к объекту, было зафиксировано в журнале аудита, необходимо одновременное выполнение следующих двух условий:

1) политика аудита операционной системы допускает регистрацию в журнале аудита событий, связанных с успешным (или неуспешным) доступом субъектов к объектам;

2) SACL объекта содержит хотя бы один АСЕ, в котором:

SID субъекта относится к субъекту, открывающему объект;

установлен флаг s (или соответственно f) и не установлен флаг i;

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

В общем случае каждая запись в списке SACL обрабатывается так:

Windows NT проверяет, что тип записи — SystemAudit и если это не так, то запись игнорируется;

Windows NT сравнивает идентификатор безопасности (SID) в записи АСЕ (если SID не указан вовсе, то регистрируются попытки доступа всех пользователей) с SID субъекта и если совпадений нет, то запись пропускается;

маска требуемого доступа сравнивается с маской доступа в записи АСЕ и если ни один тип доступа, указанный в маске АСЕ, не требовался пользователем, запись пропускается, в противном случае проверяются биты доступа;

если пользователь получил доступ, а бит SUCCESSFUL_ACCESS_ ACE_FLAG не установлен или пользователю доступ был запрещен, а бит FAILED_ACCESS_ACE_FLAG не установлен, запись пропускается;

если запись прошла все проверки, монитор безопасности генерирует событие о доступе к объекту, которое должно быть помещено в журнал аудита (LSA потом помещает эту запись в журнал).

По умолчанию аудит в Windows 2000 отключен. Это снижает накладные расходы системы, но часто вызывает недоумение администраторов, когда они переключаются на просмотр журнала безопасности и видят, что он пуст. Чтобы включить аудит, администратор должен включить аудит в системе и установить соответствующие политике аудита правила. На уровне контроллера домена можно задать правила аудита (Audit Policy) для всех контроллеров (компьютеров) в этом домене. На отдельной рабочей станции и сервере, не являющемся контроллером домена, правила аудита задаются индивидуально для каждого компьютера (через локальные политики безопасности).

Как говорилось выше, решения об аудите конкретного типа событий безопасности принимаются в соответствии с политикой аудита локальной системы. Политика аудита явля­ется частью политики безопасности, поддерживаемой Lsass в локальной систе­ме. При инициализации системы и изменении политики Lsass посылает SRM сообщения, информирующие его о текущей политике аудита. Lsass отвечает за прием записей аудита, генерируемых на основе событий аудита от SRM, их ре­дактирование и передачу Event Logger (регистратору событий). Эти записи по­сылает именно Lsass (а не SRM), так как он добавляет в них сопутствующие под­робности, например информацию, нужную для более полной идентификации процесса, по отношению к которому проводится аудит.

После этого Event Logger заносит записи в журнал безопасности. В дополнение к записям аудита, передаваемым SRM, Lsass и SAM тоже генерируют записи аудита, которые Lsass пересылает непосредственно Event Logger.

Записи аудита, подлежащие пересылке LSA, помещаются в очередь по мере получения — они не передаются пакетами. Пересылка этих записей осуществ­ляется одним из двух способов. Если запись аудита невелика (меньше макси­мального размера LPC-сообщения), она посылается как LPC-сообщение. Запи­си аудита копируются из адресного пространства SRM в адресное пространство процесса Lsass. Если запись аудита велика, SRM делает ее доступной Lsass через разделяемую память и передает Lsass указатель на нее, используя для этого LPC-сообщение.