सवाल nginx real_ip_header और एक्स-फॉरवर्डेड-गलत लगता है


HTTP शीर्षलेख का विकिपीडिया विवरण X-Forwarded-For है:

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

निर्देश के लिए nginx दस्तावेज real_ip_header कुछ हिस्सों में पढ़ता है:

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

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

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

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


49
2017-09-22 20:41


मूल




जवाब:


मेरा मानना ​​है कि एक्स-फॉरवर्डेड को हल करने की कुंजी - कई आईपी जंजीर होने पर परेशानियों के लिए हाल ही में पेश किए गए कॉन्फ़िगरेशन विकल्प हैं, 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 अब ग्राहक के आईपी पते के रूप में 123.123.123.123 चुन देगा।

क्यों nginx सिर्फ बाएं सबसे अधिक आईपी पते नहीं चुनता है और आपको विश्वसनीय प्रॉक्सी को स्पष्ट रूप से परिभाषित करने की आवश्यकता है, यह आसान आईपी स्पूफिंग को रोकने के लिए है।

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

X-Forwarded-For: 11.11.11.11

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

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 आईपी ​​पता के रूप में, उस स्पूफेड आईपी के बावजूद वास्तव में बाएं सबसे अधिक होने के बावजूद।


75
2017-08-03 22:45



इसके लिए बहुत बहुत धन्यवाद, यह वास्तव में मेरी मदद की। यह स्वीकार्य उत्तर होना चाहिए। - José F. Romaniello
डिफ़ॉल्ट रूप से real_ip_header एक्स-रीयल-आईपी के अनुसार प्रतीत होता है nginx.org/en/docs/http/ngx_http_realip_module.html क्या इसका मतलब यह है कि दुर्भावनापूर्ण उपयोगकर्ता केवल यादृच्छिक एक्स-रीयल-आईपी के साथ अनुरोध भेज सकता है और इसका उपयोग nginx में $ remote_addr के रूप में किया जाएगा (और संभवतः एप्लिकेशन को पास किया गया है)? - gansbrest
@gansbrest नहीं, क्योंकि set_real_ip_from विश्वसनीय होस्ट को सीमित करता है। - El Yobo


की पार्सिंग 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;
  }
}

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

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

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

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


9
2017-09-22 22:08



उत्तर के लिए धन्यवाद, @ शेन। वास्तव में, जब nginx तक पहुंचते हैं, ए X-Forwarded-For पहले से ही मौजूद है। (यह सही ग्राहक आईपी पता है) nginx इसके बाद ही हमारे लोड बैलेंसर (पिछली हॉप) के आईपी पते को जोड़ने के लिए आगे बढ़ता है X-Forwarded-For हैडर। (संभावित रूप से "रिमोट एड्रेस" के रूप में जो दिखता है उसे जोड़ना) यदि यह बस ऐसा नहीं करता है, तो मैं बस इसका उपयोग कर पाऊंगा X-Forwarded-For पहले के रूप में हेडर। (हम हाल ही में nginx में माइग्रेट कर रहे हैं) - Kirk Woll
@ किर्क तो, जब nginx हेडर प्राप्त करता है, यह सिर्फ मूल ग्राहक का पता है? लेकिन जब यह संसाधित हो रहा है, तो यह कनेक्टिंग प्रॉक्सी सर्वर के शीर्षलेख पर जोड़ा गया है? यह जोड़ नहीं है - उस हेडर को स्पर्श करने का एकमात्र समय यह है कि जब वह किसी अन्य प्रॉक्सी से कनेक्शन भेज रहा है proxy_pass - और फिर भी, केवल साथ proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; जगह में। - Shane Madden♦
यहां तक ​​कि डब्ल्यू 3 सी भी यह गलत हो जाता है: उनके दस्तावेज बताते हैं "प्रॉक्सी को अनुरोध के आरंभकर्ता का आईपी पता जोड़ना चाहिए समाप्त एक एक्स-फॉरवर्डेड-HTTP हेडर फ़ील्ड में अल्पविराम से अलग सूची की ", यह अवश्य होना चाहिए शुरू। - Ian Kemp
@ इनकेम्प, नहीं, समाप्त सही है। प्रॉक्सी के सर्वर पक्ष में, अनुरोध के आरंभकर्ता (अर्थात। टीसीपी अनुरोध) पिछली प्रॉक्सी है (यदि कोई है तो)। वह पिछली प्रॉक्सी संभवतः पहले से ही भेजती है X-Forwarded-For संभावित रूप से बाईं ओर संभवतः मूल क्लाइंट पता के साथ शीर्षलेख और संभावित रूप से किसी भी पूर्ववर्ती प्रॉक्सी को जोड़ा गया है। तो वर्तमान में प्रस्तुति प्रॉक्सी उस सूची के अंत में पिछली प्रॉक्सी (= आरंभकर्ता) जोड़ देगी और इस प्रकार संवर्धित की जाएगी X-Forwarded-For अगली अपस्ट्रीम हॉप के लिए हेडर। माना जाता है कि वे एक और स्पष्ट शब्द चुन सकते थे। - blubberdiblub


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


4
2017-09-22 21:07



ठीक है, लेकिन, मेरे लिए, यह कभी भी उपयोगी जानकारी नहीं है। मैं क्लाइंट का मूल आईपी पता प्राप्त करना चाहता हूं - यह महत्वपूर्ण है, और मैंने जो कुछ भी पढ़ा है, उसके अनुसार, इन शीर्षकों का उद्देश्य। मैं अपने प्रॉक्सी सर्वर का आईपी पता क्यों जानना चाहूंगा? - Kirk Woll
यदि यह आपके लिए उपयोगी नहीं है तो यह आपके लिए नहीं है। एक्स-रीयल-आईपी का उपयोग करने के लिए कोई भी आपको मजबूर नहीं कर रहा है। यदि आपको अपने आवेदन में उपयोगकर्ता के आईपी की आवश्यकता है, तो अपने एप्लिकेशन पार्स एक्स-फॉरवर्ड-फॉर (जो हमेशा विश्वसनीय नहीं है क्योंकि कुछ प्रॉक्सी (इंटरनेट सुरक्षा उपकरण / फ़ायरवॉल) हैं जो एक्स-फॉरवर्ड- के लिये)। Nginx के संदर्भ में, एक्स-फॉरवर्ड-फॉर महत्वपूर्ण नहीं है क्योंकि यह उन प्रविष्टियों से बात नहीं कर रहा है, वैसे भी, अंतिम प्रविष्टि (एक्स-रीयल-आईपी) जो कि nginx के क्लाइंट है। अगर आपको इसकी आवश्यकता नहीं है तो इसे सेट न करें, इसे अनसेट करें, या इसे अनदेखा करें: / - user558061
नहीं, मेरा मतलब क्या है, क्यों होगा X-Real-IP अपना खुद का प्रॉक्सी सर्वर का आईपी पता वापस कर रहा है कभी उपयोगी होना? - Kirk Woll
महान .. जवाब आदमी। मैं इस सटीक जानकारी की तलाश में था। मुझे अपने प्रॉक्सी सर्वर पर एक एनटीसी सर्वर से बात करने की ज़रूरत है, इसलिए मुझे इसे फ्लाई पर चाहिए। - Yugal Jindle