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

56

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

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

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

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

Кристоф Де Тройер
источник
4
Связанный: Что такое Logjam и как мне его предотвратить?
Восстановить Монику - М. Шредер

Ответы:

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 и в статье, связанной с этой конкретной уязвимостью.

BE77Y
источник
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