nginx real_ip_header और X-Forwarded-For गलत लगता है

Question

HTTP हेडर X-Forwarded-Forका विकिपीडिया विवरण है:

एक्स-फॉरवर्डेड-फॉर: क्लाइंट 1, प्रॉक्सी 1, प्रॉक्सी 2, ...

निर्देश के लिए nginx प्रलेखन real_ip_headerभाग में पढ़ता है:

यह निर्देश प्रतिस्थापन आईपी पते को स्थानांतरित करने के लिए उपयोग किए गए शीर्ष लेख का नाम सेट करता है।
एक्स-फॉरवर्ड-फॉर के मामले में, यह मॉड्यूल प्रतिस्थापन के लिए एक्स-फॉरवर्डेड-फॉर हेडर में अंतिम आईपी का उपयोग करता है । [जोर मेरा]

ये दो वर्णन एक-दूसरे के साथ अजीब लगते हैं। हमारे परिदृश्य में, X-Forwarded-Forहेडर बिल्कुल वर्णित है - क्लाइंट का "वास्तविक" आईपी पता सबसे बाईं ओर है। इसी तरह, नेग्नेक्स का व्यवहार सही -अधिकतम मूल्य का उपयोग करना है - जो, जाहिर है, हमारे प्रॉक्सी सर्वरों में से एक है।

मेरी समझ X-Real-IPयह है कि इसका उपयोग वास्तविक ग्राहक आईपी पते को निर्धारित करने के लिए किया जाना चाहिए - प्रॉक्सी नहीं । क्या मुझे कुछ याद आ रहा है, या यह नगीना में एक बग है?

और, उस से परे, क्या किसी के पास कोई सुझाव है कि X-Real-IPहेडर को बाईं ओर के प्रदर्शन को कैसे बनाया जाए , जैसा कि परिभाषा के अनुसार है X-Forwarded-For?

Answer 1

मेरा मानना ​​है कि एक्स-फॉरवर्डेड-फॉर वुल्स को हल करने की कुंजी जब कई आईपी जंजीर होती है तो हाल ही में शुरू किया गया कॉन्फ़िगरेशन विकल्प है, real_ip_recursive(nginx 1.2.1 और 1.3.0 में जोड़ा गया)। से nginx realip डॉक्स :

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

nginx डिफ़ॉल्ट रूप से श्रृंखला में अंतिम आईपी पते को पकड़ रहा था क्योंकि यह एकमात्र ऐसा था जिस पर भरोसा किया गया था। लेकिन नए real_ip_recursiveसक्षम और कई set_real_ip_fromविकल्पों के साथ , आप कई भरोसेमंद परदे के पीछे परिभाषित कर सकते हैं और यह अंतिम गैर-विश्वसनीय आईपी लाएगा।

उदाहरण के लिए, इस विन्यास के साथ:

set_real_ip_from 127.0.0.1;
set_real_ip_from 192.168.2.1;
real_ip_header X-Forwarded-For;
real_ip_recursive on;

और एक एक्स-फॉरवर्डेड-हेडर जिसके परिणामस्वरूप:

X-Forwarded-For: 123.123.123.123, 192.168.2.1, 127.0.0.1

अब nginx क्लाइंट के IP पते के रूप में 123.123.123.123 को बाहर निकालेगा।

के रूप में के लिए क्यों nginx बस छोड़ दिया सबसे आईपी पते नहीं है और आप स्पष्ट रूप से विश्वसनीय परदे के पीछे परिभाषित करने की आवश्यकता है, यह आसान आईपी स्पूफिंग को रोकने के लिए है।

मान लीजिए कि एक ग्राहक का वास्तविक आईपी पता है 123.123.123.123। मान लें कि क्लाइंट अच्छा नहीं है, और वे अपना आईपी पता खराब करने की कोशिश कर रहे हैं 11.11.11.11। वे इस हेडर के साथ सर्वर से पहले ही अनुरोध भेज देते हैं:

X-Forwarded-For: 11.11.11.11

चूंकि समीपवर्ती परदे के पीछे आईपी को इस एक्स-फॉरवर्डेड-फॉर चेन से जोड़ते हैं, चलो कहते हैं कि यह समाप्त होता है जब नग्नेक्स इसे प्राप्त करता है:

X-Forwarded-For: 11.11.11.11, 123.123.123.123, 192.168.2.1, 127.0.0.1

यदि आप बस बाएं-सबसे पते को पकड़ लेते हैं, तो वह ग्राहक को आसानी से अपने आईपी पते को खराब कर देगा। लेकिन ऊपर के उदाहरण के साथ nginx config, nginx केवल आखिरी दो पते पर भरोसा करेगा। इसका मतलब यह है कि nginx सही ढंग 123.123.123.123से आईपी पते के रूप में ले जाएगा , इसके बावजूद कि स्पूफ आईपी वास्तव में सबसे बाईं ओर है।

Comments

इसके लिए बहुत बहुत धन्यवाद, इसने वास्तव में मेरी मदद की। यह स्वीकृत उत्तर होना चाहिए।

— जोसे एफ। रोमनियलो

डिफ़ॉल्ट रूप से real_ip_header लगता है कि x-Real-IP nginx.org/en/docs/http/ngx_http_realip_module.html के अनुसार है। इसका मतलब यह है कि दुर्भावनापूर्ण उपयोगकर्ता बस यादृच्छिक-रियल-आईपी के लिए अनुरोध भेज सकते हैं और जिसका उपयोग $ Remote_addr के रूप में किया जाएगा। nginx में (और संभवतः आवेदन के लिए भी पारित किया गया है)?

— गैंसब्रस्ट

@gansbrest नहीं, क्योंकि set_real_ip_from विश्वसनीय होस्ट को सीमित करता है।

— एल योबो

Answer 2

X-Forwarded-Forहेडर की पार्सिंग वास्तव में nginx real_ip मॉड्यूल में त्रुटिपूर्ण है।

len = r->headers_in.x_forwarded_for->value.len;
ip = r->headers_in.x_forwarded_for->value.data;

for (p = ip + len - 1; p > ip; p--) {
  if (*p == ' ' || *p == ',') {
    p++;
    len -= p - ip;
    ip = p;
    break;
  }
}

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

यह कल्पना के अनुसार अच्छा नहीं खेल रहा है; यह एक RFC में स्पष्ट रूप से स्पष्ट शब्दों में वर्तनी नहीं होने का खतरा है।

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

यदि संभव हो तो, क्या आप अपने मध्यवर्ती परदे के पीछे खुद को हेडर के अंत में जोड़ना बंद कर सकते हैं, बस इसे केवल वास्तविक ग्राहक पते के साथ छोड़ सकते हैं?

Comments

उत्तर के लिए धन्यवाद, @ शेन। वास्तव में, जब नग्नेक्स तक पहुंचते हैं, तो X-Forwarded-Forपहले से ही मौजूद है। (यह सही क्लाइंट IP एड्रेस है) nginx खुद तो हमारे लोड बैलेंसर (पिछले हॉप) के IP एड्रेस को X-Forwarded-Forहेडर पर अपग्रेड करने के लिए आगे बढ़ता है । (संभवतः "रिमोट एड्रेस" के रूप में इसे जो भी देखता है) यदि यह बस ऐसा नहीं करता है, तो मैं X-Forwarded-Forपहले की तरह हेडर का उपयोग कर पाऊंगा । (हम हाल ही में nginx की ओर पलायन कर रहे हैं)

— Kirk Woll

@Kirk तो, जब nginx को हेडर मिलता है, तो यह केवल मूल ग्राहक का पता है? लेकिन जब यह इसे संसाधित कर रहा है, तो यह कनेक्टिंग प्रॉक्सी सर्वर के हेडर पर जोड़ा गया है? यह जोड़ नहीं करता है - केवल उसी समय इसे उस हेडर को छूना चाहिए जब वह किसी अन्य प्रॉक्सी से कनेक्शन भेज रहा हो proxy_pass- और फिर भी, केवल उसी proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;स्थान पर।

— शेन मैडेन

यहां तक कि W3C यह गलत हो जाता है : अपनी दस्तावेज़ीकरण कहा गया है "प्रॉक्सी के लिए अनुरोध के सर्जक के आईपी पते जोड़ने चाहिए अंत में एक अल्पविराम के एक्स-Forwarded-For HTTP शीर्ष लेख क्षेत्र में अलग की गई सूची", यह लिखा होना चाहिए शुरुआत ।

— इयान केम्प

@IKKemp, नहीं, अंत सही है। किसी प्रॉक्सी के सर्वर पक्ष के लिए, अनुरोध का आरंभकर्ता (यानी टीसीपी अनुरोध) पिछला प्रॉक्सी है (यदि कोई है)। यह पिछले प्रॉक्सी संभवतः पहले से ही X-Forwarded-Forहेडर को मूल रूप से बाईं ओर मूल ग्राहक पते के साथ भेजता है और संभवतः किसी पूर्ववर्ती प्रॉक्सी को उस पर जोड़ा गया है। इसलिए वर्तमान में कार्यरत प्रॉक्सी पिछली सूची (= आरंभकर्ता) को उस सूची के अंत में जोड़ देगा और इस तरह संवर्धित X-Forwarded-Forहेडर को अगले अपस्ट्रीम हॉप में सेवा देगा। दी, वे और अधिक स्पष्ट शब्दों को चुन सकते थे।

— ब्लबरडाइबल जुब

Answer 3

एक्स-रियल-आईपी वास्तविक क्लाइंट का आईपी पता है जो सर्वर से बात कर रहा है (सर्वर का "वास्तविक" क्लाइंट), जो प्रॉक्सी कनेक्शन के मामले में, प्रॉक्सी सर्वर है। यही कारण है कि एक्स-रियल-आईपी में एक्स-फॉरवर्डेड-फॉर हेडर में अंतिम आईपी होगा।

Comments

ठीक है, लेकिन, मेरे लिए, यह केवल उपयोगी जानकारी नहीं है। मैं क्लाइंट का मूल आईपी पता प्राप्त करना चाहता हूं - जो कि महत्वपूर्ण है, और मैंने जो कुछ भी पढ़ा है, उसके अनुसार इन हेडर का उद्देश्य है। हम हमारे प्रॉक्सी सर्वरों का आईपी पता क्यों जानना चाहते हैं?

— कर्क वुल्फ

अगर यह आपके लिए उपयोगी नहीं है तो यह आपके लिए नहीं है। कोई भी आपको X-Real-IP का उपयोग करने के लिए मजबूर नहीं करता है। यदि आपको अपने आवेदन में उपयोगकर्ता के आईपी की आवश्यकता है, तो आपके आवेदन में एक्स-फॉरवर्ड-फॉर (जो हमेशा विश्वसनीय नहीं है, क्योंकि आपके पास कुछ प्रॉक्सी (इंटरनेट सुरक्षा उपकरण / फ़ायरवॉल) हैं, जो एक्स-फ़ॉर्वर्ड सेट नहीं करते हैं) के लिये)। Nginx के संदर्भ में, X-Forwarded-For महत्वपूर्ण नहीं है क्योंकि यह उन ग्राहकों से बात नहीं कर रहा है, जो कि अंतिम प्रविष्टि (X-Real-IP) से अलग है जो कि nginx का क्लाइंट है। यदि आपको इसकी आवश्यकता नहीं है, तो इसे सेट न करें, इसे अनसेट करें, या बस इसे अनदेखा करें: /

— user558061

नहीं, मैं क्या मतलब है, क्यों होता X-Real-IPलौटने मेरे अपने प्रॉक्सी सर्वर का आईपी पता कभी उपयोगी हो?

— कर्क वू

शानदार .. जवाब दे यार। मैं इस सटीक जानकारी की तलाश में था। मुझे अपने प्रॉक्सी सर्वर पर एक एनसीएटी सर्वर से बात करने की आवश्यकता है, इसलिए मुझे मक्खी पर इसकी आवश्यकता है।

— युगल जिंदल