Ligtas ba ang VPS Hosting? Mga Risk na Kontrolado Mo

Ligtas ba ang VPS hosting? Ang maikling sagot

Oo. Ligtas ang VPS hosting para sa karaniwang mga gawaing pinagagamit dito ng karamihan, at malaking improvement ito kumpara sa shared hosting. Ang VPS (virtual private server) ay isang virtual machine na may sarili nitong kernel, memory, disk, at user accounts. Pinipigilan ng hypervisor na nagpapatakbo rito ang ibang customer na ma-access ang apat na ito. Hindi mababasa ng taong umuupa ng server na katabi ng sa iyo sa parehong physical machine ang mga file mo, malilista ang mga process mo, makakapag-login sa server mo, o makikita ang network traffic mo.

May dalawang bahagi ang tapat na sagot. Pagmamay-ari ng provider ang hardware at hypervisor. Ikaw ang may kontrol sa lahat ng nasa loob ng virtual machine mo, at dito nagsisimula ang halos lahat ng totoong insidente. Nabibreach ang mga server dahil sa bukas na port, mahinang SSH password, package na hindi na-update, o secret na nailagay sa file na na-publish. Napakadalang nilang ma-breach sa pamamagitan ng hypervisor.

Ang aktuwal na hinihiwalay ng hypervisor

Ang hypervisor ay software na nagpapatakbo ng mga virtual machine sa isang pisikal na host. Sa isang KVM VPS (ang KVM ay nangangahulugang kernel based virtual machine at ito ang karaniwang gamit sa Linux hosts), ang server mo ay isang ganap na virtual machine. Nagbo-boot ito gamit ang sarili nitong kernel. Binibigyan ito ng host ng nakatalagang rehiyon ng physical memory, at pinipigilan ng memory management unit ng processor ang anumang access sa labas ng rehiyong iyon. Dahil dito, hindi maa-access ng code na tumatakbo sa ibang guest ang RAM mo. Walang shared filesystem at walang shared user table, kaya walang epekto sa server mo ang file permissions sa server ng ibang customer.

Iba ang paraan ng shared hosting. Maraming site ang nasa iisang operating system, sa ilalim ng iisang web server at iisang PHP install, bilang mga ordinaryong user account. File permissions lamang ang boundary sa pagitan nila. Kaya maaaring ma-access ang mga file ng ibang account kapag may maling permission setting o may vulnerable plugin na tumatakbo bilang user na may sobrang lawak na read access. Ito ang puwang na sinasara ng paglipat mula shared hosting patungo sa VPS.

Suriin kung ano talaga ang binibili mo, dahil hindi lahat ng plan na ibinebenta bilang VPS ay virtual machine. Ang container based plans (OpenVZ, LXC, Virtuozzo) ay gumagamit ng kernel ng host at naghihiwalay sa mga customer gamit ang namespaces at cgroups sa halip na hardware virtualization. Mas mahina ang boundary na ito, dahil ang kernel bug sa host ay kernel bug din sa server mo. Hindi ka rin makakapag-load ng kernel modules sa mga plan na ito, kaya hindi gagana ang ilang software. Mas ligtas na default ang KVM. Itanong kung alin ang makukuha mo bago magbayad.

Ano ang maaaring idulot sa iyo ng maingay na katabing tenant

Kapag nakikihati ka sa isang physical host, bilis ang kapalit, at iyon lang ang kapalit. Magkakahati ang mga guest sa isang machine sa physical CPU at mga disk. Kapag abala ang CPU dahil ginagamit ito ng ibang customer, naghihintay ang iyong virtual CPU. Iniuulat ng Linux ang paghihintay na ito bilang steal time: ang field na %st sa top at vmstat. Kapag nananatili sa lampas ilang porsyento ang steal time nang maraming oras, nangangahulugan itong overloaded ang host. Hindi ito nangangahulugang may nagbabasa ng iyong data. Ang solusyon ay ibang plan o ibang provider. Maaari mo ring sukatin ang aktuwal na CPU at disk na natanggap mo bago magpasya.

