Журналы Windows
Операционная система Windows, системные службы и приложения записывают события и ошибки в системные журналы, чтобы в дальнейшем у системного администратора была возможность проверки операционной системы и диагностики проблем.
Получить доступ к этим записям можно через встроенное приложение Просмотр событий (Event Viewer). Есть несколько вариантов запуска данного приложения:
В Диспетчере серверов в разделе Средства выбрать Просмотр событий (Server Manager – Tools – Event Viewer):
Описание интерфейса программы
Окно программы состоит из следующих компонентов:
Для удобства просмотра и управления системные журналы разбиты по категориям:
В разделе Журналы приложений и служб (Applications and Services Logs) можно найти более детальную информацию о событиях отдельных служб и приложений, зарегистрированных в операционной системе, что бывает полезно при диагностике проблем в работе отдельных сервисов.
Сами события также разделяются на типы:
Работа с журналами
Службы и приложения могут генерировать огромное количество самых разнообразных событий. Для простоты доступа к нужным записям журнала можно использовать функцию фильтрации журнала:
Правый клик по журналу – Фильтр текущего журнала… (>Filter Current Log…), либо выбрать данную функцию в панели быстрых действий. Открывшееся окно позволяет настроить фильтр и отобразить только те события, которые необходимы в данный момент:
Можно задать временной период, уровни события, выбрать журналы и конкретные источники событий. Если известны коды событий, которые нужно включить или исключить из фильтра, их также можно указать.
Когда необходимость в фильтрации событий отпадет, ее можно отключить действием Очистить фильтр (Clear Filter):
Приложение Просмотр событий (Event Viewer) позволяет также настроить дополнительные свойства журналов. Доступ к настройкам можно получить через панель быстрых действий, либо через контекстное меню журнала – правый клик по журналу – Свойства (Properties):
В открывшемся окне настроек можно увидеть путь, по которому сохраняется файл журнала, текущий размер, а также можно задать максимальный размер файла:
В нижней части окна можно выбрать вариант действия при достижении журналом максимального значения:
Журналирование Windows EventLog и система оповещения для администраторов
Некоторое количество времени(года три) назад, в попытке найти способ экспорта Windows EventLog, была найдена возможность в удобном виде осуществлять аудит различных событий происходящих на сервере.
Microsoft своими «добрыми» технологиями сделала Windows практически несовместимым со штатными системами журналирования событий(syslog), но оставила небольшую лазейку которую можно использовать.
Лазейка представляет собой комбинацию SNMP trap и программы экспорта системных событий evntwin.
Для работы связки нужен настроенный snmptrapd, а также активированный сервис SNMP на windows сервере (добавляется через «добавление/удаление компонентов»).
Первым делом нужно настроить сервер на который будут сбрасываться сообщения из Eventlog. 
После того как сервис настроен, запускаем программу evntwin.exe
technet.microsoft.com/en-us/library/cc759390%28WS.10%29.aspx
Как она выглядит видно на следующем скриншоте.
Принцип использования evntwin прост. Вы выбираете категорию и код события которые Вас интересуют и добавляете их в список. При наступлении события сообщение одновременно будет сохранено в EventLog, а также будет «трапнуто» на сервер мониторинга.
На сервере мониторинга в snmptrapd.conf нужно добавить строку обработчика.
Сам обработчик написан мной на perl, код можно взять по ссылке trapd.pl(Не рекомендуется копипастить подсвеченный код из поста, лучше взять по ссылке). Он разбирает входящие trap сообщения и формирует письмо администраторам.
Hostname: bdc.mydoman.ru
Source: UDP: [192.168.0.3]:1081
Change Password Attempt:
Target Account Name:pupkin_v
Target Domain:MYDOM
Target Account ID:%
Caller User Name:pupkin_v
Caller Domain:MYDOM
Caller Logon ID:(0x0,0x39B1BD)
Hostname: sadc.mydomain.ru
Source: UDP: [192.168.0.4]:1074
User Account Locked Out:
Target Account Name:ivanov_v
Target Account ID:%
Caller Machine Name:MX
Caller User Name:SADC$
Caller Domain:MYDOM
Caller Logon ID:(0x0,0x3E7)
Hostname: sadc.mydomain.ru
Source: UDP: [192.168.0.4]:1072
Logon Failure:
Reason:Unknown user name or bad password
User Name:Popov_V
Domain:MYDOM
Logon Type:3
Logon Process:Advapi
Authentication Package:Negotiate
Workstation Name:SADC
Caller User Name:SADC$
Caller Domain:MYDOM
Caller Logon ID:(0x0,0x3E7)
Caller Process ID:580
Source Network Address:192.168.0.20
Source Port:36018
Так как мы подписаны только на интересующие нас сообщения, мы не видим остального системного мусора из EventLog.
Очень удобна данная система при вирусных эпидемиях типа Kido, когда сразу нельзя понять откуда пошло всё размножаться или при брутфорсе системных паролей. Потому что чётко виден Logon Failure и имя машины с которой была неудачная попытка.
Спокойной Вам работы.
PS: готовый конфиг с представленными на скриншоте категориями лежит тут
Что полезного можно вытащить из логов рабочей станции на базе ОС Windows
Пользовательская рабочая станция — самое уязвимое место инфраструктуры по части информационной безопасности. Пользователям может прийти на рабочую почту письмо вроде бы из безопасного источника, но со ссылкой на заражённый сайт. Возможно, кто-то скачает полезную для работы утилиту из неизвестно какого места. Да можно придумать не один десяток кейсов, как через пользователей вредоносное ПО может внедриться на внутрикорпоративные ресурсы. Поэтому рабочие станции требуют повышенного внимания, и в статье мы расскажем, откуда и какие события брать для отслеживания атак.
Для выявления атаки на самой ранней стадии в ОС Windows есть три полезных событийных источника: журнал событий безопасности, журнал системного мониторинга и журналы Power Shell.
Журнал событий безопасности (Security Log)
Это главное место хранения системных логов безопасности. Сюда складываются события входа/выхода пользователей, доступа к объектам, изменения политик и других активностей, связанных с безопасностью. Разумеется, если настроена соответствующая политика.
Перебор пользователей и групп (события 4798 и 4799). Вредоносное ПО в самом начале атаки часто перебирает локальные учетные записи пользователей и локальные группы на рабочей станции, чтобы найти учетные данные для своих тёмных делишек. Эти события помогут обнаружить вредоносный код раньше, чем он двинется дальше и, используя собранные данные, распространится на другие системы.
Создание локальной учётной записи и изменения в локальных группах (события 4720, 4722–4726, 4738, 4740, 4767, 4780, 4781, 4794, 5376 и 5377). Атака может также начинаться, например, с добавления нового пользователя в группу локальных администраторов.
Попытки входа с локальной учётной записью (событие 4624). Добропорядочные пользователи заходят с доменной учётной записью и выявление входа под локальной учётной записью может означать начало атаки. Событие 4624 включает также входы под доменной учетной записью, поэтому при обработке событий нужно зафильтровать события, в которых домен отличается от имени рабочей станции.
Попытка входа с заданной учётной записью (событие 4648). Такое бывает, когда процесс выполняется в режиме “Запуск от имени” (run as). В нормальном режиме работы систем такого не должно быть, поэтому такие события должны находиться под контролем.
Блокировка/разблокировка рабочей станции (события 4800-4803). К категории подозрительных событий можно отнести любые действия, которые происходили на заблокированной рабочей станции.
Изменения конфигурации файрволла (события 4944-4958). Очевидно, что при установке нового ПО настройки конфигурации файрволла могут меняться, что вызовет ложные срабатывания. Контролировать такие изменения в большинстве случаев нет необходимости, но знать о них точно лишним не будет.
Подключение устройств Plug’n’play (событие 6416 и только для WIndows 10). За этим важно следить, если пользователи обычно не подключают новые устройства к рабочей станции, а тут вдруг раз — и подключили.
Windows включает в себя 9 категорий аудита и 50 субкатегорий для тонкой настройки. Минимальный набор субкатегорий, который стоит включить в настройках:
Системный монитор (Sysmon)
Sysmon — встроенная в Windows утилита, которая умеет записывать события в системный журнал. Обычно требуется его устанавливать отдельно.
Эти же события можно в принципе найти в журнале безопасности (включив нужную политику аудита), но Sysmon даёт больше подробностей. Какие события можно забирать из Sysmon?
Создание процесса (ID события 1). Системный журнал событий безопасности тоже может сказать, когда запустился какой-нибудь *.exe и даже покажет его имя и путь запуска. Но в отличие от Sysmon не сможет показать хэш приложения. Злонамеренное ПО может называться даже безобидным notepad.exe, но именно хэш выведет его на чистую воду.
Сетевые подключения (ID события 3). Очевидно, что сетевых подключений много, и за всеми не уследить. Но важно учитывать, что Sysmon в отличие от того же Security Log умеет привязать сетевое подключение к полям ProcessID и ProcessGUID, показывает порт и IP-адреса источника и приёмника.
Изменения в системном реестре (ID события 12-14). Самый простой способ добавить себя в автозапуск — прописаться в реестре. Security Log это умеет, но Sysmon показывает, кто внёс изменения, когда, откуда, process ID и предыдущее значение ключа.
Создание файла (ID события 11). Sysmon, в отличие от Security Log, покажет не только расположение файла, но и его имя. Понятно, что за всем не уследишь, но можно же проводить аудит определённых директорий.
А теперь то, чего в политиках Security Log нет, но есть в Sysmon:
Изменение времени создания файла (ID события 2). Некоторое вредоносное ПО может подменять дату создания файла для его скрытия из отчётов с недавно созданными файлами.
Загрузка драйверов и динамических библиотек (ID событий 6-7). Отслеживание загрузки в память DLL и драйверов устройств, проверка цифровой подписи и её валидности.
Создание потока в выполняющемся процессе (ID события 8). Один из видов атаки, за которым тоже нужно следить.
События RawAccessRead (ID события 9). Операции чтения с диска при помощи “\\.\”. В абсолютном большинстве случаев такая активность должна считаться ненормальной.
Создание именованного файлового потока (ID события 15). Событие регистрируется, когда создается именованный файловый поток, который генерирует события с хэшем содержимого файла.
Создание named pipe и подключения (ID события 17-18). Отслеживание вредоносного кода, который коммуницирует с другими компонентами через named pipe.
Активность по WMI (ID события 19). Регистрация событий, которые генерируются при обращении к системе по протоколу WMI.
Для защиты самого Sysmon нужно отслеживать события с ID 4 (остановка и запуск Sysmon) и ID 16 (изменение конфигурации Sysmon).
Журналы Power Shell
Power Shell — мощный инструмент управления Windows-инфраструктурой, поэтому велики шансы, что атакующий выберет именно его. Для получения данных о событиях Power Shell можно использовать два источника: Windows PowerShell log и Microsoft-WindowsPowerShell / Operational log.
Windows PowerShell log
Загружен поставщик данных (ID события 600). Поставщики PowerShell — это программы, которые служат источником данных для PowerShell для просмотра и управления ими. Например, встроенными поставщиками могут быть переменные среды Windows или системный реестр. За появлением новых поставщиков нужно следить, чтобы вовремя выявить злонамеренную активность. Например, если видите, что среди поставщиков появился WSMan, значит был начат удаленный сеанс PowerShell.
Microsoft-WindowsPowerShell / Operational log (или MicrosoftWindows-PowerShellCore / Operational в PowerShell 6)
Журналирование модулей (ID события 4103). В событиях хранится информация о каждой выполненной команде и параметрах, с которыми она вызывалась.
Журналирование блокировки скриптов (ID события 4104). Журналирование блокировки скриптов показывает каждый выполненный блок кода PowerShell. Даже если злоумышленник попытается скрыть команду, этот тип события покажет фактически выполненную команду PowerShell. Ещё в этом типе события могут фиксироваться некоторые выполняемые низкоуровневые вызовы API, эти события обычно записывается как Verbose, но если подозрительная команда или сценарий используются в блоке кода, он будет зарегистрирован как c критичностью Warning.
Обратите внимание, что после настройки инструмента сбора и анализа этих событий потребуется дополнительное время на отладку для снижения количества ложных срабатываний.
Расскажите в комментариях, какие собираете логи для аудита информационной безопасности и какие инструменты для этого используете. Одно из наших направлений — решения для аудита событий информационной безопасности. Для решения задачи сбора и анализа логов можем предложить присмотреться к Quest InTrust, который умеет сжимать хранящиеся данные с коэффициентом 20:1, а один его установленный экземпляр способен обрабатывать до 60000 событий в секунду из 10000 источников.
Вертим логи как хотим ― анализ журналов в системах Windows
Пора поговорить про удобную работу с логами, тем более что в Windows есть масса неочевидных инструментов для этого. Например, Log Parser, который порой просто незаменим.
В статье не будет про серьезные вещи вроде Splunk и ELK (Elasticsearch + Logstash + Kibana). Сфокусируемся на простом и бесплатном.
Журналы и командная строка
До появления PowerShell можно было использовать такие утилиты cmd как find и findstr. Они вполне подходят для простой автоматизации. Например, когда мне понадобилось отлавливать ошибки в обмене 1С 7.7 я использовал в скриптах обмена простую команду:
Она позволяла получить в файле fail.txt все ошибки обмена. Но если было нужно что-то большее, вроде получения информации о предшествующей ошибке, то приходилось создавать монструозные скрипты с циклами for или использовать сторонние утилиты. По счастью, с появлением PowerShell эти проблемы ушли в прошлое.
Основным инструментом для работы с текстовыми журналами является командлет Get-Content, предназначенный для отображения содержимого текстового файла. Например, для вывода журнала сервиса WSUS в консоль можно использовать команду:
Для вывода последних строк журнала существует параметр Tail, который в паре с параметром Wait позволит смотреть за журналом в режиме онлайн. Посмотрим, как идет обновление системы командой:
Смотрим за ходом обновления Windows.
Если же нам нужно отловить в журналах определенные события, то поможет командлет Select-String, который позволяет отобразить только строки, подходящие под маску поиска. Посмотрим на последние блокировки Windows Firewall:
Смотрим, кто пытается пролезть на наш дедик.
При необходимости посмотреть в журнале строки перед и после нужной, можно использовать параметр Context. Например, для вывода трех строк после и трех строк перед ошибкой можно использовать команду:
Оба полезных командлета можно объединить. Например, для вывода строк с 45 по 75 из netlogon.log поможет команда:
Для получения списка доступных системных журналов можно выполнить следующую команду:
Вывод доступных журналов и информации о них.
Для просмотра какого-то конкретного журнала нужно лишь добавить его имя. Для примера получим последние 20 записей из журнала System командой:
Последние записи в журнале System.
Для получения определенных событий удобнее всего использовать хэш-таблицы. Подробнее о работе с хэш-таблицами в PowerShell можно прочитать в материале Technet about_Hash_Tables.
Для примера получим все события из журнала System с кодом события 1 и 6013.
В случае если надо получить события определенного типа ― предупреждения или ошибки, ― нужно использовать фильтр по важности (Level). Возможны следующие значения:
Собрать хэш-таблицу с несколькими значениями важности одной командой так просто не получится. Если мы хотим получить ошибки и предупреждения из системного журнала, можно воспользоваться дополнительной фильтрацией при помощи Where-Object:
Ошибки и предупреждения журнала System.
Аналогичным образом можно собирать таблицу, фильтруя непосредственно по тексту события и по времени.
Подробнее почитать про работу обоих командлетов для работы с системными журналами можно в документации PowerShell:
PowerShell ― механизм удобный и гибкий, но требует знания синтаксиса и для сложных условий и обработки большого количества файлов потребует написания полноценных скриптов. Но есть вариант обойтись всего-лишь SQL-запросами при помощи замечательного Log Parser.
Работаем с журналами посредством запросов SQL
Утилита Log Parser появилась на свет в начале «нулевых» и с тех пор успела обзавестись официальной графической оболочкой. Тем не менее актуальности своей она не потеряла и до сих пор остается для меня одним из самых любимых инструментов для анализа логов. Загрузить утилиту можно в Центре Загрузок Microsoft, графический интерфейс к ней ― в галерее Technet. О графическом интерфейсе чуть позже, начнем с самой утилиты.
О возможностях Log Parser уже рассказывалось в материале «LogParser — привычный взгляд на непривычные вещи», поэтому я начну с конкретных примеров.
Для начала разберемся с текстовыми файлами ― например, получим список подключений по RDP, заблокированных нашим фаерволом. Для получения такой информации вполне подойдет следующий SQL-запрос:
Посмотрим на результат:
Смотрим журнал Windows Firewall.
Разумеется, с полученной таблицей можно делать все что угодно ― сортировать, группировать. Насколько хватит фантазии и знания SQL.
Log Parser также прекрасно работает с множеством других источников. Например, посмотрим откуда пользователи подключались к нашему серверу по RDP.
Работать будем с журналом TerminalServices-LocalSessionManager\Operational.
Не со всеми журналами Log Parser работает просто так ― к некоторым он не может получить доступ. В нашем случае просто скопируем журнал из %SystemRoot%\System32\Winevt\Logs\Microsoft-Windows-TerminalServices-LocalSessionManager%4Operational.evtx в %temp%\test.evtx.
Данные будем получать таким запросом:
Смотрим, кто и когда подключался к нашему серверу терминалов.
Особенно удобно использовать Log Parser для работы с большим количеством файлов журналов ― например, в IIS или Exchange. Благодаря возможностям SQL можно получать самую разную аналитическую информацию, вплоть до статистики версий IOS и Android, которые подключаются к вашему серверу.
В качестве примера посмотрим статистику количества писем по дням таким запросом:
Если в системе установлены Office Web Components, загрузить которые можно в Центре загрузки Microsoft, то на выходе можно получить красивую диаграмму.
Выполняем запрос и открываем получившуюся картинку…
Любуемся результатом.
Следует отметить, что после установки Log Parser в системе регистрируется COM-компонент MSUtil.LogQuery. Он позволяет делать запросы к движку утилиты не только через вызов LogParser.exe, но и при помощи любого другого привычного языка. В качестве примера приведу простой скрипт PowerShell, который выведет 20 наиболее объемных файлов на диске С.
Ознакомиться с документацией о работе компонента можно в материале Log Parser COM API Overview на портале SystemManager.ru.
Благодаря этой возможности для облегчения работы существует несколько утилит, представляющих из себя графическую оболочку для Log Parser. Платные рассматривать не буду, а вот бесплатную Log Parser Studio покажу.
Интерфейс Log Parser Studio.
Основной особенностью здесь является библиотека, которая позволяет держать все запросы в одном месте, без россыпи по папкам. Также сходу представлено множество готовых примеров, которые помогут разобраться с запросами.
Вторая особенность ― возможность экспорта запроса в скрипт PowerShell.
В качестве примера посмотрим, как будет работать выборка ящиков, отправляющих больше всего писем:
Выборка наиболее активных ящиков.
При этом можно выбрать куда больше типов журналов. Например, в «чистом» Log Parser существуют ограничения по типам входных данных, и отдельного типа для Exchange нет ― нужно самостоятельно вводить описания полей и пропуск заголовков. В Log Parser Studio нужные форматы уже готовы к использованию.
Помимо Log Parser, с логами можно работать и при помощи возможностей MS Excel, которые упоминались в материале «Excel вместо PowerShell». Но максимального удобства можно достичь, подготавливая первичный материал при помощи Log Parser с последующей обработкой его через Power Query в Excel.
Приходилось ли вам использовать какие-либо инструменты для перелопачивания логов? Поделитесь в комментариях.
Журнал событий в Windows 7/10 – где находится и как открыть?
Даже когда пользователь ПК не совершает никаких действий, операционная система продолжает считывать и записывать множество данных. Наиболее важные события отслеживаются и автоматически записываются в особый лог, который в Windows называется Журналом событий. Но для чего нужен такой мониторинг? Ни для кого не является секретом, что в работе операционной системы и установленных программ могут возникать сбои. Чтобы администраторы могли находить причины таких ошибок, система должна их регистрировать, что собственно она и делает.
Итак, основным предназначением Журнала событий в Windows 7/10 является сбор данных, которые могут пригодиться при устранении неисправностей в работе системы, программного обеспечения и оборудования. Впрочем, заносятся в него не только ошибки, но также и предупреждения, и вполне удачные операции, например, установка новой программы или подключение к сети.
Где находится журнал событий Windows
Физически Журнал событий представляет собой набор файлов в формате EVTX, хранящихся в системной папке %SystemRoot%/System32/Winevt/Logs.
Хотя эти файлы содержат текстовые данные, открыть их Блокнотом или другим текстовым редактором не получится, поскольку они имеют бинарный формат. Тогда как посмотреть Журнал событий в Windows 7/10, спросите вы? Очень просто, для этого в системе предусмотрена специальная штатная утилита eventvwr.
Как открыть журнал
Запустить утилиту можно из классической Панели управления, перейдя по цепочке Администрирование – Просмотр событий или выполнив в окошке Run (Win+R) команду eventvwr.msc.
В левой колонке окна утилиты можно видеть отсортированные по разделам журналы, в средней отображается список событий выбранной категории, в правой – список доступных действий с выбранным журналом, внизу располагается панель подробных сведений о конкретной записи. Всего разделов четыре: настраиваемые события, журналы Windows, журналы приложений и служб, а также подписки.
Наибольший интерес представляет раздел «Журналы Windows», именно с ним чаще всего приходится работать, выясняя причины неполадок в работе системы и программ. Журнал системных событий включает три основных и две дополнительных категории. Основные это «Система», «Приложения» и «Безопасность», дополнительные – «Установка» и «Перенаправленные события».
Категория «Система» содержит события, сгенерированные системными компонентами – драйверами и модулями Windows.
Ветка «Приложения» включает записи, созданные различными программами. Эти данные могут пригодиться как системным администраторам и разработчикам программного обеспечения, так и обычным пользователям, желающим установить причину отказа той или иной программы.
Третья категория событий «Безопасность» содержит сведения, связанные с безопасностью системы. К ним относятся входы пользователей в аккаунты, управление учётными записями, изменение разрешений и прав доступа к файлам и папкам, запуск и остановка процессов и так далее.
Так как число событий может исчисляться тысячами и даже десятками тысяч, в eventvwr предусмотрена возможность поиска и фильтрации событий по свойствам – важности, времени, источнику, имени компьютера и пользователя, коду и так далее. Допустим, вы хотите получить список системных ошибок. Выберите слева Журналы Windows – Система, справа нажмите «Фильтр текущего журнала» и отметьте в открывшемся окне галочкой уровень события – пункты «Ошибка» и «Критическое». Нажмите «OK» и утилита тут же отфильтрует записи.
Чтобы просмотреть конкретную запись, кликните по ней дважды – сведения откроются в окошке «Свойства событий».
Как использовать содержимое журнала
Хорошо, теперь мы в курсе, где находится журнал событий и как его открыть, осталось узнать, как его можно использовать. Сразу нужно сказать, что в силу своей специфичности содержащиеся в нем сведения мало что могут поведать обычному пользователю. О чем говорит, к примеру, ошибка «Регистрация сервера
Так, описание приведенной выше ошибки имеется на сайте Microsoft и указывает оно на проблемы со SkyDrive, кстати, не представляющие совершенно никакой угрозы. Если вы не пользуетесь этим сервисом, ошибку можно игнорировать или отключить ее источник в «Планировщике заданий». А еще описание ошибки можно отправить разработчику, предварительно сохранив его в файл XML, CSV или TХT.
Также пользователи могут связывать отслеживаемые события с задачами в «Планировщике заданий». Для этого необходимо кликнуть ПКМ по записи, выбрать «Привязать задачу к событию» и создать с помощью запустившегося мастера нужное задание. В следующий раз, когда произойдет такое событие, система сама запустит выполнение задания.
Очистка, удаление и отключение журнала
На жестком диске файлы журнала занимают сравнительно немного места, тем не менее, у пользователя может возникнуть необходимость их очистить. Сделать это можно разными способами: с помощью оснастки eventvwr, командной строки и PowerShell. Для выборочной очистки вполне подойдет ручной способ. Нужно зайти в журнал событий, кликнуть ПКМ по очищаемому журналу в левой колонке и выбрать в меню опцию «Очистить журнал».
Если вы хотите полностью удалить все записи журнала, удобнее будет воспользоваться запущенной от имени администратора командной строкой. Команда очистки выглядит следующим образом:
for /F «tokens=*» %1 in (‘wevtutil.exe el’) DO wevtutil.exe cl «%1»
Вместо командной строки для быстрой и полной очистки журнала также можно воспользоваться консолью PowerShell. Откройте ее с повышенными правами и выполните в ней такую команду:
wevtutil el | Foreach-Object
При очистке через PowerShell в журнале могут остаться несколько записей. Это не беда, в крайнем случае события можно удалить вручную.
Итак, мы знаем, как открыть журнал событий, знаем, как его использовать и очищать, в завершение давайте посмотрим, как его полностью отключить, хотя делать это без особой нужды не рекомендуется, так как вместе с журналом событий отключатся некоторые, возможно нужные вам службы.
Командой services.msc откройте оснастку «Службы», справа найдите «Журнал событий Windows», кликните по нему дважды, в открывшемся окошке свойств тип запуска выберите «Отключено», а затем нажмите кнопку «Остановить».
Изменения вступят в силу после перезагрузки компьютера. Вот и все, больше системные и программные события регистрироваться не будут.