Bagaimana cara memperbaiki kerentanan 'logjam' di Apache (httpd)

Baru-baru ini, sebuah kerentanan baru di Diffie-Hellman, yang secara informal disebut 'logjam' telah diterbitkan, yang mana halaman ini telah disusun bersama-sama menyarankan cara untuk melawan kerentanan:

Kami memiliki tiga rekomendasi untuk menyebarkan Diffie-Hellman untuk TLS dengan benar:

Nonaktifkan Suites Cipher Suites. Meskipun browser modern tidak lagi mendukung suite ekspor, serangan FREAK dan Logjam memungkinkan penyerang man-in-the-middle untuk mengelabui browser menggunakan kriptografi tingkat ekspor, setelah itu koneksi TLS dapat didekripsi. Cipher ekspor adalah sisa dari kebijakan era 1990-an yang mencegah protokol kriptografi yang kuat diekspor dari Amerika Serikat. Tidak ada klien modern yang mengandalkan suite ekspor dan ada sedikit kelemahan dalam menonaktifkannya.

Menyebarkan (Ephemeral) Elliptic-Curve Diffie-Hellman (ECDHE). Elliptic-Curve Diffie-Hellman (ECDH) pertukaran kunci menghindari semua serangan cryptanalytic yang diketahui layak, dan browser web modern sekarang lebih memilih ECDHE daripada bidang, asli terbatas, Diffie-Hellman. Algoritma log diskrit yang kami gunakan untuk menyerang grup Diffie-Hellman standar tidak mendapatkan keuntungan yang kuat dari perhitungan sebelumnya, dan masing-masing server tidak perlu menghasilkan kurva eliptik yang unik.

Hasilkan Diffie Hellman Group yang Kuat dan Unik . Beberapa grup tetap digunakan oleh jutaan server, yang menjadikannya target optimal untuk komputasi awal, dan potensi penyadapan. Administrator harus membuat grup Diffie-Hellman yang unik, 2048-bit atau lebih kuat menggunakan bilangan prima "aman" untuk setiap situs web atau server.

Apa langkah praktik terbaik yang harus saya ambil untuk mengamankan server saya sesuai rekomendasi di atas?

apache-2.2 ssl apache-2.4 httpd vulnerability Christophe De Troyer
sumber

Terkait: Apa itu Logjam dan bagaimana cara mencegahnya?

Pasang kembali Monica - M. Schröder

Jawaban:

Dari artikel yang Anda tautkan , ada tiga langkah yang disarankan untuk melindungi diri Anda dari kerentanan ini. Pada prinsipnya langkah-langkah ini berlaku untuk perangkat lunak apa pun yang dapat Anda gunakan dengan SSL / TLS tetapi di sini kami akan membahas langkah-langkah spesifik untuk menerapkannya ke Apache (httpd) karena itu adalah perangkat lunak yang dimaksud.

Nonaktifkan Suites Cipher Suites

Diatasi dalam perubahan konfigurasi yang akan kami buat di 2. di bawah ini (di !EXPORTdekat akhir SSLCipherSuitebaris adalah bagaimana kami akan menonaktifkan suite cipher ekspor)

Menyebarkan (Ephemeral) Elliptic-Curve Diffie-Hellman (ECDHE)

Untuk ini, Anda perlu mengedit beberapa pengaturan di Apache file konfigurasi Anda - yaitu SSLProtocol, SSLCipherSuite, SSLHonorCipherOrderuntuk memiliki "-praktek terbaik" setup. Sesuatu seperti yang berikut ini sudah cukup:

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

Catatan: untuk SSLCipherSuitepengaturan mana yang digunakan, ini selalu berubah, dan merupakan ide bagus untuk berkonsultasi dengan sumber daya seperti ini untuk memeriksa konfigurasi yang disarankan terbaru.

3. Hasilkan Grup Hellman Diffie yang Kuat dan Unik

Untuk melakukannya, Anda dapat berlari

openssl dhparam -out dhparams.pem 2048.

Perhatikan bahwa ini akan menempatkan beban yang signifikan pada server saat params dihasilkan - Anda selalu dapat mengatasi potensi masalah ini dengan membuat params pada mesin lain dan menggunakan scpatau serupa untuk mentransfernya ke server yang bersangkutan untuk digunakan.

Untuk menggunakan ini yang baru dibuat dhparamsdi Apache, dari Dokumentasi Apache :

Untuk menghasilkan parameter DH khusus, gunakan perintah openssl dhparam. Atau, Anda dapat menambahkan parameter DH 1024-bit standar berikut dari RFC 2409, bagian 6.2 ke file SSLCertificateFile masing-masing :

