Katbert

В явном виде - нет. Есть уведомления по email, sms и запуском исполняемого файла. Последний вариант можно использовать косвенно - если есть exe-файл или скрипт, который умеет слать в telegram - то только так.

Нет. Если пользователь через контекстное меню значка KES сделает "приостановить" - то со стороны KSC можно остановить и запустить защиту. После запуска значок так и остается серым. Ничего не изменилось

Наблюдаю тайм-аут задачи установки агента - 2 ч. По факту установка отработала за пару минут, но исталлятор запросил перезагрузку, и служба агента не была запущена

Обновление поверх с KSC 13.2 прошло без проблем. Затем стал обновлять агенты - из первой партии из 12 машин на двух - задача установки слишком долго висит в стадии "Запущена установка". Стал смотреть логи - на обоих машинах нашлось событие от MsiInstaller: "Продукт: Агент администрирования Kaspersky Security Center. Требуется перезагрузка. После установки или обновления продукта требуется перезагрузка, чтобы все изменения вступили в силу. Перезагрузка будет выполнена позже." Абыдна, одна из машин, возжелавших перезагрузки после установки агента - это сервер. Придется перезагружать к ночи

Да, вижу что в системных требованиях KSC14 для агента официально заявлена только WinXP. Про Win2003 скромно умалчивают, хотя серверный антивирус KSWS11 официально поддерживает Win2003. Было бы логично, чтобы и агенты официально поддерживали его. Про родственные ОС - имел в виду, что обе основаны на ядре версии 5.

Предыдущий агент 13.2 тоже работал на WinXP. А на Win2003, который принципиально от WinXP не отличается - были проблемы. В одной из сетей все машины с WinXP работают с агентом 13.2, а сервера Win2003 пришлось откатить до 13.0. Интересно, полечили или нет в 14.0 работу агента на Win2003?

Вопрос решили организационно - админ главного сервера временно отключил свою политику, я импортировал старые политики и сделал их неактивными. После этого политику главного сервера снова включили, но на неактивные политики она уже не влияет

В итоге, после коллективного обсуждения, красивого технического решения не нашли. Посмотреть поведение в веб-консоли - оказалось, что в ней вообще нет функционала экспорта/импорта политик Попробовать импортировать скиптом klakaut - но там или нет такой функции, или не осилил Использовать сохранение флага активности/неактивности политики при экспорте: если политика была неактивная при экспорте, то и при импорте она будет неактивной. Но вручную отредактировать файл klp, чтобы превратить активную политику в неактивную - тоже не вышло

Жил-был сервер KSC 13.0, и стал он подчиненным сервером. Вышестоящая политика затоптала местные настройки, но перед созданием иерархии был сделан экспорт политик в файлы *.klp Если создать новую пустую политику и сразу сделать ее неактивной - то параметры с главного сервера не затаптывают настройки, все замочки открыты. Но если импортировать старую политики из файла - то она принудительно становится активной, и настройки меняются. Есть ли способ импортировать политику, без автоматического назначения ее активной?

После обновления плагина с 11.9 до 11.10 потребовалось перепринять соглашение об использовании KSN

Возможно, этот пакет по умолчанию ставится в профиль запустившего пользователя, а агент работаете от localsystem. Нужно проверить, куда будет ставиться пакет, если ручками запустить. Иногда есть ключи командной строки, чтобы пакет установился не в профиль текущего пользователя, а для всех (в program files)

Вариант с подключением по имени kcs.domain.ru годный, только нужно перенести сертификат со старого сервера на новый, раз уж планируется ставить новый сервер с нуля. Для переноса сертификата нужно воспользоваться утилитой klbackup, у нее есть режим "бекапить только сертификат"

И ещё бяку вижу - диагностика правил веб-контроля в локальном интерфейсе kes не проверяет категорию сайта. Например, создано единственное правило для запрета соцсетей по категории. Если в диагностику правил вбить vk.com - то она покажет, что доступ будет предоставлен по правилу по умолчанию. Если же в диагностике в явном виде указать категорию соцсети - то она покажет, что созданное блокирующее правило сработает. Насколько помню, раньше диагностика могла проверить категорию по доменному имени (что логично и ожидаемо)

по доступности сайта cloud.mail.ru, который должен блокироваться категорией файлообменники. И блокируется, когда в правиле оставил только 2 категории

В результате - при попытке обращения к vk.com будет блокировка, а cloud.mail.ru откроется. Если уменьшить список категорий - оставить только социальные сети и файловые обменники - то будут заблокированы оба сайта. Напрашивается вывод - что KES некорректно кушает большой список категорий, и игнорирует часть правил

Второе правило блокирует все возможные категории, которые есть в KES:

Похоже, уперлись в багу веб-контроля KES 11.9. Если создать правило блокировки всех возможных категорий сайтов - то весь список категорий не обрабатывается. Создаем два правила - первое будет поименно разрешать доступ к конкретным сайтам (белый список)

Security Center в большинстве случаев не требует лицензию. Она нужна для управления мобильными устройствами и для функциональности System Management в Расширенной лицензию. Чтобы просто управлять Kes на рабочих станциях - достаточно KSC без лицензии Чтобы из KSC управлять защитой - на каждой рабочей станции кроме kes должен быть установлен агент администрирования. Если агенты усьановлены, но не могут подключить к серверу - о причинах расскажет утилита klnagchk.exe, она находится в той же папке, куда был установлен агент

Да, это была известная проблема в 13.1, она исправлена в 13.2

Создавал запрос в СА по этому же вопросу. Ответили так: Так что продолжаем ждать. Кому сильно нужно - заводите новые вопросы в СА, можно со ссылкой на мой INC000014061230. Возможно, количество запросов повлияет на сроки

Исходя из этой логике - в первом поле пишем domain.com, MX-lookup переключаем в положение Enable. И на DNS-сервере, к которому обращается KSMG, должны быть прописаны mx-записи для domain.com с учетом приоритетов (чтобы был основной и резервный SMTP-сервер)

И если в первом поле было прописано domain.com, то можно было включить поиск MX-записей для этого домена:

Посмотрел, как эти настройки выглядели в интерфейсе KSMG 1.2. Там были контекстные подсказки, которые здорово помогали в настройке. В KSMG 2.0 их зачем-то выпилили. В поле Destiantion address можно было писать так:

Вторую неделю веду вялую переписку с СА по этому же вопросу, INC000013926559. Пока что посоветовали использовать пересылку с галкой про поиск MX-записей (и уже на DNS-сервере прописать основной и резервный почтовик с разными MX-приоритетами). Но похоже в интерфейсе KSMG есть бага - если включаю поиск MX-записей - то не дает сохранить настройки без заполнения поля Хост. Хотя как я понимаю, это взаимоисключающие вещи: либо пересылаем на статически заданный хост, либо ищем хосты через DNS

Проверка веб-трафика и почты теперь тоже не доступна со Стандартным ключом: