Na-hack ang VPS? Huwag Linisin, I-rebuild Ito

Huwag linisin ang na-hack na VPS

Kung na-hack ang iyong VPS, ang pinakamahalagang desisyon ay ginagawa bago ka magpatakbo ng anumang command. Huwag subukang linisin ang machine. I-isolate ito sa provider, gumawa ng snapshot ng disk bilang ebidensiya, palitan ang bawat credential na naka-store dito, at pagkatapos ay mag-rebuild sa isang bagong server gamit ang mga source na pinagkakatiwalaan mo.

Hindi mo mapapatunayang wala na ang rootkit, dahil ang mga tool na makapagpapatunay nito ay ang mga tool na kontrolado ng attacker.

Iyan ang buong argumento. Narito kung paano ito nangyayari. Ang attacker na nakakuha ng root ay maaaring magpalit ng ps upang hindi kailanman lumitaw sa output nito ang isang process ID. Maaaring mag-load ang isang linya sa /etc/ld.so.preload ng code ng attacker sa bawat dynamically linked program sa machine, kaya pare-pareho ang pagsisinungaling ng ls, ss at find. Maaaring magtago ang isang loadable kernel module ng mga file sa ibaba ng system call, kaya kahit ang bagong-download na binary ay makakakita ng malinis na disk. Buburahin mo ang miner, bababa ang CPU graph, at tatahimik ang server. Ang pagiging tahimik ay maaari ring senyales ng gumaganang backdoor.

Mas mababa ang gastos ng pag-rebuild kaysa sa inaakala. Karaniwang binubuo ang isang VPS ng ilang package, isang config directory at isang data set, kaya ang rebuild ay isang limitadong task na may malinaw na katapusan. Walang tiyak na hangganan ang paghahanap sa bawat pagbabagong ginawa ng attacker, at hindi ito kailanman umaabot sa patunay.

Kumpirmahin kung talagang may security breach

Maraming server na iniuulat na na-hack ang hindi naman talaga na-breach. Ang libo-libong nabigong SSH login bawat araw ay karaniwang background noise sa internet, dahil patuloy na sini-scan ang bawat public IPv4 address. Ang lastb output na puno ng mga pagtatangkang root at admin ay nangangahulugang natuklasan ng mga scanner ang iyong port. Hindi ito nangangahulugang may nakapasok.

May kahulugan ang mga signal na ito:

• Isang matagumpay na login na hindi mo maipaliwanag, gaya ng Accepted password for root from 203.0.113.7.
• Isang key sa authorized_keys na hindi mo idinagdag.
• Isang abuse notice mula sa iyong host tungkol sa traffic na lumalabas sa iyong server.
• Isang process na gumagamit ng 100% CPU at may pangalang kinopya mula sa isang kernel thread. Ang mga miner na pumasok sa pamamagitan ng exposed Redis at Docker socket ay karaniwang nagrerehistro sa mga pangalang gaya ng kdevtmpfsi at kinsing.
• Mga outbound connection sa mga address na hindi ginagamit ng alinman sa iyong mga serbisyo.

May mabilis na test para sa pagpapanggap bilang kernel thread. Ang mga tunay na kernel thread ay ipinapakita sa loob ng square brackets at walang executable sa likod ng mga ito. Kaya nagfa-fail ang sudo ls -l /proc/<pid>/exe para sa mga ito at nagbabalik ng No such file or directory. Kung ang process na ipinapakita bilang [kworker/0:2] ay may exe link na tumuturo sa isang bagay sa ilalim ng /tmp, isa itong ordinaryong user program na gumagamit ng pangalan ng kernel.

Isagawa ang mga check na ito nang may kaalamang maaaring magsinungaling sa iyo ang server. Sapat ang mga ito para matukoy na may mali. Hindi sapat ang mga ito para matukoy na walang problema.

Ihiwalay ang network sa provider, hindi mula sa loob ng server

Unahin ang isolation, dahil masasayang ang lahat ng susunod na hakbang habang may ibang taong may hawak pa ring shell. Walang saysay ang pagbabasa ng logs, pag-rotate ng keys, at pag-restore ng data kung may aktibong attacker na nagmamasid.

Gawin ito sa control panel ng provider, sa network firewall na tumatakbo sa labas ng operating system. I-deny ang inbound at outbound traffic, at panatilihing web console ang paraan ng pag-access. Ang mga rule na ipinapatupad doon ay mananatiling aktibo anuman ang mangyari sa disk.

