В журналах событий Windows хранится полезная информация, которая нужна при анализе состояния служб и приложений в Windows, отладки ошибок и аварийный ситуаций, аудите различных событий безопасности. По умолчанию для журналов Event Viewer в Windows заданы максимальные размеры, при достижении которых новые события начинают перезаписывать более старые. Если на вход Event Viewer попадает слишком большое количество событий, может случится, что в журнал помещаются события лишь за последние несколько часов, что может быть не достаточно.
Чтобы предотвратить перезапись старых событий и всегда иметь под рукой события за достаточно большой промежуток времени, вы можете увеличить максимальный размер журналов Event Viewer.
Содержание:
- Получить информацию о журналах событий Windows с помощью PowerShell
- Изменить размер журнала событий из консоли Event Viewer
- Увеличить размер журнала событий Windows через GPO
Получить информацию о журналах событий Windows с помощью PowerShell
Файлы журналы событий Windows хранятся в каталог
%SystemRoot%\System32\Winevt\Logs\
в виде файлов с расширением .EVTX. Обратите внимание, что для каждого журнала используется собственный файл. Соответственно, вы можете управлять размерами только того лога Windows, который вам нужен и оставить остальные значения по-умолчанию.
Текущие лимиты на все включенные журналы событий в Windows можно вывести с помощью PowerShell:
Get-Eventlog -List
Вы можно вывести размер определенного лога с помощью командлета Get-WinEvent. Например, получим текущий и максимальный размер журнала Security:
Get-WinEvent -ListLog Security| Select MaximumSizeInBytes, FileSize, IsLogFull, OldestRecordNumber, IsEnabled, LogMode
Суммарный размер паки с файлами журналов событий можно получить с помощью PowerShell:
«{0:N2} MB» -f ((gci c:\windows\System32\Winevt\Logs\| measure Length -s).sum / 1Mb)
Чтобы увеличить максимальный размер лога, можно использовать утилиту wevtutul (новый размер задается в Кб):
wevtutil sl "Application" /ms:200000
Или с помощью PowerShell:
Limit-Eventlog -Logname Application -MaximumSize 200MB -OverflowAction OverwriteOlder
Изменить размер журнала событий из консоли Event Viewer
Проще всего увеличить максимальный размер журнала прямо из консоли Event Viewer.
- Откройте
eventvwr.msc
; - Найдите в консоли свойства нужного журнала и откройте его свойства (например, Security);
- Задайте ограничение в разделе Maximum log size (KB) и сохраните изменения;
- Здесь же можно изменить поведение при достижение максимального размера:
Owerwrite events as needed (oldest events first) – этот режим исопльзуется по умолчанию. Новые события просто перезаписывают более старые.
Archive the log when full, do not owerwrite events – текущий журнал событий при заполнении архивируется в папке \System32\Winevt\Logs\ и новые события записываются в новый evtx файл. Архивные файлы событий можно открыть через меню Open Saved Log в Event Viewer.
Do not owerwrite events (Clear log manually) – события никогда не перезатираются. Для записи новых событий нужно очистить журнал.
Увеличить размер журнала событий Windows через GPO
Чтобы централизованно управлять размерами журналов событий на компьютерах или серверах в домене Active Directory, можно использовать групповые политики.
- Запустите консоль Group Policy Management (
gpmc.msc
), создайте новую GPO и назначьте на OU с компьютерами или серверами, для которых вы хотите изменить настройки Event Viewer (или назначьте GPO на корень домена); - Перейдите в раздел GPO Computer Configuration -> Policies -> Administrative Templates -> Windows Components -> Event Log Service. Как вы видите, в этом ветке есть подразделы для управления базовыми журналами Windows:
Application Security Setup System
- Чтобы увеличить максимальный размер любого из журналов, откройте параметр Specify the maximum log file size (KB), включите его и задайте нужный вам размер;
- Обновите настройки политики на клиентах и проверьте, что в свойствах журнала теперь указан новый размер, который вы не можете изменить. При попытке задать другой размер появится ошибка:
Event Viewer
The Maximum Log Size specified is not valid. It is too large or too small. The Maximum Log Size will be set to the following: 61440 KB
Обратите внимание, что в описанном выше разделе GPO отсутствуют настройки для других журналов из раздела Applications and Services Logs -> Microsoft.Если вам нужно увеличить размер любого другого журнала событий (кроме стандартного), это можно сделать через реестр. Настройки журналов событий Windows хранятся в разделе реестра HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\EventLog\<log_name>. Размер журнала задается с помощью параметра MaxSize (тип REG_DWORD). Вы можете распространить нужное вам значение параметра реестра MaxSize на компьютеры домена с помощью Group Policy Preferences.
Подробнее о настройке ключей и параметров реестра через GPO здесь.
В этом примере мы увеличим размер журнала Directory Service на контроллерах домена. Настройки этого лога хранятся в ветке HKLM\SYSTEM\CurrentControlSet\Services\EventLog\Directory Service.
- Откройте GPO и перейдите в раздел Computer Configuration -> Preferences -> Windows Settings -> Registry;
- Выберите New -> Registry Item;
- Создайте новый параметр со следующими настройками:
Hive: HKEY_LOCAL_MACHINE Key path: SYSTEM\CurrentControlSet\Services\EventLog\Directory Service Value name: MaxSize Value type: REG_DWORD Value data: 52428800 (значение задается в байтах. В нашем примере это 50 Мб)
- Проверьте, что после обновления GPO на DC увеличится максимальный размер журнала.
Например, если вам нужно хранить историю RDP подключений к RDS хосту за продолжительное время, нужно увеличить размер лога Terminal-Services-RemoteConnectionManager.
За счет увеличения размеров журналов событий Windows вы можете получить различную информацию за более длительный промежуток времени. Например, из журналов событий можно получить историю перезагрузок Windows, понять кто удалил файл в сетевой папке или кто изменил NTFS права доступа.
Текстовая версия выступления на PHD12
Пару слов о проблеме
При реагировании на инциденты бывает необходимо посмотреть логи Windows машины, и аналитики подготавливают утилиты для удобной фильтрации событий в журналах evtx. Это связано с тем, что способы фильтрации, предложенные Microsoft, выглядят крайне не удобно.
Live response — это область, которая занимается сбором информации с работающего компьютера, чтобы определить, произошел ли инцидент.
При проведении live response анализа, полезно быстро понять, что происходило с компьютером в последнее время.
Существуют различные инструменты для проведения live response: коммерческие, с открытым исходным кодом и встроенные возможности ОС.
Использование opensource и коммерческих инструментов связано с рядом проблем:
-
Утилиты могут отправлять телеметрию разработчику
-
Отсутствие описания анализируемых журналов и EventId
Неудобство фильтрации оснасткой eventvwr.msc
Фильтрация evtx с помощью стандартной оснастки просмотра событий (eventvwr.msc) ограничена в возможностях.
Проблемы:
-
отсутствует возможность вывести информацию в колонках
-
отсутствуют регулярные выражения и поиск подстрок
-
отсутствует группировка
Кроме того, стандартная оснастка просмотра событий не поддерживает все функции XPath, что может создавать дополнительные проблемы при фильтрации.
Одним из основных ограничений XPath 1.0 является то, что он не поддерживает поиск по атрибутам. То есть, если вы хотите найти события, связанные с определенным EventID, вы можете воспользоваться элементом EventID, но вы не сможете использовать атрибуты, вложенных элементов для поиска событий, например: TargetUserName.
XPath, в оснастке, не поддерживает регулярные выражения и поиск подстрок, которые могут быть полезны при фильтрации журналов событий Windows. Регулярные выражения позволяют искать текстовые строки, соответствующие определенному шаблону, что может быть полезно, например, при поиске IP-адресов или имен файлов.
Таким образом, недостатки XPath для фильтрации журналов событий Windows заключаются в ограниченных возможностях поиска по атрибутам вложенных элементов, отсутствии некоторых функций сравнения, а также отсутствии поддержки регулярных выражений.
Как показано выше, узлы «Элемент» могут содержать «Атрибуты», и мы можем использовать подстановочный знак «@» для поиска узлов «Data».
Пример ниже позволяет найти все события из журнала Security c EventID = 4688. Атрибут Path в директиве Query можно опустить. Путь к журналу указывается в в атрибуте Path директивы Select.
<QueryList>
<Query Id="0" Path="Security">
<Select Path="Security">*[System[EventID=4688]]</Select>
</Query>
</QueryList>В пример ниже добавляем использования логического оператора OR для поиска события с EventID 4688 или 4624.
<QueryList>
<Query Id="0" Path="Security">
<Select Path="Security">*[System[EventID=4688 or EventID=4624]]</Select>
</Query>
</QueryList>В следующем примере добавим фильтрацию по разделу XML — EventData. Для объединения двух условий в одном Select используется логический оператор AND. Вторая часть запроса начинается со знака *, который означает что верхний узел может принимать любое значение, далее мы указываем путь к атрибуту значение которого хотим указать в условии EventData -> Data -> @Атрибут=»значение».
<QueryList>
<Query Id="0" Path="Security">
<Select Path="Security">*[System[EventID=4688]] and
*[EventData[Data[@Name="SubjectUserName"]="hacker"]]</Select>
</Query>
</QueryList>XPath позволяет искать значение по всем атрибутам, как в примере ниже. Структура указанные выше изменилась до EventData -> Data -> @Атрибут =»значение». Следующим запросам мы найдем все события где в атрибутах фигурировало «C:\Windows\System32\lsass.exe»
<QueryList>
<Query Id="0" Path="Security">
<Select Path="Security">*[System[EventID=4688]] and
*[EventData[Data="C:\Windows\System32\lsass.exe"]]</Select>
</Query>
</QueryList>Оператор Suppress позволяет исключить из конечной выборки события, которые подходят под условие в нем. В примере ниже, мы найдем все события 4624, в которых LogonType=5.
<QueryList>
<Query Id="0" Path="Security">
<Select Path="Security">*[System[EventID=4624]]</Select>
<Suppress Path="Security">*[EventData[Data[@Name='LogonType']=5]]</Suppress>
</Query>
</QueryList>В пределах одного Query мы можем указывать несколько Select-запросов, также есть возможность запрашивать события из разных журналов.
<QueryList>
<Query Id="0">
<Select Path="Security">*[System[EventID=4688]]</Select>
<Select Path="Windows PowerShell">*</Select>
</Query>
</QueryList>В одном QueryList может быть несколько Query. Это удобно для логического разбиения запросов и их фильтрации.
<QueryList>
<Query Id="0" Path="Security">
<Select Path="Security">*[System[EventID=4688]]</Select>
</Query>
<Query Id="1" Path="Microsoft-Windows-Sysmon/Operational">
<Select Path="Microsoft-Windows-Sysmon/Operational">*</Select>
</Query>
</QueryList>Таким образом, фильтрация evtx с помощью стандартной оснастки просмотра событий и XPath 1.0 ограничена и не всегда удобна. Для более гибкой и удобной работы с журналами событий можно использовать специализированные инструменты для анализа журналов, которые предоставляют более широкие возможности фильтрации и поиска информации.
Возможности CMD
Возможности CMD ограничены использованием двух основных утилит wevtutil и Findstr. wevtutil позволяет работать с параметрами журналов и создавать к ним запросы. Для запросов в wevtutil также используются XPath-запросы.
wevtutil.exe qe Security /q:"*[EventData[Data[@Name='TargetUserName']='User1' and Data[@Name='LogonType']=2]]" /f:textПри использовании findstr, наши возможности расширяются для поиска интересующих нас строк.
wevtutil.exe qe Security /q:"*[EventData[Data[@Name='LogonType']=11]]" /f:text | findstr "Account Name"Возможности PowerShell
В Powershell для работы с журналами существуют два командлета Get-EventLog и Get-WinEvent. Мы рассмотри второй командлет так как он считается актуальным.
Основные возможности Get-WinEvent это использование хеш-таблиц и Xpath для фильтрации событий. Для использование хеш-таблиц используется аргумент -FilterHashtable, его можно опустить и строить запрос сразу с @{<выражение>}.
Рассмотрим несколько примеров использования командлета Get-WinEvent и построения конвейеров с ним.
Следующим примером мы выведем 1000 событий из журнала Security.
Get-WinEvent -LogName Security -MaxEvents 1000
Тот же запрос, но используем Format-List для приведения вывода в читаемый.
Get-WinEvent -LogName Secutity -MaxEvents 10 | Format-List
Используем FilterHashtable. Выведем события из журнала Security с EventId 4688.
Get-WinEvent @{logname="security";ID=4688} -MaxEvents 100 | Format-ListДля понимания дальнейших фильтров давайте посмотрим как представлено событие в Powershell, для этого выведем одно событие и воспользуемся командлетом Get-Member.
Get-WinEvent @{logname="security";ID=4688} -MaxEvents 1 | Get-Member
Свойство Properties — это список, который хранит основные параметры события, которые расположены в секции EventData xml-представления.
После того, как мы научились получать события из определенного журнала и по определенному EventId, давайте посмотрим каким образом мы можем получить интересующие нас данные. Давайте выведем события 4688, и отобразим время создания события и {$_.Properties[5].value}, которое хранит имя запущенного процесса. Номер элемента списка Properties соответствует номеру атрибута в секции EventData xml-представления события.
Get-WinEvent @{logname="security";ID=4688} -MaxEvents 100 |
select timecreated,{$_.Properties[5].value} | Format-List
Powershell позволяет нам создавать группировки, используя командлет Group-Object. Следующим запросом сгруппируем события Sysmon EventId 3 по следующим полям: процесс, адрес получателя, доменное имя получателя, порт получателя.
Get-WinEvent @{LogName="*sysmon*";ID=3} -MaxEvents 10000 |
Where-Object {$_.Properties[16].Value -ne 443} |
Group-Object {$_.Properties[4].Value},{$_.Properties[14].Value}, {$_.Properties[15].Value}, {$_.Properties[16].Value} |
Select-Object Name, Count | Sort-Object Count -Descending | Format-List
Для поиска подстрок можем воспользоваться -Match или -Like.
Get-WinEvent @{LogName="*sysmon*";ID=1} -MaxEvents 1000 |
Where-Object {$_.Properties[10].Value -Match ".*cmd.exe" } |
Select-Object {$_.Properties[10].Value} |
Format-List
Поиска событий с известным значением атрибута выполняется быстрее при использовании XPath запросов, чем конвейеров Powershell. Например: запрос ниже найдет все события, связанные с пользователем R00t1k\Vadim.
Get-WinEvent -LogName *Sysmon* -FilterXPath "*[EventData[Data[@Name='User']='LAB\vadim']]" |
Where-Object {$_.Properties[4].Value -Match ".*WINWORD.exe"} |
Format-List
Poweshell позволяет представить сообщение в виде xml, выполнив следующий код.
$eventlog = Get-WinEvent -FilterHashtable @{LogName="Security";ID=4624} -MaxEvents 1
$xml = [xml]$eventlog.ToXml()
$xml.Event.EventData.Data
Модуль Powershell Convert-EventLogRecord преобразовывает события в структуру данных, которая позволяет обращаться к атрибутам по их имени. Конвейер для фильтрации событий с Convert-EventLogRecord будет выполняться в 2-3 раза дольше, в отличие от ковейера без его использования.
# С использованием Convert-EventLogRecord
Get-WinEvent -FilterHashtable @{LogName="Security";ID=4624} |
Convert-EventLogRecord | Where-Object LogonType -ne 5 |
Select TimeCreated, TargetUserName, LogonType
# Без использования Convert-EventLogRecord
Get-WinEvent @{LogName="Security";Id=4624} |
Where-Object {$_.Properties[8].Value -ne 5} |
Select TimeCreated, {$_.Properties[5].Value}, {$_.Properties[8].Value}Используя командлет Out-GridView мы можем вывести события в виде таблицы.
Get-WinEvent -FilterHashtable @{LogName='Security'; ID=4624} |
Select-Object TimeCreated,
@{Name='User'; Expression={$_.Properties[5].Value}},
@{Name='LogonType'; Expression={$_.Properties[8].Value}},
@{Name='SrcIp'; Expression={$_.Properties[18].Value}} |
Out-GridViewДля вывода нескольких событий в таблицу нужно учитывать, что порядковые номера атрибутов у разных EventId могут хранить разные данные.
Get-WinEvent -FilterHashtable @{LogName='Security'; ID=4624, 4688} -MaxEvents 1000 | Where-Object {$_.Properties[8].Value -ne 5} |
ForEach-Object {
if ($_.Id -eq 4624) {
$Username = $_.Properties[5].Value
$LogonType = $_.Properties[8].Value
$LogonProcess = $_.Properties[9].Value
$IpAddress = $_.Properties[18].Value
}
elseif ($_.Id -eq 4688) {
$SubjectUserName = $_.Properties[1].Value
$SubjectUserDomain = $_.Properties[2].Value
$NewProcessName = $_.Properties[5].Value
$CommandLine= $_.Properties[8].Value
$ParrentProcessName= $_.Properties[13].Value
}
[PSCustomObject]@{
Time = $_.TimeCreated
EventID = $_.Id
Username = $Username
LogonType = $LogonType
LogonProcess = $LogonProcess
IpAddress = $IpAddress
SubjectUserName = $SubjectUserName
SubjectUserDomain = $SubjectUserDomain
NewProcessName = $NewProcessName
CommandLine = $CommandLine
ParrentProcessName = $ParrentProcessName
}
} | Out-GridView
Перед расследованием инцидентов, стоит уделить время первому этапу при реагировании — подготовка. Оказавшись в ситуации без флешки, с подготовленным софтом, Вы не растерялись и смогли понять, что происходило в журналах Windows. Во второй статье, рассмотрим утилиты, упомянутые в докладе.
Подписывайтесь на Telegram Detection is easy
Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.
Какими утилитами при реагировании на инциденты Вы пользуетесь?
Проголосовали 25 пользователей. Воздержались 10 пользователей.
В процессе работы Windows постоянно ведёт запись различных системных событий в файлы журналов, которые можно просмотреть с помощью утилиты «Просмотр событий». Сами по себе журналы не занимают много места на диске, но общее количество операций записи на продолжительном отрезке времени значительно и потенциально может влиять на общий ресурс дисков, особенно SSD. При желании, запись событий в журнал можно отключить.
В этой инструкции подробно о способах отключить журнал событий полностью или частично для отдельных событий, очистить его и дополнительная информация, которая может быть полезной.
Отключение службы «Журнал событий Windows»
Самый очевидный и простой способ отключить журнал событий — отключение соответствующей службы, однако у этого способа есть минусы:
- От указанной службы зависят и другие службы, в частности могут возникнуть проблемы с работой планировщика заданий, службами сведений о подключенных сетях, списка сетей и автоматической настройки сетевых устройств.
- Полное отключение журнала событий может быть не лучшим вариантом: собираемые в журналах сведения о сбоях могут быть полезными для диагностики проблем с работой системы.
Список зависимостей службы отличается в разных версиях Windows: в Windows 11 проблем после отключения службы «Журнал событий» вы вероятнее всего не заметите, а в Windows 10 они могут быть.
Для того, чтобы отключить службу «Журнал событий Windows» (чего я не рекомендую) вы можете использовать оснастку «Службы»:
- Нажмите клавиши Win+R на клавиатуре, введите services.msc и нажмите Enter.
- В списке служб найдите «Журнал событий Windows» и дважды нажмите по этой службе.
- Нажмите кнопку «Остановить», измените тип запуска на «Отключена» и нажмите «Ок».
Ещё один способ — запустить командную строку от имени администратора и по порядку использовать следующие команды:
net stop eventlog sc config eventlog start= disabled
Это полностью отключит ведение журнала событий, но, при возникновении проблем с работой других системных служб не забудьте, что, возможно, они были вызваны описанными действиями.
Отключение записи отдельных событий или выбранных журналов
Вместо отключения журнала событий полностью, вы можете отключить запись лишь отдельных событий — тех, которые записываются чаще всего, при этом не несут полезной информации для большинства пользователей.
Прежде всего — это события «Аудит успеха» в журнале «Безопасность». Для отключения записи этих событий в командной строке от имени администратора используйте одну из следующих команд (первая — для русскоязычной версии Windows, вторая — для англоязычной или переведенной на русский язык путем установки языкового пакета):
auditpol /set /subcategory:"Подключение платформы фильтрации" /success:disable /failure:enable auditpol /set /subcategory:"Filtering Platform Connection" /success:disable /failure:enable
Указанные команды отключат запись событий типа «Успех», но оставят запись событий «Отказ». Аналогичным образом возможно отключение событий других подкатегорий, полный список подкатегорий можно получить с помощью команды auditpol /list /subcategory:*
Следующая возможность — отключение записи определенных событий по их GUID, шаги будут следующими (пример для журнала «Система»):
- В просмотре событий (Win+R — eventvwr.msc) найдите событие, запись которых нужно отключить, на вкладке «Подробности» включите режим XML, здесь нам потребуется значение параметра GUID.
- В редакторе реестра (Win+R — regedit) перейдите к разделу
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\WMI\Autologger\EventLog-System
- В этом разделе выберите подраздел с именем, совпадающим с GUID из первого шага, дважды нажмите по параметру с именем Enabled и установите значение 0 для него, повторите то же самое для параметра EnableProperty
- Закройте редактор реестра и перезагрузите компьютер.
И ещё один метод для журналов приложений, на примере журнала WFP (который у многих пользователей постоянно пишется с большой интенсивностью):
- В Просмотре событий откройте «Журналы приложений» и перейдите к нужному журналу, например: Microsoft — Windows — WFP — Operational
- Нажмите правой кнопкой мыши по журналу и выберите пункт «Отключить журнал».
Отдельно по журналу wfpdiag.etl: ещё одна возможность отключения — команда
netsh wfp set options netevents = off
Очистка журнала событий
Файлы журналов событий располагаются в папках
C:\Windows\System32\winevt\Logs C:\Windows\System32\LogFiles
И некоторых других расположениях, например — C:\ProgramData\Microsoft\Windows\wfp\
Очистка вручную путем удаления файлов нежелательна и не всегда удобна. Вы можете:
- Использовать опцию «Очистить журнал» для соответствующего журнала в «Просмотре событий» в контекстном меню журнала или его свойствах.
- Использовать одну из команд (первая — для командной строки, вторая — для PowerShell, в обоих случаях требуется запуск от имени администратора):
for /F "tokens=*" %1 in ('wevtutil.exe el') DO wevtutil.exe cl "%1" Get-EventLog -LogName * | ForEach { Clear-EventLog $_.Log }
Если остаются вопросы по журналам событий в Windows, задавайте их в комментариях — не исключено что я или кто-то из читателей сможет подсказать.
Чтобы не потеряться в огромном объеме данных, в «Просмотре событий» Windows есть возможность создавать собственные фильтры событий: «Настраиваемые представления — Создать настраиваемое представление»
Например, по номерам событий (4624 — Вход в систему; 4634 — Выход из системы):
В результате будет выведен список всех событий с этими кодами:
Однако, здесь будут события по всем пользователям. Но что делать, если нужно отфильтровать события по дополнительным полям, которые есть в свойствах события? Например, по имени учетной записи:
В этом случае, когда базовые фильтры не дают должного результата, нужно прибегнуть к расширенным фильтрам XML. Для этого нужно увидеть структуру события в формате XML (Подробности — Режим XML):
Отсюда можно взять названия нужных для фильтра полей. Например, такие как TargetUserName или IpAddress.
Чтобы создать свой XML-фильтр нужно в свойствах уже созданного фильтра нажать «Изменить фильтр»:
Здесь нужно перейти на вкладку XML и нажать «Изменить запрос вручную» и ответить «Да» во всплывающем окне:
Теперь здесь можно написать свой фильтр в формате XML. Например, для фильтрации входа или выхода из системы по конкретному пользователю:
<QueryList>
<Query Id="0" Path="Security">
<Select Path="Security">
*[System[(EventID=4624 or EventID=4634)]] and *[EventData[Data[@Name='TargetUserName']='this_user']]
</Select>
</Query>
</QueryList>
или по IP-адресу устройства, с которого осуществлялся вход или выход из системы:
<QueryList>
<Query Id="0" Path="Security">
<Select Path="Security">
*[System[(EventID=4624 or EventID=4634)]] and *[EventData[Data[@Name='IpAddress']='192.168.0.10']]
</Select>
</Query>
</QueryList>
для указания диапазона дат можно использовать следующую конструкцию:
<QueryList>
<Query Id="0" Path="Security">
<Select Path="Security">*[System[(EventID=4624) and TimeCreated[@SystemTime>='2024-09-30T21:00:00.000Z' and @SystemTime<='2024-10-31T20:59:59.999Z']]] and *[EventData[Data[@Name='TargetUserName']='this_user']]</Select>
</Query>
</QueryList>
При написании XML-фильтра можно использовать не только оператор and (И), но и оператор or (ИЛИ).
После этого нужно два раза нажать «ОК» — подтвердить изменения:
и отобразятся события, отфильтрованные с новыми параметрами, которые заданы XML-фильтром.
Следующий фильтр поможет найти все события, связанные со службой «Установщик модулей Windows» (здесь может быть наименование любой службы) и источником «Service Control Manager»:
<QueryList>
<Query Id="0" Path="System">
<Select Path="System">
*[System[Provider[@Name='Service Control Manager']]] and *[EventData[Data[@Name='param1']='Установщик модулей Windows']]
</Select>
</Query>
</QueryList>
Названия параметров для написания XML-фильтра я брал из свойства нужного события:
Созданные фильтры можно экспортировать в xml-файлы для переноса на другие устройства с ОС Windows:
Если нужно вывести события, например, из двух журналов, то XML-фильтр будет таким:
<QueryList>
<Query Id="0">
<Select Path="System">
*[System[(EventID=1502)]]
</Select>
<Select Path="Application">
*[System[(EventID=8224)]]
</Select>
</Query>
</QueryList>
Аналогичным образом можно настраивать фильтры не только для Журналов Windows, но и для Журналов приложений:
При помощи PowerShell можно выгружать содержимое отфильтрованного Журнала событий в csv-файл. Например, команда
Get-WinEvent -FilterXml ([xml](Get-Content C:\Temp\test.xml)) | Export-Csv "C:\Temp\test.csv" -Encoding UTF8
выгрузит события, которые заданы XML-фильтром из файла test.xml
Отслеживание событий — основа безопасности систем
Когда на компьютере происходит какое-либо значимое событие, операционная система записывает это событие в журнал. Входом в журналы служит Event Viewer (eventvwr.exe). Большинство администраторов открывают Event Viewer, только когда пытаются решить какую-нибудь проблему, и многие знакомые администраторы говорят мне, что используют Event Viewer только на серверах. Оба подхода ошибочны, потому что периодическая проверка системных журналов часто позволяет выявлять неполадки на ранней стадии, до того как они превратятся в серьезную проблему. Уметь пользоваться Event Viewer очень важно, поэтому я хочу предложить читателям краткий обзор по этой теме и представить свои способы работы с Event Viewer.
Общие сведения
Event Viewer открывается через меню Administrative Tools (если это меню добавлено в Programs) или через приложение Administrative Tools панели управления. Консоль программы Event Viewer содержит список доступных журналов. На компьютерах Windows по умолчанию имеются следующие журналы:
- Application (журнал приложе-ний) — содержит события, записываемые программами. Приложение определяет типы записываемых событий и язык сообщения.
- Security (журнал безопасности) — содержит события, относящиеся к безопасности компьютера, такие как попытки регистрации в системе или манипуляции с файлами.
- System (журнал системы) — содержит события, записываемые компонентами Windows.
В системах Windows Server 2003 и Windows 2000 Server в зависимости от роли сервера можно также использовать следующие журналы:
- Directory Service — содержит события, имеющие отношение к Active Directory (AD), и доступен только на контроллерах домена (DC).
- File Replication Service — содержит события, записываемые во время репликации между DC, и доступен только на DC.
- DNS Server — содержит события, относящиеся к разрешению имен DNS, и доступен только на серверах DNS.
Event Viewer отображает типы событий, каждое из которых имеет собственный уровень важности и собственную пиктограмму в журнале. Например:
- Error (ошибка) — сигнализирует об актуальной проблеме, которая может касаться потери функциональности, такой как нарушение корректного запуска служб и драйверов.
- Warning (предупреждение) — указывает на проблему, которая впоследствии может стать серьезной, если не обращать внимания на предупреждение. Предупреждения сугубо информативны и не свидетельствуют о наличии проблемы в настоящем или обязательном ее появлении в будущем.
- Success Audit (аудит успехов) — это событие, имеющее отношение к системе безопасности, которое произошло и записывается потому, что система или администратор включили аудит данного события.
- Failure Audit (аудит отказов) — это событие, имеющее отношение к системе безопасности, которое не произошло, но запись о нем делается потому, что система или администратор включили аудит данного события.
Информация, отображаемая в Event Viewer, включает дату и время, когда произошло событие, источник события (то есть служба, драйвер устройства или приложение, записавшее событие в журнал), категорию события, ID события, имя пользователя, который был зарегистрирован в системе, когда событие произошло (не обязательно) и имя компьютера, на котором произошло событие. Для того чтобы просматривать журнал Security, необходимо иметь права администратора.
Настройка Event Viewer
Системные журналы начинают функционировать автоматически при запуске операционной системы. Размеры журнальных файлов ограничены, и система записывает события, удаляя старые записи в соответствии с выбором параметров журнала. Чтобы просмотреть или изменить конфигурацию, нужно щелкнуть правой кнопкой на имени журнала в списке Event Viewer и выбрать в раскрывающемся меню пункт Properties. Должно появиться соответствующее диалоговое окно свойств, как показано на экране 1.
Экран 1. Настройка размеров и режима перезаписи журнала System |
Менять конфигурацию следует в зависимости от ситуации. Если вы не вносите существенных изменений в конфигурацию журнала или не видите необходимости в аудите событий, то работа настроек по умолчанию должна вас устроить. Настройка по умолчанию для максимального размера файла журнала составляет 512 Кбайт, и когда журнал заполнен, система автоматически заменяет старые записи новыми через 7 дней. Однако, если в систему вносятся существенные изменения или вводится в действие подробный аудит, журналы, скорее всего, начнут заполняться многочисленными записями. Если журнал оказывается заполненным и не содержит записей, хранящихся более 7 дней, утилите Event Viewer будет нечего удалить, чтобы освободить место для новых записей, и система прекратит записывать события. В этой ситуации нужно увеличить размер журнального файла или выполнить настройку журнала на затирание старых записей по мере необходимости (вариант Overwrite events — as needed).
Фильтры
Когда администратор исследует журнал, чтобы решить какую-либо проблему, или проверяет реакцию компьютера на существенное изменение конфигурации, он может ускорить этот процесс, избавившись от не имеющих отношения к делу записей в панели Details. Диалоговое окно Properties каждого журнала имеет вкладку Filter, с помощью которой выбираются типы отображаемых событий. Например, вы не хотите видеть информационные записи от определенных компьютеров или вы хотите видеть только события, произошедшие в течение недели после внесения системных изменений. Следует просто нужным образом выбрать фильтры (или отменить выбор). Помните, что фильтры влияют только на то, что отображается в окне; система продолжает записывать в журнал события тех типов, которые были отфильтрованы. Например, если есть основания полагать, что возникла угроза системе безопасности в виде вторжения извне, можно оставить для отображения события только тех типов, быстрый взгляд на которые позволяет обнаружить аномалии в регистрации, такие как события с ID 675 и 681, соответствующие неудачным попыткам аутентификации, или событие с ID 644, означающее блокировку учетной записи вследствие многократного некорректного ввода пароля.
Сортировка журнала
Погружаясь в решение какой-нибудь проблемы, я предпочитаю сортировать журналы, чтобы иметь возможность находить нужные записи непосредственно по типу события, идентификационному номеру (ID) события или по предполагаемому источнику сообщения. Например, я могла бы задаться целью найти событие Userenv, если проблема касается некоторого пользователя, имеющего проблемы с доступом в сети.
Общее событие Userenv имеет ID 1000 в журнале приложений и его описание гласит, что Windows не смогла определить имя пользователя или компьютера. Это означает, что конфигурация TCP/IP компьютера для обращения к DNS-серверу установлена некорректно. Администраторы сплошь и рядом используют неправильные адреса при настройке DNS на клиентских компьютерах; я часто нахожу IP-адрес шлюза в поле для адреса DNS. Проверку журнала компьютера-«обидчика» со своей рабочей станции обычно выполнить проще, чем идти к клиентскому компьютеру и проверять настройки TCP/IP.
Чтобы сосредоточиться на событиях конкретных типов, нужно выбрать подходящий журнал в консоли, раскрыть его содержимое, затем щелкнуть область заголовка столбца, по которому предстоит выполнить сортировку. По умолчанию журналы отсортированы по дате, а затем по времени.
Очистка журнала
Любой журнал можно очистить, чтобы освободить дополнительное место для записей. Если выбрана настройка Do not overwrite events (clear log manually) —«Не затирать события (очистка журнала вручную)», необходимо периодически чистить журнал.
Чтобы очистить журнал, следует щелкнуть правой кнопкой на названии журнала в списке консоли Event Viewer и выбрать пункт Clear all Events («Стереть все события»). Система спрашивает, нужно ли сохранить журнал перед тем, как очистить его. Если в журнале есть записи, которые могли бы пригодиться в будущем (например, при длительном отслеживании проблемы), можно выполнить архивацию содержимого журнала.
Архивация журнала
Любой журнал можно заархивировать как отдельный файл — это полезно, если в журнале появляются необычные записи и требуется понаблюдать некоторое время за изменением его содержимого. Иногда в журналах появляются события, которые выглядят угрожающе, но пользователь не ощущает никаких проблем. Если проблемы возникнут позже, сотрудникам службы поддержки Microsoft, возможно, будет полезно изучить историю этого события.
Чтобы создать архивную копию журнала, нужно щелкнуть правой кнопкой мыши по названию журнала в консоли и выбрать в меню Save Log File As («Сохранить файл журнала как…»). По умолчанию Windows сохраняет файл в папке Administrative Tools, расположенной в папке C:documentssettingsusernamestart menuprograms. Можно указать другую папку или создать отдельную папку для хранения архивных копий журналов. Я обычно присваиваю журналам имя в формате имя_журнала-дата (например, apps-dec012003). Windows добавляет расширение .evt.
Архивные копии журналов являются отдельными файлами на жестком диске, но открывать их можно только через программу просмотра событий Event Viewer. Для этого следует выбрать пункт Open Log File («Открыть файл журнала») в меню Action (или щелкнуть правой кнопкой по любому объекту в консоли и выбрать Open Log File). В диалоговом окне открытия файла требуется выбрать нужный архив, указать тип журнала (т. е. Application, Security) в меню со списком Log Type, затем щелкнуть Open.
Чтобы удалить архив из консоли, следует щелкнуть правой кнопкой по его названию в списке и выбрать Delete. Это действие не удаляет файл с жесткого диска — только из консоли. Удаление архивной копии журнала с жесткого диска выполняется так же, как и удаление любого другого файла.
Просмотр событий на удаленном компьютере
Чтобы облегчить себе задачу, администратор может со своей рабочей станции просматривать журналы удаленных компьютеров, на которых у него есть административные привилегии. На удаленном компьютере должна быть установлена Windows 2003, Windows XP, Windows 2000 Professional, Windows 2000 Server, Windows NT Server или NT Workstation.
На локальной консоли просмотра событий нужно щелкнуть правой кнопкой Event Viewer (Local) и выбрать Connect to another computer («Подключиться к другому компьютеру»). Следует ввести имя удаленного компьютера, с которым предстоит работать, или щелкнуть Browse, чтобы открыть диалоговое окно, показанное на экране 2, затем выбрать компьютер. Кроме того, если имя удаленного компьютера известно, нет необходимости вводить его в виде имени UNC. Вид консоли Event Viewer меняется таким образом, что отображает имя UNC удаленного компьютера. На удаленном компьютере можно производить те же действия, что и на локальном Event Viewer. Чтобы вернуться на локальный компьютер, следует щелкнуть правой кнопкой Event Viewer (имя компьютера), выбрать Connect to another computer, а затем Local computer.
Экран 2. Доступ к удаленному компьютеру из Event Viewer |
Что искать при просмотре событий
Большинство реальных и потенциальных проблем проявляют себя посредством записи событий в тот или иной журнал. Когда вы видите запись с пометкой Error или Warning, будьте внимательны. Поищите информацию об этом событии в Microsoft Knowledge Base или на Web-сайте Windows & .NET Magazine. Если медлить с просмотром журналов, вы упустите возможность предотвратить проблему. Приведу пример. Во время периодических просмотров журналов на всех компьютерах своей сети я обнаруживаю запись в системном журнале, которая показана на экране 3. Никаких видимых признаков неполадок на компьютере не было.
Экран 3. Обнаружение надвигающегося сбоя в Event Viewer |
Я быстро выполняю резервное копирование данных компьютера и запускаю программу Chkdsk, которая перемещает файлы (это были системные файлы) из испорченной области и помечает ее как испорченную, чтобы предотвратить дальнейшую запись в эту часть диска. Затем я начинаю ежедневно проверять системный журнал в течение нескольких недель и, только убедившись, что никаких новых сообщений об ошибках не появляется, возвращаюсь к еженедельному просмотру Event Viewer. Увидев дополнительные сообщения об ошибках, я бы заменила диск. Если бы я периодически не проверяла журналы компьютера, диск мог бы продолжать разваливаться и резервное копирование оказалось бы бесполезным из-за порчи файлов.
Кстати, когда я проверяю Event Viewer, я выполняю сортировку событий по типу и сначала просматриваю сообщения об ошибках, а затем предупреждения. В этот раз я также обнаружила предупреждение, датированное днем раньше, чем появилось сообщение об ошибке, и в этом предупреждении говорилось, что при записи в файл подкачки Windows обнаружила ошибку на диске. Если бы я проверила системный журнал днем раньше, я бы, возможно, нашла меньшее количество испорченных фрагментов для исправления программой Chkdsk.
Следует также просматривать все события в журнале безопасности. Этот журнал будет оставаться пустым до тех пор, пока вы не установите аудит событий безопасности. Если аудит событий безопасности установлен, ищите значительные события в зависимости от настроек аудита. Журнал безопасности — единственный журнал в Event Viewer, для просмотра которого необходимы административные полномочия. Более подробную информацию об аудите событий безопасности можно найти в статье «Мониторинг событий безопасности» (Windows & .NET Magazine/RE, №7 за 2003 год, и на Web-странице http://www.osp.ru/win2000/2003/07/019.htm).
Как остановить запись нежелательных событий
По умолчанию Windows настраивает компьютеры как принт-серверы, которые записывают все события, относящиеся к печати на принтерах. Кроме того, системный журнал компьютера делает информационные записи при каждой отправке документа на принтер и повторно — когда файл спулера удален после выполнения задания на печать.
Для меня события, относящиеся к печати на принтерах, не имеют значения, но некоторые администраторы хотят знать, были ли ошибки в работе с принтерами и если были, то когда; возможна также запись уведомлений, когда кто-то добавляет или удаляет принтер. Сомневаюсь, что администраторы убеждены в необходимости пополнять журнал уведомлений каждый раз, когда задание на печать отправляется спулеру, а потом удаляется.
Можно изменить выбор событий печати, записываемых в системный журнал, в папке Printers компьютера (в Windows 2003 и XP она называется Printers and Faxes). Выберите File, Server Properties и перейдите на вкладку Advanced, показанную на экране 4. Можно просто отменить выбор событий, которые вы не хотите регистрировать в журнале.
Экран 4. Выбор событий печати, записываемых в журнал System |
Возьмите за правило
Поместите Event Viewer в свой список задач по обслуживанию и периодически проверяйте сетевые компьютеры. Если вы отвечаете за множество компьютеров, обеспечьте по крайней мере еженедельную проверку серверов (особенно контроллеров доменов), а рабочие станции следует проверять так, чтобы каждая рабочая станция попадала в поле зрения раз в несколько недель. Хотя на первый взгляд может показаться, что эта задача очень трудоемкая, устранение серьезной проблемы отнимает намного больше времени и сил, чем проверка журналов для получения дополнительной информации о текущих неполадках.
Кэти Ивенс (kivens@win2000mag.com) — редактор Windows & .NET Magazine. Является соавтором более 40 книг по компьютерной тематике, включая «Windows 2000: The Complete Reference»