Cara Melindungi Database MySQL &MariaDB Anda Terhadap Serangan Siber Saat di Jaringan Publik

Terkadang menjalankan server database MySQL pada jaringan publik atau terbuka tidak dapat dihindari. Ini adalah pengaturan umum di lingkungan shared hosting, di mana server dikonfigurasi dengan beberapa layanan dan sering berjalan dalam server yang sama dengan server database. Bagi mereka yang memiliki pengaturan seperti ini, Anda harus selalu memiliki semacam perlindungan terhadap serangan siber seperti penolakan layanan, peretasan, perengkahan, pembobolan data; semua yang dapat mengakibatkan hilangnya data. Ini adalah hal-hal yang selalu ingin kami hindari untuk server database kami.

Berikut adalah beberapa tips yang dapat kami lakukan untuk meningkatkan keamanan MySQL atau MariaDB kami.

Pindai Server Database Anda Secara Teratur

Perlindungan terhadap file berbahaya di server sangat penting. Pindai server secara teratur untuk mencari virus, spyware, malware, atau rootkit, terutama jika server basis data terletak bersama dengan layanan lain seperti server surat, HTTP, FTP, DNS, WebDAV, telnet, dan sebagainya. Umumnya, sebagian besar masalah peretasan basis data berasal dari tingkat aplikasi yang menghadapi jaringan publik. Jadi, penting untuk memindai semua file, terutama file web/aplikasi karena mereka adalah salah satu titik masuk untuk masuk ke server. Jika itu disusupi, peretas dapat masuk ke direktori aplikasi, dan memiliki kemampuan untuk membaca file aplikasi. Ini mungkin berisi informasi sensitif, misalnya, kredensial login database.

ClamAV adalah salah satu solusi antivirus yang paling dikenal dan dipercaya secara luas untuk berbagai sistem operasi, termasuk Linux. Ini gratis dan sangat mudah dipasang dan dilengkapi dengan mekanisme deteksi yang cukup baik untuk mencari hal-hal yang tidak diinginkan di server Anda. Jadwalkan pemindaian berkala di cron job, misalnya:

0 3 * * * /bin/freshclam ; /bin/clamscan / --recursive=yes -i > /tmp/clamav.log ; mail -s clamav_log_`hostname` [email protected] < /tmp/clamav.log

Di atas akan memperbarui database virus ClamAV, memindai semua direktori dan file dan mengirimi Anda email tentang status eksekusi dan laporan setiap hari pada jam 3 pagi.

Gunakan Peran dan Hak Pengguna yang Lebih Ketat

Saat membuat pengguna MySQL, jangan izinkan semua host mengakses server MySQL dengan host wildcard (%). Anda harus memindai host MySQL Anda dan mencari nilai host wildcard, seperti yang ditunjukkan pada pernyataan berikut:

mysql> SELECT user,host FROM mysql.user WHERE host = '%';
+---------+------+
| user    | host |
+---------+------+
| myadmin | %    |
| sbtest  | %    |
| user1   | %    |
+---------+------+

Dari output di atas, tegaskan atau hapus semua pengguna yang hanya memiliki nilai '%' di bawah kolom Host. Pengguna yang perlu mengakses server MySQL dari jarak jauh dapat dipaksa untuk menggunakan metode tunneling SSH, yang tidak memerlukan konfigurasi host jarak jauh untuk pengguna MySQL. Sebagian besar klien administrasi MySQL seperti MySQL Workbench dan HeidiSQL dapat dikonfigurasi untuk terhubung ke server MySQL melalui penyetelan SSH, oleh karena itu koneksi jarak jauh untuk pengguna MySQL dapat dihilangkan sepenuhnya.

Juga, batasi hak istimewa SUPER hanya untuk pengguna dari localhost, atau sambungkan melalui file soket UNIX. Berhati-hatilah saat memberikan hak istimewa FILE kepada pengguna non-root karena mengizinkan membaca dan menulis file di server menggunakan pernyataan LOAD DATA INFILE dan SELECT ... INTO OUTFILE. Setiap pengguna yang diberikan hak istimewa ini juga dapat membaca atau menulis file apa pun yang dapat dibaca atau ditulis oleh server MySQL.

Ubah Pengaturan Default Basis Data

Dengan menjauh dari pengaturan, penamaan, dan konfigurasi default, kita dapat mengurangi vektor serangan menjadi beberapa kali lipat. Tindakan berikut adalah beberapa contoh konfigurasi default yang dapat dengan mudah diubah oleh DBA tetapi biasanya diabaikan terkait dengan MySQL:

Ubah port MySQL default ke selain 3306.
Ganti nama nama pengguna root MySQL menjadi selain "root".
Terapkan masa berlaku sandi dan kurangi masa pakai sandi untuk semua pengguna.
Jika MySQL ditempatkan bersama dengan server aplikasi, terapkan koneksi melalui file soket UNIX saja, dan berhenti mendengarkan pada port 3306 untuk semua alamat IP.
Terapkan enkripsi server-klien dan enkripsi replikasi server-server.

Kami sebenarnya telah membahas ini secara rinci dalam posting blog ini, Cara Mengamankan Server MySQL/MariaDB.

Mengatur Budak yang Tertunda

Budak yang tertunda hanyalah budak biasa, namun server budak secara sengaja mengeksekusi transaksi lebih lambat dari master dengan setidaknya jumlah waktu tertentu, tersedia dari MySQL 5.6. Pada dasarnya, sebuah event yang diterima dari master tidak dieksekusi sampai setidaknya N detik lebih lambat dari eksekusinya pada master. Hasilnya adalah bahwa budak akan mencerminkan keadaan tuannya beberapa waktu lalu.

Budak yang tertunda dapat digunakan untuk memulihkan data, yang akan sangat membantu ketika masalah ditemukan segera, dalam periode penundaan. Misalkan kita mengkonfigurasi budak dengan penundaan 6 jam dari master. Jika database kami diubah atau dihapus (secara tidak sengaja oleh pengembang atau sengaja oleh peretas) dalam rentang waktu ini, ada kemungkinan bagi kami untuk kembali ke momen tepat sebelum itu terjadi dengan menghentikan master saat ini, kemudian menghidupkan server budak sampai titik tertentu dengan perintah berikut:

# on delayed slave
mysql> STOP SLAVE;
mysql> START SLAVE UNTIL MASTER_LOG_FILE='xxxxx', MASTER_LOG_POS=yyyyyy;

Di mana 'xxxxx' adalah file log biner dan 'yyyyy' adalah posisi tepat sebelum bencana terjadi (gunakan alat mysqlbinlog untuk memeriksa peristiwa tersebut). Terakhir, promosikan slave untuk menjadi master baru dan layanan MySQL Anda sekarang kembali beroperasi seperti biasa. Metode ini mungkin merupakan cara tercepat untuk memulihkan database MySQL Anda di lingkungan produksi tanpa harus memuat ulang cadangan. Memiliki sejumlah budak tertunda dengan durasi panjang yang berbeda, seperti yang ditunjukkan di blog ini, Beberapa Budak Replikasi Tertunda untuk Pemulihan Bencana dengan RTO Rendah tentang cara menyiapkan server replikasi tertunda yang hemat biaya di atas wadah Docker.

Aktifkan Logging Biner

Log biner umumnya disarankan untuk diaktifkan meskipun Anda menjalankan server MySQL/MariaDB yang berdiri sendiri. Log biner berisi informasi tentang pernyataan SQL yang mengubah isi database. Informasi disimpan dalam bentuk "peristiwa" yang menjelaskan modifikasi. Terlepas dari dampak kinerja, memiliki log biner memungkinkan Anda untuk memiliki kemungkinan untuk memutar ulang server database Anda ke titik yang tepat di mana Anda ingin memulihkannya, juga dikenal sebagai pemulihan titik-dalam-waktu (PITR). Logging biner juga wajib untuk replikasi.

Dengan mengaktifkan logging biner, seseorang harus menyertakan file log biner dan informasi posisi saat mengambil cadangan penuh. Untuk mysqldump, menggunakan flag --master-data dengan nilai 1 atau 2 akan mencetak informasi yang diperlukan yang dapat kita gunakan sebagai titik awal untuk melanjutkan database saat memutar ulang log biner nanti.

Dengan mengaktifkan logging biner, Anda dapat menggunakan fitur pemulihan keren lainnya yang disebut flashback, yang dijelaskan di bagian berikutnya.

Aktifkan Flashback

Fitur flashback tersedia di MariaDB, di mana Anda dapat memulihkan kembali data ke snapshot sebelumnya di database MySQL atau dalam tabel. Flashback menggunakan mysqlbinlog untuk membuat pernyataan rollback dan membutuhkan gambar baris log biner LENGKAP untuk itu. Jadi, untuk menggunakan fitur ini, server MySQL/MariaDB harus dikonfigurasi dengan yang berikut:

[mysqld]
...
binlog_format = ROW
binlog_row_image = FULL

Diagram arsitektur berikut mengilustrasikan bagaimana flashback dikonfigurasi pada salah satu slave:

Untuk melakukan operasi flashback, pertama Anda harus menentukan tanggal dan waktu ketika Anda ingin "melihat" data, atau file dan posisi log biner. Kemudian, gunakan flag --flashback dengan utilitas mysqlbinlog untuk menghasilkan pernyataan SQL untuk mengembalikan data ke titik itu. Dalam file SQL yang dihasilkan, Anda akan melihat bahwa acara DELETE dikonversi ke INSERT dan sebaliknya, dan juga menukar bagian WHERE dan SET dari acara UPDATE.

Baris perintah berikut harus dijalankan pada slave2 (dikonfigurasi dengan binlog_row_image=FULL):

$ mysqlbinlog --flashback --start-datetime="2020-02-17 01:30:00"  /var/lib/mysql/mysql-bin.000028 -v --database=shop --table=products > flashback_to_2020-02-17_013000.sql

Kemudian, lepaskan slave2 dari rantai replikasi karena kita akan memecahnya dan menggunakan server untuk mengembalikan data kita:

mysql> STOP SLAVE;
mysql> RESET MASTER;
mysql> RESET SLAVE ALL;

Terakhir, impor file SQL yang dihasilkan ke server MariaDB untuk database shop di slave2:

$ mysql -u root -p shop < flashback_to_2020-02-17_013000.sql

Ketika hal di atas diterapkan, tabel "produk" akan berada pada status 17-02-2020 01:30:00. Secara teknis, file SQL yang dihasilkan dapat diterapkan ke server MariaDB dan MySQL. Anda juga dapat mentransfer biner mysqlbinlog dari server MariaDB sehingga Anda dapat menggunakan fitur flashback di server MySQL. Namun, implementasi MySQL GTID berbeda dari MariaDB sehingga memulihkan file SQL mengharuskan Anda menonaktifkan MySQL GTID.

Beberapa keuntungan menggunakan flashback adalah Anda tidak perlu menghentikan server MySQL/MariaDB untuk menjalankan operasi ini. Ketika jumlah data yang akan dikembalikan kecil, proses flashback jauh lebih cepat daripada memulihkan data dari full backup.

Log Semua Kueri Basis Data

Log umum pada dasarnya menangkap setiap pernyataan SQL yang dieksekusi oleh klien di server MySQL. Namun, ini mungkin bukan keputusan yang populer di server produksi yang sibuk karena dampak kinerja dan konsumsi ruang. Jika kinerja penting, log biner memiliki prioritas lebih tinggi untuk diaktifkan. Log umum dapat diaktifkan selama runtime dengan menjalankan perintah berikut:

mysql> SET global general_log_file='/tmp/mysql.log'; 
mysql> SET global log_output = 'file';
mysql> SET global general_log = ON;

Anda juga dapat mengatur output log umum ke tabel:

mysql> SET global log_output = 'table';

Anda kemudian dapat menggunakan pernyataan SELECT standar terhadap tabel mysql.general_log untuk mengambil kueri. Harapkan sedikit lebih banyak dampak kinerja saat menjalankan dengan konfigurasi ini seperti yang ditunjukkan dalam entri blog ini.

Jika tidak, Anda dapat menggunakan alat pemantauan eksternal yang dapat melakukan pengambilan sampel dan pemantauan kueri sehingga Anda dapat memfilter dan mengaudit kueri yang masuk ke server. ClusterControl dapat digunakan untuk mengumpulkan dan meringkas semua kueri Anda, seperti yang ditunjukkan pada tangkapan layar berikut di mana kami memfilter semua kueri yang berisi string DELETE:

Informasi serupa juga tersedia di bawah halaman kueri teratas ProxySQL (jika aplikasi Anda menghubungkan melalui ProxySQL):

Ini dapat digunakan untuk melacak perubahan terbaru yang terjadi pada server database dan juga dapat digunakan untuk tujuan audit.

Kesimpulan

Server MySQL dan MariaDB Anda harus selalu terlindungi dengan baik karena biasanya berisi data sensitif yang dijaga oleh penyerang. Anda juga dapat menggunakan ClusterControl untuk mengelola aspek keamanan server database Anda, seperti yang ditunjukkan oleh posting blog ini, Cara Mengamankan Database Open Source Anda dengan ClusterControl.