(penekanan milikku)

yang kemudian diikuti oleh parameter DH 1024-bit standar. Dari sini kita dapat menyimpulkan bahwa parameter DH yang dibuat khusus dapat dengan mudah ditambahkan ke yang bersangkutan SSLCertificateFile.

Untuk melakukannya, jalankan sesuatu yang mirip dengan yang berikut:

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

Atau, sesuai dengan ayat Apache dari artikel yang Anda tautkan sebelumnya, Anda juga dapat menentukan file dhparams khusus yang telah Anda buat jika Anda memilih untuk tidak mengubah file sertifikat itu sendiri, dengan demikian:

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

di mana konfigurasi Apache relevan dengan implementasi SSL / TLS Anda - umumnya dalam conf.d/ssl.confatau conf.d/vhosts.conftetapi ini akan berbeda tergantung pada bagaimana Anda telah mengkonfigurasi Apache.

Perlu dicatat bahwa, sesuai tautan ini ,

Sebelum Apache 2.4.7, parameter DH selalu diatur ke 1024 bit dan tidak dapat dikonfigurasi pengguna. Ini telah diperbaiki di mod_ssl 2.4.7 yang Red Hat telah backport ke distribusi RHEL 6 Apache 2.2 mereka dengan httpd-2.2.15-32.el6

Pada Debian Wheezy, tingkatkan apache2 ke 2.2.22-13 + deb7u4 atau lebih baru dan openssl ke 1.0.1e-2 + deb7u17. SSLCipherSuite di atas tidak berfungsi dengan baik, gunakan yang berikut ini sesuai blog ini :

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

Anda harus memeriksa apakah versi Apache Anda lebih lama dari nomor versi ini tergantung pada distribusi Anda, dan jika tidak - perbarui jika memungkinkan.

Setelah Anda melakukan langkah-langkah di atas untuk memperbarui konfigurasi Anda, dan memulai kembali layanan Apache untuk menerapkan perubahan, Anda harus memeriksa bahwa konfigurasi seperti yang diinginkan dengan menjalankan tes pada SSLLab dan pada artikel yang terkait dengan kerentanan khusus ini.

BE77Y
sumber

Adapun beban diletakkan di server dengan menghasilkan params, Anda selalu dapat menghasilkan mereka di komputer lain dan cukup scp atau bahkan salin-tempel file ke server target. Tidak perlu membuat params di server produksi.

Erathiel

Setelah Anda mengubah konfigurasi Anda, Anda mungkin ingin menjalankan pemeriksaan di SSLLabs.com juga hanya untuk memastikan.

user2428118

Apakah ada cara untuk memperbaiki kerentanan ini di Apache / 2.2.22 (Ubuntu 12.04)? Saya menambahkan dhparams.pem ke Certificate.crt tetapi lemahdh.org/sysadmin.html masih mengeluh

tersmitten

@tersmitten Itu pertanyaan yang sepenuhnya terpisah dengan yang ini.

Michael Hampton

Anda dapat menjalankan generasi kunci dengan perintah 'bagus'. jadi, Anda bisa menyebutnya: nice 19 openssl dhparam -out dhparams.pem 2048. Ini akan bekerja lebih lama, tetapi hanya akan menghabiskan waktu cpu yang tidak terpakai.

Znik

Berdasarkan sepetak Winni Neessen, saya telah menerbitkan perbaikan untuk Apache / 2.2.22 (Debian Wheezy, mungkin juga dapat digunakan di Ubuntu): https://flo.sh/debian-wheezy-apache2-logjam-fix/ - thx . atas tanggapan Anda.

Flo
sumber

ini lebih merupakan retasan hackish daripada solusi. menempatkan nginx infront terbaru dari apache Anda sebagai reverse-proxy akan jauh lebih mudah, dan seseorang tidak bergantung pada apache pihak ketiga.

pria itu dari sana

Mengapa kita harus mempercayai binari ini?

CVn

Anda tidak harus mempercayai binari; Anda dapat mengkompilasi ulang apache2.2.x sendiri dengan sangat mudah mengikuti langkah-langkah yang dijelaskan jika Anda meluangkan waktu. Ini juga akan meningkatkan keamanan Anda, karena pengaturan Anda memiliki kunci utama yang unik.

Flo

Sarankan bahwa orang tidak mengeluh tentang tambalan memperbaiki masalah dalam perangkat lunak opensource.

Florian Heigl

@FlorianHeigl Saya bahkan tidak yakin apa yang membuat komentar itu ...

BE77Y

-7

Alih-alih menggunakan rute kompleks 'peretasan' di atas, pertimbangkan beralih ke nginx sebagai perangkat lunak server-web utama Anda (bukan hanya caching atau proxy). Tampaknya lebih sesuai dengan standar saat ini, dari sisi keamanan, daripada mesin apache lama. Dengan menggunakan repositori nginx itu memberi Anda cara yang lebih up-to-date mesin-webser stabil daripada apache.

Saya benar-benar beralih. Menyelamatkan saya banyak penyelesaian masalah yang memakan waktu mengenai TLS, dan - untuk konfigurasi kami - itu juga membebaskan banyak RAM di jalan yang sama. Bahkan, saya menemukan pekerjaan nginx menyegarkan sederhana dan mudah, dibandingkan dengan banyak komplikasi konfigurasi httpd / apache saya sudah terbiasa. Bisa jadi soal selera, saya menjadi cukup lancar dalam httpd / apache rewrite / config / maintenance sebelum saya berbalik, dan itu lebih mudah daripada yang saya khawatirkan. Ada info terbaru yang sesuai tentang konfigurasi nginx yang tersedia online, dan basis penggunanya sangat besar, sangat aktif, dan ramah dukungan. https://news.netcraft.com/wp-content/uploads/2018/11/wpid-wss-top-1m-share.png

Julius
sumber

nginx yang diatur untuk memungkinkan cipher ekspor akan sama rentannya dengan serangan Logjam seperti server Apache yang diatur untuk memungkinkan cipher ekspor. Juga, pertanyaannya menanyakan solusi di Apache.

CVn

Sebenarnya, solusi: beralih ke distribusi yang menyediakan lebih banyak paket terbaru untuk perangkat lunak di mana Anda benar-benar membutuhkan versi yang lebih baru (bukan hanya perbaikan bug yang di-backport, seperti misalnya halnya dengan Debian atau CentOS), atau buat paket sendiri dari source (tidak sulit) dan instal menggunakan manajer paket, atau instal lama dari source code (juga tidak sulit, tetapi butuh sedikit lebih banyak pekerjaan untuk dikelola). Untuk pertanyaan yang menanyakan "bagaimana cara mengurangi kerentanan X dalam perangkat lunak Y?", Sebuah jawaban yang menyatakan "ganti perangkat lunak Y dengan perangkat lunak Z" seringkali bukan jawaban yang berguna.

CVn

Apache ke Nginx bukan pemutakhiran, ini pengganti. Backporting adalah suatu kemungkinan. Jika Anda memiliki banyak pekerjaan yang diinvestasikan dalam solusi Apache, benar-benar membuangnya dan menggantinya dengan sesuatu yang lain juga membutuhkan banyak pekerjaan. Dan pertanyaan ini masih tentang solusi yang berpusat di sekitar Apache , bukan Nginx. Saya tidak akan menghabiskan lebih banyak waktu untuk berdebat tentang ini; ketika Anda memposting jawaban, pastikan mereka menjawab pertanyaan seperti yang ditanyakan di halaman atas. Jika Anda ingin mengirim jawaban yang mendorong orang untuk beralih dari Apache ke Nginx, tentu saja lakukan itu, tetapi ke pertanyaan yang memungkinkan untuk Nginx.

CVn

Jadi mengonfigurasi perangkat lunak dengan benar agar aman dari serangan yang diketahui adalah "rute peretasan yang rumit"? Saya mendapatkan A + di ssllabs.com dengan konfigurasi apache sederhana, Anda hanya perlu meluangkan waktu dan melakukan riset untuk memahami cara mengkonfigurasi perangkat lunak yang Anda gunakan dengan benar, tidak ada peretasan di sini ...

Chazy Chaz

@Julius - downvotes cenderung lebih berkaitan dengan kurangnya nilai dalam jawaban Anda mengenai pertanyaan yang diajukan, daripada "agenda" tersembunyi yang tampaknya dimiliki orang terhadap nginx vs apache. Seperti yang terjadi, saya secara eksklusif menggunakan nginx karena preferensi saya - tetapi sayalah yang menjawab pertanyaan ini. "Beralih ke perangkat lunak lain" bukan jawaban yang dapat diterima untuk "cara memperbaiki (masalah apa pun)". Belum lagi, Anda juga sepenuhnya melewatkan titik kerentanan sebenarnya - itu dalam pertukaran kunci difie-hellman, bukan apache (atau nginx, atau sshd, atau ...)

BE77Y