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


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

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

  1. पोर्ट स्कैनर मौजूद हैं
  2. यदि कोई आवेदन कमजोर है, तो यह इसके पोर्ट नंबर पर ध्यान दिए बिना बना रहता है।

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


64
2017-09-28 19:04


मूल


एक चीज जो मैंने किया है वह है कि कुछ डिफ़ॉल्ट बंदरगाहों (उदाहरण के लिए, एसएसएच पोर्ट 22) शहद के बर्तन के रूप में उपयोग करें। जो भी बंदरगाहों से जुड़ने का प्रयास कर रहा है वह पूरी तरह अवरुद्ध है xसमय की राशि। यह पोर्ट स्कैनिंग के खिलाफ प्रभावी साबित हुआ है। बेशक, यह सुरक्षा टूलबॉक्स में सिर्फ एक उपकरण है। - Belmin Fernandez
अस्पष्टता के माध्यम से सुरक्षा के बारे में सामान्य सवाल यहां पूछा गया है: security.stackexchange.com/questions/2430/... - Tony Meyer
अच्छी तरह से यह शायद "पटकथा बच्चों" के लिए एक बाधा - Lukasz Madon
@BelminFernandez, "सुरक्षा टूलबॉक्स में एक उपकरण"? नहीं, यह सर्वर लोड (प्रदर्शन) को कम करने के लिए है और है सुरक्षा के साथ कुछ नहीं करना इसके भ्रम के अलावा। सुरक्षा के अनुसार, सर्वर पूरी तरह से मजबूत है, और यदि सर्वर कमजोर है, तो यह पूरी तरह से अनावश्यक है, यह इसे और अधिक सुरक्षित नहीं बनाता है। - Pacerier
@Pacerier, सहमत हैं कि प्रयास और ध्यान अधिक ठोस सुरक्षा प्रथाओं को लागू करने पर होना चाहिए। हालांकि, ऐसा कोई कारण नहीं है कि आप दोनों क्यों नहीं कर सकते हैं। - Belmin Fernandez


जवाब:


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

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

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

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


66
2017-09-28 19:19



माना। एसएसएच को गैर मानक पोर्ट में ले जाने के साथ प्रयोग करते समय मैंने एक बहुत ही समान बूंद देखी। सौभाग्य से पासवर्ड ऑथ अक्षम के साथ, यह वास्तव में एक गैर-मुद्दा है। - EEAA
अब तक का सबसे अच्छा जवाब। यह सब नीचे आ रहा है किस पर हमला कर रहा है। मैंने एक बार व्यवस्थापक को एक प्रणाली की मदद की जो स्कैनिंग किड्डी से शून्य-दिन के हमले के साथ मारा गया। संभवतः एमएस-आरडीपी में क्योंकि हमारे पास फायरवॉल द्वारा आईआईएस का खुलासा नहीं किया गया था। हमारा मेजबान हमें आरडीपी पोर्ट (प्रबंधित होस्टिंग) को बदलने की इजाजत नहीं देगा, इसलिए मूल रूप से वहां बैठना पड़ा जब उन्होंने अपने आईडीएस / आईपीएस फ़िल्टरिंग के लिए एक नए पैटर्न पर काम किया। हालांकि यह एसएसएच जैसे अधिक स्थापित सर्वरों के लिए उतना अधिक मदद नहीं कर सकता है, जो कि कुछ एमएस उत्पादों की तुलना में कम सुरक्षा समस्याएं प्रतीत होता है। - Matt Molnar
निश्चित रूप से सहमत हैं। सुरक्षा परतों के बारे में सब कुछ है, और आपके जितना अधिक है, उतना ही सुरक्षित आप हैं। यह एक कमजोर परत हो सकती है, लेकिन फिर भी एक परत है। जब तक यह पूरी तरह से भरोसा नहीं किया जाता है, यह केवल सुरक्षा में जोड़ सकता है। - Paul Kroon
बंदरगाह 22 से एसएसएच को स्थानांतरित करने का एक और मुद्दा यह है कि बड़ी मात्रा में एसएसएच प्लस सेवाओं की कोशिश करता है क्योंकि विफल 2 बीन कभी-कभी मूल्यवान CPU समय ले सकता है। यह लाइन हार्डवेयर के शीर्ष पर नगण्य हो सकता है लेकिन कुछ पुराने सर्वर CPU स्पाइक्स का अनुभव कर सकते हैं। इसका सीपीयू समय, मेमोरी और बैंडविड्थ आप अन्य सामानों के लिए उपयोग कर सकते हैं। - artifex
मैंने सर्वर 2003 पर आरडीपी के साथ ऐसा किया है - यह इवेंट व्यूअर में विफल प्रमाणीकरण प्रविष्टियों की मात्रा पर काफी कटौती करता है। - Moshe


लॉग को साफ रखना बहुत उपयोगी है।

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

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


42
2017-09-28 22:58



अद्भुत भेद - ZJR
+1 यह बंदरगाह संख्याओं को बदलने के लिए सबसे अच्छा तर्क है जिसे मैंने कभी सुना है और अब तक केवल एक चीज है जो मुझे ऐसा करने के लिए लुभाने वाली है - squillman
+1 यह एक महान बिंदु है। लक्ष्यित खतरे यादृच्छिक जांच से कहीं अधिक खतरनाक हैं (यदि आपके पास कोई सभ्य सुरक्षा है तो स्क्रिप्ट किड्स केवल आसान लक्ष्य पर आगे बढ़ती हैं)। लक्षित हमलावर विशिष्ट भेद्यता या यहां तक ​​कि पासवर्ड पैटर्न के बारे में बहुत कुछ जान सकता है। बंदरगाह 22 पर स्पैम के झुंड के बाहर इन हमलों को पहचानने में सक्षम होना अच्छा है। - Steven T. Snyder
यह गलत है। मैंने देखा है कि कम-से-कम एक सर्वर गैर-मानक एसएसएच पोर्ट पर स्कैन के माध्यम से समझौता किया जाता है। कोई अंतर्निहित कारण नहीं है कि हमलावर अन्य बंदरगाहों को स्कैन करने में सक्षम नहीं होगा। - Sven Slootweg
@SvenSlootweg, सच है, खासकर कंप्यूटर तेजी से और सस्ता हो रहा है, एक स्कैन 65535 गुना अधिक समय ले रहा है अब नहीं है बहुत लंबे समय तक और भी - Pacerier


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

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

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


28
2017-09-28 19:10



अस्पष्टता द्वारा सुरक्षा के विचार में (मजबूत) पासवर्ड और एन्क्रिप्शन का प्रक्षेपण एक छोटा सा हिस्सा है, मेरी विनम्र राय में ... - squillman
वर्णमाला और संख्यात्मक वर्णों (और विशेष वर्णों की अनुमति भी नहीं) की पूरी श्रृंखला के साथ केवल 8 वर्णों का उपयोग करना संभव संयोजनों की संख्या 62 ^ 8 (218,340,105,584,896) है। 65535 उसी ब्रह्मांड में भी नहीं है, भले ही पोर्ट स्कैन डिटेक्टरों को नियोजित किया जाए। नोट, मैं कमजोर पासवर्ड छूट रहा हूँ। - squillman
फिर, "ऐसा नहीं है कि गैर-मानक पोर्ट संपूर्ण सुरक्षा उपकरण है"। हर छोटी चीज़ मदद करती है। यह एक 10 सेकंड ट्विक है कि, यदि कुछ और नहीं है, तो आपके सर्वर को दरवाजे पर दस्तक देने के लिए एसएसएच की तलाश में किसी को दिखाए जाने से रोकने जा रहा है। - ceejayoz
भावहीन। गैर-मानक बंदरगाहों का ट्रैक रखना मेरी पुस्तक में इसके लायक नहीं है। मैं किसी से असहमत होने के लिए सहमत हूं ... बंदरगाह को बदलने से परे आगे के प्रतिद्वंद्वियों को जोड़ना निश्चित रूप से समीकरण का हिस्सा है और मैं पहेली के उन टुकड़ों तक चीजों को छोड़ दूंगा। - squillman
मैंने जो देखा है उससे गैर-मानक बंदरगाह काफी मानक बन गए हैं। HTTP के लिए एसएसएच, 1080, 8080, 81, 82, 8088 के लिए 2222। अन्यथा, यह बहुत अस्पष्ट हो जाता है और आपको आश्चर्य है कि पोर्ट 7201 पर कौन सी सेवा है और आप 7102 पर एसएसएच से क्यों कनेक्ट नहीं हो सकते हैं। - BillThor


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

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


13
2017-09-28 19:10



कड़ी कॉन्फ़िगरेशन और समर्थन समस्या के लिए +1। आपको उस समय को बर्बाद कर देता है जिसे दरवाजा सुरक्षित करने के लिए खर्च किया जा सकता है (इसके बजाय आपके घर पर कहां रखा गया है)। - Macke


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

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

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

Port    Service
22      SSH
80      HTTP
443     HTTPS

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

Port    Service
2222    SSH
10080   HTTP
10443   HTTPS

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

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

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


12
2017-09-28 19:45



मैं 99 मेजबानों को तब तक देखता हूं जब तक अनुभव मुझे अन्यथा सिखाया न जाए। यदि आप मुझसे पूछते हैं तो कोई भी जो आसपास के बंदरगाहों को ले जा रहा है, पैच और सुरक्षित होने की अधिक संभावना है। - ceejayoz
मैं उस मेजबान को देखता हूं जो बाहर खड़ा था, इस मौके पर कि कुछ पीएफवाई ने सोचा था "अगर मैं बंदरगाह संख्या बदलता हूं, तो मैं अविश्वसनीय हूं!" लेकिन रूट पासवर्ड "पासवर्ड" पर सेट है। - Andrew
@Ceejayoz, पूरी तरह से सहमत हैं। मैं 2222 को एसएसएच चला रहा हूं, कोई सुरक्षा मूल्य नहीं है लेकिन स्क्रिप्ट किड्स पर कटौती करता है। मुझे लगता है कि वे मुझे अनदेखा करने की अधिक संभावना रखते हैं, बंदरगाह को बदलने के लिए परेशान, शायद अन्य उपायों को भी लिया। जाहिर है यह सभी डिफ़ॉल्ट विन्यास नहीं है ... - Chris S
मैं समझता हूं कि हर कोई मेरी राय से सहमत नहीं है। लेकिन मेरे अनुभव में, कई सिस्टम मालिक थे जो पोर्ट-ओबफ्यूशन का उपयोग करेंगे, लेकिन कुछ गलती सुरक्षा भेद्यता के संपर्क में आने के बाद ओपनएसएसएच को अपडेट नहीं करने की तरह गलतियां होती हैं, या साझा विश्वविद्यालय प्रणाली से अनएन्क्रिप्टेड एसएसएच कुंजी का उपयोग करेंगे। इनमें से कुछ ये सिस्टम रसदार लक्ष्य थे। - Stefan Lasiewski
विस्तार से: एक गैर मानक पोर्ट पर जाने के लिए, आप स्क्रिप्ट किड्स को हतोत्साहित करने की अधिक संभावना रखते हैं, लेकिन एक अनुभवी हैकर साज़िश करने की अधिक संभावना है। जो सवाल पूछता है: आप किसके द्वारा लक्षित होने से ज्यादा डरते हैं? - tardate


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

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

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

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


9
2017-09-29 01:11



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


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

कुछ उदाहरण:

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

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


5
2017-09-29 16:56





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

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

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

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


2
2017-09-29 00:53



लॉग फ़ाइलों को आसानी से उचित फिल्टर के साथ uncluttered किया जा सकता है। यदि आप कम लॉग के कारण सर्वर प्रदर्शन के बारे में बात कर रहे हैं, तो हम अब सुरक्षा के बारे में बात नहीं कर रहे हैं। प्रदर्शन पूरी तरह से एक पूरी तरह से अलग विषय है। - Pacerier
जब अतिरिक्त डिस्क उपयोग के कारण कंप्यूटर अनुपयोगी हो जाता है। - curiousguy
हां यह एक प्रदर्शन मुद्दा है। प्रदर्शन निश्चित रूप से भी महत्वपूर्ण है, लेकिन यह विशेष धागा विशेष रूप से केवल सुरक्षा के बारे में चर्चा कर रहा है। (इस धागे के उद्देश्य के लिए, बस कल्पना करें कि आप Google-आकार हैं, और Google करता है वास्तव में विश्लेषण और / या बिक्री उद्देश्यों के लिए उन डेटा चाहते हैं।) - Pacerier


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

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


1
2017-09-28 19:55



परिदृश्य केवल तभी वैध होगा जब सभी व्यवस्थापक पूरी तरह से इस "अतिरिक्त समय" के साथ कोई छूट नहीं लेते हैं लंच के लिए जाओ और आदि। - Pacerier