Вопрос: Как исправить уязвимость «logjam» в Apache (httpd)


Недавно была опубликована новая уязвимость в Diffie-Hellman, неофициально называемая «logjam», для которой эта страница был составлен вместе с предложением о том, как противостоять этой уязвимости:

У нас есть три рекомендации по правильному развертыванию Diffie-Hellman   для TLS:

  1. Отключить экспортные шрифты. Хотя современные браузеры больше не работают   поддержка экспортных наборов, атаки FREAK и Logjam позволяют   Человек-в-середине злоумышленник обманывает браузеры с использованием экспортного класса   криптография, после чего соединение TLS может быть расшифровано. экспорт   шифры - это остатки политики эпохи 1990-х годов, которая   криптографические протоколы от экспорта из США. нет   современные клиенты полагаются на экспортные апартаменты, и в   отключив их.
  2. Развертывание (эфемерная) Эллиптическая кривая Диффи-Хеллман   (ECDHE). Обмен ключами с использованием эллиптической кривой Diffie-Hellman (ECDH) позволяет избежать всех   известных возможных криптоаналитических атак и современных веб-браузеров сейчас   предпочитают ECDHE над исходным конечным полем, Диффи-Хеллман.   алгоритмы дискретного журнала, которые мы использовали для атаки стандартного Диффи-Хеллмана   группы не получают столь же сильного преимущества от предвычисления, и   отдельным серверам не требуется генерировать уникальные эллиптические кривые.
  3. Создайте Сильную, уникальную группу Диффи Хеллмана, Несколько фиксированных групп   используемых миллионами серверов, что делает их оптимальной целью для   предвычисления и потенциального подслушивания. Администраторы должны   генерировать уникальные, 2048-битные или более сильные группы Диффи-Хеллмана, используя   «безопасных» простых чисел для каждого веб-сайта или сервера.

Каковы наиболее эффективные шаги, которые я должен предпринять для защиты моего сервера в соответствии с вышеприведенными рекомендациями?


56
2018-05-20 09:34


Источник


Связанный: Что такое Logjam и как его предотвратить? - Martin Schröder


Ответы:


Из статья, которую вы связали, есть три рекомендуемых шага, чтобы защитить себя от этой уязвимости. В принципе эти шаги применимы к любому программному обеспечению, которое вы можете использовать с SSL / TLS, но здесь мы рассмотрим конкретные шаги по их применению к Apache (httpd), поскольку это программное обеспечение, о котором идет речь.

  1. Отключить экспортные шрифты

Ознакомиться с изменениями конфигурации мы сделаем в 2. ниже (!EXPORT ближе к концу SSLCipherSuite строка - как мы отключим экспортные шифровые комплекты)

  1. Развертывание (эфемерная) Эллиптическая кривая Диффи-Хеллман (ECDHE)

Для этого вам нужно отредактировать несколько настроек в конфигурационных файлах Apache, а именно: SSLProtocol, SSLCipherSuite, SSLHonorCipherOrder для настройки «наилучшей практики». Будет достаточно следующего:

SSLProtocol             all -SSLv2 -SSLv3

SSLCipherSuite          ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA

SSLHonorCipherOrder     on

Примечание: для чего SSLCipherSuite чтобы использовать, это всегда меняется, и рекомендуется проконсультироваться с такими ресурсами, как вот этот для проверки последней рекомендованной конфигурации.

3. Создать сильную, уникальную группу Диффи Хеллмана

Для этого вы можете запускать

openssl dhparam -out dhparams.pem 2048,

Обратите внимание, что это приведет к значительной нагрузке на сервер, пока будут созданы параметры - вы всегда можете обойти эту потенциальную проблему, создав параметры на другой машине и используя scpили аналогично передавать их на сервер, о котором идет речь, для использования.

Чтобы использовать эти вновь созданные dhparams в Apache, из Документация Apache:

Чтобы создать пользовательские параметры DH, используйте команду openssl dhparam.   Кроме того, вы можете добавьте следующее стандартный 1024-битный DH   параметры из RFC 2409, раздел 6.2 к соответствующему   Файл SSLCertificateFile:

