Cara Mengatasi VPS Yang Telah Digodam

Jangan bersihkan VPS yang telah digodam

Jika VPS anda digodam, keputusan paling penting perlu dibuat sebelum anda menjalankan sebarang arahan. Jangan cuba membersihkan mesin tersebut. Asingkan mesin itu di peringkat penyedia, ambil snapshot cakera sebagai bukti, tukar setiap kelayakan (credential) yang disimpan di dalamnya, kemudian bina semula pada pelayan baharu menggunakan sumber yang anda percayai.

Anda tidak dapat membuktikan bahawa rootkit telah dibuang, kerana alatan yang digunakan untuk membuktikannya adalah alatan yang dikawal oleh penyerang.

Itu adalah hujah keseluruhannya. Berikut adalah mekanisme di sebaliknya. Penyerang yang mencapai tahap root boleh menggantikan ps supaya satu ID proses tidak akan muncul dalam outputnya. Satu baris dalam /etc/ld.so.preload memuatkan kod penyerang ke dalam setiap program yang dipautkan secara dinamik pada kotak tersebut, jadi ls, ss dan find semuanya berbohong dengan cara yang konsisten. Modul kernel yang boleh dimuatkan (loadable kernel module) boleh menyembunyikan fail di bawah panggilan sistem (system call), jadi walaupun binari yang baru dimuat turun akan melihat cakera yang bersih. Anda memadamkan pelombong (miner), graf CPU menurun, dan pelayan menjadi senyap. Senyap juga adalah keadaan pintu belakang (backdoor) yang sedang berfungsi.

Membina semula menelan kos yang lebih rendah daripada yang disangkakan. VPS tipikal terdiri daripada segelintir pakej, satu direktori konfigurasi dan satu set data, jadi pembinaan semula adalah tugas terhad yang mempunyai penghujung. Mencari setiap perubahan yang dilakukan oleh penyerang adalah tugas yang tiada kesudahan, dan ia tidak akan pernah mencapai tahap pembuktian.

Sahkan bahawa pelayan benar-benar telah diceroboh

Banyak pelayan yang dilaporkan telah digodam sebenarnya tidak diceroboh. Beribu-ribu cubaan log masuk SSH yang gagal setiap hari hanyalah gangguan latar belakang internet, kerana setiap alamat IPv4 awam diimbas secara berterusan. Output lastb yang dipenuhi dengan cubaan root dan admin bermakna pengimbas telah menemui port anda. Ini tidak bermakna sesiapa telah berjaya masuk.

Isyarat berikut menunjukkan sesuatu yang serius:

• Log masuk berjaya yang tidak dapat anda jelaskan, seperti Accepted password for root from 203.0.113.7.
• Kunci dalam authorized_keys yang tidak anda tambahkan.
• Notis penyalahgunaan daripada hos anda mengenai trafik yang keluar dari pelayan anda.
• Proses pada 100% CPU yang menggunakan nama yang disalin daripada thread kernel. Pelombong yang dimasukkan melalui socket Redis dan Docker yang terdedah biasanya dilaporkan di bawah nama seperti kdevtmpfsi dan kinsing.
• Sambungan keluar ke alamat yang tidak digunakan oleh mana-mana servis anda.

Penyamaran thread kernel mempunyai ujian pantas. Thread kernel sebenar dicetak di dalam kurungan segi empat sama dan tidak mempunyai fail boleh laku di belakangnya, jadi sudo ls -l /proc/<pid>/exe akan gagal untuk thread tersebut dengan No such file or directory. Jika proses yang dicetak sebagai [kworker/0:2] mempunyai pautan exe yang menghala ke sesuatu di bawah /tmp, ia adalah program pengguna biasa yang menggunakan nama kernel.

Jalankan pemeriksaan ini dengan kesedaran bahawa pelayan mungkin memberikan maklumat palsu kepada anda. Pemeriksaan ini mencukupi untuk menentukan bahawa sesuatu tidak kena. Ia tidak mencukupi untuk menentukan bahawa tiada apa-apa yang berlaku.

