Kaspersky security center не удалось подключиться к серверу localhost

Обновлено: 07.07.2024

Как это ни странно, я нашёл на Хабре всего одну статью по данной тематике — и ту в песочнице и ~~сильно незаконченную~~ фактически содержащую в себе маленький кусочек чуть переделанной справки по продукту. Да и Google по запросу klakaut молчит.

Я не собираюсь рассказывать, как администрировать иерархию Kaspersky Security Center (далее по тексту KSC) из командной строки — мне это пока не понадобилось ни разу. Просто хочу поделиться некоторыми соображениями по поводу средств автоматизации с теми, кому это может понадобиться, и разберу один кейс, с которым мне пришлось столкнуться. Если тебе, %habrauser%, эта тема будет интересной — добро пожаловать под кат.

Исторически сложилось так, что в качестве средства антивирусной защиты на работе я предпочитаю продукты Лаборатории Касперского (далее ЛК). Причины и прочие священные войны личных мнений, пожалуй, оставим за кадром.

Естественно, хотелось бы централизованно развернуть, защитить, ~~оградить и не пущать~~ рисовать красивые графики, интегрироваться в существующие системы мониторинга и заниматься прочим перекладыванием работы с больной головы на здоровый сервер. И если с развёртыванием и защитой тут всё более или менее в порядке (у ЛК даже есть какие-то онлайн-курсы по продуктам), то с интеграцией уже сильно грустнее: в последней на текущий момент версии KSC 10.2.434 появилась интеграция аж с двумя SIEM: Arcsight и Qradar. На этом всё.

Для интеграции в что-то своё KSC предоставляет аж 2 интерфейса:

: в БД KSC есть ряд представлений с именами, начинающимися на «v_akpub_», из которых можно достать какую-то информацию о состоянии антивирусной защиты. : DCOM-объект, позволяющий скриптовать работу с KSC.

Минусы klakdb очевидны: чтобы напрямую обратиться к БД, нужно иметь к этой БД доступ, что приводит к необходимости лишних телодвижений по созданию правил доступа в межсетевых экранах, настройке прав доступа на серверах СУБД и прочему крайне неувлекательному времяпрепровождению. Ну и плюс мониторинг актуальности всех этих правил, естественно. Особенно интересно становится, когда имеется 20+ серверов — и все в разных филиалах, в каждом из которых свои администраторы.

klakaut в этом плане значительно более интересен: подключившись к корневому серверу иерархии, можно средствами самого KSC пройтись по оной иерархии и получить доступ ко всем нужным данным. Например, построить дерево серверов KSC с пометкой, кто из них живой, а кто нет, позапускать задачи, поперемещать компьютеры и вообще дать волю фантазии.

Минусы тоже есть, естественно: долго и сложно. Если нужно собрать какую-то статистику — нужно будет сначала долго писать скрипт, а потом долго ~~ловить баги~~ ждать, когда он отработает.

Естественно, никто не запрещает (по крайней мере, мне про это неизвестно) использовать оба механизма вместе: например, пройтись по иерархии серверов с помощью klakaut, получить полный список серверов KSC с информацией об используемых БД, а потом уже передать эту информацию в более другие средства автоматизации, которые удалят устаревшие правила из сетевых экранов, создадут новые, дадут разрешения на доступ и ~~принесут кофе в постель~~ отредактируют список источников данных в вашей системе мониторинга, которая, в свою очередь, опросит список и, обнаружив какие-нибудь девиации, с помощью klakaut сделает что-нибудь хорошее. Ну, или просто зарегистрирует инцидент в трекере. Тогда что-нибудь хорошее сделают администраторы в ручном режиме.

Воодушевлённый всеми этими соображениями, я написал свой первый скрипт:

И запустил его на сервере:

Если использовать js, эта ошибка не возникает. Интересно, почему.

Открыв консоль KSC, я убедился, что с правами у меня всё в порядке.

К сожалению, KSC не логирует неудачные попытки входа. Переписка с вендором показала, что логирование неудачных попыток входа можно включить (это была отдельная увлекательная история, которая, кстати, ещё не закончилась), однако данная конкретная попытка в логи всё равно попадать отказалась.

Казалось бы, можно сделать вот так:

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

