क्या 8080/8443 बंदरगाहों पर HTTP / HTTPS की सेवा करना सुरक्षित है


9

एक बुनियादी ढांचे की सीमा के कारण, दुनिया के लिए एक HTTP सेवा प्रदान करने के लिए प्रस्तावित समाधानों में से एक इसे 8080 और 8443 बंदरगाहों पर पेश करना है।

मेरी चिंता यह है कि कुछ उपयोगकर्ता इन सेवाओं तक पहुंचने में सक्षम नहीं हो सकते हैं क्योंकि वे मानक बंदरगाहों पर नहीं चल रहे हैं, और कॉर्पोरेट नेटवर्क नीति के भाग के रूप में सामग्री को (उदाहरण के लिए) फ़िल्टर किया जा सकता है।

तो ... यह कैसे संभव है कि बड़े पैमाने पर इंटरनेट से एक उपयोगकर्ता इन सेवाओं तक पहुंचने में सक्षम न हो?


क्या आप 80 और 443 को पोर्ट करने के लिए एड्रेस नहीं कर सकते?
फ्रूगिज़

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

मेरा मतलब है जैसे: azure.microsoft.com/en-us/documentation/articles/…
Froggiz

2
मैं एक चिंता का समाधान करना चाहता हूं जो यहां याद आ रही है। तथ्य यह है कि आप बंदरगाहों का उपयोग नहीं कर सकते हैं 80या 443सुझाव दे सकते हैं कि आप एक साझा सर्वर पर चल रहे हैं। यदि ऐसा है, तो संभावना मौजूद है कि यदि आप कभी भी काम करना बंद कर देते हैं तो एक अन्य उपयोगकर्ता उन बंदरगाहों से जुड़ सकता है । फिर वह उपयोगकर्ता आपकी वेबसाइट को लागू कर सकता है (हालांकि SSL इसे कम करने में मदद कर सकता है)।
नाथन उस्मान

@NathanOsman, मुझे लगता है कि वह उपयोगकर्ता पहुंच और उपयोगकर्ता फ़ायरवॉल के बारे में चिंतित है।
22

जवाबों:


7

कॉर्पोरेट नेटवर्क आमतौर पर इस तरह के नियमों के लिए डिफ़ॉल्ट हो जाएगा:

deny all; allow 80; allow 443; allow 21; allow 22; etc...

65,535 उपलब्ध बंदरगाहों में से 99% को स्पष्ट रूप से नकारने के बजाय इस तरह से कॉन्फ़िगर करना बहुत आसान है।

इसके साथ ही, मैंने एक क्लाइंट-फेसिंग पोर्टल को संभाला, जो नेटवर्क सीमाओं के कारण एक गैर-मानक पोर्ट का उपयोग करता था; मुझे NAT विवरण नहीं पता है। वैसे भी, हमारे उपयोगकर्ताओं / आगंतुकों को साइट तक पहुंचने में लगभग 50% तक असंभव हो गया था और जब भी वे हमें इस मुद्दे की रिपोर्ट करने के लिए कहते थे, हमें प्रयास करने और नियम लागू करने के लिए उनके गैर-मौजूद आईटी के साथ समन्वय करना होगा।


मुझे आपके बुनियादी ढांचे की सीमाओं का विवरण नहीं पता है, लेकिन मुझे लगता है कि 80/443 पर कुछ और चल रहा है

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


टी एल; डॉ

सार्वजनिक-सामना करने वाली सेवाओं के लिए एक गैर-मानक पोर्ट का उपयोग न करें, जिसमें पहले से ही एक मानक पोर्ट है।


1
"65,535 उपलब्ध बंदरगाहों में से 99% को स्पष्ट रूप से अस्वीकार करने के बजाय इस तरह से कॉन्फ़िगर करना बहुत आसान है।" - भले ही उन्होंने 99% बंदरगाहों को स्पष्ट रूप से नकार दिया हो, लेकिन इसका वही असर होगा।
2325 बजे user253751

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

@ लोगों को सुनकर मुझे खुशी हुई कि आप लोग क्लाइंट-फेसिंग नॉन-स्टैंडर्ड पोर्ट्स का उपयोग किए बिना इसे काम करने में सक्षम थे :)
मंकीज़्यूस

6

बहुत संभावना है कि वे अवरुद्ध हो जाएंगे, विशेष रूप से कॉर्पोरेट नेटवर्क या सार्वजनिक वाईफाई पर। एक नियमित घर इंटरनेट कनेक्शन पर कम संभावना है।

यह निश्चित रूप से मेरे कार्य नेटवर्क पर अवरुद्ध होगा।

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


विचाराधीन सेवाओं को कभी भी ब्राउज़र में टाइप नहीं किया जाता है ... बल्कि उन्हें सामान्य बंदरगाहों पर दिए गए संसाधनों से इंगित किया जाता है। हालांकि, ऐसा लगता है कि मेरे दृष्टिकोण की विश्वसनीयता के बारे में मेरी चिंताएं उचित हैं।
प्रातः

क्या आप बता सकते हैं कि इसे अवरुद्ध क्यों किया जाएगा? मैंने बिना किसी परेशानी के लंबे समय तक पोर्ट 800 का इस्तेमाल किया, यहां तक ​​कि google SEO टूल्स और
रेफरेंसिंग के

1
मेरी एक नौकरी एक वेबसाइट चला रही है जो धाराओं को अनुक्रमित करती है, और यह एक सामान्य शिकायत है कि कॉर्पोरेट नेटवर्क के पीछे कुछ उपयोगकर्ता गैर-मानक बंदरगाहों पर चलने वाली धाराओं को नहीं सुन सकते हैं। हालाँकि, bit० bit० और but४४३ कुछ खास लगते हैं , लेकिन शायद इतने खास नहीं हैं। मैं कहूंगा कि 800 पर एक सेवा चलाना विशेष रूप से जोखिम भरा है क्योंकि यह "अच्छी तरह से ज्ञात" बंदरगाहों के अंतर्गत आता है जो अवरुद्ध होने की अधिक संभावना है।
खर्चा

एक आसान उपाय यह है कि आप अपने सर्वर को 8080/8443 पोर्ट पर चला रहे हैं और फ़ायरवॉल, NAT / फ़ॉरवर्ड पोर्ट 80/443 से 8080/8443 पर चला रहे हैं।
स्नेकडोक

1
@SnakeDoc सहमत, मैंने अपने उत्तर में प्रॉक्सी विकल्प को कवर किया :-)
मंकीज़ेउस

2

अपने ब्राउज़र को हिट बनाने में मुश्किल नहीं है http://example.com:8080/index.html , लेकिन जब आप कॉर्पोरेट नीतियों के बारे में बात करते हैं जो गैर-मानक पोर्ट्स को अवरुद्ध करती हैं जो शक्तिशाली लगता है।

यदि आपके पास किसी प्रकार का लोड संतुलन स्थापित है, तो आप अभी भी मानक पोर्ट पर चलने के लिए अपने एप्लिकेशन सेट कर सकते हैं और आंतरिक रूप से विषम पोर्ट के लिए लोड बैलेंसर पोर्ट को आगे बढ़ा सकते हैं। यहां तक ​​कि अगर आपके पास लोड संतुलन नहीं है, तो मुझे यकीन है कि आप एक आंतरिक पोर्ट के आगे पोर्ट करने का एक तरीका पा सकते हैं जो गैर मानक है।

आंतरिक रूप से, उपयोगकर्ता एक विषम पोर्ट (यदि आपकी कॉर्पोरेट नीति को ब्लॉक करने का हिस्सा नहीं है) पर पहुंच सकते हैं, तो बाहरी रूप से वे http://example.com देखते हैं ।

ऐसा करने के कई तरीके हैं, आपके द्वारा सामना की जाने वाली बाधाओं के प्रकार के आधार पर आपको थोड़ा रचनात्मक होना पड़ेगा। यह हमेशा एक चुनौती है!

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.