Диагностика и решение проблем

• Проблемы ICAP интеграции
• Техническое ПМИ KATA 7.* - проверка всех технологий, что они работают
• Базовая диагностика и устранение сбоев продукта KATAP
• Инструкция по устранению ошибок приоритизации в Sandbox (KATA Platform v7)
• Как исправить ошибки маршрутизации в KATA Sandbox

Проблемы ICAP интеграции

Troubleshooting ICAP интеграции KATA с внешними системами.

Если после настройки нет срабатываний или активности в графиках, выполните следующие действия:

Проверка сетевой взаимосвязанности

1. Проверьте соединение между CN/Sensor и Proxy по порту 1344 с помощью tcpdump:

tcpdump -i  port 1344 -nn

Описание функциональных возможностей команды tcpdump

Проверка со тсороны Сentral Node

Проверка со стороны Proxy

---

Сбор tcpdump для анализа трафика

1. Для проверки соединения по порту 1344 между CN/Sensor и ProxyServer выполните на каждой из сторон:

tcpdump -i  port 1344 -nn -w capture_filename.pcap

2. Эти файлы в формате PCAP удобно анализировать в инструментах типа Wireshark.
3. Для выгрузки файлов используйте SCP/WinSCP, например:
4. Подключитесь к CN/Sensor или ProxyServer.
5. Перейдите в каталог, где сохранен tcpdump (например, /home/admin/).
6. Скачайте файл на локальный компьютер.

Примечание: Ссылка на описание функциональных возможностей команды tcpdump.

---

Проверка логов системы

1. Подключитесь к CN/Sensor через SSH и перейдите в Technical Support Mode.
2. Для выгрузки логов выполните:

sudo su
kata-collect-siem-logs log-history --output-dir /tmp --no-compress
kata-collect-siem-logs log-detects --output-dir /tmp --no-compress



В данный журнал пишутся файлы создавшие сработку в решении KATA

• В log-history.log содержатся записи обо всех проверенных файлах.
• В log-detects.log — информация об объектах, вызвавших срабатывания.

3. Скачайте журналы с помощью SCP/WinSCP из каталога /tmp.
4. В файлах логов найдите записи по ключевому слову ICAP, чтобы убедиться в получении и анализе трафика от ICAP-клиента.

---

Просмотр логов сработки

Для просмотра логов работы ICAP на стороне CN/Sensor подключитесь через SSH и выполните:

sudo su
cat /var/log/kaspersky/services/preprocessor_icap/preprocessor_icap.log

Для удобства анализа можно использовать фильтрацию по режимам сканирования:

• стандартный режим:

  grep --color 'blocking_simple mode' /var/log/kaspersky/services/preprocessor_icap/preprocessor_icap.log | grep 'verdict'

• расширенный режим:

  grep --color 'blocking_advanced mode' /var/log/kaspersky/services/preprocessor_icap/preprocessor_icap.log | grep 'verdict'

---

Советы по созданию заявки в службу технической поддержки

Чтобы ускорить решение возможных проблем и сократить время обработки заявки, рекомендуется:

• Соберите как можно больше информации об установке KATA и KEDR:
  • модель и характеристики оборудования,
  • уровень трафика,
  • типы интеграции,
  • версии программного обеспечения,
  • даты возникновения проблемы.
• Обязательно приложите актуальные логи:
  • журнал системы,
  • tcpdump с обеих сторон (ICAP-клиент и ICAP-сервер),

  Пример: tcpdump -i ens192 port 1344 -nn -w capture_filename 

• collect log с CN/Sensor.

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

---

Техническое ПМИ KATA 7.* - проверка всех технологий, что они работают

IDS‑обнаружения (SPAN)

Для проверки IDS‑обнаружений (SPAN) можно использовать утилиту tcpreplay на сервере, сконфигурированном для получения трафика SPAN.

Пакет tcpreplay не устанавливается по умолчанию, поэтому его нужно установить вручную. Следуйте инструкции ниже:

1. Скачайте пакет tcpreplay_4.3.2‑1build1_amd64.deb по ссылке.
2. Скопируйте загруженный файл на узел KATA, например с помощью scp:

   [user@host]$ scp <your-path>/tcpreplay_4.3.2-1build1_amd64.deb admin@<kata‑ip>:/tmp

3. Установите пакет на узле KATA командой:

   [admin@katahost]$ sudo dpkg -i /tmp/tcpreplay_4.3.2-1build1_amd64.deb

После установки вы сможете использовать tcpreplay на KATA.

Проверка трафика EICAR

Загрузите пример EICAR-Test-File_TCP.pcap на сервер с SPAN‑интерфейсом, затем выполните команду от имени root:

tcpreplay -i ens34 EICAR-Test-File_TCP.pcap    # ens34 в этом примере — SPAN‑интерфейс

Проверка трафика Nmap

Сценарий такой же, как для Eicar, только используется другой файл .pcap (HackTool.Nmap.HTTP.C&C.pcap).

