'बिन' उपयोगकर्ता को लॉगिन शेल की आवश्यकता क्यों है?

Question

/var/log/auth.logमेरे एक सार्वजनिक वेबसर्वर के ऑडिट के दौरान , मैंने पाया:

Jan 10 03:38:11 Bucksnort sshd[3571]: pam_unix(sshd:auth): authentication failure; 
    logname= uid=0 euid=0 tty=ssh ruser= rhost=61.19.255.53  user=bin
Jan 10 03:38:13 Bucksnort sshd[3571]: Failed password for bin from 61.19.255.53 
    port 50647 ssh2

पहले ब्लश पर, यह sshयादृच्छिक हैकर्स से विशिष्ट लॉगिन स्पैम जैसा दिखता है; हालाँकि, जैसा कि मैंने करीब देखा, मैंने कुछ और देखा। अधिकांश असफल /var/log/auth.logप्रविष्टियाँ invalid userइस तरह कहती हैं :

Jan  9 10:45:23 Bucksnort sshd[3006]: Failed password for invalid user sales 
    from 123.212.43.5 port 10552 ssh2

उस विफल लॉगिन संदेश के बारे में अयोग्य बात binयह है कि यह एक मान्य उपयोगकर्ता है /etc/passwdजिसमें यहां तक ​​कि एक लॉगिन शेल भी है:

[mpenning@Bucksnort ~]$ grep ^bin /etc/passwd
bin:x:2:2:bin:/bin:/bin/sh

मैंने सोचा कि मैं सभी डिफ़ॉल्ट उपयोगकर्ता नाम है कि दूर से लॉग इन कर सकता है जब मैं अक्षम किया था PermitRootLoginमें /etc/ssh/sshd_config; इस प्रविष्टि की खोज ने मेरे पागल दिमाग में नई संभावनाओं को खोला। यदि किसी तरह सेवाएं चलती हैं bin, तो यह दूर से संभव है कि कोई व्यक्ति किसी binबॉक्स में चल रही सेवा से उपयोगकर्ता की निर्देशिका में एक ssh कुंजी डाल सके, इसलिए binयदि संभव हो तो मैं उपयोगकर्ता के लिए लॉगिन को पूरी तरह से अक्षम करना चाहूंगा ।

प्रशन

• यह सर्वर दूरस्थ है, और ठीक करने के लिए महंगा है (यानी मैं केवीएम, प्लस केवीएम किराए पर लेने के लिए दूरदराज के हाथों का भुगतान करूंगा)। मैं यह पता लगाने की कोशिश कर रहा हूं कि अगर मैं इस तरह दिखने के /etc/passwdलिए प्रविष्टि को बदलता हूं तो मैं क्या तोड़ सकता हूं bin:

  bin:x:2:2:bin:/bin:/bin/false

• मैंने निम्नलिखित आदेशों को चलाने की कोशिश की कि इसके लिए क्या binआवश्यक है ... हालांकि, ये आदेश बिना फ़ाइलों के साथ आए और मुझे कोई प्रक्रिया नहीं मिल सकी bin। binवैसे भी उपयोगकर्ता क्या करता है?

  $ sudo find / -group bin

  $ sudo find / -user bin

• क्या कोई अन्य उपयोगकर्ता हैं जिन्हें अपना लॉगिन शेल सेट करना चाहिए /bin/false? FYI करें, मेरे पास है पहले से ही है /bin/falseपर www-data।

• क्या मैं बहुत ज्यादा पागल हो रहा हूँ?

मैं डेबियन चला रहा हूं, अगर यह मायने रखता है।

Comments

एक संबंधित प्रश्न unix.stackexchange.com/questions/485505 है ।

— JdeBP

Answer 1

एक उपयोगकर्ता जिसके पास एक वैध शेल है और कोई पासवर्ड अभी भी गैर-पासवर्ड-आधारित तरीकों से लॉग इन नहीं कर सकता है, सबसे आम एक ssh कुंजी है। क्रोन नौकरियों को चलाने के लिए एक वैध शेल आवश्यक है। su bin -c 'wibble'काम करने के लिए एक वैध शेल भी आवश्यक है (लिनक्स पर कम से कम, su bin -s /bin/sh -c 'wibble'यह भी काम करेगा)।

के मामले में bin, अधिकांश सिस्टम binसामान्य ऑपरेशन के रूप में कभी भी कमांड नहीं चलाते हैं , इसलिए शेल को /bin/falseठीक करना होगा।

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

आप सिस्टम उपयोगकर्ताओं के नामों को एक DenyUsersनिर्देश में सूचीबद्ध करके SSH छेद को प्लग कर सकते हैं /etc/ssh/sshd_config(दुर्भाग्य से, आप एक संख्यात्मक सीमा का उपयोग नहीं कर सकते हैं)। या, इसके विपरीत, आप एक AllowGroupsनिर्देश डाल सकते हैं और केवल उन समूहों को अनुमति दे सकते हैं जिनमें भौतिक उपयोगकर्ता शामिल हैं (जैसे usersकि यदि आप अपने सभी भौतिक उपयोगकर्ताओं को सदस्यता प्रदान करते हैं)।