May dalawang dahilan para hindi ito gawin mula sa loob ng server. Ang firewall na kino-configure mo sa loob ng compromised kernel ay ipinapatupad ng kernel na iyon, at kayang i-flush ng root ang nftables gaya ng kaya mo itong i-configure. At ang sudo ip link set enp1s0 down sa SSH ay unang puputol sa sarili mong session, kaya mai-lock out ka sa machine na kasalukuyan mong sinusuri.

I-block ang outbound pati inbound traffic. Ang reverse shell ay kumokonekta palabas mula sa box mo papunta sa attacker, kaya mananatiling gumagana nang maayos ang established connection kapag inbound-only ang block. Kung inbound rules lamang ang iniaalok ng provider, ang natitirang mga option ay i-detach ang network interface o i-power off ang instance.

Huwag munang mag-reboot. Suriin muna kung umiiral ang /var/log/journal. Kung wala ang directory na iyon, nagsusulat ang journald sa /run/log/journal, na nasa memory, kaya mabubura ng reboot ang record ng intrusion. Mawawala rin sa reboot ang mga tumatakbong process, at madalas ang command line ng mga ito ang pinakamalinaw na ebidensiyang makukuha mo.

Gumawa ng snapshot ng disk bago ka gumawa ng anumang pagbabago

Magkaiba ang tungkulin ng snapshot at backup dito. Ang snapshot na gagawin mo ngayon ay kopya ng breached na disk: ito ang ebidensiya mo, at ito lang ang nagbibigay-daan para makabalik ka kapag may hindi mo sinasadyang ma-overwrite. Ang mas lumang backups mo ang recovery path. Kung maluwag gamitin ng panel ng provider mo ang dalawang terminong ito, basahin muna ang kung paano naiiba ang VPS snapshots sa totoong backups, dahil magkaiba ang retention rules at restore behavior ng mga ito.

Gawin ang snapshot mula sa provider panel bago ka muling mag-log in. Ang live snapshot ay crash-consistent: kinokopya nito ang disk ayon sa estado nito sa sandaling iyon, tulad ng biglang pagpatay sa power. Ayos ito para sa ebidensiya. Pangalanan ito nang malinaw para walang makapag-restore nito nang hindi sinasadya. Ang tahasang pangalan na COMPROMISED-do-not-restore-2026-08-12 ang tamang antas ng pagiging malinaw. Itago ito hanggang matapos ang imbestigasyon mo at maisara ang anumang abuse ticket sa iyong host.

Paano makakapasok kapag wala na ang SSH

Dalawa ang paraan, at parehong nasa provider panel. Ikinokonekta ng web console (VNC o serial) ang machine na parang nagsaksak ka ng keyboard. Gumagana ito kapag patay ang sshd, mali ang firewall, o binago ng attacker ang SSH port. Nagpapatunay ito gamit ang local password, kaya maaaring kailangan munang mag-reset ng root password bago maging kapaki-pakinabang ang console sa server na key-only.

Mas mainam ang rescue mode. Nagbo-boot ito ng maliit na live system habang nakakabit ang disk mo pero hindi tumatakbo mula rito, kaya mapagkakatiwalaan ang mga command: hindi tumatakbo ang compromised kernel at ang compromised binaries. I-mount ang disk bilang read only.

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

Kung ipinapakita ng lsblk ang mga volume ng LVM (logical volume manager) sa halip na plain partition, i-activate muna ang mga ito gamit ang sudo vgchange -ay, saka i-mount ang device na lumilitaw sa ilalim ng /dev/mapper/.

Huwag mag-chroot sa mounted disk para maghanap-hanap. Ine-execute ng chroot ang binaries ng attacker gamit ang permissions mo, kaya nawawala ang buong dahilan kung bakit ka nag-boot sa rescue mode.

Kolektahin ang ebidensiyang mapagkakatiwalaan pa

Patakbuhin ang mga ito mula sa rescue mode, habang naka-mount ang disk bilang read only sa /mnt/victim. Magsimula sa mga login dahil nagbibigay ang mga ito ng oras kung kailan naganap ang intrusion. Mas madali ang lahat ng iba pang pagsusuri kapag mayroon ka nang time window.

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"