Необходимо выставить в настройках COM, на вкладке Default Properties:
Default Authentication Level: Packet
Default Impersonation Level: Delegate

Эта инструкция заставила работать исходный скрипт, но показалась мне сомнительной в плане безопасности, поэтому я решил покопать чуть глубже. После некоторого времени поисков нашёлся добрый человек, который подсказал мне, как задать указанные уровни проверки подлинности и олицетворения для конкретного объекта, а не разрешать всем и всё сразу:

Вот так скрипт никаких ошибок выдавать не стал. Первый квест пройден.

Вообще в боевой среде неплохо бы проверять при вызове EnableImpersonation возвращаемое значение на предмет ошибок, а не перенаправлять его в никуда, как это сделал я.

Следующая задача: получить от KSC данные об используемой БД.

А вот тут всё сложно: документация о том, как это сделать, молчит. Исследование класса KlAkProxy ничего интересного не выявило, кроме параметра KLADMSRV_SERVER_HOSTNAME, который оказался идентификатором компьютера, на котором установлен KSC.

Перейдём тогда к компьютеру, для этого есть специальный класс KlAkHosts2. Для сокращения количества кода приведу только содержимое блока try:

Обратите внимание: переменная $Params, которую я использовал при подключении к KSC — экземпляр класса KlAkParams. А переменная $HostParams при, на мой взгляд, аналогичной функциональности, является экземпляром класса KlAkCollection. Почему используются разные классы — боюсь даже представить. Видимо, то, что SetAt принимает первым аргументом только целочисленные значения — очень принципиальный момент.

Данный код вернул значение «KSC», а значит, я на верном пути.

Метод GetHostInfo класса KlAkHosts2 достаточно хорошо задокументирован, но — не содержит нужной мне информации. Увы и ах. Зато есть метод GetHostSettings. Всё описание для которого сводится к следующему:

Давайте, заглянем внутрь:

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

Секция 85, судя по всему, отвечает за события и ныне нам неинтересна. А вот в 87 есть что-то, на что стоит обратить внимание:

Тут я воспользовался одним из предыдущих кейсов, где упоминалось, что нужные данные следует брать именно из KLSRV_CONNECTION_DATA (тогда я ещё не знал, что это вообще такое, просто отложилось).

Ну, вот, в общем-то, и всё. Данные об используемой БД получены. Квест пройден.

Наверное, ещё неплохо бы набросать скрипт для прохождения по иерархии серверов. Здесь ничего загадочного не оказалось, всё было вполне по документации. Я написал скрипт, который выбирает UID родителя, UID самого сервера, экземпляр СУБД и имя БД и выводит их в stdout через разделитель.

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

Естественно, чтобы превратить точку в актуальное имя сервера, придётся поколдовать с KlAkHosts2.GetHostInfo(), но это уже не столь страшно, просто ещё сколько-то кода.

Техподдержка ЛК, естественно, пугала меня тем, что структура SS_SETTINGS в следующих релизах KSC может поменяться, поэтому так лучше не делать. К сожалению, даже мой внутренний перфекционист считает, что скрипт нельзя просто написать и забыть: при смене версии используемого ПО его по-любому придётся тестировать и отлаживать. Так что пока пользуемся тем, что есть, а проблемы будем решать по мере поступления, благо, техника уже отработана.

Продолжаем цикл статей о Kaspersky Security Center.

Сегодня речь пойдет об одной специфичной проблеме, которая может возникнуть при администрировании KSC.

Дело в том, что периодически сервер Kaspersky Security Center может терять связь с рабочими станциями. Происходить это может из-за сбоя в работе Агента администрирования.

В таком случае можно наблюдать следующую картину:

Как видим, на одном из компьютеров на функционирует Агент администрирования Kaspersky Security Center. Такой компьютер не будет получать обновлений через групповые задачи и не будет предоставлять отчеты серверу KSC.

Как правило, проблема спонтанно появляется и также спонтанно исчезает (как я уже говорил, Kaspersky Security Center таит в себе множество багов). Причина здесь в том, что корни проблемы лежат в службе Агента администрирования. А потому проблема уходит с перезагрузкой компьютера и, как правило, остается незамеченной.

В таком случае стоит открыть службы, которые есть в операционной системе (способ одинаково подходит как для серверных, так и для десктопных ОС), и найти службу Агент администрирования Kaspersky Security Center.

Скорее всего, Вы увидите что служба вполне себе исправно работает. Не верьте этому утверждению. Откройте свойства службы и нажмите сперва кнопку Остановить, а затем Запустить.

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

Если переустанавливался сервер администрирования Kaspersky Security Center

Другое дело, если была выполнена переустановка сервера администрирования KSC с сохранением базы данных. В таком случае можно наблюдать массовое появление статуса, что Агент администрирования не функционирует. Даже если имя сервера и IP-адрес не менялись. Насколько мне известно, проблема кроется в сертификате сервера администрирования, который меняется после переустановки.

Обратите внимание, что установка должна проходить от учетной записи, обладающей правами локального администратора на клиентских машинах.

Как выполнить подключение к серверу администрирования (СА)?

Если во время процесса у вас возникают проблемы и затруднения, то необходимо тщательно искать причину. Желательно при этом отслеживать неисправность на каждом этапе отдельно.

Задание адреса и параметров подключения

При этом компьютер выполняет установку соединения с сервером, а на мониторе отображаются следующие сведения.

Неправильное имя, введенное в строку «Адрес сервера» localhost. При этом DNS-сервер работает неверно.
Не открыт порт TCP 14000 на СА при подключении. Подобная проблема возникает с выключением функции «Использовать SSL-соединение».
Отсутствие запуска службы Kaspersky Lab Administration Server.
Связь с СА осуществляется посредством прокси-сервера, однако параметры соединения не указаны. Для устранения проблемы необходимо нажать кнопку «Дополнительно» и прописать недостающие сведения.
С выключенной опцией «Использовать SL-соединение» порт TCP-13000 не открыт.
Применение нестандартных портов для подключения консоли. Для решения проблемы в строке «Адрес сервера» прописываются значения в следующем виде «Имя сервера:порт».

Проверка подлинности

Если при указании адреса и параметров подключения вы применили опцию «Использовать SL-соединение», то затем следует подобрать значения проверки подлинности СА консолью. Базой операции служит сертификат, создаваемый в момент установки обеспечения. Поэтому выберите параметр «Подключиться к серверу администрирования» и получите его.

При повторном всплывании окна пропишите путь к сертификату с помощью кнопки «Выбрать». Файл klserver.cer находится в папке Cert каталога установки KSC Administration Kit.

Проверка прав учетной записи пользователя

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

Администраторы домена (при установке сервера на домене);
KLAdmins (при полном доступе);
KLOperators (при установке сервера на контроллере домена);
администраторы компьютера (при полном доступе);
все пользователи и группы, указанные в разделе «Безопасность» вкладки «Свойства»;
KLOperators (если сервер расположен на компьютере рабочей группы или рядовой);
KLAdmins (при полном доступе).

В этой статье я хочу рассказать о трудностях, возникших при осуществлении процедуры, указанной в заголовке. Изначально стояла простая задача: Установить KSC 11 вместо 10 версии. Но, поскольку вместе с KSC на сервере работают еще и другие программы, а также он является по совместительству еще и файловым сервером, решено было организовать отдельный виртуальный сервер для KSC. Также, еще захотелось перенести все настройки и данные, полученные KSC за время своей работы со старого сервера на новый, чтобы не вносить эти данные потом вручную.

Предстоящую задачу можно разделить на несколько этапов:

1. Создание нового виртуального сервера

Был создан виртуальный сервер со следующими параметрами: 4 ядерный процессора, 16 Гб RAM,

Сразу скажу, что установка KSC версии 11 на новом сервере и импорт на него всех настроек с версии 10.2.434e не увенчались успехом. Поэтому было решено на новом сервере установить все необходимые для работы KSC программы тех же версий, что и на старом сервере. Собственно, была поставлена MySQL 2008, как и на старом сервере, чтобы исключить возможные ошибки при импорте данных в БД.

2. Установка Microsoft SQL Server 2008

