Как сделать сервер касперского подчиненным

Обновлено: 07.07.2024

Цель: ознакомиться с процессом подключения подчиненного Сервера администрирования, принципами и правилами наследования политики и задач Kaspersky Administration Kit , работой утилиты резервного копирования Сервера администрирования.

Программное обеспечение:

операционная система
- Microsoft Windows 2000 Professional Service Pack 2 или выше; Microsoft Internet Explorer версии 5.0 или выше
- Microsoft Windows XP Professional Service Pack 1 или выше
Для проведения данной лабораторной работы необходимо два компьютера, на которых установлен один часовой пояс и проведена синхронизация времени.

Содержание работы:
1. Ознакомиться с процессом подключения и управления подчиненным Сервером администрирования
2. Ознакомиться с процессом создания политик и задач, правилами их наследования
3. Ознакомиться с видами отчетов и событий в Kaspersky Administration Kit
4. Ознакомиться с работой утилиты резервного копирования
5. Выполнить задания к лабораторной работе
6. Защитить лабораторную работу, ответив на контрольные вопросы
Методические указания к лабораторной работе

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

Два Сервера администрирования считаются относящимися к одной логической сети , если либо один из них прямо или опосредованно (через цепочку последовательно подключенных друг другу Серверов администрирования) подключен к другому, либо если оба этих Сервера администрирования прямо или опосредованно подключены к одному Серверу администрирования. Все Сервера в логической сети , кроме одного, таким образом являются подчиненными Серверами администрирования.
Сервер администрирования, стоящий во главе иерархии, называется Главным Сервером администрирования
Структурированная совокупность всех компьютеров, прямо или опосредованно подключенных к произвольному Серверу администрирования в логической сети (не обязательно Главному) будет называться логической подсетью Сервера администрирования .

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

Узел Сервера администрирования

В панели обзора Консоли администрирования на верхнем уровне расположен элемент Kaspersky Administration Kit, который включает в себя все объекты, относящиеся к управлению логической сетью.

На первом уровне расположены узлы Серверов администрирования, а также узел Локальный компьютер, предназначенный для управления Антивирусом Касперского, установленным локально. В качестве имени каждого узла фигурирует адрес соответствующего Сервера администрирования. Если соединение с Сервером администрирования не установлено, напротив имени узла Сервера администрирования указывается статус Не подключен. Отсутствие статуса означает, что Консоль администрирования подключена к этому серверу.

По отношению к узлу Сервера администрирования доступны следующие действия (через контекстное меню или подменю Действие системного меню):
- Подключиться к Серверу администрирования - открывает окно ввода адреса Сервера администрирования, к которому требуется подключиться, полностью аналогичное тому, что отображается при добавлении нового Сервера администрирования. Если ввести адрес отличный от адреса текущего узла, и подключение пройдет успешно, то узел будет переименован в соответствии с новым адресом
- Отключиться от Сервера администрирования - прервать соединение с этим Сервером администрирования
- Мастер первоначальной настройки - запуск мастера первоначальной настройки на выбранном Сервере администрирования
- Мастер удаленной установки - запуск мастера удаленной установки продуктов Лаборатории Касперского на компьютеры в сети организации
- Найти компьютер - поиск компьютера с заданными свойствами в базе данных Сервера администрирования
- Вид - аналог подменю Вид в системном меню, содержит те же пункты (в меню Действие отсутствует)
- Удалить - удалить данный узел из панели обзора
- Экспортировать список - сохранить в формате txt или csv ( Coma Separated Values - значения, разделенные запятыми) содержимое панели результатов
- Свойства - открыть окно настроек Сервера администрирования
- Справка - вызов справочной системы
Добавление подчиненного Сервера администрирования

При выборе в контекстном меню контейнера Серверы одной из групп пунктов Создать и Сервер администрирования запускается мастер добавления Сервера администрирования. Следующим после приветствия окном мастера является окно выбора имени Сервера администрирования.

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

