На этой страницы приведены настройки для активации логирования в сетевом экране, рассмотрено содержание различных типов логов и способ их отправки на внешний syslog-сервер.

Настройка даты и время.

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

Актуальный IP-адрес NTP-сервера можно найти через pool.ntp.org.

После ввода настроек нужно нажать кнопку «Refresh» и убедится что статус Synchronized.

Настройка через CLI

 

Просмотр статуса.

 

Если нужно чтоб USG сам стал NTP-серверов для устройств в локальной сети, то это можно активировать командой.

ntp-service server disable – отключает NTP-сервер на устройстве, т.е. USG не отвечает на запросы времени от других устройств (настроено по умолчанию).

undo – отменяет действие, т.е. включает NTP-сервер, позволяя USG выступать как NTP-сервер для клиентов в сети.

 

Карта памяти microSD.

Для работы логирования требуется накопитель хранения логов. Без него меню логов сокращенное. В USG6510Е в качестве накопителя можно подключить microSD карту памяти. Подключение SSD не предусмотрено. Карта должна быть с хорошей скоростью чтения и записи, иначе не заработает. В данном примере использована карта SanDisk Extreme Pro Class 10 V30 32Gb.

Карта памяти должна быть предварительно отформатирована в ext4. Это можно сделать с помощью программы Linux File Systems for Windows от Paragon Software. Достаточно бесплатной версии.

Вставляем карту в слот на передней части корпуса USG.

Примонтировать карту можно только через CLI. Подключаемся через терминал Putty. Переводим карту в on-line.

 

Просмотр состояния SD-карты.

 

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

Назначение меню логов.

Traffic Logs – логи всего проходящего через USG трафика: источники/назначения, порты, интерфейсы, протоколы.

Threat Logs – логи угроз и атак, обнаруженных IPS/IDS: сканеры, вирусы, DoS/DDoS, уязвимости.

URL Logs – логи URL-запросов (HTTP/HTTPS) и действия URL-фильтра.

Content Logs – логи по анализу контента файлов: AV, вредоносные файлы, запрещённые типы контента.

Operation Logs – логи действий администраторов: конфигурации, изменения политики, команды CLI/GUI.

System Logs – системные события USG: перезагрузки, интерфейсы UP/DOWN, ошибки, состояние модулей.

User Activity Logs – логи аутентификации пользователей: VPN, WebAuth, учетные записи, вход/выход.

Policy Matching Logs – логи совпадений с политиками безопасности: разрешено/заблокировано, правило, действие.

Mail Filtering Logs – логи фильтрации почтового трафика: спам, вирусы, вредоносные вложения, объем, блокировка по политике.

 

По разным причинам логи могут не идти. Проверяем активацию центра информирования (обычно включен по умолчанию).

info-center – это ядро системы логирования в Huawei USG. Без него логи не будут маршрутизироваться, то есть не попадут ни в буфер, ни в файл, ни на syslog-сервер если нужна пересылка.

Активируем для надежности.

 

Проверяем статус модулей логирования и включаем по необходимости.

Проверка по настройке конфигурации.

 

Проверка по статистике.

Смотрим статистику. Если нули – не работает.

 

Назначение команд включения логов.

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

Включает логирование всего трафика, который проходит через FW. Включение даёт статистику по сессиям, src/dst IP, портам, интерфейсам и т.д.

 

Включает генерацию системных логов (например, события FW, интерфейсов, перезагрузки).

 

Включает логирование по правилам политики безопасности. Каждое совпадение политики (разрешено/заблокировано) будет записано.

 

Включает логирование угроз (IPS/атак и т.п.).

 

Включает логирование URL-запросов (HTTP/HTTPS).

 

Включает логирование аутентификации пользователей.

 

Включает логирование почтового трафика.

 

Включает логирование контента файлов.

 

Включает логирование по умолчанию для всех правил политики, если явно не задано другое.

 

Включает логирование всех сессий, по умолчанию.

 

Включает логирование всего трафика по умолчанию.

 

Дополнительно включает логирование всех действий политики.

 

Логи по каждой сессии.

 

Дублирует log type traffic enable для отдельных политик.

 