Hindi awtomatikong kahina-hinala ang kawalan ng /var/log/auth.log. May ilang kasalukuyang Ubuntu image na walang rsyslog, kaya sa journal lamang nagla-log ang sshd. Ito ang binabasa ng linyang journalctl -D. Ang dapat tandaan ay puwang sa mga log na dati namang tuloy-tuloy, o log file na na-truncate at naging zero bytes. Karaniwan ang pagbura ng log at kadalasan ay magaspang ang pagkakagawa.

Sunod, suriin ang mga account at 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

Inililista ng linyang awk ang lahat ng account na may user ID na 0. Anumang resulta bukod sa root ay isa pang root account. Sadyang kasama sa pattern na find ang authorized_keys2 dahil parehong file name ang binabasa ng OpenSSH bilang default, at madaling hindi mapansin ang pangalawa. Kung mag-print ang lsattr ng i sa attribute list, immutable ang file. Itinatakda ng attacker ang flag na ito upang mabigo ang pagtatangkang mag-delete ng kanilang key gamit ang Operation not permitted, at ipalagay ng pagod na admin na matagumpay ang pag-edit.

Karaniwang nagtatago ang persistence sa iilang lugar lamang, kaya suriin ang lahat ng ito.

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

Wala ang /etc/ld.so.preload sa karaniwang Ubuntu o Debian system. Kaya ang malusog na resulta ay No such file or directory, at dapat suriin ang anumang nilalaman. Ganito rin ang kaso sa login file na ipinapasa ang output ng base64 -d sa isang shell. Hindi kailangang itago ng lehitimong configuration ang sarili nitong text.

Buuin ang timeline gamit ang change time sa halip na modification time.

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

Maaaring itakda ng touch ang modification time sa anumang halagang gusto ng attacker, kaya madaling magsinungaling ang mtime. Nag-a-update ang change time (ctime) sa anumang pagbabago sa inode, at hindi ito maaaring ibalik ng touch sa nakaraang oras. Kaya nagbibigay ang -newerct ng mas tapat na listahan ng mga kamakailang naisulat. Hindi pa rin ito patunay dahil maaaring baguhin ng root ang system clock o direktang magsulat sa block device.

Mahalaga ang package integrity para sa isang command at isang caveat. Sa live system, nagpi-print ang sudo dpkg --verify ng isang linya para sa bawat packaged file na hindi na tumutugma ang checksum, na may 5 sa checksum column. Ginagawa rin ito ng sudo debsums -ac, kasama ang mga config file kapag naka-install ang debsums package. Isang direksiyon lamang ang pagbasa sa resulta. Totoong ebidensya ang nabagong /usr/sbin/sshd. Walang napapatunayan ang malinis na report dahil maaaring palitan ng parehong root account na nagpalit ng binary ang checksum lists sa ilalim ng /var/lib/dpkg/info/. Pareho ang tuntunin sa rootkit scanner gaya ng rkhunter at chkrootkit: ang hit ay impormasyon, ngunit hindi clearance ang malinis na run.

I-copy palabas ng machine ang lahat ng nakolekta mo bago gumawa ng anumang mapanirang aksyon.

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

Itala ang hash sa isang lokasyon na wala sa server. Kung mauwi ito sa insurance claim o police report, ang kakayahang ipakita na hindi nagbago ang archive mula nang kolektahin ito ang naghihiwalay sa ebidensya sa isang folder lamang ng mga file. Normal ang aksidenteng pagbura ng mga bagay habang nag-iimbestiga, at ang snapshot kasama ng archive na ito ang dahilan kung bakit maaari pa itong mabawi. Mas mahirap kaysa inaasahan ang pag-undo sa maling rm pagkatapos, gaya ng ipinapaliwanag sa pag-recover ng mga file na binura gamit ang rm -rf.

Hanapin ang pinasukan nila

Kung hindi isasara ng rebuild ang entry route, muli kang maba-breach, kadalasan sa loob ng ilang araw, dahil patuloy na tumatakbo ang scan na unang nakahanap sa iyo. Apat na entry point ang sumasaklaw sa karamihan ng mga compromise sa iisang server.

