Проблемы в системе журналирования событий безопасности ос windows / хабр

Введение

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

Программа «Просмотр событий» представляет собой оснастку консоли управления Microsoft (MMC) и предназначена для просмотра и управления журналами событий. Это незаменимый инструмент для наблюдения за работоспособностью системы и устранения возникших неполадок. Служба Windows, которая управляет протоколированием событий, называется «Журнал событий». В том случае, если она запущена, Windows записывает важные данные в журналы. При помощи программы «Просмотр событий» вы можете выполнять следующие действия:

Просматривать события определенных журналов;
Применять фильтры событий и сохранять их для последующего использования в виде настраиваемых представлений;
Создавать подписки на события и управлять ими;
Назначать выполнение конкретных действий на возникновение определенного события.

Введение

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

Выбор «Поданные» для входа в файл журнала ошибок HTTP

Раздел реестра ErrorLoggingFields добавлен для управления полями, вошедшего в журнал ошибок HTTP. Эти значения реестра находятся в разделе HTTP\Parameters, расположенном по адресу:

Значение реестра ErrorLoggingFields — это значение DWORD, содержащее битовые значения для каждого поля, которое можно регистрироваться. Чтобы включить ведение журнала определенного поля, задайте для соответствующего битового значения значение 1 и перезапустите службу HTTP. Чтобы отключить ведение журнала, задайте битовое значение 0. Чтобы настроить несколько полей, используйте побитовое ИЛИ отдельных значений. Например, чтобы включить поля ведения журнала файлов cookie и ссылки, значение должно быть 0x00020000 | 0x00040000 = 0x00060000. Если раздел реестра ErrorLoggingFields отсутствует, регистрируются поля по умолчанию. Значение ErrorLoggingFields для записи полей по умолчанию — 0x7c884c7. Чтобы включить ведение журнала для всех полей, показанных в таблице ниже, задайте значение 0x7dff4e7.

Поля ведения журнала ошибок перечислены в следующей таблице:

Поле журнала	Зарегистрировано по умолчанию	Битовое значение
Дата	Да	0x00000001
Time	Да	0x00000002
Имя сервера	Нет	0x00000020
IP-адрес клиента	Да	0x00000004
Порт клиента	Да	0x00400000
IP-адрес сервера	Да	0x00000040
Порт сервера	Да	0x00008000
Версия протокола	Да	0x00080000
Метод	Да	0x00000080
URI	Да	0x00800000
Агент пользователя	Нет	0x00010000
Куки-файл	Нет	0x00020000
Реферер	Нет	0x00040000
Узел	Нет	0x00100000
Состояние протокола	Да	0x00000400
SC-Bytes	Нет	0x00001000
CS-Bytes	Нет	0x00002000
Затраченное время	Нет	0x00004000
Идентификатор сайта	Да	0x01000000
Фраза причины	Да	0x02000000
Имя очереди	Нет	0x04000000
Идентификатор потока	Нет	0x????????

Утилита Sysmon

Кроме задействования штатного функционала подсистемы журналирования, можно воспользоваться и официальной бесплатной утилитой Sysmon из пакета Microsoft Windows Sysinternals, которая существенно расширяет и дополняет возможности мониторинга ОС. Данная утилита дает возможность проводить аудит создания файлов, ключей реестра, процессов и потоков, а также осуществлять мониторинг загрузки драйверов и библиотек, сетевых подключений, WMI-событий и именованных каналов. Из особо полезных функций отметим возможность утилиты показывать родительский процесс и командную строку процесса, отображать значение хэш-сумм при событиях создания процесса и загрузки драйверов и библиотек с указанием наличия и действительности цифровой подписи. Несложным путем можно автоматизировать сравнение полученных хэш-сумм с индикаторами компрометации (IoCs, Indicator of Compromise) из данных фидов CyberThreat Intelligence, а также использовать приложение QVTI для IBM QRadar, с помощью которого хэши запускаемых файлов автоматически проверяются через сервис VirusTotal. Еще одной приятной опцией является возможность создания XML-конфигураций, в которых можно предельно четко указать объекты контроля и настройки работы Sysmon. Одними из наиболее продвинутых и детальных вариантов XML-конфигураций, с нашей точки зрения, являются конфиги https://github.com/ion-storm/sysmon-config и https://github.com/SwiftOnSecurity/sysmon-config .

Установка Sysmon предельно проста и также может быть легко автоматизирована:

1. Дистрибутив скачивается с https://docs.microsoft.com/en-us/sysinternals/downloads/sysmon

Все исполняемые файлы подписаны.

2. Создается или скачивается по приведенным выше ссылкам xml-файл с конфигурацией Sysmon.

3. Установка sysmon для x64 производится командой:

C:\folder\sysmon64.exe -accepteula -i C:\folder\sysmonconfig-export.xml , где sysmonconfig-export.xml – файл конфигурации, sysmon64.exe – файл-установщик.

Поддерживается запуск установки из сетевой папки.

4. После установки создается журнал Microsoft-Windows-Sysmon/Operational , размер которого мы сразу рекомендуем увеличить как минимум до 100 Мб.

Перезапуск устройства не требуется, Sysmon работает в виде сервиса, его исполняемый файл находится в C:\Windows\sysmon64.exe . По нашим подсчетам, footprint на конечной системе даже при использовании максимально детального конфига Sysmon не превышает 5-10% ЦПУ и около 100 Мб ОЗУ.

Настройка сервера для отправки логов на центральный сервер

Первым делом вы должны настроить ваши сервера на отправку событий. Я для примера это буду делать для контроллеров домена. Чтобы у вас все работало, вам нужно включить службу для удаленного управления WinRM. Открывайте командную строку от имени администратора и введите команду:

winrm qc или winrm quickconfig

Либо так же через PowerShell:

Enable-PSRemoting

Теперь нам нужно предоставить права от имени кого вы будите производить подключение к серверам откуда будите брать логи. На выбор у вас два варианта:

Вы предоставите нужные права учетной записи компьютера, что по мне правильнее
Либо можно производить подключение от имени доменной учетной записи (Можно и не доменной, но я рассматриваю исключительно окружение Active Directory)

Все, что нам нужно это предоставить учетной записи членство в локальной группе «Читатели журнала событий (Event Log Readers)»

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

Для того чтобы дать права, откройте оснастку «Active Directory — Пользователи и компьютеры» и перейдите в раздел Bultin. Тут будет группа «Читатели журнала событий (Event Log Readers)». Добавьте в нее пользователя или учетную запись компьютера, кому вы назначаете права (Члены этой группы могут читать журналы событий с локального компьютера)

Еще очень важно дать учетной записи Network Service право на чтение, иначе вы будите получать ошибку 0x138C:

Error — Last retry time: 02.09.2022 12:40:22. Code (0x138C): <f:ProviderFault provider=»Event Forwarding Plugin» path=»C:\Windows\system32\wevtfwd.dll» xmlns:f=»http://schemas.microsoft.com/wbem/wsman/1/wsmanfault»><t:ProviderError xmlns:t=»http://schemas.microsoft.com/wbem/wsman/1/windows/EventLog»>Windows Event Forward plugin can’t read any event from the query since the query returns no active channel. Please check channels in the query and make sure they exist and you have access to them.</t:ProviderError></f:ProviderFault> Next retry time: 02.09.2022 13:00:22.

Причина ошибки 0x138C, заключается в том, что служба удаленного управления Windows запускается под учетной записью сетевой службы. Нужно добавить SID учетной записи сетевой службы в разрешения на доступ к каналу журнала событий безопасности. Для начала давайте на контроллере домена, с которого я буду отправлять логи посмотрим текущие разрешения, сделать это можно в командной строке Windows.

wevtutil gl security или Wevtutil get-log security

Видим текущий канал безопасности:

channelAccess: O:BAG:SYD:(A;;0xf0005;;;SY)(A;;0x5;;;BA)(A;;0x1;;;S-1-5-32-573)

Нам нужно в самый конец добавить SID Network Service. Это стандартный SID (A;;0x1;;;S-1-5-20). Команда будет выглядеть вот так:

wevtutil set-log security /ca:O:BAG:SYD:(A;;0xf0005;;;SY)(A;;0x5;;;BA)(A;;0x1;;;S-1-5-32-573)(A;;0x1;;;S-1-5-20)

или

wevtutil sl security /ca:O:BAG:SYD:(A;;0xf0005;;;SY)(A;;0x5;;;BA)(A;;0x1;;;S-1-5-32-573)(A;;0x1;;;S-1-5-20)

После добавления проверьте, что новый SID добавился в канал доступа. Примерно через 20 минут вы должны начать видеть события в перенаправленных событиях.

Чтобы назначить массово права для Network Service, вы можете воспользоваться преимуществами Active Directory и создать на нужном OU групповую политику, в которой нужно перейти:

(Computer Configuration — Policies — Windows Settings — Security Settings — Restricted Groups)

Тут вам нужно через правый клик добавить группу «Event Log Readers».

Далее вам нужно ее отредактировать, добавив туда Network Service и все остальные группы, для которых вы выдаете права.

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

Те же манипуляции вы можете сделать через реестр Windows, так как я не перестаю вам напоминать, что любая настройка групповой политики меняет именно его. Откройте реестр Windows и перейдите в куст:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet \Services\EventLog\Security

Тут будет ключ реестра CustomSD. В CustomSD вы увидите ту самую строку channelAccess. При желании вы можете отредактировать ключ, добавив нужный SID. Так же данный ключ можно менять централизованно через GPO, но это сложнее, чем Restricted Groups.

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

Настройка ведения журнала на уровне сайта

Эту процедуру можно выполнить с помощью пользовательского интерфейса или путем непосредственного изменения файлов конфигурации.

Настройка ведения журнала на уровне сайта с помощью пользовательского интерфейса

Откройте диспетчер служб IIS.
- Для Windows Server 2012 на начальной странице щелкните плитку диспетчер сервера и нажмите кнопку «ОК». В Диспетчере серверов откройте меню Сервис и выберите пункт Диспетчер служб Internet Information Services (IIS).
- Для Windows 8 на панель управления типаначальной страницы и щелкните значок панель управления в результатах поиска. На экране панели управления выберите раздел Система и безопасность, выберите Администрирование,а затем щелкните пункт Диспетчер служб IIS.
В древовидном представлении Подключения выберите ваш веб-сайт.
В представлении Просмотр возможностей дважды щелкните Ведение журнала.
На странице Ведение журнала в пункте Файл журнала раздела Формат выберите один из следующих форматов файлов журналов:
- IIS: использовать файл журнала в формате Microsoft IIS для записи сведений о сайте. Этот формат обрабатывается HTTP.sys и имеет фиксированный текстовый формат ASCII, что означает, что нельзя настраивать поля, которые записываются в журнал. Поля разделяются запятыми, а для указания времени записывается местное время. Дополнительные сведения о формате файлов журнала IIS см. в разделе «Формат файла журнала IIS» (IIS 6.0).
- NCSA: использование файлов журнала общего формата Национального центра сверхмощных вычислений (NCSA) для регистрации сведений об узле. Этот формат обрабатывается HTTP.sys и имеет фиксированный текстовый формат ASCII, что означает, что нельзя настраивать поля, которые записываются в журнал. Поля отделяются пробелами, а время записывается как местное время со смещением относительно UTC. Дополнительные сведения о формате файла журнала NCSA см. в разделе NCSA Common Log File Format (IIS 6.0).
- W3C: использование централизованного формата файла журнала W3C для записи сведений обо всех сайтах на сервере. Этот формат обрабатывается HTTP.sys и имеет настраиваемый текстовый формат ASCII, что означает, что можно указать поля, которые записываются в журнал. Укажите поля, которые записываются в журнал, в диалоговом окне Поля ведения журнала W3C, нажав кнопку Выбрать поля на странице Ведение журнала. Поля отделяются пробелами, а время записывается в формате UTC. Дополнительные сведения о формате файла журнала W3C см. в разделе W3C Extended Log File Format (IIS 6.0).
- Настраиваемые: использование настраиваемого формата для пользовательского модуля ведения журнала. При выборе этого параметра страница ведения журнала становится отключенной, так как настраиваемое ведение журнала не может быть настроено в диспетчере IIS. Дополнительные сведения об использовании пользовательских форматов файлов журналов см. в разделе «Пользовательские модули ведения журнала» (IIS 6.0).
В разделе Каталог укажите путь для хранения файла журнала. Значение по умолчанию — .