Включаем все типы логов.

 

Вывод логов в терминал. (вводится в режиме user-view)

 

Отключение вывода логов в терминал.

 

Далее рассмотрено содержание каждого типа логов.

 

Traffic Logs.

Открываем любой лог.

Описание полей лога.

Common Log Field – общие сведения.
Time – время события.
Duration – продолжительность сессии: 256 секунд (~4 минуты 16 секунд).
Session End Reason – причина завершения: tcp-fin – клиент или сервер корректно завершил TCP-сессию.
Virtual System – сессия принадлежит виртуальной системе public.
Security Policy – применена политика безопасности ALLOW-ALL-TEST-POLICY.
Protocol – протокол TCP.
Application Category – категория приложения: General_Internet – общий Интернет-трафик.
Application Subcategory – подкатегория Search_Engines – поисковые системы
Application – конкретное приложение Google_Service.

Traffic – параметры трафика.
Traffic Policy – применённая политика трафика: default.
Total Traffic – общий объём: 90.14 KB
Upstream Traffic – входящий трафик: 4.75 KB
Downstream Traffic – исходящий: 85.4 KB.
Inbound Interface – входящий интерфейс GE0/0/3.9.
Outbound Interface – исходящий интерфейс GE0/0/9.

Source – источник.
Source Zone – зона источника: trust (внутренняя сеть).
Source Region – регион источника не указан unknown-zone.
Source Address – IP-адрес источника 192.168.9.179.
Source Port – порт источника 49411.
NAT Source Address – адрес NAT 192.168.5.2
NAT Source Port – порт NAT 2050.

Destination – назначение.
Destination Zone – зона назначения: untrust (Интернет)
Destination Region – регион назначеня Germany Германия.
Destination Address – IP-адрес назначения 142.250.186.200
Destination Port – порт назначения 443 (HTTPS).
NAT Destination Address: —
NAT Destination Port: —

Анализируя лог, можно предположить, что клиент из локальной сети запрашивал данные у сервера в Интернете. Этот лог показывает конкретную TCP-сессию. URL не виден, но видно какое приложение/категория использовались и сколько трафика прошло. Можно понять, был ли трафик разрешён или заблокирован, и через какие интерфейсы он шёл.

USG определяет приложение в логе с помощью App-ID механизма, который анализирует сетевой поток и классифицирует его на уровне L7 (Application Layer). Отображение поля Application в логе происходит если приложение известно системе (в базе сигнатур App-ID). Если сигнатура трафика по портам, URL-паттернам, handshake, заголовкам совпадает с известным шаблоном в локальной или облачной базе приложений.

Расшифровка HTTPS не обязательна.  Для большинства популярных сервисов Huawei уже включает сигнатуры, основанные на TLS SNI, сертификате сервера, IP-диапазонах, DNS-запросах и характере сессии. Поэтому даже без включенной расшифровки USG способен определить приложение.

 

URL Logs.

Главное отличие от Traffic Log – здесь фиксируется конкретный URL и его категория, а не просто сессия.

Для полноценной работы URL-логов нужна расшифровка трафика. Когда расшифровка HTTPS не включена, USG не может заглянуть внутрь зашифрованного HTTP-запроса (внутри TLS-туннеля). То есть не виден фактический URL-путь. Видна только информация, доступная в открытой части TLS-сеанса, например доменное имя из SNI (Server Name Indication), поля CN/SAN из сертификата сервера, IP-адрес назначения, порт, и т.п. Но с таким набором тоже можно что-то отслеживать. Как настроить расшифровку трафика написано тут.

Чтоб URL-логи начали появляться нужно, создать профиль URL-фильтрации и применить его к политике безопасности.

Создаем профиль.

Filter Encrypted Traffic – это механизм анализа зашифрованного HTTPS без расшифровки. Он позволяет определять домен через SNI, относить его к URL-категории, применять действие профиля, создавать URL-логи. Но эта настройка не позволяет видеть полный URL-путь и параметры запроса. Логи содержат только домен, без конкретного ресурса, например, yandex.ru/…//. Как уже отмечалось выше, чтоб видеть полный URL нужно настраивать расшифровку трафика. info.support.huawei.com

