Hatua za kuchukua baada ya VPS yako kuvamiwa

Usijaribu kusafisha VPS iliyovamiwa

Ikiwa VPS yako imevamiwa, uamuzi muhimu zaidi unakuja kabla ya kuendesha amri yoyote. Usijaribu kusafisha mashine hiyo. Itenge kwenye mfumo wa mtoa huduma, chukua snapshot ya diski kama ushahidi, badilisha kila kitambulisho (credential) kilichokuwemo, kisha jenga upya kwenye seva mpya kwa kutumia vyanzo unavyoviamini.

Huwezi kuthibitisha kuwa rootkit imeondolewa, kwa sababu zana ambazo zingethibitisha hilo ndizo zana ambazo mshambuliaji anazidhibiti.

Huo ndio hoja nzima. Hii hapa ni mbinu iliyo nyuma yake. Mshambuliaji aliyefikia ngazi ya root anaweza kubadilisha ps ili kitambulisho cha mchakato (process ID) kisionekane kamwe kwenye matokeo yake. Mstari mmoja katika /etc/ld.so.preload hupakia msimbo wa mshambuliaji kwenye kila programu inayounganishwa kinguvu (dynamically linked) kwenye mashine hiyo, kwa hivyo ls, ss na find zote husema uongo kwa njia ile ile inayolingana. Moduli ya kernel inayoweza kupakiwa (loadable kernel module) inaweza kuficha faili chini ya mfumo wa wito (system call), kwa hivyo hata binary iliyopakuliwa upya huona diski ikiwa safi. Unafuta mchimbaji (miner), grafu ya CPU inashuka, na seva inatulia. Utulivu pia ndivyo mlango wa nyuma (backdoor) unaofanya kazi unavyoonekana.

Kujenga upya kunagharimu kidogo kuliko inavyohisiwa. VPS ya kawaida ni mkusanyiko wa vifurushi vichache, saraka moja ya usanidi na seti moja ya data, kwa hivyo kujenga upya ni kazi yenye ukomo na mwisho. Kusaka kila mabadiliko yaliyofanywa na mshambuliaji ni kazi isiyo na mwisho, na haifikii uthibitisho kamwe.

Thibitisha kama seva imevamiwa kweli

Seva nyingi zinazoripotiwa kuvamiwa hazijavamiwa. Maelfu ya majaribio yaliyoshindwa ya SSH kila siku ni kelele za kawaida za mtandao, kwa sababu kila anwani ya IPv4 ya umma huchunguzwa mfululizo. Pato la lastb lililojaa majaribio ya root na admin linamaanisha tu kuwa skana zimepata port yako. Haimaanishi kuwa kuna mtu ameingia.

Ishara hizi ndizo zenye maana:

• Kuingia kwa mafanikio (login) usikoweza kukuelezea, kama vile Accepted password for root from 203.0.113.7.
• Ufunguo (key) katika authorized_keys ambao hukuongeza wewe.
• Notisi ya matumizi mabaya kutoka kwa mtoa huduma wako kuhusu trafiki inayotoka kwenye seva yako.
• Mchakato (process) unaotumia 100% ya CPU ukiwa na jina lililonakiliwa kutoka kwa kernel thread. Wachimbaji wa crypto (miners) wanaowekwa kupitia Redis na Docker sockets zilizo wazi huripotiwa mara nyingi kwa majina kama kdevtmpfsi na kinsing.
• Viunganisho vya nje (outbound connections) kwenda kwenye anwani ambazo hakuna huduma yako inayozitumia.

Kujificha kwa kernel thread kuna jaribio la haraka. Kernel threads halisi huchapishwa ndani ya mabano mraba na hazina faili ya kutekelezeka (executable) nyuma yake, kwa hivyo sudo ls -l /proc/<pid>/exe hushindwa kwa ajili yao na kutoa No such file or directory. Ikiwa mchakato uliotajwa kama [kworker/0:2] una kiungo cha exe kinachoelekeza kwenye kitu kilicho chini ya /tmp, huo ni programu ya kawaida ya mtumiaji inayotumia jina la kernel.

Fanya ukaguzi huu ukijua kuwa seva inaweza kukudanganya. Hii inatosha kuamua kuwa kuna kitu kibaya. Haitoshi kuamua kuwa hakuna kitu kibaya.

