क्या VPS hosting सुरक्षित है? सुरक्षा के मुख्य तथ्य

क्या VPS hosting सुरक्षित है? संक्षिप्त उत्तर

हाँ। अधिकांश लोगों के उपयोग के लिए VPS hosting सुरक्षित है, और यह shared hosting की तुलना में एक वास्तविक सुधार है। एक VPS (virtual private server) एक virtual machine है जिसका अपना kernel, अपनी memory, अपनी disk और अपने user accounts होते हैं। इसे चलाने वाला hypervisor अन्य ग्राहकों को इन चारों संसाधनों से दूर रखता है। उसी physical machine पर आपके सर्वर के बगल में सर्वर किराए पर लेने वाला व्यक्ति आपकी files को पढ़ नहीं सकता, आपकी processes की सूची नहीं देख सकता, आपके सर्वर में login नहीं कर सकता और न ही आपके network traffic को देख सकता है।

इस ईमानदार उत्तर के दो पहलू हैं। hardware और hypervisor का स्वामित्व provider के पास होता है। आपकी virtual machine के अंदर की हर चीज़ आपकी है, और लगभग हर वास्तविक सुरक्षा घटना वहीं से शुरू होती है। सर्वर में सेंध किसी खुले port, कमजोर SSH password, किसी ऐसे package जिसे update नहीं किया गया, या किसी file में मौजूद secret के सार्वजनिक हो जाने के कारण लगती है। hypervisor के माध्यम से सर्वर में सेंध लगने की घटनाएं बहुत दुर्लभ हैं।

Hypervisor वास्तव में क्या अलग करता है

Hypervisor वह सॉफ्टवेयर है जो एक physical host पर virtual machines चलाता है। KVM VPS (KVM का अर्थ है kernel based virtual machine, जो Linux hosts पर मानक है) पर आपका सर्वर एक पूर्ण virtual machine होता है। यह अपना स्वयं का kernel boot करता है। Host इसे physical memory का एक निश्चित हिस्सा देता है, और processor की memory management unit उस क्षेत्र के बाहर किसी भी access को अस्वीकार कर देती है, इसलिए किसी अन्य guest में चलने वाला कोड आपकी RAM को बिल्कुल भी address नहीं कर सकता है। इसमें कोई shared filesystem और कोई shared user table नहीं होता है, इसलिए पड़ोसी के सर्वर पर file permissions का आपके सर्वर पर कोई अर्थ नहीं होता है।

Shared hosting अलग तरह से काम करती है। कई साइटें एक ही operating system के भीतर, एक ही web server और एक ही PHP install के अंतर्गत, सामान्य user accounts के रूप में रहती हैं। एकमात्र सीमा file permissions होती है। एक permission की गलती, या बहुत अधिक पढ़ने में सक्षम user के रूप में चलने वाला एक vulnerable plugin, इसलिए किसी अन्य account की files तक पहुँच सकता है। यह वह अंतर है जिसे shared hosting से VPS पर जाना समाप्त करता है।

जाँचें कि आप क्या खरीद रहे हैं, क्योंकि VPS के रूप में बेचा जाने वाला हर plan एक virtual machine नहीं होता है। Container आधारित plans (OpenVZ, LXC, Virtuozzo) host के kernel को साझा करते हैं और hardware virtualization के बजाय namespaces और cgroups के साथ ग्राहकों को अलग करते हैं। यह एक कमजोर सीमा है, क्योंकि host पर एक kernel bug आपके सर्वर में भी एक kernel bug होता है। आप उन plans पर kernel modules भी load नहीं कर सकते हैं, जो कुछ सॉफ्टवेयर के उपयोग को असंभव बना देता है। KVM एक अधिक सुरक्षित विकल्प है। भुगतान करने से पहले पूछें कि आपको कौन सा मिल रहा है।

Noisy neighbour का आप पर क्या प्रभाव पड़ सकता है

एक physical host साझा करने से आपकी गति (speed) प्रभावित होती है, और केवल गति ही वह चीज है जो प्रभावित होती है। एक ही मशीन पर मौजूद सभी guests physical CPU और disks को साझा करते हैं। जब CPU किसी और कार्य में व्यस्त होता है, तो आपका virtual CPU प्रतीक्षा करता है, और Linux इस प्रतीक्षा को steal time के रूप में रिपोर्ट करता है: top और vmstat में %st field। यदि steal time घंटों तक कुछ प्रतिशत से ऊपर रहता है, तो इसका अर्थ है कि host oversubscribed है। इसका यह अर्थ नहीं है कि कोई आपका डेटा पढ़ रहा है। इसका समाधान एक अलग plan या अलग provider है, और आप निर्णय लेने से पहले वास्तव में प्राप्त CPU और disk को माप सकते हैं।

एक cross-customer प्रभाव के बारे में जानना महत्वपूर्ण है, और यह कोई security hole नहीं है। यदि आप अपने VPS से email भेजते हैं, तो आपका IP address एक ऐसी range में होता है जिसे अन्य ग्राहक भी उपयोग करते हैं। कोई पड़ोसी जो spam भेजता है, वह उस range के एक हिस्से को blocklist में डलवा सकता है, जिससे आपके mail spam folders में चले जाते हैं, जिसका कारण आप नहीं होते। जो providers abuse को नियंत्रित करते हैं, उनकी ranges अधिक साफ रहती हैं। यदि email आपके लिए महत्वपूर्ण है, तो इस बारे में पूछें।

एक hostile neighbour क्या नहीं कर सकता, और वह दुर्लभ स्थिति जहाँ वे ऐसा कर सकते हैं

उसी host पर मौजूद किसी अन्य customer के पास आपकी फाइलों तक पहुँचने का कोई रास्ता नहीं होता है। वे आपके processes को नहीं देख सकते, आपकी डिस्क को mount नहीं कर सकते और न ही आपके सर्वर पर shell खोल सकते हैं, क्योंकि इनमें से कोई भी चीज उनके virtual machine के अंदर मौजूद नहीं होती है। एक अपवाद का उल्लेख करना आवश्यक है: किसी भी provider के private network को ऐसा नेटवर्क मानें जिसे आप अजनबियों के साथ साझा करते हैं, और जो डेटा उससे होकर गुजरता है उसे encrypt करें, न कि यह मान लें कि वह अदृश्य है।

Hypervisor escapes वास्तविक हैं। virtualization layer में मौजूद कोई bug किसी guest के अंदर के code को host तक पहुँचने दे सकता है, और host से उस पर मौजूद हर guest तक पहुँचने की अनुमति दे सकता है। ये bugs खोजे जाते हैं, एक CVE (common vulnerabilities and exposures) identifier के साथ प्रकाशित किए जाते हैं और patch कर दिए जाते हैं। hosting providers इन्हें जल्दी patch करते हैं क्योंकि उनका पूरा व्यवसाय इसी layer पर टिका होता है। इनका उपयोग करने के लिए एक विशिष्ट hypervisor version के लिए कार्यशील exploit की आवश्यकता होती है, जो एक छोटे hosting account पर खर्च करने के लिए बहुत महंगी चीज है।

Cross guest side channels भी वास्तविक हैं। ये Spectre और Meltdown परिवार के हैं, और ये एक boundary के पार डेटा की छोटी मात्रा का अनुमान लगाने के लिए shared processor caches का दुरुपयोग करते हैं। Microcode और kernel updates इन्हें कम करते हैं, और प्रकाशित शोध में leak की दरें बहुत कम हैं। प्रकाशित मामले बड़े पैमाने पर हमलों के बजाय शोध प्रदर्शन (research demonstrations) अधिक हैं। जोखिम शून्य नहीं है। यह बस उन चीजों की सूची में सबसे ऊपर कहीं नहीं है जो आपको नुकसान पहुँचा सकती हैं।

प्रदाता की जिम्मेदारी कहाँ समाप्त होती है और आपकी कहाँ शुरू होती है

प्रदाता बिल्डिंग, होस्ट हार्डवेयर, हाइपरवाइजर और होस्ट कर्नल, फिजिकल नेटवर्क, और उस कंट्रोल पैनल के लिए जिम्मेदार है जो आपके सर्वर को स्टार्ट, स्टॉप, रीबिल्ड और स्नैपशॉट कर सकता है। यदि इनमें से कुछ भी विफल होता है, तो उसे ठीक करना उनकी जिम्मेदारी है।

आप अपने ऑपरेटिंग सिस्टम से लेकर ऊपर की हर चीज के लिए जिम्मेदार हैं। इसका मतलब है आपके द्वारा इंस्टॉल किए गए पैकेज, आपके द्वारा खुले छोड़े गए पोर्ट, लॉगिन करने वाले अकाउंट और की (keys), आपके द्वारा लागू किए गए अपडेट, आपके बैकअप और आपका अपना एप्लिकेशन कोड। अधिकांश VPS प्लान अनमैनेज्ड (unmanaged) होते हैं, जिसका अर्थ है कि कोई भी आपके लिए सर्वर को पैच नहीं कर रहा है और कोई सपोर्ट टिकट इसे नहीं करेगा। खरीदने से पहले मैनेज्ड और अनमैनेज्ड का अंतर पढ़ना उचित है, क्योंकि यह तय करता है कि उस सूची का कितना हिस्सा आपकी जिम्मेदारी है।

आपके हिस्से का एक हिस्सा जिसे भूलना आसान है: स्वयं होस्टिंग कंट्रोल पैनल। जिसके पास भी वह लॉगिन है, वह आपके सर्वर के अंदर का पासवर्ड जाने बिना ही आपके सर्वर को रीबिल्ड कर सकता है या आपकी डिस्क को रेस्क्यू सिस्टम से जोड़ सकता है। होस्टिंग अकाउंट पर टू-फैक्टर ऑथेंटिकेशन (2FA) चालू करें, और उस पासवर्ड का उपयोग कहीं और न करें।

क्या आपका होस्टिंग प्रदाता आपका डेटा देख सकता है?

हाँ, सिद्धांत रूप में, और VPS आपको जो सुरक्षा देता है, उसकी यही वास्तविक सीमा है। आपकी डिस्क इमेज प्रदाता के स्टोरेज पर रहती है। उनका कंसोल आपकी वर्चुअल मशीन तक स्क्रीन-लेवल एक्सेस प्रदान करता है। रेस्क्यू मोड आपकी डिस्क को अटैच करके एक अलग सिस्टम बूट कर सकता है। एक VPS आपको अन्य ग्राहकों से सुरक्षित रखता है, लेकिन प्रदाता उस वादे के दायरे से बाहर रहता है।

यदि आपके पास ऐसा डेटा है जिसे होस्ट के लिए अपठनीय रहना चाहिए, तो उसे लिखे जाने से पहले अपने एप्लिकेशन में एन्क्रिप्ट करें। गेस्ट के भीतर फुल डिस्क एन्क्रिप्शन रेस्ट पर मौजूद कॉपी की गई इमेज के खिलाफ मदद करता है, लेकिन सर्वर चलते समय कुंजी (key) को मेमोरी में रहना पड़ता है, इसलिए यह प्रदाता को पूरी तरह से बाहर नहीं करता है। यही विश्वास आपके द्वारा अकेले किराए पर लिए गए डेडिकेटेड सर्वर पर भी लागू होता है, बस इसमें एक साझा परत कम होती है।

VPS में सेंध कैसे लगती है

हर interface पर listen करने वाली service. Databases, caches, message queues और admin panels अक्सर डिफ़ॉल्ट रूप से 0.0.0.0 पर bind होते हैं, जिसका अर्थ है कि वे हर network interface पर उपलब्ध हैं, जिसमें public interface भी शामिल है। इंटरनेट पर स्कैनिंग निरंतर और स्वचालित होती है, इसलिए एक नए IP address के ऑनलाइन आते ही कुछ ही मिनटों में उस पर अनचाही probes आने लगती हैं। बिना password वाला Redis, बिना authentication वाला Elasticsearch node, port 2375 पर खुला Docker API और डिफ़ॉल्ट login का उपयोग करने वाला admin panel, ये सब इसी तरह खोजे जाते हैं। ऐसे scanners को यह नहीं पता होता कि आप कौन हैं। जब केवल local machine को इसकी आवश्यकता हो, तो service को 127.0.0.1 पर bind करें और बाकी को firewall पर block कर दें।

