Cara Mengamankan Server MySQL/MariaDB

Setelah serangan pada database MongoDB, baru-baru ini kami juga melihat bahwa server MySQL menjadi sasaran ransomware. Ini seharusnya tidak mengejutkan, mengingat meningkatnya adopsi cloud publik dan pribadi. Menjalankan database yang dikonfigurasi dengan buruk di cloud dapat menjadi tanggung jawab besar.

Dalam posting blog ini, kami akan berbagi dengan Anda sejumlah tips tentang cara melindungi dan mengamankan server MySQL atau MariaDB Anda.

Memahami Vektor Serangan

Mengutip SCMagazine:
“Serangan dimulai dengan memaksa kata sandi root untuk database MySQL. Setelah login, database dan tabel MySQL diambil. Penyerang kemudian membuat tabel baru yang disebut 'PERINGATAN' yang mencakup alamat email kontak, alamat bitcoin, dan permintaan pembayaran. ”

Berdasarkan artikel tersebut, vektor serangan dimulai dengan menebak kata sandi root MySQL melalui metode brute force. Serangan brute force terdiri dari penyerang yang mencoba banyak kata sandi atau frasa sandi dengan harapan akhirnya menebak dengan benar. Ini berarti sandi yang pendek biasanya dapat ditemukan dengan cukup cepat, tetapi sandi yang lebih panjang mungkin memerlukan waktu berhari-hari atau berbulan-bulan.

Brute-force adalah serangan umum yang akan terjadi pada layanan apa pun. Sayangnya untuk MySQL (dan banyak DBMS lainnya), tidak ada fitur out-of-the-box yang mendeteksi dan memblokir serangan brute force dari alamat tertentu selama otentikasi pengguna. MySQL memang menangkap kegagalan otentikasi di log kesalahan.

Tinjau Kebijakan Kata Sandi Anda

Meninjau kebijakan kata sandi MySQL selalu merupakan langkah pertama untuk melindungi server Anda. Kata sandi root MySQL harus cukup kuat dengan kombinasi huruf, angka, dan simbol (yang membuatnya lebih sulit untuk diingat) dan disimpan di tempat yang aman. Ubah kata sandi secara teratur, setidaknya setiap kuartal kalender. Berdasarkan vektor serangan, ini adalah titik terlemah yang ditargetkan oleh peretas. Jika Anda menghargai data Anda, jangan abaikan bagian ini.

Penerapan MySQL yang dilakukan oleh ClusterControl akan selalu mengikuti praktik terbaik keamanan vendor, misalnya tidak akan ada host wildcard yang ditentukan selama GRANT dan kredensial login sensitif yang disimpan dalam file konfigurasi hanya diizinkan untuk pengguna root OS. Kami sangat menyarankan pengguna kami untuk menentukan sandi yang kuat selama tahap penerapan.

Dalam lingkungan produksi standar, server database biasanya terletak di tingkat tingkat yang lebih rendah. Lapisan ini harus dilindungi dan hanya dapat diakses dari tingkat atas, seperti aplikasi atau penyeimbang beban. Jika database berada di lokasi yang sama dengan aplikasi, Anda bahkan dapat mengunci alamat non-lokal dan menggunakan file soket MySQL (lebih sedikit overhead dan lebih aman).

Konfigurasi parameter "bind-address" sangat penting di sini. Perhatikan bahwa pengikatan MySQL terbatas pada tidak satu pun, satu atau semua alamat IP (0.0.0.0) di server. Jika Anda tidak punya pilihan dan membutuhkan MySQL untuk mendengarkan semua antarmuka jaringan, batasi akses ke layanan MySQL dari sumber yang dikenal baik. Gunakan aplikasi firewall atau grup keamanan untuk mengizinkan akses hanya dari host yang perlu mengakses database secara langsung.

