-
Похожий контент
-
Автор cringemachine
Добрый день.
Существует ли функциональная возможность ограничить права главного сервера в отношении подчиненного? Например, чтобы администратор безопасности при подключении к подчиненному серверу из консоли главного сервера мог просматривать только вкладку Управляемые устройства и Лицензии Лаборатории Касперского?
Поделитесь знаниями, пожалуйста.
-
Автор infobez_bez
Здравствуйте!
Я настраиваю политику карантина для устройств под управлением Windows в KSC. При переносе устройства в эту политику у него должна блокироваться вся сетевая активность, кроме связи с сервером администрирования.
Проблема:
-В политике для Linux есть опция «Всегда добавлять разрешающее правило для портов агента администрирования», но в политике для Windows такой настройки нет.
-Я пробовал добавлять сервер администрирования в доверенные узлы, но при этом разрешались и другие локальные службы, а нужно, чтобы работала только связь с KSC.
-Также пытался вручную прописать правила в сетевом экране для портов агента (например, 13000, 14000 TCP/UDP), но это не сработало — устройство теряло связь с сервером.
Вопрос:
Как правильно настроить политику карантина для Windows, чтобы:
-Устройство имело доступ только к серверу администрирования KSC.
-Все остальные сетевые соединения (включая локальные службы) блокировались.
-Устройство могло получать обновления политик (например, при выходе из карантина).
-Нужна ли дополнительная настройка сетевого экрана или есть скрытые параметры, аналогичные функционалу для Linux?
KSC 14.2
-
Автор KL FC Bot
Постоянный доступ в Интернет и мобильная связь привычны, как электричество, и мы уже плохо представляем, как жили без них раньше. Но представьте себе ситуацию, когда мобильного Интернета или сотовой связи нет, а вам нужно оставаться на связи с друзьями поблизости. Например, в самолете вашу компанию рассадили по разным концам салона, а вы собирались во время полета обсудить дальнейшие планы поездки. Или на музыкальном фестивале Интернет еле дышит, вокруг громко, но договориться, когда идти на мейн, все-таки нужно.
Тут на помощь могут прийти децентрализованные p2p- (peer-to-peer) или mesh-мессенджеры, позволяющие связать множество устройств в единую mesh-сеть через Bluetooth или Wi-Fi Direct.
В 2010-е годы с появлением Wi-Fi Direct подобные мессенджеры, с одной стороны, наделали много шума, а с другой, — не получили особого распространения: непонятно было, для чего и где их использовать. Странная замена рации, менее дальнобойной и более энергозависимой, не стала популярной среди пользователей смартфонов. Тем не менее по сей день подобные мессенджеры живы, поддерживаются разработчиками и даже появляются новые разработки.
Меж тем, у этих мессенджеров есть важная ниша: они позволяют оставаться на связи в ситуациях природных катаклизмов, координировать работу поисковых групп или просто общаться с соседями по дому или даче при сбоях мобильной связи или Интернета. Для этих и других подобных случаев не идеально, но подойдут децентрализованные мессенджеры, которые не требуют подключения к Интернету.
Так что, если перед задуманным походом вам не доставят заказанные рации, вы можете попробовать воспользоваться mesh-мессенджерами как запасным вариантом.
Как работают p2p-мессенджеры?
Принцип работы подобных мессенджеров основан на децентрализованных mesh-сетях, где каждое устройство одновременно является и клиентом, и ретранслятором. Из множества клиентских устройств строится распределенная сеть, каждый участник которой может служить мостом для передачи сообщений дальше.
Представьте, что ваш смартфон превращается в мини-рацию, которая может передавать сообщения другим таким же устройствам с нужным приложением поблизости. Если вы хотите отправить сообщение, оно будет «прыгать» через смартфоны других пользователей приложения, пока не дойдет до адресата. При этом промежуточные устройства не смогут прочитать сообщение — для связующих узлов оно будет зашифровано.
Устройства связываются между собой напрямую с использованием либо Bluetooth, либо Wi-Fi Direct.
View the full article
-
Автор DeniTornado
Доброго всем!
Коллеги, а кто-нибудь использует KES на своих RDS серверах? Все нормально с работой серверов?
Дано:
- несколько RDS на Windows Server 2019
- на них установлен KES 12.1.0.506
Проблема:
Вот уже в течении нескольких дней подряд наблюдаю утром проблему пока только на RDS (на остальных серверах пока все нормально - служебные серверы для определенных целей). То один сервер, то второй, то третий - утром когда все пользователи заходят на свои рабочие столы (почти все у нас работают на терминальных серверах со своих тонких клиентов), зайти не могут! Сервер тупо не отвечает на запросы. RDSы - это виртуальные машины на Hyper-V. Приходится через консоль Hyper-V перезагружать виртуалку и тогда она или после первой перезагрузки или после второй начинает пускать пользователей.
Самое интересное что в логах ни чего такого, что указало бы на проблему. ТП в собранных логах ни чего криминального не видит
До установки KES такого не было ни когда! Раньше пользовались другим известным антивирусом вообще не знали таких симптомов и проблем.
Есть у кого схожие проблемы на RDS?
И еще такой вопрос: на RDS серверах я использую скрытый режим работы KES - в настройках политики для RDSов отключил интерфейс. Не за чем пользователям его видеть в трее Windows. Но при такой настройке становится недоступна проверка из контекстного меню WIndows файлов на вирусы - эти менюшки серые и их не нажать. Можно как-то и скрыть KES, но при этом и функция проверки из контекстного меню была доступна?
-
Автор Anivas
Доброго времени суток.
Перестал подключатся Kaspersky Secure Connection к серверам через мобильны интернет. Выдает ошибку (скрин ниже). Подскажите, пожалуйста, что сделать.
-
Рекомендуемые сообщения
Пожалуйста, войдите, чтобы комментировать
Вы сможете оставить комментарий после входа в
Войти