Jump to content
Vadimon

Запрет запуска скриптов по расширению [В процессе]

Recommended Posts

В очередной раз сотрудник поймал шифровальщик. Анализ доступных мне двух экземпляров писем показал, что заражение происходит через почту, в которую вложен zip-архив внутри которого .js, .jse или ещё какой-нибудь скрипт. Этот скрипт уже и загружает все остальные зловреды. С момента выхода новой версии такого downloader-a до попадания в базы проходит несколько часов, в течение которых пользователь и успевает заразиться.

Обидно, что угроза, соответствующая простой логике - во вложении zip без пароля, внутри которого только файл с расширением скрипта - не обрабатывается даже крутыми почтовыми серверами, а написать самому такое правило фильтрации почты не представляется возможным. Но хотелось бы решить задачу просто - запретить пользователям запуск любых файлов с потенциально-опасными расширениями (bat, cmd, js, jse, vb, vbe, vbs, wsc, wsh, wsf, pif, scr), кроме как из доверенного расположения. Нашим пользователям запуск файлов с такими расширениями для работы никогда не понадобится. А подозрительные .exe даже в архиве с высокой вероятностью зарежет почта. Скрипты мы используем только для администрирования, поэтому они все находятся в сетевой папке, куда может записать только админ. В домене это удалось сделать через Политику ограниченного использования программ. Но есть недоменные машины, да и настройка таких ограничений через антивирус позволила бы узнать количество таких срабатываний через KSC, тогда как в случае с доменной политикой это существенно сложнее.

 

У нас KSC 10, KES 10.2.5. Беру машину без политики. Создаю в контроле запуска программ правило для блокировки скриптов. Указываю путь *.js, не выбирая конкретную папку или файл. В исключение ввожу папку с админскими скриптами, получается правило <имя папки>\*. Такое правило отлично справляется с описанной задачей.

Но я хочу распространить это правило через KSC. Там для этого приходится создавать группу программ. А для группы программ можно укзаать только правило для папки, а для файла - нельзя. В результате, если я создаю на сервере правило для папки *.js на клиенте оно превращается в *.js\*, которое не срабатывает на скрипты.

Пробовал экспериментировать указывая *.js для метаданных файла. Не удалось. В техподдержке сказали,

Блокировка по метаданным (в частности, по имени файла) осуществляется при наличии цифровой подписи у файла. Соответственно, блокировка файлов без цифровой подписи по метаданным невозможна.

Как бы так "обмануть" сервер касперского, чтобы на клиенты ушло правило вида *.js?

Share this post


Link to post
В очередной раз сотрудник поймал шифровальщик. Анализ доступных мне двух экземпляров писем показал, что заражение происходит через почту, в которую вложен zip-архив внутри которого .js, .jse или ещё какой-нибудь скрипт.

 

Можно включить автоматическое удаление скриптов с помощью фильтра вложений почтового антивируса. Для архивов ZIP, RAR, ARJ срабатывает.

Edited by Bingo

Share this post


Link to post
Добрый день.

 

Данный способ http://support.kaspersky.ru/10905 Вам не подходит?

 

post-196453-1476346863_thumb.jpg

 

Я убедился, что необходимая мне программа не находится в доверенной группе. Дальше что?

Share this post


Link to post
Добрый день.

 

Данный способ http://support.kaspersky.ru/10905 Вам не подходит?

Нет, в указанном способе необходимо каталогизировать программы по группам, затем постоянно поддерживать список доверенных программ в актуальном состоянии, а ПО постоянно обновляется, то браузеры, то плееры. Это стратегия "белого списка", которая мне не нравится.

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

Share this post


Link to post
Можно включить автоматическое удаление скриптов с помощью фильтра вложений почтового антивируса. Для архивов ZIP, RAR, ARJ срабатывает.

К несчастью, у нас веб-почта.

Share this post


Link to post
А мониторинг системы работал во время запуска впо?