Сразу скажу, что установку MySQL Server лучше начинать после того, как вы уже создали всех необходимых локальных пользователей на сервере и ввели его в домен (в том случае, если в сети у вас работает доменная структура и особенно, если одна из ее политик удаляет локальные учетные записи администраторов и добавляет доменную(ые) учетную(ые) запись(и)). Почему? Потому, что в первый раз я сделал иначе, чем написал и возникла проблема при установке KSC на этапе проверке соединения с базой данных. Появлялась ошибка, говорящая о недостаточных полномочиях пользователя для доступа к БД . Хотя были перепробованы все возможные пользователи с правами администратора и настройки авторизации, но соединиться с БД так и не удалось. В итоге пришлось удалить Microsoft SQL Server 2008 и поставить его заново, с теми же настройками, с какими я устанавливал его в первый раз. В итоге, при установке KSC соединение с БД прошло успешно.

Во время установки Microsoft SQL Server 2008 необходимо использовать те же настройки (название БД, пути), как и в Microsoft SQL Server 2008 на старом сервере, иначе возникнут проблемы при импорте данных.

3. Установка KSC 10.2.434c с пререквизитами, обновление до 10.2.434e

Для работы KSC также потребуется компонент MSXML для работы с XML-данными. Его необходимо поставить до установки KSC, учитывая также разрядность ОС (32 или 64 бита). Дистрибутив можно найти на сайте Microsoft. После этого можно приступать к установке KSC 10.2.434.

И здесь будут поджидать две неприятности:

- не удалось обнаружить инсталляционный пакет Microsoft SQL Server 2008 R2 Express S2
- не удалось обнаружить инсталляционный пакет MSXML 4.0

Это независимо от того, установлены эти программы у вас в системе, или нет. KSC нужны их дистрибутивы, чтобы все равно предложить их установку.

Первая неприятность поджидает, если выбрать тип установки «полная» или «обычная», поэтому необходимо выбрать тип установки «выборочная», тогда KSC не затребует дистрибутив MsSQL Server.

Чтобы победить вторую, нужно создать папку msxml в общей папке дистрибутива KSC 10.2.434 - KSC_10.2.434c и поместить туда файл msxml4-KB973685-enu. Именно по пути ..\KSC_10.2.434c\MSXML\msxml4-KB973685-enu KSC ищет дистрибутив MSXML. Путь, названия папок, версия MSXML актуальны для KSC_10.2.434c. После этой манипуляции установка пройдет успешно.

Обновление установленной KSC 10.2.434c до 10.2.434e.

Очень важно, чтобы и на старом сервере и на новом версии KSC ПОЛНОСТЬЮ совпадали. Просмотр информации о версии в «Справка -> о программе» не дает всей полноты информации о версии. О том, что что-то не так я узнал тогда, когда пытался восстановить данные на новом сервере и их восстановление не происходило из-за такой ошибки, говорящей о том, что версия ПО на которое я импортирую сохраненные данные старше чем версия ПО, с которого эти данные были экспортированы. Информация о версия на новом и старом сервере говорила о версии 10.2.434 в обоих случаях. Мое внимание привлек некий патч, находившийся в папке с именем patch_10_2_434_server_e, который я поспешил поставить. После чего импортирование данных прошло успешно. Стало очевидно, что этот патч стоял на и старом сервере.

Но, прежде чем начать импортирование данных, важно сделать еще одну вещь:

4. Сохранение новых сертификатов, сгенерированных KSC 10.2.434 после его установки

Дело в том, что функция экспорта данных и настроек сохраняет в резервной копии много разнообразных файлов, в т.ч. и сертификаты, которые генерирует KSC во время своей установки. И нет никакой возможности сделать выборочное экспортирование данных. Можно лишь экспортировать отдельно сертификаты, либо все данные, включая и сертификаты.

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

5. Резервирование информации на старом сервере и восстановлениее ее на новом

После сохранения сертификатов на новом KSC-сервере можно заняться сохранением данных на старом KSC-сервере и восстановлением ее на новом. Делается это все при помощи той же утилиты.

После импортирования данных KSC на новом сервере делаем импортирование сертификатов, которые мы сохраняли на предыдущем шаге. Пробуем запустить KSC. Если все хорошо, то переходим к его обновлению.

6. Обновление KSC 10.2.434e на новом сервере до 11 версии

Обновление проводим, запустив дистрибутив 11-версии. Обновление проходит без ошибок. Отмечу, что у меня и на этом шаге случилась проблема. После обновления KSC категорически отказался соединяться со своим сервером (127.0.0.1). Она решилась, но весьма странным образом и быстро.

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

Читайте также: