ओरिजिन सर्वर IP छुपाना

"क्या मुझे इसके आगे CDN लगाना चाहिए?" — ऑफ़शोर सर्वर ख़रीदने के बाद ज़्यादातर लोग यही पहला सवाल पूछते हैं, और इसका कोई एक जवाब नहीं है, क्योंकि असल में यह एक ही कोट पहने दो सवाल हैं। किसी हमले को झेलना और अनदेखा-अनजान बने रहना दो अलग समस्याएँ हैं जिनके हल भी अलग हैं, और जो व्यवस्था एक को हल करती है, वह चुपचाप दूसरी को बिगाड़ सकती है।

यह उलझन दोनों दिशाओं में महँगी पड़ती है। लोग एक बड़ा अमेरिकी CDN उस कंटेंट के आगे लगा देते हैं जिसके लिए उन्होंने DMCA-ignored होस्टिंग चुनी थी, और ठीक उसी तरह के बिचौलिये को वापस एक शिकायत डेस्क सौंप देते हैं जिससे वे बचना चाहते थे। कुछ लोग सब कुछ छोड़ देते हैं, एक ऐसे एप्लिकेशन-लेयर फ्लड की चपेट में आ जाते हैं जिसे देखने के लिए नेटवर्क फ़िल्टरिंग कभी बनाई ही नहीं गई थी, और यह मान लेते हैं कि DDoS प्रोटेक्शन एक झूठ था। यह गाइड इन दोनों समस्याओं को अलग करती है, बताती है कि हर लेयर असल में क्या करती है, और अपनी ज़्यादातर लंबाई उस हिस्से पर ख़र्च करती है जो हर हाल में नतीजा तय करता है: वे छह तरीके जिनसे बाक़ी सब कुछ सही तरह से कॉन्फ़िगर होने पर भी एक ओरिजिन पता लीक हो जाता है।

एक जैसी दिखने वाली दो समस्याएँ

सर्वर के आगे आप जो भी लगाते हैं, वह दो में से एक काम कर रहा होता है: हमले को उससे दूर रखना, या उसका पता अनजान बनाए रखना। ये दोनों इतने ओवरलैप करते हैं कि उलझ जाएँ, और इतने अलग हैं कि ग़लत वाला हल करना पैसे की बर्बादी बन जाए।

आख़िरी पंक्ति को दो बार पढ़ें, क्योंकि यही वह है जो लोगों को फँसाती है। इस पेज पर बाक़ी सब कुछ इंजीनियरिंग है। वह पंक्ति नहीं है।

आपका होस्ट पहले से क्या करता है, और कहाँ रुक जाता है

लेयर 3 और लेयर 4 फ़िल्टरिंग हमारे बेचे हर प्लान में शामिल है, बिना किसी अतिरिक्त लागत के, और यह आपके सर्वर पर नहीं बल्कि नेटवर्क एज पर चलती है — यही एकमात्र जगह है जहाँ यह काम कर सकती है, क्योंकि भरा हुआ अपलिंक उसके पीछे चल रही किसी भी चीज़ से ठीक नहीं किया जा सकता। बैंडविड्थ अनमीटर्ड है, इसलिए कोई हमला बिल में नहीं बदलता। जिसे ज़्यादातर लोग "एक DDoS" कहते हैं, उसके बड़े हिस्से के लिए यही पूरी कहानी है।

जो यह नहीं देख सकता, वह दूसरी क़िस्म है। चालीस हज़ार रेज़िडेंशियल पतों से किसी सर्च एंडपॉइंट पर पाँच सौ रिक्वेस्ट प्रति सेकंड, बिगड़ा हुआ ट्रैफ़िक नहीं है; वह ट्रैफ़िक है। Slowloris कनेक्शन जो हर कुछ सेकंड में एक हेडर टपकाते हैं, अकेले में शिष्ट होते हैं। असली POST बॉडी से पीटा गया एक लॉगिन फ़ॉर्म, पैकेट स्तर पर एक व्यस्त सोमवार से अलग नहीं दिखता। कोई पैकेट फ़िल्टर मदद नहीं करता, क्योंकि पैकेट में कुछ भी ग़लत नहीं है।

ट्रैफ़िक की एक दिशा है जिस पर हम कार्रवाई करते हैं, और इसे साफ़ कहना बनता है: हमारे नेटवर्क से निकलने वाले हमले और थोक स्पैम को बाक़ी इन्फ्रास्ट्रक्चर को सेहतमंद रखने के लिए नल-रूट किया जा सकता है। यह एक परिचालन क़दम है, कंटेंट संबंधी नहीं — यही फ़र्क़ हमारी DMCA-ignored होस्टिंग गाइड ज़्यादा तफ़सील से बताती है।

CDN क्या छुपाता है, और आपको साथ में कौन-सी शिकायत डेस्क विरासत में मिलती है

यह तरीक़ा सरल है और वाक़ई असरदार है। आपका डोमेन प्रोवाइडर के पतों पर रिज़ॉल्व होता है, क्लाइंट वहीं कनेक्ट करते हैं, और प्रोवाइडर आपके ओरिजिन से डेटा लाता है। असली पता किसी क्लाइंट के कनेक्शन में कभी दिखता ही नहीं, इसलिए सिर्फ़ डोमेन जानने वाला कोई भी उस पर हमला नहीं कर सकता। यही तरकीब है जिसकी वजह से सेंसरशिप-प्रतिरोधी प्रॉक्सी के लिए CDN फ़्रंटिंग काम करती है: सेंसर को ऐसे पते पर जाता ट्रैफ़िक दिखता है जिसे ब्लॉक करना उसे भारी पड़े।

इसके साथ तीन चीज़ें आती हैं, और कोई भी बारीक अक्षरों में छुपी नहीं है:

• एज आपका TLS टर्मिनेट करता है। ट्रैफ़िक डिज़ाइन से ही प्रोवाइडर के नेटवर्क के अंदर प्लेनटेक्स्ट होता है — कैशिंग और फ़िल्टरिंग इसी तरह काम करती हैं। आपके यूज़र जो भी टाइप करते हैं, वह आप तक पहुँचने से पहले एक तीसरे पक्ष तक पहुँचता है।
• एक शिकायत चैनल जो पहले नहीं था। शिकायतें सीधे CDN के ख़िलाफ़ दर्ज की जा सकती हैं, और CDN उनका जवाब देता है: आपको आगे भेजकर, आपके होस्टिंग प्रोवाइडर का नाम बताकर, या आपको हटाकर। अगर ऑफ़शोर होने की आपकी वजह यह थी कि शिकायतें कहीं नहीं पहुँचतीं, तो आगे एक US बिचौलिया लगाना उसी ज़ंजीर को फिर से जोड़ देता है जिसे तोड़ने के लिए आपने पैसे ख़र्च किए थे।
• एक अकाउंट। ईमेल पता, पेमेंट मेथड, अक्सर एक फ़ोन नंबर, जो आपके डोमेन से जुड़ा होता है और अनिश्चित काल तक रखा जाता है। इस पर आगे और बात होगी, क्योंकि यह आमतौर पर पूरी व्यवस्था की सबसे कमज़ोर कड़ी होती है।

इनमें से कुछ भी CDN को ग़लत नहीं बनाता। यह इसे दो पहलुओं वाला फ़ैसला बना देता है: असली यूज़र और असली लेयर-7 दबाव वाली किसी दुकान या एप्लिकेशन के लिए बेहतरीन, ऐसी पब्लिशिंग के लिए सीधे नुक़सानदेह जो टेकडाउन खींचती है। DMCA-ignored होस्टिंग पेज पर इस सवाल का हमारा अपना जवाब हमेशा से इसका छोटा रूप रहा है: टेकडाउन प्रतिरोध के लिए, वह नेटवर्क फ़िल्टरिंग इस्तेमाल करें जो आपके पास पहले से है, और CDN छोड़ दें।

वे छह तरीके जिनसे ओरिजिन पता फिर भी लीक हो जाता है

यही वह हिस्सा है जो मायने रखता है, क्योंकि छुपाव कोई ऐसा प्रोडक्ट नहीं है जो आप ख़रीद लें — यह एक ऐसा गुण है जिसे आप या तो बनाए रखते हैं या खो देते हैं, आमतौर पर कुछ ही दिनों में, छह चीज़ों में से किसी एक के आगे। ओरिजिन हर दिन बिल्कुल ठीक-ठाक CDN कॉन्फ़िगरेशन के पीछे भी खोज लिए जाते हैं।

• सर्टिफ़िकेट ट्रांसपेरेंसी लॉग। आपके डोमेन के लिए जारी हर पब्लिकली भरोसेमंद सर्टिफ़िकेट मिनटों के भीतर पब्लिक, स्थायी, सर्च की जा सकने वाली लॉग में छप जाता है। वे आपका पता नहीं छापते; वे आपके होस्टनेम छापते हैं — staging, mail, vpn, वह सबडोमेन जो आपने 2024 में एक बार बनाया था। हर एक को रिज़ॉल्व करने लायक उम्मीदवार माना जाता है, और एक भी रिकॉर्ड जो फ़्रंट की ओर इशारा नहीं करता, पूरी कवायद ख़त्म कर देता है।
• DNS इतिहास। पैसिव-DNS सर्विसें उन सभी पतों को संग्रहित करती हैं जिन पर आपका डोमेन कभी भी रिज़ॉल्व हुआ है। बाद में CDN के पीछे जाना यह नहीं मिटाता जो पहले ही दर्ज हो चुका है — छुपाव को डोमेन के पहली बार रिज़ॉल्व होने से पहले ही शुरू होना पड़ता है, वरना आपको एक नया फ़्रंट नहीं, एक नया पता चाहिए।
• वे रिकॉर्ड जिन्हें प्रॉक्सी नहीं किया जा सकता, और जिन्हें आप भूल गए। मेल एक्सचेंजर को किसी ऐसी जगह इशारा करना ही होता है जो पहुँच में हो। ऐसा ही एक AAAA रिकॉर्ड करता है जो तब छूट गया जब आपने सिर्फ़ IPv4 प्रॉक्सी किया, या एक पुराना FTP या पैनल होस्टनेम, एक वाइल्डकार्ड, या वह "अस्थायी" डेवलपमेंट होस्ट जो अब तीन साल पुराना हो चुका है।
• सर्वर जो कुछ भी भेजता है। ओरिजिन से आने वाली मेल अपने पते को Received हेडर में ले जाती है — एक पासवर्ड-रीसेट मैसेज ख़ुद ही अपनी जानकारी उजागर कर देता है। वेबहुक, आउटबाउंड इमेज फ़ेच, लिंक प्रीव्यू, पिंगबैक, अपडेट चेक और क्रैश रिपोर्टर — ये सब असली पते से बाहर पहुँचते हैं, और जो कोई भी आपके एप्लिकेशन को अपने नियंत्रण वाले होस्ट से बात करवा सके, वह इसे जान लेता है।
• पूरे इंटरनेट की स्कैनिंग। हर IPv4 पते को पब्लिक सर्विसें लगातार स्कैन और इंडेक्स करती हैं, और नतीजे सेकंडों में सर्च किए जा सकते हैं। अगर आपका ओरिजिन पोर्ट 443 पर आपके सर्टिफ़िकेट के साथ जवाब देता है, या किसी भी Host हेडर पर आपका होमपेज परोसता है, तो उसका मिलान एक बॉडी हैश, एक सर्टिफ़िकेट फ़िंगरप्रिंट या एक favicon हैश के ख़िलाफ़ बस एक क्वेरी भर है। ज़्यादातर ओरिजिन इसी तरह खोजे जाते हैं, और यह खोजने वाले को कुछ भी ख़र्च नहीं करता।
• एप्लिकेशन का ख़ुद अपने बारे में बताना। कच्चा पता ले जाने वाले एब्सोल्यूट URL और रीडायरेक्ट, खुले छोड़ दिए गए स्टेटस या मेट्रिक्स एंडपॉइंट, इंटरनल होस्ट के नाम लेने वाले वर्बोज़ स्टैक ट्रेस, बैकएंड ज़ाहिर करने वाले हेडर, और वह डिफ़ॉल्ट वर्चुअल Host जो पते से पूछने वाले किसी को भी ख़ुशी-ख़ुशी आपकी साइट परोस देता है।

ओरिजिन को इस तरह लॉक करना कि सिर्फ़ फ़्रंट ही उस तक पहुँच सके

