Своими руками на тему сша


Своими руками на тему сша

Недавно Microsoft объявила, что после официального выпуска версии 1803 (RS4) на рынок выйдет более 20 моделей ПК с Windows 10 Home и Pro в режиме S Mode, а организации смогут развертывать в нем издание Enterprise. Сегодня я расскажу о том, как работает S Mode в Windows 10, а вы сможете попробовать его на практике, воспользовавшись готовыми политиками WDAC или настроив их самостоятельно.

[+] Сегодня в программе Что такое S Mode и в чем разница с изданием S

Microsoft относительно недавно начала экспериментировать с этим вариантом поставки Windows 10, поэтому история вопроса короткая.

Издание Windows 10 S

Изначально Microsoft сделала отдельное издание Windows 10 S, и в мае 2017 года компания выпустила свой Surface Laptop с этим изданием на борту. Доподлинно неизвестно, что скрывается за буквой “S”, но можно предположить Security.

В этом издании можно запускать только приложения из Магазина, а также классические программы, входящие в состав Windows, но не все. В черный список попали исполняемые файлы, с помощью которых можно запустить вредоносный код или нарушить нормальную работу системы: cmd, powershell, mshta, wmic, cscript, wscript, regedit и т.д.

При попытке запустить заблокированное приложение появляется такое окно:

S Mode WDAC

В издании S ссылка «Узнать…» ведет в магазин, где можно обновиться до обычного издания.

Кому нужна такая Windows

Осенью 2017 года Microsoft анонсировала устройства вендоров, а заодно изобрела новый ужасный термин для целевой аудитории – Firstline Workers. По версии компании, это два миллиарда неких людей, которые являются первой точкой контакта между их работодателем и клиентами.

S Mode WDAC

Журналист Brad Sams опубликовал полученную от Microsoft статистику переходов с издания S до обычного на устройствах вендоров (апгрейд был бесплатным).

60% остались на S Из перешедших на обычное издание, 60% сделали это в первые сутки Из не перешедших на обычное издание в первые семь дней, 83% остались на S

Трудно поверить, что 6 из 10 человек устроил столь ограниченный режим, но это были устройства из нижнего ценового сегмента (в статистику не попали владельцы Surface Laptop). Поэтому сведения основаны на не самых опытных пользователях или наоборот, слишком опытных ;) Но очевидно, что потенциальная аудитория у такого подхода есть, и она вполне пересекается с типичными жертвами вредоносного и кривого ПО.

S Mode

Первоначально Microsoft планировала сделать бесплатным обновление издания S до обычного Home, но брать за переход на Pro. Этой весной компания сменила стратегию. Начиная с версии 1803 вместо отдельного издания будет просто режим S, который можно бесплатно отключить на всех изданиях и получить обычную Windows 10, будь то Pro или Home.

Видимо, со временем S Mode станет основным в новых компьютерах с Windows. И платное отключение ограничений лишь вызвало бы гнев владельцев новых ПК, не подозревавших о подвохе. Я считаю новый подход более разумным.

S Mode в действии

Я отдаю себе отчет, что подавляющее большинство читателей этого блога такая Windows не устроит. Но ведь интересно же попробовать :) Загнать себя в S Mode вы можете за минуту на любом издании.

Загрузите ZIP-архив и распакуйте файл SIPolicy.p7b в любое место Скопируйте файл в папку C:\Windows\System32\CodeIntegrity Перезагрузите систему и запустите любое стороннее приложение

Вот так блокируется запуск браузера Chrome (скриншот сделан в издании Pro, но в Home работает точно так же).

S Mode WDAC

Когда надоест жить по новым правилам, просто удалите файл из системной папки и перезагрузитесь.

В готовых устройствах S Mode может форсироваться несколько иначе, например, путем размещения файла политик winsipolicy.p7b на разделе EFI в папке EFI\Microsoft\Boot, либо в папке \Windows\Boot\EFI. Но это мелочи реализации.

Понятно, что в S Mode сторонних классических приложений нет изначально, и установить их не получится. Однако в моем примере консоли не блокируются, и дальше я покажу, как это делается в S Mode.

Device Guard

Microsoft не публикует техническую документацию по реализации ограничений в издании S, из-за чего создается некий налет таинственности. Но читатели моего канала в Telegram , наверняка, вспомнили пост про защиту целостности кода с помощью гипервизора (HVCI), где тоже фигурировал файл SIPolicy.p7b.