При указании адреса следует руководствоваться теми же правилами, что и при подключении консоли администрирования к Серверу администрирования: если на подключаемом Сервере администрирования используются нестандартные порты, порт для подключения следует прописать через двоеточие после адреса.

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

Если ранее был задан адрес подчиненного Сервера администрирования, то следующим шагом является настройка параметров главного Сервера администрирования, которые будут переданы подчиненному

При подключении подчиненного Сервера администрирования выполняются следующие действия:
1. Подключение подчиненного Сервера администрирования к главному - внесение в базу данных главного Сервера администрирования информации об имени, адресе (если задан) и сертификате подчиненного Сервера администрирования
2. Подключение к подчиненному Серверу администрирования - выполнение соединения с подчиненным Сервером администрирования используя заданные параметры
3. Настройка информации о главном Сервере администрирования для подчиненного - передача подчиненному Серверу администрирования информации об адресе, параметрах подключения и сертификате главного Сервера администрирования
Последние два действия будут выполнены, только если был указан адрес подчиненного Сервера администрирования. В противном случае их придется выполнять вручную на подключаемом Сервере.

По окончании всех действий мастер выводит окно, сигнализирующее о завершении добавления.

Добавленный Сервер администрирования отображается в контейнере Серверы со статусом Не подключен.

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

При объединении Серверов в иерархию необходимо, чтобы порт 13291 обоих Серверов был доступен. Порт 13291 необходим для приема подключений от Консоли администрирования к Серверу администрирования.

Подключение Сервера администрирования в качестве подчиненного к главному Серверу

Вы можете добавить Сервер администрирования в качестве подчиненного Сервера с подключением к главному Серверу по порту 13000. Вам потребуется устройство с установленной Консолью администрирования, с которого доступны порты TCP 13291 обоих Серверов администрирования: будущего главного Сервера и будущего подчиненного Сервера.

Чтобы добавить Сервер администрирования, доступный для подключения через Консоль, в качестве подчиненного Сервера, выполните следующие действия:
1. Убедитесь, что порт 13000 будущего главного Сервера доступен для приема подключений от подчиненных Серверов администрирования.
2. С помощью Консоли администрирования подключитесь к будущему главному Серверу администрирования.
3. Выберите группу администрирования, в которую вы планируете добавить подчиненный Сервер администрирования.
4. В рабочей области узла Сервер администрирования выбранной группы нажмите на ссылку Добавить подчиненный Сервер администрирования .
Запустится мастер добавления подчиненного Сервера администрирования.

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

Чтобы добавить Cервер администрирования, недоступный для подключения через Консоль, в качестве подчиненного Сервера, выполните следующие действия:
1. Убедитесь, что порт 13000 будущего главного Сервера доступен для подключения от подчиненных Серверов администрирования.
2. Запишите файл сертификата будущего главного Сервера администрирования на внешний носитель (например, USB-носитель) либо перешлите системному администратору того удаленного офиса, в котором находится Сервер администрирования.
Файл сертификата Сервера администрирования находится на Сервере администрирования по адресу %ALLUSERSPROFILE%\Application Data\KasperskyLab\adminkit\1093\cert\klserver.cer.

Файл сертификата Сервера администрирования находится на Сервере администрирования по адресу %ALLUSERSPROFILE%\Application Data\KasperskyLab\adminkit\1093\cert\klserver.cer.

Запустится мастер добавления подчиненного Сервера администрирования.

Поля ввода станут доступными для ввода и редактирования.

Подключение главного Сервера администрирования к подчиненному Серверу

Вы можете добавить новый Сервер администрирования в качестве подчиненного Сервера так, чтобы главный Сервер подключался к подчиненному Серверу по порту 13000. Это целесообразно, например, если вы размещаете подчиненный Сервер в демилитаризованной зоне.

Вам потребуется устройство с установленной Консолью администрирования, с которого доступны порты TCP 13291 обоих Серверов администрирования: будущего главного Сервера и будущего подчиненного Сервера.

