VPS Diretas: Langkah Aman yang Harus Dilakukan

Jangan membersihkan VPS yang diretas

Jika VPS Anda diretas, keputusan yang paling penting diambil sebelum Anda menjalankan perintah apa pun. Jangan mencoba membersihkan mesin tersebut. Isolasi VPS pada penyedia layanan, buat snapshot disk sebagai bukti, rotasi setiap kredensial yang pernah tersimpan di dalamnya, lalu bangun ulang pada server baru dari sumber yang Anda percayai.

Anda tidak dapat membuktikan bahwa rootkit telah hilang, karena alat yang dapat membuktikannya dikendalikan oleh penyerang.

Itulah inti argumennya. Berikut mekanismenya. Penyerang yang berhasil memperoleh akses root dapat mengganti ps sehingga satu ID proses tidak pernah muncul dalam outputnya. Satu baris dalam /etc/ld.so.preload dapat memuat kode penyerang ke setiap program yang terhubung secara dinamis pada mesin tersebut. Akibatnya, ls, ss, dan find semuanya memberikan hasil yang salah dengan cara yang konsisten. Modul kernel yang dapat dimuat dapat menyembunyikan file di bawah lapisan system call. Karena itu, bahkan binary yang baru diunduh pun dapat melihat disk yang tampak bersih. Anda menghapus miner, grafik penggunaan CPU turun, dan server menjadi tidak aktif. Kondisi tidak aktif juga merupakan ciri backdoor yang berfungsi.

Membangun ulang biasanya membutuhkan biaya dan usaha yang lebih kecil daripada yang terasa. VPS pada umumnya hanya terdiri atas sejumlah package, satu direktori konfigurasi, dan satu set data. Karena itu, pembangunan ulang merupakan pekerjaan terbatas yang memiliki titik akhir. Sebaliknya, mencari setiap perubahan yang dibuat penyerang tidak memiliki batas yang jelas dan tidak pernah menghasilkan bukti yang meyakinkan.

Pastikan bahwa server benar-benar telah dibobol

Banyak server yang dilaporkan diretas sebenarnya tidak. Ribuan upaya login SSH yang gagal setiap hari merupakan kebisingan latar belakang Internet, karena setiap alamat IPv4 publik dipindai secara terus-menerus. Output lastb yang penuh dengan percobaan root dan admin berarti pemindai menemukan port Anda. Itu tidak berarti seseorang berhasil masuk.

Sinyal berikut memang menunjukkan sesuatu:

• Login berhasil yang tidak dapat Anda jelaskan, seperti Accepted password for root from 203.0.113.7.
• Key di authorized_keys yang tidak Anda tambahkan.
• Pemberitahuan penyalahgunaan dari host Anda tentang trafik yang keluar dari server.
• Proses dengan penggunaan CPU 100% yang menggunakan nama yang disalin dari kernel thread. Miner yang masuk melalui Redis dan Docker socket yang terekspos sering dilaporkan menggunakan nama seperti kdevtmpfsi dan kinsing.
• Koneksi keluar ke alamat yang tidak digunakan oleh service Anda.

Penyamaran sebagai kernel thread dapat diuji dengan cepat. Kernel thread yang sebenarnya ditampilkan di dalam tanda kurung siku dan tidak memiliki executable di belakangnya, sehingga sudo ls -l /proc/<pid>/exe gagal untuk proses tersebut dengan No such file or directory. Jika proses yang ditampilkan sebagai [kworker/0:2] memiliki link exe yang mengarah ke sesuatu di bawah /tmp, proses itu adalah program pengguna biasa yang menggunakan nama kernel.

Jalankan pemeriksaan ini dengan menyadari bahwa server mungkin menipu Anda. Pemeriksaan ini cukup untuk menyimpulkan bahwa ada sesuatu yang salah. Pemeriksaan ini tidak cukup untuk menyimpulkan bahwa tidak ada masalah.

Putuskan jaringan di penyedia, bukan dari dalam server

Isolasi harus dilakukan terlebih dahulu karena semua langkah setelahnya sia-sia selama pihak lain masih memiliki shell. Membaca log, merotasi key, dan memulihkan data tidak berguna jika penyerang masih aktif dan memantaunya.

Lakukan ini dari control panel penyedia, menggunakan network firewall yang berjalan di luar sistem operasi Anda. Tolak koneksi masuk dan keluar, lalu pertahankan web console sebagai akses masuk Anda. Aturan yang diterapkan di sana tetap berlaku terlepas dari apa pun yang terjadi pada disk.

Ada dua alasan untuk tidak melakukan ini dari dalam server. Firewall yang Anda konfigurasi di dalam kernel yang telah disusupi diterapkan oleh kernel tersebut, dan root dapat mengosongkan nftables semudah Anda mengisinya. Selain itu, sudo ip link set enp1s0 down melalui SSH akan memutus sesi Anda sendiri terlebih dahulu, sehingga Anda terkunci dari mesin yang sedang Anda periksa.

Blokir koneksi keluar maupun masuk. Reverse shell melakukan koneksi keluar dari server Anda ke penyerang, sehingga pemblokiran koneksi masuk saja tidak mengganggu koneksi yang sudah terbentuk. Jika penyedia Anda hanya menyediakan aturan untuk koneksi masuk, pilihan yang tersisa adalah melepaskan network interface atau mematikan instance.

Jangan reboot dulu. Periksa terlebih dahulu apakah /var/log/journal ada. Jika direktori tersebut tidak ada, journald menulis ke /run/log/journal, yang berada di memori, sehingga reboot akan menghapus catatan intrusi. Proses yang sedang berjalan juga hilang saat reboot, dan command line proses tersebut sering kali menjadi bukti paling jelas yang akan Anda peroleh.

Buat snapshot disk sebelum melakukan perubahan apa pun

Snapshot dan backup memiliki fungsi yang berbeda di sini. Snapshot yang Anda buat sekarang adalah salinan disk yang telah disusupi. Snapshot tersebut merupakan bukti dan satu-satunya cara untuk kembali ke kondisi sebelumnya jika Anda tidak sengaja menimpa sesuatu. Backup lama adalah jalur pemulihan Anda. Jika panel provider Anda menggunakan kedua istilah tersebut secara longgar, baca perbedaan snapshot VPS dari backup sebenarnya terlebih dahulu, karena aturan retensi dan perilaku pemulihannya tidak sama.

Buat snapshot dari panel provider sebelum login kembali. Snapshot aktif bersifat konsisten terhadap crash: snapshot menangkap kondisi disk pada saat itu, sama seperti ketika daya listrik langsung diputus. Hal tersebut memadai untuk keperluan bukti. Beri nama snapshot dengan jelas agar tidak ada yang tidak sengaja memulihkannya. Nama yang lugas seperti COMPROMISED-do-not-restore-2026-08-12 memiliki tingkat kejelasan yang tepat. Simpan snapshot tersebut sampai investigasi selesai dan tiket penyalahgunaan dengan host Anda ditutup.

Cara mengakses server ketika SSH tidak berfungsi

Ada dua cara, dan keduanya tersedia di panel provider. Konsol web (VNC atau serial) terhubung ke mesin seolah-olah Anda memasang keyboard secara langsung. Cara ini tetap berfungsi ketika sshd berhenti, konfigurasi firewall salah, atau penyerang mengubah port SSH. Konsol melakukan autentikasi dengan kata sandi lokal. Karena itu, server yang hanya mengizinkan autentikasi dengan key mungkin memerlukan reset kata sandi root sebelum konsol dapat digunakan.

Rescue mode adalah pilihan yang lebih baik. Mode ini mem-boot sistem live berukuran kecil dengan disk Anda terpasang tetapi tidak sedang digunakan untuk menjalankan sistem. Dengan demikian, perintah yang Anda jalankan dapat dipercaya: kernel yang telah disusupi dan binary yang telah disusupi tidak sedang dieksekusi. Pasang disk dalam mode hanya baca.