Putuskan rangkaian di peringkat penyedia, bukan dari dalam pelayan

Pengasingan adalah langkah pertama, kerana setiap langkah seterusnya adalah sia-sia selagi orang lain masih memegang akses shell. Membaca log, menukar kunci kriptografi dan memulihkan data tidak berguna jika penyerang masih memantau sistem secara langsung.

Lakukan tindakan ini di panel kawalan penyedia anda, melalui firewall rangkaian yang beroperasi di luar sistem pengendalian anda. Sekat trafik masuk dan keluar, dan kekalkan konsol web sebagai cara akses anda. Peraturan yang dikuatkuasakan di sana akan kekal berkesan walau apa pun yang berlaku pada cakera.

Terdapat dua sebab mengapa anda tidak patut melakukan ini dari dalam pelayan. Firewall yang anda konfigurasikan di dalam kernel yang telah diceroboh akan dikuatkuasakan oleh kernel tersebut, dan akaun root boleh memadamkan peraturan nftables dengan mudah. Selain itu, sudo ip link set enp1s0 down melalui SSH akan memutuskan sesi anda sendiri terlebih dahulu, yang menyebabkan anda terkunci daripada mesin yang sedang anda periksa.

Sekat trafik keluar dan juga trafik masuk. Reverse shell akan menghubungi keluar dari pelayan anda kepada penyerang, jadi sekatan trafik masuk sahaja akan membiarkan sambungan yang telah sedia ada berfungsi dengan sempurna. Jika penyedia anda hanya menawarkan peraturan trafik masuk, pilihan yang tinggal ialah menanggalkan antara muka rangkaian atau mematikan instans tersebut.

Jangan but semula (reboot) lagi. Periksa sama ada /var/log/journal wujud terlebih dahulu. Jika direktori tersebut tiada, journald sedang menulis ke /run/log/journal, yang disimpan dalam memori, jadi but semula akan memadamkan rekod pencerobohan tersebut. Proses yang sedang berjalan juga akan hilang semasa but semula, sedangkan baris perintah (command line) proses tersebut sering kali menjadi bukti paling jelas yang anda akan perolehi.

Ambil snapshot cakera sebelum anda mengubah apa-apa

Snapshot dan sandaran (backup) mempunyai fungsi yang berbeza dalam konteks ini. Snapshot yang anda ambil sekarang ialah salinan cakera yang telah diceroboh: ia merupakan bukti anda, dan ia satu-satunya cara untuk anda kembali ke keadaan asal sekiranya anda tertindih sesuatu secara tidak sengaja. Sandaran lama anda ialah laluan pemulihan. Jika panel pembekal anda menggunakan kedua-dua istilah ini secara longgar, baca perbezaan antara snapshot VPS dan sandaran sebenar terlebih dahulu, kerana peraturan pengekalan dan kelakuan pemulihan adalah tidak sama.

Ambil snapshot daripada panel pembekal sebelum anda log masuk semula. Snapshot secara langsung (live snapshot) adalah konsisten secara ranap (crash consistent): ia merakam cakera pada saat itu, sama seperti mencabut bekalan kuasa. Ini memadai untuk tujuan bukti. Namakannya supaya tiada sesiapa yang memulihkannya secara tidak sengaja. Nama yang terus-terang seperti COMPROMISED-do-not-restore-2026-08-12 adalah tahap kejelasan yang tepat. Simpan snapshot tersebut sehingga siasatan anda selesai dan sebarang tiket penyalahgunaan dengan hos anda ditutup.

Cara untuk masuk apabila SSH tidak berfungsi

Terdapat dua laluan, kedua-duanya melalui panel pembekal. Konsol web (VNC atau bersiri) bersambung ke mesin seolah-olah anda telah memasang papan kekunci. Ia berfungsi apabila sshd mati, apabila firewall tersalah konfigurasi, dan apabila penyerang menukar port SSH. Ia mengesahkan identiti menggunakan kata laluan tempatan, jadi pelayan yang hanya menggunakan kunci mungkin memerlukan tetapan semula kata laluan root sebelum konsol tersebut boleh digunakan.