Чтобы добавить новый Сервер администрирования в качестве подчиненного и подключить главный Сервер к нему по порту 13000, выполните следующие действия:
1. Убедитесь, что порт 13000 будущего подчиненного Сервера доступен для приема подключений от главного Сервера администрирования.
2. С помощью Консоли администрирования подключитесь к будущему главному Серверу администрирования.
3. Выберите группу администрирования, в которую вы планируете добавить подчиненный Сервер.
4. В рабочей области узла Серверы администрирования нужной группы администрирования нажмите на ссылку Добавить подчиненный сервер администрирования .
В основу интегрированного решения «Лаборатории Касперского» для защиты рабочих мест положены классическое EPP-решение Kaspersky Endpoint Security и EDR-комплекс Kaspersky Endpoint Detection and Response «Оптимальный». Единый агент для автоматической защиты от массовых угроз и расширенного противодействия сложным атакам облегчает управление инцидентами и минимизирует дополнительные затраты на обслуживание. В итоге обеспечивается сбалансированный подход к защите.

Сертификат AM Test Lab

Номер сертификата: 329

Дата выдачи: 17.02.2021

Срок действия: 17.02.2026

Введение

Ряд исследований, проведённых в 2019–2020 годах несколькими ведущими аналитическими центрами, показывает быстрый рост решений класса EDR и стойкий интерес к ним.

Так, например, компания IDC в своём отчёте «Безопасность рабочих мест в 2020 г.: возрождение EPP и предназначение EDR» сделала следующие выводы:
- Слабое решение класса EPP сводит на нет все преимущества EDR-решения.
- EDR-система должна анализировать данные, в том числе те, что находятся за пределами рабочих мест.
- Люди и время становятся новым показателем окупаемости EDR-решений.
По результатам исследования, проведённого «Лабораторией Касперского», в 2019 году доля фишинговых атак только в финансовом секторе по отношению ко всем зафиксированным случаям фишинга возросла с 44,7 % до 51,4 %. Также чаще стали подвергаться атакам субъекты критической информационной инфраструктуры (КИИ). Так, с начала 2020 года было выявлено более миллиарда атак только в отношении объектов КИИ.

По данным аналитического агентства Technavio, рынок средств класса EDR будет расти в течение 2020–2024 годов и увеличится на 7,67 млрд долларов США.

Исходя из исследований можно сделать выводы, что классические решения EPP и EDR по отдельности уже не всегда удовлетворяют потребности потенциальных заказчиков в привычном виде. Именно поэтому специалисты «Лаборатории Касперского» выработали решение по усилению уже внедрённой защиты конечных точек в целях противодействия сложным угрозам — KES + KEDR «Оптимальный» (рис. 1).

Рисунок 1. Усиленная защита конечных точек за счёт интеграции решений

Суть усиления и доработки заключается в использовании функциональности решений обоих классов через бесшовное взаимодействие посредством единого агента. Перечислим актуальные проблемы информационной безопасности, которые помогает решать такой подход:
- необходимость ручного разбора и анализа большого числа инцидентов;
- эксплуатация средств ИБ, которые не взаимодействуют друг с другом и управляются из разных консолей;
- принятие решений без использования средств для наглядного централизованного представления информации;
- выполнение сложных задач в условиях нехватки квалифицированных кадров и экспертизы;
- несоответствие требованиям регулирующих органов и действующего законодательства.
Ещё одним важным моментом и запросом на сегодняшний день является возможность не только внедрить сложное и широкофункциональное решение по обнаружению инцидентов и реагированию на них на конечных точках в больших организациях, но и надёжно защитить активы и бизнес-процессы независимо от уровня и размера организации, равно как и её зрелости в части ИБ (рис. 2).

Рисунок 2. Уровни зрелости организаций в части информационной безопасности

