क्या डिफ़ॉल्ट पोर्ट नंबर बदलने से वास्तव में सुरक्षा बढ़ जाती है?

69

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

मैं पूरी तरह से आश्वस्त नहीं हूं कि सुरक्षा में सुधार हो सकता है

पोर्ट स्कैनर मौजूद हैं
यदि कोई एप्लिकेशन असुरक्षित है, तो वह अपने पोर्ट नंबर की परवाह किए बिना रहता है।

क्या मुझे कुछ याद आया या मैंने अपने प्रश्न का उत्तर दिया है?

security port port-scanning

— सैम
स्रोत

30

एक चीज जो मैंने की है, वह कुछ निश्चित पोर्ट (जैसे, SSH पोर्ट 22) का उपयोग शहद के बर्तन के रूप में किया जाता है। उन बंदरगाहों से जुड़ने का प्रयास करने वाला कोई भी व्यक्ति xसमय की राशि के लिए पूरी तरह से अवरुद्ध है । यह पोर्ट स्कैनिंग के खिलाफ प्रभावी साबित हुआ है। बेशक, यह सुरक्षा टूलबॉक्स में सिर्फ एक उपकरण है।

— 21:39 पर बेलमिन फर्नांडीज

अस्पष्टता के माध्यम से सुरक्षा के बारे में सामान्य प्रश्न यहाँ कहा जाता है: security.stackexchange.com/questions/2430/...

— टोनी मेयेर

अच्छी तरह से यह "पटकथा बच्चों" के लिए एक बाधा हो सकती है

— लुकाज़ मैडन

1

@BelminFernandez, "सुरक्षा टूलबॉक्स में एक उपकरण" ? नहीं, यह सर्वर लोड (प्रदर्शन) को कम करने के लिए है और इसका भ्रम के अलावा सुरक्षा से कोई लेना-देना नहीं है। सुरक्षा-वार, यह पूरी तरह से अनावश्यक है यदि सर्वर पहले से ही मजबूत है, और यदि सर्वर कमजोर है, तो यह इसे और अधिक सुरक्षित नहीं बनाता है।

— पचेरियर

@Pacerier, सहमत हैं कि प्रयास और ध्यान अधिक ठोस सुरक्षा प्रथाओं को लागू करने पर होना चाहिए। हालाँकि, कोई कारण नहीं है कि आप दोनों क्यों नहीं कर सकते।

— बेलमिन फर्नांडीज

68

यह एक लक्षित हमले के खिलाफ कोई गंभीर बचाव प्रदान नहीं करता है। यदि आपके सर्वर को लक्षित किया जा रहा है, तो जैसा कि आप कहते हैं, वे आपको स्कैन करेंगे और पता करेंगे कि आपके दरवाजे कहां हैं।

हालाँकि, SSH को 22 के डिफ़ॉल्ट पोर्ट पर ले जाने से कुछ गैर-लक्षित और शौकिया स्क्रिप्ट किडी प्रकार के हमलों का पता चलेगा। ये अपेक्षाकृत अप्रभावी उपयोगकर्ता हैं, जो विशेष रूप से यह देखने के लिए एक समय में IP पते के बड़े ब्लॉक को पोर्ट करने के लिए स्क्रिप्ट का उपयोग कर रहे हैं कि क्या पोर्ट 22 खुला है और जब वे एक को ढूंढते हैं, तो वे उस पर किसी प्रकार का हमला शुरू करेंगे (जानवर बल, शब्दकोश हमला,) आदि)। यदि आपकी मशीन आईपी के उस ब्लॉक में स्कैन की जा रही है और वह 22 पोर्ट पर SSH नहीं चला रहा है, तो वह प्रतिक्रिया नहीं देगा और इसलिए इस स्क्रिप्ट किडी पर हमला करने के लिए मशीनों की सूची में दिखाई नहीं देगा। एर्गो, कुछ निम्न-स्तरीय सुरक्षा प्रदान की गई है, लेकिन केवल इस प्रकार के अवसरवादी हमले के लिए।

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

मैं Fail2Ban को एक सार्वजनिक वेबसर्वर पर चलाता था और यह वास्तव में, वास्तव में स्पष्ट था जब मैंने SSH को 22 बंदरगाह से दूर स्थानांतरित कर दिया। इसने अवसरवादिता के हमलों को परिमाण के आदेशों से काट दिया।

— JDW
स्रोत

3

माना। मैंने एक समान मानक ड्रॉप देखा जब एसएसएच को एक गैर-मानक बंदरगाह पर ले जाने के साथ प्रयोग किया गया। सौभाग्य से पासवर्ड के साथ विकलांग, यह वास्तव में एक गैर-मुद्दा है।

— ईईएए

3

अब तक का सबसे अच्छा जवाब। यह सब नीचे आता है कि कौन हमला कर रहा है। मैंने एक बार एक सिस्टम को प्रबंधित करने में मदद की थी जो एक स्कैनिंग कीडी से शून्य-दिन के हमले के साथ मारा गया था। संभवतः MS-RDP में क्योंकि हमारे पास फ़ायरवॉल द्वारा IIS उजागर नहीं था। हमारा मेजबान हमें RDP पोर्ट (प्रबंधित होस्टिंग) को बदलने की अनुमति नहीं देगा, इसलिए हमें मूल रूप से वहां बैठना पड़ा जब उन्होंने अपने आईडीएस / आईपीएस फ़िल्टरिंग के लिए एक नए पैटर्न पर काम किया। हालांकि यह एसएसएच जैसे अधिक स्थापित सर्वरों के लिए उतना मदद नहीं कर सकता है, जो कुछ एमएस उत्पादों की तुलना में कम सुरक्षा मुद्दे हैं।

— मैट मोलनार

9

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

— पॉल क्रून

1

SSH को पोर्ट 22 पर ले जाने का एक और बिंदु यह है कि SSH की बड़ी मात्रा प्लस सेवाओं की कोशिश करती है क्योंकि Fail2Ban कई बार मूल्यवान CPU समय ले सकता है। यह लाइन हार्डवेयर के शीर्ष पर नगण्य हो सकता है लेकिन कुछ पुराने सर्वर सीपीयू स्पाइक्स का अनुभव कर सकते हैं। इसका CPU समय, मेमोरी और बैंडविथ आप अन्य सामान के लिए उपयोग कर सकते हैं।

— आर्टिफेक्स

मैंने सर्वर 2003 पर आरडीपी के साथ ऐसा ही किया है - यह इवेंट व्यूअर में विफल प्रमाणीकरण प्रविष्टियों की मात्रा में काफी कटौती कर देता है।

— मोशे

43

यह लॉग्स को साफ रखने में बहुत मददगार है।

यदि आप बंदरगाह 33201 पर चल रहे sshd के साथ विफल प्रयासों को देखते हैं, तो आप सुरक्षित रूप से मान सकते हैं कि वह व्यक्ति आपको निशाना बना रहा है और आपके पास इच्छा होने पर उपयुक्त कार्रवाई करने का विकल्प है .. जैसे कि अधिकारियों से संपर्क करना, जांच करना कि यह व्यक्ति कौन हो सकता है ( अपने पंजीकृत उपयोगकर्ताओं के आईपी के साथ क्रॉस रेफ़रिंग या जो भी हो), आदि।

यदि आप डिफ़ॉल्ट पोर्ट का उपयोग करते हैं तो यह जानना असंभव होगा कि क्या कोई आप पर हमला कर रहा है या यह केवल यादृच्छिक बेवकूफ है जो यादृच्छिक स्कैन कर रहा है।

— थॉमस बोनी
स्रोत

8

अद्भुत अंतर

— ZJR 2

3

+1 यह पोर्ट नंबर बदलने के लिए सबसे अच्छा तर्क है जो मैंने कभी सुना है और अब तक केवल एक चीज है जो मुझे ऐसा करने के लिए

— लुभाएगी

2

+1 यह एक बेहतरीन बिंदु है। लक्षित खतरे यादृच्छिक जांच की तुलना में बहुत अधिक खतरनाक होते हैं (यदि आपके पास कोई भी सभ्य सुरक्षा है तो स्क्रिप्ट किडीज़ आसान लक्ष्यों को आगे बढ़ाते हैं)। लक्षित हमलावर विशिष्ट कमजोरियों या यहां तक कि पासवर्ड पैटर्न के बारे में बहुत कुछ जान सकता है। पोर्ट 22 पर स्पैम के झुंड के बाहर इन हमलों को पहचानने में सक्षम होना अच्छा है।

— स्टीवन टी। स्नाइडर

1

यह गलत है। मैंने देखा है कि कम से कम एक सर्वर एक गैर-मानक एसएसएच पोर्ट पर स्कैन के माध्यम से समझौता कर लेता है। कोई अंतर्निहित कारण नहीं है कि एक हमलावर अन्य बंदरगाहों को भी स्कैन करने में सक्षम नहीं होगा।

— स्वेन स्लोववेग

@SvenSlootweg, सच है, विशेष रूप से कंप्यूटर तेज और सस्ता होने के साथ, 65535 गुना अधिक समय तक एक स्कैन अब और नहीं रह गया है ।

— पचेरियर

28

नहीं, यह नहीं है। ज़रुरी नहीं। इस शब्द के लिए सुरक्षा अस्पष्टता से सुरक्षा है और यह एक विश्वसनीय अभ्यास नहीं है। आप अपनी दोनों बातों में सही हैं।

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

अपने आप को एक एहसान करो और अपने बंदरगाहों को ठीक से कॉन्फ़िगर करें, लेकिन उचित फ़ायरवॉल, प्राधिकरण, एसीएल, आदि के साथ उन्हें बंद करने की उचित सावधानी बरतें।

— squillman
स्रोत

17

अस्पष्टता से सुरक्षा के विचार में (मजबूत) पासवर्ड और एन्क्रिप्शन का प्रक्षेपण मेरे स्वयं के विनम्र विचार में थोड़ा खिंचाव है ...

— स्क्वीमैन

5

वर्णमाला और संख्यात्मक वर्णों की पूरी श्रृंखला के साथ केवल 8 वर्णों का उपयोग करना (और विशेष वर्णों की अनुमति भी नहीं देना) संभव संयोजनों की संख्या 62 ^ 8 (218,340,105,584,896) है। पोर्ट स्कैन डिटेक्टरों को नियोजित करने पर भी 65535 उसी ब्रह्मांड में नहीं है। ध्यान दें, मैं कमजोर पासवर्डों पर छूट दे रहा हूं।

— स्क्विलमैन 19

3

फिर से , "ऐसा नहीं है जैसे कि गैर-मानक पोर्ट संपूर्ण सुरक्षा उपकरण है"। हर छोटी चीज़ मदद करती है। यह 10 सेकंड का ट्वीक है, अगर और कुछ नहीं, तो आपके सर्वर को एसएसएच की तलाश में किसी को दिखाने से रोकने के लिए जा रहा है ताकि दरवाजे पर दस्तक देना शुरू कर सकें।

— सिज्जोज

8

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

— स्क्विलमैन

6

मैंने गैर-मानक बंदरगाहों को जो देखा है, वह काफी मानक हो गया है। HTTP के लिए ssh, 1080, 8080, 81, 82, 8088 के लिए 2222। अन्यथा, यह भी अस्पष्ट हो जाता है और आपको आश्चर्य क्या सेवा पोर्ट 7201 पर है और आप 7102. पर ssh क्यों कनेक्ट नहीं कर सकता

— BillThor

13

यह अश्लीलता का एक मामूली स्तर है, लेकिन हैक करने के लिए सड़क पर एक महत्वपूर्ण गति-टक्कर नहीं है। यह लंबे समय तक समर्थन करने के लिए एक कठिन विन्यास है क्योंकि उस विशेष सेवा से बात करने के लिए अलग-अलग पोर्ट के बारे में बताना पड़ता है।

एक बार नेटवर्क वर्म से बचने के लिए यह एक अच्छा विचार था, क्योंकि यह केवल एक पोर्ट को स्कैन करने के लिए था। हालांकि, तेजी से बढ़ते कृमि का समय अब अतीत है।

— sysadmin1138
स्रोत

2

+1 कठिन कॉन्फिग & सपोर्ट इश्यू के लिए। आपको समय बर्बाद करने में मदद करता है जो दरवाजे को सुरक्षित करने पर खर्च किया जा सकता है (इसके बजाय यह जानने के लिए कि आपके घर पर आपने इसे कहाँ रखा है)।

— मैके सिप

12

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

मैं जोड़ना चाहूंगा कि पोर्ट नंबर बदलना वास्तव में आपकी सुरक्षा के लिए हानिकारक हो सकता है।

निम्नलिखित सरलीकृत परिदृश्य की कल्पना करें। एक पटाखा 100 मेजबान स्कैन करता है। इनमें से निन्यानबे मेजबान इन मानक बंदरगाहों पर उपलब्ध सेवाएं हैं:

Port    Service
22      SSH
80      HTTP
443     HTTPS

लेकिन फिर एक मेजबान है जो भीड़ से बाहर खड़ा है, क्योंकि वे सिस्टम के मालिक ने उनकी सेवाओं को बाधित करने की कोशिश की।

Port    Service
2222    SSH
10080   HTTP
10443   HTTPS

अब, यह एक पटाखा के लिए दिलचस्प हो सकता है, क्योंकि स्कैन दो चीजों का सुझाव देता है:

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

यदि आप एक पटाखा थे, तो क्या आप मानक बंदरगाहों पर 99 होस्ट्स में से एक पर मानक सेवाओं को चलाने के लिए एक नज़र रखना चाहेंगे, या यह एक होस्ट जो पोर्ट ऑबफ्यूजन का उपयोग कर रहा है?

— स्टीफन लासिवस्की
स्रोत

14

मैं 99 मेजबानों को देखता हूँ जब तक कि अनुभव ने मुझे अन्यथा सिखाया नहीं। यदि आप मुझसे पूछते हैं, तो संभवतया आसपास घूमने वाले बंदरगाहों को पैच और सुरक्षित करने की अधिक संभावना है।

— सिजयोज

4

मैं 1 मेजबान को देखता हूं जो बाहर खड़ा था, इस मौके पर कि कुछ PFY ने सोचा कि "अगर मैं पोर्ट नंबर बदलता हूं, तो मैं आमंत्रित कर रहा हूं!" लेकिन रूट पासवर्ड "पासवर्ड" पर सेट है।

— एंड्रयू

3

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

— क्रिस एस

1

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

— स्टीफन लासिवस्की

3

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

— टार्डेट करें

9

मैं सामान्य प्रवृत्ति के खिलाफ जाने वाला हूं, कम से कम आंशिक रूप से।

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

यहां यह स्थिति है क्योंकि यह मेरे सिस्टम पर लागू होता है: गैर-सार्वजनिक सेवाएं गैर-मानक पोर्ट पर चलाई जाती हैं। किसी एकल स्रोत पते से दो से अधिक पोर्ट के लिए किसी भी कनेक्शन का प्रयास, सफल या नहीं, उस स्रोत से सभी ट्रैफ़िक के समय की एक निश्चित मात्रा के भीतर गिरा दिया जाता है।

इस प्रणाली को हराने के लिए या तो भाग्य की आवश्यकता होती है (अवरुद्ध होने से पहले सही पोर्ट मारना) या एक वितरित स्कैन, जो अन्य उपायों को ट्रिगर करता है, या बहुत लंबे समय तक, जिस पर भी ध्यान दिया जाएगा और उस पर कार्रवाई की जाएगी।

— जॉन गार्डनियर्स
स्रोत

लक्ष्यित हमलों के बारे में एंड्रियास बोनीनी द्वारा इस बिंदु को मिलाएं और वैकल्पिक बंदरगाहों का उपयोग करने के लिए यह एक मजबूत तर्क है।

— जीवनअमारा

5

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

कुछ उदाहरण:

"यह लॉग को साफ करता है" - फिर आपको एक समस्या है कि आप अपने लॉग को कैसे संभाल रहे हैं।
"यह कनेक्शन ओवरहेड को कम करता है" - ओवरहेड या तो महत्वहीन है (जैसा कि सबसे अधिक स्कैनिंग है) या आपको किसी तरह के फ़िल्टरिंग की आवश्यकता है / Denial-of-Service शमन उपरिगामी
"यह एप्लिकेशन के एक्सपोज़र को कम करता है" - यदि आपका एप्लिकेशन स्वचालित स्कैनिंग और शोषण के लिए खड़ा नहीं हो सकता है, तो आपके एप्लिकेशन में गंभीर सुरक्षा कमियां हैं जिन्हें संबोधित करने की आवश्यकता है (यानी, इसे पैच रखें!)।

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

2

आप सही हैं कि यह बहुत अधिक सुरक्षा नहीं लाएगा (चूंकि टीसीपी सर्वर पोर्ट रेंज में केवल 16 बिट्स एन्ट्रापी हैं), लेकिन आप इसे दो अन्य कारणों से कर सकते हैं:

जैसा कि दूसरों ने पहले ही कहा है: कई लॉगिन की कोशिश करने वाले घुसपैठिये आपकी लॉग फाइल को अव्यवस्थित कर सकते हैं (भले ही सिंगल आईपी से डिक्शनरी फेल 2बान के साथ अवरुद्ध हो सकती है);
SSH को सुरक्षित सुरंग बनाने के लिए गुप्त कुंजियों का आदान- प्रदान करने के लिए सार्वजनिक कुंजी क्रिप्टोग्राफी की आवश्यकता है (यह एक महंगा ऑपरेशन है कि सामान्य परिस्थितियों में बहुत बार ऐसा करने की आवश्यकता नहीं होती है); बार-बार SSH कनेक्शन्स CPU शक्ति को बर्बाद कर सकते हैं ।

टिप्पणी: मैं यह नहीं कह रहा हूं कि आपको सर्वर पोर्ट को बदलना चाहिए। मैं पोर्ट नंबर बदलने के लिए उचित कारणों (IMO) का वर्णन कर रहा हूं।

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

— curiousguy
स्रोत

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

— पचेरियर

नहीं जब अधिक डिस्क उपयोग के कारण कंप्यूटर अनुपयोगी हो जाता है।

— जिज्ञासु

हाँ यह एक प्रदर्शन मुद्दा है। प्रदर्शन निश्चित रूप से भी महत्वपूर्ण है, लेकिन यह विशेष रूप से सुरक्षा के बारे में विशेष रूप से चर्चा कर रहा है। (इस सूत्र के प्रयोजन के लिए, बस आप Google के आकार की कल्पना करें, और Google वास्तव में विश्लेषण और / या बिक्री के उद्देश्यों के लिए उन डेटा को चाहता है।)

— Pacerier

1

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

स्वयं मैं अपनी निजी मशीनों पर वैकल्पिक पोर्ट पर sshd चलाता हूं, लेकिन यह मुख्य रूप से /var/log/auth.log में अव्यवस्था को कम रखने के लिए एक सुविधा के रूप में है। एक बहु-उपयोगकर्ता प्रणाली पर मैं वास्तव में ऊपर दिए गए छोटे काल्पनिक सुरक्षा लाभ पर विचार नहीं करता हूं, जो sshd द्वारा मानक भाग पर नहीं पाए जाने के कारण होने वाली अतिरिक्त परेशानी का पर्याप्त कारण है।

— andol
स्रोत

परिदृश्य केवल तभी मान्य होगा जब सभी व्यवस्थापक (ओं) को इस "अतिरिक्त समय" के साथ कभी भी दोपहर के भोजन और आदि में जाने के लिए कोई

— लेवे न हो

1

यह सुरक्षा को थोड़ा बढ़ाता है। इसमें हमलावर को खुला बंदरगाह मिला है जिसे अब बंदरगाह पर चल रहे व्हाट्सएप को काम करना है। आपकी कॉन्फ़िग फाइल्स (अभी तक :-)) तक पहुँच नहीं होने के कारण उन्हें पता नहीं है कि पोर्ट 12345 http, sshd, या एक हज़ार अन्य सामान्य सेवाओं में से एक है या नहीं, इसलिए उन्हें गंभीरता से लेने से पहले व्हाट्सएप चलाने के लिए अतिरिक्त काम करने की ज़रूरत है। उस पर हमला करो।

अन्य पोस्टर के रूप में भी बताया गया है कि पोर्ट 22 में प्रवेश करने का प्रयास करते समय, लिपियों की लिपि kiddies, ज़ोंबी ट्रोजन या यहां तक कि वास्तविक उपयोगकर्ता हो सकते हैं जिन्होंने एक आईपी पते को गलत बताया। पोर्ट 12345 में प्रवेश करने का प्रयास लगभग वास्तविक उपयोगकर्ता या गंभीर हमलावर होने के लिए निश्चित है।

एक और रणनीति के लिए कुछ "शहद जाल" बंदरगाहों है। जैसा कि कोई भी वास्तविक उपयोगकर्ता इन पोर्ट नंबरों के बारे में नहीं जानता है, तो किसी भी कनेक्शन के प्रयास को दुर्भावनापूर्ण माना जाना चाहिए और आप स्वचालित रूप से आपत्तिजनक आईपी पते को अवरुद्ध / रिपोर्ट कर सकते हैं।

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

— user23523
स्रोत

प्रासंगिक सुरक्षा में कमी के खिलाफ ~ 0.1% सुरक्षा वृद्धि का वजन किया जाना चाहिए , संभवत: उपयोग के मामले और संदर्भ के आधार पर सुरक्षा में कुल शुद्ध हानि हुई।

— 5

0

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

— Keiths
स्रोत