Praktik terbaik untuk menjaga mesin Ubuntu EC2 diperbarui

12

Mengikuti kerentanan OpenSSL yang baru-baru ini menyentuh hati , saya ingin menjaga mesin-mesin EC2 saya diperbarui secara teratur. Pendekatan naif akan menetapkan pekerjaan cron per jam untuk pembaruan keamanan ( sudo apt-get update && sudo unattended-upgrade).

Apakah ada risiko melakukan itu? Apakah ada mekanisme pembaruan yang disarankan untuk mesin EC2?

unattended-upgrades

— Adam Matan
sumber

13

Paket peningkatan tanpa pengawasan adalah cara standar untuk secara otomatis menerapkan perbaikan bug dan patch keamanan penting di Ubuntu.

Saya sarankan menginstal ini di setiap sistem Ubuntu:

sudo apt-get update &&
sudo apt-get install unattended-upgrades

Anda tidak perlu membuat pekerjaan cron Anda sendiri. Paket menginstal satu untuk Anda.

Anda dapat mengedit konfigurasi default jika Anda ingin mengubah perilakunya: https://help.ubuntu.com/lts/serverguide/automatic-updates.html

— Eric Hammond
sumber

Adakah pemikiran tentang kelayakan melakukan ini di server produksi? Itu membuat saya gugup untuk menerapkan perubahan secara diam-diam dan mempertaruhkan kemungkinan pembaruan gagal atau menimbulkan masalah.

— ianjs

3

Yang dimaksud dengan "setiap" adalah sistem produksi. Saya telah secara otomatis menerapkan patch keamanan Ubuntu selama bertahun-tahun dan tidak dapat mengingat masalah serius. Itu membuat saya gugup untuk memiliki server produksi duduk di sana tanpa tambalan untuk masalah keamanan yang diketahui dan risiko kemungkinan dieksploitasi. Yang mengatakan setiap situasi memiliki kebutuhan yang berbeda, sehingga Anda mungkin lebih baik melalui fase pengujian yang ketat untuk setiap tambalan. Berhati-hatilah, mereka dirilis sepanjang waktu, jadi Anda akan sibuk.

— Eric Hammond

1

Saya tidak menyarankan ini kecuali Anda memiliki pengaturan redundant / cluster. Prosedur pembaruan Ubuntu tidak bisa dihentikan, saya telah menghentikan beberapa kali layanan dan yang paling baru bahkan sektor boot yang rusak ... Dan kami tidak melakukan sesuatu yang istimewa - hanya Apache sebagai reverse proxy dan aplikasi Tomcat.

— digandakan

1

Kami telah menggunakan unattended-upgradesdari 2015 hingga 2020 tanpa masalah. Kami memiliki pengaturan kecil (di DigitalOcean) dengan:

nginx
mysql-server
php5-fpm php5-curl php5-mysql

Berdasarkan kinerja masa lalu yang baik, melakukan pembaruan dengan cara ini terasa lebih aman daripada tidak melakukannya. Tapi itu belum tentu jaminan untuk masa depan!

Ini mungkin bukan ide yang bagus untuk itu apache, berdasarkan laporan dari pengguna lain, dan pengalaman apachepembaruan saya yang lalu . [Lihat di atas, dan di sini ]

Dengan unattended-upgrades, intervensi manual masih akan diperlukan ketika rilis mendekati EOL .

(Selain dari pertanyaan: Dalam pengalaman saya dengan TWiki, WordPress dan Jenkins, menjaga agar aplikasi-aplikasi ini tetap mutakhir sebenarnya merupakan masalah yang lebih besar daripada OS itu sendiri, meskipun tentu saja kita harus benar-benar melakukan keduanya. Untuk ketenangan pikiran, Anda bisa memberi kotak pasir pada aplikasi yang menghadap Internet sebagai proses non-root yang berjalan di dalam wadah Docker.)

Tetapi karena Anda bertanya tentang praktik terbaik , pendekatan utama yang direkomendasikan dalam dokumentasi AWS adalah:

Buat dan mulai instance baru untuk menggantikan instance online Anda saat ini. Kemudian hapus instance saat ini.

Mesin virtual baru akan memasang set tambalan keamanan terbaru saat pemasangan.

(Februari 2020)

Ini dapat dilakukan sebagai bagian dari strategi penyebaran biru-hijau . Keuntungannya di sini adalah Anda dapat menjalankan tes terhadap server baru Anda sebelum mengalihkan lalu lintas. Jika pengujian Anda menyeluruh, maka secara teori pembaruan Anda dapat sepenuhnya otomatis, diverifikasi sebelum ditayangkan, dan tanpa downtime.

Keuntungan lain:

Tes ini dapat memberi Anda peringatan lanjutan jika diperlukan perhatian manusia (berbeda dengan unattended-upgrades, ketika peringatan hanya datang dari pengguna Anda setelah masalahnya hidup!)
Jika sistem Anda dikompromikan, atau Anda memutuskan untuk beralih penyedia, pendekatan ini akan membuatnya mudah untuk meluncurkan penyebaran baru. Strategi penyebaran Anda ditulis, bukan memori kuno.

Tetapi tentu saja ada lebih banyak pengaturan yang diperlukan untuk pendekatan ini daripada hanya menginstal unattended-upgrades, dan lebih banyak kerumitan, sehingga masih ada ruang untuk kesalahan.

AWS juga menyebutkan melakukan "Update Dependencies stack command", yang tampaknya merupakan cara resmi mereka untuk melakukan sesuatu yang serupa unattended-upgrades. Tampaknya itu dapat dipicu dari antarmuka Instans mereka, tetapi saya tidak yakin apakah itu dapat otomatis.

— joeytwiddle
sumber