Enkripsi VPS dengan LUKS

Enkripsi disk penuh menjawab satu pertanyaan dan menjawabnya secara tuntas: apa yang terjadi kalau disk itu berakhir di tangan orang lain saat sedang mati? Di infrastruktur sewaan, ini bukan hal hipotetis. Drive rusak dan dikembalikan ke supplier. Node dipensiunkan dan storage-nya dijual kembali. Volume di-image saat investigasi, atau dibawa keluar gedung dalam sebuah krat.

• Yang dilindungi. Disk yang mati, image offline dari volume Anda, drive yang dikembalikan lewat garansi, node yang dipensiunkan, file snapshot yang disalin. Dalam semua kasus itu, penyerang hanya memegang ciphertext dan header, dan tanpa passphrase, itu adalah akhir ceritanya.
• Yang tidak dilindungi: mesin yang sedang berjalan. Begitu volume-nya terbuka, kuncinya ada di memori kernel dan filesystem-nya polos bagi apa pun yang punya akses root.
• Yang tidak dilindungi: traffic Anda. Byte yang lewat jalur jaringan adalah urusan TLS dan WireGuard. LUKS tidak pernah melihatnya.
• Yang tidak dilindungi: akun root yang sudah dibobol. Penyusup yang sudah masuk membaca file Anda lewat mount yang sama seperti yang Anda pakai. Untuk itulah hardening ada, dan kedua kontrol ini tidak saling menggantikan.

Daftar ini sengaja dibuat pendek. Enkripsi at rest adalah kontrol yang murah dan bernilai tinggi dengan cakupan yang dibatasi secara presisi, dan hampir semua kekecewaan yang dilaporkan orang soal ini berasal dari diam-diam mengharapkannya juga menutup tiga hal lain di atas.

Begitu volume terenkripsi Anda terbuka, kuncinya ada di RAM milik guest — dan di VPS mana pun, RAM itu berada di mesin yang secara fisik dikendalikan oleh operatornya. Hypervisor bisa membaca memori guest. Ini bukan cacat pada LUKS, atau pada KVM, atau pada host ini secara khusus; ini adalah konsekuensi dari menyewa komputer, dan penyedia mana pun yang bilang sebaliknya sedang mendeskripsikan produk yang tidak ada.

Jadi perhitungannya blak-blakan: enkripsi at rest membuat serangan offline jadi mustahil dan membiarkan serangan online persis seperti sebelumnya. Drive yang meninggalkan rak jadi tidak berharga. Server yang sedang berjalan tetap sama terbukanya seperti kemarin. Kedua bagian kalimat itu sama-sama benar sekaligus, dan panduan yang hanya memberi tahu Anda separuh pertama tidak sedang membantu Anda.

Yang benar-benar mengubah keadaan pada bagian kedua itu adalah sekumpulan kontrol yang berbeda, dan itu bertumpuk dengan enkripsi, bukan menggantikannya. Tidak ada apa pun yang tercatat untuk diungkap, karena pendaftaran di sini tanpa KYC — hanya email untuk pengiriman kredensial, tidak lebih. Pembayaran diselesaikan on-chain, bukan lewat bank. Dan yurisdiksi tempat VPS ini berada menentukan perintah macam apa yang bisa memaksa apa pun sama sekali. Uraian jujur kami soal apa yang disembunyikan VPS berbayar kripto membahas sisanya, dan entri Fourteen Eyes membahas sisi berbagi intelijennya. Dibaca sebagai satu lapisan di antara beberapa lapisan, LUKS adalah nilai yang sangat baik. Dibaca sebagai perisai melawan host Anda sendiri, itu adalah kesalahpahaman.

Ada dua bentuk yang bisa diambil di sini, dan pilihannya soal risiko, bukan soal kekuatan.

