रूट विशेषाधिकार प्राप्त करने का सबसे सुरक्षित तरीका कौन सा है: सुडो, सु या लॉगिन?

Question

यदि मेरा अप्रभावी उपयोगकर्ता समझौता कर रहा है, तो मैं सुरक्षा में रूट खाता रखना चाहूंगा।

Ubuntu पर आप केवल डिफ़ॉल्ट रूप से "सुरक्षा कारणों" के लिए sudo का उपयोग कर सकते हैं। हालाँकि मुझे यकीन नहीं है कि यह केवल टेक्स्ट-मोड कंसोल पर लॉगिन का उपयोग करने की तुलना में सुरक्षित है। बहुत सी चीजें हैं जो गलत हो सकती हैं अगर कोई हमलावर मेरे सामान्य उपयोगकर्ता के रूप में कोड चला सकता है। उदाहरण के लिए, उपनाम जोड़ने के लिए, मेरे पेट में सामान जोड़ना, केवल कुछ का उल्लेख करने के लिए LD_PRELOAD और X11 keyloggers सेट करना। एकमात्र फायदा जो मैं देख सकता हूं वह है टाइमआउट तो मैं कभी भी लॉग आउट करना नहीं भूलता।

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

टेक्स्ट-मोड कंसोल पर लॉगिन सबसे सुरक्षित लगता है। चूंकि यह init द्वारा शुरू किया जाता है यदि कोई हमलावर PATH या LD_PRELOAD को नियंत्रित कर सकता है तो वह पहले से ही जड़ है। X पर चलने वाले प्रोग्राम्स के द्वारा कीपर्स इवेंट्स को इंटरसेप्ट नहीं किया जा सकता। मुझे नहीं पता कि X पर चलने वाले प्रोग्राम्स [ctrl] + [alt] + [f1] को इंटरसेप्ट कर सकते हैं (या कंसोल की तरह दिखने वाली फुलस्क्रीन विंडो खोलें) या यह विंडोज़ पर [ctrl] + [alt] + [del] की तरह सुरक्षित है। इसके अलावा जो एकमात्र समस्या मुझे दिखाई देती है वह है टाइमआउट की कमी।

तो क्या मुझे कुछ याद आ रहा है? उबंटू वालों ने केवल सूडो की अनुमति देने का फैसला क्यों किया? किसी भी तरीके की सुरक्षा को बेहतर बनाने के लिए मैं क्या कर सकता हूं?

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

• SSH के माध्यम से रूट की अनुमति दें
• टेक्स्ट-मोड पर स्विच करें
• रूट के रूप में लॉग इन करें
• दूसरी मशीन के लिए ssh
• रूट के रूप में लॉग इन करें

Comments

आपके ssh समाधान में, क्या आपका मतलब यह है कि आप किसी अन्य बॉक्स से संभावित शामिल बॉक्स में ssh करना चाहते हैं? 1 / यदि हाँ, तो, अपने विचार की ट्रेन का पालन करने के लिए, आपको यह सुनिश्चित करना होगा कि इससे पहले कि आप अपने दूसरे बॉक्स से समझौता न करें। 2 / यदि नहीं, तो आपको भी यही समस्या है।

— asoundmove

@asoundmove: मेरे ssh स्थिति वाले 4 उपयोगकर्ता हैं: root @ hosta, root @ hostb, stribika @ hosta, stribika @ hostb। एक हमलावर की मानें तो दोनों stribikas के रूप में मनमाना कोड चला सकते हैं (आखिरकार वे फ़्लैशप्लगिन और whatnot चला रहे हैं) मैं अभी भी सुरक्षित रूट एक्सेस चाहता हूं। तो दोनों बॉक्स को आंशिक रूप से समझौता किया जा सकता है।

— स्ट्रिबिका

Answer 1

सुरक्षा हमेशा ट्रेड-ऑफ बनाने के बारे में है। बस लौकिक सर्वर जो एक सुरक्षित में है की तरह, अनप्लग, समुद्र के तल पर, rootहो सकता है सबसे सुरक्षित अगर वहाँ सब पर इसे उपयोग करने में कोई रास्ता नहीं थे।

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

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

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

याद रखें कि अधिकांश "साइबर-क्राइम" भीतर से आता है। वर्णित रूट पासवर्ड की स्थिति के साथ, यह ट्रैक करना मुश्किल है कि किसने क्या किया - सुदूर लॉगिंग सौदों के साथ कुछ सूडो बहुत अच्छी तरह से।

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

पासवर्ड का उपयोग करना बिल्कुल के बाद से पासवर्ड-सूँघने trojaned ssh डेमॉन वास्तविक दुनिया प्रणाली समझौता मैंने देखा है की 90% की तरह कुछ में जगह में डाल रहे हैं SSH के लिए, खतरनाक है। SSH कुंजियों का उपयोग करना बेहतर है, और यह रिमोट रूट एक्सेस के लिए भी एक व्यावहारिक प्रणाली हो सकती है।

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

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

यह शायद घर के लिए ओवरकिल है, हालांकि, जहां आपके पास वास्तव में प्रबंधन की बाधाएं नहीं हैं - जब तक आप समझदार सुरक्षा प्रथाओं का पालन करते हैं।

Comments

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

— स्ट्रिबिका

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

— जॉर्ग डब्ल्यू मित्तग

पासवर्ड सूँघने ट्रोजन ssh डेमन? यदि वे ssh डेमॉन को बदल सकते हैं, तो उनके पास पहले से ही रूट है।

— Psusi

@ अपुस्सी: हां, उस सिस्टम पर; ऐसे वातावरण में जहाँ कई प्रणालियों के बीच पासवर्ड (एक निर्देशिका सेवा द्वारा) साझा किए जाते हैं, इस तरह से समझौता करना आसान है। यहां तक ​​कि जब यह एक एकल प्रणाली है, तो समझौता पता लगने के बाद पुनर्स्थापना के बाद हर किसी के पासवर्ड को फिर से जमा करने में परेशानी होती है।

— mattdm

आपकी कंपनी के सभी rootपासवर्डों को बदलने की संभावित कठिनाइयों को ओपीएस रिपोर्ट कार्ड में अंतिम आइटम के रूप में भी उल्लेख किया गया है , जो अच्छी तरह से पढ़ने योग्य है।

— वाइल्डकार्ड

Answer 2

यह एक बहुत ही जटिल प्रश्न है। mattdm पहले से ही कई बिंदुओं को कवर कर चुका है ।

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

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

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

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

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

Comments

यदि वे आपका पासवर्ड पा सकते हैं, तो वे रूट पासवर्ड को आसानी से नहीं तो आसानी से ढूंढ सकते हैं। इसके अलावा आप sysrq-k का उपयोग एक सुरक्षित ध्यान अनुक्रम के रूप में कर सकते हैं।

— Psusi

लिनक्स में सुरक्षा ध्यान कुंजी है, कर्नेल प्रलेखन

— btshengsheng

@btshengsheng लिनक्स कर सकते हैं एक "सुरक्षित ध्यान कुंजी" है, लेकिन जब से यह पता विन्यस्त किया जा सकता है, तो आप विश्वास है कि यह किसी विशेष मशीन पर काम कर रहा है नहीं हो सकता। यह कीबोर्ड लेआउट पर भी निर्भर है, इसलिए इसे चाबियों में से एक को पुन: असाइन करके बाईपास किया जा सकता है। इसे "सुरक्षित ध्यान कुंजी" कहा जाता है, लेकिन यह बिल के लिए उपयुक्त नहीं है।

— गाइल्स

Answer 3

सुरक्षित ओपनवॉल जीएनयू / * / लिनक्स डिस्ट्रो के डिजाइनरों ने भी su(रूट बनने के लिए) और पर महत्वपूर्ण राय व्यक्त की है sudo। आपको इस सूत्र को पढ़ने में रुचि हो सकती है:

... दुर्भाग्य से सु और सूद दोनों सूक्ष्म रूप से मौलिक रूप से त्रुटिपूर्ण हैं।

इसके अलावा suऔर अन्य चीजों की खामियों पर चर्चा करने के अलावा , सोलर डिज़ाइनर उपयोग करने के लिए एक विशेष कारण को लक्षित करता है su:

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

अपने डिस्ट्रो में, उन्होंने "डिफ़ॉल्ट इंस्टॉल में SUID रूट प्रोग्राम से पूरी तरह से छुटकारा पा लिया है" (यानी, सहित su, और वे इसके लिए क्षमताओं का उपयोग नहीं करते हैं):

सर्वर के लिए, मुझे लगता है कि लोगों को पुनर्विचार करने की आवश्यकता है और ज्यादातर मामलों में, उपयोगकर्ताओं द्वारा सु और सुडो के आह्वान को अस्वीकार कर दिया जाता है। गैर-रूट के रूप में लॉगिंग और सीधे रूट (दो अलग-अलग सत्र) की तुलना में पुराने "लॉगिन को गैर-रूट के रूप में, फिर सु या सूडो से" सिसाडमिन "ज्ञान" में कोई अतिरिक्त सुरक्षा नहीं है। इसके विपरीत, सुरक्षा दृष्टिकोण से उत्तरार्द्ध दृष्टिकोण एकमात्र सही है,:

http://www.openwall.com/lists/owl-users/2004/10/20/6

(कई sysadmins की जवाबदेही के लिए, सिस्टम को कई रूट-विशेषाधिकार प्राप्त खातों का समर्थन करने की आवश्यकता होती है, जैसे उल्लू करता है।)

(एक्स के साथ डेस्कटॉप के लिए, यह मुश्किल हो जाता है।)

तुम भी पूरी तरह से निपटने के लिए है ...

Btw, वे बदलने के लिए थे suloginसाथ msuloginअनेक रूट खातों के साथ सेटअप अनुमति देने के लिए: msuloginएक भी उपयोगकर्ता नाम लिखने पर जब एकल उपयोगकर्ता मोड में जाने (और "जवाबदेही" की रक्षा) (इस जानकारी से आता है की अनुमति देता है में रूसी इस चर्चा ) ।

Comments

एक प्रणाली के लिए जो मूल रूप से एक फ़ायरवॉल होने के लिए होती है और अधिक नहीं यह ठीक है, लेकिन अगर आप एक यादृच्छिक उदाहरण के रूप में, mysql / postgresql / bind / powerdns / apache और whatnot को एक उत्पादन प्रणाली में चलाना चाहते हैं, तो आप शुरू करते हैं समस्याओं में चल रहे हैं, जितना कि वे एक्स के साथ वर्णन करते हैं। अनिवार्य रूप से उन्होंने सुरक्षा की एक डिग्री के लिए बहुत अधिक प्रयोज्य का कारोबार किया है; यह तय करना सिस्टम प्रशासक के लिए है कि क्या यह एक निष्पक्ष व्यापार है। व्यक्तिगत रूप से, मैं डेबियन से चिपका रहूंगा।

— शादुर

Answer 4

आपको लगता है कि sudoपर्यावरण चर का उपयोग हमेशा किया जाता है, लेकिन यह हमेशा ऐसा नहीं होता है। यहाँ sudo manpage का एक अंश दिया गया है:

पर्यावरण चर से निपटने के दो अलग-अलग तरीके हैं। डिफ़ॉल्ट रूप से, env_reset sudoers विकल्प सक्षम है। इसके कारण env_check और env_d sudoers विकल्पों द्वारा अनुमत चालान प्रक्रिया से चर के अलावा TERM, PATH, HOME, SHELL, LOGNAME, USER और USERNAME युक्त न्यूनतम वातावरण के साथ कमांड निष्पादित की जाती है। पर्यावरण चर के लिए प्रभावी रूप से एक श्वेतसूची है।

अगर, हालांकि, env_reset विकल्प sudoers में अक्षम है, तो env_check और env_delete विकल्पों द्वारा स्पष्ट रूप से अस्वीकार नहीं किए गए किसी भी चर को इनवॉइसिंग प्रक्रिया से विरासत में मिला है। इस मामले में, env_check और env_delete एक ब्लैकलिस्ट की तरह व्यवहार करते हैं। चूंकि सभी संभावित खतरनाक पर्यावरण चर को ब्लैकलिस्ट करना संभव नहीं है, डिफ़ॉल्ट env_reset व्यवहार का उपयोग प्रोत्साहित किया जाता है।

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

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

Comments

मेरा मतलब था कि अगर हमलावर मेरे रास्ते को नियंत्रित कर सकता है तो वह मुझे असली / usr / बिन / sudo के बजाय कुछ भी चला सकता है। उदाहरण के लिए / tmp / sudo जो प्रिंट Password: करता है वह कुछ भी नहीं दिखाता है जब मैं टाइप करता हूं, जो मैं उसे टाइप करता हूं वह भेजता है, कहते हैं कि पासवर्ड गलत है, फिर असली sudo निष्पादित करता है।

— स्ट्रिबिका

हम्म, मुझे लगता है कि इस मामले में आप बस खोल सकते हैं / usr / बिन / sudo खोल पर भरोसा करने के बजाय सीधे आप के लिए इसे खोजने के लिए। लेकिन आप सही हैं, यह एक ऐसी समस्या है जिसके बारे में मैंने नहीं सोचा था।

— सेड्रिक

@CedricStaub: जहां तक ​​मैं बता सकता हूं कि कोई भी ऐसा नहीं सोचता है। मैं पूरा रास्ता दे सकता हूं, लेकिन यह कोशिश कर सकता हूं: alias /usr/bin/sudo="echo pwned"इसके अलावा इसमें एक टन कार्यक्रम शामिल हैं (एक्स, एक्सटर्म, शेल) जिनमें से कोई भी पासवर्ड चुरा सकता है। इसलिए मैंने कहा कि सुरक्षित रूप से स्विच करने के साथ बहुत अधिक समस्याएं हैं।

— स्ट्रिबिका

क्या आपने इसकी कोशिश की? मैंने किया:bash: alias: `/usr/bin/sudo': invalid alias name

— maaartinus

@aaartinus: दिलचस्प है। यह ZSH में काम करता है।

— स्ट्रिबिका

Answer 5

सबसे सुरक्षित तरीका ssh लॉगिन है (कम से कम) 2048 लंबी कुंजी (पासवर्ड लॉगिन अक्षम के साथ) कुंजी को संग्रहीत करने के लिए भौतिक डिवाइस का उपयोग करके।

Comments

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

— stribika

@ श्रीबिका खैर, दोनों। यदि मशीन से समझौता किया जाता है तो भी आप अपनी चाबी को ढीला नहीं करेंगे। यह फैलने से रोकता है (पासवर्ड की सबसे बड़ी समस्या)।

— Let_Me_Be

Answer 6

मैं बस थोड़ा सा विषय जोड़ना चाहता हूं। (विषय के लिए एक चेक '/ बिन / सु -' के बाद यहाँ)

मुझे लगता है कि उपरोक्त "सुरक्षा" को उस वास्तविक डेटा से भी जोड़ा जाना चाहिए जिसे हम सुरक्षित करना चाहते हैं।

अगर हम सुरक्षित करना चाहते हैं तो यह अलग होगा और यह होना चाहिए: my_data, my_company_data, my_company_detwork।

आमतौर पर, अगर मैं सुरक्षा के बारे में बोलता हूं तो मैं "डेटा सुरक्षा" और बैकअप के बारे में भी बोलता हूं। हम फॉल्ट-टॉलरेंट सिस्टम और लाइक भी जोड़ सकते हैं।

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

उबंटू का लक्ष्य था, और ज्यादातर अभी भी है, अंतिम उपयोगकर्ता: सूडो डिफ़ॉल्ट है।

फेडोरा रेडहैट का मुफ्त संस्करण है जो बदले में अधिक सर्वर उन्मुख है: सूडो को अक्षम किया जाता था।

अन्य वितरणों के लिए मुझे कोई प्रत्यक्ष जानकारी नहीं है।

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

बाकी के लिए मुझे लगता है कि @mattdm बहुत सटीक था।

लेकिन इसे सही बॉक्स में डालें। मान लें कि एक स्क्रिप्टिंग स्मार्ट किट को मेरे डेटा तक पहुंच मिलती है। आपको क्या लगता है कि वह इसके साथ क्या करने जा रहा है? - मेरी तस्वीरें प्रकाशित करें? मेरे? - मेरी प्रेमिका का नाम जानने और उसे बताने की कोशिश कर रहा हूं कि मैं पोर्नो साइटों पर जाता हूं?

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

पहले मामले के लिए, मैंने ऊपर उल्लेख किया, नेटवर्क सुरक्षा की तुलना में बैकअप पर बेहतर प्रयास करना। हां, आप बच रहे हैं। मेरा मतलब है कि हार्डवेयर क्रैश अलग नहीं है।

दूसरा मामला अधिक सूक्ष्म है। लेकिन इन गतिविधियों के बारे में संकेत हैं। किसी भी मामले में, आप संभव कर सकते हैं, लेकिन मैं अपने घर पीसी को आतंकवादी हमलों से बचाने के लिए कॉन्फ़िगर नहीं करूंगा!

मैं अन्य परिदृश्यों को छोड़ दूंगा।

चीयर्स एफ

Answer 7

चिंता यह है कि एक समझौता किया उपयोगकर्ता खाते के लिए प्रयोग किया जाता पासवर्ड सूंघ करने के लिए इस्तेमाल किया जा सकता है, तो sudoया su, तो के लिए एक एक बार की पासकोड का उपयोग sudoऔर su।

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

Answer 8

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

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

बेशक संगठनात्मक कार्य और वर्कफ़्लो हैं, सिस्टम को सुरक्षित करने के लिए।