Сканер уязвимостей TrustWave не выполняет сканирование из-за компьютера с Windows 10, на котором запущен RDP:
Алгоритмы блочного шифрования с размером блока 64 бита (такие как DES и 3DES), атака по случаю дня рождения, известная как Sweet32 (CVE-2016-2183)
ПРИМЕЧАНИЕ. В системах Windows 7/10, использующих RDP (протокол удаленного рабочего стола), уязвимый шифр, который следует отключить, помечен как «TLS_RSA_WITH_3DES_EDE_CBC_SHA».
Используя IIS Crypto (от Nartac), я попытался применить шаблон «Best Practices», а также шаблон PCI 3.1, однако оба они включают небезопасный шифр (TLS_RSA_WITH_3DES_EDE_CBC_SHA):
Если я отключу этот шифр, RDP из этот компьютер на многих станциях Windows перестает работать (он все еще работает на некоторых серверах 2008 R2 и 2012 R2). Клиент RDP просто сообщает: «Произошла внутренняя ошибка» и журнал событий:
Произошла фатальная ошибка при создании учетных данных клиента TLS. Состояние внутренней ошибки - 10013.
Я проверил журнал событий одного из серверов и увидел эти два сообщения
Запрос на соединение TLS 1.2 был получен от удаленного клиентского приложения, но ни один из наборов шифров, поддерживаемых клиентским приложением, не поддерживается сервером. Запрос на соединение SSL не удался.
Было создано следующее критическое предупреждение: 40. Состояние внутренней ошибки - 1205.
Как я могу исправить уязвимость системы безопасности, не нарушая исходящий RDP?
Или, если это невозможно, Есть ли что-то, что я могу сделать на каждом хосте RDP, к которому я больше не могу подключиться, который обрабатывает его с этой стороны?
--- Обновление # 1 ---
После отключения TLS_RSA_WITH_3DES_EDE_CBC_SHA на компьютере с Windows 10 я попытался подключиться к нескольким хостам RDP (половина из них завершилась с ошибкой «Внутренняя ошибка ...»). Я сравнил один из этих хостов, который я жестяная банка соединиться с тем, что я не может присоединиться. Оба - 2008 R2. Оба имеют одинаковую версию RDP (6.3.9600, поддерживается протокол RDP 8.1).
Я сравнил протоколы и шифры TLS, используя IIS Crypto, чтобы выполнить «Сохранить шаблон» с их текущими настройками, чтобы я мог сравнить файлы шаблонов. Они были идентичны! Так что, как бы то ни было, проблема не в том, что на хосте отсутствует набор микросхем. Вот снимок экрана с файлами Beyond Compare:
Чем могут отличаться два хоста RDP, вызывающие эту проблему, и как ее исправить?
IIS Crypto имеет возможность установить параметры как на стороне сервера (входящая), так и на стороне клиента (исходящая). Есть несколько шифров, которые вам нужно оставить включенными на стороне клиента для совместимости.
Чтобы делать то, что вы хотите, я лично использую следующее:
При желании перезагрузитесь (и у вас будет физический доступ к машине).
Перезагрузка здесь должна привести к правильному конечному состоянию.
Фактически вы хотите только отключить входящий 3DES, но по-прежнему разрешить исходящее использование указанного набора шифров.
Изменить (2018-09-26): я обнаружил, что отключение 3DES на 2012R2 НЕ нарушает RDP, но ДЕЙСТВИТЕЛЬНО ломается на 2008 R2. Поддерживаемые параметры в разных ядрах различаются.
Я поделюсь своим ответом из TechNet нить но сначала BLUF:
Заключение о сбое сервера: Скорее всего, у вас есть еще какое-то различие между системами. Вы подключаетесь между разными версиями ОС, в одной системе включен FIPS, а в другой - нет, или у вас есть разные ограничения на шифрование в HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers
. Я бы обязательно включил регистрацию SCHANNEL в системе, которая делает поработайте, чтобы определить, какой шифр используется. Хотел бы услышать ответ, если вы каким-то образом заставили RDP работать с альтернативным шифром.
Копия сообщения:
Мы заставили его работать!
Очевидно, у 2008 и 2012 годов есть проблемы с синтаксисом, а для 2008/7 требуется завершающий / 168. 2012 / 8.1 / 10 - нет.
ключ на 2008 год выглядит так:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\Triple DES 168/168
А ключ на 2012 год выглядит так:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\Triple DES 168
Я могу подтвердить, что использование «Triple DES 168/168» НЕ отключает 3DES в системе. Вы можете убедиться в этом сами с помощью сканера протокола (например, Nessus) или включив ведение журнала SCHANNEL:
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL] "EventLogging"=dword:00000007
Тогда у вас будут, например, события в журнале SYSTEM;
Подтверждение связи клиента SSL успешно завершено. Согласованные криптографические параметры следующие.
Протокол: TLS 1.0 CipherSuite: 0x2f Уровень обмена: 1024
Для меня результатом является 0xa, который Google показывает как TLS_RSA_WITH_3DES_EDE_CBC_SHA.
Когда я использую «Triple DES 168» (без / 168), идентификатор системного события 36880 не появляется, и сеанс RDP блокируется.
Согласно статье: Системная криптография: используйте FIPS-совместимые алгоритмы для шифрования, хеширования и подписи.
Службы удаленных рабочих столов (RDS). Для шифрования сетевых подключений служб удаленных рабочих столов этот параметр политики поддерживает только алгоритм шифрования Triple DES.
Этот параметр также влияет на службы терминалов в Windows Server 2003 и более поздних версиях Windows. Эффект зависит от того, используется ли TLS для аутентификации сервера.
Если TLS используется для аутентификации сервера, этот параметр приводит к использованию только TLS 1.0.
По умолчанию, если TLS не используется и этот параметр не включен на клиенте или на сервере, канал протокола удаленного рабочего стола (RDP) между сервером и клиентом зашифрован с использованием алгоритма RC4 со 128-битным длина ключа. После включения этого параметра на компьютере под управлением Windows Server 2003 выполняется следующее: канал RDP зашифрован с использованием алгоритма 3DES в режиме Cipher Block Chaining (CBC) с длиной ключа 168 бит. Алгоритм SHA-1 используется для создания дайджестов сообщений. Для подключения клиенты должны использовать клиентскую программу RDP 5.2 или более позднюю версию.
Таким образом, оба они поддерживают идею о том, что RDP может использовать только 3DES. Однако эта статья предполагает, что доступен более широкий диапазон шифров: Проверка FIPS 140
Набор криптографических алгоритмов, которые будет использовать сервер протокола удаленного рабочего стола (RDP), ограничен следующими параметрами: - CALG_RSA_KEYX - алгоритм обмена открытым ключом RSA - CALG_3DES - алгоритм шифрования Triple DES - CALG_AES_128 - 128-битный AES - CALG_AES_256 - 256-битный AES - CALG_SHA - CALG_SHA Алгоритм хеширования SHA - CALG_SHA_256 - алгоритм хеширования SHA 256 бит - CALG_SHA_384 - алгоритм хеширования SHA 384 бит - CALG_SHA_512 - алгоритм хеширования SHA 512 бит
В конечном итоге неясно, может ли RDP поддерживать протоколы, отличные от 3DES, когда включен режим FIPS, но данные свидетельствуют о том, что это не так.
Я не вижу доказательств того, что Server 2012 R2 будет работать иначе, чем Server 2008 R2, однако кажется, что Server 2008 R2 был основан на соответствии FIPS 140-1, а Server 2012 R2 следует FIPS 140-2, поэтому вполне возможно, что Server 2012 R2 поддерживает дополнительные протоколы. Обратите внимание на дополнительные протоколы в Проверка FIPS 140 ссылка на сайт.
В заключение: Я не думаю, что Server 2008 R2 может поддерживать RDP в режиме FIPS с отключенным 3DES. Я рекомендую проверить, соответствует ли ваша система условиям для атаки SWEET32 (более 768 ГБ отправлено за один сеанс) и стоит ли отключать 3DES для удаления возможности RDP. Существуют и другие утилиты для управления серверами за пределами RDP, особенно в мире, где виртуализация является очень распространенным явлением.
У меня была такая же проблема, установка патча KB3080079 на сервере включает поддержку TLS 1.1 и 1.2.
Обратите внимание, что для клиентов Windows 7 вам необходимо установить обновление клиента rdp (KB2830477), в противном случае только Windows 8+ сможет подключиться.
По-видимому, в 2008 и 2012 годах есть проблемы с синтаксисом, а для 2008/7 требуется завершающий / 168. 2012 / 8.1 / 10 нет.
ключ в 2008 году выглядит так: HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Control \ SecurityProviders \ SCHANNEL \ Ciphers \ Triple DES 168/168
** Отличная находка, у меня была точно такая же проблема на некоторых контроллерах домена Windows 2008 R2, как ни странно, мои серверы 2008R2 кажутся нормальными ... и мои серверы 2012R2 тоже работают нормально. Надо взломать разборку старых DC :)