Сбор диагностической информации

Базовый комплект

Описание проблемы

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

Информация о системе

Версия пакета и ОС позволяют поддержке сверить поведение с известными проблемами сборки. Версия ядра критична для проблем с ipc_engine — модуль собирается под работающее ядро.

dpkg -l alertixnta            # Debian/Ubuntu/Astra
rpm -q alertixnta             # RHEL/Rocky/AlmaLinux/SberLinux
uname -a
cat /etc/os-release

Журналы

Журналы — основная часть комплекта: по ним локализуется звено конвейера, в котором возникла проблема.

Архив каталога журналов. Сохраняет хронологию целиком, включая ротированные копии в backup/.

sudo tar -zcvf /tmp/ngrsensor_logs.tar.gz /opt/alertixnta/log/

Журнал systemd. Сообщения sensor-ipc и sensor-manager есть только здесь; также фиксируются коды возврата при падении служб. Период выбирайте так, чтобы он охватывал момент инцидента и предшествующие 10–15 минут.

journalctl -u sensor-analyser.service --since "1 day ago" \
  > /tmp/analyser_journal.log
journalctl -u sensor-ipc -u sensor-manager -b \
  > /tmp/ipc_manager_journal.log
journalctl -u "sensor-*" --since "1 day ago" \
  > /tmp/sensor_journal.log

Сообщения ядра о модуле IPC. При успешной загрузке — строки [IPC-ENGINE] loading…​ и [IPC-ENGINE] loaded.; их отсутствие при загруженном модуле указывает на ошибку инициализации.

sudo dmesg | grep -i 'ipc.engine' | tail -20

Статус служб

Снимок фиксирует, какие службы работают, а какие в failed/inactive, — первичный признак локальной или каскадной проблемы. В выводе смотрите Active:, Main PID, Tasks, Memory и последние записи журнала.

sudo systemctl status 'sensor-*.service' > /tmp/services_status.txt

Восемь из десяти служб без модуля ipc_engine не стартуют (lsmod | grep ipc_engine). Если в юнитах директива ExecStart всё ещё указывает на /opt/alertixnta/sensor_<имя>, скорректируйте путь и выполните systemctl daemon-reload.

Ресурсы

Снимок в момент инцидента отделяет проблему конфигурации от проблемы инфраструктуры. Столбец available в free -h важен: ipc_engine выделяет буферы IPC-каналов при старте служб. Раздел с /opt/alertixnta/ проверяйте отдельно — каталоги retrans/ и filedrop/ растут при недоступности получателя.

top -b -n 1 > /tmp/top.txt
free -h     > /tmp/memory.txt
df -h       > /tmp/disk.txt
sudo /opt/alertixnta/ipc_counters > /tmp/ipc_counters.txt 2>&1

ipc_counters содержит lost_packets, resource_exceeding, transports/msg_sent_fail — по ним определяется узкое место.

Конфигурация и правила

Сравнение рабочих файлов с шаблонами поставки показывает отличия от эталона.

