☰

如何修復 Apache 中的「logjam」漏洞 (httpd)

tag-icon • tag-icon apache-2.2 ssl apache-2.4 httpd vulnerability
如何修復 Apache 中的「logjam」漏洞 (httpd)

最近，Diffie-Hellman 中的一個新漏洞（非正式地稱為「logjam」）已發布，該漏洞這一頁已匯總建議如何應對該漏洞：

對於正確部署 TLS 的 Diffie-Hellman，我們提出了三個建議：

  1. 停用導出密碼套件。儘管現代瀏覽器不再支援匯出套件，但 FREAK 和 Logjam 攻擊仍允許中間人攻擊者誘騙瀏覽器使用匯出級加密，然後可以解密 TLS 連線。出口密碼是 20 世紀 90 年代政策的殘餘，該政策阻止強密碼協議從美國出口。現代客戶不依賴匯出套件，停用它們也沒有什麼壞處。
  2. 部署（臨時）橢圓曲線 Diffie-Hellman (ECDHE)。橢圓曲線 Diffie-Hellman (ECDH) 金鑰交換避免了所有已知的可行密碼分析攻擊，現代 Web 瀏覽器現在更喜歡 ECDHE，而不是原始的有限域 Diffie-Hellman。我們用來攻擊標準 Diffie-Hellman 群組的離散對數演算法並沒有從預計算中獲得如此強大的優勢，而各個伺服器不需要產生獨特的橢圓曲線。
  3. 建立一個強大、獨特的迪菲赫爾曼集團。數百萬台伺服器使用一些固定群組，這使它們成為預先計算和潛在竊聽的最佳目標。管理員應使用「安全性」素數為每個網站或伺服器產生獨特的 2048 位元或更強的 Diffie-Hellman 群組。

根據上述建議，我應該採取哪些最佳實踐步驟來保護我的伺服器？

答案1

來自您連結的文章，建議採取三個步驟來保護自己免受此漏洞的影響。原則上，這些步驟適用於您可能使用 SSL/TLS 的任何軟體，但在這裡我們將處理將它們應用於 Apache (httpd) 的特定步驟，因為這是有問題的軟體。

  1. 停用導出密碼套件

我們將在下面的 2. 中進行的配置更改中進行處理（!EXPORT靠近行尾的SSLCipherSuite是我們將如何禁用導出密碼套件）

  1. 部署（短暫）橢圓曲線 Diffie-Hellman (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或類似的方式將它們傳輸到有問題的伺服器上以供使用，從而解決此潛在問題。

要在 Apache 中使用這些新生成的內容dhparams，請從阿帕奇文檔：

若要產生自訂 DH 參數，請使用 openssl dhparam 指令。或者，您可以附加以下內容RFC 2409 第 6.2 節中的標準 1024 位元 DH 參數到對應的 SSLCertificateFile 文件：

（強調我的）

然後是標準的 1024 位元 DH 參數。由此我們可以推斷，自訂產生的 DH 參數可以簡單地附加到相關的相關SSLCertificateFile參數。

為此，請執行類似於以下內容的操作：

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

或者，根據阿帕契小節在您最初連結的文章中，如果您不想更改證書文件本身，您也可以指定您建立的自訂 dhparams 文件，因此：

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

在與您的特定 SSL/TLS 實作相關的 Apache 配置中 - 通常在conf.d/ssl.conf或conf.d/vhosts.conf中，但這會根據您配置 Apache 的方式而有所不同。

值得注意的是，根據這個連結,

在 Apache 2.4.7 之前，DH 參數始終設定為 1024 位，且使用者不可設定。此問題已在 mod_ssl 2.4.7 中修復，Red Hat 已使用 httpd-2.2.15-32.el6 將其向後移植到其 RHEL 6 Apache 2.2 發行版中

在 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 服務以套用變更後，您應該透過執行測試來檢查設定是否符合預期SSL實驗室以及文章與此特定漏洞相關。

答案2

基於 Winni Neessen 的補丁，我發布了 Apache/2.2.22 的修復程式（Debian Wheezy，也許也可以在 Ubuntu 上使用）：https://flo.sh/debian-wheezy-apache2-logjam-fix/- 謝謝。尋求您的回饋。

答案3

與其走上述「駭客」的複雜路線，不如考慮切換到 Nginx作為您的主要網頁伺服器軟體（不僅僅是快取或代理）。從安全角度來看，它顯然比舊的 apache 引擎更符合當前標準。透過使用 nginx 儲存庫，它為您提供了比 apache 更最新、更穩定的網頁伺服器引擎。

我徹底轉變了。為我節省了大量解決有關 TLS 問題的時間，而且對於我們的配置來說，它也同時釋放了大量 RAM。事實上，與我已經習慣的 httpd/apache 的無數配置複雜性相比，我發現 nginx 的使用非常簡單明了。可能是品味問題，在我轉向之前，我已經非常熟悉 httpd/apache rewrite/config/maintenance，而且它比我擔心的要容易。網路上有關於 nginx 配置的適當的最新信息，其用戶群龐大、非常活躍且支持友好。 https://news.netcraft.com/wp-content/uploads/2018/11/wpid-wss-top-1m-share.png

相關內容