Примечание

Рекомендуется хранить файлы журналов, например журналы трассировки неудачных запросов, в другом каталоге .
В разделе Смена файлов журнала выберите один из следующих вариантов.
- Расписание: создание нового файла журнала на основании одного из следующих значений.
  - Каждый час: новый файл журнала создается каждый час.
  - Ежедневно: новый файл журнала создается каждый день.
  - Еженедельно: новый файл журнала создается каждую неделю.
  - Ежемесячно: новый файл журнала создается ежемесячно.
- Максимальный размер файла (в байтах): новый файл журнала создается при достижении файлом определенного размера (в байтах). Минимальный размер файла — 1048576 байт. Если установленное значение этого атрибута меньше, чем 1 048 576 байтов, неявно принимается значение по умолчанию, равное 1 048 576 байтам.
- Не создавать новый файл журнала: имеется один файл журнала, размер которого продолжает увеличиваться по мере записи новых данных.
Выберите «Использовать локальное время для именования и смены файлов «, чтобы указать, что имя файла журнала и время для смены файла журнала использует время локального сервера. Если этот параметр не выбран, используется время в формате UTC.

Примечание

Независимо от этого параметра в метках времени текущего файла журнала будет использоваться формат времени, соответствующий выбранному в списке Формат формату журнала. Например, для журналов в форматах NCSA и W3C для отметок времени применяется формат UTC.
Щелкните Применить в области Действия.

XPath-запросы

Наконец, выполнив необходимые настройки файлов журналов Windows, перейдем непосредственно к поиску интересующей информации. Заметим, что в случае включения всех рекомендованных политик аудита ИБ сами журналы событий становятся достаточно объемными, поэтому поиск по их содержимому может быть медленным (этих недостатков лишены специализированные решения, предназначенные в том числе для быстрого поиска информации — Log Management и SIEM-системы). Отметим также, что по умолчанию не все журналы Windows отображаются к графической оснастке (eventvwr.msc), поэтому в данной оснастке следует перейти в меню «Вид» и отметить check-box «Отобразить аналитический и отладочный журналы».

Итак, поиск по журналам аудита будем осуществлять с помощью встроенного редактора запросов XPath (XPath queries). Открыв интересующий нас журнал, например, журнал безопасности Windows (вкладка «Журналы Windows» -> «Безопасность» / Security), нажатием правой кнопки мыши на имени журнала выберем пункт «Фильтр текущего журнала». Нам откроется графический редактор поисковых запросов, при этом для наиболее продуктивной работы следует открыть вторую вкладку открывшегося окна с названием XML, отметив внизу check-box «Изменить запрос вручную». Нам будет предложено изменить XML-текст (по сути, XPath запрос) в соответствии с нашими критериями поиска.

Результат запроса будет также представляться в различных формах, но для лучшего понимания и получения детального контента в конкретном событии рекомендуем переключиться на вкладку «Подробности», а там выбрать radio-button «Режим XML», в котором в формате «ключ-значение» будут представлены данные события безопасности.

Приведем несколько полезных XPath запросов с комментариями.

1. Поиск по имени учетной записи в журнале Security — возьмем для примера имя Username:

2. Поиск по значению конкретного свойства события в журнале Sysmon — возьмем для примера поиск событий, в которых фигурировал целевой порт 443:

3. Произведем поиск сразу по двум условиям — возьмем для примера событие входа с EventID=4624 и имя пользователя Username:

4. Поиск по трем условиям — дополнительно укажем Logon Type = 2, что соответствует интерактивному входу в ОС:

5. Рассмотрим функционал исключения из выборки данных по определенным критериям — это осуществляется указанием оператора Suppress с условиями исключения. В данном примере мы исключим из результатов поиска по фактам успешного входа (EventID=4624) все события, которые имеют отношения к системным учетным записям (SID S-1-5-18/19/20) с нерелевантным для нас типам входа (Logon Type = 4/5), а также применим функционал задания условий поиска с логическим оператором «ИЛИ», указав не интересующие нас имя процесса входа (Advapi) и методы аутентификации (Negotiate и NTLM):

Проблема № 1. Неудачная система управления параметрами аудита

Наличие проблемы подтверждено на Windows 7/10/Server 2019.

Объяснение

Наименование базовых политик аудита	Наименование расширенной политики аудита
Аудит доступа к службе каталогов	Доступ к службе каталогов (DS)
Аудит доступа к объектам	Доступ к объектам
Аудит использования привилегий	Использование прав
Аудит входа в систему	Вход/выход
Аудит событий входа в систему	Вход учетной записи
Аудит изменения политики	Изменение политики
Аудит системных событий	Система
Аудит управления учетными записями	Управление учетными записями
Аудит отслеживания процессов	Подробное отслеживание

Эффективные политики аудита — информация, хранящаяся в оперативной памяти и определяющая текущие параметры работы модулей операционной системы, реализующих функции аудита.
Сохраненные политики аудита — информация, хранящаяся в реестре по адресу HKEY_LOCAL_MACHINE\SECURITY\Policy\PolAdtEv и используемая для определения эффективных политик аудита после перезагрузки системы.

Наименование средства	Отображаемые политики аудита	Сохраняемые политики аудита
«Базовые политики аудита» оснастки «Локальные политики безопасности»	Эффективные политики аудита	Эффективные политики аудита, сохраненные политики аудита
«Расширенные политики аудита» оснастки «Локальные политики безопасности»	Файл
Утилита auditpol	Сохраненные параметры аудита	Эффективные параметры аудита, сохраненные параметры аудита

Пример 1Пример 2Пример 3Пример 4

В чем суть проблемы?

Рассмотрим вероятный сценарий4719 «Аудит изменения политики»

На атакуемой рабочей станции предоставили себе права на запись к ключу реестра HKEY_LOCAL_MACHINE\SECURITY\Policy\PolAdtEv и экспортировали этот ключ в файл c именем «+fs.reg».
На другом компьютере импортировали данный файл, перезагрузились, а затем с помощью auditpol отключили аудит файловой системы, после чего экспортировали указанный выше ключ реестра в файл «-fs.reg».
На атакуемой машине импортировали в реестр файл «-fs.reg».
Создали резервную копию файла %SystemRoot%\System32\GroupPolicy\Machine\Microsoft\Windows NT\Audit\audit.csv, расположенного на атакуемой машине, а затем удалили из него подкатегорию «Файловая система».
Перезагрузили атакуемую рабочую станцию, а затем подменили на ней файл %SystemRoot%\System32\GroupPolicy\Machine\Microsoft\Windows NT\Audit\audit.csv ранее сохраненной резервной копией, а также импортировали в реестр файл «+fs.reg»

Траблшутинг сервера-коллектора логов

Очень часто тут бывают ошибки 0x138C, как ее решать я описал выше.

Еще если вы не дали права, то получите «Access is denied».

Еще если вы выбрали слишком много событий, то можете увидеть ошибку:

Error – Last retry time: 2022-08-28 16:43:18. Code (0×7A): The data area passed to a system call is too small. Next retry time

Если у вас есть такие крупные продукты, как SharePoint, MS Exchange, MS CRM, то получая с них события, вы можете видеть ошибку ID 6398:

The description for Event ID 6398 from source A cannot be found. Either the component that raises this event is not installed on your local computer or the installation is corrupted. You can install or repair the component on the local computer.

Как я вам выше показал в реестре Windows каждый журнал описан в своей ветке и за него отвечает определенная DLL библиотека, если такого источника не будет на вашем коллекторе, то и могут возникать подобного рода ошибки. Для крупных приложений очень сложно произвести перенос в другое место, так как очень много источников, кто туда пишет. Поэтому PowerShell нам в помощью.

На просторах интернета есть добрые люди, кто столкнулся с такой задачей и ее прекрасно выполнил, и самое прекрасное, что человек поделился решением со всем интернетом.

https://github.com/sanglyb/ps-copy-log-source если вдруг по какой-то причине скриптов не будет в доступе, то можете скачать их тут

Тут два скрипта:

export-log — Для экспорта данных с серверов откуда собираем данные
import-log — Для импорта на сервере-коллекторе недостающих данных

Алгоритм такой, копируем скрипт export-log на сервер со специфическим ПО, у меня это будет Dynamic CRM. Запустите PowerShell и перейдите в расположение вашего скрипта, выберите его и добавьте ключ, являющийся частью источника событий, например crm.

.\export-log.ps1 crm

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

Вот еще пример с Kaspersky.

Теперь идем на сервер коллектор и копируем туда созданную ранее папку. После чего открываем PowerShell так же в режиме администратора и импортируем все, что до этого получили.

.\import-log crm

В скрипте изначально задан каталог C:\CustomEvents, так что создайте его заранее иначе будете получать ошибку. После этого все логи будут корректно отображаться.

Еще из проблем может быть недоступность порта 5985, который должна слушать служба winrm. Проверяем порт, как я рассказывал ранее. Может получиться так, что какая-то из служб может его занять, как в случае с 1С или IIS.

Посмотреть кто слушает и что netstat -ant, далее netsh http show iplisten

И удаляем:

netsh http delete iplisten ipaddress=ip

Включение подробных сообщений о состоянии с помощью редактора групповая политика объектов

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

В среде домена

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

В меню Пуск выберите пункт Администрирование и затем пункт Active Directory — пользователи и компьютеры.
Щелкните правой кнопкой мыши контейнер для домена или подразделения, к которому вы хотите применить параметры политики, и выберите пункт «Свойства».
Откройте вкладку групповая политика.
Нажмите кнопку «Создать», а затем введите описательное имя нового групповая политика объекта (GPO).
Щелкните созданный объект групповой политики и нажмите кнопку «Изменить «.
Разверните конфигурацию компьютера, разверните административные шаблоны и щелкните «Система».
В области справа дважды щелкните подробные и обычные сообщения о состоянии.
Нажмите кнопку «Включено>ОК».
Закройте редактор объектов групповой политики, нажмите кнопку ОК, а затем закройте оснастку «Пользователи и компьютеры Active Directory».

Примечание.

Windows игнорирует этот параметр, если включен параметр «Удалить загрузку «, «Завершение работы», «Вход в систему», «Выйдите из системы».

На автономном компьютере или на одном компьютере

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

Click Start>Run.
В поле «Открыть » введите gpedit.msc и нажмите кнопку » ОК».
Разверните административные>шаблоны конфигурации компьютера и щелкните «Система».
В области справа дважды щелкните » Отобразить подробные сообщения о состоянии».
Нажмите кнопку «Включено>ОК».
Закройте групповая политика объекта и нажмите кнопку «ОК».

Примечание.

Включение подробных сообщений о состоянии с помощью редактора реестра

Важно!

В этот раздел, описание метода или задачи включены действия, содержащие указания по изменению параметров реестра. Однако неправильное изменение параметров реестра может привести к возникновению серьезных проблем. Поэтому следует в точности выполнять приведенные инструкции. Для дополнительной защиты создайте резервную копию реестра, прежде чем редактировать его. Так вы сможете восстановить реестр, если возникнет проблема. Дополнительные сведения о создании резервной копии и восстановлении реестра см. в соответствующей статье базы знаний Майкрософт: Создание резервной копии и восстановление реестра Windows

Чтобы включить подробные сообщения о состоянии путем изменения реестра, выполните следующие действия.

Click Start>Run.
В поле «Открыть » введите regedit и нажмите кнопку » ОК».
Найдите и щелкните следующий раздел реестра:
В меню Правка выберите пункт Создать, а затем Параметр DWORD.
Введите verbosestatus и нажмите клавишу ВВОД.
Дважды щелкните созданный ключ, введите 1 в поле данных » Значение» и нажмите кнопку «ОК «.
Закройте редактор реестра.

Примечание.

Windows не отображает сообщения о состоянии, если имеется следующий ключ и задано значение 1:

Заключение

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