После тестирования детектов по SPAN рекомендуем отключить tx‑capture обратно тем же способом, что и при включении.

AM Engine

Для проверки антивирусного (AM) движка используйте тестовый файл EICAR (www.eicar.com).

• Почта: отправьте файл EICAR по SMTP на порт 25 узла KATA (обработка SMTP должна быть включена). Для простоты можно воспользоваться локальным клиентом swaks на узле Central Node, чтобы не настраивать почтовую систему.

Пример использования swaks:

swaks --server 127.0.0.1 --port 25 --from antony@test.org --to cleopatra@test.org --attach eicar.com
swaks --server 127.0.0.1 --port 25 --from antony@test.org --to cleopatra@test.org --body "link_to_EICAR_here"

• Конечная точка: поместите файл EICAR на рабочую станцию и отправьте его в очередь на проверку при помощи задания GetFile.

Обнаружения YARA

По умолчанию в продукте нет правил YARA. Для тестирования можно использовать тестовое правило из документации YARA (writingrules):

rule ExampleRule
{
    strings:
        $my_text_string = "text here"
        $my_hex_string  = { E2 34 A1 C8 23 FB }
    condition:
        $my_text_string or $my_hex_string
}

Это правило отметит любой анализируемый объект, содержащий строки $my_text_string или $my_hex_string.

Обнаружения TAA (IoA)

Проверка детектов IoA возможна только при наличии лицензии KEDR.

• Скопируйте файл .bat из прикреплённого архива Test_IOA.rar (пароль not_infected) в любую папку на хосте с установленным EDR и запустите его. Через несколько минут (KATA требуется время на передачу и обработку телеметрии) проверьте оповещения в KATA. В алерте должен быть тип ioa_test_detect. Если тестировать IoA на этом хосте повторно, файл .bat необходимо размещать в разные папки.
• На хосте с установленным KEA выполните в cmd.exe команду:

  wmic.exe "sfdgcall uninstallkasperskyblabla"

  Команда завершится ошибкой, но это не важно. Через несколько минут в веб‑интерфейсе KATA появится новое IoA‑срабатывание.

Обнаружения TAA по цепочке событий

Чтобы проверить TAA‑срабатывания по цепочке событий, сначала убедитесь, что эта функция включена в веб‑интерфейсе KATA (и что ресурсы заказчика позволяют её включить).

Затем на одной из подключённых машин EDR распакуйте архивы и запустите сценарии .bat:

• short_term_user_creation_complex.7z
• multiple_login_attempts_with_the_same_account_complex.7z

Обнаружения IoC

Для тестирования можно использовать собственное правило: архив Ioctest.zip (пароль infected123) срабатывает на запуск c:\windows\system32\calc.exe.

Автоматическая песочница в EDR

Для проверки автоматической песочницы:

• Распакуйте архив с образцом и используйте пароль для образцов по умолчанию: autosbtest.zip.
• Важно: не меняйте MD5‑хэш образца.
• Запустите образец на защищённом EDR хосте и дождитесь автоматического срабатывания песочницы (verdict Suspicious Activity).
  

Для KESL: используйте файлы из архива, чтобы вызвать срабатывание песочницы и KESL:

• Распакуйте архив test_ioa_sb_linux.7z (пароль «infected») и скопируйте скрипт test_ioa_sb_linux.sh вместе с файлом kl_kata_demo_starter на хост с KESL (например, через WinSCP).
• Проверьте разрешения на файлы: если они не исполняемые, выполните команду:

  sudo chmod 777 <файл>

• Запустите скрипт командой ./test_ioa_sb_linux.sh и дождитесь появления алерта в KATA.

Проверка песочницы (Sandbox detect)

Для проверки песочницы можно использовать файл SA_sleep.exe из архива no_am_detection sample.rar. Пароль хранится в текстовом документе внутри архива.

1. Перейдите в веб‑интерфейс старшего офицера безопасности KATA.
2. Выберите меню Хранилище → Загрузить и загрузите файл SA_sleep.exe из архива для проверки KATA.
3. KATA поместит его в песочницу, и чуть позже SB должен вынести вердикт Подозрительная активность.
4. Если для SA_sleep.exe выдается вердикт «Not detected», используйте сценарий test_sb.bat из архива test_sb.zip.

Проверка репутации URL

Сначала убедитесь, что K(P)SN настроен и работает корректно. В этом примере хэш MD5 должен возвращать статус UnTrusted. Для проверки используйте команды:

Для KATA 4.+ и 5.0:
docker exec -it $(docker ps | grep ksn_proxy | awk '{print $1}') /opt/kaspersky/apt-ksn_proxy/sbin/ksn_client --ip 127.0.0.1 --hash 9C642C5B111EE85A6BCCFFC7AF896A51

