Katbert

Наблюдаю аналогичную проблему на одном из серверов с агентом версии 12a. Ничем особенным этот сервер от других не отличается, он не единственный в этой сети терминальный сервер на базе Win2008R2 с KSWS 10.1.2 Но на нем аналогичное событие спамит журнал Application каждые 6 часов

Я тоже заметил, что с некоторых пор поведение KSC изменилось. Сейчас наблюдаю статус “Устройство стало неуправляемым” у реально выключенного уже 3 дня компа. Ни по IP, ни даже по MAC-адресу он не доступен, и Intel AMT не используется. Похоже, примерно во времена KSC11 если этот статус присваивается - то не снимается до тех пор, пока агент не выйдет на связь, и сохраняется даже когда этот комп выключен.

Сегодня словил странный глюк на рабочем компе с Win8.1, на котором 3 дня назад установил KES 11.5. Во время удаленной работы вдруг потерял доступ к компу, с других машин локалки он тоже не пинговался. Изнутри комп не висел, можно было попытаться ввести пароль для входа в систему. Перезагрузка вернула комп в норму. Пока рано подозревать именно KES, но это первый такой глюк, хотя с марта удаленно использую этот комп в режиме 24x7, и таких отвалов сети не было ни разу. В логах KES и винды ничего интересного не нашел.

Я думаю, цепочка даже короче. Плагин KES11.1.1 основан на коде KES11.1.1, а KES11 напрочь несовместим с Win2003/XP. Если так уж хочется повозиться с напрочь неподдерживаемой связкой - можно установить консоль KSC 10.4 хотя бы на Win7, и уже туда установить плагин KES11.1.1. Но это может привести к еще более злым спецэффектам.

При установке на Win7 (которая из коробки имела только Framework 3.5) - инсталлятор KES 11.5 реально ставит Framework 4.6.1 И из-за этого установка на тестовой виртуалке заняла около 15 минут

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

Да, примерно так и оказалось. Отключил политику, и опытным путем определил - что при отключенных модулях Контроль программ и Адаптивный контроль аномалий - локальный статус не меняется (пишет Активных угроз не обнаружено, включено 12 задач из 14). А вот при отключенном модуле Сетевого экрана - статус меняется на “Безопасность может быть под угрозой” Но странно, что это сделали так неинформативно - логично было бы при клике по статусу получить ответ, что именно не так

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

А GUI теперь такой:

Также в системных требованиях теперь заявлен Framework 4.6.1, и его даже включили в дистрибутив KES 11.5 https://support.kaspersky.com/KESWin/11.5.0/ru-RU/127972.htm Однако при установке ручками на Win 8.1 с Framework 4.5.2 - инсталлятор KES никак на это не ругнулся, и в тихом режиме Framework тоже обновлять не стал. Возникает вопрос - в чем тогда заключается необходимость именно Framework 4.6.1, в каких случаях инсталлятор KES должен его установить, и чем грозит его отсутствие на машине?

Снова поменяли значок. После серебристого КЫ в версии 11.4, теперь будет зеленое. Цветовая дифференциация, однако 😄

В статье KB14306 предлагаются патчи для 10.1.0.622, в моем случае они не пригодны

Пока что на одном KSC открыл UDP-порт для KSN-прокси, и шквал ошибок от KSWS остановился. По поводу патча Core11 - не нашел его в статьях KB. Плохо искал или этот патч еще не выпущен официально?

Да, порт отключен Он по умолчанию отключен, и пока не было повода его включать

В настройках портов KSC есть дополнительный UDP-порт 15111 для KSN Proxy, но по умолчанию он отключен Возможно, Олег просветит - бага или фича, что KSWS пытается локально обращаться к KSN-прокси через по умолчанию закрытый UDP-порт.

В том-то и прикол, что все сервера под одной и той же политикой. И проблема только на самих KSC. Но ваш скрин натолкнул на мысль: на рядовых серверах в локальном интерфейсе KSWS 10.1.2 настройки выглядят так: Принято Положение о KSN: да Отправка данных о проверяемых файлах: да Отправка данных о запрашиваемых веб-адресах: да Отправлять статистику по событиям работы программы: да Интегрироваться с Kaspersky Managed Protection: нет Действия над зараженными и другими обнаруженными объектами: удалять Ограничение размера проверяемых объектов: не рассчитывать контрольную сумму для отправки в KSN, если размер файла превышает 2 МБ Использовать службу KSN Proxy: да Служба KSN: KSN (глобальный) Адреса KSN-прокси: 192.168.0.x : 13111 А у KSWS на машине с KSC - порт другой, хотя политика для KSWS единая на все сервера Принято Положение о KSN: да Отправка данных о проверяемых файлах: да Отправка данных о запрашиваемых веб-адресах: да Отправлять статистику по событиям работы программы: да Интегрироваться с Kaspersky Managed Protection: нет Действия над зараженными и другими обнаруженными объектами: удалять Ограничение размера проверяемых объектов: не рассчитывать контрольную сумму для отправки в KSN, если размер файла превышает 2 МБ Использовать службу KSN Proxy: да Служба KSN: KSN (глобальный) Адреса KSN-прокси: localhost : 15111

