remote credential guard что это
Remote Credential Guard защищает учетные данные удаленного рабочего стола в Windows 10
Удаленная проверка учетных данных в Windows 10
Эта функция предназначена для устранения угроз, прежде чем она перерастет в серьезную ситуацию. Он помогает защитить ваши учетные данные через подключение к удаленному рабочему столу, перенаправляя запросы Kerberos обратно на устройство, которое запрашивает подключение. Он также предоставляет возможности единой регистрации для сеансов удаленного рабочего стола.
В случае какого-либо несчастья, когда целевое устройство скомпрометировано, учетные данные пользователя не раскрываются, поскольку как целевые, так и производные учетные данные никогда не отправляются на целевое устройство.
Способ работы Remote Credential Guard очень похож на защиту, предлагаемую Credential Guard на локальном компьютере, за исключением того, что Credential Guard также защищает сохраненные учетные данные домена через диспетчер учетных данных.
Человек может использовать Remote Credential Guard следующими способами:
Требования к аппаратному и программному обеспечению
Чтобы обеспечить бесперебойную работу Remote Credential Guard, убедитесь, что выполнены следующие требования клиента и сервера Remote Desktop.
Включить удаленную проверку учетных данных через реестр
Чтобы включить Remote Credential Guard на целевом устройстве, откройте редактор реестра и перейдите к следующему ключу:
HKEY_LOCAL_MACHINE \ System \ CurrentControlSet \ Control \ LSA
Закройте редактор реестра.
Вы можете включить Remote Credential Guard, выполнив следующую команду с повышенным уровнем CMD:
Включите Remote Credential Guard с помощью групповой политики
Можно использовать Remote Credential Guard на клиентском устройстве, установив групповую политику или используя параметр с подключением к удаленному рабочему столу.
В консоли управления групповой политикой выберите Конфигурация компьютера> Административные шаблоны> Система> Делегирование полномочий .
Теперь в поле Использовать следующий ограниченный режим выберите Требуется удаленная защита учетных данных. Другой параметр Режим ограниченного администрирования также присутствует. Его значение в том, что, когда Remote Credential Guard не может быть использован, он будет использовать режим Restricted Admin.
В любом случае, ни Remote Credential Guard, ни режим Restricted Admin не будут отправлять учетные данные в виде открытого текста на сервер удаленного рабочего стола.
Нажмите кнопку ОК и выйдите из консоли управления групповой политикой.
Используйте Remote Credential Guard с параметром для подключения к удаленному рабочему столу
Если вы не используете групповую политику в своей организации, вы можете добавить параметр remoteGuard при запуске подключения к удаленному рабочему столу, чтобы включить Remote Credential Guard для этого подключения.
Что нужно учитывать при использовании Remote Credential Guard
Вы можете прочитать больше об этом в Technet.
Защищаем удаленный сервер на 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:
Зато возможна настройка в срезе приложения: например, если вы хотите дать доступ к 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). Почитать подробнее можно в документации, ну а я добавлю, что для работы механизма достаточно включить его поддержку на сервере — например, через реестр командой:
А потом подключаться к серверу командой:
Теперь учетные данные в безопасности, а сервер достаточно защищен. Правда, в материале я осознанно не касался вопросов защиты от злонамеренного хостера, но тут все сводится в общем-то к одному — к шифрованию дисков.
Как работает Credential Guard в Защитнике Windows
Область применения
Диспетчер учетных данных, NTLM и Kerberos изолируют секреты с помощью безопасности на основе виртуализации. Предыдущие версии Windows хранили секреты в локальной системе безопасности (LSA). В версиях Windows, предшествовавших Windows10, за хранение секретов, используемых в операционной системе, отвечала служба LSA, которая размещала их в памяти своего процесса. С появлением Credential Guard в Защитнике Windows процесс LSA в операционной системе стал взаимодействовать с новым компонентом— изолированным процессом LSA, который отвечает за хранение и защиту секретов. Данные, хранимые в изолированном процессе LSA, защищены с помощью безопасности на основе виртуализации и недоступны для остальной операционной системы. LSA взаимодействует с изолированным процессом LSA с помощью удаленных вызовов процедур.
По соображениям безопасности в изолированном процессе LSA не хранятся никакие драйверы устройств. Он содержит только небольшую группу двоичных файлов операционной системы, которые необходимы для обеспечения безопасности. Все эти двоичные файлы подписаны сертификатом, который является доверенным для средства обеспечения безопасности на основе виртуализации, а перед запуском файла в защищенной среде эти подписи проверяются.
При включенном Credential Guard в Защитнике Windows NTLMv1, MS-CHAPv2, Digest и CredSSP не могут использовать учетные данные для входа в систему. Таким образом, единый вход не работает с этими протоколами. Однако приложения могут запросить учетные данные или использовать учетные данные, хранимые в хранилище Windows Vault, которые не защищены Защитник Windows credential Guard ни с одним из этих протоколов. Рекомендуется, чтобы ценные учетные данные, такие как учетные данные входа, не использовались ни в одной из этих протоколов. Если эти протоколы должны использоваться пользователями домена или Azure AD, для таких случаев необходимо предоставить дополнительные учетные данные.
Если включить Credential Guard в Защитнике Windows, Kerberos запрещает неограниченное делегирование Kerberos или шифрование DES не только в отношении учетных данных для входа в систему, но также относительно запрошенных или сохраненных учетных данных.
Ниже представлен краткий обзор изолированности LSA с помощью безопасности на основе виртуализации:
Credential Guard в Защитнике Windows: требования
Область применения
Чтобы Защитник Windows безопасности учетных данных, компьютеры, которые вы защищаете, должны соответствовать определенным базовым требованиям к оборудованию, прошивке и программному обеспечению, которые мы будем называть требованиями к оборудованию и программному обеспечению. Кроме того, Credential Guard в Защитнике Windows блокирует определенные средства проверки подлинности, поэтому приложения, которым требуются заблокированные средства, прекратят работу. Мы будем ссылаться на эти требования как требования к приложению. Помимо этих требований, компьютеры могут соответствовать дополнительным требованиям к оборудованию и прошивке и получать дополнительные средства защиты. Эти компьютеры будут более защищены от определенных угроз. Подробные сведения о базовой защите, а также средствах защиты для повышения уровня безопасности, связанные с параметрами оборудования и встроенного ПО, доступные в 2015-2017 годах см. в таблицах в разделе Вопросы безопасности.
Требования к оборудованию и программному обеспечению
Чтобы обеспечить базовую защиту от попыток на уровне ОС считать учетные данные домена диспетчера учетных данных, а также учетные данные, извлеченные из NTLM и Kerberos, в Credential Guard в Защитнике Windows используются приведенные ниже функции.
Требования к безопасности на основе виртуализации.
Развертывание Credential Guard в Защитнике Windows на виртуальных машинах
Credential Guard может защищать секретные сведения на виртуальной машине Hyper-V, как и на физическом компьютере. Развертывание Credential Guard на виртуальной машине обеспечивает защиту секретных сведений от атак внутри виртуальной машины. Credential Guard не обеспечивает дополнительный уровень защиты от атак привилегированной системы, исходящих с узла.
Требования для запуска Credential Guard в Защитнике Windows на виртуальных машинах Hyper-V
Сведения о других платформах для хостов см. в Windows Server 2016 и Hyper-V на основе функций безопасности на других платформах.
Сведения о требованиях к оборудованию и программному обеспечению Защитник Windows remote Credential Guard см. в Защитник Windows требования к удаленной службе учетных данных.
Требования к приложениям
При включении Credential Guard в Защитнике Windows блокируются определенные средства проверки подлинности, поэтому приложения, которым требуются заблокированные средства, прекратят работу. Приложения должны быть протестированы перед развертыванием, чтобы обеспечить совместимость с уменьшенными функциональными возможностями.
Включение Credential Guard в Защитнике Windows на контроллерах домена не поддерживается. На контроллере домена размещаются службы проверки подлинности, которые интегрируются с процессами, изолируемыми при включении Credential Guard в Защитнике Windows, что приводит к сбоям.
Credential Guard в Защитнике Windows не обеспечивает защиту для базы данных Active Directory или диспетчера учетных записей безопасности (SAM). Учетные данные, защищенные с помощью Kerberos и NTLM при включенном Credential Guard в Защитнике Windows, также находятся в базе данных Active Directory (на контроллерах домена) и SAM (для локальных учетных записей).
Предложения прекратят работу, если потребуется приведенное ниже:
Приложения будут запрашивать учетные данные и подвергать их риску, если для них требуется приведенное ниже.
Приложения могут приводить к проблемам с производительностью, когда пытаются подключить изолированный процесс Credential Guard в Защитнике Windows.
Службы и протоколы, зависящие от Kerberos, например общие файловые ресурсы, удаленный рабочий стол и BranchCache, продолжают работать и не попадают под действие Credential Guard в Защитнике Windows.
Соображения безопасности
Все компьютеры, соответствующие базовой защите для оборудования, встроенного ПО и программного обеспечения, могут использовать Credential Guard в Защитнике Windows. Компьютеры, соответствующие дополнительным требованиям, могут обеспечить дополнительную защиту, чтобы уменьшить уязвимость. В следующих таблицах описываются базовые меры защиты, а также меры защиты для обеспечения повышенной безопасности, которые связаны с параметрами оборудования и встроенного ПО, доступными в 2015–2017 гг.
Начиная с Windows 10 версии 1607 на новых поставляемых компьютерах должен по умолчанию быть включен доверенный платформенный модуль (TPM 2.0).
Если вы OEM, см. требования pc OEM для Защитник Windows credential Guard.
Базовые меры защиты
Windows Server 2016 в роли контроллера домена не поддерживает Credential Guard.
В следующих таблицах приводятся дополнительные требования для повышенной безопасности. Мы настоятельно рекомендуем выполнить дополнительные требования для повышенной безопасности в целях значительного повышения уровня безопасности, обеспечиваемого Credential Guard в Защитнике Windows.
2015: дополнительные требования к безопасности, начиная с Windows 10 версии 1507 и Windows Server 2016 Technical Preview 4
2016 Дополнительные требования к безопасности начиная с Windows 10 версии 1607 и Windows Server 2016
В следующих таблицах приводятся дополнительные требования для повышенной безопасности. Системы, которые соответствуют этим дополнительным требованиям, могут предоставлять дополнительные средства защиты.
2017 Дополнительные требования к безопасности начиная с Windows 10 версии 1703
В следующей таблице перечислены требования к Windows 10 версии 1703, которые являются дополнительными ко всем перечисленным выше требованиям.
Что касается VBS-обеспечения защиты NX для служб выполнения UEFI:
Это касается только памяти службы UEFI, а не памяти службы загрузки UEFI.
Эта защита применяется VBS в таблицах страниц ОС.
Также имейте в виду вот что.
Не используйте разделы, которые можно и писать, и выполнять
Не пытайтесь напрямую изменять исполняемую системную память
Protect Remote Desktop credentials with Windows Defender Remote Credential Guard
Applies to
Introduced in Windows 10, version 1607, Windows Defender Remote Credential Guard helps you protect your credentials over a Remote Desktop connection by redirecting Kerberos requests back to the device that’s requesting the connection. It also provides single sign-on experiences for Remote Desktop sessions.
Administrator credentials are highly privileged and must be protected. By using Windows Defender Remote Credential Guard to connect during Remote Desktop sessions, if the target device is compromised, your credentials are not exposed because both credential and credential derivatives are never passed over the network to the target device.
For information on Remote Desktop connection scenarios involving helpdesk support, see Remote Desktop connections and helpdesk support scenarios in this article.
Comparing Windows Defender Remote Credential Guard with other Remote Desktop connection options
The following diagram helps you to understand how a standard Remote Desktop session to a server without Windows Defender Remote Credential Guard works:
The following diagram helps you to understand how Windows Defender Remote Credential Guard works, what it helps to protect against, and compares it with the Restricted Admin mode option:
As illustrated, Windows Defender Remote Credential Guard blocks NTLM (allowing only Kerberos), prevents Pass-the-Hash (PtH) attacks, and also prevents use of credentials after disconnection.
Use the following table to compare different Remote Desktop connection security options:
