☰

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

tag-icon • tag-icon apache-2.2 ssl apache-2.4 httpd vulnerability
Как исправить уязвимость «logjam» в Apache (httpd)

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

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

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

Какие наилучшие шаги мне следует предпринять для защиты своего сервера в соответствии с приведенными выше рекомендациями?

решение1

Изстатья, на которую вы ссылаетесь, есть три рекомендуемых шага, чтобы защитить себя от этой уязвимости. В принципе, эти шаги применимы к любому программному обеспечению, которое вы можете использовать с 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 Wheezy обновите 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и настатьясвязанные с этой конкретной уязвимостью.

решение2

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

решение3

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

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

Связанный контент