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

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

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

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

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

3 ответа

Решение

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

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

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

Другие вопросы по тегам