Mod penyelamatan (rescue mode) adalah pilihan yang lebih baik. Ia memuatkan sistem langsung (live system) kecil dengan cakera anda dipasang tetapi tidak dijalankan, jadi arahan anda boleh dipercayai: kernel yang terjejas dan binari yang terjejas tidak sedang dilaksanakan. Pasang cakera dalam mod baca sahaja (read-only).

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

Jika lsblk menunjukkan volum LVM (logical volume manager) dan bukannya partition biasa, aktifkannya dengan sudo vgchange -ay terlebih dahulu, kemudian pasang peranti yang muncul di bawah /dev/mapper/.

Jangan chroot ke dalam cakera yang telah dipasang untuk melihat-lihat. Chroot melaksanakan binari penyerang dengan kebenaran anda, yang mana akan membatalkan tujuan utama anda memulakan mod penyelamatan.

Kumpul bukti yang masih boleh dipercayai

Jalankan arahan ini daripada mod penyelamat (rescue mode), dengan cakera dilekapkan (mounted) sebagai baca-sahaja (read-only) pada /mnt/victim. Mulakan dengan log masuk, kerana ia menentukan tarikh pencerobohan, dan segala-galanya menjadi lebih mudah sebaik sahaja anda mempunyai tempoh masa yang tepat.

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"

Ketiadaan /var/log/auth.log bukanlah sesuatu yang mencurigakan. Sesetengah imej Ubuntu semasa tidak menyertakan rsyslog, jadi sshd merekodkan log ke dalam journal sahaja, iaitu perkara yang dibaca oleh baris journalctl -D. Perkara yang perlu diberi perhatian ialah jurang dalam log yang sepatutnya berterusan, atau fail log yang dipotong (truncated) kepada sifar bait. Pemadaman log adalah perkara biasa dan biasanya dilakukan dengan cara yang kasar.

Seterusnya, periksa akaun dan kunci.

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 setiap akaun dengan ID pengguna 0. Sebarang output selain daripada root menunjukkan adanya akaun root kedua. Corak find sengaja dipadankan dengan authorized_keys2 juga, kerana OpenSSH membaca kedua-dua nama fail secara lalai dan fail kedua mudah terlepas pandang. Jika lsattr mencetak i dalam senarai atribut, fail tersebut adalah tidak boleh ubah (immutable): penyerang menetapkan flag tersebut supaya percubaan anda untuk memadam kunci mereka gagal dengan Operation not permitted, dan pentadbir yang keletihan akan menganggap suntingan tersebut telah berjaya.

Kegigihan (persistence) bersembunyi di tempat yang terhad, jadi periksa kesemuanya.

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 wujud pada sistem Ubuntu atau Debian biasa, jadi No such file or directory adalah hasil yang sihat dan sebarang kandungan di dalamnya memerlukan perhatian anda. Fail log masuk yang menyalurkan (pipe) output base64 -d ke dalam shell adalah cerita yang sama: konfigurasi yang sah tidak perlu menyembunyikan teksnya sendiri.

Bina garis masa berdasarkan masa perubahan (change time) dan bukannya masa pengubahsuaian (modification time).

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

touch menetapkan masa pengubahsuaian kepada sebarang nilai yang diingini oleh penyerang, jadi mtime boleh menipu dengan mudah. Masa perubahan (ctime) dikemas kini pada setiap perubahan pada inode, dan touch tidak boleh mengundurkannya, jadi -newerct memberikan senarai yang lebih jujur tentang perkara yang ditulis baru-baru ini. Ia masih bukan bukti mutlak, kerana root boleh mengubah jam sistem atau menulis terus ke peranti blok.