SSH password login. Ang isang Accepted password for root line mula sa address na hindi mo kinikilala ay sapat nang ebidensiya. Suriin ang PasswordAuthentication sa /etc/ssh/sshd_config at sa bawat file sa ilalim ng /etc/ssh/sshd_config.d/. Ginagamit ng sshd ang unang value na makuha nito para sa isang keyword, at nasa itaas ng pangunahing file sa Ubuntu ang Include line. Kaya tahimik na nananaig ang config file na inilagay sa directory kaysa sa setting na in-edit mo sa bandang ibaba.

Isang service na naka-publish nang walang authentication. Halimbawa nito ang Redis sa 6379, ang Docker API sa 2375, o isang database na naka-bind sa 0.0.0.0 sa halip na 127.0.0.1. Karaniwang hindi inaasahan ang Docker. Ang pag-publish ng container port ay naglalagay ng DNAT (destination network address translation) rules na sinusuri bago ang mga chain ng ufw. Kaya maaaring i-report ng ufw status na blocked ang isang port habang sinasagot naman ng container sa likod nito ang buong internet. Unawain ito bago ang rebuild: ipinapaliwanag ng kung bakit nilalampasan ng Docker published ports ang ufw ang pagkakasunod-sunod ng rules at ang remediation.

Isang hindi na-patch na web application. Hanapin sa web server access log, malapit sa pinakamaagang kahina-hinalang timestamp, ang POST papunta sa upload path o admin path. Pagkatapos, hanapin ang mga file sa ilalim ng web root na may katugmang change time. Karaniwang resulta ang isang ligaw na PHP file sa uploads directory.

Isang na-leak na credential. Maaaring key na na-commit sa repository, token na na-paste sa chat, o .env file na naihatid bilang static file ng maling configuration ng web server. Dahil sa automation, madali itong mangyari nang hindi sinasadya. Ito ang dahilan kung bakit dapat ilayo ang mga secret sa AI agents at sa kanilang config files.

Kung hindi mo matukoy ang pinasukan matapos ang lahat ng ito, ipagpalagay na na-leak ang isang credential at ituring na public ang bawat secret na nasa machine.

I-rotate ang bawat credential na maaaring makita ng machine

Mag-rotate matapos putulin ang network, hindi bago nito. Kung magro-rotate habang may koneksiyon pa ang attacker, ibinibigay mo lang sa kanya ang mga bagong secret.

• Bawat SSH private key na naka-store sa server, pati ang bawat account sa ibang system na nagtitiwala sa katugmang public key.
• Anumang key na ipinasa mo sa machine gamit ang ssh -A. Nag-iiwan ang agent forwarding ng socket sa ilalim ng /tmp, at magagamit ito ng root sa machine na iyon para mag-authenticate bilang ikaw sa anumang lugar kung saan tinatanggap ang iyong key, habang bukas ang session mo.
• Mga API token sa mga .env file, sa mga Environment= line ng systemd, sa CI configuration, at sa provider credentials.
• Mga database password, pati ang application account na gumagamit sa mga ito.
• Mga TLS (transport layer security) private key na hawak ng server. Mag-issue muli ng certificate at i-revoke ang luma.
• Ang password ng iyong hosting account, at i-on ang two-factor authentication. Maaaring gamitin ang panel na iyon para mag-rebuild, gumawa ng snapshot, at magbukas ng console sa bawat server na pagmamay-ari mo, kaya ito ang tunay na perimeter.
• Anumang password na na-type sa shell session sa host na iyon habang compromised ito, dahil maaaring mag-record ang root ng terminal session habang ginagamit ito.

Kung ginagamit kahit saan pa ang isang password sa machine na iyon, palitan din ito roon. Ang password reuse ang dahilan kung bakit ang isang compromised VPS ay maaaring humantong sa compromised email account.

Checklist para sa rebuild

1. Gumawa ng bagong server mula sa bagong distribution image. Huwag mula sa snapshot ng breached na server, at huwag mula sa buong restore ng root filesystem.
2. Mag-install ng packages mula sa distribution repositories. Huwag kailanman magkopya ng binary mula sa lumang disk.
3. Data lamang ang i-restore, mula sa backup na may petsang mas maaga kaysa sa pinakamaagang ebidensiya sa iyong timeline. Kasama rito ang database dumps, uploads, at application state. Iwan ang /etc, /usr, at mga lumang unit file.
4. Ipasok nang mano-mano ang mga pinalitang secret. Huwag kopyahin ang lumang .env.
5. Suriin ang na-restore na web content para sa mga file na idinagdag sa loob ng intrusion window bago mo itong muling i-serve.
6. I-harden ang server bago ito ilantad: key-only SSH, non-root na working account, inbound firewall na default-deny, at walang service na ipa-publish nang mas malawak kaysa kinakailangan. Sundin ang unang sampung minuto sa bagong VPS, pagkatapos ay i-harden nang maayos ang SSH, at idagdag ang fail2ban sa Ubuntu 24.04 upang mabawasan ang login noise. Bigyan ang bawat service ng sarili nitong least-privilege account upang ang susunod na foothold ay hindi root foothold.
7. I-power off ang lumang server, at panatilihin ang snapshot nito hanggang sa matapos ang imbestigasyon at maisara ang anumang abuse ticket.
8. Ayusin ang mga backup. Kung haka-haka lamang ang step 3, ang tunay na aral ay masyadong maikli ang backup history para makabalik sa panahong bago ang intrusion. Ang versioned off-server backups na may mahabang retention ang nagbibigay ng malinis na restore point sa susunod: ibinibigay ng restic backups sa isang VPS ang parehong kailangan.

Kung hindi mo matukoy ang petsa ng intrusion, hindi ka makakapili ng ligtas na backup. Sa ganitong kaso, i-restore lamang ang data na masusuri mo nang mano-mano: isang SQL dump na mababasa mo o isang directory ng images na maililista mo. Ituring na kahina-hinala ang lahat ng executable at muling i-install ang mga ito mula sa repositories.

Ano ang ibig sabihin ng abuse notice mula sa iyong host

Karamihan sa mga tao ay nalalaman na na-breach ang kanilang server mula sa provider, hindi mula sa sarili nilang monitoring. Nakikita ng mga host ang outbound traffic: SSH brute-force laban sa ibang network, spam sa port 25, o pakikibahagi sa isang reflection attack. Karaniwang may timestamps, port, at sample ng mga flow ang ticket, kasama ang deadline na sinusukat sa oras.

Tumugon dito, kahit ang tanging sagot mo ay isolated ang server at nire-rebuild ito. Nagse-set ang mga provider ng null route o nagsu-suspend ng server kapag walang sagot sa ticket, kaya nagiging outage ang insidente mo. Pagkatapos, hingin ang raw log lines na pinagbabatayan ng report. Sa labas ng iyong machine na-record ang mga timestamp na iyon, kaya iyon ang bahagi ng timeline na hindi nabago ng attacker. Madalas din nitong natutukoy ang petsa ng intrusion nang mas maayos kaysa sa anumang nasa disk.

Karaniwang gawain para sa isang host ang paghawak sa breached na server ng customer, at hindi ito ibinabawas sa iyo kapag maayos mo itong hinandle. Ang mas malawak na tanong kung ligtas ba ang VPS hosting ay pangunahing nakasalalay sa kino-configure ng customer. Iyan mismo ang bahaging kailangan mong gawin muli mula sa simula.

Kailan dapat tumawag sa isang propesyonal

• Naglalaman ang server ng personal data na pag-aari ng ibang tao. Sa ilalim ng GDPR (General Data Protection Regulation), dapat i-report ang personal data breach sa supervisory authority nang walang hindi kinakailangang pagkaantala, at sa loob ng 72 oras mula nang matukoy ito kung maisasagawa iyon. Legal na gawain ang pagtukoy kung nagsimula na ang palugit na iyon, hindi gawain ng sysadmin.
• Kasama sa saklaw ang payment card data. Kinakailangan ng card schemes ang isang aprubadong forensic investigator, at maaaring maapektuhan ng sarili mong pagsusuri ang kaso.
• May extortion demand, o na-encrypt ang data mo.
• Nakakaabot ang machine sa iba pang machine: isang internal network, isang hypervisor, o isang CI runner na may production credentials. Ang isang compromised host sa isang grupo ay itinuturing na insidente na nakaaapekto sa buong grupo hangga't hindi napapatunayang iba.
• Kakailanganin mong tanggapin bilang ebidensiya para sa insurance o law enforcement ang mga nakalap na datos. Huminto pagkatapos gumawa ng snapshot, kumuha ng full disk image, at itala kung sino ang humawak nito at kung kailan.

