Cara Mengamankan VPS dari Malware dan DDoS

Cara mengamankan VPS merupakan hal penting yang perlu dipahami sebelum server digunakan untuk menjalankan website, aplikasi, database, mail server, maupun layanan publik lainnya. VPS yang sudah terhubung ke internet dapat menerima koneksi dari berbagai alamat IP di seluruh dunia, termasuk koneksi otomatis yang bertujuan mencari port terbuka, mencoba kata sandi, atau menemukan celah keamanan pada aplikasi.

Banyak pemilik VPS menganggap server sudah aman selama website bisa diakses dan layanan berjalan normal. Padahal, aktivitas mencurigakan terkadang berlangsung tanpa menimbulkan gangguan yang terlihat. Sebuah server bisa saja digunakan untuk mengirim spam, menambang cryptocurrency, menjalankan bot, menyebarkan malware, atau menjadi bagian dari serangan terhadap server lain tanpa sepengetahuan pemiliknya.

Masalah lain yang sering muncul adalah lonjakan trafik yang membuat website lambat, penggunaan CPU meningkat, hingga server tidak bisa diakses. Kondisi tersebut belum tentu disebabkan oleh serangan DDoS. Bisa juga berasal dari aplikasi yang bermasalah, proses backup, bot pencari, atau konfigurasi server yang kurang tepat.

Oleh karena itu, pengamanan VPS sebaiknya dilakukan sejak awal instalasi, bukan setelah server mengalami masalah. Ada beberapa langkah yang bisa diterapkan untuk memperkecil risiko serangan, mulai dari memperbarui sistem operasi, mengamankan akses SSH, mengatur firewall, melindungi aplikasi web, hingga memantau aktivitas server secara rutin.

Artikel ini membahas langkah-langkah tersebut menggunakan contoh perintah Linux, terutama untuk VPS berbasis Ubuntu atau Debian. Beberapa perintah mungkin perlu disesuaikan apabila server menggunakan distribusi Linux atau panel pengelolaan yang berbeda.

1. Memahami Bagaimana VPS Bisa Terkena Malware dan DDoS

Sebelum mulai melakukan konfigurasi, penting untuk memahami bahwa malware dan DDoS merupakan dua jenis ancaman yang berbeda.

Malware adalah perangkat lunak berbahaya yang dijalankan pada sistem tanpa izin atau digunakan untuk tujuan yang merugikan. Malware dapat masuk melalui aplikasi yang memiliki celah keamanan, plugin yang rentan, kredensial yang bocor, skrip berbahaya, atau file yang diunggah melalui aplikasi web.

Setelah berhasil masuk, penyerang mungkin mencoba mendapatkan hak akses lebih tinggi, membuat akun tersembunyi, menambahkan tugas otomatis, atau menjalankan proses yang tetap aktif setelah server direstart.

Sementara itu, DDoS (Distributed Denial of Service) adalah serangan yang membanjiri layanan menggunakan trafik atau permintaan dari banyak sumber sehingga layanan kesulitan melayani pengguna yang sebenarnya.

Ada juga aktivitas yang sering dianggap sebagai DDoS, padahal hanya berupa pemindaian port atau percobaan login otomatis. Perbedaan ini penting karena penanganannya tidak selalu sama.

Berikut beberapa sumber risiko yang perlu diperhatikan:

Port SSH terbuka ke seluruh internet dengan autentikasi kata sandi yang lemah.
Panel admin, database, Redis, atau layanan internal terbuka tanpa pembatasan akses.
WordPress, framework, plugin, dan dependensi yang tidak diperbarui.
Penggunaan akun administrator untuk menjalankan semua aplikasi.
Kredensial database atau API yang tersimpan dalam file dan dapat diakses publik.
Tidak adanya firewall, pembatasan login, atau pemantauan penggunaan sumber daya.
Aplikasi yang dapat menjalankan perintah sistem tanpa validasi memadai.

Tidak semua port terbuka berarti server rentan, dan tidak semua trafik tinggi merupakan serangan. Tujuan pengamanan adalah mengurangi permukaan serangan, membatasi dampak ketika terjadi masalah, serta mempercepat proses deteksi dan pemulihan.

2. Perbarui Sistem Operasi dan Paket Server

Langkah pertama yang sebaiknya dilakukan adalah memperbarui sistem operasi. Pembaruan tidak hanya membawa fitur baru, tetapi juga memperbaiki celah keamanan yang sudah diketahui.

Pada Ubuntu atau Debian, jalankan:

sudo apt update
sudo apt upgrade

