SSH के माध्यम से रूट लॉगिन इतना बुरा क्यों है कि हर कोई इसे अक्षम करने की सलाह देता है?

Question

इंटरनेट पर हर कोई SSH के माध्यम से रूट लॉगिन को अक्षम करने की सलाह देता है क्योंकि यह एक बुरा अभ्यास और सिस्टम में एक सुरक्षा छेद है, लेकिन कोई भी यह नहीं बताता है कि ऐसा क्यों है।

रूट लॉगिन (विशेष रूप से अक्षम पासवर्ड लॉगिन के साथ) को सक्षम करने में कितना खतरनाक है?

और मामले के प्रतीक प्रमाणीकरण में X प्रतीक उपयोगकर्ता नाम और Y प्रतीक पासवर्ड या रूट उपयोगकर्ता नाम और सुरक्षा बिंदु से X + Y प्रतीक पासवर्ड के बीच अंतर क्या है?

Comments

अधिकांश सिस्टम में एक रूट उपयोगकर्ता होना अपने आप में बुरा है, अकेले छोड़ दें ताकि उपयोगकर्ता के लिए SSH लॉगिन सक्षम हो सके!

— सुमन

Sh के माध्यम से रूट लॉगिन ehealth-aussie.blogspot.com/2012/01/… के लिए आवश्यक है । सब कुछ एक समझौता है।

— एमोरी

उम्म ... क्या हमें इस प्रश्न को सुरक्षा में स्थानांतरित करना चाहिए? चूँकि विषय सुरक्षा की ओर अधिक झुक गया है।

— ब्रिअम

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

— फिलिप युग्म

Answer 1

SSH पर जड़ क्यों खराब है

वहाँ बहुत सारे बॉट हैं जो SSH के ऊपर आपके कंप्यूटर में लॉग इन करने की कोशिश करते हैं। ये बॉट निम्नलिखित तरीके से काम करते हैं।

वे कुछ ऐसा निष्पादित करते हैं ssh root@$IPऔर फिर वे "रूट" या "पासवर्ड123" जैसे मानक पासवर्ड आज़माते हैं। वे ऐसा तब तक करते हैं जब तक वे सही पासवर्ड नहीं पाते हैं। एक विश्व व्यापी सुलभ सर्वर पर आप अपनी लॉग फ़ाइलों में बहुत सी लॉग प्रविष्टियाँ देख सकते हैं। मैं 20 प्रति मिनट या अधिक तक जा सकता हूं।

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

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

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

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

टिप्पणियों में यह उल्लेख किया गया था कि एक सामान्य उपयोगकर्ता को उपयोग करने का अधिकार हो सकता है sudoऔर अगर इस उपयोगकर्ता के पासवर्ड से यह अनुमान लगाया जाएगा कि सिस्टम पूरी तरह से भी खो गया है।

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

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

SSH पर पासवर्ड खराब क्यों हैं

पासवर्ड को निष्क्रिय करने का कारण वास्तव में सरल है।

• उपयोगकर्ता खराब पासवर्ड चुनते हैं!

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

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

लेकिन जब आप लॉग इन करने के लिए प्रमाणपत्र का उपयोग करते हैं, तो उपयोगकर्ता अपना पासवर्ड नहीं चुनता है। प्रमाणपत्र एक यादृच्छिक स्ट्रिंग पर आधारित है जो 1024 बिट्स से 4096 बिट्स (~ 128 - 512 चरित्र पासवर्ड) तक बहुत लंबा है। इसके अतिरिक्त यह प्रमाणपत्र केवल आपके सर्वर में लॉग इन करने के लिए है और किसी भी बाहरी सेवाओं के साथ इसका उपयोग नहीं किया जाता है।

लिंक

http://bsdly.blogspot.de/2013/10/the-hail-mary-cloud-and-lessons-learned.html

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

Comments

अच्छा सारांश। लेकिन ssh प्राइवेट कीज़ चोरी भी हो सकती हैं।

— फहीम मीठा

@ फहीम मीठा हाँ, लेकिन चोरी अनुमान से अलग है, जो बॉट करते हैं। इसके अलावा आपकी निजी कुंजी केवल आपके हाथों (या हार्ड ड्राइव) पर होती है न कि स्टैक एक्सचेंज या Google जैसी तृतीय पक्षों के हाथों में।

— राफेल एहरेंस

+1। यह जवाब वास्तव में बस नीचे उबाल सकता है N*M > N। चूंकि अधिकांश * निक्स होस्ट में एक rootउपयोगकर्ता होता है, यदि आप रूट को दूरस्थ होस्ट से सीधे लॉग इन करने की अनुमति देते हैं, तो परीक्षण मैट्रिक्स का आकार पासवर्ड को आज़माने की संख्या है; प्रत्यक्ष रूट लॉगिन को अस्वीकार करना, आपके द्वारा परीक्षण किए जाने वाले उपयोगकर्ता नाम की संख्या के साथ संभावित संयोजनों की संख्या को गुणा करना (और अभी भी कोई गारंटी नहीं है कि आप वैध उपयोगकर्ता नामों का परीक्षण करेंगे!)।

— बजे एक CVn

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

— राफेल एहरेंस

@ हर कोई, यदि उपयोगकर्ता के पास एक्स सिंबल और पासवर्ड Y है तो कोशिश करने के लिए # of X length words* # of Y length wordsसंभव संयोजन हैं। जब उपयोगकर्ता नाम तय हो जाता है (जैसे रूट) लेकिन पासवर्ड X + Y प्रतीक लंबा होता है, तो # of X+Y length wordsसंभव पासवर्ड होते हैं। और # of X+Y length words=# of X length words * # of Y length words

— skarap

Answer 2

ये कुछ कारण हो सकते हैं जिनकी वजह से सीधे रूट लॉगिन की अनुमति नहीं दी जानी चाहिए।

• Bruteforce प्रयास। सीधा रूट लॉगिन एक सफल bruteforce हमले पर अधिक नुकसान हो सकता है।
• "पासवर्ड रहित" SSH कुंजी (मानव त्रुटि होती है) पर मिसकॉन्फ़िगरेशन आपकी मशीन को इंटरनेट पर उजागर कर सकता है

लेकिन यह सिर्फ हिमखंड का टीआईपी है। आपको अन्य प्रतिबंधों और कॉन्फ़िगरेशन को कॉन्फ़िगर करने की आवश्यकता है जैसे:

• डिफ़ॉल्ट पोर्ट बदलें (22)
• मजबूत पासवर्ड और पासफ़्रेज़
• होस्ट-आधारित प्रमाणीकरण अक्षम करें
• अनुमत उपयोगकर्ताओं की एक सूची बनाएँ
• निष्क्रिय टाइमआउट कॉन्फ़िगर करें
• बल SSHv2 प्रोटोकॉल
• खाली पासवर्ड अक्षम करें
• एक उपाय के रूप में bruteforce फिर से विफल 2 का प्रयोग करें
• सब कुछ लॉग इन करें
• SSH कुंजियों को कॉन्फ़िगर करें, और केवल .ssh / अधिकृत_keys पर सार्वजनिक कुंजियों पर भरोसा करें

Comments

"सीधे रूट लॉगिन एक सफल bruteforce हमले पर अधिक नुकसान हो सकता है।" वास्तव में नहीं, अगर एक डिफ़ॉल्ट sudoसेटअप के साथ तुलना की जाती है । असली हत्यारा वह गुणात्मक प्रभाव है जब आपके पास कोई एक उपयोगकर्ता नाम नहीं होता है जिसे आप किसी भी होस्ट पर मान्य होने पर भरोसा कर सकते हैं।

— बजे एक CVn

@ माइकलकॉर्जलिंग - हाँ, यह सुनिश्चित करने के लिए कि गड़बड़ सूडो पर्मिट्रूट की तरह हार्मफुल हो सकती है;)

देखें unix.stackexchange.com/a/2944/9454

— मार्टिन श्रोडर

पोर्ट को बदलना वास्तव में अपने आप में कई परिदृश्यों में हानिकारक है। और यह अश्लीलता के साथ-साथ सुरक्षा से ज्यादा कुछ नहीं है।

— 0xC0000022L

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

— एरिक ग्रेंज

Answer 3

आप सही हैं कि रूट उपयोगकर्ता नाम और X + Y प्रतीक पासवर्ड क्रिप्टोग्राफिक रूप से कम से कम एक X प्रतीक उपयोगकर्ता नाम + Y प्रतीक पासवर्ड के रूप में सुरक्षित है। वास्तव में यह और भी अधिक सुरक्षित है, क्योंकि लोगों के नामों का अनुमान लगाना आसान है (बॉट सिर्फ जॉन, माइक, बिल आदि की कोशिश कर सकते हैं ... और btw: कि उनमें से कई रूट की कोशिश करने के बजाय क्या करते हैं)। और आप विशेष रूप से भाग्य से बाहर हैं अगर यह एक लक्षित हमला है, तो कोई व्यक्ति किसी कंपनी के सर्वर को तोड़ना चाहता है, तो यह समस्या का पता लगाने के लिए नहीं होगा।

और जैसे ही हमलावर के खाते में पहुंच होती है sysadmin ssh logins के लिए उपयोग करता है (और फिर अपने कार्यों का उपयोग करता है suया करता sudoहै) वह उस उपयोगकर्ता के सत्र को एक प्रोग्राम के साथ संक्रमित कर सकता है जो हमलावर रूट पासवर्ड भेजेगा जब sysadin प्रकार कि अगले समय।

यह किसी भी प्रकार के रूट लॉगिन हैं जो सुरक्षा के दृष्टिकोण से बुरे व्यवहार हैं (या होने चाहिए)। "सामान्य" उपयोगकर्ता लॉगिन -> su / sudo श्रृंखला एक ऑडिट ट्रेल जोड़ता है। सादे अंग्रेजी में: यह पता लगाना संभव बनाता है कि किसने क्या किया।

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

Answer 4

रूट लॉगिन (विशेष रूप से अक्षम पासवर्ड लॉगिन के साथ) को सक्षम करने में कितना खतरनाक है?

हमलावर (बॉट / बॉटनेट / हैकर) को केवल पासवर्ड का अनुमान लगाने की आवश्यकता है और आपके सिस्टम पर पूरा नियंत्रण है, यदि आप इंटरनेट पर खुले हैं। इसके अलावा, सिस्टम खातों (www-data, प्रॉक्सी, आदि) में से कोई भी समान कारणों से SSH के माध्यम से लॉगिन करने में सक्षम होना चाहिए।

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

और मामले के प्रतीक प्रमाणीकरण में X प्रतीक उपयोगकर्ता नाम और Y प्रतीक पासवर्ड या रूट उपयोगकर्ता नाम और सुरक्षा बिंदु से X + Y प्रतीक पासवर्ड के बीच अंतर क्या है?

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

इस मामले में सार्वजनिक कुंजी भी एक से अधिक है, क्योंकि:

1. हमलावर को आपकी सार्वजनिक कुंजी की आवश्यकता होती है
2. हमलावर को उन्नत विशेषाधिकार प्राप्त करने के लिए पासवर्ड (या प्रमाणीकरण विधि) की आवश्यकता होती है

Comments

मेरे द्वारा उपयोग किए जाने वाले बहुत कम पासवर्ड लगभग 20 यादृच्छिक अल्फ़ान्यूमेरिक वर्ण (सेट [A-Za-z0-9] प्लस कुछ विशेष वर्ण) से कम हैं। इस तरह के २० अक्षर (४० के एक चरित्र के २० में से २० लंबाई) आपको १० ^ ३२ संयोजनों के क्रम पर देते हैं। एन्ट्रापी के 128 बिट्स 10 ^ 38 के क्रम पर है। बहुत बड़ा अंतर नहीं है, सभी चीजों पर विचार किया गया है, और एसएसएच सर्वर किसी भी तरह की दर को लागू करने के लिए स्वतंत्र है, जो इसे पसंद करता है, इसलिए ऐसा नहीं है कि आप उस मामले में एक ऑफ़लाइन जानवर बल हमला कर रहे हैं। पासवर्ड के साथ कुछ भी गलत नहीं है, अगर आप 128-बिट कुंजी के रूप में याद रखने में मुश्किल हो सकते हैं।

— बजे एक CVn

@michael shh ... सीमा न दें, अब हैकर्स को पता है कि उन्हें 20 वर्णों के आदेश का इंद्रधनुष तालिकाओं का उपयोग करना चाहिए ...?

— Braiam

@ ब्रायम रेनबो टेबल केवल तभी उपयोगी है जब हमलावर के पास ऑफ़लाइन खोज करने के लिए हैश की पहुंच हो। यहां मामले में, हमलावर के पास सत्यापित करने के लिए केवल सर्वर प्रतिक्रिया है, जो संभवतः केवल इतने प्रयासों तक ही सीमित है - और बहुत धीमा।

— पीटर

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

— ब्रिएम

अगर आपको कुछ 1.8 * 10 ^ 35 पासवर्ड की कोशिश करने का मन करता है (और यह सिर्फ 40 के सेट के बाहर 18-22 यादृच्छिक वर्णों के लिए है, और आपको पता नहीं है कि सेट के बाहर कौन से अक्षर हैं- A-Za-z0- 9] मैं उपयोग करता हूं), मैंने कहा कि लगभग मज़े करो। यह लगभग 117.1 बिट्स एन्ट्रापी समतुल्य है (2 ^ 117.1 ~ 1.78 * 10 ^ 35) और @Peter की तरह, आपको सबसे अधिक संभावना है कि आपको ऑनलाइन हमला करना होगा। उन सभी पासवर्ड (संपीड़न का सहारा लिए बिना) को संग्रहीत करना लगभग 3.6 * 10 ^ 36 बाइट्स या 3 * 10 ^ 24 TiB (और अगर वह आंकड़ा परिमाण के कुछ आदेशों द्वारा गलत है, तो कौन परवाह करता है? ) की आवश्यकता के रूप में सामने आता है । कीवर्ड यादृच्छिक ।

— बजे एक सीवीएन जूल

Answer 5

जब तक आप सुरक्षा सावधानी बरतते हैं, यह बिल्कुल बुरा नहीं है। एक उदाहरण के रूप में आप CSF स्थापित कर सकते हैं (सर्वर फ़ायरवॉल कॉन्फ़िगर करें) और इसे अनुमत विफलता प्रयासों की संख्या निर्धारित करें, इसलिए यदि कोई व्यक्ति कोशिश करता है, तो हम 5 से अधिक असफल प्रयासों को कहते हैं ?, तो वे स्वचालित रूप से अवरुद्ध हो जाते हैं। तो सबसे अच्छा उत्तर देने वाले के पहले भाग में कोई समस्या नहीं होगी। यह मेरे साथ कई बार हुआ, और सौभाग्य से सभी परिचयकर्ता स्थायी रूप से अवरुद्ध हो गए। मैं एक सर्वर के लिए अनुमान लगाता हूं कि यह एक बड़ी समस्या नहीं है यदि आप एकमात्र व्यक्ति हैं जो सर्वर का प्रबंधन करते हैं, लेकिन निश्चित रूप से अगर बहुत सारे सिस्टम व्यवस्थापक हैं, या यदि आप किसी संगठन में काम कर रहे हैं, तो स्पष्ट रूप से उपयोग नहीं करते हैं जड़। डेस्कटॉप पीसी के लिए भी, मुझे लगता है कि किसी अन्य खाते का उपयोग करना बेहतर है क्योंकि आपके पास बहुत सारे सॉफ़्टवेयर का उपयोग करने के बाद से सुरक्षा जोखिम है, लेकिन एक सर्वर में, आप डॉन ' t बेतरतीब सॉफ़्टवेयर के लिए जाना जिस पर आपको भरोसा नहीं है, आप उन्हें यथासंभव कम रखना सुनिश्चित करते हैं। इसलिए निष्कर्ष यह है कि नहीं, यह वास्तव में हानिकारक नहीं है यदि आप जानते हैं कि किसी सर्वर को ठीक से कैसे प्रबंधित किया जाए।