सेल्फ़-होस्टिंग प्राइवेसी चेकलिस्ट

Guides · 9 मिनट रीड

संक्षिप्त उत्तर: एक ठोस self-hosting privacy checklist तीन परतों को कवर करती है: कौन अकाउंट को वापस आप तक ट्रेस कर सकता है, सर्वर खुद हमले का कितना अच्छा प्रतिरोध करता है, और चलने के बाद आपके ऐप्लिकेशन क्या लीक करते हैं। व्यवहार में इसका मतलब है गुमनाम साइनअप और क्रिप्टो भुगतान, फ़ायरवॉल और fail2ban के साथ केवल SSH की-आधारित एक्सेस, फुल-डिस्क एन्क्रिप्शन या एन्क्रिप्टेड वॉल्यूम, न्यूनतम लॉगिंग, और सिर्फ़ लॉन्च पर एक बार के बजाय एक बार-बार होने वाले शेड्यूल पर जांची गई अनुशासित बैकअप व अपडेट आदतें।

एक चेकलिस्ट एकबारगी सेटअप से बेहतर क्यों है

ज़्यादातर सेल्फ़-होस्टिंग प्राइवेसी विफलताएं नाटकीय नहीं होतीं। ये छोटी, संचयी दरारें हैं: एक लॉग फ़ाइल जो चुपचाप महीनों तक IP एड्रेस बनाए रखती है, एक डिफ़ॉल्ट SSH पोर्ट जो खुला छूट गया क्योंकि इसे घुमाना ज़रूरी नहीं लगा, एक बैकअप स्नैपशॉट जो किसी लैपटॉप पर अनएन्क्रिप्टेड सहेजा गया, एक WHOIS रिकॉर्ड जो अब भी असली नाम की ओर इशारा करता है। इनमें से कोई भी अपने-आप में जल्दबाज़ी वाला नहीं दिखता, और यही वजह है कि ये टिके रहते हैं।

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

निजता की मज़बूती को लॉन्च-डे का काम नहीं, बल्कि रखरखाव मानें
हर नई सेवा, पैकेज, या कॉन्फ़िग बदलाव के बाद सूची को दोबारा जांचें
जब तक सत्यापित न कर लें, मान लें कि डिफ़ॉल्ट अनुमति देने वाले हैं

परत एक: अकाउंट को कौन ट्रेस कर सकता है

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

इसी वजह से गुमनाम साइनअप फ़्लो मौजूद हैं। उदाहरण के लिए, VPS GOAT साइनअप पर ईमेल या पहचान दस्तावेज़ एकत्र करने के बजाय एक अकेली हैश की गई अकाउंट-की जारी करता है, ठीक उसी Mullvad-शैली पैटर्न में जो निजता-केंद्रित VPN प्रोवाइडरों द्वारा इस्तेमाल होता है, और भुगतान केवल Paymento के ज़रिए क्रिप्टोकरेंसी में तय करता है, जिसमें इसके लेन-देन-स्तरीय निजता के लिए Monero को Bitcoin, USDT, Litecoin, Ethereum और Tron के साथ अनुशंसित किया जाता है। आप जो भी प्रोवाइडर इस्तेमाल करें, वही सवाल पूछें: साइनअप कौन-सा पहचान डेटा इकट्ठा करता है, भुगतान क्या उजागर करता है, और अगर प्रोवाइडर को उजागर करने के लिए मजबूर किया जाए तो उस डेटा का क्या होता है।

एक गुमनाम अकाउंट-की या छद्मनामी ईमेल इस्तेमाल करें, कभी भी अपनी असली पहचान से जुड़ा व्यक्तिगत ईमेल नहीं
अपने नाम से जुड़े कार्ड के बजाय निजता-सम्मान करने वाली क्रिप्टोकरेंसी से भुगतान करें
किसी गुमनाम प्रोजेक्ट और व्यक्तिगत प्रोजेक्ट में यूज़रनेम, PGP की, या SSH की फ़िंगरप्रिंट दोहराने से बचें
साइन अप करने से पहले जांचें कि प्रोवाइडर का अकाउंट क्रिएशन फ़्लो असल में क्या सहेजता है, बाद में नहीं

परत दो: OS स्तर पर VPS को कैसे सुरक्षित करें