Perintah pertama memperbarui daftar paket yang tersedia, sedangkan perintah kedua memasang pembaruan paket yang sudah terinstal.

Sebelum memperbarui server produksi, pastikan tersedia backup dan periksa apakah pembaruan membutuhkan restart layanan atau sistem operasi. Untuk kernel atau komponen penting tertentu, restart mungkin diperlukan agar perbaikan benar-benar digunakan.

Untuk mengetahui apakah sistem menyarankan restart pada Ubuntu, periksa:

test -f /var/run/reboot-required \
  && echo "Restart diperlukan" \
  || echo "Tidak ada penanda restart"

Jika server menggunakan panel seperti aaPanel atau cPanel, jangan hanya memperbarui paket melalui terminal tanpa memperhatikan kompatibilitas panel dan layanan yang dikelolanya. Ikuti mekanisme pembaruan yang sesuai dengan sistem tersebut.

Selain sistem operasi, periksa pembaruan untuk:

Web server seperti Nginx atau Apache.
PHP dan ekstensi yang digunakan aplikasi.
Database MySQL atau MariaDB.
Framework serta library aplikasi.
Plugin dan tema CMS.
Panel administrasi server.
Docker, image container, dan dependensi aplikasi.

Paket yang sudah tidak mendapat dukungan keamanan sebaiknya diganti dengan versi yang masih didukung. Hindari menunda pembaruan terlalu lama hanya karena server terlihat berjalan normal.

3. Amankan Akses SSH ke VPS

SSH merupakan salah satu jalur administrasi utama pada server Linux. Jika akses SSH dibiarkan menggunakan kata sandi lemah atau akun administrator yang mudah ditebak, risiko pengambilalihan server akan meningkat.

Gunakan SSH key

SSH key memungkinkan administrator melakukan autentikasi menggunakan pasangan kunci publik dan privat. Kunci privat tetap disimpan pada perangkat administrator, sedangkan kunci publik ditempatkan di server.

Pada komputer lokal, buat kunci menggunakan:

ssh-keygen -t ed25519

Sebaiknya gunakan passphrase untuk melindungi kunci privat. Setelah itu, pasang kunci publik ke server menggunakan metode yang tersedia, misalnya:

ssh-copy-id username@IP_VPS

Ganti username dan IP_VPS sesuai konfigurasi server. Jika ssh-copy-id tidak tersedia, kunci publik dapat dipasang secara manual ke file ~/.ssh/authorized_keys milik akun yang benar dengan izin file yang sesuai.

Kemudian, uji login menggunakan kunci dari terminal baru. Jangan menonaktifkan autentikasi kata sandi sebelum akses SSH key terbukti berfungsi. Jika salah konfigurasi, administrator bisa kehilangan akses ke server.

Nonaktifkan login root langsung

Setelah tersedia akun administrator non-root yang dapat menggunakan sudo, login root langsung dapat dinonaktifkan.

Edit konfigurasi SSH:

sudo nano /etc/ssh/sshd_config

Periksa atau atur opsi berikut:

PermitRootLogin no
PubkeyAuthentication yes

Jika ingin menonaktifkan autentikasi kata sandi, pastikan seluruh administrator yang memerlukan akses sudah berhasil menggunakan SSH key, lalu atur:

PasswordAuthentication no

Validasi konfigurasi sebelum menerapkannya:

sudo sshd -t

Jika tidak ada pesan kesalahan, muat ulang layanan SSH menggunakan nama service yang sesuai dengan distribusi, misalnya:

sudo systemctl reload ssh

Pada sistem tertentu, nama layanannya adalah sshd.

Pertahankan sesi SSH lama sampai login baru berhasil diuji. Jika menggunakan VPS dengan panel administrasi, pastikan perubahan tersebut tidak bertentangan dengan pengelolaan akses oleh panel.

Apakah port SSH harus diganti?

Port SSH dapat dipindahkan dari port standar 22 ke port lain untuk mengurangi sebagian percobaan otomatis yang hanya menyasar port umum. Namun, langkah ini bukan pengganti SSH key, firewall, dan pembatasan akses.

Jika port diubah, sesuaikan firewall dan konfigurasi klien SSH. Jangan sampai port baru justru terbuka untuk semua sumber tanpa alasan.

4. Gunakan Firewall untuk Membatasi Port yang Terbuka

Firewall membantu menentukan koneksi mana yang boleh masuk dan keluar dari server. Prinsip dasarnya sederhana: hanya buka layanan yang benar-benar dibutuhkan.

Pada Ubuntu, UFW dapat digunakan sebagai pengelola firewall yang relatif mudah dipahami.

Periksa statusnya terlebih dahulu:

sudo ufw status verbose

Sebelum mengaktifkan firewall, izinkan SSH agar koneksi administrasi tidak terputus:

sudo ufw allow OpenSSH

Kemudian izinkan layanan web jika VPS memang digunakan untuk hosting website:

sudo ufw allow 80/tcp
sudo ufw allow 443/tcp

Atur kebijakan koneksi masuk dan keluar sesuai kebutuhan server:

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw enable

Perintah di atas merupakan contoh konfigurasi dasar, bukan aturan universal untuk semua server. Server yang menjalankan mail server, VPN, DNS, game server, atau layanan lain membutuhkan aturan tambahan yang sesuai.

Periksa kembali hasilnya:

sudo ufw status numbered

Port yang umum perlu diperiksa antara lain:

Port	Layanan	Rekomendasi
22/tcp	SSH	Batasi ke IP administrator jika memungkinkan
80/tcp	HTTP	Buka jika diperlukan untuk website
443/tcp	HTTPS	Buka jika diperlukan untuk website
3306/tcp	MySQL/MariaDB	Jangan buka publik jika tidak diperlukan
6379/tcp	Redis	Batasi ke jaringan internal
27017/tcp	MongoDB	Jangan buka publik tanpa kebutuhan dan proteksi
Port panel	Panel administrasi	Batasi ke IP atau VPN jika memungkinkan

Nomor port panel bisa berbeda-beda. Periksa dokumentasi dan konfigurasi layanan yang digunakan sebelum menambahkan aturan.

Penting: firewall pada sistem operasi perlu diselaraskan dengan firewall penyedia VPS, aturan jaringan virtual, dan konfigurasi container. Pada Docker, port yang dipublikasikan dapat melewati jalur pemrosesan UFW tertentu. Jangan menganggap aturan UFW otomatis melindungi semua port container. Pastikan aturan filter yang relevan benar-benar berlaku dan uji akses dari luar server.

5. Jangan Membuka Semua Layanan ke Internet

Salah satu kesalahan konfigurasi VPS adalah membuka port sebanyak mungkin agar semua layanan mudah diakses. Padahal, setiap layanan yang dapat dijangkau dari internet menambah permukaan serangan.

Contohnya, aplikasi web yang menggunakan MySQL biasanya tidak membutuhkan database agar dapat diakses langsung dari internet. Jika database hanya digunakan oleh aplikasi pada server yang sama, layanan tersebut sebaiknya mendengarkan koneksi lokal saja.

Periksa port yang sedang mendengarkan koneksi:

sudo ss -lntup

Perintah ini menampilkan port TCP dan UDP yang sedang digunakan, termasuk alamat IP tempat layanan mendengarkan koneksi.

Perhatikan perbedaan alamat berikut:

127.0.0.1 biasanya menunjukkan layanan hanya menerima koneksi melalui loopback IPv4.
0.0.0.0 menunjukkan layanan mendengarkan pada semua alamat IPv4 lokal yang tersedia.
:: menunjukkan layanan mendengarkan pada alamat IPv6 yang tersedia, bergantung pada konfigurasi sistem.

Alamat 0.0.0.0 tidak selalu berarti layanan bisa diakses publik, karena firewall dan aturan jaringan masih dapat membatasi aksesnya. Namun, konfigurasi tersebut patut diperiksa.

Untuk layanan internal seperti database, Redis, atau API privat, gunakan loopback atau jaringan privat apabila memungkinkan. Jika aplikasi berjalan dalam container terpisah, gunakan jaringan internal yang sesuai dan jangan memublikasikan port layanan yang tidak diperlukan.

Jika layanan harus diakses dari server lain, batasi sumber koneksinya berdasarkan alamat IP, VPN, atau jaringan privat. Hindari menggunakan 0.0.0.0/0 sebagai sumber yang diizinkan hanya karena lebih praktis.

6. Lindungi Website, CMS, dan Aplikasi yang Berjalan di VPS

VPS yang sudah memiliki firewall tetap bisa terkena malware jika aplikasi di dalamnya memiliki celah keamanan. Penyerang tidak selalu masuk melalui SSH. Mereka juga bisa mengeksploitasi aplikasi yang dapat diakses melalui HTTP atau HTTPS.

Jika menggunakan WordPress, Laravel, aplikasi PHP, atau framework lain, lakukan pemeriksaan berikut.

Pertama, perbarui aplikasi dan dependensinya. Gunakan versi yang masih mendapat dukungan keamanan. Jangan memasang plugin atau library dari sumber yang tidak jelas hanya karena menawarkan fitur tertentu.

Kedua, hapus komponen yang tidak digunakan. Plugin, tema, modul, dan aplikasi lama yang dibiarkan terpasang bisa menjadi jalur serangan apabila masih dapat diakses atau memiliki celah keamanan.

Ketiga, batasi hak akses file. Aplikasi sebaiknya berjalan menggunakan akun layanan tersendiri dan hanya memiliki izin yang dibutuhkan. Hindari menjalankan seluruh proses web sebagai root.

Untuk aplikasi PHP, misalnya, jangan memberikan izin tulis kepada semua pengguna secara membabi buta. Direktori unggahan mungkin membutuhkan akses tulis, tetapi file konfigurasi dan kode aplikasi sebaiknya tidak bisa diubah oleh proses web tanpa kebutuhan yang jelas.

Keempat, lindungi file konfigurasi dan kredensial. File .env, konfigurasi database, private key, dan token API tidak boleh dapat diunduh melalui browser. Pastikan document root mengarah ke direktori publik yang tepat, seperti direktori public pada aplikasi Laravel, bukan ke seluruh direktori proyek.

Kelima, validasi unggahan file. Jika aplikasi mengizinkan pengguna mengunggah gambar atau dokumen, validasi jenis file, ukuran, dan nama file di sisi server. Jangan hanya mengandalkan ekstensi file yang dikirim pengguna. Bila memungkinkan, simpan file di luar document root dan cegah eksekusi skrip di direktori unggahan.

Keenam, gunakan HTTPS. Sertifikat TLS membantu melindungi komunikasi antara pengguna dan server. HTTPS tidak menghilangkan celah aplikasi, tetapi dapat mengurangi risiko penyadapan dan manipulasi data selama transmisi.

Untuk Laravel, periksa pula konfigurasi environment produksi. Pastikan mode debug tidak aktif dan informasi kesalahan internal tidak ditampilkan kepada pengunjung. Contoh pengaturan yang umum digunakan adalah APP_DEBUG=false dan APP_ENV=production.

Jangan menyalin konfigurasi tersebut secara membabi buta ke setiap framework. Ikuti mekanisme konfigurasi aplikasi yang benar dan pastikan log kesalahan tetap tersedia bagi administrator.

7. Pasang Proteksi untuk Percobaan Login Berulang

Server yang memiliki layanan SSH terbuka sering menerima percobaan login otomatis. Aktivitas ini belum tentu berarti server telah berhasil ditembus, tetapi tetap perlu dikendalikan.

Salah satu pilihan pada Linux adalah Fail2ban. Layanan ini memantau log tertentu dan dapat memblokir alamat IP sementara ketika memenuhi pola kegagalan autentikasi yang dikonfigurasi.

Pada Ubuntu atau Debian, instal dengan:

sudo apt update
sudo apt install fail2ban

Setelah terpasang, periksa status layanan:

sudo systemctl status fail2ban

Konfigurasi dapat disesuaikan melalui file lokal seperti /etc/fail2ban/jail.local. Sebagai contoh, pengaturan jail SSH bisa dibuat seperti berikut:

[sshd]
enabled = true
backend = systemd
maxretry = 5
findtime = 10m
bantime = 1h

Simpan konfigurasi, lalu restart layanan:

sudo systemctl restart fail2ban
sudo fail2ban-client status
sudo fail2ban-client status sshd

Contoh tersebut mengatur pemblokiran berdasarkan lima kegagalan dalam jangka waktu sepuluh menit, dengan durasi blokir satu jam. Pastikan jail SSH sesuai dengan backend log dan nama layanan pada distribusi yang digunakan.

Fail2ban membantu mengurangi percobaan login berulang, tetapi bukan pengganti autentikasi yang kuat. Penyerang bisa menggunakan banyak alamat IP, sehingga pembatasan sumber SSH dan penggunaan kunci publik tetap lebih penting.

Jika menggunakan panel seperti cPanel atau aaPanel, periksa apakah panel sudah menyediakan mekanisme pembatasan login. Hindari memasang aturan yang saling bertentangan atau mengunci akses administrator sendiri.

8. Mengurangi Risiko Serangan DDoS dari Luar

DDoS tidak selalu dapat dicegah hanya dengan konfigurasi VPS. Jika trafik serangan memenuhi kapasitas jaringan atau jalur koneksi di sisi penyedia, firewall lokal mungkin tidak cukup untuk memulihkan akses.

Meski begitu, ada beberapa langkah yang dapat membantu mengurangi dampak serangan.

Batasi akses yang tidak diperlukan

Tutup layanan yang tidak digunakan dan batasi akses administratif. Ini mengurangi jumlah layanan yang bisa dijadikan sasaran.

Gunakan pembatasan permintaan pada web server

Untuk website yang menggunakan Nginx, fitur limit_req dapat membantu membatasi laju permintaan HTTP pada endpoint tertentu.

Contoh konfigurasi di konteks http:

limit_req_zone $binary_remote_addr zone=api_limit:10m rate=5r/s;

Kemudian, pada lokasi API yang sesuai:

location /api/ {
    limit_req zone=api_limit burst=10 nodelay;

    proxy_pass http://127.0.0.1:3000;
}

Contoh ini membatasi laju permintaan berdasarkan alamat IP dan mengizinkan sejumlah lonjakan singkat. Angka tersebut hanya ilustrasi, bukan nilai yang cocok untuk semua aplikasi. Sesuaikan dengan pola trafik normal, kebutuhan pengguna, dan kapasitas backend.

Jika aplikasi berada di balik reverse proxy, pastikan alamat IP pengunjung diidentifikasi dengan benar melalui konfigurasi proxy tepercaya. Konfigurasi yang salah bisa membuat semua pengunjung terlihat berasal dari alamat proxy yang sama atau memungkinkan manipulasi alamat IP melalui header.

Aktifkan caching untuk konten yang sesuai

Konten statis seperti gambar, CSS, JavaScript, dan halaman yang tidak berubah setiap permintaan dapat dilayani melalui cache. Ini membantu mengurangi beban aplikasi dan database saat trafik meningkat.

Namun, caching tidak selalu sesuai untuk halaman login, dashboard pribadi, transaksi, atau konten yang berbeda bagi setiap pengguna. Pastikan informasi privat tidak tersimpan atau disajikan melalui cache publik.

Pantau kapasitas server

Lonjakan penggunaan CPU, RAM, koneksi, dan bandwidth bisa menjadi tanda adanya masalah. Perintah berikut dapat membantu pemeriksaan awal:

uptime
free -h
top

Untuk memeriksa jumlah koneksi jaringan:

sudo ss -s

Untuk melihat statistik antarmuka jaringan, gunakan alat yang tersedia pada sistem, misalnya ip -s link. Penggunaan bandwidth yang tinggi perlu dibandingkan dengan pola normal dan data dari penyedia VPS.

Ketahui batas perlindungan firewall lokal

Firewall lokal dapat memblokir koneksi berdasarkan aturan yang dibuat, tetapi tidak selalu mampu menghentikan serangan volumetrik yang sudah memenuhi jalur jaringan menuju server.

Jika VPS mengalami serangan besar, hubungi penyedia VPS untuk meminta pemeriksaan trafik dan mitigasi di sisi jaringan. Untuk website publik, layanan mitigasi DDoS atau reverse proxy yang sesuai dapat menjadi lapisan tambahan.

Tidak ada konfigurasi yang menjamin VPS sepenuhnya kebal DDoS. Tujuannya adalah mengurangi permukaan serangan, menjaga kapasitas tetap memadai, dan mempersiapkan respons ketika serangan terjadi.

9. Amankan Database, Redis, dan Layanan Internal

Database merupakan komponen penting yang sering menyimpan informasi pengguna, data transaksi, konfigurasi aplikasi, dan informasi sensitif lainnya. Jika akses database tidak dibatasi, dampaknya bisa lebih besar daripada sekadar website tidak bisa dibuka.

Untuk MySQL atau MariaDB, periksa konfigurasi alamat bind pada file konfigurasi yang digunakan oleh sistem. Pada instalasi yang hanya melayani aplikasi di server yang sama, alamat loopback seperti 127.0.0.1 umumnya lebih sesuai daripada membuka database pada semua antarmuka jaringan.

Setelah melakukan perubahan, pastikan aplikasi masih dapat terhubung ke database dan periksa status layanan.

Gunakan akun database khusus untuk setiap aplikasi. Hindari menggunakan akun root database untuk koneksi aplikasi sehari-hari. Berikan hak akses hanya pada database dan operasi yang memang diperlukan.

Contoh prinsip pengamanan database:

Gunakan kata sandi yang kuat dan berbeda dari kata sandi SSH atau panel.
Jangan menyimpan kredensial di direktori publik website.
Batasi akses database ke alamat IP atau jaringan yang diperlukan.
Hapus akun dan database yang sudah tidak digunakan.
Lakukan backup secara berkala dan uji proses pemulihannya.
Hindari membuka port database ke internet tanpa kebutuhan yang jelas.

Redis juga perlu mendapatkan perhatian. Jangan menganggap Redis aman hanya karena tidak menggunakan autentikasi pada konfigurasi awal tertentu. Batasi alamat bind, gunakan ACL atau autentikasi yang sesuai, serta atur firewall agar layanan hanya dapat dijangkau oleh aplikasi yang berwenang.

Jika menggunakan Docker, periksa pula pemetaan port container. Publikasi port database atau Redis ke semua antarmuka host dapat membuat layanan bisa diakses dari luar apabila tidak ada pembatasan jaringan yang efektif.

10. Deteksi Proses Mencurigakan dan Indikasi Malware

Tidak semua malware terlihat dari tampilan website. Beberapa justru bekerja di latar belakang, menggunakan CPU untuk menambang cryptocurrency, mengirim email spam, atau menjalankan proses otomatis.

Administrator perlu membiasakan diri memeriksa aktivitas server, terutama ketika penggunaan sumber daya meningkat tanpa alasan yang jelas.

Periksa proses yang menggunakan banyak sumber daya:

top

Lihat proses dan pemiliknya dengan:

ps aux --sort=-%cpu | head -n 15

Periksa penggunaan ruang penyimpanan:

df -h

Jika CPU mendadak tinggi, periksa nama proses, akun pemilik, waktu mulai, dan apakah proses tersebut berkaitan dengan layanan yang dikenal. Proses yang menggunakan banyak CPU belum tentu malware; bisa juga berupa backup, kompresi, query database berat, atau pekerjaan aplikasi yang sah.

Selanjutnya, periksa tugas terjadwal:

crontab -l
sudo ls -la /etc/cron.d/
sudo ls -la /etc/cron.daily/

Perintah tersebut membantu memeriksa sebagian lokasi cron, tetapi tidak mencakup seluruh mekanisme penjadwalan. Periksa juga cron milik akun layanan dan timer systemd jika ada indikasi aktivitas otomatis yang tidak dikenal.

Untuk melihat layanan systemd yang sedang berjalan:

systemctl --type=service --state=running

Periksa log autentikasi pada sistem yang menggunakan systemd:

sudo journalctl -u ssh --since "24 hours ago"

Pada beberapa distribusi, nama layanan bisa berupa sshd. Log autentikasi juga dapat tersimpan di file seperti /var/log/auth.log atau /var/log/secure, bergantung pada sistem yang digunakan.

Perhatikan tanda-tanda berikut:

Proses asing yang berjalan dari direktori sementara atau direktori unggahan.
Akun pengguna baru yang tidak dikenal.
Tugas cron atau layanan systemd yang tidak pernah dibuat administrator.
Lonjakan penggunaan CPU atau bandwidth tanpa aktivitas yang sepadan.
File website yang berubah tanpa proses deployment yang diketahui.
Koneksi keluar menuju alamat atau layanan yang tidak dikenal.

Jika menemukan indikasi kompromi, jangan langsung menghapus file secara acak. Catat proses, waktu kejadian, log, dan informasi jaringan yang relevan. Isolasi server dari jaringan jika diperlukan dan memungkinkan, lalu lakukan investigasi. Jika penyerang diduga sudah mendapatkan hak akses root, menghapus satu proses atau mengganti kata sandi saja tidak menjamin server kembali bersih. Pemulihan dari sistem yang diketahui bersih sering kali lebih dapat dipercaya.

11. Gunakan Backup untuk Mengantisipasi Kerusakan dan Infeksi

Backup bukan hanya berguna ketika file terhapus. Backup juga penting jika website disusupi, database rusak, pembaruan gagal, atau server harus dibangun ulang.

Simpan salinan backup di lokasi yang berbeda dari VPS utama. Jika seluruh backup berada pada server yang sama, penyerang yang berhasil menguasai server mungkin dapat menghapus atau mengenkripsi salinan tersebut.

Strategi backup yang baik meliputi:

Backup file website dan konfigurasi yang diperlukan.
Backup database menggunakan metode yang sesuai dengan jenis database.
Simpan salinan di penyimpanan terpisah.
Batasi hak akses terhadap file backup.
Gunakan enkripsi untuk data sensitif saat diperlukan.
Lakukan uji pemulihan secara berkala.