जो छुपाव इस बात पर निर्भर करे कि कोई पते का अंदाज़ा न लगाए, वह छुपाव है ही नहीं। यह व्यवस्था तभी टिकती है जब ओरिजिन फ़्रंट के अलावा किसी से भी बात करने से इनकार कर दे, ताकि लीक हुआ पता एक घटना नहीं बल्कि एक झुंझलाहट भर रह जाए।

• पहले सब कुछ नकारें, फिर फ़्रंट को इजाज़त दें। 80 और 443 सिर्फ़ प्रोवाइडर की प्रकाशित एड्रेस रेंज से स्वीकार करें, और उस सूची को अपने-आप ताज़ा करते रहें — रेंज बदलती रहती हैं, और एक बासी सूची सबसे बुरे पल पर या तो खुल जाती है या बंद हो जाती है। बाक़ी सब कुछ, SSH समेत, हमारी फ़र्स्ट-आवर हार्डनिंग चेकलिस्ट की तरह किसी टनल या मैनेजमेंट पते पर होना चाहिए।
• फ़्रंट को ऑथेंटिकेट करें। CDN और आपके ओरिजिन के बीच क्लाइंट सर्टिफ़िकेट — जिन्हें आमतौर पर ऑथेंटिकेटेड ओरिजिन पुल कहा जाता है — का मतलब है कि सही पता और सही Host हेडर मिलकर भी, सर्टिफ़िकेट के बिना कुछ हासिल नहीं करते।
• बेहतर: कोई इनबाउंड पोर्ट ही नहीं। ओरिजिन से एज तक सिर्फ़ आउटबाउंड टनल — चाहे वह CDN का अपना कनेक्टर हो या आपके चलाए किसी नोड तक WireGuard — का मतलब है कि ओरिजिन कभी किसी पब्लिक इंटरफ़ेस पर सुनता ही नहीं। स्कैनिंग वह नहीं खोज सकती जो जवाब ही न दे, और यह इस व्यवस्था का सबसे मज़बूत रूप है।
• एक वर्चुअल Host, एक Host हेडर। डिफ़ॉल्ट सर्वर को कुछ भी काम का जवाब नहीं देना चाहिए। अगर आपकी साइट पते से लोड होती है, तो एक हफ़्ते के भीतर कोई स्कैनर उसका मिलान कर लेगा।
• मेल को वेब ओरिजिन से हटाएँ। मेल का पहुँच में होना और ख़ुद की पहचान बताना ज़रूरी है; इसे अपनी अलग मशीन पर रखें, जैसा हमारी मेल सर्वर गाइड मानकर चलती है।
• बाहर से पुष्टि करें। इस सूची की हर जाँच, सर्वर से ही चलाई जाए तो बेमानी है। किसी ऐसे नेटवर्क से टेस्ट करें जो आपका न हो।

CDN की जगह आपका अपना फ़्रंट नोड

तीसरे विकल्प को नज़रअंदाज़ कर दिया जाता है क्योंकि इसके पास कोई मार्केटिंग बजट नहीं है: पब्लिक चेहरे के तौर पर एक छोटा VPS, डेटा रखने वाली मशीन तक वापस जाता एक एन्क्रिप्टेड टनल, और उनके बीच ट्रैफ़िक पास करता nginx या HAProxy। बाहर से यह किसी भी वेब सर्वर जैसा दिखता है। असली वाला कहीं और है, बिना किसी इनबाउंड पोर्ट के।

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

जो आपको नहीं मिलता, वह है एनीकास्ट क्षमता। एक नोड के पास बस एक नोड की क्षमता होती है, और जबकि हमारी नेटवर्क फ़िल्टरिंग इसे ठीक वैसे ही सुरक्षित करती है जैसे किसी और सर्वर को, एक सचमुच बड़ा वॉल्यूमेट्रिक हमला एक बैंडविड्थ मुक़ाबला है जिसे एक ग्लोबल नेटवर्क जीत जाता है। ईमानदार नज़रिया यह है: एक भारी या महँगे बैकएंड — एक स्टोरेज ऐरे, एक GPU बॉक्स, एक मेल सर्वर, एक डेटाबेस — को छुपाने के लिए, और क्षेत्राधिकार बाँटने के लिए, फ़्रंट नोड सही जवाब है। लगातार बने रहने वाले लेयर-7 दबाव के तहत यह CDN का विकल्प नहीं है।

एक तालिका में चुनाव

अकाउंट ही आमतौर पर सबसे कमज़ोर कड़ी होता है

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

इसका इलाज पेचीदा नहीं है, बस भूलना आसान है: अगर मक़सद गुमनामी है, तो या तो फ़्रंट आपका अपना हो, या उसके आगे मौजूद अकाउंट उतना ही डिस्पोज़ेबल और उतना ही अनट्रेसेबल हो जितना पीछे का सर्वर है। Server OpSec इस अनुशासन को ठीक से कवर करती है, और ऑफ़शोर गुमनामी पर हमारा ईमानदार जवाब इस बारे में बेलाग है कि ज़ंजीर की कौन-सी कड़ियाँ आमतौर पर सबसे पहले टूटती हैं। वे लगभग कभी तकनीकी वाली नहीं होतीं।

दस मिनट में अपनी एक्सपोज़र का ऑडिट करना

नीचे दी गई हर चीज़ वह है जिसे कोई दिलचस्पी रखने वाला पक्ष पहले कुछ मिनटों में जाँच लेगा। इन्हें ख़ुद चलाएँ, किसी ऐसी मशीन से जो सर्वर नहीं है, इससे पहले कि आपको जवाबों की ज़रूरत पड़े।

• वह हर होस्टनेम सूचीबद्ध करें जिसे आपने कभी सर्टिफ़ाई किया है। अपने एपेक्स डोमेन को किसी सर्टिफ़िकेट ट्रांसपेरेंसी सर्च इंजन में खोजें और हर नतीजे को रिज़ॉल्व करें। जो भी फ़्रंट की ओर इशारा न करे, वह एक लीक है, उन होस्ट समेत जिन्हें आप अब इस्तेमाल नहीं करते।
• अपना ख़ुद का DNS इतिहास पढ़ें। एक पैसिव-DNS लुकअप वे पते दिखाता है जिन पर आपका डोमेन CDN से पहले रिज़ॉल्व होता था। अगर कल का ओरिजिन आज भी ओरिजिन है, तो छुपाव कभी असली था ही नहीं।
• ओरिजिन से सीधे पूछें। curl -sI --resolve example.com:443:198.51.100.10 https://example.com/ — अगर साइट जवाब देती है, तो आपका फ़ायरवॉल फ़्रंट तक सीमित नहीं कर रहा, और किसी संभावित पते वाला कोई भी इसे एक ही रिक्वेस्ट में पुष्टि कर सकता है।
• इससे रूखेपन से पूछें। curl -skI https://198.51.100.10/ को कुछ भी पहचाने जाने लायक नहीं लौटाना चाहिए। आपका होमपेज परोसता एक डिफ़ॉल्ट वर्चुअल Host, इस पेज पर अकेली सबसे आम ग़लती है।
• हर रिकॉर्ड टाइप जाँचें, सिर्फ़ A नहीं। dig +short AAAA example.com, dig +short MX example.com, और ट्रांसपेरेंसी लॉग से पता चले हर सबडोमेन के लिए भी वही। बिना प्रॉक्सी किया गया IPv6 एक क्लासिक मामला है।
• एप्लिकेशन से ख़ुद को मेल करें। एक पासवर्ड रीसेट ट्रिगर करें और पूरी Received चेन पढ़ें। अगर ओरिजिन पता उसमें है, तो वह आपके भेजे हर मैसेज में भी है।
• पुष्टि करें कि पोर्ट बंद हैं। किसी असंबंधित नेटवर्क से, nmap -Pn -p80,443 198.51.100.10 को फ़िल्टर्ड दिखाना चाहिए, खुला नहीं।
• स्कैनर खँगालें। अपना सर्टिफ़िकेट फ़िंगरप्रिंट और अपने होमपेज का favicon हैश किसी पब्लिक इंटरनेट-स्कैन इंडेक्स में खोजें। अगर आपका ओरिजिन इंडेक्स्ड है, तो इसी तरह इसे खोजा जाएगा।

जब पता पहले ही जल चुका हो

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

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

संक्षेप में

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

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