Proxmox VE Aman dari Luar, tapi VM Digunakan untuk Menyerang Hypervisor

Ada satu perasaan bangga dan tenang tersendiri saat melihat dashboard Proxmox Virtual Environment (PVE) dengan indikator status hijau semua. Cluster sehat, sinkronisasi storage Ceph lancar, backup mingguan berjalan tanpa error, dan yang paling penting: akses dari internet ke port manajemen 8006 sudah ditutup total dengan firewall hardware di depannya.

Di artikel ini, kita membahas serangan Proxmox VM secara praktis agar kamu paham konteks dan penerapannya.

Sebagai admin, saya pikir benteng pertahanan itu sudah tak tertembus. Logika saya sederhana: “Siapa yang bisa masuk dan mengacak-acak konfigurasi cluster kalau semua port manajemen ditutup rapat dari akses publik?”

Namun, kenyataan di lapangan seringkali menampar kita dengan keras. Pagi itu, log keamanan cluster menunjukkan anomali yang membuat bulu kuduk berdiri, ada ribuan percobaan login gagal (failed login attempts) ke user root@pam.

Pertanyaannya: Dari mana asalnya?

Saya segera mengecek source IP penyerang tersebut. Ternyata itu bukan IP dari China, Rusia, atau negara antah-berantah lainnya. Itu adalah IP lokal subnet 192.168.x.x. Jantung saya berdegup kencang saat menyadari fakta mengerikan, IP tersebut adalah milik salah satu Virtual Machine (VM) klien yang sedang berjalan di dalam node Proxmox itu sendiri.

Saya baru sadar bahwa saya telah melakukan kesalahan fatal yang sering dilakukan oleh admin pemula maupun senior yang sedang lengah, menganggap jaringan internal (LAN) adalah zona aman yang bebas ancaman.

Saya lupa bahwa ancaman terbesar bagi Hypervisor seringkali bukan hacker jenius yang membobol firewall perimeter dari seberang samudra, tapi dari “tetangga satu kamar”, sebuah VM yang sudah dikuasai orang jahat.

Ilusi keamanan internal

Mari kita bedah skenarionya. Skenario serangan ini sangat sederhana, tidak butuh tools canggih, tapi dampaknya mematikan.

1. Entry Point: Sebuah VM yang menjalankan web server (misalnya Ubuntu Server dengan WordPress) diretas. Penyebabnya klasik, plugin usang, password user admin yang lemah, atau upload filter yang buruk. Hacker berhasil masuk dan mendapatkan akses shell di VM tersebut.
2. Reconnaissance (Pengintaian): Dari dalam VM yang sudah dikuasai itu, hacker melakukan network scanning sederhana menggunakan nmap atau bahkan ping sweep ke subnet lokalnya.
3. Discovery: Hacker menemukan IP gateway atau IP host Proxmox yang berada di satu subnet network bridge (vmbr0) yang sama.
4. Attack: Karena konfigurasi default instalasi Proxmox seringkali membiarkan port manajemen 8006 terbuka untuk semua interface di bridge vmbr0, hacker bisa melihat halaman login Proxmox kita dari dalam VM.

Dari titik ini, tinggal masalah waktu. Mereka bisa menjalankan brute force password root Proxmox tanpa terhalang firewall luar (karena serangannya dari “dalam”), atau mengeksploitasi celah keamanan PVE yang belum dipatch.

Kalau mereka berhasil tembus ke level Hypervisor, Game Over. Mereka bisa menghapus semua VM, mencuri backup, memformat storage, atau menanam ransomware di level host yang akan mengunci seluruh infrastruktur perusahaan.

Ini mengingatkan saya pada prinsip dasar pertahanan yang saya tulis di Best Practice Server Hardening Linux: jangan pernah percaya default setting, bahkan di jaringan internal sekalipun.

Mengisolasi “anak nakal” dengan vlan

Kejadian ini mengajarkan saya pelajaran mahal, kita harus memperlakukan setiap VM seolah-olah dia adalah musuh potensial. Prinsip Zero Trust Architecture bukan cuma jargon marketing vendor keamanan, itu adalah kebutuhan mutlak di era cloud computing.

Setelah insiden tersebut, saya merombak total arsitektur jaringan virtualisasi saya. Berikut adalah langkah praktis yang saya terapkan dan menyelamatkan saya di insiden-insiden berikutnya:

Pisahkan jalur manajemen dan jalur tamu (traffic)

Jangan pernah membiarkan traffic VM pengguna bercampur (satu subnet/satu bridge) dengan interface manajemen Proxmox. Pisahkan secara fisik atau logikal menggunakan VLAN (Virtual LAN).

• VLAN 10 (Management): Khusus untuk IP Host Proxmox, iDRAC/IPMI. Hanya bisa diakses dari laptop Admin atau VPN khusus.
• VLAN 20 (VM Public): Khusus untuk traffic internet VM.
• VLAN 30 (VM Private/DB): Khusus untuk komunikasi antar database backend.

Dengan pemisahan ini, meskipun sebuah VM di VLAN 20 diretas, hacker di dalamnya tidak akan bisa ping atau melihat IP manajemen Proxmox yang ada di VLAN 10. Jalurnya sudah diputus di level switch atau router.

Kasus serangan jaringan internal seperti ini mirip polanya dengan serangan DDoS yang pernah saya bahas di Studi Kasus DDoS Mikrotik, di mana pemisahan traffic menjadi kunci mitigasi.

Aktifkan firewall di level datacenter/node

Proxmox VE memiliki fitur firewall bawaan (pve-firewall) yang luar biasa powerful dan terintegrasi langsung di kernel Linux. Sayangnya, fitur ini sering dimatikan atau tidak disentuh oleh admin karena “takut salah setting” yang bisa menyebabkan lockout (admin terkunci dari server sendiri).

Jangan takut. Nyalakan firewallnya! Strategi paling aman adalah membuat aturan “Whitelist” di level Datacenter atau Node.

Contoh logika firewall Proxmox yang aman:

1. Drop by Default: Set Input Policy ke DROP.
2. Allow Management IP: Izinkan port 8006 (GUI) dan 22 (SSH) HANYA dari source IP statis laptop admin atau IP VPN kantor.
3. Drop Internal: Pastikan aturan DROP menangkap traffic dari subnet VM.

# Ilustrasi logika rule (bukan command paste):
IN ACCEPT -p tcp --dport 8006 -s 192.168.10.5 (Laptop Admin)
IN ACCEPT -p tcp --dport 22 -s 192.168.10.5
IN DROP -p tcp --dport 8006 -s 0.0.0.0/0 (Tolak semua sisanya)

Dengan aturan ini, meskipun hacker di dalam VM bisa “melihat” IP Host Proxmox, paket request mereka ke port 8006 akan langsung dibuang oleh firewall kernel host.

Tips Penting: Sebelum menerapkan aturan DROP pada port manajemen, pastikan kamu punya akses fisik (monitor+keyboard) atau akses IPMI ke server. Jaga-jaga kalau kamu tidak sengaja memblokir dirimu sendiri.

Jangan pernah percaya “localhost”

Keamanan itu berlapis (Defense in Depth). Mengamankan Proxmox dari akses internet publik itu baru langkah 1. Mengamankannya dari serangan “tusuk dari belakang” oleh VMnya sendiri itu langkah 2 yang sering kali dilupakan karena rasa percaya yang berlebihan pada jaringan internal.

Kasus ini mengubah mindset saya menjadi lebih paranoid dalam artian yang positif. VM klien bisa saja disusupi kapan saja. Bug aplikasi bisa muncul kapan saja. Tugas saya sebagai sysadmin bukan memastikan sistem 100% tidak pernah bobol (karena itu mustahil), tapi memastikan bahwa kalaupun satu kamar hotel terbakar, apinya tidak akan membakar satu gedung, dan yang terpenting tidak membakar ruang kontrol utama.

Coba cek konfigurasi firewall Proxmox kamu sekarang. Akses salah satu VM kamu, buka terminal, dan coba ping atau curl https://<IP-DEPAN-PROXMOX>:8006. Kalau statusnya “Reply” atau halaman loginnya muncul di terminal VM tsb? Selamat, kamu punya PR (Pekerjaan Rumah) malam ini sebelum tidur.

---

Butuh Audit Keamanan Virtualisasi?

Jika kamu ragu dengan topologi jaringan cluster Proxmox kamu saat ini, atau butuh bantuan untuk merancang segmentasi VLAN yang aman untuk environment production, kamu bisa mendiskusikannya dengan saya.

Semoga pembahasan serangan Proxmox VM ini membantu kamu mengambil keputusan yang lebih tepat di lapangan.