Docker का आपके firewall को दरकिनार करना. Container port publish करने पर network address translation (NAT) rules लिखे जाते हैं, जिन्हें ufw (uncomplicated firewall) के नियमों से पहले evaluate किया जाता है। इसलिए, एक container इंटरनेट से पहुँच योग्य हो सकता है, जबकि ufw status यह कहता है कि वह port denied है। यह उन लोगों के लिए समस्या बनता है जिन्होंने बाकी सब कुछ सही किया होता है। Docker port के ufw को अनदेखा करने का कारण को container port publish करने से पहले पढ़ना उपयोगी है।

Passwords के साथ SSH का उपयोग. किसी भी public server पर /var/log/auth.log को पढ़ें, आपको Failed password for root from 203.0.113.10 port 54312 ssh2 जैसी लाइनें दिन-रात हजारों की संख्या में मिलेंगी। Bots सामान्य usernames और passwords के जरिए प्रयास करते रहते हैं। Password login और root account का login स्वीकार करना, एक हमलावर के लिए पर्याप्त है। केवल keys का उपयोग करें और root login बंद रखें, इससे यह traffic केवल शोर बनकर रह जाएगा जिसे आप अनदेखा कर सकते हैं।

हर जगह एक ही private key का उपयोग. हर laptop और server पर एक ही key कॉपी करने का मतलब है कि एक चोरी हुआ laptop सब कुछ खोल सकता है। SSH keys की कोई expiry नहीं होती, इसलिए दो साल पहले किसी contractor को दी गई key आज भी काम करती है। प्रति व्यक्ति और प्रति मशीन एक key का उपयोग करने में कोई खर्च नहीं आता और यह एक चोरी हुई key की पहुँच को सीमित कर देता है।

ऐसे packages जिन्हें अपडेट नहीं किया गया. आपके web server या application framework के खिलाफ जारी किया गया कोई भी CVE सार्वजनिक निर्देशों का एक सेट होता है, और scanners कुछ ही दिनों में उनका परीक्षण शुरू कर देते हैं। Security updates सबसे सस्ता बचाव हैं, और वे अपने आप चल सकते हैं: देखें Ubuntu पर स्वचालित security updates।

Secret का लीक होना. Database passwords और API keys .env फाइलों में रहते हैं, और ये फाइलें public repository में commit हो जाती हैं, या गलत directory की ओर इशारा करने वाले web server द्वारा serve कर दी जाती हैं। AI coding agent के context में पेस्ट की गई कोई भी चीज़ log में भी जा सकती है, जो अपने आप में एक अलग विषय है: secrets को agent की पहुँच से दूर रखना।

सब कुछ root के रूप में चलना. जब आपका application root के रूप में चलता है, तो उसमें मौजूद एक bug पूरी मशीन को खतरे में डाल देता है, क्योंकि सर्वर के भीतर इसे फैलने से रोकने के लिए कोई सीमा नहीं बचती।

आपकी जिम्मेदारी का हिस्सा

निम्नलिखित में से कोई भी कार्य हाइपरवाइजर (hypervisor) का नहीं है। यह सब आपकी जिम्मेदारी के दायरे में आता है, और यही वह पक्ष है जो यह तय करता है कि आपका VPS सुरक्षित है या नहीं।

• पहले घंटे का काम सही ढंग से करें: नए VPS पर शुरुआती दस मिनट में एक non-root user बनाने और firewall सेट करने की जानकारी दी गई है।
• रिमोट एक्सेस को सुरक्षित करें: VPS पर SSH को सुरक्षित (harden) करना।
• उन ports को बंद करें जिनका आप उपयोग नहीं कर रहे हैं: ufw firewall की बुनियादी जानकारी।
• प्रत्येक service को केवल उतनी ही एक्सेस दें जितनी उसे आवश्यकता है: VPS पर न्यूनतम विशेषाधिकार (least privilege) वाले users।
• Brute force लॉगिन की गति धीमी करें: Ubuntu 24.04 पर fail2ban।
• ऐसा बैकअप रखें जिसे आपने कम से कम एक बार restore करके देखा हो: VPS के लिए restic बैकअप।

प्रदाता (provider) का आधा काम तब पूरा हो जाता है जब आपका सर्वर बूट होता है। आपका आधा काम पहले दिन लगभग एक घंटे का होता है और उसके बाद हर महीने कुछ मिनट का। यदि आप अभी भी विकल्पों की तुलना कर रहे हैं, तो VPS वास्तव में क्या है लेख में इन सभी विषयों का आधार समझाया गया है।

FAQ

क्या उसी physical server पर कोई अन्य ग्राहक मेरी फाइलें पढ़ सकता है?

नहीं, KVM VPS पर ऐसा नहीं है। आपका सर्वर एक virtual machine है जिसका अपना kernel और अपनी virtual disk होती है। इसके अलावा, host उसे physical memory का एक हिस्सा आवंटित करता है और processor उस क्षेत्र के बाहर किसी भी पहुँच को रोकता है। guests के बीच कोई shared filesystem नहीं होता, इसलिए पड़ोसी सर्वर के अंदर मौजूद file permissions का आपके सर्वर के भीतर कोई अर्थ नहीं है। OpenVZ और LXC जैसे container-आधारित plans host kernel को साझा करते हैं और उनमें boundary कमजोर होती है, इसलिए जाँच लें कि आप किस प्रकार का plan खरीद रहे हैं।

क्या VPS, shared hosting से अधिक सुरक्षित है?

isolation के मामले में, हाँ। shared hosting पर कई sites एक ही operating system के भीतर चलती हैं और एकमात्र boundary file permissions होती है, इसलिए किसी अन्य account में हुई गलती कभी-कभी आपकी फाइलें उजागर कर सकती है। VPS पर boundary एक virtual machine होती है। इसका दूसरा पहलू यह है कि shared hosting को host द्वारा patch किया जाता है, जबकि unmanaged VPS को आपको स्वयं patch करना पड़ता है। VPS तभी अधिक सुरक्षित है यदि आप वास्तव में updates लागू करते हैं और अनावश्यक ports बंद रखते हैं।

क्या मेरा hosting provider मेरा डेटा पढ़ सकता है?

सिद्धांत रूप में हाँ, और कोई भी VPS product इसे नहीं बदलता। disk image provider के hardware पर संग्रहीत होती है, console चलती हुई machine तक screen-level access देता है, और rescue mode आपकी disk को attach करके एक अलग system boot कर सकता है। यदि कुछ डेटा को host के लिए अपठनीय रखना आवश्यक है, तो उसे लिखने से पहले अपने application में encrypt करें। guest के भीतर disk encryption भी सर्वर चलने के दौरान key को memory में ही रखता है, इसलिए यह provider को trust के दायरे से बाहर नहीं करता।

VPS के compromised होने का सबसे सामान्य तरीका क्या है?

एक exposed service या कमजोर SSH login, सबसे बड़ा कारण है। automated scanners लगातार हर public IP address की जाँच करते रहते हैं, इसलिए बिना password के 0.0.0.0 पर bound database, या default credentials पर छोड़ा गया admin panel महीनों के बजाय मिनटों में खोज लिया जाता है। किसी भी public server पर /var/log/auth.log इसका SSH वाला हिस्सा दिखाता है: दुनिया भर के addresses से बार-बार आने वाली Failed password for root lines। Hypervisor escapes मौजूद हैं, लेकिन वे उच्च-मूल्य वाले लक्ष्यों के लिए किए गए शोध-स्तर के कार्य हैं, न कि सामान्य breaches का कारण।