lsblk -f
sudo mkdir -p /mnt/victim
sudo mount -o ro /dev/vda1 /mnt/victim

Jika lsblk menampilkan volume LVM (logical volume manager), bukan partisi biasa, aktifkan volume tersebut terlebih dahulu dengan sudo vgchange -ay, lalu mount device yang muncul di bawah /dev/mapper/.

Jangan menjalankan chroot pada disk yang telah di-mount hanya untuk memeriksanya. chroot akan mengeksekusi binary milik penyerang dengan izin Anda. Tindakan ini menghilangkan seluruh alasan Anda melakukan boot ke rescue mode.

Kumpulkan bukti yang masih dapat dipercaya

Jalankan perintah berikut dari rescue mode, dengan disk terpasang sebagai read-only pada /mnt/victim. Mulailah dari login karena log tersebut menunjukkan waktu intrusi. Setelah rentang waktu diketahui, pemeriksaan lain menjadi lebih mudah.

sudo grep -aE 'Accepted (password|publickey)' /mnt/victim/var/log/auth.log
sudo last -f /mnt/victim/var/log/wtmp
sudo lastb -f /mnt/victim/var/log/btmp
sudo journalctl -D /mnt/victim/var/log/journal -u ssh --since "2026-07-01"

/var/log/auth.log yang tidak ada tidak dengan sendirinya mencurigakan. Beberapa image Ubuntu saat ini dikirim tanpa rsyslog, sehingga sshd hanya mencatat ke journal. Inilah yang dibaca oleh baris journalctl -D. Hal yang perlu dicatat adalah jeda pada log yang sebelumnya berkelanjutan atau file log yang terpotong menjadi 0 byte. Penghapusan log sering terjadi dan biasanya dilakukan secara ceroboh.

Berikutnya, periksa akun dan key.

sudo find /mnt/victim/root /mnt/victim/home -name 'authorized_keys*' -exec ls -l {} +
sudo awk -F: '$3 == 0 {print $1}' /mnt/victim/etc/passwd
sudo lsattr /mnt/victim/root/.ssh/authorized_keys

Baris awk mencetak semua akun dengan user ID 0. Selain root dalam output tersebut berarti ada akun root kedua. Pola find sengaja mencocokkan authorized_keys2 juga karena OpenSSH membaca kedua nama file tersebut secara default, dan file kedua mudah terlewatkan. Jika lsattr mencetak i dalam daftar atribut, file tersebut bersifat immutable. Penyerang menetapkan flag itu agar upaya Anda menghapus key mereka gagal dengan Operation not permitted, lalu admin yang lelah mengira perubahan telah berhasil.

Persistence tersembunyi di beberapa lokasi, jadi periksa semuanya.

sudo ls -lt /mnt/victim/etc/systemd/system
sudo ls -l /mnt/victim/etc/cron.d /mnt/victim/var/spool/cron/crontabs
sudo cat /mnt/victim/etc/ld.so.preload
sudo grep -rnE 'curl|wget|base64|/dev/tcp' /mnt/victim/etc/update-motd.d /mnt/victim/etc/rc.local /mnt/victim/root/.bashrc /mnt/victim/root/.profile

/etc/ld.so.preload tidak ada pada sistem Ubuntu atau Debian normal. Karena itu, No such file or directory adalah hasil yang sehat, sedangkan konten apa pun patut diperhatikan. File login yang meneruskan output base64 -d ke shell menunjukkan pola yang sama. Konfigurasi yang sah tidak perlu menyembunyikan teksnya sendiri.

Susun timeline berdasarkan change time, bukan modification time.

sudo find /mnt/victim -xdev -newerct '2026-08-01' -type f -printf '%TF %TT %p\n' | sort

touch dapat menetapkan modification time ke nilai apa pun yang diinginkan penyerang, sehingga mtime dapat dipalsukan dengan mudah. Change time (ctime) diperbarui setiap kali ada perubahan pada inode. touch tidak dapat memundurkannya, sehingga -newerct memberikan daftar yang lebih akurat tentang hal-hal yang baru saja ditulis. Ini tetap bukan bukti pasti karena root dapat mengubah waktu sistem atau menulis langsung ke block device.

Integritas paket layak diperiksa dengan satu perintah dan satu catatan penting. Pada sistem yang sedang berjalan, sudo dpkg --verify mencetak satu baris untuk setiap file paket yang checksum-nya tidak lagi cocok, dengan 5 pada kolom checksum. sudo debsums -ac melakukan pemeriksaan yang sama, termasuk file konfigurasi, jika paket debsums terpasang. Baca hasilnya hanya dalam satu arah. /usr/sbin/sshd yang berubah merupakan bukti nyata. Laporan yang bersih tidak membuktikan apa pun karena akun root yang sama yang mengganti binary dapat menulis ulang daftar checksum di bawah /var/lib/dpkg/info/. Pemindai rootkit seperti rkhunter dan chkrootkit mengikuti aturan yang sama: temuan memberikan informasi, sedangkan hasil pemindaian yang bersih bukan berarti sistem dinyatakan aman.

Salin hasil yang telah dikumpulkan keluar dari mesin sebelum melakukan tindakan yang merusak data.

sudo tar --ignore-failed-read -C /mnt/victim -czf /root/evidence-2026-08-12.tgz \
  var/log etc root/.ssh root/.bash_history home
sha256sum /root/evidence-2026-08-12.tgz

Simpan hash tersebut di lokasi di luar server. Jika hal ini kemudian menjadi klaim asuransi atau laporan polisi, kemampuan untuk menunjukkan bahwa archive tidak berubah sejak dikumpulkan membedakan bukti dari sekadar folder berisi file. Menghapus sesuatu secara tidak sengaja selama investigasi merupakan hal yang biasa. Snapshot dan archive inilah yang membuat proses tersebut dapat ditangani. Membatalkan rm yang keliru setelahnya jauh lebih sulit daripada yang diperkirakan, seperti dijelaskan dalam memulihkan file yang dihapus dengan rm -rf.

Cari tahu jalur masuknya

Rebuild yang tidak menutup jalur masuk akan membuat server kembali dibobol, sering kali dalam hitungan hari, karena pemindaian yang pertama kali menemukan server tersebut terus berjalan. Empat jalur mencakup sebagian besar pembobolan server tunggal.

Login password SSH. Baris Accepted password for root dari alamat yang tidak Anda kenali sudah cukup menjadi petunjuk. Periksa PasswordAuthentication di /etc/ssh/sshd_config dan di setiap file dalam /etc/ssh/sshd_config.d/. sshd menggunakan nilai pertama yang diperolehnya untuk suatu keyword, dan baris Include berada di bagian atas file utama pada Ubuntu. Karena itu, file konfigurasi tambahan dapat secara diam-diam mengalahkan pengaturan yang Anda edit lebih jauh di bawah.

Service yang dipublikasikan tanpa autentikasi. Redis pada 6379, Docker API pada 2375, atau database yang terikat ke 0.0.0.0, bukan 127.0.0.1. Docker sering menjadi penyebab yang tidak terduga. Memublikasikan port container menambahkan aturan DNAT (destination network address translation) yang dievaluasi sebelum chain ufw. Akibatnya, ufw status dapat melaporkan bahwa suatu port diblokir, sementara container di belakangnya tetap merespons seluruh Internet. Pahami hal ini sebelum melakukan rebuild: mengapa port yang dipublikasikan Docker melewati ufw menjelaskan urutan aturan dan solusinya.

Aplikasi web yang belum ditambal. Cari log akses web server di sekitar timestamp mencurigakan paling awal untuk menemukan POST ke path upload atau path admin, kemudian cari file di bawah web root dengan waktu perubahan yang sesuai. File PHP yang tidak dikenal dalam direktori uploads adalah hasil yang paling umum.