В Windows 10 реализована мощная защитная технология – Windows Defender Device Guard. Это набор политик, контролирующих целостность исполняемого кода. Они загружаются при запуске системы и применяются ко всему устройству.

Device Guard стоит на трех китах:

Windows Defender Application Control (WDAC) — политики контроля запуска приложений допускают только выполнение явно разрешенного подписанного кода. В файле SIPolicy.p7b выше сконфигурированы политики, блокирующие запуск любых приложений, кроме магазинных и подписанных Microsoft. VSM Protected Code Integrity — целостность кода, защищенная с помощью режима виртуальной безопасности (Virtual Secure Mode). Технология опирается на виртуализацию процессора для дополнительной защиты данных в памяти. В рамках VSM работает механизм Kernel Mode Code Integrity (KMCI), контролирующий целостность кода в режиме ядра. В пользовательском режиме контроль осуществляет аналогичный механизм User Mode Code Integrity (UMCI). Вместе они форсируют настроенные политики WDAC. UEFI Secure Boot — защита файлов загрузки ОС от манипуляций и подмены. Для работы Device Guard требуется загрузка в нативный UEFI и включенный Secure Boot.

S Mode WDAC

Политики контроля приложений (WDAC)

Device Guard вообще и WDAC в частности рассчитаны на применение в крупных организациях. Командлеты PowerShell и групповые политики для работы с политиками целостности кода есть только в корпоративных изданиях Enterprise / Education. Но сама по себе технология защиты реализована и в младших изданиях Windows, что констатирует msinfo32 в моем издании Pro (в домашнем издании эти сведения не отображаются).

S Mode WDAC

Именно политики WDAC препятствуют запуску сторонних приложений в моем примере. В S Mode они также блокируют ряд исполняемых файлов Microsoft, и сейчас я покажу, как это настроено.

Вам понадобится корпоративное издание

Device Guard – большая и сложная тема, поэтому я разберу основы создания и настройки политик приложений, а также подкину вам достаточно документации по этому вопросу.

Для конфигурации и создания политик требуется издание Enterprise или Education, и вы можете воспользоваться бесплатной виртуальной машиной (на ней же и тестировать).

Создание простой блокирующей политики WDAC

В папке C:\windows\schemas\codeIntegrity\ExamplePolicies есть образцы форсирования (Enforce) и аудита (Audit) политик в формате XML. Там, кстати, есть и образец для HVCI.

S Mode WDAC

Для примера выше я взял файл DefaultWindows_Enforced.xml и преобразовал его в двоичный формат PKCS #7 с помощью командлета PowerShell ConvertFrom-CIPolicy.

ConvertFrom-CIPolicy -XmlFilePath C:\windows\schemas\CodeIntegrity\ExamplePolicies\DefaultWindows_Enforced.xml -BinaryFilePath C:\Windows\System32\CodeIntegrity\SIPolicy.p7b

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

Все срабатывания политики регистрируются в журнале событий: Журналы приложений и служб – Microsoft – Windows – Code Integrity. На картинке событие, которое заносится при запуске заблокированного приложения.

S Mode WDAC

Для аудита воспользуйтесь файлом DefaultWindows_Audit.xml. В этом случае ничего не блокируется, но в журнал вносится запись с информационным уровнем.

Блокировка отдельных приложений

Надо понимать, что в состав Windows входит немало приложений, с помощью которых можно выполнить произвольный код, даже если они для этого не предназначены. Формально Microsoft может не считать это уязвимостью, если нет повышения привилегий, но факт остается фактом.

Осмотрительные администраторы блокируют такие приложения с помощью SRP или AppLocker, но можно использовать и Device Guard.

Правила для файлов: пример запрета

Давайте посмотрим, как в S Mode блокируются CMD, PowerShell и прочие системные приложения, позволяющие выполнение кода. Документация перечисляет полный набор доступных уровней правил для файлов — от имени файла до издателя. На другой странице есть образец политики в формате XML, где содержатся правила для приложений, которые могут послужить для выполнения произвольного кода.

В списке нет консолей, но их несложно добавить. Скопируйте файл в текстовый редактор, и двигайтесь по нему сверху вниз.

