Ограничение запуска программ через домен: как игровой вирус научил нас говорить «нет» по умолчанию

Два месяца назад один из сотрудников принёс из дома архив с «интересной стрелялкой». Запустил на рабочей машине, пострелял минут десять, закрыл. Игра была вполне рабочая - и вполне рабочий носитель. Через сутки у нас было четыре заражённых машины в одном офисе и много неприятного разговора с клиентом о том, как оно вообще могло произойти.

Антивирус на той машине стоял. Базы были не то чтобы свежие, но и не катастрофически старые. Просто этот конкретный образец антивирус не знал - новый, ещё не в базах. Стандартная история.

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

Идея простая, реализация требует аккуратности

Антивирус работает по принципу «знаю плохое - блокирую». Это называют подходом по чёрному списку. Проблема в том, что плохое всегда появляется раньше, чем попадает в список.

Есть другой подход: разрешить запуск только того, что заранее известно как допустимое. Белый список. Всё остальное - не запускается, точка. Неизвестная игра с вирусом внутри? Не важно, знает о ней антивирус или нет - она просто не запустится, потому что её нет в списке разрешённого.

В Windows 2003 и XP это реализовано через Software Restriction Policies - SRP, политики ограничения программного обеспечения. Настраиваются через групповые политики домена, то есть одно изменение покрывает всех пользователей сразу.

Механика такая: в GPO задаётся уровень безопасности по умолчанию - либо «запрещено всё, кроме явно разрешённого», либо «разрешено всё, кроме явно запрещённого». Мы поставили первый вариант. Потом добавляются правила-исключения: папки, из которых запуск разрешён.

Базовый список доверенных папок, который мы использовали:

• C:\Windows и подпапки - системные компоненты ОС
• C:\Program Files - установленные программы
• Сетевые шары с дистрибутивами и утилитами, которые администрирует ИТ

Всё, что запускается из C:\Documents and Settings, с рабочего стола, из Temp, из Downloads, с USB-носителей - блокируется автоматически. Игра, скачанная пользователем, сохранённая на рабочем столе или запущенная с флешки, не стартует независимо ни от чего.

Где ломается и как починить

Вот здесь начинается интересная часть. Простая идея наталкивается на реальность, в которой часть легитимного корпоративного софта ведёт себя нестандартно.

Первое - инсталляторы. Многие программы при установке распаковывают временные файлы в %Temp% и запускают их оттуда. Под SRP это не пройдёт. Решение: установку делать с правами администратора, для которого создаётся отдельное правило, или временно поднимать ограничение на время установки через GPO Update. Мы выбрали второй путь для плановых установок и первый для экстренных.

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

Третье - скрипты. VBScript, JScript, BAT-файлы - SRP умеет ограничивать и их, если включить соответствующие расширения в политике. Но тут надо смотреть, есть ли у клиента легитимные скрипты в пользовательских папках. У одного из наших клиентов бухгалтер держала на рабочем столе bat-файл для запуска отчёта. Пришлось перенести его в Program Files и добавить ярлык.

Четвёртое - обновления самих программ. Некоторые приложения обновляются через собственный апдейтер, который тянет исполняемый файл и запускает его из временной папки. Здесь нужно смотреть конкретику: либо добавлять путь к временной папке апдейтера в исключения, либо переходить на централизованное управление обновлениями через ИТ.

Как разворачивали

Первое правило: не катить сразу на всех. Мы создали тестовую OU с несколькими машинами, применили политику туда. Прогнали два дня - нашли три проблемных случая с конкретными программами, поправили правила.

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

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

Где-то на третий день количество обращений резко упало. А потом наступил тихий момент: пользователи перестали звонить с просьбой «а установи мне вот эту программку». Не потому что мы их запугали, а потому что стало понятно - оно просто не запустится.

Что получилось по итогу

После блокировки USB один из векторов заноса закрыли - с флешки теперь ничего не запустишь. SRP закрыл второй: скачанное из интернета, принесённое по почте, любым другим способом попавшее в пользовательские папки - не стартует.

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

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

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