Решение, рассматриваемое в нашем обзоре, было разработано для организаций среднего уровня зрелости процессов ИБ. Создатели исходили из того, что для охвата потребностей такого предприятия или ведомства не требуется всех умений Kaspersky EDR: будет достаточно набора самых нужных функций с возможностью расширить его за счёт подключения дополнительных решений (рис. 3).

Рисунок 3. Различия между Kaspersky EDR «Оптимальный» и Kaspersky EDR

Далее в обзоре будет рассматриваться только Kaspersky EDR «Оптимальный». Начнём с функциональных возможностей.

Функциональные возможности «Kaspersky EDR для бизнеса Оптимальный»

Kaspersky EDR «Оптимальный» объединяет новейшие технологии защиты рабочих мест и гибкие инструменты контроля со средствами эффективного противодействия сложным атакам и повышения прозрачности инфраструктуры.

Отметим следующие аспекты функциональности решения:
- Управление функциями EPP и EDR из единой консоли.
- Автоматизированные средства реагирования на угрозы.
- Возможность проведения анализа первопричин (root-cause analysis).
- Интегрированные шифрование и патч-менеджмент.
- Формирование карточки инцидента: Kaspersky Endpoint Agent составляет подробную карточку с важными данными об инциденте на конечном устройстве. Карточка формируется в веб-консоли сервера администрирования на основе сигнала об обнаружении от совместимой EPP-программы Kaspersky.
- Возможность запустить цепочку ответных действий: создать правило запрета на запуск недоверенного объекта, выполнить поиск похожих инцидентов в группе устройств на основе выбранных индикаторов атаки (IoC), изолировать недоверенный объект, отсечь скомпрометированное конечное устройство от сети.
- Визуализация пути распространения атаки (attack spread path): для каждой заполненной карточки инцидента Kaspersky Endpoint Agent строит интерактивный граф, описывающий этапы развёртывания обнаруженной атаки во времени. Построенный граф содержит информацию о модулях, задействованных в атаке, и действиях, выполненных ими.
- Интеграция с решением Kaspersky Security Center Cloud Console в рамках функций Kaspersky EDR «Оптимальный».
Рисунок 4. Основные функциональные возможности KES + EDR

В целом подобная функциональность может встретиться в решениях классов EPP и EDR по отдельности, но в том и преимущество комплекса от «Лаборатории Касперского»: в легковесности, едином агенте и возможности гибко наращивать необходимую функциональность. Взглянем на его архитектуру.

Архитектура KES + EDR

В основу архитектуры решения положены привычные нам Kaspersky Security Center и Kaspersky Endpoint Security, что даёт гибкие возможности по интеграции в существующую инфраструктуру организации. Если говорить о месте в экосистеме продуктов, то стоит отметить тесную взаимосвязь и взаимозависимость между ними, что обеспечивает перекрёстный охват всех объектов сети.

Рисунок 5. Архитектура KES + EDR

Как видно по схеме выше, Kaspersky Security Center и Kaspersky Endpoint Agent являются обязательными компонентами, а Kaspersky Sandbox — вспомогательным.

Рисунок 6. Другие решения, в которых используется единый агент

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

Системные требования

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

Таблица 1. Аппаратные требования для Kaspersky Endpoint Agent

Для работы Kaspersky Endpoint Agent 3.9 в составе решения Kaspersky EDR «Оптимальный» требуется Kaspersky Security Center 12.1 или Kaspersky Security Center Cloud Console. Управление программой осуществляется через облачную или веб-консоль администрирования. Программа Kaspersky Endpoint Agent должна быть установлена в составе Kaspersky Endpoint Security 11 для Windows (версии 11.4 или 11.5) или Kaspersky Security 11 для Windows Server.

Таблица 2. Программные требования для Kaspersky Endpoint Agent

В целом предъявляемые системные требования — такие же, как и у решений Kaspersky Endpoint Security и Kaspersky Security Center, так что при наличии последних не потребуется выделять дополнительные ресурсы.

Сценарии использования KES + EDR

