Продолжаем цикл статей о противодействии классу вирусов-шифровальщиков в корпоративной среде. В предыдущих частях мы рассмотрели настройку защиты на файловых серверах с помощью FSRM и использования теневых снимков дисков для быстрого восстановления данных после атаки. Сегодня речь пойдет о способе предотвращения запуска исполняемых файлов вирусов-шифровальщиков (в том числе обычных вирусов и троянов) на ПК пользователей.
Помимо антивируса, еще одним барьером для предотвращения запуска вредоносного ПО на компьютерах пользователей могут быть политики ограниченного использования программ. В среде Windows это могут быть технология Software Restriction Policies или AppLocker. Мы рассмотрим пример использования Software Restriction Policies для защиты от вирусов.
Software Restriction Policies (SRP) предоставляют возможность разрешать или запрещать запуск исполняемых файлов с помощью локальной или доменной групповой политики. Метод защиты от вирусов и шифровальщиков с помощью SRP предполагает запрет запуска файлов из определенных каталогов в пользовательском окружении, в которые, как правило, попадают файлы или архивы с вирусом. В подавляющем большинстве случаев файлы с вирусом, полученные из интернета или из электронный почты оказываются внутри каталога %APPDATA% профиля пользователя (в нем же находится папки %Temp% и Temporary Internet Files). В этом же каталоге хранятся распакованные временные копии архивов, когда пользователь не глядя открывает архив полученный по почте или скачанный с интернета.
При настройке SRP могут быть использованы две стратегии:
- Разрешить запуск исполняемых файлов на компьютере только из определенных папок (как правило, это каталоги %Windir% и Program Files / Program Files x86) – это самый надежный метод, но требует длительного периода отладки и выявления нужного ПО, которое не работает в такой конфигурации
- Запрет запуска исполняемых файлов из пользовательских каталогов, в которых в принципе не должно быть исполняемых файлов. Именно в этих каталогах в большинстве случаев оказываются файлы вируса при появлении на компьютере. Кроме того, у пользователя, не обладающего правами администратора, просто отсутствуют права на запись в каталоги системы кроме своих собственных. Поэтому вирус просто не сможет поместить свое тело куда-либо кроме директорий в профиле пользователя.
Мы рассмотрим создание SRP по второму варианту, как достаточно надежному и менее трудоемкому во внедрении. Итак, создадим политику, блокирующую запуск файлов по определенным путям. На локальном компьютере это можно сделать с помощью консоли gpedit.msc, если политика должна использоваться в домене, нужно в консоли Group Policy Management (gpmc.msc) создать новую политику и назначить ее на OU с компьютерами пользователей.
В консоли редактора GPO перейдите в раздел Computer Configuration -> Windows Settings -> Security Settings . Щелкните ПКМ по Software Restriction Policies и выберите New Software Restriction Policies.
Выберите раздел Additional Rules, и создайте новое правило New Path Rule.
Создадим правило, запрещающее запуск исполняемых файлов с расширением *.exe из каталога %AppData%. Укажите следующие параметры правила:
- Path: %AppData%\*.exe
- Security Level: Disallowed
- Description: Блокировка запуска exe файлов из папки %AppData%
Аналогичным образом нужно создать запрещающие правила для путей, перечисленных в таблице. Т.к. переменные окружения и пути в Windows 2003/XP и Windows Vista/выше отличаются, в таблице указаны значения для соответствующих версий ОС. Если у вас в домене еще остались Windows 2003/XP, для них лучше создать отдельную политики и назначить ее на OU с компьютерами с использованием WMI фильтра GPO по типу ОС.
Описание | Windows XP и 2003 | Windows Vista/7/8/10, Windows Server 2008/2012 |
Запрет запуска файлов из %LocalAppData% | %UserProfile%Local Settings*.exe | %LocalAppData%\*.exe |
Запрет запуска файлов из вложенных каталогов %AppData%: | %AppData%\*\*.exe | %AppData%\*\*.exe |
Запрет запуска файлов из вложенных каталогов %LocalAppData% | %UserProfile%\Local Settings\*\*.exe | %LocalAppData%\*\*.exe |
Запрет запуска exe файлов из архивов, открытых с помощью WinRAR | %UserProfile%\Local Settings\Temp\Rar*\*.exe | %LocalAppData%\Temp\Rar*\*.exe |
Запрет запуска exe файлов из архивов, открытых с помощью 7zip | %UserProfile%\Local Settings\Temp\7z*\*.exe | %LocalAppData%\Temp\7z*\*.exe |
Запрет запуска exe файлов из архивов, открытых с помощью WinZip | %UserProfile%\Local Settings\Temp\wz*\*.exe | %LocalAppData%\Temp\wz*\*.exe |
Запрет запуска exe файлов из архивов, открытых с помощью встроенного архиватора Windows | %UserProfile%\Local Settings\Temp\*.zip\*.exe | %LocalAppData%\Temp\*.zip\*.exe |
Запрет запуска exe файлов из каталога %temp% | %Temp%\*.exe | %Temp%\*.exe |
Запрет запуска exe файлов из вложенных каталогов %temp% | %Temp%\*\*.exe | %Temp%\*\*.exe |
Опционально. Запрет запуска exe фалов из любых каталогов в профиле пользователя . Важно. с эти правилом нужно быть внимательным, т.к. некоторое ПО, например плагины браузеров, установщики – хранят свои исполняемые файлы в профиле. Для таких программ нужно будет сделать правило исключения SRP | %UserProfile%\*\*.exe | UserProfile%\*\*.exe |
Вы можете добавить собственные каталоги. В нашем примере получился примерно такой список запрещающих правил SRP.
Как правило, также следует запретить запуск других расширений потенциально опасных файлов (*.bat,*.vbs, *.js, *.wsh и т.п.), ведь вредоносный код может находиться не только в *.exe файлах. Для этого нужно изменить пути в правилах SPR , удалив вхождения *.exe. Таким образом, будет запрещен запуск всех исполняемых файлов и файлов сценариев в указанных каталогах. Список «опасных» расширений файлов задается в параметрах политики SRP в разделе Designated File Types. Как вы видите, в нем уже есть предустановленный список расширений исполняемых файлов и скриптов. Можете добавить или удалить определенные расширения.
Осталось проверить действие политики Software Restriction Policies на клиентском компьютере. Для этого обновите политики командой gpupdate /force и попробуйте запустить исполняемый *.exe файл из любого из указанных каталогов. Должно появиться сообщение об ошибке:
Попытки запуска исполняемых файлов из защищенных каталогов, которые были блокированы политиками SRP можно отслеживать с помощью журнала событий Windows. Интересующие нас события находятся в разделе Application, и имеют Event ID 866, с источником SoftwareRestrictionPolicies и примерно таким текстом:
Итак, мы показали общий пример техники использования политики ограниченного использования программ (SRP или Applocker) для блокировки вирусов, шифровальщиков и троянов на компьютерах пользователей. Рассматриваемая методик позволяет существенно усилить степень защиты систем от запуска вредоносного кода пользователями.
Угу. Все красиво.
А нет ли способа заполнить/добавить Additional Rules более эффективно чем тупым тыканием мышки в GUI gpedit.msc ? Импорт/экспорт, средство редактирования .pol ?
можно, но админы так не делают, админ должен знать все применяемые правила чтобы потом не искать в куче экспортированных чужих наборов правил причину неработоспособности системы в целом
И в чем противоречие? Да, я хочу сам заполнить правила, но … я против тупого «кликанья мышкой» и copy-paste одних и тех же строк с незначительными изменениями (другое расширение, в данном случае).
При установке данных скриптов, если ПК в домене, SRP-политика активируется автоматически.
Если хотите применить политику на недоменном ПК, просто выполните команду ImportSRP после установки скриптов.
https://sites.google.com/site/smkuzmin/home/scripts?authuser=0
На самом деле хороший вопрос. Средств для импорта/экспорта нет. Теоретически на локальной машине все правила хранятся в реестре HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\safer, но у каждого правила есть уникальный ID. И как потом их перенести в домен — не понятно.
Наверно вместо SRP стоит переключится на Applocker, он также умеет блокировать запуск исполняемых файлов по пути, но в отличии от SRP поддерживает экспорт/импорт настроек.
Попробовал выяснить можно ли через PowerShell … и тут облом. Средства для работы с GPO есть, но крайне ограниченные.
В частности так и не нашел даже того, что можно хоть как-то «притянуть за уши» к набивке SRP.
Импорт вполне возможен из reg-файлов на недоменных ПК. На доменных ПК импортированные политики будут просто перезаписаны доменными политиками — это не вызовет никаких ошибок.
При установке данных скриптов, если ПК в домене, SRP-политика активируется автоматически.
Если хотите применить политику на недоменном ПК, просто выполните команду ImportSRP после установки скриптов.
https://sites.google.com/site/smkuzmin/home/scripts?authuser=0
а про CryptoPrevent что нить можете рассказать?
Судя по описанию CryptoPrevent является по сути надстройкой над той же самой SRP политикой ограничения использования программ Windows + какой-то функционал антивируса с обновлением сигнатур из некой базы
Более того, завялено, что он меняет локальные политики (если компьютер не доменны), а на самом деле работает как «вещь в себе». Установил на тестовую машинку, прогнал его настройки, в политиках … ничего не поменялось. В реестр не полез, лень было. Автор вопрос об этом, ответил так:
Alex
― Ноябрь 2, 2016 — 7:43 дп
Прочитал, что CryptoPrevent работает с политиками.
Поставил для теста на виртуалку с 7-кой. Применил все по Default.
Затем запустил gpedit.msc и … в Software Restriction Policies не нашел ничего. Как-то странно…
Валерий
― Ноябрь 2, 2016 — 7:04 пп
Alex, программа работает. Пример блокировки da-vinchi-code вируса, приведен в статье. После включения блокировки просканируйте компьютер программой FRST, она все покажет.
Возможно она работает через AppLocker, либо еще есть такая штука — множественные локальные политики (MLGPO — Multiple Local Group Policy Objects), когда на одном компьютере для разных учетных записей и групп можно создавать собственные локальные политики.
Возможно. Будет не лень, снова подниму еще раз виртуалку и проверю. Старую тестовую грохнул уже 🙂
Tckb elfkbnm вхождения *.exe, то у пользователей перестает запускаться IE и проводник, которые на панели задач, при этом ссылки на ворд, эксель — работают.
Как добавить в исключения?, а то не получилось че-то с ходу, добавил путь к ярлыку\Проводник. lnk и не захотел все равно работать.
Попробуй создать разрешительные правила для путей %LocalAppData%\Roaming\Microsoft\Internet Explorer\Quick Launch и
%LocalAppData%\Roaming\Microsoft\Windows\Start Menu
В этом случае блокируются не только файлы из списка Designated File Types + блокируется запуск для всех подкаталогов.
Пример: Правило на запрет запуска из %UserProfile%\
В результате exe установщик запущенный из разрешенного каталога отваливается с пояснением:
AttemptedPath C:\Users\Users\AppData\Local\Temp\is-NI5T1.tmp\Win32DiskImager-0.9.5-install.tmp
RulePath C:\Users\Users\
почему «удалив exe» ?
%UserProfile%\*\*.exe — хорошее правило, но есть ли правило для распространения еще и на подкаталоги или просто самому добавлять : %UserProfile%\*\*\*\*\*\*\*\*\*\*.exe
Вот это, кстати, очень хороший вопрос. Тоже ищу на него ответ.
мне предложили указать так %TEMP%\**\*.exe
Еще для Оперы надо добавить правило разрешающее.
Но, интереснее процесс установки программ. Если не все, то очень многие инсталяторы используют каталог %LocalAppData%\Temp\, а здесь как раз по-умолчанию все запрещено…
С обновлением программ возможны сюрпризы…
Подтверждаю сюрпризы, установка Microsoft Office вылетает с ошибкой. Проверил при снятых ограничениях. При установке офиса, в каталоге %Temp%\ создается несколько файлов ose*.exe.
Только с Microsoft Office? Были еще «сюрпризы»? Как обошли?
пользовательский Хром там даже живет)
Полно. В темр летит очень много во время инсталяции. Выход — временно для этого хоста запрет снимать.
Поддерживаю ! Нашёл кто-нить решение ?
Решил заблокировать Bad Rabbit по хеш? Но в окне Windows 10 и в Windows Server 2016 только кнопка Browse…/Обзор… и не дает вставить именно хеш файла.
По хэшу умеет блокировать только Applocker
почему политику SRP применяете на компьютер, а не на пользователя? Ведь на ПК работают еще например службы, под другими учетными записями, в результате можем получить, что службы (система) может быть ограничена этой политикой
Почему вы решили, что такие службы потенциально не могут быть причиной заражения? Правильно применять такие политики именно к компьютеру, а не пользователю. Если есть службы, на ПК, запущенные под другой учетной записью (на самом деле это не всегда хорошо, особенно если у этой записи есть права администратора), то нужно правильно настроить исключения.
Видимо потому, что если на службы действуют ограничения, тогда требуется более тонкая настройка. А так-же нет возможности простым способом исключить ряд пользователей, входящих не ПК из действия политики.
ИМХО все-таки правильнее делать SRP исключения на уровне пути к программе / расширения файла.
Покажите как выглядит пример исключения к вашему списку запрещающих. Спасибо.
это я к тому что в моей политике Исключение для одной прг не хочет работать. Запрещено и все тут.((
to Eugene 06.06.2018
В каком формате вы указываете путь к программе-исключению?
Например %AppData%\ ссылается на папку C:\Users\username\AppData\Roaming. Поэтому для разрешения запуска программы C:\Users\username\AppData\Roaming\some.exe нужно сделать правило %AppData%\some.exe — Unrestricted
%AppData%\UpdateLog\*.exe
важно какого вида сама политика по умолчанию: Запрещающая и Разрешающая. В зависимости от этого обрабатываются внесенные в нее правила.
Категорически не рекомендуется, по понятным причинам, прописывать разрешения через переменные среды.
При создании политик создаются два правила по умолчанию:
— %HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SystemRoot%
— %HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\ProgramFilesDir%
Для минимума общих путей ним желательно добавить для x86:
%HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\CommonFilesDir%
а для х64:
%HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\CommonFilesDir (x86)%
%HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\CommonW6432Dir%
%HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\ProgramFilesDir (x86)%
%HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\ProgramW6432Dir%
Правила для пользователя это путь в реестре:
[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders]
для компьютера
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders]
Пример правила для примочки от Google Chrome (software_reporter_tool.exe)
%HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders\Local AppData%Google/Chrome/User Data/SwReporter/*/software_reporter_tool.exe
Тут после указания ключа реестра для пользователя и значения пользовательского расположения «Local AppData», дальше в пути до исполняемого файла или библиотеки обычный «\» слэш меняется на обратный «/».
Полезно так же при тестировании правил желательно включить логирование запретов c указанием пути к лог-файлу:
reg add «HKLM\SOFTWARE\Policies\Microsoft\Windows\Safer\CodeIdentifiers» /v LogFileName /t REG_SZ /d «<Путь к LOG-файлу>» /f
Это особенно полезно, если включено блокирование библиотечных файлов.
Как-то так. Если данная информация уже оговаривалась, прошу извинения за дублирование.
Прописал политку %Temp%\
Залил в него exe
Как запускался, так и запускается
gpupdate /force делал, никакой реакции
при этом если ставить %AppData%\ перестает запускать и офис, и даже powershell (windows server 2012 r2)
Как заблочить запуск exe во всех вложенных каталогах? %USERPROFILE%\**\*.exe — не работает.
Пробовал настроить SRP — отказался от этой идеи, слишком много исключений делать надо, т.е. — всё как всегда — идея отличная, реализация хромает.
Каждый раз при перезагрузке Software Restriction Policies постоянно сбрасываются. И даже во время текущей сессии когда всё настрою, например, из програм файл можно, с десктопа нельзя, то всё равно программы запускаются как хотят: стоит запустить одну программу из програм файл и потом её копия с десктопа тоже запускается.
Вот прям правила в GPO очищаются? Речь, как я понимаю о локальной политике?
Что именно вы настраивали?
Да, иногда после перезагрузки настроенный Software Restriction Policies полностью сбрасывается и выглядит как на первом скриншоте в статье (нужно заново жать ПКМ и выбирать New…, заново настраивать). Но кажется, это приколы Windows 10 1709. Я перепроверил на ХР, там всё работает как надо, и описанных мною проблем нет.
Похоже на глюк именно вашей системы, или какой-то софт, или инсайд у вас сбрасывает настройки политик.
Кстати, не пробовали через applicker правила создавать? Они тоже сбрасываются?
С учётом многочисленных комментарием и противоречий в них, хочу попросить пояснить — если настроить всё по статье то нормальная работоспособность ПК гарантируется? Или офисные приложения например перестанут запускаться, программы перестанут устанавливаться и т.д..
SRP довольно мощная штука, но требует тонкой настройки, чтобы обеспечить баланс между безопаностью и удобством. Если у вас не достаточно скилов администратора — не беритесь за натройку ограничивающей политике. Статья всего лиш верхнеуровневый рецепт — как вы его будете варить в своей инфраструктуре, зависит от вас.
SRP у меня не работает с сетевыми дисками. что может быть не так.
software restriction policy не поддерживают сетевые диски. Насколько я знаю, лучше указывать UNC путь: \\server1\share\file.exe
Прошу помощи.
Создаю запрещающую политику для пользователей, применяю ее на ou. Политика не применяется. Если делать на ПК, то проблем нет, но нужно именно на группу или на пользователя.
Не могу понять в чем проблема.
iam, политика должна быть привязана к нужным OU и распространяться на группу пользователей (или отдельных).
В том и дело. Сам gpo связана с корнем домена, применяется на группу домена в которой есть пользователи.
Вернее должен применяться, но нифига. Уже отключал политику для пк, толку нет. В логах все ок. Права у пользователей нужные есть.