Kredensial yang bocor. Key yang di-commit ke repository, token yang ditempelkan ke chat, atau file .env yang disajikan sebagai file statis oleh web server yang salah konfigurasi. Otomatisasi memudahkan hal ini terjadi tanpa sengaja. Karena itu, simpan secret di luar AI agent dan file konfigurasinya merupakan langkah penting.

Jika Anda tetap tidak dapat menentukan jalur masuknya, anggap kredensial telah bocor dan perlakukan setiap secret yang pernah disimpan mesin tersebut sebagai data publik.

Rotasi setiap kredensial yang dapat diakses mesin

Lakukan rotasi setelah jaringan diputus, bukan sebelumnya. Jika rotasi dilakukan saat penyerang masih memiliki koneksi, Anda hanya menyerahkan rahasia baru kepada mereka.

• Setiap private key SSH yang tersimpan di server, serta setiap akun di tempat lain yang mempercayai public key terkait.
• Setiap key yang Anda teruskan ke mesin dengan ssh -A. Agent forwarding meninggalkan socket di bawah /tmp, dan root pada mesin tersebut dapat menggunakannya untuk melakukan autentikasi sebagai Anda di mana pun key Anda diterima, selama sesi Anda tetap terbuka.
• Token API dalam file .env, pada baris Environment= systemd, dalam konfigurasi CI, dan pada kredensial provider.
• Password database serta akun aplikasi yang menggunakannya.
• Private key TLS (transport layer security) yang disimpan server. Terbitkan ulang sertifikat dan cabut sertifikat lama.
• Password akun hosting Anda, dengan autentikasi dua faktor diaktifkan. Panel tersebut dapat membangun ulang, membuat snapshot, dan membuka console ke setiap server yang Anda miliki, sehingga panel itu merupakan perimeter sebenarnya.
• Setiap password yang diketikkan ke sesi shell pada host tersebut selama host dalam kondisi disusupi, karena root dapat merekam sesi terminal saat berlangsung.

Jika password pada mesin tersebut digunakan di tempat lain, ubah password itu di tempat tersebut juga. Penggunaan ulang kredensial dapat mengubah satu VPS yang disusupi menjadi akun email yang turut disusupi.

Daftar periksa pembangunan ulang

1. Buat server baru dari image distribusi yang masih bersih. Jangan gunakan snapshot dari server yang telah dibobol atau pemulihan seluruh sistem berkas root.
2. Instal paket dari repositori distribusi. Jangan pernah menyalin binary dari disk lama.
3. Pulihkan hanya data dari backup yang dibuat sebelum bukti paling awal dalam linimasa Anda. Pulihkan dump database, upload, dan state aplikasi. Jangan sertakan /etc, /usr, atau unit file lama.
4. Masukkan secret yang telah dirotasi secara manual. Jangan menyalin .env lama.
5. Periksa konten web yang dipulihkan untuk mencari file yang ditambahkan selama periode intrusi sebelum menyajikannya kembali.
6. Perkuat keamanan sebelum mengekspos server: SSH yang hanya menggunakan key, account kerja non-root, firewall inbound dengan kebijakan default-deny, dan tidak ada service yang dipublikasikan lebih luas daripada yang diperlukan. Ikuti sepuluh menit pertama pada VPS baru, lalu perkuat SSH dengan benar, kemudian tambahkan fail2ban pada Ubuntu 24.04 untuk mengurangi gangguan login. Berikan setiap service account dengan hak akses minimum khusus agar foothold berikutnya tidak menjadi foothold root.
7. Matikan server lama, dan simpan snapshot-nya sampai investigasi serta tiket penyalahgunaan ditutup.
8. Perbaiki backup. Jika langkah 3 hanya berdasarkan perkiraan, pelajaran sebenarnya adalah riwayat backup Anda terlalu singkat untuk mencapai titik sebelum intrusi. Backup berversi di luar server dengan retensi panjang akan menyediakan titik pemulihan yang bersih pada kejadian berikutnya: backup restic pada VPS menyediakan keduanya.

