Шифровальщики вымогатели и SRP
 

У нас сегодня в очередной раз одна из сотрудниц получила письмо счастья, замаскированное под деловую переписку с zip-архивом внутри, в архиве файл .js. Ну она не придумала ничего лучше, чем запустить это, несмотря на то, что я лично несколько месяцев назад после первого за несколько лет подобного инцидента обходил всех сотрудников, объясняя что вот именно так делать не надо, как отличить нормальный документ от замаскированного зловреда, и чем грозит, если наплевать на бдительность. Не помогли ни объяснения, ни ограниченная учетка, ни "антивирус" MSE.
Так вот, что думаете насчет идеи прописать в SRP запрещающее правило для пути "*.js", чтобы рубануть начисто возможность запуска этого типа вируса? Я не стал делать этого сразу, потому что не уверен, не появятся ли проблемы у всяких бухгалтеров с их браузерами, расширениями, клиентами, платежками и пр.?

а мы, конечно же, можем ответить на этот вопрос, ведь все мы знаем какие у вас
=)
да?

dislike, может какие идеи сможете подсмотреть в этой теме форума safezone.cc?

Основной вопрос был не этот, а

И второй вопрос, подразумевается: "Какие потенциально проблемы могут возникнуть в связи с этим правилом у пользователей, особенно у бухгалтеров, с которыми вы возможно сталкивались на своем опыте?

Идея запретить только .js — отрицательно, потому что blacklisting не решает проблем. Blacklisting столь же бесполезен, как "ходить и объяснять".

https://blog.windowsnt.lv/2015/11/25...ion-framework/
Скоро докину шестую часть.

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

Может и не решает всех проблем, но по крайней мере не порождает огромное число новых. Чтобы правильно настроить белый список, надо садиться за каждый компьютер и несколько дней за ним работать, проверяя, всё ли нормально запускается, всё ли корректно отрабатывает во всех сценариях. Ладно бы компы были все одинаковые, с одинаковой версией и битностью ОС, с одинаковым и неизменным набором софта, но это далеко не так. Неизбежно будут ошибки, раздражение сотрудников и т.д. Имхо, слишком сложно и не оправданно.

Насколько мне известно, SRP хреновенько работает с файлами из system32.
В интернетах говорят, что MS в курсе проблемы.
Например mshta.exe, который по сути есть упаковка для скрипта, невозможно заблокировать средствами AppLocker.
Однако SRP и AppLocker не одно и то же.

Хех. А если этих человеков более трёх тысяч?
На вашем месте я бы смотрел в сторону стороннего вендора. (шёпотом-) KIS
Там очень гибко настраиваются блокировки по белым/чёрным спискам.

А че с ними работать? У пользователя нет прав на запись в системные директории.

Ну не, у нас основная почтовая нагрузка лежит буквально на 10-12 людях, таких критичных масштабов нет.

Угу, угу.
Понятно что нет. Иногда и чтения достаточно. Вот тебе файл "7.hta"
Заверни в него любой скрипт и попробуй заблокировать. :)
Это не малварь, если чо, это файл который создаёт в темпе TeamViewer после выхода.

Вот что внутри:
Прикол в том, что он унаследует права mshta.exe.
Даже если для AppLocker-а не были созданы дефолтные правила, де-факто он самостоятельно разрешает запуск из system32.
Хотя в документации технета чётко сказано: "Если файл был запрещен для выполнения в коллекции правил, запрещающее действие получит приоритет над любым разрешающим действием независимо от того, в каком объекте групповой политики было изначально применено правило. Так как AppLocker функционирует как разрешенный список по умолчанию, если ни одно из правил явным образом не разрешает или не запрещает выполнение файла, заданное по умолчанию запрещающее действие AppLocker заблокирует файл."
Вот. Человек столкнулся с той же проблемой, это я про него упоминал:
https://www.sysadmins.lv/blog-ru/sek...s-chast-5.aspx
Ответ MS:
https://www.sysadmins.lv/blog-ru/sek...-chast-5a.aspx

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

На самом деле уже есть две утилиты, которые в паре могут обеспечить почти 100% защиту. Про первую тут уже написал NickM, задача которой тупо не давать запускать определенные типы исполняемых файлов, вторая http://virusinfo.info/showthread.php?t=203022 же утилита блокирует по поведению шифровальщики.

Приветствую форумчане.
На днях один из компов в сети поймал шифровщик да винчи.
я вовремя успел его обезвредить (он только малую часть файлов успел зашифровать на машине пользователя)

собственно в чем вопрос: у компа были права на запись на некоторые папки на файловом сервере (2008R2 - сразу скажу на нем идет бэкап расшаренных папок в такие же папки, но на другом локальном/физическом диске, не рэйд, просто бэкап прогой без перезаписи измененных файлов).
Есть какие-нибудь методы и/или средства избежать шифровки данных на шаре, если на комп в сети вирус уже проник и лютует?

не подключать ресурсы сетевых ПК как диски. Шифровальщики не сканят сеть на предмет общих ресурсов.

это заблуждение.
сканят и ещё как. мы таким образом потеряли в одном из городов 10Тб бэкапов - шара на NAS была хоть и скрытой, но для everyone=RW.

0. Шифровальщики сканируют сеть. Такие есть, они не дураки.
1. Существенная корректировка: права на запись были не у компьютера, а у пользователя.
2. Судя по всему, ежечасные shadow copies не применяете. Досадно.
3. Убедитесь, что разрешения NTFS на запись стоят только для нужных групп пользователей и только на требуемые папки. Ещё Server 2012 R2 умеет делать Conditional Permissions (например, "разрешить запись только при условии, что пользователь работает на компьютере финансового департамента").
4. Внятного способа отличить работу сетевого пользователя от работы вируса нет, хотя некоторые производители клялись, что могут. Так или иначе, для снижения рисков придётся распространять SRP на все сервера и рабочие станции.

Понял. Вопрос про ярлыки с сетевыми папками отпал сам собой.
Извините, вы правы - пользователя. Просто у меня 1 комп - 1 пользователь.
Нет, не применяем. вместо этого делается бэкап файлов раз в 2 часа (для важных папок). Не подскажите, что лучше теневые копии или мой вариант?
так и есть. Правда у некоторых пользователей - есть доступ ко всем :(
Уже читаю. Спасибо за помощь.

1. Теневые копии не являются заменой полноценному резервному копированию.
2. Но без них нельзя. Технология моментальных снимков является чрезвычайно эффективной и изначально предназначена для резервирования в рабочие часы, не прерывая работу пользователей. В конце концов, включить shadows и отконфигурить на ежечасные snapshots ничего не стоит, а отдача максимальна.

Типичный сценарий: звонок "помогите, всё пропало, кто-то удалил все папки!"
1. В журнале безопасности с помощью предварительно настроенного аудита успешных удалений ищу дату и время удаления, а также имя героя;
2. Монтирую правильную тень и восстанавливаю потерянные объекты.

cameron, исходил из того, что подобным заразам нужно время для обработки локальных объектов, на сетевые не тратятся... значит, уже тратятся... приму к сведению.

WindowsNT, против шифровальщиков бесполезны как теневые копии, так и точки восстановления - сносится первым же делом.

Что, прям была учётная запись обычного пользователя и был установлен пароль администратора и всё равно система была разрушена?

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