Нет, мониторинг был отключен. До последнего времени я использовал только сканирование по базам и никаких проактивных и поведенческих анализаторов. Всё ради того, чтобы минимизировать число запущенных компонентов, особенно на слабых машинах, а также избежать любых ложных срабатываний, ведь каждое ложное срабатывание требует вмешательства администратора. Раньше этот подход себя оправдывал, но сейчас, когда мошенники тщательно готовятся и синхронно запускают вирусную атаку, чтобы успеть "накрыть" побольше жертв, пока вирус не попал в базы, этого недостаточно. Пока пытаюсь смоделировать в виртуалке поведение того же вируса при включенном мониторинге.

 

спасибо за ссылку, но там лишь подтверждение того, что KES умеет, а KSC пока этого не умеет.

Share this post


Link to post

Ну что же, некое решение проблемы всё-таки удалось мне найти. Напомню, имеем KSC 10, KES 10.2.5, домен, групповые политики.

1. Заходим в KES в контроль запуска программ, создаём правило Скрипты

2. Делаем Включающие условия - Добавить - Условие вручную - Путь к файлу или папке - *.cmd - OK

3. Повторяем для *.bat, *.ps1, *.js, *.jse , *.vb, *.vbe, *.vbs, *.wsc, *.wsh, *.wsf, *.pif, *.scr

post-166806-1476416732_thumb.png

4. Делаем Исключающие условия - Добавить - Условие вручную - Пусть к файлу или папке - C:\Program Files\* - OK

5. Аналогично для C:\Program Files (x86)\*, а также всех других доверенных расположений, где могут быть разрешенные к запуску скрипты, например, \\server\*

6. В пользователи и группы, получающие запрет - Все

post-166806-1476418898_thumb.png

7. Сохранить настройки

8. Запустить командную строку и выполнить

"C:\Program Files (x86)\Kaspersky Lab\Kaspersky Endpoint Security 10 for Windows SP1\avp.com" export EntAppControl c:\temp\EntAppControl.dat

При этом настройки контроля запуска программ будут сохранены в файл EntAppControl.dat. При необходимости корректируем путь к Program Files

post-166806-1476416929_thumb.png

9. В KSC открываем соответствующую политику, Контроль запуска программ. Включаем Контроль запуска программ, Блокируем контроль запуска программ, Разблокируем параметры контроля запуска программ.

post-166806-1476417175_thumb.png

10. В политике на вкладке интерфейс включем и блокируем пароль. Если пароль не установлен, импорт параметров будет невозможен.

11. Создаем скрипт EntAppControl.cmd

IF "%ProgramFiles(x86)%"=="" (
  "C:\Program Files\Kaspersky Lab\Kaspersky Endpoint Security 10 for Windows SP1\avp.com" import /login=KLAdmin /password=PASS \\FS\SHARE\EntAppControl.dat
) ELSE (
  "C:\Program Files (x86)\Kaspersky Lab\Kaspersky Endpoint Security 10 for Windows SP1\avp.com" import /login=KLAdmin /password=PASS \\FS\SHARE\EntAppControl.dat
)

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

12. Через GPO распространяем задание в планировщике на запуск скрипта, например, каждые 15 минут. При отсутствии GPO можно сделать в KSC задачу установки и сделать установочный пакет из одного скрипта.

post-166806-1476419284_thumb.png

post-166806-1476419290_thumb.png

post-166806-1476419294_thumb.png

post-166806-1476419298_thumb.png

 

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

Из минусов - пароль открытым текстом в файле, что несовместимо с вариантом, когда антивирус используется для контроля действий пользователя. Если стоит только задача защиты от основного метода распространения шифровальщиков - то это допустимо: даже если пользователь найдет скрипт, узнает пароль, введет его в программу, изменит настройки контроля запуска, то при очередном запуске скрипта настройки установятся обратно.

 

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

Edited by Vadim Dvorovenko

Share this post


Link to post
А мониторинг системы работал во время запуска впо?

Глубоко изучил вопрос возможностей мониторинга системы по защите от шифровальщиков - https://forum.kaspersky.com/index.php?showtopic=358963

Возможно, что мониторинга системы помог бы. А возможно, что и нет.

 

Share this post


Link to post
А возможно, что и нет.

 

Бывали и такие случаи

 

Share this post


Link to post

×
×
  • Create New...

Important Information

We use cookies to make your experience of our websites better. By using and further navigating this website you accept this. Detailed information about the use of cookies on this website is available by clicking on more information.