Jika Anda tidak dapat menentukan tanggal intrusi, Anda tidak dapat memilih backup yang aman. Dalam situasi tersebut, pulihkan hanya data yang dapat Anda periksa secara langsung: dump SQL yang dapat Anda baca atau direktori image yang dapat Anda daftarkan. Anggap semua yang dapat dieksekusi sebagai sesuatu yang mencurigakan, lalu instal ulang dari repositori.

Makna pemberitahuan penyalahgunaan dari host Anda

Sebagian besar orang mengetahui bahwa server mereka telah dibobol dari penyedia layanan, bukan dari pemantauan mereka sendiri. Penyedia melihat trafik keluar: brute force SSH terhadap jaringan lain, spam pada port 25, atau keterlibatan dalam serangan refleksi. Tiket biasanya mencantumkan timestamp, port, dan sampel aliran trafik, beserta tenggat waktu dalam hitungan jam.

Balas pemberitahuan tersebut, meskipun jawaban Anda hanya menyatakan bahwa server telah diisolasi dan sedang dibangun ulang. Penyedia dapat mengarahkan trafik ke null route atau menangguhkan server jika tiket tidak dijawab. Hal ini mengubah insiden Anda menjadi outage. Selanjutnya, minta baris log mentah yang mendasari laporan tersebut. Timestamp itu dicatat di luar mesin Anda, sehingga merupakan bagian dari linimasa yang tidak dapat diedit oleh penyerang. Timestamp tersebut juga sering membantu menentukan waktu intrusi dengan lebih akurat daripada apa pun yang ada di disk.

Server pelanggan yang telah dibobol merupakan pekerjaan rutin bagi penyedia host, dan penanganan yang baik tidak akan merugikan Anda. Pertanyaan yang lebih luas mengenai keamanan hosting VPS terutama bergantung pada konfigurasi yang dibuat pelanggan. Kini Anda harus mengonfigurasinya kembali dari awal.

Kapan harus menghubungi profesional

• Server menyimpan data pribadi milik orang lain. Berdasarkan GDPR (General Data Protection Regulation), pelanggaran data pribadi harus dilaporkan kepada otoritas pengawas tanpa penundaan yang tidak semestinya, dan dalam waktu 72 jam sejak Anda mengetahuinya jika hal tersebut memungkinkan. Menentukan apakah batas waktu tersebut sudah dimulai merupakan pekerjaan hukum, bukan pekerjaan sysadmin.
• Data kartu pembayaran termasuk dalam cakupan insiden. Jaringan kartu pembayaran mewajibkan penggunaan penyelidik forensik yang disetujui, dan tindakan pemeriksaan oleh Anda sendiri dapat merusak kasus.
• Ada tuntutan pemerasan, atau data Anda telah dienkripsi.
• Mesin tersebut dapat menjangkau mesin lain: jaringan internal, hypervisor, atau CI runner yang menyimpan kredensial produksi. Satu host yang disusupi dalam suatu grup dianggap sebagai insiden yang berdampak pada seluruh grup sampai terbukti sebaliknya.
• Anda memerlukan bukti yang dapat diterima oleh perusahaan asuransi atau penegak hukum. Hentikan aktivitas pada tahap snapshot, buat full disk image, lalu catat siapa yang menanganinya dan kapan.

Untuk satu VPS yang menjalankan layanan Anda sendiri dan tidak menyimpan data milik orang lain, playbook di atas sudah mencakup seluruh pekerjaan. Isolasi VPS pada provider. Buat snapshot untuk bukti. Kumpulkan data yang masih dapat dipercaya. Rotasi semua kredensial dan secret. Bangun ulang sistem dari kondisi bersih.

FAQ

Dapatkah saya membersihkan VPS yang diretas tanpa membangunnya ulang?