एक बार अकाउंट साफ़ हो जाए, तो अगली परत ऑपरेटिंग सिस्टम खुद है। VPS को सुरक्षित करना उन हर एक्सेस पथ को हटाने से शुरू होता है जिनकी आपको स्पष्ट रूप से ज़रूरत नहीं, फिर जिन्हें आप रखते हैं उन्हें लॉक डाउन करने से। यही चेकलिस्ट का वह हिस्सा है जो सबसे सीधे तौर पर तय करता है कि क्या कोई अवसरवादी स्कैनर पैर जमा सकता है।

लगभग हर ऑटोमेटेड हमले का पहला लक्ष्य SSH होता है, इसलिए इसे सबसे ज़्यादा ध्यान चाहिए। पासवर्ड ऑथेंटिकेशन पूरी तरह बंद करें और की-पेयर पर निर्भर रहें, आदर्श रूप से स्थानीय रूप से जनरेट की गई और कहीं भी अपलोड न की गई Ed25519 की। SSH को पोर्ट 22 से हटाना सिर्फ़ एक मामूली शोर-कम करने वाला उपाय मानें, कोई असली सुरक्षा नियंत्रण नहीं, और इसे ऑटोमेटेड ब्रूट-फ़ोर्स प्रयासों को स्वचालित रूप से रोकने के लिए fail2ban या समान टूल के साथ जोड़ें।

SSH पर रूट लॉगिन बंद करें और पासवर्ड ऑथेंटिकेशन बंद करें, केवल की-आधारित एक्सेस
डिफ़ॉल्ट-डिनाई इनबाउंड नीति और स्पष्ट अनुमति नियमों के साथ फ़ायरवॉल (ufw, nftables, या iptables) लागू करें
बार-बार असफल लॉगिन प्रयासों को अपने-आप ब्लॉक करने के लिए fail2ban या crowdsec इंस्टॉल करें
एक शेड्यूल पर सुरक्षा अपडेट लागू करें; Debian और Ubuntu के लिए unattended-upgrades यह अपने-आप संभालता है
रोज़मर्रा के प्रशासन के लिए एक नॉन-रूट सुडो यूज़र बनाएं और असाधारण मामलों के लिए रूट सुरक्षित रखें
बिना इस्तेमाल की सेवाएं बंद करें और किसी भी सक्रिय रूप से चल रही सेवा से न जुड़ा पोर्ट बंद करें

परत तीन: सर्वर को सिर्फ़ सुरक्षा के लिए नहीं, निजता के लिए मज़बूत करें

सुरक्षा और निजता ओवरलैप करते हैं लेकिन एक जैसे नहीं हैं। कोई सर्वर तोड़ना मुश्किल हो सकता है फिर भी वह हर विज़िटर का IP एड्रेस एक साल तक प्लेनटेक्स्ट में लॉग करता रह सकता है, जो एक निजता विफलता है भले ही यह कोई सुरक्षा भंग न हो। किसी सर्वर को निजता के लिए मज़बूत करने का मतलब है मानक सुरक्षा आधार के ऊपर सक्रिय रूप से यह कम करना कि वह क्या रिकॉर्ड और सुरक्षित रखता है।

फुल-डिस्क एन्क्रिप्शन (Linux पर LUKS) डेटा को आराम में सुरक्षित रखता है अगर कोई भौतिक ड्राइव कभी ज़ब्त कर ली जाए या कोई स्नैपशॉट बिना अनुमति कॉपी कर लिया जाए; VPS GOAT की योजनाएं डिफ़ॉल्ट रूप से एन्क्रिप्टेड NVMe स्टोरेज पर चलती हैं, जो इन्फ्रास्ट्रक्चर स्तर पर हार्डवेयर परत को कवर करता है, लेकिन आपकी अपनी डिस्क एन्क्रिप्शन और ऐप्लिकेशन-स्तरीय लॉग अनुशासन गेस्ट OS के भीतर आपके नियंत्रण वाली चीज़ों के लिए अब भी मायने रखता है। एन्क्रिप्शन से परे, हर सेवा के डिफ़ॉल्ट लॉगिंग व्यवहार की समीक्षा करें: वेब सर्वर, मेल सर्वर, और यहां तक कि शेल हिस्ट्री भी ज़रूरत से कहीं ज़्यादा लंबे समय तक IP एड्रेस, टाइमस्टैम्प, और क्वेरी स्ट्रिंग रख सकती हैं।

समय समन्वय और DNS विकल्प भी मायने रखते हैं। ग़लत टाइमज़ोन वाला सर्वर या हर लुकअप को आपके इन्फ्रास्ट्रक्चर तक वापस लॉग करने वाला DNS रिसॉल्वर मेटाडेटा निशान बनाता है जिन्हें नज़रअंदाज़ करना आसान है क्योंकि ये रोज़मर्रा के इस्तेमाल में अदृश्य होते हैं।

गेस्ट OS के भीतर LUKS या समकक्ष फुल-डिस्क एन्क्रिप्शन से डेटा को आराम में एन्क्रिप्ट करें
nginx, Apache, और ऐप्लिकेशन सर्वर में विस्तृत एक्सेस लॉग को छोटा या बंद करें जहां रिटेंशन ज़रूरी नहीं है
लॉग को अनिश्चित काल तक जमा होने देने के बजाय आक्रामक रूप से रोटेट और समाप्त करें (कम रिटेंशन के साथ logrotate)
आपके एक्सेस ISP के डिफ़ॉल्ट के बजाय DNS-over-TLS या DNS-over-HTTPS पर निजता-सम्मान करने वाला DNS रिसॉल्वर इस्तेमाल करें
संवेदनशील कमांड की शेल हिस्ट्री साफ़ करें और सीक्रेट छूने वाले ऑटोमेशन स्क्रिप्ट के लिए bash हिस्ट्री बंद करें
NTP को अपने भौतिक स्थान से जुड़े स्रोत के बजाय किसी तटस्थ समय स्रोत पर सेट करें

बैकअप, स्नैपशॉट, और रिकवरी का जाल

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

समाधान यह है कि बैकअप एन्क्रिप्शन को लाइव डिस्क जितनी ही गंभीरता से लिया जाए। restic या borg जैसे टूल का इस्तेमाल करते हुए, एक मज़बूत पासफ़्रेज़ जो ऑफ़लाइन सहेजा गया हो, के साथ बैकअप आर्काइव को सर्वर छोड़ने से पहले क्लाइंट-साइड एन्क्रिप्ट करें, ताकि भले ही कोई बैकअप डेस्टिनेशन समझौता हो जाए, अंदर का डेटा अपठनीय बना रहे। अगर आपका प्रोवाइडर बिल्ट-इन स्नैपशॉट देता है, तो समझें कि वे कहां सहेजे जाते हैं और क्या वे सोर्स वॉल्यूम जैसा ही एन्क्रिप्शन विरासत में पाते हैं।

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

आखिर में जांचने लायक ऐप्लिकेशन-स्तरीय रिसाव

अकाउंट, OS, और बैकअप कवर हो जाने के बाद, आखिरी परत वे ऐप्लिकेशन हैं जिन्हें आप वाकई चलाते हैं। यहीं पर निजता की मज़बूती ऐप्लिकेशन-विशिष्ट हो जाती है: एक सेल्फ़-होस्टेड ईमेल सर्वर, एक स्टैटिक ब्लॉग, और एक Tor हिडन सर्विस, हर एक का रिसाव सतह अलग होता है, लेकिन कुछ जांच लगभग सार्वभौमिक रूप से लागू होती हैं।

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

प्रकाशित करने से पहले किसी भी फ़ाइल या इमेज से EXIF और मेटाडेटा हटाएं
विस्तृत सर्वर हेडर (Server, X-Powered-By) दबाएं और प्रोडक्शन में विस्तृत एरर पेज बंद करें
किसी भी कॉन्टैक्ट फ़ॉर्म या कमेंट सिस्टम की समीक्षा करें कि आपने अनजाने में कहीं IP लॉगिंग तो सक्षम नहीं कर दी
अगर क्लियरनेट साइट के साथ Tor हिडन सर्विस दे रहे हैं, तो पुष्टि करें कि दोनों TLS सर्टिफिकेट या एनालिटिक्स स्क्रिप्ट जैसी पहचान-योग्य संपत्तियां साझा नहीं करते