Integriti pakej bernilai satu arahan dan satu amaran. Pada sistem yang sedang berjalan, sudo dpkg --verify mencetak satu baris untuk setiap fail pakej yang checksum-nya tidak lagi sepadan, dengan 5 dalam lajur checksum, dan sudo debsums -ac melakukan tugas yang sama termasuk fail konfigurasi apabila pakej debsums dipasang. Baca hasil tersebut dalam satu arah sahaja. /usr/sbin/sshd yang berubah adalah bukti sebenar. Laporan yang bersih tidak membuktikan apa-apa, kerana akaun root yang sama yang menggantikan binari tersebut boleh menulis semula senarai checksum di bawah /var/lib/dpkg/info/. Pengimbas rootkit seperti rkhunter dan chkrootkit mengikut peraturan yang sama: hasil positif adalah maklumat, manakala imbasan yang bersih bukanlah pelepasan (clearance).

Salin apa yang telah anda kumpulkan keluar dari mesin sebelum anda melakukan sebarang tindakan yang merosakkan.

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

Catatkan hash tersebut di luar pelayan. Jika perkara ini menjadi tuntutan insurans atau laporan polis, keupayaan untuk menunjukkan bahawa arkib tersebut tidak berubah sejak pengumpulan adalah perbezaan antara bukti dan sekadar folder fail. Memadam sesuatu secara tidak sengaja semasa penyiasatan adalah perkara biasa, dan snapshot berserta arkib ini adalah perkara yang membolehkan anda bertahan. Membatalkan rm yang salah selepas itu adalah jauh lebih sukar daripada yang dijangkakan, seperti yang dijelaskan dalam memulihkan fail yang dipadam dengan rm -rf.

Cari pintu masuk yang mereka gunakan

Proses bina semula yang tidak menutup laluan masuk akan menyebabkan anda dicerobohi semula, selalunya dalam masa beberapa hari, kerana imbasan yang menemui anda pada kali pertama tidak pernah berhenti berjalan. Empat pintu merangkumi kebanyakan pencerobohan pelayan tunggal.

Log masuk kata laluan SSH. Baris Accepted password for root daripada alamat yang anda tidak kenali adalah jawapannya. Semak PasswordAuthentication dalam /etc/ssh/sshd_config dan dalam setiap fail di bawah /etc/ssh/sshd_config.d/. sshd menggunakan nilai pertama yang diperoleh untuk sesuatu kata kunci, dan baris Include berada di bahagian atas fail utama pada Ubuntu, jadi fail konfigurasi yang dimasukkan secara senyap akan mengatasi tetapan yang anda edit di bahagian bawah.

Servis yang diterbitkan tanpa pengesahan. Redis pada 6379, Docker API pada 2375, pangkalan data yang diikat pada 0.0.0.0 dan bukannya 127.0.0.1. Docker adalah kejutan yang biasa berlaku. Menerbitkan port kontena akan memasukkan peraturan DNAT (destination network address translation) yang dinilai sebelum rantaian ufw, jadi ufw status boleh melaporkan port sebagai disekat sedangkan kontena di belakangnya menjawab seluruh internet. Fahami perkara itu sebelum proses bina semula: mengapa port yang diterbitkan Docker memintas ufw merangkumi susunan peraturan dan penyelesaiannya.

Aplikasi web yang tidak ditampal. Cari log akses pelayan web di sekitar cap masa mencurigakan anda yang paling awal untuk POST ke laluan muat naik atau laluan admin, kemudian cari fail di bawah root web dengan masa perubahan yang sepadan. Fail PHP yang tersesat dalam direktori muat naik adalah hasil yang klasik.

Kredensial yang bocor. Kunci yang dikomit ke dalam repositori, token yang ditampal ke dalam sembang, fail .env yang dihidangkan sebagai fail statik oleh pelayan web yang tersalah konfigurasi. Automasi menjadikan perkara ini mudah berlaku secara tidak sengaja, itulah hujah untuk menjauhkan rahsia daripada ejen AI dan fail konfigurasi mereka.

Jika anda tidak dapat menamakan pintu tersebut selepas semua itu, anggaplah kredensial telah bocor dan anggap setiap rahsia yang disimpan oleh mesin tersebut sebagai awam.