В наших сценариях мы будем использовать стенд в следующем составе:
- Kaspersky Security для рабочих станций и файловых серверов,
- Kaspersky Endpoint Agent,
- Kaspersky Security Center.
Процесс развёртывания рассматриваться не будет; о нём можно подробно узнать из официальной документации. Один из способов установки также описан в ранее выпущенной нами статье.

Подключимся к Kaspersky Security Center (рис. 7).

Рисунок 7. Авторизация в Kaspersky Security Center

После подключения перемещаемся в панель мониторинга Kaspersky Security Center с настраиваемой панелью и инструментами визуализации (рис. 8).

Рисунок 8. Панель мониторинга Kaspersky Security Center

Будут рассмотрены классические и часто используемые сценарии, но начнём мы с интересных возможностей, связанных с визуализацией цепочек развития угрозы (kill chain).

Построение цепочки развития угрозы в KES + EDR

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

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

Собираемые сведения отправляются в Kaspersky Security Center, где и происходит само построение.

Настройка правил, по которым формируются цепочки развития угрозы, выполняется в разделе управляемых устройств (рис. 9, 10, 11). Перед настройкой важно выполнить ряд предварительных условий (табл. 3). Также важно знать, что цепочка развития угрозы отображается в карточке инцидента.

Рисунок 9. Раздел «Управляемые устройства» в Kaspersky Security Center

После выбора управляемого устройства переходим в свойства и выбираем раздел «Параметры программы» → «Синхронизация с Сервером администрирования».

Рисунок 10. Настройка параметров Kaspersky Endpoint Agent

В параметрах синхронизации должно быть выбрано «Отправлять данные для построения цепочки развития угрозы».

Рисунок 11. Параметры синхронизации отправки данных для построения цепочки развития угрозы

Таблица 3. Предварительные условия для развития цепочки угроз

Благодаря произведённым настройкам у ИБ-администратора появляется возможность получить более наглядную и полную картину для принятия решения по событию и оперативно перевести последнее в статус инцидента.

Функциональность работы с цепочками развития угроз привлекательна, так как имеет низкий порог вхождения: на её основе даже не занимающийся ИБ профессионально специалист сможет разобраться в ситуации и принять решение на своём уровне. В расширенной же версии Kaspersky EDR присутствует возможность корреляции цепочки развития угроз с матрицей MITRE ATT&CK.

Работа с карточками инцидентов в KES + EDR

Ранее было отмечено, что всю необходимую информацию (ту же цепочку развития угрозы) можно найти в карточке инцидента. Но прежде чем добраться до неё и посмотреть, как она выглядит, разберём несколько моментов, позволяющих понять, где и в каких разделах Kaspersky Security Center находятся полезная информация и настройки KES + EDR.

Так, в интерфейсе Kaspersky Security Center отображаются политики KES + EDR (рис. 12). Они позволяют распространять на управляемые устройства с установленным Kaspersky Endpoint Agent политики в массовом формате.

Рисунок 12. Отображение политик KES + EDR в Kaspersky Security Center

Переключимся теперь на раздел со списком управляемых устройств (рис. 13). Находим здесь интересующее нас устройство и щелчком по нему переходим в его свойства.

Рисунок 13. Выбор управляемого устройства из списка в KES + EDR

В разделе общих свойств выбранного устройства (рис. 14) отображается информация по нему, включая текущие сеансы с его участием, а также доступна немаловажная функциональность, связанная с возможностью принудительно синхронизировать параметры и настройки устройства с сервером администрирования.

Рисунок 14. Общие свойства управляемого устройства в KES + EDR

Здесь нам кроме всего прочего доступна информация об установленных на управляемом узле программах. Всё это позволяет централизованно держать под контролем ситуацию с актуальной версией (рис. 15). На остальных вкладках доступны для просмотра данные о задачах, запускаемых на узле, событиях и инцидентах, а также дополнительные сведения.

Рисунок 15. Установленное программное обеспечение «Лаборатории Касперского» на подконтрольном управляемом устройстве в KES + EDR

