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


56

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

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

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

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


Ответы:


82

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


1
Что касается нагрузки на сервер путем генерации параметров, вы всегда можете сгенерировать их на другом компьютере и просто скопировать или скопировать файл на целевой сервер. Нет необходимости генерировать параметры в производственном сервере.
— Эратиэль

2
После того, как вы изменили свою конфигурацию, вы можете также выполнить проверку на SSLLabs.com, чтобы быть уверенным.
— user2428118

2
Есть ли способ исправить эту уязвимость в Apache / 2.2.22 (Ubuntu 12.04)? Я приложил dhparams.pem к certificate.crt но weakdh.org/sysadmin.html до сих пор жалуется
— tersmitten

2
@tersmitten Это совершенно отдельный вопрос к этому.
— Майкл Хэмптон

3
вы всегда можете запустить генерацию ключа командой 'nice'. Итак, вы можете указать это как: nice 19 openssl dhparam -out dhparams.pem 2048. Это будет работать дольше, но будет занимать только неиспользованное время процессора.
— Зник

1

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


3
это скорее хакерский взлом, чем решение. поместить недавний nginx напротив вашего apache в качестве обратного прокси было бы гораздо проще, и нельзя полагаться на сторонний apache.
— этот парень оттуда

6
Почему мы должны доверять этим двоичным файлам?
— CVn

2
Вам не нужно доверять двоичным файлам; Вы можете очень легко перекомпилировать apache2.2.x самостоятельно, следуя инструкциям, если вы не торопитесь. Это, кроме того, повысит вашу безопасность, потому что тогда ваша установка имеет уникальные первичные ключи.
— Фло

Предположил бы, что люди не жалуются на исправления, исправляющие проблему в программном обеспечении с открытым исходным кодом.
— Флориан Хейгл

@FlorianHeigl Я даже не уверен, что делать с этим комментарием ...
— BE77Y

-7

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


3
nginx, настроенный для поддержки экспортных шифров, будет в такой же степени уязвим к атаке Logjam, как сервер Apache, настроенный для поддержки экспортных шифров. Также вопрос требует решения в Apache.
— CVn

2
На самом деле, решение: либо переключитесь на дистрибутив, который предоставляет больше современных пакетов для программного обеспечения, где вам абсолютно необходима более новая версия (а не просто багпортированные исправления ошибок, как, например, в Debian или CentOS), или соберите пакеты самостоятельно из исходного кода (это не сложно) и установите их с помощью менеджера пакетов или простой старой установки из исходного кода (тоже не сложно, но для управления требуется немного больше работы). На вопрос, который спрашивает: «Как я могу смягчить уязвимость X в программном обеспечении Y?», Ответ, в котором говорится «заменить программное обеспечение Y программным обеспечением Z», часто не является полезным ответом.
— CVN

1
Apache для Nginx - это не обновление, а замена. Backporting это возможность. Если у вас есть много работы, вложенной в решение Apache, то полное его удаление и замена чем-то другим также потребует много работы. И этот вопрос по- прежнему касается решений, сконцентрированных вокруг Apache , а не Nginx. Я не собираюсь тратить больше времени на споры об этом; Когда вы публикуете ответы, убедитесь, что они отвечают на вопрос так, как задано в верхней части страницы. Если вы хотите опубликовать ответ, побуждающий людей перейти с Apache на Nginx, сделайте это любыми способами, но на вопрос, который учитывает Nginx.
— CVN

1
Итак, правильная настройка программного обеспечения для защиты от известных атак - это "сложный путь взлома"? Я получаю A + на ssllabs.com с простой настройкой Apache, вам просто нужно потратить время и провести некоторое исследование, чтобы понять, как правильно сконфигурировать используемое программное обеспечение, без хаков здесь ...
— Chazy Chaz

1
@Julius - отрицательные отзывы, скорее всего, больше связаны с отсутствием ценности в вашем ответе на заданный вопрос, чем с любой скрытой «повесткой дня», которую люди, очевидно, могут иметь против nginx против apache. Так получилось, что я пользуюсь исключительно nginx из-за своих предпочтений, но именно я ответил на этот вопрос. «Переключиться на другое программное обеспечение» не является приемлемым ответом на «как исправить (любую проблему)». Не говоря уже о том, что вы также полностью упустили момент фактической уязвимости - это был обмен ключами diffie-hellman, а не apache (или nginx, или sshd, или ...)
— BE77Y
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.