परत के अनुसार सेल्फ़-होस्टिंग प्राइवेसी चेकलिस्ट
परत	क्या जांचें	आम टूल या सेटिंग
अकाउंट	साइनअप पहचान, भुगतान निशान	गुमनाम अकाउंट-की, Paymento के ज़रिए Monero
एक्सेस	SSH एक्सपोज़र, ब्रूट-फ़ोर्स जोखिम	केवल की-आधारित SSH, fail2ban, डिफ़ॉल्ट-डिनाई फ़ायरवॉल
स्टोरेज	अगर डिस्क या स्नैपशॉट कॉपी हो तो आराम में डेटा	LUKS फुल-डिस्क एन्क्रिप्शन, एन्क्रिप्टेड NVMe
लॉग	IP और टाइमस्टैम्प का रिटेंशन	कम रिटेंशन वाला logrotate, न्यूनतम एक्सेस लॉग
बैकअप	अगर बैकअप डेस्टिनेशन भंग हो तो एक्सपोज़र	restic या borg से क्लाइंट-साइड एन्क्रिप्शन
ऐप्लिकेशन	मेटाडेटा और हेडर रिसाव	EXIF हटाना, दबाए गए सर्वर हेडर

सामान्य प्रश्न

निजता के लिए VPS को सुरक्षित करने का सबसे महत्वपूर्ण कदम क्या है?+

की-आधारित SSH एक्सेस को डिफ़ॉल्ट-डिनाई फ़ायरवॉल के साथ जोड़ना नए सर्वर के खिलाफ़ ज़्यादातर ऑटोमेटेड हमलों को रोकता है, इसलिए यह आमतौर पर सबसे प्रभावी पहला कदम है। गुमनाम साइनअप भी उतना ही मायने रखता है लेकिन सर्वर के मौजूद होने से पहले ही हो जाता है, इसलिए दोनों वाकई पहले नंबर के लिए बराबर हैं।

अगर प्रोवाइडर पहले से स्टोरेज एन्क्रिप्ट करता है तो क्या फुल-डिस्क एन्क्रिप्शन ज़रूरी है?+

प्रोवाइडर-साइड एन्क्रिप्शन, जैसे VPS GOAT पर एन्क्रिप्टेड NVMe, भौतिक हार्डवेयर परत की रक्षा करता है, लेकिन गेस्ट-स्तरीय डिस्क एन्क्रिप्शन (LUKS) डेटा की रक्षा करता है अगर कोई ऑपरेटिंग सिस्टम के अंदर एक्सेस पा ले या कोई स्नैपशॉट कॉपी कर ले। दोनों चलाना दोहराव नहीं है; वे अलग-अलग थ्रेट परिदृश्यों को कवर करते हैं।

self hosting privacy checklist को कितनी बार चलाना चाहिए?+

किसी भी सार्थक बदलाव के बाद इसे दोबारा जांचें, जैसे कोई नई सेवा इंस्टॉल करना या पोर्ट खोलना, और चाहे कुछ बदला हो या न हो, कम से कम हर महीने पूरी जांच करें। कॉन्फ़िगरेशन धीरे-धीरे बदलता है, इसलिए दुर्लभ समीक्षा ही मुख्य वजह है जिससे छोटी दरारें नज़रअंदाज़ रह जाती हैं।

क्या निजता के लिए सर्वर को मज़बूत करने से यह धीमा हो जाता है?+

यहां दिए गए ज़्यादातर कदमों, जैसे की-आधारित SSH, फ़ायरवॉल नियम, और लॉग रोटेशन, का प्रदर्शन पर नगण्य असर होता है। फुल-डिस्क एन्क्रिप्शन थोड़ा CPU ओवरहेड जोड़ता है, लेकिन AES-NI त्वरण वाले आधुनिक हार्डवेयर पर यह सामान्य सेल्फ़-होस्टिंग वर्कलोड के लिए शायद ही ध्यान देने योग्य हो।

क्या मैं इस चेकलिस्ट को किसी भी VPS प्रोवाइडर पर, या केवल किसी निजता-केंद्रित प्रोवाइडर पर लागू कर सकता हूं?+

OS और ऐप्लिकेशन मज़बूती के कदम किसी भी प्रोवाइडर के VPS पर लागू होते हैं। अकाउंट-स्तरीय कदम, जैसे गुमनाम साइनअप और केवल-क्रिप्टो भुगतान, इस पर निर्भर करते हैं कि प्रोवाइडर उन्हें सपोर्ट करता है या नहीं, और यहीं VPS GOAT जैसा निजता-प्राथमिक होस्ट किसी मुख्यधारा के होस्ट से अलग है जिसे शुरू में ही ID और कार्ड विवरण चाहिए होते हैं।

ऑफशोर जाने के लिए तैयार हैं?

कोई KYC नहीं, कोई ईमेल नहीं — बस एक अनाम की और क्रिप्टो। ~55 सेकंड में डिप्लॉय करें।

अपना VPS कॉन्फ़िगर करें →