Jangan hanya memeriksa apakah proses backup selesai. Coba pulihkan backup ke lingkungan pengujian untuk memastikan file dan database benar-benar dapat digunakan.

Backup yang dibuat setelah server terinfeksi juga mungkin sudah mengandung file berbahaya. Karena itu, pertahankan beberapa versi backup dan tentukan titik pemulihan berdasarkan waktu sebelum kompromi terjadi.

12. Kelola Hak Akses Pengguna dan Kredensial

Selain akun root, VPS biasanya memiliki akun administrator, akun aplikasi, akun deployment, dan akun layanan. Setiap akun sebaiknya memiliki hak akses sesuai tanggung jawabnya.

Jangan membagikan satu akun administrator kepada semua orang jika akses terpisah dapat diterapkan. Akun individual mempermudah penelusuran aktivitas dan pencabutan akses ketika seseorang tidak lagi membutuhkan akses ke server.

Periksa akun pengguna yang tersedia:

getent passwd

Untuk melihat pengguna yang memiliki UID nol, yang biasanya menandakan hak istimewa setara root, jalankan:

awk -F: '$3 == 0 {print $1}' /etc/passwd

Hasilnya perlu ditinjau karena akun root tambahan dengan UID nol tidak seharusnya muncul tanpa alasan yang jelas.

Gunakan sudo untuk tugas administratif dan hindari memberikan izin luas seperti NOPASSWD: ALL kepada akun yang tidak benar-benar memerlukannya.

Jika pernah ada indikasi kredensial bocor, lakukan rotasi pada kredensial yang terdampak, termasuk kata sandi panel, kunci SSH, token API, kredensial database, serta secret aplikasi. Periksa pula apakah ada sesi aktif atau kunci publik yang tidak dikenal.

13. Pantau Log dan Siapkan Prosedur Penanganan Insiden

Keamanan server tidak berhenti setelah firewall diaktifkan. Tanpa pemantauan, administrator bisa terlambat mengetahui adanya perubahan konfigurasi atau aktivitas mencurigakan.

Periksa log sesuai layanan yang digunakan. Untuk Nginx, misalnya, log akses dan error umumnya dapat ditemukan di bawah /var/log/nginx/. Untuk Apache, lokasi log bergantung pada distribusi dan konfigurasi instalasi.

Log akses membantu melihat pola permintaan, alamat sumber, kode status HTTP, dan endpoint yang sering dipanggil. Lonjakan permintaan ke satu URL bisa berasal dari bot, pengguna sah, atau aktivitas yang mencurigakan. Jangan memblokir alamat IP hanya berdasarkan satu permintaan tanpa melihat konteksnya.

Buat prosedur sederhana jika server menunjukkan tanda serangan:

Catat waktu mulai, gejala, serta perubahan terakhir pada server.
Periksa penggunaan CPU, RAM, koneksi, dan bandwidth.
Tentukan apakah masalah terjadi pada satu aplikasi atau seluruh jaringan.
Simpan log dan informasi yang diperlukan untuk investigasi.
Terapkan pembatasan trafik atau isolasi sesuai kondisi.
Hubungi penyedia VPS apabila serangan melibatkan kapasitas jaringan.
Pulihkan layanan dari sumber yang diketahui bersih jika terjadi kompromi.

Untuk server produksi, tentukan siapa yang bertanggung jawab menerima pemberitahuan dan siapa yang berwenang melakukan isolasi atau pemulihan. Prosedur yang jelas dapat mengurangi kesalahan saat terjadi insiden.

14. Checklist Pengamanan VPS yang Bisa Dilakukan Secara Berkala

Agar langkah pengamanan tidak hanya dilakukan saat pertama kali menyewa VPS, buat jadwal pemeriksaan rutin. Tidak semua pemeriksaan harus dilakukan setiap hari, tetapi hal-hal penting seperti kondisi layanan dan penggunaan sumber daya perlu dipantau secara berkala.

Checklist keamanan server

Pemeriksaan harian
[ ] Periksa penggunaan CPU, RAM, disk, dan bandwidth.
[ ] Periksa notifikasi keamanan serta log yang menunjukkan aktivitas tidak biasa.
[ ] Pastikan website dan layanan penting tetap berjalan.

Pemeriksaan mingguan
[ ] Periksa pembaruan keamanan sistem dan aplikasi.
[ ] Tinjau port yang terbuka dan aturan firewall.
[ ] Periksa akun pengguna, SSH key, dan tugas terjadwal yang tidak dikenal.

