Проверьте настройки конфиденциальности Facebook ПРЯМО СЕЙЧАС
Автор
KL FC Bot
в Новости и события из мира информационной безопасности
-
Похожий контент
-
Автор -Александр-
Coreport.txreport.txtreport.txttllectionLog-2025.08.08-09.22.zip
-
Автор Олег Андрианов
Добрый день!
Уже вторую неделю бьюсь с настройкой связки KSC и KES под Astra Linux. Основная проблема обновление баз с KSC - оно отказывается идти.
Есть изолированная сеть с ~20 компьютеров. Домена, DNS, интернета - нет. На одном из компьютеров (работает под Astra Linux Воронеж) установлены две сетевые карты. Одна смотрит внутрь этой сети, другая имеет доступ в интернет. На этом же компьютере установлен KSC. Задача - получать обновления из интернета и распространять их на компьютеры (тоже работают под ASTRA Linux внутри изолированной сети.
Все настройки проверены и перепроверены многократно. Коннект с агентами есть. Данные сервер с рабочих станций получает. Обновление не идёт.
Внутри этой сети есть старый комп с Windows 10 и KES. Переключил агента на KSC под Astra Linux - обновления пошли
На компьютере где установлен KSC также установлен KES и также отказывается обновляться.
На всех АРМ стоит ASTRA Linux 1.7 в версии Воронеж.
Готов предоставить любые дополнительные данные.
Не понимаю в какую сторону смотреть.
-
Автор infobez_bez
Здравствуйте!
Я настраиваю политику карантина для устройств под управлением Windows в KSC. При переносе устройства в эту политику у него должна блокироваться вся сетевая активность, кроме связи с сервером администрирования.
Проблема:
-В политике для Linux есть опция «Всегда добавлять разрешающее правило для портов агента администрирования», но в политике для Windows такой настройки нет.
-Я пробовал добавлять сервер администрирования в доверенные узлы, но при этом разрешались и другие локальные службы, а нужно, чтобы работала только связь с KSC.
-Также пытался вручную прописать правила в сетевом экране для портов агента (например, 13000, 14000 TCP/UDP), но это не сработало — устройство теряло связь с сервером.
Вопрос:
Как правильно настроить политику карантина для Windows, чтобы:
-Устройство имело доступ только к серверу администрирования KSC.
-Все остальные сетевые соединения (включая локальные службы) блокировались.
-Устройство могло получать обновления политик (например, при выходе из карантина).
-Нужна ли дополнительная настройка сетевого экрана или есть скрытые параметры, аналогичные функционалу для Linux?
KSC 14.2
-
Автор andrew75
Если у вас есть лицензия на Kaspersky Secure Connection, то вы можете настроить VPN подключение в Linux к серверу KSC.
Сначала нам нужно получить файл конфигурации для подключения к OVPN-серверу.
1. Заходим в свой аккаунт на My Kaspersky, идем на вкладку "Безопасное соединение" и нажимаем кнопку "Создать конфигурацию".
2. Выбираем протокол OpenVPN и нажимаем "Продолжить".
3. Выбираем локацию. Можно выбрать только одну. Если захотите поменять, то нужно будет пересоздать конфигурацию. При этом предыдущая будет деактивирована. То есть использовать одновременно несколько локаций нельзя.
Нажимаем кнопку "Продолжить".
4. Теперь скачиваем файл конфигурации. Он называется credentials.ovpn
Не забываем сохранить логин и пароль для подключения. Больше их вам не покажут. Если забыли сохранить, то придется пересоздавать конфигурацию.
Теперь настроим OVPN подключение c использованием этой конфигурации на Linux
Рассмотрим на примере Linux Mint 22.1
Весь необходимый софт уже установлен в системе по умолчанию, поэтому ничего доустанавливать не надо.
1. В трее нажимаем на иконку "Менеджер сетей" и выбираем "Параметры сети".
2. Добавляем новое VPN подключение.
3. Выбираем "Импортировать из файла"
4. Находим наш файл конфигурации (credentials.ovpn) и нажимаем "Открыть".
5. На вкладке "Идентификатор" меняем при желании имя соединения (по умолчанию будет credentials), вводим сохраненные логин и пароль и нажимаем "Добавить". Никаких других настроек менять не надо.
6. В результате мы создали новое соединение VPN Kaspersky.
7. Идем в "Менеджер сетей" и нажимаем движок "Подключить".
8. Соединение установлено.
9. Проверяем. Германия, Франкфурт.
Как видите, все достаточно просто.
Напоминаю. Использовать можно только одну локацию. Если нужна другая, то нужно создать новую конфигурацию OVPN. При этом старая конфигурация будет деактивирована.
-
Автор KL FC Bot
Сразу после католического Рождества стало известно о многоэтапной атаке на разработчиков популярных расширений Google Chrome. Самой известной целью по иронии судьбы стало ИБ-расширение от компании Cyberhaven, скомпрометированное прямо перед праздниками (о таких рисках мы предупреждали). По мере расследования инцидента список пополнился как минимум 35 популярными расширениями с суммарным числом установок 2,5 млн копий. Целью злоумышленников является похищение данных из браузеров пользователей, которые установили троянизированные обновления расширений. В ходе данной кампании преступники фокусировались на похищении учетных данных от сервисов Meta* с целью компрометации чужих бизнес-аккаунтов и запуска своей рекламы за чужой счет. Но, в теории, вредоносные расширения позволяют похищать и другие данные из браузера. Рассказываем о том, как устроена атака и какие меры принять для защиты на разных ее этапах.
Атака на разработчиков: злоупотребление OAuth
Чтобы внедрить троянскую функциональность в популярные расширения Chrome, преступники разработали оригинальную систему фишинга. Они рассылают разработчикам письма, замаскированные под стандартные оповещения Google о том, что расширение нарушает политики Chrome Web Store и его описание необходимо скорректировать. Текст и верстка сообщения хорошо мимикрируют под типовые аналогичные письма Google, поэтому для жертвы письмо выглядит убедительно. Более того, во многих случаях письмо отправляется с домена, специально зарегистрированного для атаки на конкретное расширение и содержащего название расширения прямо в имени домена.
Клик по ссылке в письме приводит на легитимную страницу аутентификации Google. Пройдя ее, разработчик видит еще один стандартный экран Google, предлагающий авторизоваться по OAuth в приложении Privacy Policy Extension и в рамках входа в это приложение дать ему определенные права. Эта стандартная процедура проходит на легитимных страницах Google, только приложение Privacy Policy Extension запрашивает права на публикацию расширений в Web Store. Если разработчик дает такое разрешение, то авторы Privacy Policy Extension получают возможность публикации обновлений в Web Store от лица жертвы.
В данном случае атакующие не крадут пароль и другие реквизиты доступа разработчика, не обходят MFA. Они просто злоупотребляют системой Google по делегированию прав, чтобы выманить у разработчика разрешение на обновление его расширения. Судя по длинному списку зарегистрированных злоумышленниками доменов, они пытались атаковать гораздо больше, чем 35 расширений. В тех случаях, когда атака проходила успешно, они выпускали обновленную версию расширения, добавляя в него два файла, ответственные за кражу куки-файлов и других данных Facebook** (worker.js и content.js).
View the full article
-
Рекомендуемые сообщения
Пожалуйста, войдите, чтобы комментировать
Вы сможете оставить комментарий после входа в
Войти