Узел Rules

В узле Rules сформулированы общие правила Device Guard.

<Rule> <Option>Enabled:UMCI</Option> </Rule>

По умолчанию Device Guard форсирует только KMCI, a это правило включает UMCI (оно активно и в образце DefaultWindows_Enforced.xml). Форсирование UMCI переводит PowerShell 5.1 в режим Constrained Language, значительно снижая поверхность атаки. Это даже важнее, чем просто блокировка запуска powershell.exe, потому что злоумышленники могут задействовать PowerShell и другими способами.

<Rule> <Option>Enabled:Audit Mode</Option> </Rule>

Образец рассчитан на аудит. Если вы планируете форсировать политику, удалите правило.

Узел File Rules

Раздел содержит правила для файлов.

<Deny ID="ID_DENY_WINDBG" FriendlyName="windbg.exe" FileName="windbg.Exe" MinimumFileVersion = "65535.65535.65535.65535" />

По порядку:

ID — идентификатор правила на ваше усмотрение. FriendlyName и FileName — имя файла, причем обойти политику переименованием файла не получится, поскольку отслеживание ведется на уровне имени в ресурсах файла (FileName). Замена ресурсов ломает цифровую подпись, что тоже ведет к блокировке. MinimumFileVersion  — минимальная версия файла, которую разрешает политика. В примере указана максимально возможная версия, т.е. полный запрет. Но если, скажем, уязвимость есть в версии 3.2.1, а в версии 3.2.2 она исправлена, в политике можно указать 3.2.2.

Добавьте полный запрет на запуск консолей:

<Deny ID="ID_DENY_CMD" FriendlyName="cmd.exe" FileName="cmd.exe" MinimumFileVersion = "65535.65535.65535.65535" /> <Deny ID="ID_DENY_POWERSHELL" FriendlyName="powershell.exe" FileName="powershell.exe" MinimumFileVersion = "65535.65535.65535.65535" /> Узел Signers

Раздел содержит правила для подписей. В образце есть такой узел:

<SigningScenario Value="12" ID="ID_SIGNINGSCENARIO_WINDOWS" FriendlyName="User Mode Signing Scenarios"> <ProductSigners> <FileRulesRef> <FileRuleRef RuleID="ID_DENY_BGINFO"/> <FileRuleRef RuleID="ID_DENY_CBD"/> <FileRuleRef RuleID="ID_DENY_KD"/> <FileRuleRef RuleID="ID_DENY_NTKD" /> <FileRuleRef RuleID="ID_DENY_WINDBG" /> ...

Здесь перечислены идентификаторы файловых правил, добавьте свои:

<FileRuleRef RuleID="ID_DENY_CMD"/> <FileRuleRef RuleID="ID_DENY_POWERSHELL"/>

Сохраните файл с любым именем, например, FilePolicy_Enforced.xml где-нибудь в C:\temp.

Объединение и применение политик

Теперь надо объединить политику с правилами для файлов с общей политикой контроля кода. Тем самым будут блокироваться не только сторонние приложения, но и файлы из списка.

Я буду форсировать политику, и чтобы не набирать длинные пути, я скопировал в C:\temp образец DefaultWindows_Enforced.xml. Для объединения используется командлет Merge-CIPolicy.

cd c:\temp Merge-CIPolicy -PolicyPaths '.\DefaultWindows_Enforced.xml','.\FilePolicy_Enforced.xml' -OutputFilePath '.\MergedPolicy.xml'

На выходе получается файл MergedPolicy.xml, который теперь можно конвертировать в политику. Я сразу помещаю сформированный файл в системную папку.

ConvertFrom-CIPolicy -XmlFilePath C:\temp\MergedPolicy.xml -BinaryFilePath C:\Windows\System32\CodeIntegrity\SIPolicy.p7b

Результат после перезагрузки:

S Mode WDAC

Работает! Конечно, на практике обязательно потребуется не только запретить что-то, но и разрешить какие-то приложения.

Разрешение отдельных приложений

В качестве примера возьмем браузер Chrome и разрешим его запуск, сохраняя запрет на прочие сторонние приложения и консоли.

Создание правила для издателя

Правило Publisher будет опираться на сертификат издателя, которым подписан исполняемый файл браузера Chrome (см. также примечание Артема в комментариях по поводу правил Publisher и FilePublisher).

Командлет New-CIPolicy умеет сканировать указанную папку и создавать правила в соответствии с заданными параметрами. Пример продолжает работу в папке temp.

New-CIPolicy -Level Publisher -ScanPath "C:\Program Files (x86)\Google\Chrome\Application" -FilePath '.\AllowPolicy.xml' -UserPE

Здесь задается уровень правил для издателя, а параметр UserPEs обеспечивает применение политики к приложениям, запускаемым в режиме пользователя (без этого параметра защита блокирует запуск). По результатам сканирования создается файл AllowPolicy.xml, где в разделе Signers вы найдете правило для конкретного сертификата Symantec, которым подписан исполняемый файл Chrome.

<Signer ID="ID_SIGNER_S_2B" Name="Symantec Class 3 SHA256 Code Signing CA"> <CertRoot Type="TBS" Value="A08E79C386083D875014C409C13D144E0A24386132980DF11FF59737C8489EB1" /> <CertPublisher Value="Google Inc" /> </Signer>

Файл политик формируется для режима аудита, поэтому для форсирования надо удалить из него правило Enabled:Audit Mode.

Объединение и применение политик

Теперь нужно объединить три правила уже знакомым командлетом Merge-CIPolicy. Команда та же, что и раньше, но в теперь список политик добавляется разрешающая:

Merge-CIPolicy -PolicyPaths '.\DefaultWindows_Enforced.xml','.\FilePolicy_Enforced.xml', '.\AllowPolicy.xml' -OutputFilePath '.\MergedPolicy.xml'

Создание файла политики из XML вы уже видели:

ConvertFrom-CIPolicy -XmlFilePath C:\temp\MergedPolicy.xml -BinaryFilePath C:\Windows\System32\CodeIntegrity\SIPolicy.p7b

В результате Chrome будет запускаться, а все сторонние приложения и консоли – блокироваться.

S Mode WDAC

Тему разрешения запуска неподписанных приложений я оставляю вам для самостоятельного изучения ;)

Полезные материалы

Цель этой статьи – снять завесу таинственности с S Mode и познакомить вас с основами политик контроля приложений. Для внедрения на практике придется повозиться подольше, и я подобрал для вас ссылки по теме.

На момент публикации статьи документация не переведена на русский язык, но это не должно быть проблемой для ИТ-специалиста, берущегося развертывать политики WDAC.

Дискуссия и опрос

Device Guard и S Mode в частности не являются непробиваемой защитой. Исследователи время от времени публикуют способы обхода Device Guard, и наверное, невозможно полностью защитить Windows, не превращая ее в бесполезную для работы ОС. Но контроль запуска приложений значительно снижает поверхность атаки, эффективно защищая от массовых угроз.

У меня отец пользуется только браузером (Chrome, но я сам пересадил его с IE), торрентом, проигрывателем видео, Skype и Telegram. И я время от времени нахожу у него какие-то левые программы и прочие агенты mail.ru. Думаю, он вполне смог бы работать в S Mode, и я считаю этот режим правильным направлением в контексте укрепления безопасности экосистемы Windows в целом.

Microsoft не бросит Магазин, и там фактически уже есть набор приложений (не UWP, так Desktop Bridge), который должен удовлетворить не самых требовательных пользователей. Компания также возлагает надежды на Progressive Web Apps (PWA). Начиная с версии 1803 их поддерживает Edge, а в качестве канала доставки можно использовать Магазин.

Расскажите в комментариях, есть ли у вас родственники или знакомые, которым было бы достаточно S Mode, и рекомендовали бы вы этот режим им? Опрос покажет количественный расклад. Если S Mode хватило бы лично вам, выбирайте первый пункт.

Есть ли у вас родственники или знакомые, которых устроил бы S Mode?

Да, если бы в магазине был сторонний браузер (35%, голосов: 65) Нет (32%, голосов: 58) Да (23%, голосов: 42) Не знаю / Моего варианта тут нет (10%, голосов: 19)

Проголосовало: 184 [архив опросов]

Загрузка ... Загрузка ...
Своими руками на тему сша

Похожие записи:



Поделки из бутылок звери

Схема монтажного блока 17.3722-01м ваз

Стабилизатор тока и напряжения для зарядного устройства схема