На трех никак не связанных серверах KSC 12a или 12_2 локально установлен KSWS 10.1.2 В политике KSWS приняты соглашения KSN, и сказано использовать KSC в качестве KSN Proxy Все сервера сети работают через KSN Proxy без проблем, а локально установленный на машине с KSC KSWS - не может, в событиях много таких: Не удалось отправить запрос в KSN. Проверьте настроенные параметры KSN Proxy. Код ошибки: 0x80000063. Имя объекта: C:\Windows\System32\ru-RU\profsvc.dll.mui

Ставлю патчи 12_2 на KSC, и бросилась в глаза странная картина. Есть 7 вариантов патча OSSL для машин с агентами 12a, причем машины с промежуточными версиями патчей OSSL включены и доступны, и нет видимых причин, почему бы им не обновиться до крайней версии OSSL Наблюдает ли кто подобное у себя?

Одной политикой тут не разрулить - если замок отрыт, то для машинки эта настройка не является принудительной. Но вполне можно выкрутиться профилями политики - это как вложенные политики, которые активирутся по некоторому критерию. Вопрос только в том, сможете ли выделить такой критерий

Инцидент открывал, но багом такое поведение не посчитали. Спорить не стал, т.к. к этому времени уже раздал патчи на проблемные машинки Разработчики сообщили что это ожидаемое поведение. KEA ставится отдельным пакетом (даже когда установку инициирует установщик KES, задачей изменения состава компонентов), и ее результат не возвращается задаче изменения компонентов. Проверить успешность установки KEA на хост можно по фактическому наличию его в списке приложений в свойствах хоста, отчете о версиях ПО или аналогичной выборке. INC000011866499

Видел такое из-за кривого назначения агентов обновления (они же точки распространения в KSC12). По умолчанию включено автоматическое назначение, и в качестве агента обновления может быть выбрана произвольная рабочая станция. И при обновлении с KSC - машина на самом деле пытается обновиться с агента обновления. Попробуйте отключить в свойствах сервера KSC \ Точки распространения

Не тот случай. Большиство моих KSC12 были свежими установками - т.к. переход на новый KSC совмещался с переходом на поддерживемые ОС (Win2008 R2 уже не годится для KSC12) Но посмотрел на одном KSC12, который обновлялся поверх. Там тоже свежие версии KES 11.3 и 11.4 - и там проблем с обновлениями тоже нет, стабильно 4.-5 мин Похоже, достаточно переехать на KSC12 и иметь свежие версии KES

Для тестирования EDR Optimum и Kaspersky Sandbox в сети KSC12.1 + KES11.4 потребовалось доустановить компонент KES - Endpoint Agent 3.9 Для этого в KSC создана задача изменения состава компонентов программы. Задача успешно отработала на всех машинах тестовой группы, но на двух из них Endpoint Agent 3.9 так и не появился. Это были машины с Win10 1903 без патчей с сентября 2019 г. Посмотрел на них локально в журнале событий Application - а там ошибка от MSIInstaller: Продукт: Kaspersky Endpoint Agent 3.9 — Обновление KB4528760 (https://support.microsoft.com/ru-RU/help/4528760/windows-10-update-kb4528760) или более новое не установлено. Это обновление устраняет уязвимость CVE-2020-0601 (https://portal.msrc.microsoft.com/en-us/security-guidance/advisory/CVE-2020-0601). Т.е. при ошибках установки - задача изменения компонентов считается выполненной успешно. На мой взгляд - это бага.

На втором объекте - KSC 11.2, к которому подключены только свежие KES 11.2 и 11.4, и KSWS 10.1.2. Плагинов тоже только два - для KES11.4 и KSWS 10.1.2, инсталл-пакеты не модифицированные KES 11.2 и 11.4, и KSWS 10.1.2. Задача загрузки обновлений выполняется около 5-7 минут, ошибки проверки подписи xml-файлов возникают очень редко. Вывод напрашивается - при использовании свежей версии KSC, к которому подключены свежие версии KES и KSWS, и не болтается лишних старых плагинов и инсталл-пакетов - нет проблемы с мучительно долгим обновлением баз

Сегодня появился повод проверить, что изменилось с весны. На двух разных объектах проверил логи задачи загрузки обновлений. Первый KSC10.5, к которому подключено много KES 11.1.1 и KSWS10.1.2, а также в незначительных количествах устаревшие версии KES 11.0.1, 11.0.0, 10.3.0, 10.2.6, 10.2.5, 8.1.0. На этом KSC есть только 2 инсталл-пакета - для KES10.2.6 и KES11.1.1 (с модифицированным по шаманству, описанному выше kpd-файлом), плагинов тоже много - KES 10.2.2, 10.2.4, 10.3.0, 8.1.0, 11.1.1 и KSWS 10.1.2 и 8.0.2. Задача загрузки обновлений выполняется 50 +/- 10 мин, ошибок ретрансляции нет, есть блуждающие ошибки проверки подписи файлов xml и dat