इस मुद्दे पर डेबियन ( # 274229 , # 330882 , # 581899 ) में बग दर्ज किए गए हैं , जो वर्तमान में "इच्छा सूची" के रूप में खुले और वर्गीकृत हैं। मैं इस बात से सहमत हूं कि ये बग हैं और सिस्टम उपयोगकर्ताओं /bin/falseको उनके शेल के रूप में होना चाहिए जब तक कि यह अन्यथा करना आवश्यक न प्रतीत हो।

Answer 2

आप के रूप में उन लोगों के बारे में चिंता करने की ज़रूरत नहीं है। वे सुरक्षा समूहों के अर्थ में "उपयोगकर्ता" हैं, न कि "लॉगिन और उपयोग" वाले लोगों के अर्थ में उपयोगकर्ता। यदि आप "/ etc / shadow" में देखते हैं, तो आप देखेंगे कि इन सभी "उपयोगकर्ताओं" के पास लंबे नमकीन हैश के बजाय पासवर्ड (या तो "" "" या "" नहीं हैं)। इसका मतलब है कि ये उपयोगकर्ता लॉगिन नहीं कर सकते हैं, चाहे जो भी हो।

उस ने कहा, मुझे नहीं पता कि इन सभी उपयोगकर्ताओं के लिए "/ bin / sh" को "/ bin / false" में बदलना अच्छा है या नहीं। क्योंकि कार्यक्रम इन समूहों के तहत चलते हैं, इसलिए यह उन्हें उन आज्ञाओं को निष्पादित करने की अनुमति नहीं दे सकता है जिनकी उन्हें आवश्यकता है। मैं उन्हें "बिन / श" के रूप में छोड़ देता हूँ।

आपको इन उपयोगकर्ताओं के बारे में चिंता करने की कोई आवश्यकता नहीं है। केवल उन उपयोगकर्ताओं के बारे में चिंता करें जिन्हें आप बनाते हैं (और "/ etc / shadow" में हैश वाले)

Comments

फेयर पॉइंट नाउ हैश के बारे में /etc/shadow, लेकिन यदि कोई सेवा उपयोगकर्ता के रूप में चलती है, तो सैद्धांतिक रूप से किसी के लिए sshलॉगिन कुंजी सम्मिलित करना संभव है , नहीं?

— माइक पेनिंगटन

केवल तभी जब वे पहले से ही आपके खाते में रूट विशेषाधिकारों के साथ लॉग इन थे ... किस स्थिति में, ये उपयोगकर्ता आपकी चिंताओं के कम से कम हैं :-P

— क्रिस

मुझे यकीन नहीं है कि मैं आपके द्वारा सूचीबद्ध सभी बाधाओं से सहमत हूं। अगर यह सच था, तो खुले rpcdबंदरगाहों से कोई समस्या नहीं होगी; हालाँकि, मैंने व्यक्तिगत रूप से एक पुरानी सोलारिस मशीन पर एक दूरस्थ कारनामे के परिणामों को देखा, जहाँ हमलावर ने rpcबॉक्स पर एक शोषण के माध्यम से पहुँच प्राप्त की । rhostsउस rpcउपयोगकर्ता द्वारा सक्षम और योग्य बनाया गया था (कोई और बारीकियों को याद नहीं कर सकता है ... यह वर्षों पहले था) ... इसी तरह अगर वे ~/.ssh/authorized_keysउस उपयोगकर्ता के लिए बना सकते हैं जो लॉगिन कर सकता है, तो यह अभी भी एक जोखिम जैसा लगता है (बिना भी पासवर्ड में /etc/shadow)

— माइक पेनिंगटन

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

— क्रिस

क्षमा करें, कमरे से बाहर भाग गया। शेल को बदलना जो एक प्रोग्राम को उस समस्या को ठीक कर सकता है, लेकिन यह उस समस्या को और अधिक बना देता है जो प्रोग्राम वास्तव में करने वाला है। मुझे लगा कि आप मूल रूप से इसका मतलब यह है कि दुर्भावनापूर्ण उपयोगकर्ता उस उपयोगकर्ता के माध्यम से SSH कर सकते हैं, जो वे नहीं कर सकते हैं (जब तक कि वे एक कुंजी सेट नहीं करते हैं, मुझे विश्वास है, जैसा आपने कहा था)। आप sshd_config में उस छोटी सी समस्या को हल कर सकते हैं, "AllowUsers <username> <username> ..." डालकर केवल विशिष्ट उपयोगकर्ताओं को SSH की अनुमति दे सकते हैं।

— क्रिस

Answer 3

मेरा मानना ​​है कि यह एक गैर-मुद्दा है, क्योंकि SSH सार्वजनिक कुंजी को bin's होम डाइरेक्टरी ( /bin) में सेट करने के लिए , हमलावर को फाइल सिस्टम में रूट एक्सेस करना होगा, जिसका अर्थ है कि आप वैसे भी खराब हो चुके हैं।

यदि आप चाहें, तो आप ब्लॉक binका उपयोग करके sshd के विन्यास में उपयोगकर्ता के लिए सभी प्रमाणीकरण विधियों को अक्षम कर सकते हैं MatchUser।

उस ने कहा, लगता है कि बिन उपयोगकर्ता आधुनिक डेबियन-व्युत्पन्न प्रणालियों पर अप्रयुक्त है और विशुद्ध रूप से परंपरा के लिए एक संकेत है या कुछ मानकों के अनुपालन के लिए है।