Tukar setiap kelayakan yang mungkin telah dilihat oleh mesin

Lakukan penukaran selepas rangkaian diputuskan, jangan sesekali sebelumnya. Menukar kelayakan semasa penyerang masih mempunyai sambungan hanya akan menyerahkan rahsia baharu kepada mereka.

• Setiap kunci peribadi SSH yang disimpan pada pelayan, serta setiap akaun di tempat lain yang mempercayai kunci awam yang sepadan.
• Sebarang kunci yang anda majukan ke dalam kotak dengan ssh -A. Pemajuan ejen meninggalkan soket di bawah /tmp, dan root pada mesin tersebut boleh menggunakannya untuk mengesahkan diri sebagai anda di mana-mana sahaja kunci anda diterima, selagi sesi anda kekal terbuka.
• Token API dalam fail .env, dalam baris Environment= systemd, dalam konfigurasi CI dan dalam kelayakan pembekal.
• Kata laluan pangkalan data, dan akaun aplikasi yang menggunakannya.
• Kunci peribadi TLS (transport layer security) yang dipegang oleh pelayan. Terbitkan semula sijil dan batalkan sijil yang lama.
• Kata laluan akaun pengehosan anda, dengan pengesahan dua faktor diaktifkan. Panel tersebut boleh membina semula, mengambil snapshot dan mengakses konsol ke setiap pelayan yang anda miliki, jadi ia adalah perimeter sebenar.
• Sebarang kata laluan yang ditaip ke dalam sesi shell pada hos tersebut semasa ia diceroboh, kerana root boleh merakam sesi terminal semasa ia berlaku.

Jika kata laluan pada mesin tersebut digunakan di tempat lain, tukarkannya di sana juga. Penggunaan semula kata laluan adalah punca bagaimana satu VPS yang diceroboh menjadi akaun e-mel yang diceroboh.

Senarai semak pembinaan semula

1. Cipta pelayan baharu daripada imej pengedaran yang bersih. Jangan gunakan snapshot daripada pelayan yang telah diceroboh, dan jangan lakukan pemulihan keseluruhan sistem fail root.
2. Pasang pakej daripada repositori pengedaran. Jangan sesekali menyalin fail binari daripada cakera lama.
3. Pulihkan data sahaja, daripada sandaran yang bertarikh sebelum bukti terawal dalam garis masa anda. Ini termasuk dump pangkalan data, fail yang dimuat naik dan status aplikasi. Tinggalkan /etc, /usr dan fail unit lama.
4. Masukkan rahsia yang telah diubah secara manual. Jangan salin .env lama ke pelayan baharu.
5. Periksa kandungan web yang dipulihkan untuk mengesan fail yang ditambah semasa tempoh pencerobohan sebelum anda menyediakannya semula kepada pengguna.
6. Perketatkan keselamatan sebelum mendedahkannya kepada umum: gunakan SSH berasaskan kunci sahaja, akaun kerja bukan root, firewall masuk yang menolak semua trafik secara lalai, dan tiada servis yang diterbitkan lebih luas daripada yang diperlukan. Selesaikan langkah dalam sepuluh minit pertama pada VPS baharu, kemudian perketatkan SSH dengan betul, dan tambah fail2ban pada Ubuntu 24.04 untuk mengurangkan gangguan log masuk. Berikan setiap servis akaun keistimewaan minimumnya sendiri supaya pencerobohan seterusnya tidak memberikan akses root.
7. Matikan pelayan lama, dan simpan snapshotnya sehingga siasatan dan sebarang tiket penyalahgunaan ditutup.
8. Baiki sistem sandaran anda. Jika langkah 3 dilakukan secara meneka, pengajaran sebenar ialah sejarah sandaran anda terlalu singkat untuk mencapai tempoh sebelum pencerobohan. Sandaran luar pelayan yang mempunyai versi dan tempoh pengekalan yang panjang akan memberikan titik pemulihan yang bersih pada masa hadapan: sandaran restic pada VPS menyediakan kedua-duanya.

Jika anda tidak dapat menentukan tarikh pencerobohan, anda tidak boleh memilih sandaran yang selamat. Dalam keadaan itu, pulihkan hanya data yang boleh anda periksa dengan mata kasar: dump SQL yang boleh dibaca, atau direktori imej yang boleh disenaraikan. Anggap segala yang boleh dilaksanakan (executable) sebagai mencurigakan dan pasang semula daripada repositori.

Maksud notis penyalahgunaan daripada hos anda

Kebanyakan orang mengetahui pelayan mereka telah diceroboh daripada penyedia perkhidmatan, bukan daripada pemantauan sendiri. Hos melihat trafik keluar: serangan SSH brute force terhadap rangkaian lain, spam pada port 25, atau penyertaan dalam serangan pantulan (reflection attack). Tiket tersebut biasanya mengandungi cap masa, port, dan sampel aliran trafik, berserta tarikh akhir dalam kiraan jam.

Balas tiket tersebut, walaupun jawapan anda hanyalah bahawa pelayan telah diasingkan dan sedang dibina semula. Penyedia akan melakukan null-route atau menggantung pelayan apabila tiket tidak dijawab, yang akan menukarkan insiden anda menjadi gangguan perkhidmatan. Kemudian, minta baris log mentah yang menjadi asas laporan tersebut. Cap masa itu direkodkan di luar mesin anda, jadi ia merupakan satu-satunya bahagian garis masa yang tidak boleh diubah oleh penyerang, dan ia sering kali memberikan tarikh pencerobohan yang lebih tepat berbanding apa-apa yang terdapat pada cakera.

Pelayan pelanggan yang diceroboh merupakan kerja rutin bagi pihak hos, dan mengendalikannya dengan baik tidak akan memburukkan reputasi anda. Persoalan yang lebih luas tentang sama ada VPS hosting selamat kebanyakannya bergantung kepada konfigurasi pelanggan, iaitu bahagian yang kini perlu anda lakukan semula dari awal.

Bilakah perlu mendapatkan bantuan profesional

• Pelayan tersebut menyimpan data peribadi milik orang lain. Di bawah GDPR (General Data Protection Regulation), pelanggaran data peribadi mesti dilaporkan kepada pihak berkuasa penyelia tanpa kelewatan yang tidak wajar, dan dalam tempoh 72 jam selepas menyedarinya jika boleh dilakukan. Menilai sama ada tempoh masa tersebut telah bermula adalah tugas undang-undang, bukan tugas pentadbir sistem.
• Data kad pembayaran terlibat. Skim kad memerlukan penyiasat forensik yang diluluskan, dan tindakan anda menyiasat sendiri boleh menjejaskan kes tersebut.
• Terdapat tuntutan peras ugut, atau data anda telah disulitkan.
• Mesin tersebut boleh mencapai mesin lain: rangkaian dalaman, hypervisor, atau CI runner yang memegang kelayakan pengeluaran. Satu hos yang terjejas dalam satu kumpulan dianggap sebagai insiden seluruh kumpulan sehingga terbukti sebaliknya.
• Anda memerlukan bukti yang boleh diterima untuk insurans atau penguatkuasaan undang-undang. Berhenti pada snapshot, ambil imej cakera penuh, dan rekodkan siapa yang mengendalikannya serta bila.

Bagi satu VPS tunggal yang menjalankan perkhidmatan anda sendiri, tanpa data orang lain di dalamnya, panduan di atas adalah keseluruhan tugasnya. Asingkan di peringkat pembekal. Ambil snapshot untuk bukti. Kumpulkan apa yang masih boleh dipercayai. Tukar semua kelayakan. Bina semula dengan bersih.

FAQ

Bolehkah saya membersihkan VPS yang digodam dan bukannya membina semula?

Tidak, kerana anda meminta sistem yang telah diceroboh untuk melaporkan keadaannya sendiri. ps yang diganti boleh menyembunyikan proses, satu baris dalam /etc/ld.so.preload boleh menyuntik kod ke dalam setiap alat yang dipautkan secara dinamik yang anda jalankan, dan modul kernel boleh menyembunyikan fail daripada semua program serentak. Anda boleh menemui bukti, jadi penemuan positif adalah bermakna. Anda tidak boleh membuktikan ketiadaan ancaman, jadi hasil yang bersih tidak boleh dipercayai. Pembersihan hanya boleh dipertahankan jika pelayan tidak menyimpan apa-apa yang penting bagi anda dan anda menerima risiko bahawa ia mungkin diceroboh semula.

Patutkah saya mematikan pelayan yang diceroboh atau membiarkannya berjalan?

Putuskan sambungan rangkaiannya di pihak penyedia terlebih dahulu, kemudian biarkan ia berjalan cukup lama untuk mengambil snapshot dan melihat proses yang sedang berjalan. Mematikan pelayan akan memusnahkan senarai proses, dan ia memadamkan jurnal sepenuhnya apabila /var/log/journal tidak wujud, kerana journald kemudian menulis ke dalam memori di bawah /run. Matikan juga pelayan tersebut jika ia sedang aktif menyerang rangkaian lain dan anda tidak mempunyai cara untuk menyekat trafik keluar. Menghentikan kerosakan adalah lebih utama daripada menyimpan bukti.

Bagaimanakah saya mengetahui bila penyerang masuk?

Cari baris Accepted password atau Accepted publickey terawal yang tidak dapat anda jelaskan, dalam /var/log/auth.log atau dalam jurnal. Semak silang dengan senarai masa perubahan, find / -xdev -newerct 'YYYY-MM-DD' -type f, kerana ctime lebih sukar dipalsukan berbanding mtime. Kemudian bandingkan kedua-duanya dengan cap masa dalam tiket penyalahgunaan (abuse ticket) daripada penyedia anda, yang direkodkan di luar mesin dan tidak boleh disunting. Pilih sandaran yang lebih lama daripada tarikh terawal antara ketiga-tiga sumber tersebut. Jika tiada apa yang sepadan, anggap pencerobohan berlaku lebih awal daripada sejarah sandaran anda dan pulihkan hanya data yang boleh anda periksa.

Adakah sandaran saya selamat untuk dipulihkan selepas pencerobohan?

Data biasanya selamat, dengan pemeriksaan. Fail sistem pula tidak. Sandaran yang diambil selepas pencerobohan mengandungi pintu belakang (backdoor), jadi memulihkan keseluruhan sistem fail root akan memulihkan penyerang juga. Periksa repositori sandaran itu sendiri: jika kelayakan untuknya disimpan pada pelayan yang diceroboh, sejarah mungkin telah dipadam atau diubah, itulah sebabnya sasaran sandaran jenis append-only atau berasaskan pull disyorkan. Pulihkan data aplikasi, kemudian pasang semula perisian daripada repositori pengedaran.

Adakah saya perlu memberitahu sesiapa bahawa VPS saya diceroboh?

Sentiasa balas notis penyalahgunaan daripada hos anda. Selain itu, ia bergantung kepada data siapa yang berada pada mesin tersebut. Data peribadi milik orang lain boleh mencetuskan kewajipan pelaporan undang-undang, seperti pemberitahuan 72 jam GDPR kepada pihak berkuasa penyeliaan. Jika kelayakan pengguna disimpan pada pelayan, beritahu pengguna tersebut supaya mereka boleh menukar kata laluan di tempat lain. Jika kunci pada mesin tersebut membenarkan akses kepada sistem pihak ketiga, seperti hos kod atau akaun awan, beritahu penyedia tersebut supaya mereka boleh memeriksa penyalahgunaan. Pelayan yang bersifat peribadi sepenuhnya dan tidak menyimpan data orang lain tidak membawa sebarang kewajipan selain daripada menjawab tiket penyalahgunaan.