Cách khắc phục lỗ hổng 'logjam' trong Apache (httpd)

Gần đây, một lỗ hổng mới trong Diffie-Hellman, được gọi một cách không chính thức là 'logjam' đã được xuất bản, trong đó trang này đã được tập hợp lại gợi ý cách chống lại lỗ hổng:

Chúng tôi có ba đề xuất để triển khai chính xác Diffie-Hellman cho TLS:

1. Vô hiệu hóa bộ mật mã xuất khẩu. Mặc dù các trình duyệt hiện đại không còn hỗ trợ các bộ xuất, các cuộc tấn công FREAK và Logjam cho phép kẻ tấn công trung gian lừa các trình duyệt sử dụng mật mã cấp xuất khẩu, sau đó kết nối TLS có thể được giải mã. Mật mã xuất khẩu là phần còn lại của chính sách thời kỳ những năm 1990 ngăn chặn các giao thức mật mã mạnh được xuất khẩu từ Hoa Kỳ. Không có khách hàng hiện đại nào dựa vào các bộ xuất khẩu và có rất ít nhược điểm trong việc vô hiệu hóa chúng.
2. Triển khai (Phù du) Elliptic-Curve Diffie-Hellman (ECDHE). Trao đổi khóa Elliptic-Curve Diffie-Hellman (ECDH) tránh tất cả các cuộc tấn công mật mã khả thi đã biết, và các trình duyệt web hiện đại bây giờ thích ECDHE hơn trường gốc, hữu hạn, Diffie-Hellman. Các thuật toán nhật ký rời rạc mà chúng tôi sử dụng để tấn công các nhóm Diffie-Hellman tiêu chuẩn không đạt được lợi thế mạnh mẽ từ tiền mã hóa và các máy chủ riêng lẻ không cần tạo các đường cong elip độc đáo.
3. Tạo ra một nhóm Hellie Diffie mạnh mẽ, độc đáo . Một vài nhóm cố định được sử dụng bởi hàng triệu máy chủ, điều này khiến chúng trở thành mục tiêu tối ưu cho việc tính toán trước và nghe lén tiềm năng. Quản trị viên nên tạo các nhóm Diffie-Hellman duy nhất, 2048 bit hoặc mạnh hơn bằng cách sử dụng các số nguyên tố "an toàn" cho mỗi trang web hoặc máy chủ.

Các bước thực hành tốt nhất tôi nên thực hiện để bảo mật máy chủ của mình theo các khuyến nghị ở trên là gì?

Từ bài viết bạn liên kết , có ba bước được đề xuất để bảo vệ bạn khỏi lỗ hổng này. Về nguyên tắc, các bước này áp dụng cho bất kỳ phần mềm nào bạn có thể sử dụng với SSL / TLS nhưng ở đây chúng tôi sẽ giải quyết các bước cụ thể để áp dụng chúng cho Apache (httpd) vì đó là phần mềm được đề cập.

1. Vô hiệu hóa Xuất mật mã Suites

Xử lý các thay đổi về cấu hình, chúng tôi sẽ thực hiện trong 2. bên dưới ( !EXPORTgần cuối SSLCipherSuitedòng là cách chúng tôi vô hiệu hóa bộ mật mã xuất khẩu)

2. Triển khai (Phù du) Elliptic-Curve Diffie-Hellman (ECDHE)

Đối với điều này, bạn cần phải chỉnh sửa một vài thiết lập trong file cấu hình Apache của bạn - cụ thể là SSLProtocol, SSLCipherSuite, SSLHonorCipherOrderđể có một "thực hành tốt nhất" thiết lập. Một cái gì đó như sau sẽ đủ:

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

Lưu ý: đối với SSLCipherSuitecài đặt nào sẽ sử dụng, điều này luôn thay đổi và bạn nên tham khảo các tài nguyên như tài nguyên này để kiểm tra cấu hình được đề xuất mới nhất.

3. Tạo ra một nhóm Hellie Diffie mạnh mẽ, độc đáo

Để làm như vậy, bạn có thể chạy

openssl dhparam -out dhparams.pem 2048.

Lưu ý rằng điều này sẽ gây ra tải đáng kể cho máy chủ trong khi các thông số được tạo - bạn luôn có thể khắc phục sự cố tiềm ẩn này bằng cách tạo thông số trên máy khác và sử dụng scphoặc tương tự để chuyển chúng vào máy chủ để sử dụng.

Để sử dụng những thứ mới được tạo dhparamstrong Apache này, từ Tài liệu Apache :

Để tạo các tham số DH tùy chỉnh, sử dụng lệnh openssl dhparam. Ngoài ra, bạn có thể nối các tham số DH tiêu chuẩn 1024 bit sau từ RFC 2409, phần 6.2 vào tệp SSLCertertFile tương ứng :

(nhấn mạnh của tôi)

sau đó được theo sau bởi một tham số DH tiêu chuẩn 1024 bit. Từ đó, chúng ta có thể suy ra rằng các tham số DH được tạo tùy chỉnh có thể đơn giản được thêm SSLCertificateFilevào câu hỏi liên quan .

Để làm như vậy, hãy chạy một cái gì đó tương tự như sau:

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

Ngoài ra, theo phần phụ Apache của bài viết mà bạn đã liên kết ban đầu, bạn cũng có thể chỉ định tệp dhparams tùy chỉnh mà bạn đã tạo nếu bạn không muốn thay đổi tệp chứng chỉ, do đó:

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

trong đó bất kỳ cấu hình Apache nào có liên quan đến việc triển khai SSL / TLS cụ thể của bạn - thường là trong conf.d/ssl.confhoặc conf.d/vhosts.confnhưng điều này sẽ khác nhau tùy thuộc vào cách bạn đã cấu hình Apache.

Điều đáng chú ý là, theo liên kết này ,

Trước Apache 2.4.7, tham số DH luôn được đặt thành 1024 bit và không thể định cấu hình người dùng. Điều này đã được sửa trong mod_ssl 2.4.7 rằng Red Hat đã nhập vào bản phân phối RHEL 6 Apache 2.2 của họ với httpd-2.2.15-32.el6

Trên Debian Wheezy nâng cấp apache2 lên 2.2.22-13 + deb7u4 trở lên và openssl thành 1.0.1e-2 + deb7u17. SSLCodesSuite ở trên không hoạt động hoàn hảo, thay vào đó hãy sử dụng các mục sau theo blog này :

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

Bạn nên kiểm tra xem phiên bản Apache của bạn có muộn hơn các số phiên bản này hay không tùy thuộc vào bản phân phối của bạn và nếu không - hãy cập nhật nếu có thể.

Khi bạn đã thực hiện các bước trên để cập nhật cấu hình của mình và khởi động lại dịch vụ Apache để áp dụng các thay đổi, bạn nên kiểm tra xem cấu hình đó có như mong muốn hay không bằng cách chạy thử nghiệm trên SSLLabs và trên bài viết liên quan đến lỗ hổng cụ thể này.

Dựa trên bản vá của Winni Neessen Tôi đã xuất bản bản sửa lỗi cho Apache / 2.2.22 (Debian Wheezy, cũng có thể sử dụng được trên Ubuntu): https://flo.sh/debian-wheezy-apache2-logjam-fix/ - thx . cho phản hồi của bạn.

Thay vì đi theo con đường phức tạp của các 'hack' ở trên, hãy xem xét chuyển sang nginx làm phần mềm máy chủ web chính của bạn (không chỉ bộ nhớ đệm hoặc proxy). Nó rõ ràng có vẻ phù hợp với các tiêu chuẩn hiện tại, bảo mật hơn so với các công cụ apache cũ. Bằng cách sử dụng kho nginx, nó cung cấp cho bạn một cách cập nhật công cụ máy chủ web ổn định hơn là apache.

Tôi hoàn toàn chuyển qua. Tiết kiệm cho tôi rất nhiều giải quyết vấn đề tốn thời gian liên quan đến TLS, và - đối với cấu hình của chúng tôi - nó cũng giải phóng rất nhiều RAM trong cùng một lúc. Trong thực tế, tôi thấy việc làm của nginx rất đơn giản và dễ hiểu, so với vô số các biến chứng cấu hình của httpd / apache mà tôi đã quen. Có thể là một vấn đề của hương vị, tôi đã trở nên khá thành thạo trong việc viết lại httpd / apache viết lại / config / bảo trì trước khi tôi chuyển, và nó dễ dàng hơn tôi sợ nó sẽ xảy ra. Có thông tin gần đây thích hợp về cấu hình nginx có sẵn trực tuyến và cơ sở người dùng của nó rất lớn, rất năng động và thân thiện với hỗ trợ. https://news.netcraft.com/wp-content/uploads/2018/11/wpid-wss-top-1m-share.png