May isang cross-customer effect na dapat mong malaman, at hindi ito security hole. Kung nagpapadala ka ng email mula sa iyong VPS, kabilang ang iyong IP address sa isang range na ginagamit din ng ibang customer. Maaaring mailista sa blocklist ang bahagi ng range na iyon dahil sa spam na ipinapadala ng isang katabing customer. Dahil dito, mapupunta sa spam folder ang iyong mail kahit hindi ikaw ang sanhi. Mas malilinis ang mga range ng mga provider na mahigpit na nagpapatupad ng abuse policies. Itanong ito kung mahalaga sa iyo ang email.

Ano ang hindi magagawa ng isang mapanirang kapwa user, at ang bihirang pagkakataong magagawa niya ito

Walang paraan ang customer na nasa parehong host upang ma-access ang iyong mga file. Hindi niya makikita ang iyong mga process, mai-mount ang iyong disk, o magbukas ng shell sa iyong server, dahil wala sa mga ito sa loob ng kanyang virtual machine. May isang eksepsiyon na dapat tandaan: ituring ang private network ng provider bilang network na pinaghahatian ninyo ng mga hindi kilalang user, at i-encrypt ang dumadaan dito sa halip na ipagpalagay na hindi ito nakikita.

Totoo ang hypervisor escapes. Maaaring payagan ng bug sa virtualization layer ang code sa loob ng isang guest na maabot ang host, at mula sa host ay maabot ang bawat guest dito. Natutuklasan ang mga bug na ito, inilalathala kasama ng CVE (common vulnerabilities and exposures) identifier, at pinapatakan ng patch. Mabilis itong ginagawa ng mga hosting provider dahil nakasalalay ang buong negosyo nila sa layer na iyon. Para magamit ang ganitong bug, kailangan ng gumaganang exploit para sa partikular na bersyon ng hypervisor. Mahal itong gastusan para sa isang maliit na hosting account.

Totoo rin ang cross-guest side channels. Kabilang dito ang pamilya ng Spectre at Meltdown, na gumagamit ng shared processor caches upang mahinuha ang kaunting data sa kabilang boundary. Nakababawas sa epekto ng mga ito ang microcode at kernel updates, at napakaliit ng leak rates sa mga nailathalang pag-aaral. Ang mga nailathalang kaso ay mga research demonstration, hindi malawakang attack. Hindi zero ang risk. Hindi lang ito malapit sa mga pangunahing bagay na malamang na magdulot sa iyo ng pinsala.

Saan nagtatapos ang responsibilidad ng provider at nagsisimula ang sa iyo

Responsibilidad ng provider ang gusali, host hardware, hypervisor at host kernel, physical network, at control panel na maaaring mag-start, mag-stop, mag-rebuild, at gumawa ng snapshot ng iyong server. Kapag may alinman sa mga ito na pumalya, provider ang kailangang mag-ayos nito.

Responsibilidad mo ang lahat mula sa operating system pataas. Kabilang dito ang mga package na ini-install mo, mga port na iniiwan mong bukas, mga account at key na maaaring gamitin sa pag-login, mga update na inilalapat mo, iyong mga backup, at sarili mong application code. Karamihan sa VPS plan ay unmanaged. Ibig sabihin, walang magpa-patch ng server para sa iyo at walang support ticket na awtomatikong gagawa nito. Mahalagang basahin ang Pagkakaiba ng managed at unmanaged bago bumili, dahil dito nakasalalay kung gaano kalaki sa listahang iyon ang magiging responsibilidad mo.

Madaling makalimutan ang isang bahagi ng responsibilidad mo: ang hosting control panel mismo. Ang sinumang may access sa login na iyon ay maaaring mag-rebuild ng server o i-attach ang disk nito sa isang rescue system, kahit hindi niya alam ang anumang password sa loob ng server. I-enable ang two factor authentication (2FA) sa hosting account, at huwag gamitin muli ang password na iyon sa ibang lugar.

Maaari bang makita ng hosting provider ang iyong data?