Default Action: Alert.

Alert – это действие, при котором трафик разрешается, но создаётся запись (лог) о срабатывании правила. Используется для мониторинга: позволяет видеть, какие URL, приложения или категории трафика проходят через фильтр, не блокируя их.

Если URL-запрос не попадает в категорию или в списки (черный и белый), будет применено действие default. С дефолтным действием Allow URL-запросы, которые не попадают ни в одну категорию, могут не логироваться – трафик разрешён, но лог не создаётся. Поэтому, чтобы видеть URL-запросы, к которым не задана категория, устанавливается Alert как default, чтобы даже не попавшие в категорию запросы логировались.

User-defined – отмечаем все категории Alert. Если оставить эти действия по первоначальной настройке, то может срабатывать Allow или Block без логирования.

Создание профиля через CLI.

Применяем к политике безопасности.

Профиль URL_LOG_PROFILE работает только внутри политики, к которой он привязан. Он анализирует только трафик, который разрешён этой политикой. То есть, если трафик не попадает под политику – профиль его даже не увидит. Чтобы логировались все URL-запросы, профиль нужно применить во все политики, выпускающие трафик в Интернет.

Для начала логирования политики нужно активировать соответствующую настройку в Other Options.

Record Traffic Logs – включает журналирование сетевого трафика, проходящего по этой политике. Включать обязательно на всех политиках, где нужен аудит сетевого взаимодействия. Иначе Traffic Logs могут не появлятся в мониторинге.

Record Policy Matching Logs – логирует сам факт совпадения трафика с данной политикой. Используется для отладки и анализа правил чтобы понимать, какая политика сработала для конкретного потока. Напрямую отвечает за появление записей в разделе Policy Matching Logs в разделе Monitoring >> Logs. Можно включать временно при настройке или проверке политик. Постоянно включать не обязательно, так как хранилище логов быстро переполнится.

Record Session Logs – ведёт журнал сессий, то есть записывает информацию при создании и завершении каждой TCP/UDP-сессии. Включать на политике доступа в Интернет.

Через CLI.

 

Посмотрим содержание одного любого лога.

Common Log Field – общие сведения.
Time – время фиксации события (момент, когда сработало правило URL-фильтра).
Security Policy – название политики безопасности, по которой проходил трафик.
Protocol: – транспортный протокол соединения.
Application Category – категория приложения Network –сеть.
Application Subcategory – подкатегория Infrastructure.
Application HTTPS – классификация приложения системой Application Identification.
Huawei определил, что это HTTPS-трафик, относящийся к сетевой инфраструктуре.

URL-информация.
URL: an.yandex.ru/…// – реальный запрошенный домен. Полный путь скрыт, т.к. HTTPS не расшифровывается.
Huawei показывает только домен и часть пути, которую может извлечь без SSL-расшифровки.
URL Category – категория URL.
URL Subcategory – подкатегория URL.
Категория и подкатегория из встроенной базы URL-фильтрации. Помогает отнести ресурс к типу контента.
Filtering Type: Pre-defined – используется встроенная база категорий Huawei, а не пользовательские правила.
Profile: – название профиля URL-фильтра, применённого в политике.
Domain Name: an.yandex.ru – домен, который был извлечён из запроса.
Referer: none – нет ссылки-источника (страница не была загружена по переходу).
Action: – действие профиля. Трафик разрешён, но событие записано в лог.

Source — источник.
Source Zone – зона, откуда пришёл трафик (внутренняя сеть).
Source Address – IP-адрес источника, (клиента).
Source Port – исходный порт клиента.
NAT Source Address – адрес после преобразования NAT (внешний IP).
NAT Source Port – порт после преобразования NAT.

Destination – назначение.
Destination Zone – внешняя зона (Интернет).
Destination Address – IP-адрес сервера (владельца ресурса).
Destination Port: 443– порт HTTPS (шифрованный веб-трафик).

Этот лог фиксирует HTTPS-запрос клиента 192.168.8.185 к домену an.yandex.ru (сервер в РФ). Трафик разрешён политикой FULL-INTERNET-ACCESS, URL-фильтр только сработал с действием Alert, ничего не блокировал, а просто зафиксировал обращение. Полный путь (/path/…) не виден, потому что SSL-декрипт отключён.

 

