जवाबों:
मेरे सभी सर्वर रूट अकाउंट डिसेबल ( sp_pwdpसेट टू *) हैं। यह sudoसभी रूट एक्सेस के लिए आवश्यक है । [१] इसका उद्देश्य सभी सुपरयूजर गतिविधियों का ऑडिट करना है, इसलिए लोग देख सकते हैं कि सिस्टम को क्या किया गया है।
अधिक कट्टर विकल्प के लिए, आप sudoएक लॉग फ़ाइल को लिख सकते हैं (जैसा कि विरोध किया जाता है syslog), और फ़ाइल को केवल एपेंड ( chattrलिनक्स पर, या chflagsबीएसडी पर उपयोग करके ) बना सकते हैं। इस तरह, कोई भी बाद में ऑडिट संपादित नहीं कर सकता है।
[१] मेरे पास रूट शेल नहीं चलाने की नीति है, या शेल करना रूट प्रक्रिया से बच जाता है। ( sudo sh -c '...'हालांकि, पाइपलाइन या पुनर्निर्देशन करने के लिए उपयोग करना ठीक है , हालांकि)
मैं मूल उपयोगकर्ता को अक्षम करने के खिलाफ सशक्त रूप से अनुशंसा करता हूं । रूट लॉगइन को अक्षम या प्रतिबंधित करें (सिक्योरिटी के माध्यम से और sshd_config के माध्यम से और PAM के माध्यम से और आपके पास क्या है) यदि आपका सिस्टम इसे अनुमति देता है, तो रूट के विशेषाधिकारों को सीमित करें या रूट भूमिका को विभाजित करें ( RSBAC इसे कैसे करता है।) लेकिन कृपया, कृपया , करें। पासवर्ड को हटाकर रूट खाते को अक्षम न करें, अन्यथा सिस्टम के माध्यम से लॉग इन करना असंभव हो जाएगा sulogin। suloginfsck द्वारा रिपोर्ट की गई गंभीर त्रुटियों के मामले में मेरे द्वारा ज्ञात सभी इनस्क्रिप्ट्स द्वारा उपयोग किया जाता है - और इसका मतलब है कि रूट फाइल सिस्टम के दूषित होने पर आपको सिस्टम से बाहर कर दिया जाएगा।
स्पष्ट करने के लिए: "पासवर्ड को हटाकर रूट खाते को अक्षम करने से" मेरा मतलब है कि विभिन्न तंत्र जो एक के साथ समाप्त होते हैं! या * / etc / छाया के पासवर्ड फ़ील्ड में, या इसी तरह का। मेरा मतलब यह नहीं है "रूट लॉगिन तंत्र बदलें ताकि आपको पासवर्ड के लिए संकेत न मिले।"
suया sudoआपके सिस्टम में होने का अर्थ है कि यदि आप केवल समर्पित उपयोगकर्ता हैं तो आप अधिक सुरक्षा जोखिम से बच सकते हैं। यह उल्लू सुरक्षित वितरण (और उनके बीच सौर डिजाइनर) के लेखकों द्वारा वकालत की गई स्थिति है - unix.stackexchange.com/questions/8581/… संदर्भों के साथ अपनी स्थिति पेश करने की कोशिश करता है।
fastbootविकल्प के साथ अपने दोषपूर्ण लिनक्स को बूट कर सकता हूं , रूट खाता अनलॉक कर सकता हूं और अंत में fsckमैन्युअल रूप से चला सकता हूं ।
मेरे पास अपने सभी सर्वरों पर रूट खाता सक्षम है। सभी व्यवस्थापकों के पास अपना उपयोगकर्ता है और उसी के माध्यम से लॉग इन करना है। वहां से वे रूट पर जाते हैं। (रूट ssh अक्षम है)
प्रशासक की गिनती कम रखें। केवल उस सर्वर पर रूट एक्सेस की आवश्यकता वाले लोगों के पास पासवर्ड है।
मैं सूडो का प्रशंसक नहीं हूं। रूट शेल के लिए 'सूडो बैश' करना बहुत आसान है। मुझे पता है कि यह अक्षम हो सकता है लेकिन परेशान क्यों हो? बस उन उपयोगकर्ताओं को सीमित करें जो व्यवस्थापक कार्य कर सकते हैं और प्रत्येक अभिभावक से बात कर सकते हैं। हमारे पास रूट टर्मिनलों को अप्राप्य नहीं खोलने की नीति है। तो यह लॉग इन है, सु, काम करते हैं, लॉग आउट करते हैं।
नोट: मैं एक काफी छोटी कंपनी में काम करता हूं (50-कुछ कर्मचारी) और हम केवल 2 अंशकालिक प्रवेशकों (1 खिड़कियां / 1 लिनक्स) के साथ आसपास आते हैं। चीजों को करने का यह तरीका सबसे अच्छा नहीं हो सकता है जब आपके पास अधिक उपयोगकर्ताओं के परिमाण के आदेश हों। मैं व्यक्तिगत रूप से अभी भी sudo का उपयोग नहीं करूँगा। रूट गतिविधि को लॉग करने के अन्य तरीके हैं।
रूट पासवर्ड को अक्षम करना एक गलत "अच्छा विचार" है। जिस दिन आपको इसकी आवश्यकता होगी, आपको वास्तव में इसकी आवश्यकता होगी। (आपके कॉन्फ़िगरेशन के अनुसार आपको छूट के लिए एकल उपयोगकर्ता मोड में लॉग इन करना पड़ सकता है)
रूट रिमोट लॉगिन को अक्षम करना प्रासंगिक हो सकता है लेकिन केवल तभी जब आप स्थानीय रूप से लॉग इन करने में सक्षम हों।
और हाँ, sudo को आपके हर एक सर्वर पर इंस्टॉल होना चाहिए। यह उपयोगी और कॉन्फ़िगर करने में आसान है। आप इसका उपयोग क्यों नहीं करना चाहेंगे?
Disabling root remote login might be relevant but only if you are able to log on locally.यह सिर्फ गलत तरीके से गलत है। आप किसी भी खाते से दूरस्थ रूप से लॉग इन कर सकते हैं; रूट रिमोट लॉगिन को अक्षम करने से आप स्थानीय पहुंच तक सीमित नहीं होते हैं।
मैं एसएसएच एक्सेस को रूट के लिए अक्षम करता हूं और ssh कीज़ का उपयोग करने के लिए उपयोगकर्ताओं (अक्सर सिर्फ डेवलपर्स) की आवश्यकता होती है। बहुत सारे शब्दकोश हमले हैं और SSH पोर्ट बदलना हमारे लिए कोई विकल्प नहीं है।
इस तरह आपको एक अच्छा पासवर्ड लिखने की किसी की क्षमता पर भरोसा करने की ज़रूरत नहीं है। एक बार बस अंदर प्रवेशकर्ताओं के पास सूडो के लिए अनुमति है।
मुझे पता है कि यह धागा वास्तव में पुराना है, लेकिन लिंक किए गए लेख तर्क में कुछ बड़ी खामियां हैं और मैं "रांटी" महसूस कर रहा हूं - सूदो दोनों को श्वेत सूची और ब्लैक लिस्ट करने की अनुमति देता है। केवल काले रंग से नहीं जैसा कि वे लिंक किए गए लेख में निर्दिष्ट करते हैं - यह एएए (प्रमाणीकरण, प्राधिकरण और लेखा परीक्षा) के विचार पर छोड़ देता है - सुए और सूडो दोनों ग्रेडेड प्रमाणीकरण और जवाबदेही के लिए अनुमति देते हैं।
परिदृश्य 1 एक व्यवस्थापक ने गलती से एक सिस्टम पर कुछ दुष्ट कोड पेश किए, जैसे कि कोड की पूरी पहुंच है और व्यवस्थापक को कभी पता नहीं चल सका कि क्या हुआ था। कम से कम वर्गीकृत लॉगिन (जैसे su / sudo) के साथ प्रशासक को यह प्रमाणित करने के लिए प्रेरित किया जाएगा कि अगर बदमाश कोड ऊंचे अधिकारों का उपयोग करने की कोशिश करता है ... अगर यह ऊंचा नहीं होता है तो इसके उपयोगकर्ताओं के अधिकारों तक सीमित हो जाना चाहिए जिसके परिणामस्वरूप न्यूनतम नुकसान होना चाहिए।
परिदृश्य 2 एक बदमाश व्यवस्थापक जानकारी प्राप्त करना / परिवर्तन करना चाहता है। वे कंसोल (भौतिक कंसोल एक्सेस, HP iLo / समान या vGuest कंसोल एक्सेस) से कनेक्ट होते हैं, रूट के रूप में लॉगिन करते हैं और जो कुछ भी चाहते हैं। जब तक कोई नामांकित खाता / एक्सेस कार्ड का उपयोग कंसोल पहुंच प्राप्त करने के लिए किया जाता है, तब तक शायद ऑडिट ट्रेल का ज्यादा हिस्सा नहीं होता है।
आपको पॉलिसी के रूप में प्रत्येक रूट कमांड के लिए सभी को sudo का उपयोग करना चाहिए। "सुडो बैश" या इस तरह से चलने का कोई कारण नहीं है, यह केवल सुविधा के लिए है, अज्ञानता के कारण, या किसी के ट्रैक को कवर करने के लिए।
यदि आप लॉगिन को सीधे रूट खाते में अक्षम करते हैं, तो गंभीर समस्या होने पर आप सिस्टम को ठीक करने की अपनी क्षमता को अपंग कर देते हैं।
यदि आप अपने प्रवेशकों को स्वयं के रूप में लॉग इन करने के लिए मना नहीं कर सकते हैं और रूट के रूप में चलने वाले प्रत्येक कमांड के लिए sudo चला सकते हैं, और इसे एक शेल में नहीं तोड़ सकते हैं, तो आपके पास गंभीर समस्याएं हैं जिनके लिए कोई तकनीकी समाधान नहीं है।
उल्लू सुरक्षित डिस्ट्रीब्यूशन (और सोलर डिज़ाइनर) के लेखकों के पास एक विपरीत रूप से उचित दृष्टिकोण है; देखते हैं, जैसे, जवाब /unix/8581/which-is-the-safest-way-to-get-root-privileges-sudo-su-or-login/8660#8660 के लिए उनके दावों की एक प्रस्तुति। सुपरसुअर कार्यों (जिस व्यक्ति ने क्या किया) की ऑडिटिंग की समस्या को उनके दृष्टिकोण में भी संबोधित किया जाता है (मूल रूप से, समाधान में विभिन्न नामों के साथ कई रूट उपयोगकर्ता हैं)।