Но самое интересное для ИБ-администратора — это, конечно же, события и инциденты, на основе которых он сможет принимать верные решения по дальнейшим действиям, а также оценивать уровень важности ситуации, держа всё под контролем. Для получения информации о событиях можно не только воспользоваться разделом в свойствах управляемого устройства (там будут видны только относящиеся конкретно к нему записи), но и в общем плане просмотреть все события через раздел отчётов. В последнем случае в главном окне веб-консоли KSC нажимаем на «Мониторинг и отчёты» → «Отчёты» и из списка в разделе «Подробнее» выбираем интересующее нас зафиксированное событие (рис. 16).

Рисунок 16. Выбор карточки инцидента из отчёта по событиям на управляемых узлах в KES + EDR

В итоге открывается карточка инцидента (рис. 17). Там собрана самая необходимая и важная для принятия решения информация:
- действие, предпринятое по отношению к обнаруженному исполняемому файлу / процессу;
- информация об управляемом устройстве (IP-адрес, ОС, наименование применяемой политики);
- дата обнаружения, полный путь до файла, хеш-сумма в разных форматах (данные, на основе которых можно создавать IoC);
- цепочка развития угрозы;
- кнопки действий по отношению к обнаруженному объекту (запретить, поместить в карантин).
Рисунок 17. Карточка инцидента в KES + EDR

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

Сетевая изоляция устройства и запрет на исполнение файлов на управляемом устройстве в KES + EDR

Удобной и полезной функцией является возможность изолировать на сетевом уровне подконтрольное устройство (рис. 18). Это важно при обнаружении потенциально вредоносных действий или подозрении на атаку (например, где-либо появилась троянская программа), поскольку за счёт изоляции можно пресечь распространение и переход атаки на другие устройства в корпоративной сети.

Сетевая изоляция включается в два щелчка из карточки инцидента. Для этого необходимо нажать на кнопку «Изолировать устройство» и подтвердить действие (при совершении таких операций надо чётко понимать, что в этом случае легитимный пользователь не сможет работать с сетевыми устройствами и службами, что при ложном срабатывании может вызвать негативную реакцию с его стороны, так что необходимо принимать решение об изоляции обдуманно). При этом в политике могут быть заданы исключения сетевой изоляции (есть ряд предварительно настроенных), которые позволяют оставить доступ к критически важным сервисам (в том числе сохранить связь между машиной и KSC).

Рисунок 18. Включение сетевой изоляции устройства, управляемого KES + EDR

Кроме возможности изолировать устройства, полезной функцией является удалённое создание правил по запрету запуска исполняемых файлов, офисных документов / PDF, скриптовых файлов или помещение в карантин для дальнейшего анализа в Kaspersky Sandbox, а также ручного анализа и передачи экспертам (рис. 19). Такой подход, несомненно, позволит гибко принимать решения и повысить надёжность и эффективность работы решения KES + EDR.

Рисунок 19. Включение правила, запрещающего исполнение файла на управляемых узлах, в KES + EDR

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

Рисунок 20. Список задач на управляемых узлах и других компонентах комплекса KES + EDR в Kaspersky Security Center

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

Выводы

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

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

KES + EDR позволяет получить наглядные данные о событиях из области безопасности, а также значительно улучшает обзор происходящего в инфраструктуре. С помощью этого комплекса можно не только обнаружить угрозу, но и определить её истинные происхождение и масштаб, а также оперативно среагировать на неё, минимизировав бизнес-потери. Базовые инструменты EDR включены в состав «Kaspersky EDR для бизнеса Оптимальный», а он, в свою очередь, полностью входит при этом в комплект поставки «Kaspersky Total Security Plus для бизнеса» (EDR + EPP).

В этой статье я хочу рассказать о трудностях, возникших при осуществлении процедуры, указанной в заголовке. Изначально стояла простая задача: Установить 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). Она решилась, но весьма странным образом и быстро.

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

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