(акцент мой)

после чего следует стандартный 1024-битный параметр DH. Из этого можно сделать вывод о том, что настраиваемые параметры DH могут быть просто добавлены к соответствующим SSLCertificateFile обсуждаемый.

Для этого запустите что-то похожее на следующее:

cat /path/to/custom/dhparam >> /path/to/sslcertfile

В качестве альтернативы, согласно Подраздел Apache статьи, которую вы первоначально связали, вы также можете указать собственный файл dhparams, который вы создали, если вы не хотите сами изменять файл сертификата:

SSLOpenSSLConfCmd DHParameters "/path/to/dhparams.pem"

в зависимости от того, какие конфигурации (а) Apache относятся к вашей конкретной реализации SSL / TLS - как правило, в conf.d/ssl.confили conf.d/vhosts.conf но это будет отличаться в зависимости от того, как вы настроили Apache.

Стоит отметить, что, согласно эта ссылка,

До Apache 2.4.7 параметр DH всегда установлен на 1024 бит и   не настраивается пользователем. Это было исправлено в mod_ssl 2.4.7, что   Red Hat представила свой дистрибутив RHEL 6 Apache 2.2 с   HTTPD-2.2.15-32.el6

В Debian-кодеке обновите apache2 до 2.2.22-13 + deb7u4 или позже, а openssl - 1.0.1e-2 + deb7u17. Вышеупомянутый SSLCipherSuite работает не так, вместо этого используйте следующее в соответствии с этот блог:

SSLCipherSuite ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-DSS-AES128-SHA256:DHE-DSS-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA:!DHE-RSA-AES128-GCM-SHA256:!DHE-RSA-AES256-GCM-SHA384:!DHE-RSA-AES128-SHA256:!DHE-RSA-AES256-SHA:!DHE-RSA-AES128-SHA:!DHE-RSA-AES256-SHA256:!DHE-RSA-CAMELLIA128-SHA:!DHE-RSA-CAMELLIA256-SHA

Вы должны проверить, будет ли ваша версия Apache более поздней, чем эти номера версий, в зависимости от вашего дистрибутива, а если нет - обновите ее, если это вообще возможно.

После того как вы выполнили вышеуказанные шаги для обновления конфигурации и перезапустили службу Apache, чтобы применить изменения, вы должны проверить, что конфигурация является желательной, запустив тесты на SSLLabs и на статья связанных с этой конкретной уязвимостью.


80
2018-05-20 09:50



Что касается нагрузки, поставленной на сервер путем генерации параметров, вы всегда можете сгенерировать их на другой машине и просто scp или даже скопировать-вставить файл на целевой сервер. Нет необходимости генерировать параметры на рабочем сервере. - Erathiel
После того, как вы изменили конфигурацию, вы можете запустить проверку на SSLLabs.com а также просто быть уверенным. - user2428118
Есть ли способ устранить эту уязвимость в Apache / 2.2.22 (Ubuntu 12.04)? Я добавил dhparams.pem к сертификату.crt, но weakdh.org/sysadmin.html все еще жалуется - tersmitten
@tersmitten Это совершенно отдельный вопрос к этому. - Michael Hampton♦
вы всегда можете запускать генерацию ключей командой «nice». так что вы можете сказать, что: nice 19 openssl dhparam -out dhparams.pem 2048. Это будет работать дольше, но будет потреблять только неиспользуемое время процессора. - Znik


Основываясь на патче Winni Neessen, я опубликовал исправление для Apache / 2.2.22 (Debian Wheezy, возможно, также можно использовать на Ubuntu): https://flo.sh/debian-wheezy-apache2-logjam-fix/ - спасибо. для вашей обратной связи.


0
2018-05-21 02:32



это скорее хакерский взлом, чем решение. добавив недавний nginx infront вашего apache, поскольку обратный прокси-сервер будет намного проще, и никто не будет полагаться на сторонний-apache. - that guy from over there
Почему мы должны доверять этим двоичным файлам? - Michael Kjörling
Вам не нужно доверять двоичным файлам; вы можете перекомпилировать apache2.2.x самостоятельно очень легко, следуя инструкциям, если вы потратите время. Это также увеличит вашу безопасность, потому что тогда ваша установка имеет уникальные первичные ключи. - Flo
Предположим, что люди не жалуются на исправления, исправляющие проблему в программном обеспечении с открытым исходным кодом. - Florian Heigl
@FlorianHeigl Я даже не уверен, что делать с этим комментарием ... - BE77Y


