उच्च पोर्ट संख्या का उपयोग करने के लिए सुरक्षित है? (फिर से: अस्पष्ट वेब सेवाएँ)


9

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

एक समझौते के रूप में, क्या बहुत बड़े पोर्ट नंबर का उपयोग करना बेहतर होगा? (उदाहरण। 65531 तक के पांच अंक)

मैंने पढ़ा है कि पोर्ट स्कैनर आमतौर पर पहले 10,000 पोर्ट को स्कैन करते हैं इसलिए बहुत अधिक पोर्ट नंबर का उपयोग करना थोड़ा अधिक सुरक्षित है।

क्या ये सच है?

क्या वेब सर्वर की सुरक्षा के लिए बेहतर तरीके हैं? (आवेदन के लिए वेब गाइस)


नहीं यह सच नहीं है। ब्रॉडबैंड एक्सेस के साथ आधुनिक (यहां तक ​​कि डेस्कटॉप) मल्टी-कोर सीपीयू मशीनें सेकंडों में सभी 65535 बंदरगाहों को स्कैन कर सकती हैं। और यहां तक ​​कि अगर हमलावर ने उन्हें दो सेकंड के लिए एक डीओएस गेट्स को पन्नी में रखने का फैसला किया, जो परवाह करता है, तो आप अपने सिस्टम को एक दिन से अधिक समय के लिए छोड़ रहे हैं, है ना? एक पुरानी कहावत है, जैसा कि दूसरों ने नीचे कहा है, "अस्पष्टता के माध्यम से सुरक्षा" अनिवार्य रूप से डिजिटल दुनिया में बेकार है।
एमएसनफोर्ड

जवाबों:


9

मैंने पढ़ा है कि पोर्ट स्कैनर आमतौर पर पहले 10,000 पोर्ट को स्कैन करते हैं इसलिए बहुत अधिक पोर्ट नंबर का उपयोग करना थोड़ा अधिक सुरक्षित है।

बहुत से लोग ऐसा मानते हैं। मैं नही।

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

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

कुछ स्कैनर इस विश्वास का फायदा उठाते हैं, और शीर्ष पर शुरू करते हैं और सूची के नीचे अपना काम करते हैं। अन्य स्कैन पूरी रेंज में यादृच्छिक पोर्ट को चुनेंगे, इसलिए सभी पोर्ट के स्कैन होने की समान संभावना है।

आगे बढ़ें और NMAP का उपयोग करके स्वयं इसका परीक्षण करें । 1-10,000 बंदरगाहों के खिलाफ नैम्प स्कैन करें और HTTP सर्वर देखें, और उस स्कैन के खिलाफ तुलना करें जो सभी 1-65, xxx बंदरगाहों के खिलाफ स्कैन करता है। आप देखेंगे कि अंतर 3-10 मिनट का है। अगर मैं नेसस जैसी चीज का उपयोग करके एक विस्तृत स्कैन करता हूं, तो अंतर कभी-कभी 20-60 मिनट होता है।

एक अच्छा पटाखा एक रोगी पटाखा है। वे इंतजार करेंगे।


1
यह मानते हुए कि अन्य सभी प्रासंगिक सुरक्षा उपायों को लागू किया गया था, क्या पोर्ट नंबर को अस्पष्ट करना बेहतर या बुरा होगा? मेरी सोच यह होगी कि सर्वर को विशेष रूप से लक्षित न किया जाए तो यह थोड़ा बेहतर होगा।
wag2639

2
+1 "एक अच्छा पटाखा एक रोगी पटाखा है। वे इंतजार करेंगे।"
एमएसनफोर्ड

@ wag2639 आप किसी सेवा के पोर्ट नंबर को बदलकर वास्तव में कुछ नहीं कर रहे हैं, लेकिन स्क्रिप्ट-किडी बनाने से थोड़ी बेहतर स्क्रिप्ट मिल जाती है। आईपी ​​और एएलएसओ के एक ब्लॉक को वॉर-डायल करना हर एक पोर्ट को तुच्छ बनाना है।
एमएसनफोर्ड

यदि कोई हैकर किसी विशेष लक्ष्य के बाद जा रहा है, तो वे 20 - 60 मिनट तक हाई पोर्ट नंबरों की स्कैनिंग कर सकते हैं। हालाँकि अगर वे कमजोर सिस्टम को खोजने के लिए सैकड़ों, या हज़ारों आईपी पतों को स्कैन करने का प्रयास कर रहे हैं, तो वे उच्च बंदरगाहों को स्कैन नहीं करेंगे। इसके अलावा, उन्हें पता होना चाहिए कि वहां एक प्रणाली है, इससे पहले कि वे इसे लक्षित करना शुरू कर सकें। यदि फ़ायरवॉल काम कर रहा है, तो सिस्टम मूल रूप से अदृश्य है जब तक वे एक खुले बंदरगाह पर ठोकर नहीं खाते।
user1751825

3

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

इस तरह की बात को अस्पष्टता से सुरक्षा के रूप में माना जा सकता है लेकिन यह वास्तव में सुरक्षा नहीं है।


क्या पूर्ण-विकसित वीपीएन का उपयोग करने के लिए कोई विकल्प हैं? शायद किसी प्रकार का रिवर्स वेब प्रॉक्सी जिसमें अतिरिक्त लॉगिन / पासवर्ड सुरक्षा है? (स्क्वीड ऐसा नहीं करता है)
सोफा किंग

@sofakng: आप एक एसएसएल रैपर जैसे Stunnel: stunnel.org
मैक्सवेल

3

यदि आप दोनों छोरों पर लिनक्स का उपयोग कर रहे हैं तो आप एक ssh सुरंग का भी उपयोग कर सकते हैं:

ssh -f -N -L 9090:localhost:9090 user@remote-host

उदाहरण के लिए, यही वह है जो मैं अपने स्थानीय पोर्ट 9090 के लिए दूरस्थ होस्ट पर पोर्ट 9090 को अग्रेषित करने के लिए उपयोग करता हूं cherokee-admin, और मैं अन्य वेब जीयूआई के लिए इसी तरह के सेटअप का उपयोग करता हूं। आप एप्लिकेशन कॉन्फ़िगरेशन में निर्दिष्ट करके इस तरह से अनुप्रयोगों की सुरक्षा कर सकते हैं जो वे केवल लोकलहोस्ट पर चलते हैं, अर्थात 127.0.0.1। इस तरह वे बाहर से उपलब्ध नहीं हैं, लेकिन आप उन्हें आगे भेज सकते हैं sshman sshपोर्ट फ़ॉरवर्डिंग (एक्स सहित) का उपयोग करके अधिक विकल्पों की जाँच करें, जो आपकी समस्या को पूरी तरह से हल कर सकते हैं।)

यह आपके सेटअप के आधार पर, अतिरिक्त सॉफ़्टवेयर स्थापित / कॉन्फ़िगर किए बिना अपने लक्ष्य को प्राप्त करने का एक उपयुक्त तरीका हो सकता है।


1

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

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


मैं pfsense का उपयोग कर रहा हूं और मेरी कुछ वेब सेवाओं में अंतर्निहित SSL (HTTPS) समर्थन है। क्या स्टनलाइन का उपयोग करना अभी भी बेहतर है? क्या स्टनलाइन "फ़ायरवॉल पर प्रमाणीकरण" स्तर का उपयोग कर रहा है?
सोफाकिग

1
आप "फ़ायरवॉल पर प्रमाणीकरण" कैसे करते हैं?
wag2639

मुझे नहीं पता कि अगर pfsense में यह कार्यकुशलता है लेकिन, Junipers राउटर पर आप HTTP अनुवादित ट्रैफ़िक तक पहुँच प्रदान करने के लिए स्थानीय उपयोगकर्ताओं (यहां तक ​​कि RADIUS) का उपयोग कर सकते हैं। Stunnel के संबंध में आप प्रमाणपत्रों के साथ पारस्परिक उपयोग कर सकते हैं, stunnel HTTP के साथ HTTP ट्रैफ़िक को एन्कैप्सुलेट करेगा और प्रमाणीकरण को हैंडल करेगा।
मैक्सवेल
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.