Для KATA 5.1:
docker exec -it $(docker ps | grep ksn_proxy | awk '{print $1}') /opt/kaspersky/apt-ksn-proxy/sbin/ksn_client --ip 127.0.0.1 --hash 9C642C5B111EE85A6BCCFFC7AF896A51

Затем:

• Трафик: перейдите по адресу http://bug.qainfo.ru/TesT/Aphish_w/index.
• Почта (SMTP‑обработка должна быть включена): отправьте ссылку из примера по электронной почте. Быстрый тест можно сделать с помощью команды swaks:

swaks --server 127.0.0.1 --port 25 --from fisherman@test.org --to cleopatra@test.org --body "http://bug.qainfo.ru/TesT/Aphish_w/index"

Базовая диагностика и устранение сбоев продукта KATAP

Просмотр информации о файлах, поступавших на проверку в Kaspersky Anti Targeted Attack Platform

Инструкция по устранению ошибок приоритизации в Sandbox (KATA Platform v7)

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

В среде KATA Platform версии 7 на компоненте Sandbox наблюдается:

• Рост времени обработки объектов;
• Ошибки самодиагностики компонента;
• Задержки доставки писем от интеграции с KSMG.

Симптомы

1. В логах Sandbox (/var/log/kaspersky/sandbox/checker/checker.log) присутствуют записи вида:

[2025.07.01 08:53:47] [ERROR   ] - root - Job 41909 timed out
[2025.07.01 09:01:54] [ERROR   ] - root - Job 42151 timed out
[2025.07.01 09:07:02] [ERROR   ] - root - Job 42411 timed out
[2025.07.01 09:15:09] [ERROR   ] - root - Job 42744 timed out

2. В логах Central Node (/var/log/kaspersky/services/web_backend/web_backend.log) фиксируются события самодиагностики:

2025-07-01 02:25:27,615.615 [kata_notifications.system_health_notifier] DEBUG engines: status changed `sandbox`
2025-07-01 02:25:27,615.615 [kata_notifications.system_health_notifier] DEBUG meta received {'host': '0.0.0.0', 'status': 'error', 'lastCheck': '2025-07-01T02:23:17.600974', 'message': {'debug': 'Win7_x64-1750946849,CentOS7_x64-1750947724', 'id': 'sandbox_error'}, 'type': 'sandbox'}
2025-07-01 02:25:27,616.616 [Audit] CRITICAL Component Sandbox IP 0.0.0.0 Type sandbox Status error

Решение

sudo -u postgres psql kitchen -c 'UPDATE submitters SET default_priority=0 WHERE id=2;'

Примечание: Если проблема сохраняется после выполнения указанных действий, рекомендуется обратиться в техническую поддержку Kaspersky с полным архивом логов Sandbox и Central Node.

Как исправить ошибки маршрутизации в KATA Sandbox

Важно:
Маршруты в веб-консоли Sandbox применяются только к management-интерфейсу. Неправильная настройка маршрутов может привести к ошибкам вида:

Incorrect response from server with HTTP code 500: /api/units/sandbox/network/central_node

Для диагностики и проверки конфигурации malware-интерфейса воспользуйтесь статьей:
How to fix malware interface route misconfiguration issues

Если проблема актуальна - воспользуйтесь одним из двух решений ниже:

ip route show

sudo ip route del <некорректный маршрут>

sudo rm /etc/network/if-up.d/route-ens224

sudo ifdown ens224 --force
sudo ifup ens224 --force

/opt/kaspersky/sandbox/bin/sbnetworking all show > settings.json

{
  "hostname": { "fqdn": "sandbox-node" },
  "slots": { "count": 48 },
  "dns": { "servers": ["192.168.x.x", "192.168.x.x"] },
  "management": {
    "ipv4": {
      "addr": "192.168.x.x",
      "mask": "255.255.255.0",
      "hw_addr": "xx:xx:xx:xx:xx:xx",
      "ip_used": "192.168.x.x"
    },
    "name": "mgmt0"
  },
  "malware_ifaces": {
    "mal0": {
      "ipv4": {
        "addr": "192.168.x.x",
        "mask": "255.255.255.0",
        "hw_addr": "xx:xx:xx:xx:xx:xx",
        "ip_used": "192.168.x.x"
      }
    }
  },
  "malware_channels": {
    "1": {
      "auto": true,
      "desc": "Primary",
      "ifname": "mal0",
      "gateway": "192.168.x.x",
      "monitor": false,
      "name": "Primary"
    }
  },
  "routes": {
    "mgmt0": [
      {
        "dest": { "addr": "0.0.0.0", "mask": "0.0.0.0" },
        "gw": "192.168.x.x"
      }
    ]
  }
}

/opt/kaspersky/sandbox/bin/sbnetworking all apply --file settings.json

reboot

После выполнения этих шагов ошибка HTTP 500 должна исчезнуть, и Sandbox будет корректно работать.

Примечание: Если проблема сохраняется после выполнения указанных действий, рекомендуется обратиться в техническую поддержку Kaspersky с полным архивом логов Sandbox.