Threat Logs.

Это журналы безопасности, фиксирующие сработки систем защиты от сетевых угроз: вторжений (IPS), вирусов (AV), вредоносных сайтов и атак.

 

Common Log Field – общие сведения.
Time — время фиксации события.
Protocol:UDP – используемый протокол.
Security Policy: DNS-1  – политика безопасности, под действие которой попал трафик.
Application: DNS – приложение.

Threat – информация об угрозе.
Threat Type: Intrusion – тип угрозы – вторжение/аномалия.
Intrusion Subtype: Attack intrusion – подтип – атака или нарушение протокола.
Threat Name: The value of DNS Request-Type is the value that is configured to warn. Описание события – аномалия в DNS-запросе. Тип запроса не стандартный, но настроен как «предупреждать».
Threat ID: 4000007 – внутренний ID сигнатуры IPS.
Occurrences: 1 – количество срабатываний за одну сессию.
Profile: IPS_TEST_PROFILE – профиль IPS, в котором задано это правило.
Action: Alert. Действие – только оповестить, не блокировать.
Severity: information – уровень критичности события.
Risk Level: Low – уровень риска низкий.
Attack Category:   Protocol-Abnormal. Категория атаки – аномалия протокола.

Source — источник.
Source Zone: trust – зона источника.
Source Address: 192.168.8.185 – IP-адрес источника инициировавшего DNS-запрос.
Source Port: 52215 – порт источника.
NAT не использовался.

Destination – назначение.
Destination Zone: local  – показывает, что запрос направлен внутрь USG, а не наружу.
Destination Address: 192.168.8.1 – DNS-сервер (локальный интерфейс FW).
Destination Port: 53 – порт DNS.
NAT не использовался.

Проведя анализ можно сделать вывод, что источник лога – модуль IPS (Intrusion Prevention System), который обнаружил отклонение в сетевом трафике от локального клиента. USG зафиксировал нестандартный DNS-запрос, система IPS сработала в режиме Alert (уведомление).

 

Content Logs.

Content Logs на Huawei USG появляются только тогда, когда устройство производит анализ содержимого трафика, то есть когда задействованы функции файлового контроля или фильтрации контента. Для того чтоб этот функционал начал работать, нужно добавить профиль File Blocking в политику доступа в Интернет (предварительно создав этот профиль). Для проверки контента HTTPS-трафика должна быть настроена расшифровка трафика соответственно.

Пример лога.

Common Log Field – общие сведения.
Time — время фиксации события.
Security Policy: FULL-INTERNET-ACCESS – политика, под действие которой попал трафик (в ней включён контент-профиль).
Protocol: TCP – протокол.
Application Category – категория приложения Network –сеть.
Application Subcategory – подкатегория Infrastructure.
Application: HTTP_Download – это HTTP-загрузка файла (порт 80, без шифрования).

Content – информация о контенте.
Type: File Blocking – сработал модуль блокировки файлов.
File Name: am_delta_patch_1.439.137.0_8e625be483c38ae43e3476f2f99e6824a5bcfc5e.exe – имя загружаемого файла.
File Type: exe – тип файла определён по расширению.
Transmission Direction: download – направление трафика, файл загружался снаружи во внутреннюю сеть.
Action: Alert – действие профиля: зафиксировать событие (не блокировать).
Profile: EXE_BLOCK_PROFILE – активный контент-профиль, в котором заданы правила по типам файлов.

Source — источник.
Source Zone: trust – зона источника.
192.168.7.10 – IP-адрес клиента в локальной сети, инициировавший загрузку.
Source Port: 55576 – порт источника.
NAT Source Address: 192.168.5.2 – преобразованный внешний IP после NAT.
NAT Source Port – порт после преобразования NAT.

Destination – назначение.
Destination Zone: untrust – внешняя не доверенная зона (Интернет).
Destination Region – регион назначеня Испания.
Destination Address – 194.36.32.203:80 – внешний HTTP-сервер, с которого загружался файл.
Destination Port: 80 – порт HTTP (веб-трафик без шифрования).

Итого. Пользователь 192.168.7.10 загрузил .exe файл по HTTP. Сработало правило профиля EXE_BLOCK_PROFILE, настроенное на Alert (только логирование, без блокировки).

 

Operation Logs.

Operation Logs – это журнал действий администраторов и системных процессов.

Он фиксирует:
-команды и операции, выполненные вручную (через GUI или CLI);
-автоматические команды системы (например обновление данных интерфейса);
-действия администраторов при работе с веб-интерфейсом (просмотр логов, изменение настроек и т.д.).

Пример действий администратора через GUI:

Это не реальные команды CLI, а внутренние HTTP-запросы от веб-интерфейса к системе для получения данных, например, когда при открытии вкладки Traffic Logs.

 

Пример действий через CLI или системные задачи.

Администратор admin выполнял команды вручную.

Если система выполняет команды автоматически по расписанию для мониторинга состояния в логах видно _system_.

Пример расшифровки строки.

2025/10/13 22:18:50 admin  192.168.0.10 getNlogDBUpdateState public

Пользователь admin с IP 192.168.0.10 в веб-интерфейсе открыл вкладку логов; система запросила состояние базы логов. Это не действие конфигурации, а просто чтение данных через GUI.

Operation Logs нужны для аудита действий администраторов, отслеживания изменений конфигурации, мониторинга отладки через GUI (можно понять, обращается ли веб-интерфейс к устройству корректно, выполняются ли внутренние диагностические команды). В первую очередь этими логами пользуются аудиторы, контролеры, администраторы безопасности. Главная цель – прозрачность и подотчётность административных действий.  Любое изменение, просмотр или диагностика фиксируются, чтобы можно было доказать кто именно сделал операцию, когда это было, на каком уровне (ручное действие или автоматическое системное).

 

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

System Logs нужны для:

Мониторинга состояния устройства – отслеживание работы служб, загрузки, интерфейсов, памяти, ЦП, хранилища.
Диагностики сбоев и ошибок – помогают понять, почему возникли проблемы (например, модуль IPS не стартовал, диск заполнен и т.п.).
Безопасности и аудита управления – фиксируют входы администраторов, неудачные попытки авторизации, изменения конфигурации.

 

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

User Activity Logs фиксируют аутентификацию конечных пользователей, проходящую через функции AAA-аутентификации: Portal (web-аутентификация пользователей сети), VPN, доступ в Интернет под управлением USG. Используются для аудита доступа, фиксации неудачных попыток входа, учёта времени онлайн активности пользователей для отчетности и расследований. В этом логе не фиксируются входы системных администраторов.

Открыть лог для подробного просмотра невозможно. Поэтому проведем разбор колонок таблицы этого лога  чтобы получить понимание того что именно контролируется и логируется системой в данном случае.

Содержание таблицы лога.
Time – время события показывает момент, когда произошло действие пользователя.
Source User – имя пользователя, прошедшего аутентификацию.
User Group – группа, к которой принадлежит пользователь. Указывается путь к группе в AAA (например, /default). Используется для применения политик доступа по группам.
Login IP Address – IP-адрес, с которого пользователь прошёл аутентификацию.
Authentication Mode – метод проверки подлинности.
Local Authentication – проверка по локальной базе USG.
Radius Authentication – проверка через внешний сервер RADIUS.
LDAP Authentication – через каталог AD/LDAP.
Access Mode – тип подключения пользователя.
PPP – если вход выполнен через L2TP/SSL VPN
Portal – если это веб-аутентификация
802.1x, IPsec, SSH, и т. д.
Device – устройство пользователя (может быть определено по клиенту VPN или через Portal User-Agent). Часто остаётся unknown, если клиент не сообщает данные.
Online/Lockout Duration – время, сколько пользователь был в сети, или продолжительность блокировки, если вход неуспешен (например, при превышении лимита попыток).
Type  Тип события:
User Login Succeeded – успешный вход.
User Login Failed – ошибка аутентификации.
User Logout – выход.
User Lockout – блокировка.
User Online Timeout – истечение сессии.
Details – дополнительные сведения, например, причина ошибки, код отклонения, таймаут, или результат входа.
Virtual System – указывает, в каком виртуальном системном контексте (VSYS) произошло событие. Обычно public, если виртуализация не используется.

Пример пояснения лога.

Пользователь vpnuser прошёл локальную аутентификацию на устройстве, через PPP (L2TP VPN) с IP 192.168.50.19, вход выполнен успешно.

 

Policy Matching Logs.

Policy Matching Logs внешне похожи на Traffic Logs, но выполняют другую задачу. В отличие от Traffic Logs которые в первую очередь фиксируют факт прохождения или завершения сеанса, Policy Matching Logs показать факт срабатывания политики безопасности (Security policy) – то есть, какое правило сработало при обработке сессии. Policy Matching Logs фиксируют какая политика была применена, откуда и куда шёл трафик (зона, IP, порт, протокол), результат, действие политики (permit/deny), время и базовую информацию о пакете, по которому произошло совпадение.

Эти логи используются при проверке применения нужного правила, а не, например, ALLOW-ALL выше по списку и для подтверждение, что трафик действительно попадает под ожидаемое правило.

 

Mail Filtering Logs.

Эти логи фиксируют события, связанные с проверкой электронной почты, например:
-отправка или получение писем по SMTP/POP3/IMAP;
-блокировка писем, содержащих запрещённые вложения, количестве вложений или размере;
-фильтрация по ключевым словам, адресам отправителей или доменам;
-предупреждения (Alert) о подозрительном контенте в письмах.

Для их появления нужно настроить соответствующий профиль (Mail Filtering) и применить его в политике безопасности.

 

Управление в логах.

Почти во всех категориях логов можно выполнить поиск по фильтру или выгрузить лог в CSV.

 

Можно убрать лишнее колонки на кнопку Customize или уменьшить отображаемое количество логов за выбранный период времени в поле Time.

 

Отправка логов на внешний сервер.

Настраивается в меню System >> Log Configuration.

Configure System Log – раздел системные события.

Log Host IP Address – IP сервера, куда USG отправляет системные логи.

Port – порт назначения по умолчанию 514 для UDP/TCP Syslog.

Language – язык логов English обязательно.

Outgoing Interface – интерфейс, через который шлются логи.

Можно добавить несколько внешних серверов на кнопку «плюс в кружке». Остальные настройки без изменений.

Настройка через CLI.

Этого достаточно, чтоб логи начали отправляться на внешний сервер. Другие настройки можно оставить без изменений если нет каких-то особенных условий.

Назначение других настроек.

Configure Session Logs – раздел логи сессий.

Log Format – формат логов сессий (Binary/Syslog/Netflow).

Binary
Формат: проприетарный (закрытый) двоичный Huawei-формат.
Назначение: используется для локального хранения и передачи логов на eSight/HiSec Insight.
Содержимое: детализированные структурированные данные (включая поля, которых нет в syslog).
Особенности: не читается вручную и не парсится сторонними SIEM; нужен Huawei-софт.
Использовать, если: в наличии установлены eSight/HiSec Insight и необходима глубокая аналитика.

Syslog
Формат: текстовый (RFC 3164 или RFC 5424), стандарт для логирования сетевых устройств.
Назначение: отправка логов на внешний syslog-сервер.
Содержимое: человекочитаемые события: время, IP-адреса, порты, политика, действие, и т. д.
Настройка: можно изменить шаблон (Syslog Template), чтобы подогнать формат под конкретный сервер или SIEM.
Использовать, если: логи идут на внешний сервер или SIEM-систему.

NetFlow
Формат: потоковый протокол учёта сетевых соединений, разработанный Cisco (версии 5/9/IPFIX).
Назначение: передача сетевой статистики (flows) на коллектор.
Содержимое: агрегированные данные: src/dst IP, порты, протокол, байты, пакеты, длительность сессии.
Не содержит подробных сведений о политике безопасности или действиях IPS/AV.
Использовать, если: нужен сетевой анализ трафика, а не событий безопасности.

Send Binary Logs to All Log Servers – дублировать бинарные логи на все сервера.

Log Source IP Address – IP-адрес, с которого USG отправляет логи. Можно выбрать системный или интерфейсный.

Source Port – порт исходящего соединения. Любой доступный >1024, например 1617 (по умолчанию нормально).

Log Host IP Address – IP Syslog-сервера для сессионных логов.

Port – порт назначения 514, чтобы совпадал с syslog-настройкой.

Encrypted Transmission – шифрование передачи (Huawei-собственный формат). Только для eSight/HiSec Insight.

Heartbeat Detection – проверка связи с лог-сервером. Можно включить, не мешает работе.

 

Configure Service Logs – логи сервисов (например, IPS, AV, URL-фильтр и т.п.).

Log Format – формат сервисных логов (Syslog/Dataflow). Оставляем по умолчанию Syslog.

Dataflow – Huawei-специфичный формат. Не активируем.

Примечание (When Syslog format is used…) говорит, что системные настройки из «Configure System Log» будут применены для сервисных логов. Это значит, что все сервисные логи (IPS, AV и т.д.) пойдут на тот же IP и порт, что указаны выше.

 

Cached Log Sending – это режим отправки логов из кеша (локальной памяти устройства), а не в реальном времени. Когда он включён, устройство сначала сохраняет логи во внутренний буфер, а потом отправляет их пакетами на loghost по расписанию или при накоплении определённого объёма данных. Эта настройка нужна например тогда, когда loghost недоступен временно, в результате логи не теряются – они хранятся в кеше и уйдут позже.

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

 

Для справки:

Основные проприетарные сборщики логов Huawei.

Huawei eSight – платформа для централизованного управления, мониторинга и эксплуатации (O&M) для обслуживания сетевых устройств (роутеры, коммутаторы, серверы, устройства безопасности). O&M – это сокращение от Operation and Maintenance (в переводе – эксплуатация и обслуживание). Intelligent Network O&M (интеллектуальная эксплуатация и обслуживание) это современный подход, при котором используются AI/ML (искусственный интеллект и машинное обучение) для анализа логов и поведения сети, Big Data для прогнозирования отказов, автоматизация (скрипты, playbooks, API), визуализация и корреляция событий. Основная цель: минимизировать ручные операции и реактивное устранение проблем, повысить предсказуемость и стабильность сети.

Huawei HiSec Insight – система ситуационной безопасности SIEM/Threat Intelligence/APT-детекция: аналитика логов, корелляция угроз, визуализация, выявление продвинутых атак. Аналог сием-системы от Huawei. HiSec Insight O&M включает интеллектуальный анализ логов, автоматическое определение аномалий и рекомендации по устранению неисправностей.

Оба продукта (eSight и HiSec Insight) требуют лицензии для полноценного использования и не являются бесплатным ПО.

 

Syslog Template

Syslog Template – в этой вкладке меню можно задать собственный формат строк логов, при отправке события на внешний сервер. По сути  это конструктор логов, где указывается, какие поля включать и в каком порядке.

Создание шаблона для примера.

 

Задаем поля, которые нужно выводит.

Варианты режимов:

Expression – позволяет вручную задать текстовую строку (гибко, удобно для интеграции с приемщиками логов).

List – позволяет выбрать фиксированный список полей, USG сам создаёт формат.

Далее добавляем профиль в конфигурацию логов.

На приемной стороне смотрим результат.

Аналогичный смысл у настройки Netflow Log Template.

Отправка логов на e-mail в данной модели USG не предусмотрена. E-mail добавить можно, но нет возможности выбрать канал email. На почту можно отправлять ежедневные отчеты.

 

Проверка приема логов.

В роли сервера логов может быть что угодно (eSight, Siem, Syslog и др), для быстрого теста использован Visual Syslog Server for Windows.

После активации отправки на приемной стороне сразу начинают появляться логи из USG.

Пример лога.

Одинаково успешно прилетают все типы логов.

 

Итог.

Работа с логами USG – это не разовое действие, а постоянный процесс. Регулярный анализ журналов позволяет своевременно выявлять инциденты, контролировать работу систем безопасности и поддерживать стабильность инфраструктуры. Эффективное использование логов повышает прозрачность сети и является неотъемлемой частью информационной безопасности организации.