Настройка srp windows 10
Обновлено: 07.07.2024
Некоторые возможности управления приложениями в Защитнике Windows доступны только в определенных версиях для Windows. Узнайте больше о доступности функции управления приложениями в Защитнике Windows.
В этом разделе для ИТ-специалистов описывается, как использовать политики ограничения программного обеспечения (SRP) и Политики AppLocker в одном Windows развертывании.
Понимание разницы между SRP и AppLocker
Вы можете развернуть политики управления приложениями в Windows операционных системах раньше, чем Windows Server 2008 R2 или Windows 7. Политики AppLocker можно использовать только в поддерживаемых версиях и выпусках Windows, как указано в требованиях к использованию AppLocker. Однако можно использовать SRP для поддерживаемых выпусков Windows плюс Windows Server 2003 и Windows XP. Чтобы сравнить функции и функции в SRP и AppLocker, чтобы определить, когда использовать каждую технологию для удовлетворения задач управления приложениями, см. в статью Определение целей управления приложениями.
Использование SRP и AppLocker в одном домене
SRP и AppLocker используют групповую политику для управления доменом. Однако, когда политики, созданные SRP и AppLocker, существуют в одном домене и применяются с помощью групповой политики, политики AppLocker имеют приоритет над политиками, созданными SRP на компьютерах с операционной системой, которая поддерживает AppLocker. Сведения о том, как наследование в групповой политике применяется к политикам и политикам AppLocker, созданным SRP, см. в рубриках Understand AppLocker rules and enforcement setting inheritance in Group Policy.
Важно: В качестве наилучшей практики используйте отдельные объекты групповой политики для реализации политик SRP и AppLocker. Чтобы устранить проблемы с устранением неполадок, не объединяйте их в одном GPO.
В следующем сценарии приводится пример того, как каждый тип политики повлияет на приложение программного обеспечения для банковского тельца, где приложение развернуто на разных операционных системах Windows и управляется GPO Tellers.
| Операционная система | GPO tellers с политикой AppLocker | GPO tellers с SRP | GPO tellers с политикой AppLocker и SRP |
|---|---|---|---|
| Windows 10, Windows 8.1, Windows 8 и Windows 7 | Политики AppLocker в GPO применяются, и они выдают все локальные политики AppLocker. | Локальные политики AppLocker замещеют политики, созданные SRP, которые применяются через GPO. | Политики AppLocker в GPO применяются, и они замещеют политики, созданные SRP в политиках GPO и локальных политиках AppLocker, созданных SRP. |
| Windows Vista | Политики AppLocker не применяются. | Применяются политики, созданные SRP в GPO, и они выдают локальные политики, созданные SRP. Политики AppLocker не применяются. | Применяются политики, созданные SRP в GPO, и они выдают локальные политики, созданные SRP. Политики AppLocker не применяются. |
| Windows XP | Политики AppLocker не применяются. | Применяются политики, созданные SRP в GPO, и они выдают локальные политики, созданные SRP. Политики AppLocker не применяются. | Применяются политики, созданные SRP в GPO, и они выдают локальные политики, созданные SRP. Политики AppLocker не применяются. |
Примечание: Сведения о поддерживаемых версиях и выпусках операционной системы Windows см. в приложении Requirements to use AppLocker.
Тестирование и проверка политик SRP и AppLocker, развернутых в одной среде
Так как политики SRP и AppLocker работают по-другому, их не следует реализовывать в одном GPO. Это упрощает тестирование результатов политики, что имеет решающее значение для успешного управления использованием приложений в организации. Настройка системы тестирования и распределения политик поможет вам понять результат политики. Эффекты политик, созданных политиками SRP и AppLocker, необходимо протестировать отдельно и с помощью различных средств.
Шаг 1. Проверка эффекта SRP
Вы можете использовать консоль управления групповой политикой (GPMC) или набор результатов политики (RSoP), чтобы определить эффект применения SRP с помощью GPOs.
Шаг 2. Проверьте влияние политик AppLocker
Политики AppLocker можно протестировать с помощью Windows PowerShell. Сведения о расследовании результатов политики см. в
Другим методом, который необходимо использовать при определении результата политики, является настройка режима применения только аудита. При развертывании политики события будут записаны в журналы AppLocker так, как если бы политика была принудительной. Сведения об использовании режима только аудита см. в этой информации:
В данной статье рассказывается о механизме Software Restriction Policies (SRP), который предназначен для создания политик запуска программ в среде Microsoft Windows. В частности, для возможности использования SRP для минимизации рисков возможного инфицирования компьютера вредоносными программами.
С чего начинается защита от вирусов и других зловредных программ?
Дело в том, что у стандартных пользователей нет прав на инсталляцию программ и настройку системы, за счёт чего она работает весьма стабильно и безопасно. Что-то напортачить или сломать не получится, на это у пользователя просто нет прав. Компьтерный вирус — это не чёрная магия, а программа, просто компьютерная программа, поэтому заразить систему вирусом рядовой пользователь тоже не может. Причём, компьютеру всё равно, новый это вирус или старый, особо хитрый или примитивный — если имеющихся привилегий недостаточно, занести вирус в системную папку или прописать его автозапуск в системном реестре не получится никак.
Рисунок 1. Уровень привилегий учётной записи пользователя в Windows 7
Вне зависимости от того, работаем мы дома или в офисе, в систему всегда следует входить только с ограниченными привилегиями. Системные администраторы должны обладать двумя учётными записями — и рядовой, и административной, но использовать последнюю только при доказанной необходимости. Тип используемой вами учётной записи можно уточнить в Control Panel (Панели Управления).
Что же такое Software Restriction Policies?
С помощью SRP можно создать “белый список” программ, которые заведомо разрешены для запуска; все остальные программы будут заблокированы. Например, мы говорим системе “запускай всё из папок C:\Windows, C:\Program Files, D:\Games, а остальное не разрешается”. В результате, приезжающий на флешке вирус тихо «обламывается», не сумев запуститься с неразрешённого пути E:\ или Z:\. Что-то попыталось пролезть с ненадёжного веб-сайта? Оно тоже не запустится, так как было сохранено в папке профиля пользователя Temporary Internet Files или %Temp%. А мы оттуда ничего запускать не разрешали! Присланный посредством Skype «новый супер-пупер скринсейвер», на самом деле представляющий собой троянскую программу, тоже не запустится.
Политика Software Restriction Policies сильно выигрывает в сравнении с любыми тормозяще-навороченными, но в то же время очень ненадёжными антивирусными программами, будь то Kaspersky, NOD или Avast (название и производитель не имеют значения). Ловля блох антивирусным монитором — компьютерный аналог «русской рулетки». Причём, далеко не факт, что вы в ней выиграете. В то же время, SRP сразу же отбросит всё неразрешённое, не вникая, что это там было, хорошее или плохое.
На самом деле, политика не предотвратит сохранение тела вируса на жёстком диске. SRP — не антивирусная программа, она не анализирует содержимое файлов. Но и запуститься хранящейся на диске или flash-носителе потенциально деструктивной программе она не позволит.
SRP не нужно откуда-то скачивать, она уже встроена в следующие системы Microsoft:
- Windows XP Professional, Windows XP Media Center 2005;
- Windows Vista Business, Windows Vista Enterprise & Ultimate;
- Windows 7 Professional, Windows 7 Enterprise & Ultimate;
- Windows Server 2003 и 2008 (все редакции);
К сожалению, никакие системы из серии Windows Home не поддерживаются.
Как включить и настроить политику SRP?
Для включения SRP зайдите в систему с правами администратора и выполните команду Start → Run → gpedit.msc. В разделе Computer Configuration (Конфигурация компьютера) раскройте папку Windows Settings → Security Settings → Software Restriction Policies.
Рисунок 2. Включение политики SRP
На всех упомянутых ранее версиях Windows это окно выглядит примерно одинаково. Однако, в политиках домена Active Directory вы можете найти SRP и в разделе User Configuration (Конфигурация пользователя). Я рекомендую выполнять базовую конфигурацию SRP на уровне Computer Configuration, а User Configuration использовать только для расширения области действия политики для некоторых групп пользователей.
Щёлкните правой кнопкой по папке Software Restriction Policies и выберите команду Create New Policies. Политика создана, теперь нужно сделать дополнительные настройки. Выполните двойной щелчок по значению Enforcement и укажите Apply to: All software files и Apply to: All Users. Тем самым, проверке будут подлежать все программы и динамические библиотеки, и защищены будут все пользователи, включая самых опасных — администраторов.
Параметр Apply to: All software files может оказаться неприменимым для вашей системы, если используются приложения, вызывающие dll-модули некорректными методами либо хранящие множество своих модулей в профилях пользователей. Чтобы облегчить управление такими приложениями, можно ослабить уровень защиты, переключив настройку в положение Apply to: All software except libraries. Однако, учтите, что количество зловредных программ, выполненных в виде динамических библиотек и вызываемых строкой вида rundll32.exe C:\Recycler\virus.dll, неуклонно растёт. И только более строгая, полная фильтрация позволяет защитить систему от крайне опасной проблемы, носящей название DLL Hijacking.
Рисунок 3. Настройка области действия политики SRP
Один параметр может оказаться досадной и никак не улучшающей безопасность помехой — по умолчанию, SRP обрабатывает не только исполняемые файлы, но и некоторые другие типы файлов — например, ярлыки (Shortcuts). Выполните двойной щелчок по значениюDesignated File Types и удалите расширение LNK из списка. Замечу, сами ярлыки и их целевые файлы обрабатываются политикой отдельно. Таким образом, удаляя LNK из списка обрабатываемых расширений, вы не понижаете уровень безопасности системы — создать ярлык на неразрешённый файл и таким образом запустить его в обход политики всё равно будет невозможным.
Рисунок 4. Настройка обрабатываемых политикой SRP типов файлов
Существуют несколько режимов работы SRP:
- Disallowed: режим «белого списка». По умолчанию, запрещён запуск любых программ, кроме описанных в правилах политики;
- Basic User: режим принудительного ограничения привилегий. Все программы запускаются с привилегиями рядового пользователя, кроме исключений, описанных политикой;
- Unrestricted: режим «чёрного списка». По умолчанию, разрешается запускать любые программы, кроме отдельно заблокированных в правилах политики.
Раскройте папку Security Levels и назначьте режим Disallowed в качестве основного.
Рисунок 5. Включение режима «белого списка» политики SRP
В контейнере Additional Rules перечисляются программы, которые мы разрешаем запускать. Обычно особого внимания это от нас не требует, так как политика автоматически указывает, что все программы, находящиеся в Program Files и Windows, разрешены для запуска. Таким образом, большинство программ будет работать нормально, а стандартные пользователи не имеют прав на изменение содержимого этих папок. Однако, если ваши программы установлены в иные каталоги, добавьте в список дополнительные разрешённые пути или хэш-суммы исполняемых модулей в режиме Unrestricted.
По возможности, не добавляйте в Additional Rules пути, которые открыты рядовым пользователям для Записи. «Белый список» Software Restriction Policies позволяет защитить систему не только от случайно приносимых вирусов, но также от других нежелательных программ — например, чат-клиентов, игр, альтернативных браузеров. Ни в коем случае не добавляйте в Additional Rules пути вида C:\, %Temp% илиF:\ (путь к сменному носителю) с типом доступа Unrestricted, так как это аннулирует весь эффект политики.
Рисунок 6. Настройка списка разрешённых для запуска программ
Итак, политика настроена. Для того, чтобы она вступила в силу, перезагрузите систему. Дальнейшие настройки и переключения режимов работы SRP перезагрузку требовать не будут.
Что делать, если что-то перестало работать?
Существует вероятность, что самая важная для вас программа перестанет работать из-за блокировок, налагаемых политикой SRP. В этом случае, вам на помощь приходит системный журнал, с содержимым которого можно ознакомиться, выполнив команду Start → Run → eventvwr.msc.
Рисунок 7. Просмотр журнала событий Application
Теперь всё работает, но что будет дальше?
Иногда вам придётся устанавливать новые программы, а также обновлять их и саму систему. Для этого политику SRP нужно временно отключать. Создайте два файла, которые помогут вам облегчить отключение/включение SRP, и сохраните их в папке Windows:
SRP_Disable.reg
SRP_Enable.reg
На самом деле, значение DefaultLevel не отключает политику, а переводит её из режима «белого списка» Default: Disallowed в режим «чёрного списка» Default: Unrestricted, разрешая запуск любых программ, кроме тех, что описаны в контейнере Additional Rules в режиме Disallowed. По возможности, не создавайте записи с типом доступа Disallowed, так как это осложняет работу с политикой.
Создайте ярлыки на reg-файлы на рабочем столе Администратора. Процедура установки новых программ усложняется лишь ненамного по сравнению с тем, как вы привыкли это делать:
- отключаем защиту SRP ярлыком SRP Disable;
- инсталлируем программу или выполняем обновление системы;
- снова включаем SRP ярлыком SRP Enable.
Рисунок 8. Ярлыки управления режимами SRP
Возможно, поначалу вы будете забывать включать политику после установки программ. Можно настроить систему таким образом, чтобы вручную отключенная защита включалась снова через регулярные интервалы времени. Запустив программу gpedit.msc, в секции Computer Configuration откройте папку Administrative Templates -> System -> Group Policy и в параметре Registry Policy Processing выберите Enabled и включите галочку Process even if the GPO have not changed. В любом случае, после перезагрузки компьютера Software Restriction Policies включится автоматически.
Software Restriction Policies не гарантирует стопроцентную защиту от зловредных программ, но её эффективность может быть по крайней мере на несколько порядков выше эффективности обычных антивирусных программ. Успехов в повышении уровня безопасности вашего компьютера!
Подписывайтесь на канал "Anti-Malware" в Telegram, чтобы первыми узнавать о новостях и наших эксклюзивных материалах по информационной безопасности.
Продолжаем цикл статей о противодействии классу вирусов-шифровальщиков в корпоративной среде. В предыдущих частях мы рассмотрели настройку защиты на файловых серверах с помощью 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 с компьютерами пользователей.
Примечание. Настоятельно рекомендуем перед внедрением SRP политик, протестировать их работу на группе тестовых компьютерах. В случае обнаружения легитимных программ, которые не запускаются из-за SRP, нужно добавить отдельные разрешительные правила.В консоли редактора GPO перейдите в раздел Computer Configuration -> Windows Settings -> Security Settings . Щелкните ПКМ по Software Restriction Policies и выберите New Software Restriction Policies.
Выберите раздел Additional Rules, и создайте новое правило New Path Rule.
Создадим правило, запрещающее запуск исполняемых файлов с расширением *.exe из каталога %AppData%. Укажите следующие параметры правила:
Аналогичным образом нужно создать запрещающие правила для путей, перечисленных в таблице. Т.к. переменные окружения и пути в Windows 2003/XP и Windows Vista/выше отличаются, в таблице указаны значения для соответствующих версий ОС. Если у вас в домене еще остались Windows 2003/XP, для них лучше создать отдельную политики и назначить ее на OU с компьютерами с использованием WMI фильтра GPO по типу ОС.
Важно. с эти правилом нужно быть внимательным, т.к. некоторое ПО, например плагины браузеров, установщики – хранят свои исполняемые файлы в профиле. Для таких программ нужно будет сделать правило исключения SRPВы можете добавить собственные каталоги. В нашем примере получился примерно такой список запрещающих правил SRP.
Как правило, также следует запретить запуск других расширений потенциально опасных файлов (*.bat,*.vbs, *.js, *.wsh и т.п.), ведь вредоносный код может находиться не только в *.exe файлах. Для этого нужно изменить пути в правилах SPR , удалив вхождения *.exe. Таким образом, будет запрещен запуск всех исполняемых файлов и файлов сценариев в указанных каталогах. Список «опасных» расширений файлов задается в параметрах политики SRP в разделе Designated File Types. Как вы видите, в нем уже есть предустановленный список расширений исполняемых файлов и скриптов. Можете добавить или удалить определенные расширения.
Your system administrator has blocked this program. For more info, contact your system administrator.
Попытки запуска исполняемых файлов из защищенных каталогов, которые были блокированы политиками SRP можно отслеживать с помощью журнала событий Windows. Интересующие нас события находятся в разделе Application, и имеют Event ID 866, с источником SoftwareRestrictionPolicies и примерно таким текстом:
Итак, мы показали общий пример техники использования политики ограниченного использования программ (SRP или Applocker) для блокировки вирусов, шифровальщиков и троянов на компьютерах пользователей. Рассматриваемая методик позволяет существенно усилить степень защиты систем от запуска вредоносного кода пользователями.
Для защиты от вредоносного программного обеспечения традиционно принято использовать антивирусы и это правильно, но и сама система вовсе не так беззащитна, как это может показаться на первый взгляд.
Весьма эффективным средством защиты от вредоносного ПО могут служить политики безопасности Windows, нужно только их должным образом настроить.
В данном посте будет рассмотрен метод защиты от вирусов посредством Software Restriction Policies или сокращённо SRP — политики ограничения программного обеспечения.
Этот механизм Windows позволяет запрещать запуск исполняемых файлов из определённых каталогов с помощью локальной или доменной групповой политики, следовательно, может использоваться в качестве средства блокирования вирусов, троянов, шифровальщиков и некоторых других типов вредоносного ПО.
Варианты защиты
Вариантов защиты с помощью SRP два:
- разрешение запуска исполняемых файлов только из папок Windows и Program Files;
- запрет запуска исполняемых файлов из определённых пользовательских папок.
Первый вариант более надёжен, но в то же время он и более сложен, так как требует тщательного выбора и отладки приложений.
Мы отдадим предпочтение второму, более простому и понятному для среднего пользователя метод.
Как правило, при заражении ПК большинство вирусов попадает в пользовательские каталоги AppData и LocalAppData, оттуда же они и запускаются.
Причина, по которой именно эти папки стали излюбленным местом для вирусов проста — у пользователей, не имеющих администраторских прав, возможность копировать или перемещать файлы в каталоги системы отсутствует, запись для них ограничивается только их собственными папками, поэтому вирусу ничего не остаётся как размещать свою копию в доступных для записи расположениях.
Чтобы предотвратить запуск вирусов, создадим политику, ограничивающую старт исполняемых файлов из указанных каталогов.
Кликните правой кнопкой по элементу «Политики ограниченного использования программ» и выберите в меню опцию «Создать политику ограниченного использования программ».
В открывшемся окошке в поле «Путь» впишите %AppData%/*.exe, «Уровень безопасности» установите «Запрещено», содержимое поля «Описание» может быть произвольным.
Нажмите «Применить», а затем «OK».
Точно таким же образом создайте правила для следующих путей:
Обратите внимание, что в список папок с ограничениями мы добавили временное хранилище для распаковываемых WinRAR архивов (третье правило снизу).
Если вы используете другой архиватор, замените элемент строки Rar основным поддерживаемым им расширением, например, %LocalAppData%/Temp/*.zip/*.exe. При необходимости можете указать свои пути.
Также неплохо было бы создать правила для других типов исполняемых файлов, вредоносный код могут содержать файлы msi, dll, cmd, bat, com, vbs, js, wsh и т.д, а не только EXE.
Просмотреть их список можно в тех же политиках ограниченного использования программ, дважды кликнув по элементу «Назначенные тип файлов» справа.
Чтобы не мучиться, создавая правило для каждого типа отдельно, допустимо просто удалить вхождения *.exe во всех путях, при этом будет запрещён запуск всех файлов, но в некоторых случаях это может привести к ошибкам.
Отдельно стоит сказать пару слов о родительском каталоге %UserProfile%, окопаться вирусы могут и нём, однако запрет на запуск файлов из него опять же может привести к ошибкам и неполадкам в работе программ.
Например, в профиле пользователя могут храниться плагины браузеров или проверяющие наличие новых версий приложений установщики.
Чтобы эти программы смогли работать, необходимо создать для них в SRP исключающие правила, указав полный путь к исполняемому файлу и выбрав в меню уровня безопасности «Обычный пользователь» или «Неограниченный».
Осталось только проверить, действительно ли блокировка работает. Для этого после изменения настроек перезагрузите компьютер или обновите конфигурацию политики командой gpupdаtе /force, а затем попробуйте запустить из папки %AppData% какой-нибудь исполняемый файл.
Более подробные сведения о заблокированных файлах можно будет получить в разделе «Приложения» журнала Windows.
Тема безопасности сервера Windows не раз поднималась, в том числе и в этом блоге. Тем не менее мне хотелось бы еще раз освежить в памяти старые методы защиты и рассказать о малоизвестных новых. Разумеется, будем использовать по максимуму встроенные средства.
Итак, предположим, что у нас есть небольшая компания, которая арендует терминальный сервер в удаленном дата-центре.
При проектировании любой защиты следует начинать с модели угроз — от кого или чего, собственно, будем защищаться. В нашей типовой конфигурации я буду строить оборону от внешних злобных хакеров, от некомпетентных (а может, и немного злонамеренных) пользователей. Начнем с внешнего периметра обороны — фаервола.
Во времена Windows 2003 встроенный фаервол представлял собой жалкое зрелище, и в случае невозможности применения сторонних средств приходилось использовать IPSec. Пример такой настройки разобран, например, в материале Secure Windows Servers using IPSec Firewall.
Сейчас, с появлением WFP (Windows Filtering Platform) дела стали получше. В принципе, с этим фаерволом так или иначе сталкивался, наверное, каждый системный администратор Windows, поэтому настройка удаленного доступа к серверу только с определенных IP не должна вызывать затруднений. Я обращу внимание на некоторые «фишки», которые используются редко.
По умолчанию фаервол блокирует все входящие соединения, кроме явно разрешенных, но исходящие разрешает все, кроме явно запрещенных. Политику эту можно изменить, открыв управление фаерволом через wf.msc и выбрав «Свойства».
Теперь, если мы захотим запретить пользователям терминального сервера выходить с этого сервера в интернет — у нас это получится.
Стоит отметить, что при настройке правил доступа к серверу (входящие подключения) явно создавать правила для исходящего трафика не нужно. В терминах iptables — established и related всегда разрешены.
Для ценителей командной строки настройку фаервола можно производить в контексте netsh advfirewall. Почитать про команды можно в материале «Брандмауэр Windows 7 в режиме повышенной безопасности», я же добавлю, что блокировка входящих и исходящих подключений включается командой:
Еще одной особенностью фаервола windows является то, что любая программа или настройка меняет его правила без уведомлений. Например, отключили вы все правила на нашем дедике, рядом появился второй, вы сделали между ними локальную сеть, настроили общий доступ и… внезапно у вас включается smb для всех и вся со всеми вытекающими последствиями.
Выхода, по сути, два с половиной (напомню, мы пока говорим только про встроенные средства): регулярно проверять, не изменились ли правила, и использовать старый добрый IPSec или — как по мне, самый разумный вариант — настраивать фаервол групповой политикой. Настройка производится в Конфигурация компьютера — Конфигурация Windows — Параметры Безопасности — Монитор брандмауэра Защитника Windows в режиме повышенной безопасности.
Настройка фаервола групповой политикой.
Также при помощи фаервола windows можно реализовать простой fail2ban. Достаточно включить аудит неудачных попыток входа и при нескольких неудачах подряд блокировать IP источника. Можно использовать самописные скрипты, а можно уже готовые средства, о которых я писал в статье «Как дать шифровальщикам потопить компанию».
Если же встроенного фаервола не хватает и хочется использовать что-то более серьезное, то можно установить стороннее ПО. Жаль, что большинство известных решений для Windows Server — платные. Другим вариантом будет поставить перед сервером роутер. Понятно, что такая установка подойдет, если мы используем colocation, а не аренду сервера где-то далеко-далеко за рубежом. Если же зарубежный дата-центр — это наш выбор, то можно использовать виртуализацию — например, встроенный Hyper-V — и установить в виртуалку привычный GNU\Linux или FreeBSD.
Возникает вопрос: как сделать так, чтоб виртуалка имела прямой выход в интернет, а сервер — нет? Да еще чтобы MAC-адрес сервера не светился хостеру и не требовал тем самым покупки еще одного IP-адреса.
Осторожно! Дальнейшие действия лучше проводить через IP-KVM!
Для этого виртуальную машину нужно снабдить двумя сетевыми адаптерами. Один — для непосредственного подключения к интернету, для него мы сделаем виртуальный коммутатор типа «внешний» и снимем галочку, разрешающую операционной системе взаимодействие с этим коммутатором. Этой самой галочкой мы лишим сервер прямого доступа в интернет (настройку виртуальной машины-фаервола лучше произвести заранее), и его MAC не будет светиться хостеру.
Настройка внешнего виртуального коммутатора.
Другой виртуальный коммутатор следует сделать типа «внутренний» для взаимодействия виртуальной машины и сервера. На нем уже нужно настроить локальную адресацию. Так получится создать виртуальный роутер, стоящий перед сервером и защищающий его.
Заодно на этой виртуальной машине можно настроить любимый VPN до офиса или удаленных сотрудников, не заморачиваясь с ролью «Маршрутизация и удаленный доступ» или со встроенным IPSec, как я рассказывал в статье «Как я базы 1С в Германии прятал». Главное, не забыть проверить автозапуск этой виртуальной машины при старте системы.
Подключаться к такому серверу можно при помощи обычного RDP или использовать HTML5 клиенты с двухфакторной аутентификацией. Стоит на случай брутфорса озаботиться и решениями fail2ban, и блокировкой учетной записи на некоторое время при нескольких неудачных попытках авторизации подряд.
Снаружи сервер мы более-менее защитили, перейдем к защите внутренней.
Конечно, для защиты сервера изнутри очень хочется поставить какой-нибудь антивирус — мало ли что пользователи сервера накопируют или накачают из интернета. Но на практике антивирус на сервере может принести больше вреда, чем пользы. Поэтому я обычно использую механизмы блокировки запуска ПО не из белого списка — в частности, механизм SRP (software restriction policies), о котором я тоже упоминал в статье «Как дать шифровальщикам потопить компанию».
Остановлюсь чуть подробнее на одном подводном камне, о котором часто забываем при включении SRP со стандартными настройками, когда блокируется все, кроме папок Windows и Program Files. Действительно, это отфильтровывает почти всех зловредов. Но не очень работает со злонамеренностью сотрудников, ведь в системных папках есть подпапки с правом на создание объектов пользователями. Например, можно посмотреть на папку C:\Windows\Temp.
Разрешения на папку, которая попадет в белый список.
И такая папка не одна. Можно, конечно, проводить аудит системных папок самостоятельно, а можно довериться людям, которые это уже сделали. Например, специалист Stefan Kanthak в своем блоге (по ссылке есть тестовый вирус EICAR, антивирус может сработать) в довольно агрессивной манере проходится по антивирусам и методам защиты Windows и заодно предлагает уже собранный пакет настроек SRP, который будет блокировать и такие подозрительные папки. По запросу автор предоставляет и программу для конвертирования этих настроек реестра в файлы локальных политик.
Если вы предпочитаете использовать механизм AppLocker c более гибкими настройками, то вам может помочь решение AaronLocker.
Редакция не рекомендует использовать и устанавливать скрипты и прочие программы из интернета без предварительного их изучения.
Если AppLocker появился уже довольно давно, а возраст SRP перевалил за 15 лет, то относительно свежей альтернативой является WDAC (Windows Defender Application Control). Действительно, со времен Security Essentials встроенный «антивирус» обзавелся многими интересными возможностями. Например, WDAC — модуль, который отвечает за политики доступа к приложениям и библиотекам. Ранее он являлся частью Device Guard (защита компьютера, в том числе с применением технологий виртуализации), и немного про его настройку рассказывалось в материале «Принцип работы S Mode в Windows 10 и настройка Device Guard своими руками». Подробнее со всеми тонкостями можно ознакомиться в официальной документации, мне же остается добавить несколько минусов, отличающих его от классических решений вроде SRP и AppLocker:
- Графической настройки нет, все через командлеты PowerShell.
- Нет настроек в срезе пользователя, только для компьютера.
- Настройка делается довольно непривычно — подготавливается файл в формате xml, который затем приводится к бинарному, и распространяется по компьютерам.
Зато возможна настройка в срезе приложения: например, если вы хотите дать доступ к cmd.exe вашему скрипту, а не стороннему вирусу — это можно реализовать. Да еще и политику можно применить до загрузки системы, при помощи UEFI.
Блокировка хрома через WDAC.
В целом из-за тягостной настройки сложилось впечатление, что WDAC больше позиционируется не сам по себе для управления компьютерами, а как средство, позволяющее интегрироваться с централизованными MDM-системами вроде Microsoft Intune. Но при этом разработка старых добрых SRP прекращена в Windows 10 1803.
Если говорить про Защитник Windows, нельзя не упомянуть про Credential Guard и Remote Credential Guard.
Первое средство использует опять же виртуализацию, запуская компонент LSA (Local Security Authority) в изолированном от операционной системы процессе, что сильно усложняет процесс кражи хешей паролей и билетов Kerberos. Подробнее про технологию можно почитать в официальной документации. Для работы процессор должен поддерживать виртуализацию, а также в системе должна быть включена безопасная загрузка (Secure Boot) и модуль TPM для привязки учетных данных к оборудованию. Включить Credential Guard можно через групповую политику Конфигурация компьютера — Административные шаблоны — Система — Device Guard — Включить средство обеспечения безопасности на основе виртуализации.
Включение Credential Guard.
Второе средство служит для защиты передаваемых учетных данных (особенно админских!) для удаленного подключения, например, по тому же RDP. Ранее для этих целей предлагался механизм Restricted Admin Mode, но он ограничивал подключение только одним сервером. Подключившись к серверу, нельзя было просто так использовать ресурсы сети, права администратора применялись только к одному серверу а-ля системный аккаунт Local System.
Remote Credential Guard позволяет передавать учетные данные с локальной машины удаленному серверу без явного ввода пароля, что, помимо расширенной безопасности, даст и удобство подключения к серверам (SSO). Почитать подробнее можно в документации, ну а я добавлю, что для работы механизма достаточно включить его поддержку на сервере — например, через реестр командой:
А потом подключаться к серверу командой:
Теперь учетные данные в безопасности, а сервер достаточно защищен. Правда, в материале я осознанно не касался вопросов защиты от злонамеренного хостера, но тут все сводится в общем-то к одному — к шифрованию дисков.
Читайте также: