सॉकेट पीयर बनाम फ़ॉरवर्डेड हेडर: किस पते पर भरोसा करें?

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

कुछ भी तुलना करने से पहले पथ का वर्णन करें:

Client -> approved reverse proxy -> application origin

उस व्यवस्था में मूल का सॉकेट पीयर आमतौर पर प्रॉक्सी होता है, और फ़ॉरवर्डिंग हेडर प्रॉक्सी का क्लाइंट के बारे में दावा ले जा सकता है। उसका मूल्य उस प्रॉक्सी के साथ नियंत्रित संबंध से आता है, हेडर के नाम से नहीं।

पते के दो तरह के साक्ष्य

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

फ़ॉरवर्डिंग फ़ील्ड एक श्रृंखला के बारे में मेटाडेटा है। X-Forwarded-For, X-Real-IP और मानकीकृत फ़ील्ड Forwarded कोई भी क्लाइंट लिख सकता है जो ऐसे एंडपॉइंट तक पहुँचता है जो उन्हें वापस गूँजता है, इसलिए उनकी विश्वसनीयता पूरी तरह इस पर निर्भर है कि उन्हें सेट करने की अनुमति किसे थी।

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

हेडर कभी कनेक्शन को दोबारा रूट नहीं करता

फ़ॉरवर्डिंग फ़ील्ड में पता लिखने से सर्वर तक पहुँचने वाले TCP कनेक्शन का स्रोत नहीं बदलता, और पथ में कहीं भी रूटिंग नहीं बदलती। सामान्य VPN रूटिंग या स्रोत NAT बिना किसी HTTP हेडर के ट्रैफ़िक पहुँचाते हैं। इसी तरह, ट्रांज़िट गेटवे TLS एंडपॉइंट की व्यवस्था बदले बिना ठीक से सुरक्षित HTTPS आदान-प्रदान को दोबारा नहीं लिखता।

उलटी गलती भी उतनी ही आम है: HTTPS क्लाइंट द्वारा दिए गए फ़ॉरवर्डिंग हेडर को सच नहीं बनाता। यह झूठे दावे के परिवहन को उतनी ही अच्छी तरह सुरक्षित करता है जितना सच्चे के।

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

उस प्रॉक्सी का नाम दें जिसे दावा करने की अनुमति है

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

NGINX का वास्तविक IP मॉड्यूल विभाजन स्पष्ट रूप से दिखाता है। set_real_ip_from उन प्रेषकों के नाम बताता है जिनका दावा गिना जाता है, और real_ip_header बताता है कि कौन सा फ़ील्ड उसे ले जाता है; पहला भरोसा करता है, दूसरा केवल यह बताता है कि कहाँ देखना है।

set_real_ip_from 10.20.0.0/24;
real_ip_header X-Forwarded-For;
# real_ip_recursive off - take the rightmost value in the field
# real_ip_recursive on  - walk the list back past every trusted address

केवल हेडर-चयन निर्देश अपने आप में यह अभी तक स्थापित नहीं करता कि मान किसने भेजा।

ट्रांसपोर्ट सुरक्षा को उन घटकों के बीच पूरे रास्ते चलना होता है जिन पर आप भरोसा करते हैं। ठीक से सामान्य करने वाला किनारा वह मूल्य उसी क्षण खो देता है जब नीचे कोई असुरक्षित हॉप किसी और को यात्रा के दौरान दावा संपादित करने देता है।

बहु-हॉप श्रृंखलाओं को जानबूझकर संभालें

कई प्रॉक्सी को स्पष्ट श्रृंखला मॉडल चाहिए। किसी ब्लॉग पोस्ट ने ऐसा किया इसलिए अल्पविराम से अलग किया गया सबसे बायाँ या सबसे दायाँ मान न लें; पता लगाएं कि आपकी कौन सी प्रॉक्सी जोड़ती है, कौन सी बदलती है और कौन सी आने वाला फ़ील्ड सहेजती है। उदाहरण के लिए, NGINX अपने विश्वस्त सेट के सामने सूची को पीछे की ओर चल सकता है और पहले ऐसे पते पर रुक सकता है जो उसका नहीं है, और यह उस उत्पाद का नियम है, कोई ऐसा कानून नहीं जिसका हर फ़्रेमवर्क पालन करे। अपनी प्रॉक्सी का दस्तावेज़ उन्हीं दो सवालों के साथ पढ़ें: वह कौन सा मान चुनती है, और किन प्रेषकों पर विश्वास करती है?

श्रृंखला लिखें: हॉप क्रम, कौन सा हॉप फ़ील्ड सेट करता है और कौन सा हॉप आने वाली प्रतियाँ हटाता है। फिर उस नोट को प्रॉक्सी कॉन्फ़िगरेशन के पास रखें, केवल टिकट में नहीं। फिर स्वीकृत सत्यापन प्रक्रिया से जाली हेडर वाला अनुरोध भेजकर और यह पुष्टि करके उसका परीक्षण करें कि मूल उसे अनदेखा करता है।

जब आप कोई हॉप जोड़ते हैं, तो उस दस्तावेज़ को फिर से देखें। विश्वस्त प्रॉक्सी के सामने डाला गया नया लोड बैलेंसर बिना किसी के एप्लिकेशन संपादित किए यह बदल सकता है कि कौन सा पता जीतता है।

दोनों अवलोकन लॉग में रखें

जहाँ निदान अधिकृत है, कनेक्शन के पीयर और सामान्यीकृत क्लाइंट पते को दो अलग फ़ील्ड के रूप में लॉग करें, और केवल वही फ़ॉरवर्डिंग मेटाडेटा जोड़ें जिसकी उद्देश्य को वास्तव में ज़रूरत है। फिर दो अनुरोधों से तैनाती साबित करें: एक प्रॉक्सी से जो दोनों मानों को समझदारी से दर्ज करना चाहिए, और एक सीधा मूल की ओर प्रयास जिसे अस्वीकार किया जाना चाहिए।

याद रखें कि इस जोड़ी का क्या अर्थ है। हेडर उस घटक द्वारा दिया गया संदर्भ जोड़ता है जिस पर भरोसा करने के लिए आपने चुना; पीयर वह एकमात्र पता बना रहता है जो आपके होस्ट ने वास्तव में देखा। इनमें से कोई भी व्यक्तिगत पहचान का प्रमाण नहीं है, और किसी भी एक को प्रमाण मानने वाला डिज़ाइन किसी के बारे में गलत होगा।