sudo tar -czf /tmp/alertixnta_config.tar.gz \
  /opt/alertixnta/config/*.json \
  /opt/alertixnta/config/init/*-default
sudo tar -czf /tmp/alertixnta_scripts.tar.gz /opt/alertixnta/scripts/

Конкретное правило. Приложите исходный код Lua-скрипта из каталога стадии (an-detect/, an-prefilter/, an-postfilter/) и запись в workFlow.* файла analyser.json с её позицией — позиция влияет на порядок вызова детекторов.

Доставка. Приложите выдержку из transfer.json (без секретов — см. Обезличивание данных), вывод nc -zv <host> <port>, строки журнала и статистику профилей:

tail -n 200 /opt/alertixnta/log/transfer.log
cat '/opt/alertixnta/log/!stat-transfer.log'

ICAP. Приложите секции clients и network.listenAddresses файла icap.json, записи icap.log. При повторяющихся ошибках временно включите журналирование запросов ("requestLog": { "enabled": true, "httpEnabled": true, "channel": "icap-request" }) и выполните sudo systemctl reload sensor-icap; после диагностики верните параметр в исходное состояние.

REST API. Приложите параметры проблемного профиля rapi.json (без ключей), tail -n 100 /opt/alertixnta/log/rapi.log, вывод ls -la /opt/alertixnta/certs/ и openssl x509 -in /opt/alertixnta/certs/<сертификат>.pem -noout -dates.

Сетевой трафик

При воспроизводимой проблеме на конкретном трафике приложите PCAP:

sudo tcpdump -i <интерфейс> -w /tmp/capture.pcap -c 1000

Либо файл из /opt/alertixnta/data/capdrop/ (запись через Traffic Record или профиль filedrop-pcap).

Запись может содержать конфиденциальные данные. Ограничьте её только необходимым трафиком и выполните требования Обезличивание данных.

Расширенный комплект: проблемы обнаружения угроз

Проверка звеньев отделяет три случая: трафик не дошёл или не разобран; разобран, но детектор не сработал; событие выпущено, но не доставлено.

Службы. Ожидается десять строк active.

systemctl is-active sensor-ipc sensor-manager sensor-watcher \
  sensor-transfer sensor-identity sensor-rapi sensor-analyser \
  sensor-ethercap sensor-pcap sensor-icap

Захват. У интерфейса в ethcap.log должно быть enabled: true; при ошибке открытия за записью Interface start следуют записи уровня E (Can’t bind to AF_PACKET socket, Did not wait for permission …, Timeout expired …).

grep "Interfaces available" /opt/alertixnta/log/ethcap.log | tail -1

Сессии. Записи должны содержать адреса проверяемого сегмента и заполненное appname:

tail -n 5 /opt/alertixnta/log/capture.log

Разбор протокола. Выберите журнал по протоколу (например, cef-kerberos.log, cef-smb.log, cef-email.log). Отсутствие записей — встроенный парсер выключен в nativeParsers либо Lua-парсер не включён в luaParsers файла ethercap.json.

tail -n 5 /opt/alertixnta/log/cef-kerberos.log

Детекторы. Вывод показывает число находок по детекторам. Если ожидаемого нет — проверьте enabled: true в workFlow.detect; для детекторов угроз номер позиции записи должен быть меньше фиксированного номера детектора протокола (l2-smb.lua — 7, l2-ssl.lua — 8, l2-ldap.lua — 4, l2-sip2.lua — 6); списки whitelist_admin_hosts и domain_controllers в anomaly.json должны быть заполнены — иначе l2-smb-lateral.lua, l2-ldap-recon.lua, l2-dcerpc-lateral.lua находок не выпускают.

grep -o '"detector":"[^"]*"' /opt/alertixnta/log/threats.log | sort | uniq -c

Конфигурация подсистемы угроз. Проверьте anomaly.enabled, объявление подканалов threat:* в ipc.json и токен criterr/all в loglevels правила threats.log (иначе находки критической важности в файл не попадут).

sudo grep -m 1 '"enabled"' /opt/alertixnta/config/anomaly.json
grep -oE '"(ti_match|behavioral|protocol_anomaly)"' \
  /opt/alertixnta/config/ipc.json | sort -u

Доставка. Признаки неисправности в transfer.log: Event delivery failed, Transport profile … is put on standby, Transport profile is not available, There is no IPC channel description(<канал>), Not found IPC channel(<канал>).

Обезличивание данных

Исключите из архивов и копий конфигурации:

  • закрытые ключи TLS из /opt/alertixnta/certs/ и учётные данные в конфигурациях профилей передачи;

  • токены и пароли в identity.json (authHdrValue, password), transfer.json (virtotal_token, athena_token, ptsb_api_key, cyberprotego_client_salt, password, kafka_ssl_key_password), rapi.json (password), icap.json (user, password секции clients.rules);

  • содержимое извлечённых объектов и записи threats.log/cef-*.log — прикладывайте выборочно.

Исходные рабочие файлы на сервере не изменяйте; обезличивайте копии.

Итоговый архив

sudo tar -czf /tmp/alertixnta_diagnostics.tar.gz \
  -C /tmp alertixnta_logs.tar.gz \
           alertixnta_config.tar.gz \
           alertixnta_scripts.tar.gz \
           services_status.txt \
           analyser_journal.log \
           ipc_manager_journal.log \
           sensor_journal.log \
           top.txt memory.txt disk.txt \
           ipc_counters.txt

Перед отправкой проверьте: описание проблемы приложено; указаны версии продукта, ОС и ядра; секреты обезличены; закрытые ключи и учётные данные отсутствуют; исходные тексты проблемных Lua-скриптов и их позиции в конфигурационных массивах включены.

Структура обращения

  1. Описание проблемы (см. «Описание проблемы»).

  2. Архив alertixnta_diagnostics.tar.gz.

  3. Номер шага, на котором ожидаемый результат не получен (для проблем обнаружения угроз).

  4. Перечень изменений конфигурации с указанием времени.

  5. Сведения о предшествующих обновлениях пакета и изменениях инфраструктуры (смена ядра, топология сети, база правил).