Kata mtandao kwenye kiwango cha mtoa huduma, siyo kutoka ndani ya seva

Kutenga seva ndiyo hatua ya kwanza, kwa sababu kila hatua inayofuata ni kupoteza muda wakati mtu mwingine bado anashikilia shell. Kusoma log, kubadilisha key, na kurejesha data ni kazi bure wakati mshambuliaji bado anatazama.

Fanya hivi kwenye control panel ya mtoa huduma wako, katika firewall ya mtandao inayofanya kazi nje ya mfumo wako wa uendeshaji. Zuia mawasiliano ya kuingia na kutoka, na utumie web console kama njia yako ya kuingilia. Sheria zinazowekwa huko haziathiriwi na chochote kinachotokea kwenye diski.

Kuna sababu mbili za kutofanya hivi kutoka ndani ya seva. Firewall unayosanidi ndani ya kernel iliyoathiriwa inatekelezwa na kernel hiyo hiyo, na root anaweza kufuta nftables kwa urahisi kama unavyoweza kuiandika. Na sudo ip link set enp1s0 down kupitia SSH itakata session yako kwanza, jambo litakalokufungia nje ya mashine uliyokuwa ukiichunguza.

Zuia mawasiliano ya kutoka na ya kuingia. Reverse shell hupiga simu kutoka kwenye seva yako kwenda kwa mshambuliaji, kwa hivyo kuzuia mawasiliano ya kuingia pekee kutaiacha connection iliyoanzishwa ikiendelea kufanya kazi vizuri. Ikiwa mtoa huduma wako anatoa sheria za kuingia pekee, chaguo zilizobaki ni kukata network interface au kuzima instance hiyo.

Usianze kwa kuwasha upya (reboot) seva. Kwanza thibitisha kama /var/log/journal ipo. Ikiwa saraka hiyo haipo, journald inaandika kwenye /run/log/journal, ambayo ipo kwenye kumbukumbu (RAM), kwa hivyo reboot itafuta rekodi ya uvamizi huo. Michakato (processes) inayoendelea pia hupotea wakati wa reboot, na mistari yao ya amri mara nyingi ndiyo ushahidi ulio wazi zaidi utakaoupata.

Piga snapshot ya diski kabla ya kugusa chochote

Snapshot na backup hufanya kazi tofauti katika muktadha huu. Snapshot unayopiga sasa ni nakala ya diski iliyoathiriwa: huu ni ushahidi wako, na ndicho kitu pekee kitakachokuruhusu kurudi nyuma iwapo utafuta kitu kwa bahati mbaya. Backup zako za zamani ndizo njia ya kurejesha mfumo. Ikiwa paneli ya mtoa huduma wako inatumia maneno haya mawili kiholela, soma kwanza jinsi snapshots za VPS zinavyotofautiana na backups halisi, kwa sababu sheria za uhifadhi na tabia ya urejeshaji si sawa.

Piga snapshot kutoka kwenye paneli ya mtoa huduma kabla ya kuingia tena kwenye seva. Snapshot ya moja kwa moja (live snapshot) ni "crash consistent": inachukua hali ya diski kama ilivyokuwa wakati huo, sawa na kukata umeme ghafla. Hii inafaa kwa ajili ya ushahidi. Ipe jina ambalo litazuia mtu yeyote kuirejesha kimakosa. Jina la moja kwa moja kama COMPROMISED-do-not-restore-2026-08-12 ndilo linalofaa. Ihifadhi hadi uchunguzi wako utakapokamilika na tiketi yoyote ya matumizi mabaya (abuse ticket) na mtoa huduma wako ifungwe.

Jinsi ya kuingia wakati SSH haipatikani

Kuna njia mbili, zote zikiwa kwenye paneli ya mtoa huduma wako. Web console (VNC au serial) huunganishwa kwenye mashine kama vile umeunganisha kibodi. Inafanya kazi wakati sshd imekufa, wakati firewall imesanidiwa vibaya, na wakati mshambuliaji amebadilisha port ya SSH. Inathibitisha utambulisho kwa kutumia nenosiri la ndani, kwa hivyo seva inayotumia funguo pekee inaweza kuhitaji kuwekwa upya kwa nenosiri la root kabla ya console kuwa na manufaa.

Rescue mode ndiyo chaguo bora zaidi. Inawasha mfumo mdogo wa live huku diski yako ikiwa imeunganishwa lakini haijawashwa, kwa hivyo amri zako ni za kuaminika: kernel iliyoathiriwa na binaries zilizoathiriwa hazitekelezwi. Mount diski hiyo kwa hali ya kusoma pekee (read-only).

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

Ikiwa lsblk inaonyesha LVM (logical volume manager) volumes badala ya partition ya kawaida, ziamilishe kwanza kwa kutumia sudo vgchange -ay, kisha mount kifaa kinachoonekana chini ya /dev/mapper/.

Usifanye chroot kwenye diski iliyowekwa (mounted) ili kuchunguza. Chroot hutekeleza binaries za mshambuliaji kwa kutumia ruhusa zako, jambo ambalo linabatilisha sababu nzima ya wewe kuwasha rescue mode.

Kusanya ushahidi ambao bado unaaminika

Tekeleza amri hizi ukiwa katika hali ya rescue mode, huku diski ikiwa imewekwa (mounted) kwa kusoma pekee (read-only) kwenye /mnt/victim. Anza na kumbukumbu za kuingia (logins), kwa sababu zinaonyesha muda wa uvamizi, na kila kitu kingine huwa rahisi ukishapata muda huo.

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"

Kukosekana kwa /var/log/auth.log hakumaanishi jambo la kutiliwa shaka. Baadhi ya picha (images) za sasa za Ubuntu haziji na rsyslog, kwa hivyo sshd huandika kumbukumbu kwenye journal pekee, jambo ambalo mstari wa journalctl -D husoma. Jambo la kuzingatia ni pengo katika kumbukumbu ambazo zilipaswa kuwa mfululizo, au faili ya kumbukumbu iliyofutwa na kuwa na ukubwa wa zero bytes. Kufuta kumbukumbu ni jambo la kawaida na mara nyingi hufanywa kizembe.

Ifuatayo ni akaunti na funguo (keys).

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

Mstari wa awk huchapisha kila akaunti yenye user ID 0. Kitu chochote tofauti na root katika matokeo hayo ni akaunti ya pili ya root. Muundo wa find unalinganisha kwa makusudi authorized_keys2 pia, kwa sababu OpenSSH husoma majina yote mawili ya faili kwa chaguomsingi na ile ya pili ni rahisi kusahaulika. Ikiwa lsattr itachapisha i katika orodha ya sifa (attribute list), faili hiyo haiwezi kubadilishwa (immutable): mshambuliaji huweka alama hiyo ili jaribio lako la kufuta ufunguo wao lishindwe kwa Operation not permitted, na msimamizi aliyechoka atadhani kuwa uhariri umefanikiwa.

Uendelevu (persistence) hujificha katika maeneo machache, kwa hivyo yachunguze yote.

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 haipo kwenye mfumo wa kawaida wa Ubuntu au Debian, kwa hivyo No such file or directory ndilo matokeo ya afya na maudhui yoyote yanayopatikana yanastahili umakini wako. Faili ya kuingia (login file) inayoelekeza matokeo ya base64 -d kwenye shell ni hadithi hiyo hiyo: usanidi halali hauhitaji kuficha maandishi yake yenyewe.

Jenga ratiba ya matukio (timeline) kulingana na muda wa mabadiliko (change time) badala ya muda wa kurekebisha (modification time).

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

touch huweka muda wa kurekebisha kuwa thamani yoyote anayotaka mshambuliaji, kwa hivyo mtime hudanganya kwa urahisi. Muda wa mabadiliko (ctime) husasishwa kwa kila mabadiliko kwenye inode, na touch haiwezi kuurudisha nyuma, kwa hivyo -newerct hutoa orodha ya kweli zaidi ya kile kilichoandikwa hivi karibuni. Hii bado si ushahidi kamili, kwa sababu root anaweza kusogeza saa ya mfumo au kuandika moja kwa moja kwenye block device.

Uadilifu wa kifurushi (package integrity) unastahili amri moja na tahadhari moja. Kwenye mfumo unaofanya kazi, sudo dpkg --verify huchapisha mstari kwa kila faili ya kifurushi ambayo checksum yake hailingani tena, ikiwa na 5 kwenye safu ya checksum, na sudo debsums -ac hufanya kazi hiyo hiyo ikijumuisha faili za usanidi wakati kifurushi cha debsums kimesakinishwa. Soma matokeo katika mwelekeo mmoja tu. /usr/sbin/sshd iliyobadilishwa ni ushahidi halisi. Ripoti safi haithibitishi chochote, kwa sababu akaunti hiyo hiyo ya root iliyobadilisha binary inaweza kuandika upya orodha za checksum chini ya /var/lib/dpkg/info/. Vichanganuzi vya rootkit kama rkhunter na chkrootkit hufuata kanuni hiyo hiyo: hit ni taarifa, lakini matokeo safi si kibali cha usalama.

Nakili kile ulichokusanya kutoka kwenye mashine kabla ya kufanya jambo lolote la uharibifu.

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

Andika hash hiyo mahali fulani nje ya seva. Ikiwa jambo hili litageuka kuwa dai la bima au ripoti ya polisi, kuweza kuonyesha kuwa kumbukumbu (archive) haijabadilika tangu ilipokusanywa ndiyo tofauti kati ya ushahidi na folda ya faili tu. Kufuta vitu kwa bahati mbaya wakati wa uchunguzi ni jambo la kawaida, na snapshot pamoja na kumbukumbu hii ndiyo inayofanya hali hiyo iweze kuhimiliki. Kurekebisha rm mbaya baadaye ni vigumu zaidi kuliko watu wanavyotarajia, kama kurejesha faili zilizofutwa kwa rm -rf inavyoeleza.

Tafuta mlango walioutumia kuingia

Ujenzi upya wa seva ambao hauzibi njia ya kuingilia utafanya udukuliwe tena, mara nyingi ndani ya siku chache, kwa sababu skani iliyokupata mara ya kwanza haisimami kamwe. Milango minne inashughulikia sehemu kubwa ya udukuzi wa seva moja.

SSH password login. Mstari wa Accepted password for root kutoka anwani usiyoijua ni jibu tosha. Kagua PasswordAuthentication katika /etc/ssh/sshd_config na katika kila faili iliyo chini ya /etc/ssh/sshd_config.d/. sshd hutumia thamani ya kwanza inayopata kwa ajili ya keyword, na mstari wa Include hukaa juu ya faili kuu kwenye Ubuntu, kwa hivyo faili ya config iliyowekwa kando hushinda kwa siri mpangilio uliouhariri hapo chini.

Huduma iliyochapishwa bila uthibitisho. Redis kwenye 6379, Docker API kwenye 2375, database iliyofungwa kwenye 0.0.0.0 badala ya 127.0.0.1. Docker ndiyo mshangao wa kawaida. Kuchapisha port ya container huingiza sheria za DNAT (destination network address translation) ambazo hupitiwa kabla ya chains za ufw, kwa hivyo ufw status inaweza kuripoti port kuwa imefungwa wakati container iliyo nyuma yake inajibu Internet nzima. Elewa hilo kabla ya ujenzi upya: kwa nini Docker published ports hupita ufw inashughulikia mpangilio wa sheria na suluhisho lake.

Programu ya wavuti isiyofanyiwa viraka. Tafuta log ya ufikiaji wa web server karibu na muda wako wa kwanza wa mashaka kwa ajili ya POST kwenye njia ya kupakia (upload path) au njia ya admin, kisha tafuta faili zilizo chini ya web root zenye muda wa mabadiliko unaolingana. Faili ya PHP iliyopotea kwenye saraka ya uploads ndiyo matokeo ya kawaida.

Credential iliyovuja. Ufunguo (key) uliowekwa kwenye repository, token iliyobandikwa kwenye chat, faili ya .env inayotolewa kama faili tuli na web server iliyosanidiwa vibaya. Uendeshaji otomatiki hufanya hili kuwa rahisi kutokea kwa bahati mbaya, jambo ambalo ni hoja ya kuweka siri nje ya AI agents na faili zao za config.

Ikiwa huwezi kutaja mlango baada ya yote hayo, chukulia kuwa credential imevuja na chukulia kila siri iliyokuwa kwenye mashine hiyo kuwa ya umma.

Badilisha kila kitambulisho ambacho mashine inaweza kuwa imekiona

Badilisha vitambulisho baada ya kukata mtandao, si kabla. Kubadilisha vitambulisho wakati mshambuliaji bado ana muunganisho kunampa tu siri mpya.

• Kila private key ya SSH iliyohifadhiwa kwenye seva, pamoja na kila akaunti nyingine iliyoamini public key inayolingana.
• Ufunguo wowote uliouingiza kwenye mashine kwa kutumia ssh -A. Agent forwarding huacha socket chini ya /tmp, na mtumiaji mwenye root kwenye mashine hiyo anaweza kuitumia kujitambulisha kama wewe popote ufunguo wako unapoaminika, mradi tu session yako iwe wazi.
• API tokens zilizopo kwenye faili za .env, kwenye mistari ya Environment= ya systemd, kwenye usanidi wa CI, na kwenye vitambulisho vya mtoa huduma.
• Nywila za database, na akaunti za programu zinazozitumia.
• Private keys za TLS (transport layer security) ambazo seva ilikuwa nazo. Toa cheti kipya na ufute kile cha zamani.
• Nywila ya akaunti yako ya hosting, huku ukiwa umewasha uthibitishaji wa hatua mbili (two-factor authentication). Paneli hiyo inaweza kujenga upya, kupiga snapshot, na kuingia kwenye kila seva unayomiliki kupitia console, kwa hivyo ndiyo mpaka halisi wa usalama.
• Nywila yoyote iliyoandikwa kwenye shell session kwenye host hiyo wakati ilipokuwa imevamiwa, kwa sababu root anaweza kurekodi session ya terminal wakati inafanyika.

Ikiwa nywila kwenye mashine hiyo inatumiwa mahali pengine popote, ibadilishe huko pia. Kutumia nywila moja sehemu nyingi ndiyo njia inayofanya VPS moja iliyovamiwa kuwa akaunti ya barua pepe iliyovamiwa.

Orodha ya ukaguzi ya kujenga upya

1. Unda seva mpya kutoka kwenye image safi ya distribution. Usitumie snapshot ya seva iliyovamiwa, na usitumie restore ya mfumo mzima wa faili (root filesystem).
2. Sakinisha vifurushi kutoka kwenye repositories za distribution. Usinakili binary yoyote kutoka kwenye diski ya zamani.
3. Rejesha data pekee, kutoka kwenye backup iliyopigwa kabla ya muda wa tukio la kwanza kwenye ratiba yako ya matukio. Hii inajumuisha database dumps, uploads, na hali ya programu. Acha /etc, /usr na faili za zamani za unit nyuma.
4. Ingiza siri (secrets) zilizobadilishwa kwa mkono. Usinakili .env ya zamani.
5. Kagua maudhui ya wavuti yaliyorejeshwa ili kuona faili zilizoongezwa ndani ya kipindi cha uvamizi kabla ya kuyaweka mtandaoni tena.
6. Imarisha usalama kabla ya kuifungua: tumia SSH ya funguo pekee (key-only), akaunti ya kufanyia kazi isiyo ya root, firewall inayokataa kila kitu kwa chaguo-msingi (default-deny), na hakuna huduma inayopaswa kuchapishwa zaidi ya inavyohitajika. Pitia dakika kumi za kwanza kwenye VPS mpya, kisha imarisha SSH ipasavyo, kisha ongeza fail2ban kwenye Ubuntu 24.04 ili kupunguza kelele za majaribio ya kuingia. Ipe kila huduma akaunti yake yenye upendeleo mdogo (least-privilege) ili hatua inayofuata ya mshambuliaji isiwe ya kupata root.
7. Zima seva ya zamani, na uhifadhi snapshot yake hadi uchunguzi na tiketi yoyote ya matumizi mabaya itakapofungwa.
8. Rekebisha backups. Ikiwa hatua ya 3 ilikuwa ya kubahatisha, somo la kweli ni kwamba historia yako ya backup ilikuwa fupi mno kufikia nyuma ya wakati wa uvamizi. Backups za nje ya seva zenye matoleo (versioned) na muda mrefu wa kuhifadhi ndizo zinazokupa uhakika wa restore point safi wakati ujao: restic backups kwenye VPS inakupa vyote viwili.

Ikiwa huwezi kubaini tarehe ya uvamizi, huwezi kuchagua backup salama. Katika hali hiyo, rejesha tu data unayoweza kuikagua kwa macho: SQL dump unayoweza kuisoma, au saraka ya picha unayoweza kuiorodhesha. Ichukulie kila kitu kinachoweza kutekelezwa (executable) kama chenye shaka na ukisakinishe tena kutoka kwenye repositories.

Maana ya notisi ya matumizi mabaya kutoka kwa mtoa huduma wako

Watu wengi hugundua kuwa seva yao imevamiwa kupitia mtoa huduma wao, si kupitia ufuatiliaji wao wenyewe. Watoa huduma huona trafiki inayotoka nje: majaribio ya SSH brute force dhidi ya mitandao mingine, barua pepe taka kwenye port 25, au ushiriki katika reflection attack. Tiketi hiyo kwa kawaida huwa na mihuri ya muda, port, na sampuli ya mtiririko wa data, pamoja na muda wa mwisho uliopimwa kwa saa.

Jibu tiketi hiyo, hata kama jibu lako pekee ni kwamba seva imetengwa na inajengwa upya. Watoa huduma hufunga njia ya trafiki (null-route) au kusimamisha seva wakati tiketi haijajibiwa, jambo ambalo hugeuza tukio lako kuwa kukatika kwa huduma. Kisha omba mistari ya logi ghafi iliyo nyuma ya ripoti hiyo. Mihuri hiyo ya muda ilirekodiwa nje ya mashine yako, kwa hivyo ndiyo sehemu pekee ya muda ambayo mshambuliaji hakuweza kuibadilisha, na mara nyingi huonyesha tarehe ya uvamizi vizuri zaidi kuliko kitu chochote kilicho kwenye diski.

Seva ya mteja iliyovamiwa ni kazi ya kawaida kwa mtoa huduma, na kushughulikia suala hilo vizuri hakutakuletea madhara. Swali pana zaidi la kama VPS hosting ni salama kwa kiasi kikubwa hutegemea kile ambacho mteja anasanidi, ambayo ndiyo sehemu hasa unayopata kufanya tena kuanzia mwanzo.

Wakati wa kumwita mtaalamu

• Seva ilikuwa na data binafsi ya watu wengine. Chini ya GDPR (General Data Protection Regulation), uvunjifu wa data binafsi lazima uripotiwe kwa mamlaka husika bila kuchelewa, na ndani ya saa 72 tangu kugunduliwa kwake pale inapowezekana. Kuhukumu kama muda huo umeanza ni kazi ya kisheria, si kazi ya sysadmin.
• Data ya kadi za malipo ilihusika. Mifumo ya kadi inahitaji mpelelezi wa kitaalamu wa forensics aliyekubaliwa, na kuchunguza kwako mwenyewe kunaweza kuharibu ushahidi.
• Kuna madai ya utapeli (extortion), au data yako imefungwa kwa encryption.
• Mashine hiyo iliweza kufikia mashine nyingine: mtandao wa ndani, hypervisor, au CI runner inayoshikilia credentials za uzalishaji (production). Host mmoja aliyevamiwa katika kundi ni tukio la kundi zima hadi itakapothibitishwa vinginevyo.
• Utahitaji ushahidi huo ili ukubalike kwa bima au vyombo vya sheria. Acha kazi kwenye snapshot, chukua full disk image, na uandike nani aliishughulikia na lini.

Kwa VPS moja inayotumia huduma zako binafsi, bila data ya mtu mwingine yeyote ndani yake, mwongozo uliotajwa hapo juu ndio kazi nzima. Itenge (isolate) kupitia mtoa huduma. Chukua snapshot kwa ajili ya ushahidi. Kusanya kile ambacho bado kinaaminika. Badilisha kila kitu (rotate). Jenga upya kwa usafi.

FAQ

Je, ninaweza kusafisha VPS iliyovamiwa badala ya kuijenga upya?

Huwezi kufanya hivyo kwa uhakika, kwa sababu utakuwa unaiomba mifumo iliyoathiriwa ijitoe ripoti yenyewe. ps iliyobadilishwa inaweza kuficha mchakato, mstari mmoja ndani ya /etc/ld.so.preload unaweza kuingiza msimbo kwenye kila zana inayotumia dynamic linking unayoiendesha, na kernel module inaweza kuficha faili kutoka kwa kila programu kwa wakati mmoja. Unaweza kupata vitu, kwa hivyo matokeo ya "hit" yana maana. Huwezi kuthibitisha kutokuwepo kwa kitu, kwa hivyo matokeo ya "safi" hayana maana. Kusafisha kunaweza kutetewa tu ikiwa seva haina kitu chochote unachokijali na unakubali kuwa inaweza kuvamiwa tena.

Je, nizime seva iliyovamiwa au niache ikiendelea kufanya kazi?

Kata muunganisho wake wa mtandao kupitia mtoa huduma kwanza, kisha iache ikiendelea kufanya kazi kwa muda wa kutosha ili kuchukua snapshot na kuangalia michakato inayofanya kazi. Kuzima seva kunaharibu orodha ya michakato, na kunafuta journal nzima wakati /var/log/journal haipo, kwa sababu journald huandika kwenye kumbukumbu chini ya /run. Izime hata hivyo ikiwa inashambulia mitandao mingine kikamilifu na huna njia ya kuzuia trafiki yake ya kutoka. Kusimamisha madhara ni muhimu zaidi kuliko kuhifadhi ushahidi.

Ninawezaje kujua ni lini mvamizi aliingia?

Tafuta mstari wa kwanza wa Accepted password au Accepted publickey ambao huwezi kuuelezea, ndani ya /var/log/auth.log au kwenye journal. Ulinganishe na orodha ya change-time, find / -xdev -newerct 'YYYY-MM-DD' -type f, kwa sababu ctime ni ngumu kughushi kuliko mtime. Kisha ulinganishe yote mawili na mihuri ya muda (timestamps) iliyo kwenye tiketi ya matumizi mabaya (abuse ticket) kutoka kwa mtoa huduma wako, ambayo ilirekodiwa nje ya mashine na haikuweza kuhaririwa. Chagua backup iliyo ya zamani kuliko tarehe ya kwanza kati ya hizo tatu. Ikiwa hakuna kinacholingana, chukulia kuwa uvamizi ni wa zamani kuliko historia yako ya backup na urejeshe data pekee unayoweza kuikagua.

Je, backups zangu ni salama kurejeshwa baada ya uvamizi?

Data kwa kawaida huwa salama, kwa ukaguzi. Faili za mfumo si salama. Backup iliyochukuliwa baada ya uvamizi ina backdoor, kwa hivyo kurejesha root filesystem nzima kunamrejesha mvamizi pia. Kagua hazina ya backup yenyewe pia: ikiwa vitambulisho vyake vilikuwa vimehifadhiwa kwenye seva iliyovamiwa, historia inaweza kuwa imefutwa au kubadilishwa, jambo ambalo ni hoja ya kutumia target za backup za aina ya append-only au pull-based. Rejesha data ya programu, kisha usakinishe programu tena kutoka kwenye hazina za usambazaji (distribution repositories).

Je, lazima nimwambie mtu yeyote kuwa VPS yangu ilivamiwa?

Jibu kila wakati notisi ya matumizi mabaya (abuse notice) kutoka kwa mtoa huduma wako. Zaidi ya hapo, inategemea ni data ya nani iliyokuwa kwenye mashine hiyo. Data ya kibinafsi ya watu wengine inaweza kusababisha wajibu wa kisheria wa kutoa taarifa, kama vile notisi ya saa 72 ya GDPR kwa mamlaka husika. Ikiwa vitambulisho vya watumiaji vilikuwa vimehifadhiwa kwenye seva, waambie watumiaji hao ili waweze kubadilisha nywila zao kwingineko. Ikiwa funguo (keys) kwenye mashine hiyo ziliruhusu ufikiaji wa mifumo ya wahusika wengine, kama vile code host au akaunti ya wingu, waambie watoa huduma hao ili waweze kukagua matumizi mabaya. Seva ya kibinafsi isiyo na data ya mtu mwingine haina wajibu wowote zaidi ya tiketi ya matumizi mabaya.