Oo, sa prinsipyo. Ito ang tapat na limitasyon ng ibinibigay ng VPS. Nasa storage ng provider ang iyong disk image. Nagbibigay ang console nila ng screen-level access sa iyong virtual machine. Maaaring mag-boot ang rescue mode ng ibang system na nakakabit ang iyong disk. Pinoprotektahan ka ng VPS laban sa ibang customer, pero hindi kasama ang provider sa proteksiyong iyon.

Kung may data kang kailangang manatiling hindi mabasa ng host, i-encrypt ito sa application bago ito isulat. Nakakatulong ang full disk encryption sa loob ng guest laban sa nakopyang image habang naka-store ito. Gayunman, kailangang nasa memory ang key habang tumatakbo ang server, kaya hindi nito inaalis ang provider sa usapin ng trust. Pareho rin ang antas ng trust sa dedicated server na ikaw lang ang umuupa, ngunit mas kaunti ang shared layer.

Ano talaga ang pumapasok sa isang VPS

Isang service na nakikinig sa lahat ng interface. Ang mga database, cache, message queue, at admin panel ay madalas naka-bind sa 0.0.0.0 bilang default. Ibig sabihin, naaabot ng mga ito ang bawat network interface, kabilang ang public interface. Tuloy-tuloy at automated ang malawakang pag-scan sa internet, kaya nakakatanggap ang bagong IP address ng unang unsolicited probe nito ilang minuto matapos itong maging online. Ang Redis na walang password, Elasticsearch node na walang authentication, bukas na Docker API sa port 2375, at admin panel na gumagamit pa rin ng default login ay natutuklasan sa ganitong paraan ng scanner na walang alam kung sino ka. I-bind ang service sa 127.0.0.1 kapag local machine lamang ang nangangailangan nito, at i-block ang iba pa sa firewall.

Pag-bypass ng Docker sa firewall. Kapag nag-publish ka ng container port, nagsusulat ito ng network address translation (NAT) rules na sinusuri bago ang mga rule mula sa ufw (uncomplicated firewall). Dahil dito, maaaring maabot mula sa internet ang isang container kahit sinasabi ng ufw status na denied ang port na iyon. Nahuhuli nito ang mga taong tama naman ang lahat ng iba pa nilang configuration. Basahin ang Dahilan kung bakit binabalewala ng Docker port ang ufw bago mag-publish ng container port.

SSH na naka-enable ang mga password. Basahin ang /var/log/auth.log sa anumang public server at makakakita ka ng mga linyang gaya ng Failed password for root from 203.0.113.10 port 54312 ssh2, libo-libong beses, araw at gabi. Sinusubukan ng mga bot ang karaniwang username at password. Ang password login na sinamahan ng root account na tumatanggap ng login ay sapat na para sa isang attacker. Kung keys lamang ang gagamitin at naka-off ang root login, magiging ingay lamang ang traffic na iyon at maaari mo itong balewalain.

Isang private key na ginagamit kahit saan. Kapag kinopya ang isang key sa bawat laptop at bawat server, kayang i-unlock ng isang nanakaw na laptop ang lahat. Hindi rin nag-e-expire ang SSH keys, kaya gagana pa rin ngayon ang key na ibinigay sa isang contractor dalawang taon na ang nakalipas. Walang gastos ang Isang key para sa bawat tao at bawat machine, at nililimitahan nito kung ano ang maaabot ng isang nanakaw na key.

Mga package na walang nag-update. Ang isang published CVE laban sa iyong web server o application framework ay isang pampublikong set ng mga instruction. Nagsisimulang mag-test ang mga scanner para rito sa loob ng ilang araw. Ang security updates ang pinakamurang available na depensa, at maaaring awtomatikong tumakbo ang mga ito: tingnan ang awtomatikong security updates sa Ubuntu.

Isang leaked secret. Nasa .env files ang mga database password at API key. Maaaring ma-commit ang mga file na ito sa isang public repository o ma-serve ng web server na nakaturo sa maling directory. Ang anumang i-paste sa context ng isang AI coding agent ay maaari ring mapunta sa isang log. Hiwalay na paksa ito: pag-iwas na maabot ng agent ang mga secret.

Lahat ay tumatakbo bilang root. Kapag root ang application mo, sapat na ang isang bug dito para mapasakamay nito ang buong machine. Wala nang natitirang boundary sa loob ng server na makapipigil sa pagkalat nito.

