Cve 2016 2183 как починить окна
Обновлено: 04.07.2024
Я занимаюсь сертификацией Cyber Essentials Plus уже несколько лет, и одна область, которая, кажется, всегда застает людей врасплох, — это использование более слабых шифров в их среде, особенно в Windows. Основная область, которую я всегда нахожу неисправной, — это уязвимость Sweet32, которая при обнаружении с помощью Tenable Nessus сообщает о ней как о CVSS 7.5, что является ошибкой схемы.
Что теперь с CVSS?
CVSS – это система оценки систем уязвимостей. Это стандартная система оценки, позволяющая оценивать результаты по определенному числу в диапазоне от 0 до 10. Они отображаются следующим образом:
| Нет | 0,0 |
| Низкий | 0,1 – 3,9< /td> |
| Средний | 4,0–6,9 |
| Высокий | 7,0–8,9< /td> |
| Критический | 9.0 – 10.0 |
Если вы не знали об этом при проведении аудита Cyber Essentials, вы должны провести оценку уязвимости вашей внутренней сети, которая находится в области оценки (а также вашего внешнего шлюза), если какие-либо выводы имеют оценку CVSS 7.0 или более поздней версии классифицируется как сбой и требует исправления, прежде чем вы сможете получить сертификацию.
Эта статья в блоге была частично написана, чтобы помочь людям понять, что им нужно сделать, чтобы решить эту проблему, и помочь им легче получить Cyber Essentials Plus, а также повысить осведомленность о том, что в среде не включены более слабые шифры SSL.< /p>
Что такое Sweet32?
Уязвимость Sweet32 существует с 2016 года. Sweet32 — это название атаки, выпущенной парой исследователей безопасности из Французского национального исследовательского института компьютерных наук (INRIA).
Их выводам были присвоены CVE-2016-2183 и CVE-2016-6329. Было обнаружено, что атака использует слабость конструкции некоторых шифров SSL, шифры, используемые в распространенных протоколах, таких как TLS, SSH, IPSec и OpenVPN.
Атака использует более старые шифры, которые, как известно, являются более слабыми и обеспечивают меньшую защиту от атак. Атака Sweet32 позволяет злоумышленнику в определенных ограниченных обстоятельствах восстанавливать небольшие части открытого текста при шифровании с помощью 64-битных блочных шифров. например (3DES и Blowfish).
Что такое блочные шифры
Блочные шифры — это тип симметричного алгоритма, который шифрует открытый текст блоками, как следует из названия, а не побитно. Одной из характеристик таких шифров является длина блока; который определяет размер фрагментов, на которые открытый текст разбивается, а затем шифруется. Важно отметить, что длина блока шифра не зависит от длины ключа. Таким образом, даже если вы выберете большой размер ключа для своего шифрования, длина блока шифра может наложить свои ограничения и, в данном случае, уязвимости.
Как удалить уязвимость Sweet32?
Чтобы защититься от этой уязвимости, вам необходимо отключить некоторые старые шифры в реестре. Это можно сделать следующим образом:
Отключить RC4
Чтобы отключить RC4 на вашем сервере Windows, установите следующие разделы реестра:
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC4 128/128] «Enabled»=dword:00000000 [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC4 40/128] "Enabled"=dword:00000000 [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC4 56/128] "Enabled"=dword:00000000
Отключить 3DES
Чтобы отключить 3DES на сервере Windows, установите следующий раздел реестра:
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\Triple DES 168] «Enabled»=dword:00000000
Если ваша версия Windows предшествует Windows Vista (т. е. XP, 2003), вам потребуется установить следующий раздел реестра:
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\Triple DES 168/168] «Enabled»=dword:00000000
Более 80% веб-сайтов в Интернете уязвимы для взлома и атак. В роли инженеров службы поддержки веб-хостов мы периодически проверяем безопасность и обновляем серверы, чтобы защитить их от взлома.
Недавняя ошибка, затрагивающая серверы, — это уязвимость SWEET32. Эта ошибка, использующая слабый шифр 3DES-CBC в шифровании TLS, вызвала у многих владельцев серверов панику по поводу безопасности их данных.
Если вы видите, что ваш веб-сайт не проходит проверку безопасности с этим сообщением, это означает, что ваш сервер уязвим для атак SWEET32.
«SSL/TLS-сервер поддерживает короткие блоки (атака SWEET32)»
Что такое атака дня рождения SWEET32?
После этого хакеры могут легко расшифровать ваши ценные данные с помощью метода под названием «Атака дня рождения». Вот как это работает:
Веб-сервер шифрует данные с помощью криптографических ключей.Эти ключи выбираются случайным образом, и вероятность того, что любые два клиента получат один и тот же ключ, очень мала.
Злоупотребляя уязвимостью SWEET32, злоумышленник может отправить большой объем фиктивных данных и получить блоки зашифрованного текста, совпадающие с данными клиента.
Чтобы разбить его:
- Злоумышленник перехватывает все данные, отправляемые вашему клиенту.
- Злоумышленник отправляет фиктивные данные на ваш сервер до тех пор, пока ключ, используемый для клиента, не совпадет с сеансовым ключом злоумышленника.
- После совпадения конфиденциальные данные можно расшифровать, определив, как был выбран ключ.
Уязвимы ли ваши серверы для атаки SWEET32?
Протокол OpenSSL использует уязвимые шифры Triple-DES для шифрования данных. Поэтому, если ваши веб-серверы, такие как Apache, NginX и т. д., используют OpenSSL с поддержкой уязвимого шифра «Triple-DES», ваш сервер подвержен атаке.
Если на ваших серверах работают версии OpenSSL до 1.0.1, которые не могут поддерживать стойкие шифры, ваши серверы уже уязвимы и для многих других атак, таких как уязвимость внедрения CCS.
Первое, что мы делаем, это проверяем версию сервера OpenSSL:
Чтобы проверить шифры, включенные на сервере OpenSSL, мы используем команду «nmap». Код «3DES» указывает на наборы шифров, в которых используется тройное шифрование DES. Это те, которые мы отключаем для безопасности сервера.
Как устранить уязвимость SWEET32
Чтобы защитить конфиденциальную информацию от этой критической уязвимости, связанной с атакой дня рождения SWEET32, мы отключаем все 64-битные слабые блочные шифры. В целях повышения безопасности мы разрешаем использовать только стойкие шифры, такие как AES.
Несмотря на то, что OpenSSL отключил поддержку слабых шифров, начиная с версии 1.1.0 и выше, мы видели, что на многих серверах по-прежнему работают старые уязвимые версии.
Для серверов, которыми мы управляем, наши технические специалисты обновляют все серверное программное обеспечение, чтобы защитить их от атак. Если на ваших серверах работают уязвимые версии, вам следует немедленно отключить эти слабые шифры.
[ Не ждите атаки. Защитите свои серверы прямо сейчас! Наши специалисты по безопасности серверов мирового класса готовы защитить ваши серверы. ]
Как мы защищаем веб-серверы Apache и Nginx от ошибки SWEET32
На серверах, на которых работает веб-сервер Apache, мы защищаем их следующим образом:
- Отредактируйте файл конфигурации Apache SSL в ‘ /etc/apache2/mods-available/ssl.conf’
- Перейдите в раздел SSL и убедитесь, что старые протоколы, такие как SSLv2 и SSLv3, отключены.
- Перейдите к текстовому разделу CIPHER и обновите запись, указав соответствующий «SSLCipherSuite».
- Перезапустите веб-сервер Apache.
На серверах с веб-сервером NginX мы делаем следующие шаги:
- Отредактируйте файл конфигурации Nginx ‘/etc/nginx/nginx.conf’.
- Перейдите в раздел SSL, установите безопасные протоколы и обновите текст шифра, указав соответствующий список «шифров».
- Перезапустите веб-сервер после сохранения новых настроек.
Как исправить ошибку SWEET32 на серверах RedHat и CentOS
Серверы RedHat и CentOS используют собственный пакет OpenSSL, который обновляется из их репозитория с помощью команды «yum». Но версии RHEL/CentOS 5,6,7 используют уязвимые пакеты OpenSSL.
Чтобы узнать версию пакета OpenSSL на сервере, выполняем команду:
Чтобы немедленно смягчить атаку, пока новый защищенный пакет OpenSSL не станет доступен в репозиториях RedHat и CentOS, мы отключаем слабые шифры в службах, использующих SSL.
Службы, которые мы обновляем с помощью надежных шифров, включают веб-серверы, такие как Apache и NginX, почтовые серверы, такие как Exim, сервер POP/IMAP, FTP-сервер и т. д.
Устранение уязвимости SWEET32 на серверах Debian и Ubuntu
Чтобы проверить версию пакета OpenSSL на сервере, мы используем команду:
Если используются старые уязвимые версии, мы обновляем пакет OpenSSL до последней поддерживаемой версии.
Последняя безопасная версия OpenSSL еще не доступна в этих пакетах. Поэтому в качестве немедленной меры мы отключаем слабые шифры во всех общедоступных службах с поддержкой OpenSSL.
Защита серверов OpenSUSE от ошибки SWEET32
В OpenSUSE инструмент zypper помогает нам обновлять и устанавливать последние пакеты OpenSSL на сервер.
Эта команда используется для обновления вашего сервера Suse:
Чтобы уменьшить уязвимость SWEET32, мы отключаем 3DES и другие слабые шифры во всех общедоступных службах на основе SSL.
Как защитить свой веб-сервер IIS от ошибки SWEET32
Чтобы отключить слабые шифры на веб-сервере Windows IIS, мы редактируем соответствующий ему реестр. Вот как это сделать:
- Нажмите "Пуск", выберите "Выполнить", введите "regedit" в поле "Открыть" и нажмите "ОК".
- Найдите следующий ключ реестра безопасности:
Перейдите к подразделу SCHANNEL\Ciphers, который используется для управления такими шифрами, как DES и RC4.
Отредактируйте подраздел «SCHANNEL\Ciphers\Triple DES 168» и задайте для данных значения DWORD значение 0x0 .
Редактирование реестра производится очень осторожно, так как любая ошибка может привести к тому, что сервер перестанет работать. Возможно, потребуется перезапуск сервера, чтобы обновления вступили в силу.
Действия по ограничению шифров и редактированию реестра могут различаться в зависимости от версии Windows на вашем сервере. Поэтому рекомендуется делать это только с помощью специалиста.
Наши специалисты по безопасности Bobcare специализируются на обеспечении безопасности серверов наших клиентов. Делая надлежащие резервные копии реестра и других соответствующих конфигураций, мы гарантируем, что серверы не испортятся.
Короче..
SWEET32 — это уязвимость в шифрах 3DES-CBC, которые используются на большинстве популярных веб-серверов. Сегодня мы увидели, как мы исправили это в популярных операционных системах и веб-серверах.
Старые операционные системы, такие как Windows XP, используют 3DES-CBC для установления соединений. Исследователи показали, что эти соединения можно легко расшифровать.
Bobcares помогает интернет-компаниям любого размера обеспечить безопасность и время безотказной работы мирового уровня, используя проверенные решения. Если вы хотите узнать, как сделать ваш сервер более надежным, мы будем рады поговорить с вами.
Похожие сообщения:
Ваш сервер может быть под угрозой!
Не паникуйте! Мы оперативно защитим ваши сайты от атак SWEET32.
var google_conversion_label = "owonCMyG5nEQ0aD71QM";
Я внес изменения в regedit, чтобы остановить атаку IIS, затем повторно просканировал сервер с помощью Trustwave, но он по-прежнему считается уязвимым. Есть предложения?
Необходимо добавить в реестр параметр 'Enabled' и установить для него значение 0. Таким образом, полный путь для отключения в IIS:
"HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\Triple DES 168. ”
новое двойное слово включено = 0
Настройка шифрования зависит от версии Windows на сервере. В более ранних версиях, если вы не настроили значение Enabled, по умолчанию включено. Этот параметр отключает этот шифр Triple DES. Если он не включен, то не о чем беспокоиться.
Я использую plesk 12.5 и уже использовал их рекомендации по соответствию PCI, включая обновление зашифрованного текста, как вы упомянули. Однако их зашифрованный текст намного длиннее предложенного вами: «EECDH+AESGCM+AES128:EECDH+AESGCM+AES256:EDH+AESGCM+AES128:EDH+AESGCM+AES256:EECDH+SHA256+AES128:EECDH+SHA384 +AES256:EDH+SHA256+AES128:EDH+SHA256+AES256:EECDH+SHA1+AES128:EECDH+SHA1+AES256:EDH+SHA1+AES128:EDH+SHA1+AES256:EECDH+HIGH:EDH+HIGH:AESGCM+AES128 :AESGCM+AES256:SHA256+AES128:SHA256+AES256:SHA1+AES128:SHA1+AES256:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!KRB5:!aECDH: !EDH+3DES». Я не решаюсь изменить это для вашего гораздо более короткого зашифрованного текста. Я обнаружил, что простое добавление «:!3DES» в конец зашифрованного текста удаляет все шифры 3DES. Этого кажется достаточно, но я подумал, что смогу узнать ваше мнение по этому поводу.
Поскольку SWEET32 основан на уязвимости 3DES, основной целью этой статьи является то, как избежать использования этого шифра на ваших серверах. На данный момент шифр AES считается надежным шифром и существует в 128- и 256-битных комбинациях. Вы можете включить столько надежных шифров, сколько хотите, чтобы ваш сервер поддерживал.
Внесение этого изменения в реестр для устранения уязвимости нарушает RDP. Больше никакого удаленного рабочего стола при применении!
"HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\Triple DES 168"
new dword Enabled = 0
Привет, Боб. Просто хотел сказать, что эта информация помогла мне пройти тест на соответствие требованиям TrustKeeper. Хороший материал!
Спасибо, рад это знать 🙂
У меня есть 3 сервера, которые в настоящее время затронуты:
– Windows Server 2012R2,
– Windows Server 2008R2,
– Windows Server 2008
Нужно ли после редактирования изменений в реестре перезагрузить серверы, чтобы изменения вступили в силу?
Я столкнулся с проблемой. У меня есть сервер Windows Server 2008R2 с этой уязвимостью Sweet32.
Ниже приведена конфигурация реестра.
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC4 128/128]
"Enabled"=dword:00000000
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC4 40/128]
"Enabled"=dword:00000000
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC4 56/128]
"Enabled"=dword:00000000
Итак, для этого сценария, как я смогу отключить шифр 3DES? Посоветуйте?
Но разве это не относится к отключению набора шифров RC4?
И эти 3 уже отключены.
Я имею в виду, что я не могу найти этот реестр ниже на серверах W2K8 и W2K8R2.
\SCHANNEL\Ciphers\Triple DES 168
Как я могу решить эту проблему?
Планируется внести это изменение, но хотелось бы знать, не нарушит ли оно работу Microsoft Exchange Server/почтового потока??
Это будет зависеть от сервера Exchange, на котором вы работаете. Поддержка SMTP для TLS 1.1 и 1.2 была добавлена в Exchange Server 2013 CU8 и Exchange Server 2010 SP3 RU9. Таким образом, если вы обновите шифры и версии TLS, вам может потребоваться применить обновление для службы SMTP, иначе почта может перестать работать.
Мы используем RHEL5 и хотели избавиться от уязвимости Sweet32. Для чего пытаемся обновить пакет openssl с 1.0.1u до 1.1.0f. Но мы сталкиваемся с множеством проблем. Не могли бы вы предложить альтернативу.
У меня есть сервер Linux Readheat со службой Weblogic. пожалуйста, как решить 3DES и RSA
Здравствуйте, я обнаружил эту уязвимость на своем сервере Windows Server 2012 R2 vSphere. Я пытался просмотреть regedit, но в моей папке …/SCHANNEL/Ciphers/ есть только (по умолчанию). Я что-то упустил или есть еще где исправить эту уязвимость?
Нам потребуется более внимательно изучить версию серверного программного обеспечения и ее зависимости. Если вы все еще обнаружите проблемы, мы будем рады поговорить с вами в чате (нажмите на значок справа внизу).
Сканер уязвимостей 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), я попытался применить шаблон "Рекомендации", а также шаблон 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, к которому я больше не могу подключиться, который обрабатывает это на этом конце?
После отключения 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, из-за которой возникает эта проблема, и как ее исправить?
Можно ли использовать NetMon или Wireshark для захвата приветствия клиента/сервера, чтобы увидеть, какой набор шифров на самом деле согласовывается при сбое подключения, а когда — успешно?
@RyanRies: Уже сделал, но до настоящего рукопожатия TLS дело не дошло. Клиент отправляет пакет «TPKT, продолжение», а сервер отвечает «RST, ACK».
4 ответа 4
IIS Crypto позволяет установить параметры как на стороне сервера (входящие), так и на стороне клиента (исходящие). Есть несколько шифров, которые нужно оставить включенными на стороне клиента для совместимости.
Чтобы сделать то, что вы хотите, лично я бы сделал следующее:
- Применить шаблон 3.1
- Оставьте все наборы шифров включенными.
- Применить как к клиенту, так и к серверу (установлен флажок).
- Нажмите "Применить", чтобы сохранить изменения.
Перезагрузитесь здесь, если хотите (и у вас есть физический доступ к машине).
- Применить шаблон 3.1
- Оставьте все наборы шифров включенными.
- Применить к серверу (флажок снят).
- Снимите флажок с параметра 3DES.
Перезагрузка здесь должна привести к правильному конечному состоянию.
Фактически вы хотите только отключить входящий 3DES, но по-прежнему разрешать исходящее использование указанного набора шифров.
Звучит многообещающе! Однако отключение 3DES 168, похоже, было ошибкой — я больше не могу к нему подключиться. Как только я разберусь с этим, я попытаюсь просто отключить шифр только на стороне сервера и отчитаюсь/приму ответ.
Я попробовал ваше предложение: 1) Примените «Лучшие практики» и примените их как к серверу, так и к клиенту, затем 2) Снимите флажок с шифра TLS_RSA_WITH_3DES_EDE_CBC_SHA и «Установить протоколы на стороне клиента» и примените снова, затем, конечно, перезагрузите компьютер. Проблема RDP с этой машины все еще сохраняется. Приветствуются дополнительные предложения.
Я попробовал это. 1) Выберите шаблон 3.1 + оставьте все наборы шифров как есть + включите «Установить протоколы на стороне клиента» + проверьте TLS 1.0 (SQL и т. д. не работает без TLS 1.0) + Примените и перезагрузите компьютер. 2) Выберите шаблон 3.1 + оставьте все наборы шифров как есть + снимите флажок «Установить протоколы на стороне клиента» + снимите флажок 3DES + установите флажок TLS 1.0 + Примените и перезагрузите компьютер. Больше не могу подключиться, "Произошла внутренняя ошибка" (думаю сервер должен поддерживать 3DES). Я подключаюсь с компьютера с Windows 10.
Я поделюсь своим ответом из темы 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
Тогда вы, например, будете иметь события в системном журнале;
< p>Квитирование клиента SSL успешно завершено. Ниже приведены согласованные криптографические параметры.Протокол: TLS 1.0 CipherSuite: 0x2f Стойкость обмена: 1024
Для меня результатом является 0xa, который Google показывает как TLS_RSA_WITH_3DES_EDE_CBC_SHA.
Когда я использую "Triple DES 168" (без /168), системное событие ID 36880 не появляется и сеанс RDP блокируется.
Службы удаленных рабочих столов (RDS) Для шифрования сетевых подключений служб удаленных рабочих столов этот параметр политики поддерживает только алгоритм шифрования Triple DES.
Итак, оба они поддерживают идею о том, что RDP может использовать только 3DES. Однако в этой статье предлагается более широкий диапазон шифров: проверка FIPS 140
Набор криптографических алгоритмов, которые будет использовать сервер протокола удаленного рабочего стола (RDP), ограничен: - CALG_RSA_KEYX - алгоритм обмена открытым ключом RSA - CALG_3DES - алгоритм шифрования Triple DES - CALG_AES_128 - 128-битный AES - CALG_AES_256 - 256-битный AES - CALG_SHA1 - Алгоритм хеширования SHA - CALG_SHA_256 - 256-битный алгоритм хеширования SHA - CALG_SHA_384 - 384-битный алгоритм хеширования SHA - CALG_SHA_512 - 512-битный алгоритм хеширования SHA
В конечном итоге неясно, может ли 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 Validation.
В заключение: я не думаю, что Server 2008 R2 может поддерживать RDP в режиме FIPS с отключенным 3DES. Я рекомендую выяснить, соответствует ли ваша система условиям для атаки SWEET32 (более 768 ГБ, отправленных за один сеанс), и стоит ли отключать 3DES для удаления возможности RDP.Существуют и другие утилиты для управления серверами помимо RDP, особенно в мире, где виртуализация широко распространена.
Я пытаюсь устранить уязвимость SWEET32 на сервере 2008R2.
Отчет сканирования Nmap для xx.xx.xx.xx
Хост работает (задержка 0,0044 с).
ПОРТ ГОСУДАРСТВЕННОЙ СЛУЖБЫ ВЕРСИИ
| TLS_RSA_WITH_3DES_EDE_CBC_SHA — F
| предпочтение шифрования: клиент
| 64-битный блочный шифр 3DES уязвим для атаки SWEET32
| TLS_RSA_WITH_3DES_EDE_CBC_SHA — F
| предпочтение шифрования: клиент
| 64-битный блочный шифр 3DES уязвим для атаки SWEET32
| TLS_RSA_WITH_3DES_EDE_CBC_SHA — F
| предпочтение шифрования: клиент
| 64-битный блочный шифр 3DES уязвим для атаки SWEET32
|_ наименьшая сила: F
Заранее спасибо.
Чадз
Intel vPro®: что нового в 2022 году
2022-03-24 16:00:00 UTC Video Meetup Видеовстреча: Intel - Intel vPro®: что нового в 2022 г. Сведения о событии Просмотреть все события
Джим Питерс
Перейдите к списку Cipher Suite, найдите TLS_RSA_WITH_3DES_EDE_CBC_SHA и снимите флажок.
Кроме того, посетите раздел "О программе" и нажмите кнопку [Проверить наличие обновлений], если вы используете этот инструмент и с момента его установки прошло некоторое время.
Последняя мысль заключается в том, что в вашей среде может быть групповая политика, которая создает список наборов шифров (длинный список строк TLS_, подобный приведенному выше).
Заключительная мысль II: в Linux-стране или везде, где используется openssl, я обычно иду на вики Mozilla по TLS за всеми подробностями об apache, ngnix, tomcat или о чем-то еще, чтобы решить эти проблемы там. Обычно это изменение в файле конфигурации.
12 ответов
Ник-C
Вместо того, чтобы копаться во множестве настроек реестра, это значительно упрощает работу.
Джим Питерс
Это мой инструмент номер один для управления подробностями протокола SSL и списком шифров на моих серверах Windows.
Метигация SWEET32 может быть такой же простой, как «Пресс-рекомендации» и удаление шифров из списка с помощью 3DES. Затем выполните перезагрузку, и все готово.
ОП Чадз
ОП Чадз
Чадз написал:
Правильно ли я настраиваю IISCrypto? Я выбрал Best Practice, и это показывает, что Triple DES 168 все еще отмечен в разделе Ciphers, а в разделе Cipher Suites он по-прежнему показывает TLS_RSA_WITH_3DES_EDE_CBC_SHA. Нужно ли их снимать, чтобы отключить?
ОП Чадз
Я по-прежнему получаю предупреждения о том, что 64-битный блочный шифр 3DES уязвим для атаки SWEET32 с отключенным шифром Triple DES и всеми наборами шифров 3DES.
Отчет сканирования Nmap для xx.xx.xx.xx
Хост работает (задержка 0,0080 с).
ГОСУДАРСТВЕННАЯ СЛУЖБА ПОРТА
8194/tcp открытый софос
| TLS_RSA_WITH_3DES_EDE_CBC_SHA — F
| предпочтение шифрования: клиент
| 64-битный блочный шифр 3DES уязвим для атаки SWEET32
| TLS_RSA_WITH_3DES_EDE_CBC_SHA — F
| предпочтение шифрования: клиент
| 64-битный блочный шифр 3DES уязвим для атаки SWEET32
| TLS_RSA_WITH_3DES_EDE_CBC_SHA — F
| предпочтение шифрования: клиент
| 64-битный блочный шифр 3DES уязвим для атаки SWEET32
|_ наименьшая сила: F
Есть идеи, где еще искать?
Покажите нам снимок экрана вашего IISCrypto, но не применяйте никаких изменений.
ОП Чадз
< /p>
ОП Чадз
< /p>
Если вы применили это и перезагрузились, я не вижу, как вы видите доступный шифр, если только вы не просканировали другую машину.
Джим Питерс
Перейдите к списку Cipher Suite, найдите TLS_RSA_WITH_3DES_EDE_CBC_SHA и снимите флажок.
Кроме того, посетите раздел "О программе" и нажмите кнопку [Проверить наличие обновлений], если вы используете этот инструмент и с момента его установки прошло некоторое время.
Последняя мысль заключается в том, что в вашей среде может быть групповая политика, которая создает список наборов шифров (длинный список строк TLS_, подобный приведенному выше).
Заключительная мысль II: в Linux-стране или везде, где используется openssl, я обычно иду на вики Mozilla по TLS за всеми подробностями об apache, ngnix, tomcat или о чем-то еще, чтобы решить эти проблемы там. Обычно это изменение в файле конфигурации.
ОП Чадз
Хорошо, возможно, я переборщил с этим, однако я хочу убедиться, что предоставляю клиенту правильную информацию, а профессиональный пентестер не вынесет мои выводы из воды.
Сканирование NMAP обнаружило, что следующие порты на целевом сервере открыты и могут согласовать безопасный канал связи;
Только 5445 и 8443 помечаются как представляющие слабые шифры (даже после того, как реестр был взломан на биты, чтобы предотвратить представление слабых шифров)
Поэтому я создал Linux-систему для запуска testsl.sh и запустил отдельное сканирование каждого порта:
РЕЗУЛЬТАТЫ для порта 8443
SSLv2 не предлагается (ОК)
SSLv3 не предлагается (ОК)
TLS 1 не предлагается
TLS 1.1 не предлагается
Предлагается TLS 1.2 (ОК)
Допуск версии понижен до TLSv1.2 (ОК)
SPDY/NPN не предлагается
Тестирование ~стандартных списков шифров
Нулевые шифры не предлагаются (ОК)
Анонимные шифры NULL не предлагаются (ОК)
Анонимные шифры DH не предлагаются (ОК)
40-битное шифрование не предлагается (ОК)
56-битные экспортные шифры не предлагаются (ОК)
Экспорт шифров (общий) не предлагается (ОК)
Эта тема заблокирована администратором и больше не открыта для комментариев.
Чтобы продолжить обсуждение, задайте новый вопрос.
Эргономичное оборудование
Кто в США должен нести ответственность за предоставление эргономичного оборудования по запросу сотрудника? Это ИТ, поскольку ИТ предоставляет клавиатуры и мыши? Должен ли это быть HR, поскольку он эргономичен и несет потенциальную ответственность, если НЕ предоставляется? Должен ли это быть тот отдел.
Приветствие Xfinity (личный домашний Интернет)
Во-первых, мне больно. Я мог бы произнести речь «Он ставит передо мной задачу», как Хан в «Звездном пути 2: Гнев Хана». Просто замените «Они» на «Он». Но они сделали то, чего я хотел годами (десятилетиями?), так что, думаю, это должно быть признано. Ю.
Щелкни! SATCOM Threat, IE End of Life, Mac с кирпичами, Planet 9, Lego Delorean
Ваша ежедневная доза технических новостей. Вы должны это услышать. ФБР и CISA предупреждают об угрозах для сетей спутниковой связи Согласно новому предупреждению ФБР и CISA спутниковые сети находятся в зоне высокого риска. Согласно ZDNet.
Какими сверхспособностями вы хотели бы обладать?
Что может сделать ИТ-специалист со сверхспособностями? В каких ИТ-задачах вы бы их использовали и как?
Можно ли подключить интерфейс управления коммутатора к одному из его собственных портов коммутатора?
Недавно я понял, что у меня есть конфигурация коммутатора с непреднамеренным потенциальным побочным эффектом. У меня есть Aruba 6300F с несколькими виртуальными локальными сетями. Он работает в режиме уровня 3. Это работает следующим образом: я просто «включаю» функции маршрутизатора, а затем.
Читайте также: