Menambal Bug Enkripsi CentOS 8 Sangat Mendesak – Apa Rencana Anda?

  • Whatsapp

News.nextcloud.asia –

Bug Enkripsi CentOS 8

Ada tiga hal yang dapat Anda yakini dalam hidup: kematian, pajak – dan CVE baru. Untuk organisasi yang mengandalkan CentOS 8, hal yang tak terhindarkan kini telah terjadi, dan tidak butuh waktu lama. Hanya dua minggu setelah mencapai akhir hidup resmi, sesuatu pecah secara spektakuler, pergi CentOS 8 pengguna dengan risiko besar serangan parah – dan tanpa dukungan dari CentOS.

Anda akan berpikir bahwa masalah ini tidak lagi mempengaruhi sejumlah besar organisasi karena sekarang, perusahaan akan bermigrasi dari CentOS 8 ke OS yang secara aktif didukung oleh vendor. Bagaimanapun, dukungan vendor sangat penting untuk keamanan dan kepatuhan.

Tetapi seperti yang selalu terjadi dengan hal-hal ini, Anda dapat mengandalkan fakta bahwa sebagian besar pengguna CentOS 8 bekerja dengan OS yang tidak didukung, meskipun menyadari risikonya. Dengan risiko itu sekarang mengkristal, kami menggunakan artikel ini untuk memeriksa CVE-2021-4122, kerentanan yang baru ditemukan dalam enkripsi LUKS, dan untuk mendiskusikan opsi Anda untuk menguranginya.

Tunggu, apa itu LUKS?

Jadi apa? KEMEWAHAN? LUKS adalah singkatan dari Linux Unified Key Setup dan merupakan mekanisme yang digunakan dalam sistem yang didukung Linux untuk mendukung, antara lain, enkripsi disk penuh. Direkomendasikan dalam banyak panduan “praktik terbaik” sebagai opsi pengerasan sistem yang penting untuk tim TI yang berpikiran keamanan.

Bagaimana cara kerja LUKS? Nah, selama penerapan sistem, Anda dapat membuat partisi yang hanya dapat dibaca – yaitu data di dalamnya hanya dapat dimengerti – dengan kata sandi yang disediakan pengguna. LUKS cukup kompleks dan banyak sistem keamanan berinteraksi dengan LUKS, tetapi panduan LUKS yang komprehensif bukanlah tujuan artikel ini.

Memiliki disk yang sepenuhnya terenkripsi (memblokir perangkat di Linux “berbicara”) memastikan bahwa data aman dari mata-mata bahkan saat istirahat, yang berarti bahwa penyerang yang mencuri laptop, misalnya, masih tidak dapat melihat data rahasia yang terkandung dalam dia.

Anda selanjutnya dapat membangun keamanan dengan mengikat perangkat blok tertentu ke komputer tertentu melalui TPM (Trusted Platform Module). Itu menambah rintangan lain bagi penyerang, membuatnya lebih sulit untuk secara fisik menarik data terenkripsi dari mesin dan menghubungkannya ke sistem berkinerja tinggi dengan tujuan memaksa akses ke data. Meskipun, seperti biasa, seberapa besar kemungkinannya untuk berhasil bergantung pada daya komputasi, algoritme enkripsi yang dipilih, dan hanya keberuntungan belaka.

Secara keseluruhan, LUKS memberikan perlindungan yang sangat baik dan karena alasan itu, LUKS sering diandalkan untuk mengamankan sistem di berbagai organisasi.

Memahami kekurangan LUKS

CVE-2021-4122 ditugaskan akhir tahun lalu, tetapi pemahaman penuh tentang risiko keamanan di sekitar LUKS baru muncul belakangan ini. Ternyata dimungkinkan untuk, setidaknya sebagian, mendekripsi disk yang dienkripsi LUKS dan mengakses data di dalamnya tanpa memiliki kata sandi yang digunakan untuk mengonfigurasi enkripsi.

Fitur utama LUKS adalah kemampuan untuk mengubah, dengan cepat, kunci yang digunakan untuk mengenkripsi perangkat tertentu. Anda akan melakukan ini, misalnya, untuk rotasi kunci terjadwal di lingkungan keamanan tinggi.

Fitur enkripsi ulang on-the-fly ini berarti bahwa perangkat tetap tersedia selama proses perubahan kunci. Ini disebut “enkripsi ulang online” – yang mengacu pada kemampuan untuk mengenkripsi ulang disk dengan kunci yang berbeda saat sedang online dan dalam penggunaan aktif.

Dalam proses inilah kerentanan diidentifikasi. Ternyata jika Anda tahu apa yang Anda lakukan, Anda dapat melakukan operasi ini tanpa memiliki sandi asli yang terbaru. Bahkan tanpa kata sandi, Anda dapat meminta enkripsi ulang.

Memanfaatkan kelemahannya, proses ini kemudian akan tampak dibatalkan dan beberapa data akan tersedia tanpa terenkripsi. Perangkat tidak pernah mengalami perilaku anomali, jadi akan sulit untuk menemukan penyerang yang melakukan operasi hanya dengan melihat status blok perangkat.

Sysadmin sangat disarankan untuk memutakhirkan cryptsetup, paket yang mendukung LUKS, pada semua sistem di bawah kendali mereka, karena kerentanan dapat menyebabkan pengungkapan informasi.

Ok, jadi saya hanya akan menambal dan melanjutkan …?

Tepat. Itulah yang harus dilakukan oleh setiap administrator sistem pada sistem mereka – mengganti paket yang terpengaruh. Tetapi untuk beberapa sysadmin ini akan lebih mudah diucapkan daripada dilakukan. Sysadmin mana yang akan mengalami kesulitan? Anda menebak dengan benar – mereka yang masih bergantung pada CentOS 8.

Sebagian besar vendor memiliki peringatan dini tentang bug tersebut dan sudah menyediakan paket yang diperbarui untuk distro mereka. Dan sama dengan Red Hat, yang mendukung CentOS. Namun, dengan CentOS 8 sekarang tidak lagi didukung secara resmi, patch CentOS 8 untuk kelemahan LUKS tidak akan muncul.

Untuk pengguna CentOS 8 hal-hal karena itu cukup suram. Sistem yang tidak ditambal rentan terhadap pencurian data karena cacat yang dipublikasikan dan diketahui secara luas. Ini adalah situasi yang serius dan dengan satu atau lain cara Anda harus menggunakan versi patch terbaru dari paket yang terpengaruh.

Tidak melakukan apa-apa bukanlah pilihan ketika data rahasia terancam. Dan, pada dasarnya, semua data Anda bersifat rahasia dan bukan untuk pengungkapan publik (jika tidak, itu akan dipublikasikan), dan Anda mengandalkan solusi enkripsi disk lengkap seperti LUKS secara tepat untuk menghindari pengungkapan.

Opsi tambalan Anda jika Anda masih menggunakan CentOS 8

Ada dua jalur yang tersedia untuk sysadmin yang mengandalkan sistem Linux yang terpengaruh yang beroperasi melewati akhir masa pakainya. Salah satu opsi adalah mengunduh sumber proyek hulu dan mengompilasinya secara lokal, membuat paket sistem pengganti. Opsi lainnya adalah menandatangani dengan vendor dukungan yang diperluas yang akan menyediakan tambalan yang tidak lagi dirilis oleh vendor asli.

Pendekatan build-it-local memiliki kelemahan. Pertama, kode sumber proyek asli tidak memberikan kelonggaran khusus untuk distribusi tertentu. Setiap distribusi atau keluarga distribusi semuanya memiliki kekhasan masing-masing. Keluarga RHEL, yang mencakup CentOS, akan memiliki kebiasaan ini juga.

Itu termasuk hal-hal seperti lokasi biner, konfigurasi awal layanan, pengaturan, dan sebagainya. Tim lokal Anda harus menyesuaikan ini secara manual. Apakah tim TI lokal Anda memiliki keahlian yang diperlukan adalah pertanyaan lain. Demikian pula, dengan tim teknologi yang umumnya berada di bawah tekanan untuk menyelesaikan sesuatu, ada risiko bahwa upaya penambalan DIY Anda tertunda. Juga, di halaman proyek LUKS diri, ada “Harap selalu lebih memilih alat build khusus distro daripada mengonfigurasi cryptsetup secara manual”.

Alternatif Anda adalah memikirkan vendor dukungan tambahan sebagai pendekatan yang andal, hemat biaya, dan lebih mudah untuk mengatasi masalah ini. Dukungan Siklus Hidup yang Diperpanjang dari TuxCare layanan melakukan hal itu. TuxCare memberikan patch berkualitas tinggi untuk distribusi akhir masa pakai seperti CentOS 8 dan melakukannya tepat waktu.

Terlebih lagi Anda mendapatkan dukungan penuh untuk patch juga. Penerapannya sederhana, Anda menerapkan tambalan TuxCare semudah tambalan yang didukung vendor.

Anda harus bertindak – sekarang

Jika Anda memutuskan untuk tidak mencari dukungan eksternal, Anda tetap harus melakukan sesuatu sekarang untuk melindungi sistem Anda dari kerentanan baru. Anda dapat memutuskan untuk menggigit peluru dan mengkompilasi cryptsetup dan dependensinya secara lokal, dan melakukan penerapan di semua sistem Anda.

Tapi itu jelas bukan CVE terakhir yang keluar yang memengaruhi CentOS 8. Untuk memberi Anda gambaran tentang cakupan dari apa yang sedang kita bicarakan: bahkan hari ini masih ada kerentanan yang muncul yang memengaruhi sistem CentOS 6. Seberapa layak dalam jangka panjang untuk terus berurusan dengan aliran CVE berkelanjutan yang memengaruhi CentOS 8?

Anda mungkin menjalankan CentOS 8 saat ini karena Anda dicegah untuk bermigrasi ke alternatif karena satu dan lain alasan. Ini bisa jadi kompatibilitas, dukungan, atau salah satu dari beberapa alasan.

Kerentanan tidak akan berhenti pada tanggal EOL, jadi buat hidup lebih mudah bagi tim TI Anda, lebih aman bagi profesional keamanan Anda, dan penuhi persyaratan kepatuhan seputar patching untuk bisnis Anda – lihat Rangkaian layanan TuxCare, dan khususnya Dukungan Siklus Hidup yang Diperpanjang. Ini adalah cara yang solid untuk mendapatkan perlindungan berkelanjutan terhadap CVE baru yang memengaruhi CentOS 8 – memberi Anda waktu untuk bermigrasi ke OS lain.

.

Pos terkait

Tinggalkan Balasan

Alamat email Anda tidak akan dipublikasikan.