Ang bahagi mo sa trabaho

Wala sa mga sumusunod ang gawain sa hypervisor. Lahat ng ito ay nasa panig mo, at ang panig na ito ang nagtatakda kung ligtas ang iyong VPS.

• Gawin nang maayos ang unang oras: tinatalakay sa unang sampung minuto sa bagong VPS ang non-root user at firewall.
• I-lock down ang remote access: pag-hardening ng SSH sa VPS.
• Isara ang mga port na hindi mo ginagamit: mga pangunahing kaalaman sa ufw firewall.
• Bigyan ang bawat serbisyo ng access na kailangan lamang nito: least-privilege users sa VPS.
• Pabagalin ang mga brute-force login: fail2ban sa Ubuntu 24.04.
• Magpanatili ng backup na kahit isang beses mo nang na-restore: restic backups para sa VPS.

Tapos na ang bahagi ng provider bago pa mag-boot ang iyong server. Aabutin ng humigit-kumulang isang oras ang bahagi mo sa unang araw, at ilang minuto bawat buwan pagkatapos nito. Kung naghahambing ka pa ng mga opsyon, tinatalakay sa kung ano talaga ang VPS ang pundasyon ng lahat ng ito.

FAQ

Mababasa ba ng ibang customer na nasa parehong pisikal na server ang mga file ko?

Hindi, kung KVM VPS ang gamit mo. Ang server mo ay isang virtual machine na may sarili nitong kernel at virtual disk, kasama ang isang bahagi ng pisikal na memory na inilaan ng host dito. Hinaharangan ng processor ang anumang access sa labas ng bahaging iyon. Walang shared filesystem sa pagitan ng mga guest, kaya walang saysay sa server mo ang file permissions sa server ng katabing customer. Ang mga container-based plan gaya ng OpenVZ at LXC ay gumagamit ng shared host kernel at may mas mahinang isolation boundary. Tiyakin kung anong uri ng VPS ang bibilhin mo.

Mas ligtas ba ang VPS kaysa shared hosting?

Para sa isolation, oo. Sa shared hosting, maraming site ang tumatakbo sa iisang operating system at file permissions lamang ang boundary. Kaya maaaring mailantad minsan ang mga file dahil sa pagkakamali sa ibang account. Sa VPS, virtual machine ang boundary. Ang kapalit nito ay ang sumusunod: ang host ang nag-a-apply ng patches sa shared hosting, samantalang ikaw ang gumagawa nito sa unmanaged VPS. Mas ligtas lamang ang VPS kung aktuwal mong ina-apply ang mga update at isinasara ang mga port.

Mababasa ba ng hosting provider ko ang data ko?

Sa prinsipyo, oo. Walang VPS product na nagbabago nito. Naka-store ang disk image sa hardware ng provider. Nagbibigay ang console ng screen-level access sa tumatakbong machine. Maaari ring mag-boot ang rescue mode ng ibang system na nakakabit ang disk mo. Kung may data na kailangang manatiling hindi mababasa ng host, i-encrypt ito sa application mo bago isulat. Ang disk encryption sa loob ng guest ay hindi pa rin nag-aalis ng key sa memory habang tumatakbo ang server. Kaya hindi nito inaalis ang provider sa trust model.

Ano ang pinakakaraniwang paraan kung paano nabibreach ang isang VPS?

Exposed service o mahinang SSH login, nang malayong higit sa iba. Patuloy na nagpo-probe ang mga automated scanner sa bawat public IP address. Kaya ang database na naka-bind sa 0.0.0.0 nang walang password, o admin panel na naiwan sa default credentials, ay natutuklasan sa loob ng ilang minuto, hindi buwan. Ipinapakita ng /var/log/auth.log sa anumang public server ang bahagi tungkol sa SSH: paulit-ulit na Failed password for root lines mula sa mga address sa iba't ibang panig ng mundo. May mga hypervisor escape, pero research-grade na mga pag-atake ang mga ito laban sa high-value targets. Hindi sila ang karaniwang sanhi ng mga breach.