Pemeriksaan bulanan
[ ] Evaluasi layanan yang tidak lagi diperlukan.
[ ] Uji pemulihan backup.
[ ] Tinjau hak akses, kredensial, serta prosedur penanganan insiden.

Pemeriksaan harianPeriksa penggunaan CPU, RAM, disk, dan bandwidth.Periksa notifikasi keamanan serta log yang menunjukkan aktivitas tidak biasa.Pastikan website dan layanan penting tetap berjalan.

Pemeriksaan mingguanPeriksa pembaruan keamanan sistem dan aplikasi.Tinjau port yang terbuka dan aturan firewall.Periksa akun pengguna, SSH key, dan tugas terjadwal yang tidak dikenal.

Pemeriksaan bulananEvaluasi layanan yang tidak lagi diperlukan.Uji pemulihan backup.Tinjau hak akses, kredensial, serta prosedur penanganan insiden.

Salin checklist

Checklist ini dapat disesuaikan dengan kebutuhan server. VPS yang menjalankan mail server, layanan DNS, container, atau aplikasi dengan trafik tinggi mungkin membutuhkan pemeriksaan tambahan.

15. Kesalahan yang Sebaiknya Dihindari Saat Mengamankan VPS

Ada beberapa tindakan yang terlihat praktis, tetapi justru bisa menimbulkan masalah keamanan atau membuat server sulit dikelola.

Mengandalkan port SSH yang tidak standar. Mengganti port SSH mungkin mengurangi sebagian pemindaian otomatis, tetapi tidak mencegah penyerang yang mengetahui port tersebut. Tetap gunakan autentikasi yang kuat dan pembatasan akses.

Menganggap firewall sebagai perlindungan menyeluruh. Firewall tidak dapat memperbaiki celah aplikasi yang sudah berjalan pada port yang memang diizinkan. Aplikasi, dependensi, dan hak akses tetap harus diamankan.

Menutup semua port tanpa memahami fungsinya. Tindakan ini bisa membuat website, DNS, email, VPN, atau panel administrasi berhenti berfungsi. Identifikasi layanan terlebih dahulu dan pastikan jalur administrasi tetap tersedia.

Memasang terlalu banyak alat keamanan tanpa pemantauan. Banyaknya perangkat keamanan tidak otomatis membuat server lebih aman. Konfigurasi yang tumpang tindih dapat menyebabkan pemblokiran pengguna sah atau membuat log sulit dianalisis.

Menghapus malware tanpa mencari sumbernya. Jika celah awal masih terbuka, server bisa kembali terinfeksi. Penanganan yang benar mencakup pencarian penyebab, pencabutan akses yang bocor, perbaikan kerentanan, dan verifikasi integritas sistem.

Menganggap DDoS selalu bisa dihentikan dari dalam VPS. Serangan yang memenuhi kapasitas jaringan memerlukan penanganan pada tingkat jaringan atau penyedia layanan. Firewall lokal tetap berguna, tetapi memiliki batas kemampuan.

Kesimpulan

Cara mengamankan VPS agar tidak terkena malware dan tidak menjadi sasaran empuk serangan dari luar membutuhkan kombinasi konfigurasi yang benar, pembaruan rutin, pembatasan akses, serta pemantauan berkelanjutan.

Mulailah dengan memperbarui sistem operasi, menggunakan SSH key, menonaktifkan login root langsung jika sudah tersedia akses administrator alternatif, dan menerapkan firewall yang sesuai. Setelah itu, periksa port yang terbuka, amankan database, perbarui aplikasi, dan batasi hak akses setiap layanan.

Untuk mengurangi dampak DDoS, gunakan pembatasan permintaan pada endpoint yang sesuai, optimalkan caching, pantau kapasitas jaringan, serta pahami kapan bantuan penyedia VPS dibutuhkan. Jangan lupakan backup terpisah dan prosedur pemulihan apabila server benar-benar terkompromi.

Tidak ada server yang dapat dijamin sepenuhnya bebas dari serangan. Namun, konfigurasi yang disiplin dapat memperkecil kemungkinan penyusupan, mengurangi dampak gangguan, dan membantu administrator memulihkan layanan dengan lebih cepat.

Hal terpenting bukan sekadar membuat VPS terlihat aman, melainkan memastikan setiap layanan yang berjalan memiliki alasan yang jelas untuk dapat diakses, setiap akun memiliki hak akses yang sesuai, dan setiap perubahan mencurigakan dapat diketahui sebelum berkembang menjadi masalah yang lebih besar.

Cara Mengamankan VPS agar Tidak Terkena Malware dan Tidak Mengundang DDoS