• Volume data terenkripsi. Sebuah container LUKS di samping sistem operasi. Semua yang penting — database, mail, kunci, upload, backup — ada di dalamnya; OS itu sendiri tetap dalam keadaan polos. Sepuluh menit kerja, tanpa risiko boot sama sekali, dan bisa dibatalkan kapan saja. Inilah yang seharusnya dibangun oleh sebagian besar pembaca, dan inilah yang dilakukan oleh langkah-langkah di bawah.
• Root filesystem terenkripsi. Semuanya ada di dalam, termasuk log, daftar paket, dan riwayat shell yang sudah Anda lupakan. Jelas lebih kuat, dan sungguh-sungguh lebih sulit diterapkan pada mesin yang sudah berjalan.

Alasan di balik kesulitan itu layak disebutkan karena tidak ada satu pun tutorial yang pernah melakukannya: Anda tidak bisa mengenkripsi filesystem yang sedang ter-mount read-write dan sedang melayani sesi SSH Anda. Kedua metode yang benar-benar berfungsi — shrink-and-copy, atau cryptsetup reencrypt di tempat — sama-sama membutuhkan root dalam keadaan offline. Di mesin dengan konsol out-of-band, Anda tinggal boot installer dan itu jadi rutin. Di VPS headless, Anda memindahkan sistem yang sedang berjalan ke RAM disk terlebih dahulu, dan kalau ada bagian mana pun dari proses itu yang salah, VPS-nya tidak akan kembali dan jalan pemulihannya adalah instal ulang, yang menghapus seluruh disk.

Jadi: bangun volume data-nya hari ini, taruh semua yang penting di sana, dan perlakukan root terenkripsi sebagai keputusan yang Anda ambil saat deploy, di mesin yang belum punya apa-apa untuk dikorbankan. Bagian terakhir membahas jalur itu, termasuk dropbear-initramfs untuk mengetik passphrase lewat SSH saat boot.

Tidak banyak, dan itu salah satu alasan kenapa ini layak dilakukan.

• Sebuah paket. Enkripsi tidak menambah kebutuhan RAM dan nyaris tidak menambah beban CPU. Cub (1 vCPU / 2 GB / 40 GB NVMe, $5.00/mo) sudah cukup; Scout (2 vCPU / 4 GB / 70 GB, $9.00/mo) adalah ukuran yang nyaman kalau VPS-nya juga menjalankan layanan sungguhan. Satu-satunya angka yang benar-benar penting adalah disk, karena volume terenkripsi Anda diambil dari situ.
• Debian 12 atau 13 dari template library, atau Ubuntu LTS — perintah-perintah di bawah bergaya Debian dan nama paketnya berbeda di distro lain. Deploy makan waktu sekitar satu menit, dan virtualisasi KVM penuh berarti kernel sungguhan dengan modul dm-crypt yang tersedia, bukan container yang meminjam kernel milik orang lain.
• Sepuluh menit hardening dasar lebih dulu. Enkripsi pada VPS yang masih menerima login lewat password itu seperti gembok di pintu tanpa kusen.
• Passphrase yang belum pernah Anda pakai di tempat lain, dihasilkan secara acak, bukan dikarang sendiri, dan disimpan di suatu tempat yang tetap ada meski Anda kehilangan mesin ini. Tidak ada pemulihan, tidak ada reset, dan tidak ada tiket dukungan yang bisa membantu.
• Suatu tempat di luar VPS untuk menyimpan backup header. Snapshot mingguan sudah termasuk di setiap paket, tapi snapshot dari volume terenkripsi tetap saja terenkripsi — berguna untuk rollback, tidak berguna kalau passphrase-nya sudah hilang.

Lokasi tidak berpengaruh pada semua ini, jadi pilih berdasarkan harga atau yurisdiksi: Amsterdam, Paris, Bucharest, dan Sofia berada di harga dasar, sementara Zurich, Reykjavik, Stockholm, dan Kuala Lumpur punya pengali harga.

LUKS2 menyimpan sampai 32 keyslot. Masing-masing menampung salinan dari master key yang sama, dibungkus dengan passphrase yang berbeda-beda, itulah sebabnya Anda bisa menambahkan passphrase kedua tanpa perlu meng-enkripsi ulang apa pun:

cryptsetup luksAddKey /dev/disk/by-partlabel/secure
cryptsetup luksDump /dev/disk/by-partlabel/secure | grep -A2 '^Keyslots'
cryptsetup luksKillSlot /dev/disk/by-partlabel/secure 1

Dua passphrase sejak awal adalah default yang tepat: satu yang Anda pakai sehari-hari, satu lagi ditulis dan disimpan di tempat lain. Kehilangan satu-satunya akses ke sebuah volume gara-gara salah ketik di password manager adalah cara paling umum orang kehilangan data LUKS-nya, jauh mengalahkan apa pun yang dilakukan penyerang.

Sekarang jebakannya. Backup header yang diambil sebelum Anda merotasi passphrase tetap bisa membuka volume dengan passphrase yang lama. Keyslot berada di dalam header, jadi salinan lama dari header adalah salinan lama dari keyslot — master key di baliknya tidak pernah berubah. Kalau Anda merotasi passphrase karena kemungkinan bocor, Anda harus menghancurkan setiap backup header yang diambil sebelum rotasi itu dan mengambil yang baru. Kalau tidak, rotasi itu tidak mencapai apa-apa selain membuat Anda merasa lebih tenang.

Fakta yang sama membuat backup header sensitif dengan sendirinya: file 16 MB itu, ditambah passphrase apa pun yang pernah dikenalnya, sudah cukup untuk mendekripsi volume-nya. Simpan itu di tempat yang sama seperti Anda menyimpan passphrase, bukan di tempat Anda menyimpan snapshot.

cryptsetup benchmark memberi tahu Anda kebenarannya untuk vCPU spesifik Anda dalam kira-kira lima belas detik. Di CPU mana pun dengan AES-NI — yang berarti prosesor server x86-64 mana pun dari dekade terakhir — harapkan angka beberapa gigabyte per detik untuk aes-xts, jauh lebih cepat daripada NVMe di bawahnya. Overhead praktis pada beban kerja sungguhan hanya beberapa persen kecil, dan itu adalah beban CPU, bukan latency.

Dua opsi cryptsetup yang penting di storage cepat, dan hanya di storage cepat:

cryptsetup --perf-no_read_workqueue --perf-no_write_workqueue \
  --allow-discards open /dev/disk/by-partlabel/secure secure

Flag workqueue ini melewati antrean internal dm-crypt dan menyerahkan I/O langsung ke device-nya. Di disk berputar, keduanya tidak mengubah apa-apa; di NVMe RAID10, keduanya menghilangkan bottleneck nyata pada queue depth yang tinggi. Tambahkan ke baris opsi crypttab sebagai no-read-workqueue,no-write-workqueue supaya permanen.

--allow-discards adalah yang punya trade-off. Opsi ini meneruskan TRIM ke NVMe, yang menjaga performa tulis tetap baik seiring waktu — dan sekaligus membocorkan kepada siapa pun yang memegang disk yang mati, block mana yang sedang dipakai dan mana yang kosong. Itu kebocoran informasi yang nyata, meski kecil: ini membeberkan kira-kira seberapa penuh volume-nya dan bisa memberi petunjuk soal struktur filesystem-nya. Di server serba guna, ambil saja performanya. Kalau isi volume Anda termasuk hal yang ukurannya sensitif, matikan discard.

Kalau Anda ingin semuanya terenkripsi, lakukan di mesin yang belum punya apa-apa di dalamnya — deploy, konversi, baru bangun. Konversinya sendiri standar: kecilkan root filesystem saat sedang offline, buat container LUKS2 di ruang yang dibebaskan, salin sistemnya dengan rsync -aHAX, arahkan /etc/fstab dan /etc/crypttab ke mapper device-nya, lalu update-initramfs -u -k all dan instal ulang GRUB. Bagian yang membuat ini jadi masalah khusus VPS headless ada pada kata saat sedang offline: mencapai kondisi itu tanpa konsol berarti memindahkan sistem yang sedang berjalan ke RAM root terlebih dahulu, dan itulah langkah yang berakhir dengan instal ulang kalau ada yang salah.

Yang membuat root terenkripsi bisa dipakai sama sekali di mesin remote adalah dropbear-initramfs — SSH server berukuran kira-kira 200 KB yang dipanggang ke dalam boot image, mendengarkan selagi kernel menunggu passphrase-nya:

apt install dropbear-initramfs cryptsetup-initramfs

# Debian 12/13: /etc/dropbear/initramfs/
cp ~/.ssh/unlock_key.pub /etc/dropbear/initramfs/authorized_keys
chmod 600 /etc/dropbear/initramfs/authorized_keys

echo 'DROPBEAR_OPTIONS="-I 300 -j -k -p 2222 -s -c cryptroot-unlock"' \
  >> /etc/dropbear/initramfs/dropbear.conf

echo 'IP=:::::eth0:dhcp' >> /etc/initramfs-tools/initramfs.conf
update-initramfs -u -k all

Anda kemudian ssh -p 2222 root@your-ip saat boot dan perintah cryptroot-unlock yang dipaksa akan meminta passphrase-nya. Ada tiga hal soal ini yang layak diketahui sebelum Anda mengandalkannya. Initramfs punya host key sendiri, jadi klien Anda akan memperingatkan soal ketidakcocokan di port 2222 — itu memang wajar terjadi, dan itulah alasan memberinya port khusus. Host key itu dan authorized_keys Anda berada di partisi boot yang tidak terenkripsi, bisa dibaca oleh siapa pun yang memegang disknya, jadi gunakan unlock key yang tidak dipakai untuk hal lain apa pun. Dan -s menonaktifkan login password di initramfs, dan itu bukan pilihan opsional.

Detail lain yang menggigit di paket kecil adalah yang dari langkah tiga, dan di sinilah gigitannya paling keras. Initramfs berjalan sebelum sebagian besar RAM Anda tersedia untuk hal yang nyaman, jadi header yang diformat dengan biaya memori Argon2id yang besar bisa gagal terbuka justru di mesin yang membuatnya. Format dengan --pbkdf-memory yang dibatasi, dan uji reboot-nya selagi Anda belum kehilangan apa-apa.

Nyaris tidak ada, dan itulah intinya. Volume LUKS yang terbuka adalah block device biasa; fsck, rsync, df, dan tool backup Anda semuanya berperilaku persis seperti sebelumnya. Upgrade kernel tidak terdampak karena dm-crypt sudah in-tree. Memperbesar volume setelah upgrade paket hanya dua perintah — cryptsetup resize lalu resize filesystem-nya sendiri — dan tidak butuh enkripsi ulang.

Ada tiga kebiasaan yang layak dibangun. Latih reboot-nya secara terjadwal, alih-alih baru sadar jam 3 pagi bahwa passphrase yang tidak pernah Anda tulis adalah satu-satunya salinan. Jaga agar backup tetap terenkripsi secara independen — restic atau borg ke target off-site, yang merupakan kontrol terpisah dari volume-nya dan tetap bertahan meski VPS-nya hilang sepenuhnya; add-on backup off-site harian tersedia seharga $2.00/mo kalau Anda tidak mau membangunnya sendiri. Dan tutup volume-nya sebelum Anda berhenti peduli pada VPS itu: cryptsetup close secure sebelum shutdown terencana, migrasi, atau instal ulang berarti kuncinya sudah keluar dari memori sebelum disknya berhenti menjadi milik Anda.

Soal kebijakan, tidak ada yang perlu dinegosiasikan. Anda mendapat full root di guest KVM dan apa yang Anda lakukan dengan block layer adalah urusan Anda sendiri; mengenkripsi volume Anda sendiri adalah administrasi sistem biasa, bukan kasus khusus. Acceptable use policy kami mengatur soal perilaku — batas mutlaknya adalah tidak boleh CSAM dan tidak boleh terorisme — dan tidak bicara apa-apa soal dm-crypt. Yang benar-benar diubah oleh enkripsi adalah bentuk dari hari buruk yang hipotetis: volume yang mati dan meninggalkan gedung ini hanyalah derau, dan itu sepadan dengan sepuluh menit waktu Anda.