Вместо того, чтобы идти по сложному маршруту вышеупомянутых хаков, рассмотрите переход на nginx как ваш основной веб-сервер-программное обеспечение (а не только кеширование или прокси). Очевидно, что это похоже на современные стандарты, безопасные, чем старые Apache-двигатели. Используя репозиторий nginx, он дает вам более современный стабильный веб-сервер, чем apache.

Я полностью переключился. Сэкономил много времени на решение проблем, связанных с TLS, и - для наших конфигураций - он также высвободил много оперативной памяти в одном и том же режиме. Фактически, я нашел занятие nginx обновляющимся простым и понятным, по сравнению с множеством конфигурационных осложнений httpd / apache, к которым я привык. Может быть, это вопрос вкуса, я довольно свободно переписывался в httpd / apache rewrite / config / maintenance, прежде чем я повернулся, и это было легче, чем я боялся. В Интернете имеется соответствующая последняя информация о конфигурации nginx, а ее пользовательская база огромна, очень активна и удобна в использовании. https://news.netcraft.com/wp-content/uploads/2018/03/wpid-wss-top-1m-share.png


-7
2017-11-04 11:16



nginx, созданный для экспорта шифров, будет в точку как уязвимый для атаки Logjam, как сервер Apache, настроенный на использование экспортных шифров. Кроме того, вопрос требует решения в Apache. - Michael Kjörling
Не правда. Фактически, основная причина, по которой я когда-то конвертировала в nginx, была именно потому, что управление дистрибутивом, как yum, так и apt, в то время не предоставить обновленную версию apache. В то время как nginx, который был поставлен, включал все, что мне нужно, против эксплойта в то время. Опять же, это было больше стандартов, и я предполагаю, что его цикл цикла обновления намного короче. Теперь это logjam, но на работе я сталкиваюсь с той же проблемой с apache 2.2, и дистрибутив не предоставляет backport для нескольких связанных с SSL / TLS проблем. Решение. Замените apache на nginx. Задача решена. - Julius
На самом деле, решение: либо переключитесь на дистрибутив, который предоставляет более современные пакеты для программного обеспечения, где вам абсолютно нужна более новая версия (а не только исправленные исправления ошибок, как, например, в случае с Debian или CentOS) или создавать пакеты самостоятельно из источника (это не сложно) и устанавливать их с помощью диспетчера пакетов, или простая старая установка из исходного кода (также не сложно, но требуется немного больше работы для управления). В вопросе, который задает вопрос «как уменьшить уязвимость X в программном обеспечении Y?», Ответ, который гласит: «заменить программное обеспечение Y программным обеспечением Z», часто не является полезным ответом. - Michael Kjörling
Ну, по-прежнему существует проблема, связанная с этими проблемами, называемая зависимостями, а также ее не новенькое оборудование, и помимо этого я не исправляю систему, изменяя ее distro.version, нам приходится иметь дело с различиями в программном обеспечении, -управление. Не похоже, что у нас достаточно времени в мире, чтобы решить переключить все ядра ОС. В сравнении одно обновление пакета (например, Apache to Nginx). - Julius
Apache для Nginx не является обновлением, это замена. Возможность резервного копирования - это возможность. Если у вас много работы, вложенной в решение Apache, полностью выкидывая это и заменяя его чем-то другим, также требуется много работы. И этот вопрос все еще о решениях, сосредоточенных вокруг апаш, а не Nginx. Я больше не собираюсь больше спорить об этом; когда вы публикуете ответы, убедитесь, что они отвечают на вопрос, заданный на верх страницы. Если вы хотите опубликовать ответ, призывающий людей переключиться с Apache на Nginx, непременно сделайте это, но на вопрос, который позволяет Nginx. - Michael Kjörling