Tidak dengan keyakinan yang memadai, karena Anda akan meminta sistem yang telah dibobol untuk melaporkan dirinya sendiri. ps yang telah diganti dapat menyembunyikan proses, satu baris dalam /etc/ld.so.preload dapat menyisipkan kode ke setiap alat yang terhubung secara dinamis yang Anda jalankan, dan modul kernel dapat menyembunyikan file dari semua program sekaligus. Anda dapat menemukan sesuatu, sehingga temuan memiliki arti. Namun, Anda tidak dapat membuktikan bahwa tidak ada apa pun yang tersembunyi, sehingga hasil pemeriksaan yang bersih bukan bukti. Pembersihan hanya dapat dibenarkan jika server tidak menyimpan apa pun yang penting bagi Anda dan Anda menerima kemungkinan bahwa server tersebut akan dibobol lagi.

Sebaiknya saya mematikan server yang telah dibobol atau membiarkannya tetap berjalan?

Putuskan jaringan server melalui penyedia terlebih dahulu, lalu biarkan server tetap berjalan cukup lama untuk mengambil snapshot dan memeriksa proses yang sedang berjalan. Mematikan server menghapus daftar proses, dan juga menghapus journal sepenuhnya jika /var/log/journal tidak ada, karena journald kemudian menulis ke memori di bawah /run. Tetap matikan server jika server sedang aktif menyerang jaringan lain dan Anda tidak memiliki cara untuk memblokir trafik keluarnya. Menghentikan dampak serangan lebih penting daripada mempertahankan bukti.

Bagaimana cara mengetahui kapan penyerang berhasil masuk?

Cari baris Accepted password atau Accepted publickey paling awal yang tidak dapat Anda jelaskan, di /var/log/auth.log atau di journal. Bandingkan dengan daftar waktu perubahan, find / -xdev -newerct 'YYYY-MM-DD' -type f, karena ctime lebih sulit dipalsukan daripada mtime. Kemudian bandingkan keduanya dengan timestamp dalam tiket penyalahgunaan dari penyedia Anda. Timestamp tersebut dicatat di luar mesin dan tidak dapat diedit dari server. Pilih backup yang lebih lama daripada tanggal paling awal dari ketiga sumber tersebut. Jika tidak ada yang cocok, anggap kompromi terjadi sebelum seluruh riwayat backup Anda dan pulihkan hanya data yang dapat Anda periksa.

Apakah backup saya aman untuk dipulihkan setelah terjadi kompromi?

Data biasanya aman, setelah diperiksa. File sistem tidak aman. Backup yang dibuat setelah penyusupan berisi backdoor. Karena itu, pemulihan seluruh root filesystem juga memulihkan penyerang. Periksa repository backup itu sendiri. Jika kredensial untuk repository tersebut disimpan di server yang telah dibobol, riwayat backup mungkin telah dihapus atau diubah. Inilah alasan target backup sebaiknya bersifat append-only atau berbasis pull. Pulihkan data aplikasi, lalu instal kembali software dari repository distribusi.

Apakah saya harus memberi tahu seseorang bahwa VPS saya telah dibobol?

Selalu balas pemberitahuan penyalahgunaan dari host Anda. Di luar itu, kewajibannya bergantung pada data milik siapa yang tersimpan di mesin tersebut. Data pribadi milik orang lain dapat menimbulkan kewajiban pelaporan berdasarkan hukum, seperti kewajiban GDPR untuk memberi tahu otoritas pengawas dalam 72 jam. Jika kredensial pengguna disimpan di server, beri tahu pengguna tersebut agar mereka dapat mengganti password di layanan lain. Jika key di server memberikan akses ke sistem pihak ketiga, seperti code host atau akun cloud, beri tahu penyedia layanan tersebut agar mereka dapat memeriksa kemungkinan penyalahgunaan. Server pribadi yang tidak menyimpan data milik orang lain tidak menimbulkan kewajiban selain menanggapi tiket penyalahgunaan.