Внедрение Антивируса Kaspersky в инфраструктуру на CentOS 7

Внедрение Антивируса Kaspersky в инфраструктуру — сложный и длительный процесс, особенно если проект уже вышел в промышленную эксплуатацию и желающих взять на себя ответственность за простой сервиса нет.

Постановка задачи

Началось всё с того, что появилось требование от коллег: развернуть на серверах проекта приложение Kaspersky Endpoint Security.

Данное решение включает три основных компонента:

• Kaspersky Security Center;
• Агент администрирования;
• Kaspersky Endpoint Security.

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

Итак, как установить Агент администрирования и Kaspersky Endpoint Security?

В целом ничего сложного: идем на официальный сайт, ищем нужные дистрибутивы, скачиваем, ставим. Но когда серверов накапливается 50-100, этот подход уже не кажется удобным.

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

Думаю, у каждого администратора есть сервер, на котором он проводит испытания. Любые процессы должны отлаживаться именно на таких серверах.

Пошаговое внедрение Антивируса Kaspersky

Для себя мы определили каким образом будем внедряться. Конечно всё, что написано ниже, не проходило через согласования и документооборот. Этот план нужен нам самим, чтобы не потеряться в процессе, так как он затянут по времени.

• нарисовать схему объектов KSC:
  • основные группы устройств;
  • политики, применяемые на группы (либо собственные, либо наследованные);
  • задачи, запускаемые на группы устройств:
    • добавление ключа;
    • обновление баз;
    • проверка на вирусы;
• в KSC создать группы устройств;
• создать политики и задачи в соответствии со схемой;
• на тестовом сервере установить агент администрирования вручную;
• в KSC устройство распределить в нужную группу;
• на тестовом сервере установить Kaspersky Endpoint Security вручную;
• проверить, что KESL подключился к KSC и работает под политикой;
• проверить запуск задач KSC на целевом тестовом сервере;
• автоматизировать процесс установки klnagent и kesl;
• определить тестовую группу из работающих серверов. Основная задача данной группы — проверить корректность обновлений и убедиться, что новшества ничего не сломают. Эта группа будет первой получать:
  • новые политики;
  • обновления программ (klnagent, kesl);
• разработать поэтапный план внедрения. Мы использовали интервал между этапами две недели для того, чтобы проверить корректность поведения антивируса перед раскатыванием в промышленном окружении;
• установить klnagent и kesl на тестовую группу;
• в соответствии с планом внедрения раскатывать на целевые сервера.

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

Техническая реализация

Техническая часть разделена на 4 отдельных статьи. Две по агенту администрирования:

Ручная установка агента администрирования

Установка klnagent с помощью ansible

Две по Kaspersky Endpoint Security:

Ручная установка Kaspersky Endpoint Security

Автоматизация установки KESL с использованием ansible

Репозиторий с исходниками автоматизации на github: https://github.com/ittxx/kaspersky

Внедрение Антивируса Kaspersky — проблемы

Исключения могут не примениться

На примере Elasticsearch добавили исключения в родительскую политику. Сначала в раздел Базовая защита -> Области исключений:

Потом в Общие параметры -> Глобальные исключения:

После этих действий принудительно синхронизировал агент и подождал около суток (периодический проверяя логи Касперского). Результат не утешительный — исключения не работают. Как я понял (официальной информации найти не удалось), первая строчка лога говорит о том, что включается модуль exclude (excl) и собирается исключить из проверки файл _6qd_Lucene70_0.dvm:

2021.02.10 15:28:11.030 3040    INF     excl    object_matcher::is_match: Path [/var/lib/elasticsearch/nodes/0/indices/cgjNKbg0SmimyMFvY6RG9g/0/index/_6qd_Lucene70_0.dvm], Verdict '(null)', Task 'oas', Md5 <empty>, Sha256 <empty>, Type 0x0, Flags 0x1

Следующая строчка говорит о том, что исключить не удалось:

2021.02.10 15:28:11.030 3040    DBG     Path not excluded from scanning: /var/lib/elasticsearch/nodes/0/indices/cgjNKbg0SmimyMFvY6RG9g/0/index/_6qd_Lucene70_0.dvm

Справиться с данной ситуацией помогло создание новой политики на эту группу устройств.

Jenkins build server

На build server jenkins увеличилось время сборки yarn проектов, периодически начали падать сборки, так как разрешение зависимостей не укладывалось в таймаут. Временно решили через увеличение таймаутов yarn:

yarn install --network-timeout 1000000

В планах дорабатывать политику KCS.

Elasticsearch 

Elasticsearch очень сильно начал тормозить после включения kesl, что привело к падению pod kubernetes. Корень проблемы в том, что kesl пытается проверить каждый записываемый файл на диск, а эластик постоянно создает и перезаписывает файлы. В результате из-за больших задержек при записи в elastic начинают копиться очереди. В нашей архитектуре в elastic пишет rsyslog, который также начинал копить очередь, так как не мог отправить в elastic. Логи же с пода в rsyslog попадают через unix socket. Вот здесь и оказалось слабое место, видимо, когда rsyslog наполнял свою in memory очередь и переставал забирать сообщения из сокета, в определенный момент сокет переполнялся и под просто падал.

Донастроил rsyslog, чтобы очереди жили не только в in memory, но и могли переноситься на диск в случае переполнения. Кроме того, добавили папку с данными elastic в исключения политики KSC (об этом чуть выше написал). После этого работа elastic, rsyslog и микросервисов нормализовалась.

Kubernetes docker node

На kubernetes docker node антивирус запускается, но статус ключа Invalid black list. Пробовали переустановки, обновления — ничего не помогает. Такая ситуация на всех Kubernetes docker node, у нас их порядка 15.

Active key information:
    Expiration date                      : 2024-01-31
    Days remaining until expiration      : 1076
    Protection                           : No protection
    Updates                              : Update black list first
    Key status                           : Invalid black list
    License type                         : Commercial
    Usage restriction                    : 110
    Application name                     : Kaspersky Endpoint Security 11.1.0 for Linux
    Active key                           : 0000-000000-00000000
    Activation date                      : 2020-12-22
Additional key is not installed

Проблема пока не решена.

Заключение

На данный момент внедрение Антивируса Kaspersky продолжается. Коллеги из кибербезопасности ведут диалог с поддержкой Kaspersky по возникающим ошибкам. Нас перестали ускорять, так как остались самые важные и нагруженные узлы сервиса.