Terkadang, server MySQL harus diekspos ke jaringan publik untuk tujuan integrasi (misalnya, pemantauan, audit, pencadangan, dll). Tidak apa-apa selama Anda menggambar perbatasan di sekitarnya. Jangan biarkan sumber yang tidak diinginkan “melihat” server MySQL. Anda dapat bertaruh berapa banyak orang di dunia yang tahu 3306 adalah port default untuk layanan MySQL, dan hanya dengan melakukan pemindaian port terhadap alamat jaringan, penyerang dapat membuat daftar server MySQL yang terbuka di subnet dalam waktu kurang dari satu menit. Sebaiknya, gunakan port MySQL kustom dengan mengonfigurasi parameter "port" di file konfigurasi MySQL untuk meminimalkan risiko paparan.

Tinjau Kebijakan Pengguna

Membatasi pengguna tertentu untuk memegang hak administrasi kritis, terutama GRANT, SUPER dan PROCESS. Anda juga dapat mengaktifkan super_read_only jika server adalah slave, hanya tersedia di MySQL 5.7.8 dan Percona Server 5.6.21 dan yang lebih baru (sayangnya tidak dengan MariaDB). Saat diaktifkan, server tidak akan mengizinkan pembaruan apa pun, selain memperbarui repositori replikasi jika log status budak adalah tabel, bahkan untuk pengguna yang memiliki hak istimewa SUPER. Hapus database pengujian default dan semua pengguna dengan kata sandi kosong untuk mempersempit cakupan penetrasi. Ini adalah salah satu pemeriksaan keamanan yang dilakukan oleh ClusterControl, yang diimplementasikan sebagai penasihat basis data.

Ini juga merupakan ide yang baik untuk membatasi jumlah koneksi yang diizinkan untuk satu akun. Anda dapat melakukannya dengan mengatur variabel max_user_connections di mysqld (defaultnya adalah 0, sama dengan tidak terbatas) atau menggunakan opsi kontrol sumber daya dalam pernyataan GRANT/CREATE USER/ALTER USER. Pernyataan GRANT mendukung pembatasan jumlah koneksi simultan ke server oleh sebuah akun, misalnya:

mysql> GRANT ALL PRIVILEGES ON db.* TO 'db_user'@'localhost' WITH MAX_USER_CONNECTIONS 2;

Nama pengguna administrator default di server MySQL adalah "root". Peretas sering berusaha mendapatkan akses ke izinnya. Untuk membuat tugas ini lebih sulit, ganti nama "root" menjadi sesuatu yang lain. Nama pengguna MySQL bisa sampai 32 karakter (16 karakter sebelum MySQL 5.7.8). Dimungkinkan untuk menggunakan nama pengguna yang lebih panjang untuk pengguna admin super dengan menggunakan pernyataan RENAME seperti yang ditunjukkan di bawah ini:

mysql> RENAME USER root TO new_super_administrator_username;

Catatan tambahan untuk pengguna ClusterControl, ClusterControl perlu mengetahui pengguna root MySQL dan kata sandi untuk mengotomatisasi dan mengelola server database untuk Anda. Secara default, itu akan mencari 'root'. Jika Anda mengganti nama pengguna root menjadi sesuatu yang lain, tentukan “monitored_mysql_root_user={new_user}” di dalam cmon_X.cnf (di mana X adalah ID cluster) dan mulai ulang layanan CMON untuk menerapkan perubahan.

Kebijakan Cadangan

Meskipun para peretas menyatakan bahwa Anda akan mendapatkan kembali data Anda setelah uang tebusan dibayarkan, hal ini biasanya tidak terjadi. Meningkatkan frekuensi pencadangan akan meningkatkan kemungkinan untuk memulihkan data Anda yang terhapus. Misalnya, alih-alih melakukan pencadangan penuh seminggu sekali dengan pencadangan tambahan harian, Anda dapat menjadwalkan pencadangan penuh sekali sehari dengan pencadangan tambahan setiap jam. Anda dapat melakukannya dengan mudah dengan fitur manajemen pencadangan ClusterControl, dan memulihkan data Anda jika terjadi kesalahan.

Jika Anda mengaktifkan log biner (binlog), itu lebih baik. Anda dapat membuat cadangan penuh setiap hari dan mencadangkan log biner. Binlog penting untuk pemulihan point-in-time dan harus dicadangkan secara teratur sebagai bagian dari prosedur pencadangan Anda. DBA cenderung melewatkan metode sederhana ini, yang bernilai setiap sen. Jika Anda diretas, Anda selalu dapat memulihkan ke titik terakhir sebelum itu terjadi, asalkan peretas tidak membersihkan log biner. Perhatikan bahwa pembersihan log biner hanya dapat dilakukan jika penyerang memiliki hak istimewa SUPER.

Satu hal lagi yang penting adalah bahwa file cadangan harus dapat dipulihkan. Verifikasi cadangan sesekali, dan hindari kejutan buruk saat Anda perlu memulihkan.

Amankan Server Web/Aplikasi Anda

Nah, jika Anda telah mengisolasi server MySQL Anda, masih ada peluang bagi penyerang untuk mengaksesnya melalui web atau server aplikasi. Dengan menyuntikkan skrip berbahaya (misalnya, Cross-Site Scripting, injeksi SQL) terhadap situs web target, seseorang dapat masuk ke direktori aplikasi, dan memiliki kemampuan untuk membaca file aplikasi. Ini mungkin berisi informasi sensitif, misalnya, kredensial login database. Dengan melihat ini, penyerang dapat dengan mudah masuk ke database, menghapus semua tabel dan meninggalkan tabel “tebusan” di dalamnya. Itu tidak harus menjadi pengguna root MySQL untuk menebus korban.

Ada ribuan cara untuk mengkompromikan server web dan Anda tidak dapat benar-benar menutup port masuk 80 atau 443 untuk tujuan ini. Lapisan perlindungan lain diperlukan untuk melindungi server web Anda dari injeksi berbasis HTTP. Anda dapat menggunakan Web Application Firewall (WAF) seperti Apache ModSecurity, NAXSI (WAF untuk nginx), WebKnight (WAF untuk IIS) atau cukup menjalankan server web Anda di Jaringan Pengiriman Konten (CDN) yang aman seperti CloudFlare, Akamai atau Amazon CloudFront.

Selalu Tetap Terkini

Anda mungkin pernah mendengar tentang eksploitasi MySQL zero-day kritis, di mana pengguna yang tidak memiliki hak istimewa dapat meningkatkan dirinya menjadi pengguna super? Kedengarannya menakutkan. Untungnya, semua vendor yang dikenal telah memperbarui repositori mereka untuk menyertakan perbaikan bug untuk masalah ini.

Untuk penggunaan produksi, sangat disarankan bagi Anda untuk menginstal paket MySQL/MariaDB dari repositori vendor. Jangan mengandalkan repositori sistem operasi default, di mana paket biasanya sudah usang. Jika Anda menjalankan di lingkungan cluster seperti Galera Cluster, atau bahkan MySQL Replication, Anda selalu memiliki pilihan untuk menambal sistem dengan waktu henti minimal. Jadikan ini sebagai rutinitas dan cobalah untuk mengotomatiskan prosedur peningkatan sebanyak mungkin.

ClusterControl mendukung peningkatan versi kecil (satu node pada satu waktu) untuk MySQL/MariaDB dengan satu klik. Pemutakhiran versi utama (misalnya, dari MySQL 5.6 ke MySQL 5.7) biasanya memerlukan penghapusan instalasi paket yang ada dan merupakan tugas yang berisiko untuk diotomatisasi. Perencanaan dan pengujian yang cermat diperlukan untuk peningkatan semacam itu.

Kesimpulan

Ransomware adalah pot emas mudah-uang. Kami mungkin akan melihat lebih banyak pelanggaran keamanan di masa depan, dan lebih baik mengambil tindakan sebelum sesuatu terjadi. Peretas menargetkan banyak server yang rentan di luar sana, dan kemungkinan besar serangan ini juga akan menyebar ke teknologi basis data lainnya. Melindungi data Anda merupakan tantangan konstan bagi administrator database. Musuh sebenarnya bukanlah pelakunya, tetapi sikap kita dalam melindungi aset penting kita.