В конце 2021г вышла новая версия продуктов Kaspersky Anti Targeted Attack (KATA) Platform и Kaspersky Endpoint Detection and Response (KEDR) 4.0, а через полгода – версия 4.1.

Выход мажорной версии обычно подразумевает крупные изменения, также возможны изменения несовместимые с предыдущей версией.

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

Таким образом в статье рассмотрим особенности перехода с версии 3.7.2 последовательно на версию 4.0 и затем на версию 4.1.

Что нового в KATA

У продуктов Лаборатории Касперского хорошая и всем доступная онлайн-справка, где перечислены все нововведения и ограничения версии 4.0, так и нововведения и ограничения версии 4.1. Новый функционал затрагивает как работу с обнаружениями, так и удобство использования KATA.

В новых версиях появились интересные возможности, которые наверняка найдут применение в повседневной эксплуатации продукта.

Так, наконец, в версии 4.0 появилась возможность использования доменных учетных записей для аутентификации в веб-интерфейсе KATA. Теперь не надо плодить дополнительные локальные учетные записи. Учет и контроль доступа к KATA значительно облегчится.

В версии 4.0 также появилась возможность автоматически отправлять файлы с хостов на проверку в Sandbox на основе выполнения правил TAA (IOA) “Лаборатории Касперского”. Данную фичу можно включать и отключать, а также наблюдать результаты отправки файлов на виджете.

В версии 4.1 в Sandbox в дополнении к трем виртуальным машинам с ОС Windows (XP, 7, и 10), появилась дополнительная виртуальная машина с операционной системой CentOS 7.8. При этом одновременно появилась возможность выбора используемых ВМ в Sandbox- либо только все ВМ с ОС Windows, либо все Windows + CentOS.

Полное описание новых возможностей, большая часть которых касается работы EDR, можно посмотреть по ссылкам, указанным выше.

Подготовка к обновлению

Стандартно, перед началом обновления рекомендуется выполнить:

Внеплановое резервное копирование виртуальных машин, для возможности восстановления системы в работоспособное состояние.
Резервное копирование настроек KATA c помощью средств CLI (GUI) и штатного механизма.
Сохранение TLS сертификатов сервера KATA, для дальнейшей установки его в систему КАТА. Это позволит сохранить текущие конфигурации агентов KEA и прочих систем, которые взаимодействуют с платформой.
Также рекомендуется сохранить скриншоты текущих настроек. Списки пользователей, паролей, исключения, пользовательские правила можно сохранить в текстовый файл путем копирования их из Web-интерфейса.

Порядок обновления

Предварительно рекомендуется провести тестирование обновления KATA в тестовой среде на стенде. В идеальном случае можно развернуть копию сервера и протестировать обновление на копии.

Обновление версии 3.7.2 выполняется путем последовательного запуска установки KATA версии 4.0 и 4.1 из файлов ISO поверх установленной версии 3.7.2 (4.0) с сохранением настроек.

В процессе установки будет обнаружена старая версия и будет предложено обновиться до новой.

Также в процессе обновления будет предложено обновить платформу, учитывая один из сценариев, где участвуют менее 5000 агентов KEA и больше 5000.

Сервер PCN обновляется без дополнительных изменений в распределенном режиме.

Сервера SCN перед обновлением необходимо перевести в автономное состояние (Standalone). После обновления сервера, необходимо будет заново переводить сервер в распределенную конфигурацию, подав запрос на авторизацию в PCN.

Sandbox КАТА версии 4.0, а затем и 4.1 использует более поздние версии ВМ, поэтому Sandbox подлежит полной переустановке с последующей интеграцией с CN.

Так как большое количество новых возможностей реализовано для хостов с компонентом Kaspersky Endpoint Agent для Windows версии 3.12 (для 4.0) и версии 3.13 для версии 4.1, то логично, для получения возможности использования всего нового функционала KATA 4.0 и 4.1, обновить агенты до версии 3.12 и 3.13 соответственно.

Старые версии KEA, начиная с версии 3.8 совместимы с KATA 4.1, но при этом объем передаваемых агентом данных ограничен.

Состав и объем данных, сохраняемых при обновлении программы с версии 3.7.2 до версии 4.0 и с версии 4.0 до версии 4.1

Тип данных	Данные, сохраняемые при обновлении
Параметры Central Node или PCN.	Все данные, кроме: - лицензионных ключей; - параметров интеграции с компонентом Sandbox; - параметров интеграции с компонентом Sensor.
Базы данных программы на Central Node или PCN (база обнаружений, данные мониторинга работы программы, база пользовательских правил, задачи, политики, правила, добавленные в исключения).	Все данные, кроме: - файлов, которые в момент обновления Kaspersky Anti Targeted Attack Platform до версии 4.1 находились в очереди на проверку; - файлов, которые в момент обновления Kaspersky Anti Targeted Attack Platform до версии 4.1 находились в очереди на повторную проверку (rescan); - данных отчетов.
База событий.	Все данные.
Хранилище и карантин.	Все данные.
Артефакты Sandbox.	Все данные.

Процесс обновления

В нашем случае производилось обновление KATA 3.7.2 в распределенной конфигурации: один PCN, два SCN, и всего 11 Sandbox (без выделенных сенсоров). Все серверы были развернуты на виртуальных машинах.

Первоначально было произведено обновление до версии 4.0. В тот момент версия 4.1 еще не вышла, поэтому нам повезло поработать с версией 4.0, а затем обновиться до версии 4.1.

Далее описан процесс обновления до версии 4.0.

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

Перед началом обновления все CN перевели в standalone режим. Первым начали обновлять PCN.

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

В этот момент нам пришлось набраться терпения – на экране иногда проскакивали сразу десятки строк, а иногда процесс останавливался на 10-20 минут. В итоге обновление происходило более 3-х часов, и завершилось без сообщений об ошибках.

После входа в Web-интерфейс появилась внутренняя ошибка сервера.

Для устранения ошибки произвели попытку сброса настроек: apt-sedr-reset. Выполнение данной команды продолжалось около 30 минут и к успешному результату не привело. Как выяснилось позже, в версии 4.0 (и в версии 4.1), после восстановления базы, необходимо в обязательном порядке для переназначения идентификаторов выполнять следующую команду:

apt-settings-manager set --merge /configuration/agent_server \{\"server_installation_id\"\:\ \"`uuidgen`\"\}

После неудачи восстановили сервер из резервной копии и произвели повторную попытку обновления PCN. Более 3-х часов ожидания та же самая внутренняя ошибка сервера и снова восстановление сервера из резервной копии.

Учитывая, что две попытки обновления заняли весь рабочий день и не привели к успеху, возможным вариантом выхода из текущей ситуации была переустановка серверов KATA с нуля. Так же, при принятии решения о переустановке CN с нуля, учитывали следующие моменты:

в целом в KATA производится небольшое фиксированное количество настроек, которые легко настроить заново;
переустановка и настройка серверов CN KATA, в нашем случае, занимает гораздо меньше времени, чем обновление;
время переустановки серверов CN незначительно, по сравнению с переустановкой 11-ти серверов Sandbox;
у нас не было большого количества пользовательских правил и исключений. При этом правила можно импортировать из заранее сохраненного списка;
при переустановке теряются ранее зафиксированные KATA обнаружения. У нас обнаружения передавались и хранились в SIEM, так что их потеря в KATA не являлась критичной;
потеря данных мониторинга работы программы не критична;
количество интеграций с внешними системами легко восстанавливается;
агенты KEA легко подключаются заново групповой политикой в KSC.

Как и ожидалось, установка PCN и одного SCN с нуля прошла быстро, приступили к установке Sandbox. Процесс установки образов ВМ длительный, ошибок при установке не было. Однако после подключения SB к CN из 10-ти SB у 5-ти получили ошибку всех трех образов на Sandbox.

Перезагрузка Sandbox к устранению ошибки не приводила. Произвели повторную переустановку Sandbox. При этом устанавливали строго по одному образу, после каждого установленного образа производили перезагрузку SB. Такие «танцы с бубном» привели к нормальной установке еще 4-х SB, однако один SB так и остался с ошибками, которые устранили позже, в результате длительной переписки с вендором.

Третий SCN переустановили и подключили позже и также не без приключений.

В итоге процесс перехода на KATA 4.0 был завершен, трафик запущен.

При переходе на версию 4.1 уже решили судьбу не испытывать, и сразу переустановили все сервера на версию 4.1 с последующей настройкой.

В случае обновления с любой ранней версии на версию 4.1 рекомендуется полная переустановка всех серверов на версию 4.1 с последующей настройкой всех параметров и интеграций «вручную».

Особенности работы новых версий KATA (лайфхаки)

В процессе установки и эксплуатации KATA 4.0 и 4.1 столкнулись с некоторыми особенностями работы новых версий KATA.

Подключение распределенного SCN

При подключении SCN расположенного в другой контролируемой зоне выяснилось, что в отличии от версии 3.7.2, в KATA версии 4.0 для подключения SCN к PCN необходимо дополнительно открывать порт TCP 8443 в обе стороны.

Также, если у вас есть интеграция KATA с KPSN, сначала необходимо подключать все SCN к PCN и только после этого производить интеграцию PCN с KPSN. В противном случае, получаем ошибку подключения SCN к PCN. На самом деле, такое поведение не является особенностью версии 4.0: оно проявлялось также в версии 3.7.2. Просто надо об этом не забывать.

Использование собственного TLS сертификата

Если при эксплуатации KATA планируется использовать собственный TLS сертификат, то рекомендуется подготовить файл сертификата заранее и загрузить его в процессе первоначальной установки PCN.

Файл TLS-сертификата, предназначенный для загрузки, должен удовлетворять следующим требованиям:

Файл должен содержать сам сертификат и закрытый ключ шифрования соединения.
Файл должен иметь формат PEM.
Длина закрытого ключа должна быть 2048 бит или более.

Загрузить собственный сертификат можно и позже, но это приведет к повторной интеграции всех SCN, Sandbox, агентов KEA, почтовых сенсоров, и других подключаемых к KATA программ Лаборатории Касперского.

Ошибки всех образов на Sandbox

Время от времени на разных Sandbox возникает ошибка сразу всех образов виртуальных машин. При первом появлении, о чем я писал выше, перезагрузка Sandbox не устраняла ошибку. Специалисты техподдержки выяснили, что происходит некорректное обновление баз Sandbox в результате чего и возникает ошибка. В нашем случае обновление баз было настроено через PCN, который в свою очередь обновлялся через proxy-сервер.

По рекомендации вендора на проблемном Sandbox настроили прямое обновление баз через malware-интерфейс. После обновления баз и перезагрузки SB ошибка ушла.

Позже выяснили, что Proxy-сервер, через который производилось обновление баз SB, блокировал загрузку исполняемых файлов в обновлениях. Данную блокировку исключили для PCN.

Также обнаружили, что для Sandbox в версии 4.0 проявлялась ошибка подвисания worker service, которая была исправлена в версии 4.1.

Подключение KSMG

После перехода на версию KATA 4.0 заказчик интегрировал с KATA пилотируемый у них Kaspersky Server Mail Gateway.

Первоначальное подключение KSMG привело к появлению в окне мониторинга графика от нового источника Kaspersky Mail Sensor и скачку времени обработки трафика на Sandbox.

Позже опытным путем выяснили, что скачок времени обработки происходил каждый раз, при интеграции (или повторной интеграции) KSMG с KATA. Чрез 1-2 часа время обработки стабилизировалось и стало чуть больше обычного, что естественно связано с увеличением количества обрабатываемых файлов на Sandbox при подключении трафика KSMG.

В процессе выяснения причин увеличения времени обработки трафика и экспериментов с повторной интеграцией KSMG, график от Kaspersky Mail Sensor, как и сам источник, пропал, и восстановить его так и не удалось. При этом обработка трафика с KSMG происходила штатно, ошибок нет.

В версии 4.1 проблему интеграции KATA с KSMG так до конца решить не удалось. График не появился, а интеграция время от времени подвисает.

Скачивание журналов системы с Sandbox

Через некоторое время работы KATA 4.0 заметили, что стандартный вариант скачивания журнала системы с Sandbox, с использованием меню – «Администрирование – Журнал системы – Скачать», приводит к появлению ошибки сети – Network Error. При анализе видно, что скачивается чуть больше гигабайта, после чего появляется ошибка. Если размер меньше гигабайта, журнал скачивается нормально.

В результате переписки вендор подтвердил, что существует техническое ограничение на размер скачиваемого через web-интерфейс журнала системы. Изменить это ограничение невозможно, в т.ч. и в версии 4.1, т.к. могут возникнуть проблемы с производительностью и работоспособностью SB в целом.

В этом случае собирать и забирать журнал системы необходимо из CLI, используя следующую последовательность действий:

Запустите команду sudo sb-logs --create '/tmp' '-7', где -7 - количество дней, за которые собирать лог. После завершения выполнения команда выведет путь к collect-логу.
Выполните команду chmod 777 <путь к collect-логу>
Скачайте лог через scp: scp admin@:/tmp/<название collect-архива>

Данное ограничение на размер скачиваемого через web-интерфейс журнала системы также осталось и для Sandbox версии 4.1

Уменьшение количества обнаружений

После установки KATA 4.0 столкнулись с тем, что довольно долго не было обнаружений в окне мониторинга офицера безопасности. Мы даже проверяли работу KATA при помощи тестовой вредоносной программы eicar.

Позже выяснили, что в KATA 4.0 действительно проводилась оптимизация обнаружений, с целью уменьшения ложноположительных срабатываний.

Аналогичная особенность присуща и версии 4.1

Итоги и рекомендации

KATA 4.1 с компонентом Kaspersky Endpoint Agent для Windows версии 3.13 и Kaspersky Endpoint Agent для Linux 3.12 предоставляет достаточно большое количество обновленных интересных возможностей, так что переход на новую версию видится целесообразным.

В целом версия 4.1 работает более стабильно, хотя не все проблемы удалось решить. Тем не менее не решенные проблемы KATA могут вас совсем не коснуться.

При переходе на новую версию KATA внимательно присмотритесь к варианту полной переустановки серверов CN, что может позволить сэкономить значительное количество времени и получить «чистую» систему. Сервера Sandbox переустанавливаются в любом случае.

Тем более переустановку целесообразно делать, если вы переходите на версию KATA 4.1 с версии 3.7.2 – просто ставите сразу версию 4.1, без промежуточной установки версии 4.0.

Устаревшие агенты KEA подключаете групповой политикой сразу после переустановки KATA и планируете время на установку последней версии KEA.

От рассвета до заKATA. Обновляем KATA до версии 4.0 и 4.1