Para sa isang VPS na nagpapatakbo ng sarili mong mga serbisyo at walang data ng ibang tao, sapat na ang playbook sa itaas. I-isolate ito sa provider. Gumawa ng snapshot bilang ebidensiya. Kolektahin ang mga datos na mapagkakatiwalaan pa. I-rotate ang lahat. Mag-rebuild gamit ang malinis na environment.

FAQ

Maaari ko bang linisin ang na-hack na VPS sa halip na i-rebuild ito?

Hindi ito magagawa nang may kumpiyansa, dahil hihilingin mong ang compromised system mismo ang mag-ulat tungkol sa sarili nito. Maaaring magtago ang pinalitang ps ng isang proseso, maaaring mag-inject ng code ang isang linya sa /etc/ld.so.preload sa bawat dynamically linked tool na pinapatakbo mo, at maaaring magtago ang kernel module ng mga file mula sa lahat ng program nang sabay-sabay. Makakahanap ka ng ilang palatandaan, kaya makabuluhan ang isang hit. Ngunit hindi mo mapatutunayang walang iba pang nakatago, kaya hindi sapat ang malinis na resulta. Katanggap-tanggap lamang ang paglilinis kung walang mahalagang data sa server at tanggap mong maaari itong ma-compromise muli.

Dapat ko bang patayin ang compromised server o hayaan itong tumakbo?

I-block muna ang network nito sa provider, pagkatapos ay hayaan itong tumakbo nang sapat para makakuha ng snapshot at masuri ang mga kasalukuyang proseso. Kapag pinatay ang server, mawawala ang process list, at tuluyang mabubura ang journal kapag hindi umiiral ang /var/log/journal, dahil sa memory nagsusulat ang journald sa ilalim ng /run. Patayin pa rin ito kung aktibo itong umaatake sa ibang network at wala kang paraan para i-block ang outbound traffic nito. Mas mahalagang ihinto ang pinsala kaysa mapanatili ang ebidensiya.

Paano ko matutukoy kung kailan nakapasok ang attacker?

Hanapin ang pinakamaagang linya ng Accepted password o Accepted publickey na hindi mo maipaliwanag, sa /var/log/auth.log o sa journal. I-cross-check ito gamit ang listing batay sa change time, find / -xdev -newerct 'YYYY-MM-DD' -type f, dahil mas mahirap i-forge ang ctime kaysa sa mtime. Pagkatapos, ihambing ang dalawang ito sa mga timestamp sa abuse ticket ng provider mo. Naitala ang mga timestamp na iyon sa labas ng machine at hindi maaaring ma-edit. Pumili ng backup na mas luma kaysa sa pinakamaaga sa tatlong petsang iyon. Kung walang nagtutugma, ipagpalagay na mas luma ang compromise kaysa sa backup history mo at i-restore lamang ang data na maaari mong inspeksiyunin.

Ligtas bang i-restore ang mga backup ko matapos ang isang compromise?

Karaniwang ligtas ang data, basta ito ay inspeksiyunin. Hindi ligtas ang system files. Ang backup na ginawa matapos makapasok ang attacker ay naglalaman ng backdoor, kaya kapag ni-restore ang buong root filesystem, kasama ring mare-restore ang attacker. Suriin din ang backup repository mismo. Kung naka-store sa compromised server ang credentials para rito, maaaring nabura o nabago ang history. Ito ang dahilan kung bakit mainam ang append-only o pull-based na backup targets. I-restore ang application data, pagkatapos ay i-install muli ang software mula sa distribution repositories.

Kailangan ko bang sabihin sa iba na na-compromise ang VPS ko?

Palaging tumugon sa abuse notice ng host mo. Higit pa rito, nakadepende ito sa kung kanino ang data na nasa machine. Maaaring magtakda ng legal na obligasyon sa pag-uulat ang personal data ng ibang tao, gaya ng 72-hour notification ng GDPR sa supervisory authority. Kung naka-store sa server ang user credentials, ipaalam ito sa mga user upang mapalitan nila ang kanilang mga password sa ibang serbisyo. Kung ang mga key sa machine ay nagbibigay ng access sa third-party systems, gaya ng code host o cloud account, ipaalam ito sa mga provider na iyon upang masuri nila kung nagamit sa maling paraan. Kung personal lamang ang server at wala itong data ng ibang tao, wala kang obligasyon bukod sa pagtugon sa abuse ticket.