На этой страницы приведены настройки для активации логирования в сетевом экране, рассмотрено содержание различных типов логов и способ их отправки на внешний syslog-сервер.
Настройка даты и время.
Для корректного отображения логов и точности воспроизведения событий необходимо настроить синхронизацию даты и время с внешним источником. Без корректного времени невозможно правильно воспроизвести цепочку событий.
Актуальный IP-адрес NTP-сервера можно найти через pool.ntp.org.
После ввода настроек нужно нажать кнопку «Refresh» и убедится что статус Synchronized.
Настройка через CLI
1 2 3 4 5 |
system-view clock timezone MSK add 03:00:00 ntp-service unicast-server 10.10.10.10 source-interface GigabitEthernet0/0/9 quit save |
Просмотр статуса.
1 |
display ntp-service status |
Если нужно чтоб USG сам стал NTP-серверов для устройств в локальной сети, то это можно активировать командой.
1 |
undo ntp-service server disable |
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.
1 2 |
system-view sd-card online |
Просмотр состояния SD-карты.
1 |
display sd-card information |
Если всё прошло успешно и без ошибок, переходим в меню логов и видим там появившиеся новые пункты.
Назначение меню логов.
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-сервер если нужна пересылка.
Активируем для надежности.
1 2 |
system-view info-center enable |
Проверяем статус модулей логирования и включаем по необходимости.
Проверка по настройке конфигурации.
1 |
display current-configuration | include log |
Проверка по статистике.
1 |
display diagnostic-information nlog |
Смотрим статистику. Если нули – не работает.
Назначение команд включения логов.
Команды почти идентичны соответствующим пунктам меню в GUI, но есть некоторые различия.
1 |
log type traffic enable |
Включает логирование всего трафика, который проходит через FW. Включение даёт статистику по сессиям, src/dst IP, портам, интерфейсам и т.д.
1 |
log type syslog enable |
Включает генерацию системных логов (например, события FW, интерфейсов, перезагрузки).
1 |
log type policy enable |
Включает логирование по правилам политики безопасности. Каждое совпадение политики (разрешено/заблокировано) будет записано.
1 |
log type threat enable |
Включает логирование угроз (IPS/атак и т.п.).
1 |
log type url enable |
Включает логирование URL-запросов (HTTP/HTTPS).
1 |
log type um enable |
Включает логирование аутентификации пользователей.
1 |
log type mail-filter enable |
Включает логирование почтового трафика.
1 |
log type content enable |
Включает логирование контента файлов.
1 |
default policy logging |
Включает логирование по умолчанию для всех правил политики, если явно не задано другое.
1 |
default session logging |
Включает логирование всех сессий, по умолчанию.
1 |
default traffic logging enable |
Включает логирование всего трафика по умолчанию.
1 |
policy logging |
Дополнительно включает логирование всех действий политики.
1 |
session logging |
Логи по каждой сессии.
1 |
traffic logging enable |
Дублирует log type traffic enable для отдельных политик.
Включаем все типы логов.
1 2 3 4 5 6 7 8 9 |
system-view log type traffic enable log type syslog enable log type policy enable log type threat enable log type url enable log type um enable log type mail-filter enable log type content enable |
Вывод логов в терминал. (вводится в режиме user-view)
1 |
terminal monitor |
Отключение вывода логов в терминал.
1 |
undo terminal monitor |
Далее рассмотрено содержание каждого типа логов.
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 без логирования.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 |
profile type url-filter name URL_LOG_PROFILE default action alert https-filter enable category pre-defined subcategory-id 101 action alert category pre-defined subcategory-id 102 action alert category pre-defined subcategory-id 162 action alert category pre-defined subcategory-id 163 action alert category pre-defined subcategory-id 164 action alert category pre-defined subcategory-id 165 action alert category pre-defined subcategory-id 103 action alert category pre-defined subcategory-id 166 action alert category pre-defined subcategory-id 167 action alert category pre-defined subcategory-id 168 action alert category pre-defined subcategory-id 104 action alert category pre-defined subcategory-id 169 action alert category pre-defined subcategory-id 170 action alert category pre-defined subcategory-id 105 action alert category pre-defined subcategory-id 171 action alert category pre-defined subcategory-id 172 action alert category pre-defined subcategory-id 173 action alert category pre-defined subcategory-id 174 action alert category pre-defined subcategory-id 106 action alert category pre-defined subcategory-id 108 action alert category pre-defined subcategory-id 177 action alert category pre-defined subcategory-id 251 action alert category pre-defined subcategory-id 109 action alert category pre-defined subcategory-id 110 action alert category pre-defined subcategory-id 111 action alert category pre-defined subcategory-id 112 action alert category pre-defined subcategory-id 114 action alert category pre-defined subcategory-id 115 action alert category pre-defined subcategory-id 117 action alert category pre-defined subcategory-id 178 action alert category pre-defined subcategory-id 179 action alert category pre-defined subcategory-id 180 action alert category pre-defined subcategory-id 181 action alert category pre-defined subcategory-id 248 action alert category pre-defined subcategory-id 118 action alert category pre-defined subcategory-id 119 action alert category pre-defined subcategory-id 122 action alert category pre-defined subcategory-id 182 action alert category pre-defined subcategory-id 183 action alert category pre-defined subcategory-id 184 action alert category pre-defined subcategory-id 123 action alert category pre-defined subcategory-id 124 action alert category pre-defined subcategory-id 186 action alert category pre-defined subcategory-id 187 action alert category pre-defined subcategory-id 188 action alert category pre-defined subcategory-id 189 action alert category pre-defined subcategory-id 125 action alert category pre-defined subcategory-id 126 action alert category pre-defined subcategory-id 190 action alert category pre-defined subcategory-id 127 action alert category pre-defined subcategory-id 128 action alert category pre-defined subcategory-id 129 action alert category pre-defined subcategory-id 191 action alert category pre-defined subcategory-id 192 action alert category pre-defined subcategory-id 193 action alert category pre-defined subcategory-id 194 action alert category pre-defined subcategory-id 195 action alert category pre-defined subcategory-id 196 action alert category pre-defined subcategory-id 130 action alert category pre-defined subcategory-id 131 action alert category pre-defined subcategory-id 132 action alert category pre-defined subcategory-id 197 action alert category pre-defined subcategory-id 198 action alert category pre-defined subcategory-id 199 action alert category pre-defined subcategory-id 200 action alert category pre-defined subcategory-id 227 action alert category pre-defined subcategory-id 228 action alert category pre-defined subcategory-id 133 action alert category pre-defined subcategory-id 201 action alert category pre-defined subcategory-id 202 action alert category pre-defined subcategory-id 204 action alert category pre-defined subcategory-id 205 action alert category pre-defined subcategory-id 134 action alert category pre-defined subcategory-id 135 action alert category pre-defined subcategory-id 136 action alert category pre-defined subcategory-id 137 action alert category pre-defined subcategory-id 138 action alert category pre-defined subcategory-id 139 action alert category pre-defined subcategory-id 140 action alert category pre-defined subcategory-id 141 action alert category pre-defined subcategory-id 206 action alert category pre-defined subcategory-id 207 action alert category pre-defined subcategory-id 208 action alert category pre-defined subcategory-id 209 action alert category pre-defined subcategory-id 210 action alert category pre-defined subcategory-id 229 action alert category pre-defined subcategory-id 142 action alert category pre-defined subcategory-id 143 action alert category pre-defined subcategory-id 144 action alert category pre-defined subcategory-id 145 action alert category pre-defined subcategory-id 146 action alert category pre-defined subcategory-id 147 action alert category pre-defined subcategory-id 211 action alert category pre-defined subcategory-id 212 action alert category pre-defined subcategory-id 213 action alert category pre-defined subcategory-id 240 action alert category pre-defined subcategory-id 253 action alert category pre-defined subcategory-id 149 action alert category pre-defined subcategory-id 150 action alert category pre-defined subcategory-id 214 action alert category pre-defined subcategory-id 215 action alert category pre-defined subcategory-id 216 action alert category pre-defined subcategory-id 217 action alert category pre-defined subcategory-id 151 action alert category pre-defined subcategory-id 218 action alert category pre-defined subcategory-id 219 action alert category pre-defined subcategory-id 220 action alert category pre-defined subcategory-id 221 action alert category pre-defined subcategory-id 222 action alert category pre-defined subcategory-id 223 action alert category pre-defined subcategory-id 230 action alert category pre-defined subcategory-id 252 action alert category pre-defined subcategory-id 152 action alert category pre-defined subcategory-id 153 action alert category pre-defined subcategory-id 238 action alert category pre-defined subcategory-id 154 action alert category pre-defined subcategory-id 155 action alert category pre-defined subcategory-id 224 action alert category pre-defined subcategory-id 225 action alert category pre-defined subcategory-id 156 action alert category pre-defined subcategory-id 157 action alert category pre-defined subcategory-id 158 action alert category pre-defined subcategory-id 231 action alert category pre-defined subcategory-id 232 action alert category pre-defined subcategory-id 159 action alert category pre-defined subcategory-id 254 action alert category pre-defined subcategory-id 160 action alert category pre-defined subcategory-id 161 action alert category pre-defined subcategory-id 176 action alert category pre-defined subcategory-id 226 action alert category pre-defined subcategory-id 234 action alert category pre-defined subcategory-id 235 action alert category pre-defined subcategory-id 236 action alert category pre-defined subcategory-id 237 action alert category pre-defined subcategory-id 239 action alert category pre-defined subcategory-id 241 action alert category pre-defined subcategory-id 233 action alert |
Применяем к политике безопасности.
Профиль 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.
1 2 3 4 5 6 7 8 9 |
security-policy rule name FULL-INTERNET-ACCESS policy logging session logging traffic logging enable source-zone trust destination-zone untrust profile url-filter URL_LOG_PROFILE action permit |
Посмотрим содержание одного любого лога.
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:
1 2 3 4 |
getContentLogListData getNlogDBUpdateState getProfileDataFile getDefined |
Это не реальные команды CLI, а внутренние HTTP-запросы от веб-интерфейса к системе для получения данных, например, когда при открытии вкладки Traffic Logs.
Пример действий через CLI или системные задачи.
1 2 3 |
display interface GigabitEthernet0/0/9 display cpu-usage display health |
Администратор 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.
1 2 3 4 |
system-view info-center enable info-center loghost source GigabitEthernet0/0/9 info-center loghost 192.168.1.10 |
Этого достаточно, чтоб логи начали отправляться на внешний сервер. Другие настройки можно оставить без изменений если нет каких-то особенных условий.
Назначение других настроек.
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 – в этой вкладке меню можно задать собственный формат строк логов, при отправке события на внешний сервер. По сути это конструктор логов, где указывается, какие поля включать и в каком порядке.
Создание шаблона для примера.
Задаем поля, которые нужно выводит.
Варианты режимов:
Expression – позволяет вручную задать текстовую строку (гибко, удобно для интеграции с приемщиками логов).
List – позволяет выбрать фиксированный список полей, USG сам создаёт формат.
Далее добавляем профиль в конфигурацию логов.
На приемной стороне смотрим результат.
Аналогичный смысл у настройки Netflow Log Template.
Отправка логов на e-mail в данной модели USG не предусмотрена. E-mail добавить можно, но нет возможности выбрать канал email. На почту можно отправлять ежедневные отчеты.
Проверка приема логов.
В роли сервера логов может быть что угодно (eSight, Siem, Syslog и др), для быстрого теста использован Visual Syslog Server for Windows.
После активации отправки на приемной стороне сразу начинают появляться логи из USG.
Пример лога.
Одинаково успешно прилетают все типы логов.
Итог.
Работа с логами USG – это не разовое действие, а постоянный процесс. Регулярный анализ журналов позволяет своевременно выявлять инциденты, контролировать работу систем безопасности и поддерживать стабильность инфраструктуры. Эффективное использование логов повышает прозрачность сети и является неотъемлемой частью информационной безопасности организации.