Обнаружены активные угрозы kaspersky security center как удалить
Как это ни странно, я нашёл на Хабре всего одну статью по данной тематике — и ту в песочнице и сильно незаконченную фактически содержащую в себе маленький кусочек чуть переделанной справки по продукту. Да и 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 Endpoint Security 10 c KSC 10.2.434, а это порядка 180 машин, на которых работает KES v10.3.3.275, v10.2.6.3733 (MR4), v10.2.5.3201 и другие версии KES 10.
Обратил внимание, что антивирусные базы KES 10.2.6.3733 перестали обновляться, неважно из какого источника – интернета или хранилища KSC. Индикатор прогресса обновления на насколько секунды может остановиться на отметке 6%, а затем резко отобразить 95%. При этом объём загруженных данных не превышает 200 КБ. Результат – «базы сильно устарели». Обновления для антивирусных баз, загружаемые через Kaspersky Update Utility 3.2.0.153 в папку, открытую для общего доступа, также не обнаруживаются.
Такой проблемы нет с KES 10 других версий. Проблема возникает только после установки обновления MR4, т.е. после обновления до версии 10.2.6.3733. Удаление и повторная переустановка антивируса любых версий KES 10 на проблемной машине не помогает. Единственное решение – переход на KES 11, но нас это пока не устраивает.
Журнал обновлений прилагаю.
P.S. Судя по отзывам, подобная проблема существует и у других пользователей, однако решения со стороны Касперского так и не предложено.
Доброго времени суток!
Прошу помощи с отключением самозащиты, или полным удалением продукта.
История такова: умер сервер с Server 2003 sp2 x32 + KES 10 sp1 mr2 (10.2.6.3733), с установленной на нем очень древней, и очень нужной программой, которую по ряду причин нельзя перетащить на другую систему. Система была перетянута в hyper-V, успешно стартует, но при запуске просто удаляет все драйвера от виртуальной машины. Т.е. драйвера определяются при запуске, и тут же удаляются. При попытке обновить конфигурацию оборудования, определяются повторно, работают корректно, при попытке удалить-обновить пишут что действие неприменимо к устройству, которое находится в состоянии удаления. После перезагрузки, все начинается заново. Кроме того, процесс services.exe на полную нагружает одно ядро.
Ситуация кардинально меняется при снятии галочки самозащиты. Все устройства волшебным образом сами определяются, и сохраняют это состояние при перезагрузке, никакой загрузки процессора, все прекрасно, НО перестает пускать по RDP. Дело не в закрытом порте, я попадаю в сеанс (но в логах пусто, попытка подключения вообще никак не регистрируется, даже в безопасности), и моментально меня выкидывает с ошибкой "Ваш сеанс со службами удаленных рабочих столов завершен, возможно, по одной из следующих причин: Администратор завершил этот сеанс, произошла ошибка при установке подключения, возникла сетевая проблема".
При этом, возврат галочки самозащиты на место, с перезагрузкой и без, не исправляет ситуацию, помогает только откат к контрольной точке hyper-v.
Попытка полностью удалить продукт, и через штатный деинсталлятор, и через фирменную утилиту, вызывает ту-же ошибку RDP.
Попытка накатить сверху другую версию, заканчивается ошибкой установки klif.sys, откатом инсталлятора, и ошибкой RDP.
Контроль устройств не установлен, да и вообще все компоненты, включая сетевой экран выключены, программа работает локально, без политики, да и попытка накатить политики, и снять самозащиту через сервер администрирования заканчивается аналогичным локальному результатом.
Попытка удалить службу терминалов, и подключаться просто в режиме удаленного доступа, ситуацию никак не исправляет, у сервера две роли, терминальная и файловая. доступ по SMB прекрасно работает.
chksdk и sfc /scannow не помогают. Брандмауэр выключен.
Подскажите, куда копать?
Доброго времени суток. Постараюсь описать свою проблему. Стоял у нас на сервере KSC10. На рабочих машинах стояли версии анивирусаа KES10.2.1.23 и KES11. всё работало идеально, был контроль над всеми машинами, задачи по обновлению баз выполнялись без ошибок.
Произошло чп с сервером, на котором стоял ksc10. После устранения проблемы, пришлось всё переставлять заново. Было решено поставить 11-ю версию KSC. С этого момента ничего не работает. KSC не находит плагин управления, вирусные базы не обновляются, на часть машин не хочет ставиться агент администрирования.
С агентами худо-бедно проблема решилась, но вот обновляться ничего категорически не хочет. C ПК на которых установлен KES11 проблем почти нет, а вот там где стоит KES10 базы устарели и не хотят обновляться даже вручную на самом пк. как можно решит эту проблему? скачивал с офф сайта плагины управления kes10 - не помогает
После удаления KES 11 в реестре остались разделы и ключи c названием LEGACY_KLBACKUPDISK
удалить с помощью прав локального администратора невозможно, прописать свою учетку локального админа в разрешения тоже не дает.
как удалить этот раздел ?
Читайте также: