yamato-security/enablewindowslogsettingsДокументация и скрипты для правильного включения журналов событий Windows.
Это ещё одно руководство по правильной настройке и мониторингу журналов событий Windows с упором на ведение журналов для правил sigma.
Работа продолжается, поэтому периодически заглядывайте сюда за обновлениями.
Zach Mathis (@yamatosecurity). По мере проведения дальнейших исследований и тестирования я планирую периодически обновлять этот документ, так как есть много возможностей для улучшения (как в документации, так и в создании новых правил обнаружения). PR приветствуются, и я с радостью добавлю вас в список участников. Если вы найдёте ошибки в этой документации, пожалуйста, сообщите мне, и я исправлю их как можно скорее.
Если вы находите это полезным, пожалуйста, поставьте звёздочку на GitHub — это, вероятно, поможет мне сохранить мотивацию для продолжения обновлений.
Большая часть информации взята из FAQ по расширенному аудиту безопасности Microsoft, правил sigma, руководства по ведению журналов событий ACSC и моих собственных исследований и тестирования. Я хотел бы особо поблагодарить сообщество sigma за то, что сделало обнаружение угроз открытым и бесплатным на благо всех защитников.
По умолчанию Windows не ведёт журнал многих событий, необходимых для обнаружения вредоносной активности и проведения криминалистических расследований.
Кроме того, максимальный размер файлов событий по умолчанию составляет всего 20 МБ для классических журналов событий (Security, System, Application), 15 МБ для PowerShell и всего 1 МБ почти для всех остальных журналов, поэтому существует большая вероятность того, что улики со временем будут перезаписаны.
В этом репозитории предоставлен простой пакетный скрипт, который позволяет системным администраторам легко настроить свои машины Windows, чтобы иметь нужные журналы при возникновении инцидента. Для крупных сетей, вероятно, стоит использовать этот документ в качестве справочника и настраивать конечные точки с помощью групповой политики и/или InTune.
Я настоятельно рекомендую улучшить настройки журналирования событий Windows по умолчанию и стараюсь предоставить максимально точную информацию. Тем не менее, я не несу никакой ответственности за любые неблагоприятные последствия включения чрезмерного журналирования или за точность чего-либо в этом репозитории. Вы несёте ответственность за то, чтобы понять и протестировать любые изменения, которые вы вносите в свои системы, на тестовых машинах перед развёртыванием в производственной среде. Я рекомендую включить как можно больше журналирования на тестовых машинах, имитирующих вашу среду, как минимум на неделю, а затем проверить, есть ли события, которые генерируют слишком много шума, или есть ли события, которые вам нужны, но не генерируются.
Вы можете просмотреть общее количество и процент идентификаторов событий в evtx-файле с помощью команды метрик идентификаторов событий Hayabusa.
Пример: hayabusa.exe eid-metrics -f path/to/Security.evtx
Process Creation, который отслеживает, какие процессы выполняются в системе.
В настоящее время около половины правил обнаружения Sigma полагаются на это событие.
Это можно сделать, установив Sysmon (идентификатор события 1) или включив встроенное событие журнала безопасности c идентификатором 4688.
Sysmon 1 предоставляет подробную информацию, такую как хэши и метаданные исполняемого файла, поэтому он идеален, но в случае, если Sysmon не может быть установлен, можно использовать встроенные журналы Security 4688. Однако важно, чтобы также было включено ведение журнала командной строки, поскольку на это полагаются многие правила обнаружения. К сожалению, Security 4688 не предоставляет столь же подробной информации, как журналы создания процессов Sysmon, поэтому не все правила Process Creation работают с Security 4688.
При настройках аудита Windows по умолчанию можно использовать лишь около 10–20% правил sigma!
Это непрактично в масштабе, но самый простой способ включить/отключить журналы и проверить и/или настроить их максимальный размер файла — щёлкнуть правой кнопкой мыши по журналу в Просмотре событий и открыть Свойства.
Вы можете использовать встроенную команду wevtutil.
Пример: wevtutil sl Security /ms:1073741824 — увеличить максимальный размер файла журнала безопасности до 1 ГБ.
Пример:```powershell $sysmon = Get-WinEvent -ListLog Microsoft-Windows-Sysmon/Operational $sysmon.MaximumSizeInBytes = 2048000000 #2GB $sysmon.SaveChanges()
## Вариант 4: групповая политика
Увеличить максимальный размер файла для классических журналов событий, таких как `Security`, `System` и `Application`, несложно; однако, к сожалению, для изменения максимального размера файла остальных журналов необходимо установить административные шаблоны и/или напрямую изменить реестр. Возможно, проще будет увеличивать размер файла при запуске с помощью пакетного или PowerShell-скрипта.
# Скрипт настройки
Скрипт для увеличения максимального размера файла и включения нужных журналов представлен здесь: [YamatoSecurityConfigureWinEventLogs.bat](https://github.com/yamato-security/enablewindowslogsettings/blob/HEAD/YamatoSecurityConfigureWinEventLogs.bat)
# Настройка параметров журналов
## Журнал Sysmon (1382 правила Sigma)
Файл: `Microsoft-Windows-Sysmon%4Operational.evtx`
Настройки по умолчанию: `Not installed`
Установка и настройка Sysmon — это лучшее, что вы можете сделать для повышения видимости в конечных точках Windows, но это потребует планирования, тестирования и сопровождения.
Это большая тема сама по себе, поэтому на данный момент она выходит за рамки этого документа.
Ознакомьтесь со следующими ресурсами:
* [Руководство сообщества TrustedSec по Sysmon](https://github.com/trustedsec/SysmonCommunityGuide)
* [Sysmon Modular](https://github.com/olafhartong/sysmon-modular)
* [Обновлённый форк Флориана Рота конфигурационного файла sysmon от Swift On Security](https://github.com/Neo23x0/sysmon-config)
* [Обновлённый форк Ion-storm конфигурационного файла sysmon от Swift On Security](https://github.com/ion-storm/sysmon-config)
* [Конфигурационный файл sysmon от Cyb3rWard0g](https://github.com/OTRF/Blacksmith/blob/master/resources/configs/sysmon/sysmon.xml)
## Журнал безопасности (1045 правил Sigma (903 правила создания процессов + 142 других правила))
Файл: `Security.evtx`
Настройки по умолчанию: `Partially enabled`
Журнал безопасности сложнее всего настраивать, поэтому я создал отдельный документ, посвящённый ему: [ConfiguringSecurityLogAuditPolicies.md](https://github.com/yamato-security/enablewindowslogsettings/blob/HEAD/ConfiguringSecurityLogAuditPolicies.md)
## Журналы PowerShell (175 правил Sigma)
Файл: `Microsoft-Windows-PowerShell%4Operational.evtx`
### Журналирование модулей (30 правил Sigma)
Включение журналирования модулей активирует событие с ID `4103`.
Преимущество журналирования модулей в том, что оно может работать на старых ОС и версиях PowerShell: PowerShell 3.0 (Win 7+).
Ещё одно преимущество: оно регистрирует и выполненную команду PowerShell, и результаты.
Недостаток в том, что оно создаёт чрезвычайно большое количество событий.
Например, если атакующий запустит Mimikatz, будет создано 7 МБ журналов с более чем 2000 событий!
#### Включение журналирования модулей
Настройки по умолчанию: `No Auditing`
##### Вариант 1: включение через групповую политику
В редакторе групповой политики (`gpedit.msc`) откройте `Computer Configuration > Administrative Templates > Windows Components > Windows PowerShell` и включите `Turn on Module Logging`.
В области `Options` нажмите кнопку `Show...`, чтобы настроить, какие модули журналировать.
Введите `*` в текстовом поле `Value`, чтобы записывать все модули.
##### Вариант 2: включение через реестр```
HKLM\SOFTWARE\Wow6432Node\Policies\Microsoft\Windows\PowerShell\ModuleLogging → EnableModuleLogging = 1
HKLM\SOFTWARE\Wow6432Node\Policies\Microsoft\Windows\PowerShell\ModuleLogging\ModuleNames → * = *
Настройки по умолчанию: На Win 10/2016+, если сценарий PowerShell помечен как подозрительный средством AMSI, он будет записан в журнал с уровнем Warning.
Включение журналирования блоков скриптов активирует идентификатор события 4104. Если включить Log script block invocation start / stop events, также будут включены EID 4105 и 4106, однако это не рекомендуется, так как создаст лишь лишний шум.
Журналирование блоков скриптов поддерживается по умолчанию в PowerShell 5.0+ (Win 10+), однако вы можете включить его и на более старых ОС (Win 7+), если установите .NET 4.5 и WMF 4.0+.
К сожалению, максимальный размер одного журнала событий Windows составляет 32 КБ, поэтому любые сценарии PowerShell, превышающие этот размер, будут разбиты на блоки по 32 КБ.
Если у вас есть исходный файл PowerShell Operational.evtx, вы можете использовать инструмент block-parser для дефрагментации этих журналов в единый удобочитаемый текстовый файл.
Одно из преимуществ журналирования блоков скриптов заключается в том, что даже если вредоносный сценарий обфусцирован с помощью XOR, Base 64, ROT13 и т. д., декодированный сценарий всё равно будет записан в журнал, что значительно упрощает анализ.
С журналами работать проще, чем с журналированием модулей: если атакующий запустит Mimikatz, будет создано всего 5 МБ и 100 событий по сравнению с 7 МБ и более 2000 событий.
Однако выходные данные команд не фиксируются при журналировании блоков скриптов.
В редакторе групповой политики откройте Computer Configuration > Administrative Templates > Windows Components > Windows PowerShell и включите параметр Turn on PowerShell Script Block Logging.
HKLM\SOFTWARE\Wow6432Node\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging → EnableScriptBlockLogging = 1
Настройки по умолчанию: No Auditing
Также существует возможность сохранять журналы PowerShell в текстовые файлы на локальном компьютере с помощью журналов транскрипций. Хотя атакующий обычно может легко удалить журналы транскрипций для противодействия криминалистическому анализу, могут существовать сценарии, в которых атакующий очищает все журналы событий, но не ищет журналы транскрипций для удаления. Поэтому рекомендуется по возможности также включать журналы транскрипций. По умолчанию они сохраняются в папку документов пользователя. В идеале журналы транскрипций должны сохраняться в сетевую папку только для записи, однако на практике это может быть трудно реализовать. Преимущество журналов транскрипций в том, что они включают временные метки и метаданные для каждой команды и очень экономичны с точки зрения хранения — менее 6 КБ для выполнения Mimikatz. Недостатком является то, что журналы транскрипций фиксируют только то, что отображается в терминале PowerShell.
В редакторе групповой политики откройте Computer Configuration > Administrative Templates > Windows Components > Windows PowerShell и включите параметр Turn on PowerShell Transcription.
Затем укажите выходной каталог.
HKLM\SOFTWARE\Wow6432Node\Policies\Microsoft\Windows\PowerShell\Transcription → EnableTranscripting = 1 HKLM\SOFTWARE\Wow6432Node\Policies\Microsoft\Windows\PowerShell\Transcription → EnableInvocationHeader = 1 HKLM\SOFTWARE\Wow6432Node\Policies\Microsoft\Windows\PowerShell\Transcription → OutputDirectory = “” (Enter path. Empty = default)
### Ссылки
* [Блог Mandiant: Повышение видимости благодаря логированию PowerShell](https://www.mandiant.com/resources/blog/greater-visibilityt)
## Системный журнал (55 правил Sigma)
Файл: `System.evtx`
Настройки по умолчанию: `Enabled. 20 MB`
Рекомендуемые настройки: `Enabled. 128 MB+`
Вредоносное ПО часто устанавливает службы для обеспечения постоянства, локального повышения привилегий и т.д., что можно обнаружить в этом журнале.
Здесь также можно обнаружить попытки эксплуатации различных уязвимостей.
> **Примечание: Одна особенность, на которую следует обратить внимание в системном журнале, заключается в том, что параметры в полях иногда переводятся на локальный язык, поэтому сигнатуры, использующие только английский, могут не срабатывать на системах с другим языком. Например, на английской системе в параметрах для EID 7045 будет записано `Enabled`, а на японской — `有効`.**
> **Примечание: Как и в журнале `Application`, несколько поставщиков могут записывать события с одним и тем же идентификатором события, поэтому может потребоваться фильтрация не только по каналу, но и по имени поставщика. Например, идентификатор события `1` используется разными поставщиками для различных событий.**
Важные идентификаторы событий:
| ID события | Описание | Правила Sigma | Правила Hayabusa | Уровень | Примечания |
| :---: | :---: | :---: | :---: | :---: | :---: |
| 1 | Сон/гибернация системы | 0 | Пока нет. | Info | Поставщик: `Power-Troubleshooter` |
| 1 | Изменение системного времени | 0 | Пока нет. | Info | Поставщик: `Kernel-General` |
| 12 | Запуск ОС | 0 | Пока нет. | Info | |
| 13 | Завершение работы ОС | 0 | Пока нет. | Info | |
| 16 | Очищена история доступа к кусту реестра | 2 | Пока нет. | High~Crit | Программы для дампа паролей могут очищать историю доступа после извлечения хэшей паролей из куста реестра SAM. Однако это происходит и в обычных условиях, поэтому необходимо отфильтровывать ложные срабатывания. |
| 55 | Повреждение файловой системы NTFS | 1 | Нет | High | Может обнаруживать атаки на уязвимости NTFS. |
| 104 | Очищен системный журнал событий | 1 | Да | Med | |
| 6005 | Служба журнала событий запущена | 0 | Да | Info | |
| 6006 | Служба журнала событий остановлена | 0 | Да | Info | |
| 6008 | Неожиданное завершение работы | 0 | Да | Info | |
| 6038 | Использован NTLMv1 | 1 | Нет | Low | |
| 7031 | Аварийное завершение работы службы | 0 | Да | Low | |
| 7034 | Аварийное завершение работы службы | 0 | Да | Low | |
| 7036 | Запуск/остановка службы | 2 | Да | Info~High | Может использоваться для обнаружения остановки Defender и т.п. |
| 7040 | Изменён тип запуска службы | 0 | Да | Info | Может указывать на то, что злоумышленник отключил службу. |
| 7045 | Установка службы | 37 | Да | Info~Crit | Это самый важный идентификатор события в системном журнале, поскольку вредоносное ПО часто устанавливает себя как службу или злоупотребляет службами. |
| 20001 | Новое PNP-устройство | 0 | Да | Info~? | Уровень зависит от того, разрешены ли USB-устройства. Журналируется только первое подключение устройства. События PNP-устройств, не связанных с USB, очень шумные, поэтому их, вероятно, следует отфильтровывать. |
## Журнал приложений (16 правил Sigma)
Этот журнал по большей части содержит шум, но здесь можно найти некоторые важные улики.
Некоторые сторонние антивирусные программы записывают в этот журнал.
Следует быть осторожным: разные поставщики используют одни и те же идентификаторы событий для разных событий, поэтому нужно фильтровать не только по ID события, но и по имени поставщика.
Файл: `Application.evtx`
Настройки по умолчанию: `Enabled. 20 MB`
Рекомендуемые настройки: `Enabled. 128 MB+`
Важные идентификаторы событий:
| ID события | Поставщик | Описание | Правила Sigma | Правила Hayabusa | Уровень | Примечания |
| :---: | :---: | :---: | :---: | :---: | :---: | :---: |
| 1 | `Audit-CVE`, `Microsoft-Windows-Audit-CVE` | Попытка эксплуатации известной уязвимости (CVE) | 1 | Нет | Critical | Обнаруживает события, создаваемые приложениями в пользовательском режиме при вызове API CveEventWrite, когда предпринимается попытка эксплуатации известной уязвимости. Microsoft начала использовать этот журнал в январе 2020 года с CVE-2020-0601 (уязвимость в Windows CryptoAPI). К сожалению, это почти единственный случай записи CVE в этот журнал. |
| 325 | `ESENT` | Создана база данных ESE | 2 | Нет | Info~Crit | Обнаруживает, когда процесс создаёт базу данных ESE. ESE используется для множества целей: Exchange, AD, службы сертификации, SRUM и т.д. Наиболее важная с точки зрения безопасности база ESE — NTDS.dit, файл с хэшами паролей всех пользователей домена, расположенный на контроллерах домена. Существует два правила Sigma для обнаружения дампа NTDS.dit, однако это может быть ложным срабатыванием, если администратор использует ntdsutil для резервного копирования или создаются теневые копии. |
| 326 | `ESENT` | Подключена база данных ESE | 1 | Нет | Info~Crit | Может помочь обнаружить доступ к NTDS.dit. |
| 1000, 1001 | `Application Error`, `Windows Error Reporting` | Ошибка приложения | 1 | Нет | Info~High | |
| 1034, 11724 | `MsiInstaller` | Приложение удалено | 1 | Нет | Info~Low | |
| 1040 | `MsiInstaller` | Установка приложения | 1 | Нет | Info~Med | |
| 33205 | `MSSQLSERVER` | Событие аудита SQL | 6 | Нет | Info~High | Может обнаруживать бэкдоры MSSQL, SQL-инъекции, внедрение команд и т.д. |
## Операционный журнал Windows Defender (10 правил Sigma)
Файл: `Microsoft-Windows-Windows Defender%4Operational.evtx`
Настройки по умолчанию: `Enabled. 1 MB`
Рекомендуемые настройки: `Enabled. 128 MB+`
Здесь можно обнаружить не только оповещения Windows Defender (за которыми важно следить), но и добавление исключений, отключение защиты от несанкционированного вмешательства, удаление истории и т.д.
## Операционный журнал Bits-Client (6 правил Sigma)
Файл: `Microsoft-Windows-Bits-Client%4Operational.evtx`
Настройки по умолчанию: `Enabled. 1 MB`
Рекомендуемые настройки: `Enabled. 128 MB+`
Bitsadmin.exe — популярный [lolbin](https://lolbas-project.github.io/lolbas/Binaries/Bitsadmin/), которым злоумышленники злоупотребляют для загрузки и выполнения вредоносного ПО.
В этом журнале можно найти соответствующие улики, хотя следует учитывать, что будет много ложных срабатываний.
## Журнал брандмауэра (6 правил Sigma)
Файл: `Microsoft-Windows-Windows Firewall With Advanced Security%4Firewall.evtx`
Настройки по умолчанию: `Enabled? 1 MB`
Рекомендуемые настройки: `Enabled. 256 MB+`
Здесь можно найти следы добавления, изменения или удаления правил брандмауэра.
Вредоносное ПО часто добавляет правила брандмауэра, чтобы обеспечить связь со своим C2-сервером, добавляет правила прокси для горизонтального перемещения и т.д.
## Операционный журнал NTLM (3 правила Sigma)
Файл: `Microsoft-Windows-NTLM%4Operational.evtx`
Настройки по умолчанию: `Enabled but Auditing is disabled. 1 MB`
Этот журнал рекомендуется включить, если вы планируете отключить аутентификацию NTLM.
Отключение NTLM, скорее всего, нарушит некоторые соединения, поэтому вы можете отслеживать этот журнал на контроллерах домена и других серверах, чтобы увидеть, кто всё ещё использует NTLM, и отключать NTLM постепенно, начиная с этих пользователей, прежде чем отключать его глобально.
Использование NTLM для входящих подключений можно обнаружить в событиях входа, например 4624, но вам нужно включить этот журнал, если вы хотите отслеживать, кто устанавливает исходящие NTLM-подключения.
Чтобы включить аудит, в групповой политике откройте `Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > Security Options` и настройте соответствующие параметры в разделе `Network security: Restrict NTLM:`.
Ссылка: [Прощай, NTLM](https://www.scip.ch/en/?labs.20210909)
## Журналы Security-Mitigations KernelMode и UserMode (2 правила Sigma)
Файлы: `Microsoft-Windows-Security-Mitigations%4KernelMode.evtx`, `Microsoft-Windows-Security-Mitigations%4UserMode.evtx`
Настройки по умолчанию: `Enabled. 1 MB`
Рекомендуемые настройки: `Enabled. 128 MB+`
На данный момент для этих журналов существует только 2 правила Sigma, но вам, вероятно, следует собирать и отслеживать все журналы Exploit Protection, Network Protection, Controlled Folder Access и Attack Surface Reduction (около 40+ идентификаторов событий).
К сожалению, журналы Attack Surface Reduction (ранее WDEG(Windows Defender Exploit Guard) и EMET) распределены по нескольким журналам и требуют сложных XML-запросов для поиска.
Подробнее: [Общие сведения о возможностях сокращения поверхности атаки и их использовании](https://learn.microsoft.com/en-us/microsoft-365/security/defender-endpoint/overview-attack-surface-reduction?view=o365-worldwide)
## Журналы PrintService (2 правила Sigma)
Рекомендуется также включить операционный журнал для обнаружения атак на Print Spooler. (Например, PrintNightmare и т.д.)
### Admin (1 правило Sigma)
Файл: `Microsoft-Windows-PrintService%4Admin.evtx`
Настройки по умолчанию: `Enabled. 1 MB`
Рекомендуемые настройки: `Enabled. 128 MB+`
### Operational (1 правило Sigma)
Файл: `Microsoft-Windows-PrintService%4Operational.evtx`
Настройки по умолчанию: `Disabled. 1 MB`
Рекомендуемые настройки: `Enabled. 128 MB+`
## Журнал безопасности SMBClient (2 правила Sigma)
Файл: `Microsoft-Windows-SmbClient%4Security.evtx`
Настройки по умолчанию: `Enabled. 8 MB`
Рекомендуемые настройки: `Enabled. 128 MB+`
Используется для попыток обнаружения PrintNightmare (подозрительный отклонённый гостевой вход SMB с IP-адреса) и пользователей, подключающих скрытые общие ресурсы.
## Журналы AppLocker (1 правило Sigma)
Файлы: `Microsoft-Windows-AppLocker%4MSI and Script.evtx`, `Microsoft-Windows-AppLocker%4EXE and DLL.evtx`, `Microsoft-Windows-AppLocker%4Packaged app-Deployment.evtx`, `Microsoft-Windows-AppLocker%4Packaged app-Execution.evtx`
Настройки по умолчанию: `Enabled if AppLocker is enabled? 1 MB`
Рекомендуемые настройки: `Enabled. 256 MB+`
Это важно, чтобы убедиться, что журнал включён и отслеживается, если вы используете AppLocker.
## Операционный журнал CodeIntegrity (1 правило Sigma)
Файл: `Microsoft-Windows-CodeIntegrity%4Operational.evtx`
Настройки по умолчанию: `Enabled. 1 MB`
Рекомендуемые настройки: `Enabled. 128 MB+`
Проверяйте этот журнал для обнаружения событий загрузки драйверов, заблокированных проверками целостности кода Windows; это может указывать на вредоносный драйвер, который не смог загрузиться.
## Операционный журнал Diagnosis-Scripted (1 правило Sigma)
Файл: `Microsoft-Windows-Diagnosis-Scripted%4Operational.evtx`
Настройки по умолчанию: `Enabled. 1 MB`
Рекомендуемые настройки: `Enabled. 128 MB+`
Здесь можно найти следы использования пакетов diagcab для эксплуатации.
## Операционный журнал DriverFrameworks-UserMode (1 правило Sigma)
Файлы: `Microsoft-Windows-DriverFrameworks-UserMode%4Operational.evtx`
Настройки по умолчанию: `No Auditing. 1 MB`
Рекомендуемые настройки: `Enabled. 128 MB+`
Обнаруживает подключённые USB-устройства.
## Операционный журнал WMI-Activity (1 правило Sigma)
Файл: `Microsoft-Windows-WMI-Activity%4Operational.evtx`
Настройки по умолчанию: `Enabled on Win10/2016+. 1 MB`
Рекомендуемые настройки: `Enabled. 128 MB+`
Этот журнал важно отслеживать, поскольку злоумышленники часто используют WMI для закрепления и горизонтального перемещения.
## Операционный журнал TerminalServices-LocalSessionManager (1 правило Sigma)
Файл: `Microsoft-Windows-TerminalServices-LocalSessionManager%4Operational.evtx`
Настройки по умолчанию: `Enabled. 1 MB`
Рекомендуемые настройки: `Enabled. 128 MB+`
Обнаруживает случаи, когда ngrok, инструмент обратного прокси, перенаправляет трафик на локальный порт RDP для обхода брандмауэров.
Ссылка: [Обход сетевых ограничений с помощью RDP-туннелирования](https://www.mandiant.com/resources/blog/bypassing-network-restrictions-through-rdp-tunneling)
## Операционный журнал TaskScheduler (1 правило Sigma)
Файл: `Microsoft-Windows-TaskScheduler%4Operational.evtx`
Настройки по умолчанию: `Disabled. 1 MB`
Рекомендуемые настройки: `Enabled. 128 MB+`
Злоумышленники часто злоупотребляют задачами для закрепления и горизонтального перемещения, поэтому этот журнал следует включить.