dpkg -l alertixnta # Debian/Ubuntu/Astra
rpm -q alertixnta # RHEL/Rocky/AlmaLinux/SberLinux
uname -a
cat /etc/os-releaseСбор диагностической информации
Базовый комплект
Описание проблемы
К обращению приложите: суть проблемы, время возникновения, условия воспроизведения, ожидаемое и фактическое поведение, предшествующие действия (обновление пакета, правка конфигурации, смена ядра, изменение топологии), влияние на эксплуатацию.
Информация о системе
Версия пакета и ОС позволяют поддержке сверить поведение с известными проблемами сборки. Версия ядра критична для проблем с ipc_engine — модуль собирается под работающее ядро.
Журналы
Журналы — основная часть комплекта: по ним локализуется звено конвейера, в котором возникла проблема.
Архив каталога журналов. Сохраняет хронологию целиком, включая ротированные копии в 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Восемь из десяти служб без модуля |
Ресурсы
Снимок в момент инцидента отделяет проблему конфигурации от проблемы инфраструктуры. Столбец 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>&1ipc_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-скриптов и их позиции в конфигурационных массивах включены.
Структура обращения
Описание проблемы (см. «Описание проблемы»).
Архив
alertixnta_diagnostics.tar.gz.Номер шага, на котором ожидаемый результат не получен (для проблем обнаружения угроз).
Перечень изменений конфигурации с указанием времени.
Сведения о предшествующих обновлениях пакета и изменениях инфраструктуры (смена ядра, топология сети, база правил).
Эта страница была полезна?
Спасибо за отзыв!
Спасибо, мы учтём это для улучшения документации.