"Sudo su -" के भीतर कमांड कैसे लॉग करें?

12

अगर मैं:

[user@notebook ~] sudo echo 123456uu
123456uu
[user@notebook ~]

फिर मैं लॉग में देख सकता हूं:

[root@notebook /var/log] grep 123456uu *
auth.log:Jan  9 17:01:51 notebook sudo: user : TTY=pts/3 ; PWD=/home/user ; USER=root ; COMMAND=/bin/echo 123456uu
[root@notebook /var/log]

लेकिन अगर मैं:

[user@notebook ~] sudo su -
[root@notebook ~] echo 1234567zz
1234567zz
[root@notebook ~]

मैं इसे लॉग में नहीं देख सकता:

[root@notebook /var/log] grep 1234567zz *
[root@notebook /var/log] echo $?
1
[root@notebook /var/log]

मेरा प्रश्न: मैं "sudo su -" के भीतर कमांड के लिए लॉगिंग कैसे चालू कर सकता हूं?

ओएस एक उबंटू 12.04 है लेकिन सवाल सामान्य रूप से है।

अद्यतन # 1:

[user@notebook ~] sudo su -
[sudo] password for user: 
[root@notebook ~] echo zizizi
zizizi
[root@notebook ~] cd /var/log
[root@notebook /var/log] grep -iIR 'zizizi' *
[root@notebook /var/log] grep 'COMMAND=/bin/su -' *
auth.log:Jan 10 15:42:42 notebook sudo: user : TTY=pts/1 ; PWD=/home/user ; USER=root ; COMMAND=/bin/su -
[root@notebook /var/log]

sudo

— newuser999
स्रोत

यदि कोई दुर्भावनापूर्ण (या यहां तक कि सिर्फ अविश्वसनीय) तक पहुंच sudo su -रखता है, तो उनके पास उन सभी लॉग प्रविष्टियों को हटाने की क्षमता भी है जो आप उनके कार्यों से बना सकते हैं। यदि आप अपने लॉगिंग में 100% निश्चितता चाहते हैं, तो आपको sudoभारी प्रतिबंध लगाने और sudo suपूरी तरह से खारिज करने की आवश्यकता है ।

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

17

चूंकि आप उबंटू 12.04 पर हैं, इसलिए I / O लॉगिंग क्षमताओं log_inputऔर log_outputविकल्पों के माध्यम से सक्रिय होने पर एक नज़र है ।

log_input
यदि सेट किया गया है, तो sudoएक छद्म ट्टी में कमांड चलाएगा और सभी उपयोगकर्ता इनपुट को लॉग करेगा। यदि मानक इनपुट I / O पुनर्निर्देशन के कारण या उपयोगकर्ता के tty से जुड़ा नहीं है, क्योंकि कमांड एक पाइपलाइन का हिस्सा है, तो उस इनपुट को भी कैप्चर किया जाता है और एक अलग लॉग फ़ाइल में संग्रहीत किया जाता है।

इनपुट को उस iolog_dirविकल्प द्वारा निर्दिष्ट निर्देशिका में लॉग ऑन किया जाता है ( /var/log/sudo-ioडिफ़ॉल्ट रूप से) एक विशिष्ट सत्र आईडी का उपयोग करके जो सामान्य sudo लॉग लाइन में शामिल है, जिसके साथ उपसर्ग किया गया है TSID=। iolog_fileविकल्प सत्र आईडी प्रारूप को नियंत्रित करने के लिए इस्तेमाल किया जा सकता है।

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

log_output
यदि सेट किया गया है, तो sudoएक छद्म ट्टी में कमांड चलाएगा और स्क्रिप्ट (1) कमांड के समान स्क्रीन पर भेजे गए सभी आउटपुट को लॉग करेगा। यदि मानक आउटपुट या मानक त्रुटि I / O पुनर्निर्देशन के कारण या उपयोगकर्ता के tty से जुड़ी नहीं है, या क्योंकि कमांड एक पाइपलाइन का हिस्सा है, तो उस आउटपुट को भी कैप्चर किया जाता है और अलग लॉग फ़ाइलों में संग्रहीत किया जाता है।

आउटपुट को एक विशिष्ट सत्र आईडी का उपयोग करके iolog_dirविकल्प ( /var/log/sudo-ioडिफ़ॉल्ट रूप से) द्वारा निर्दिष्ट निर्देशिका में लॉग किया जाता है, जो सामान्य sudo लॉग लाइन में शामिल है, जिसके साथ उपसर्ग किया गया है TSID=। iolog_fileविकल्प सत्र आईडी प्रारूप को नियंत्रित करने के लिए इस्तेमाल किया जा सकता है।

आउटपुट लॉग को sudoreplay (8) उपयोगिता के साथ देखा जा सकता है, जिसका उपयोग उपलब्ध लॉग को सूचीबद्ध करने या खोजने के लिए भी किया जा सकता है।

प्रभाव: सूडो संस्करण कम से कम: 1.7.4p4 की आवश्यकता है।

/etc/sudoersmodifcation: आपको बस इतना करना है कि सभी आवश्यक sudoers प्रविष्टियों में दो टैग जोड़ना है (जहां "su" निर्दिष्ट है, या तो कमांड या उपनाम के साथ)। LOG_INPUT और LOG_OUTPUT।

उदाहरण:

%admins         ALL=(ALL) NOPASSWD: LOG_INPUT: LOG_OUTPUT: ALL

निम्न डिफ़ॉल्ट लॉग संरचना जोड़ें sudoers:

Defaults iolog_dir=/var/log/sudo-io/%{user}

— मार्क वैगनर
स्रोत

यह बहुत अच्छा है, लेकिन पुराने सिस्टम पर काम नहीं करता है ..: \

— newuser999

हाँ शायद एक वर्तमान sudo संस्करण का पैकेज बनाएं या सिस्टम को अपग्रेड करें?

— मार्टिन एम।

13

आपका grepऐसा करना sudo su -विफल हो जाता है क्योंकि आप नहीं चल रहे हैं echo 1234567zz, आप दौड़ रहे हैं su -, जो एक शेल लॉन्च करता है। खोल तो अपना चला रहा है echo।

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

यदि आप अपना grep बदलते grep 'COMMAND=/bin/su -' *हैं तो आप उसे देख लेंगे।

sudo su -का भी एक बेकार उपयोग है su। sudo -iवही काम करता है।

— पैट्रिक
स्रोत

लेकिन मैं "सुडो सु -" कैसे लॉग कर सकता हूं?

— newuser999

1

यह लॉग किया गया है। क्या आपने grep 'COMMAND=/bin/su -' *(या वाइल्डकार्ड के बिना:) कोशिश की grep 'COMMAND=/bin/su -' /var/log/auth.log?

— पैट्रिक

मैंने सवाल अपडेट किया। मुझे और क्या साबित करना है कि "सुडो सु -" का उपयोग करते समय कमांड लॉग नहीं हैं ??

— newuser999

4

आदेश ( sudo -) है लॉग इन, और आपकी नवीन उत्पादन इस दर्शाता है। हम सब यहाँ बात कर रहे हैं। अन्य आदेश, जैसे echoआप के साथ उपयोगकर्ताओं को स्विच करने के बाद sudo -, नहीं कर रहे हैं आदेशों sudo, (मेरा उत्तर के अनुसार) लॉग इन नहीं हैं और इसलिए auth.log। केवल स्पष्ट रूप से पहले से मौजूद व्यक्तिगत आदेशों sudoको लॉग किया जाएगा। तो sudo echoलॉग किया गया है, लेकिन सिर्फ सादे echoइस तथ्य की परवाह किए बिना नहीं है कि आपने सुपरयुसर को स्विच किया है।

— गोल्डीलॉक्स

12

बढ़ती जटिलता में, "सूडो सु -" के भीतर जारी किए गए आदेशों को लॉग करने के तीन तरीके यहां दिए गए हैं:

बैश कमांड इतिहास पर भरोसा करें
एक निष्पादित लॉगिंग आवरण को स्थापित करें
SELinux के ऑडिट का उपयोग करें

जैसा कि उपयुक्त है, यह वास्तव में इस बात पर निर्भर करता है कि आप लॉगिंग के साथ क्या करने की कोशिश कर रहे हैं।

1) बैश कमांड हिस्ट्री

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

2) आवरण को निष्पादित करें

snoopylogger एक है। इसमें एक जाँच जोड़ें /etc/profileकि लकड़हारा पुस्तकालय प्रक्रिया की मेमोरी मैप ( /proc/<pid>/maps) में है, और यदि नहीं, तो सेट LD_PRELOADऔर पुनरारंभ (साथ exec $SHELL --login "$@") करें। वैकल्पिक रूप से आप snoopy.so के अपने 32/64-बिट संस्करणों के साथ /etc/ld.so.preload $LIB/snoopy.soया समतुल्य पथों के लिए एक प्रविष्टि जोड़ सकते हैं ।

हालांकि अधिक कठिन है, ऊपर के LD_PRELOADपर्यावरण चर संस्करण को अभी भी निष्पादन पर्यावरण में हेरफेर करके विकृत किया जा सकता है ताकि स्नूपा कोड अब नहीं चलता।

भरोसेमंद होने के लिए सामग्री के लिए Syslog को ऑफ-बॉक्स भेजा जाना चाहिए।

3) लेखा परीक्षा

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

यह सर्वरफॉल्ट उत्तर ऑडिट के साथ उपयोग के लिए एक काफी व्यापक विन्यास प्रतीत होता है।

सर्वरफॉल्ट पर एक समान प्रश्न के कुछ अन्य सुझाव हैं ।

— आर पेरिन
स्रोत

9

क्यों?

क्योंकि यह है sudoकि लॉगिंग कर रहा है; यह सूडो कमेंड्स को लॉग करता है। पहले मामले में, sudo echoलॉग किया गया है। दूसरे मामले में, sudo suलॉग किया गया है (इसके लिए देखो /var/log/auth.log)।

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

— गोल्डीलॉक्स
स्रोत

5

जैसा कि दूसरों ने कहा है, sudoऐसा नहीं कर सकते।

इसके बजाय, उपयोग करें auditd। यदि आप रूट द्वारा किए गए सब कुछ लॉग करना चाहते हैं (उदाहरण के लिए क्रॉस्टब द्वारा की गई चीजें), तो इसका उपयोग करें:

sudo auditctl -a exit,always -F euid=0

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

यदि आप केवल उन syscalls को लॉग इन करना चाहते हैं जहाँ मूल लॉगिन uid रूट नहीं है, तो इसके बजाय इसका उपयोग करें:

sudo auditctl -a exit,always -F euid=0 -F auid!=0

लॉग आमतौर पर /var/log/audit/audit.log में समाप्त हो जाएंगे। आप उन्हें खोज सकते हैं ausearch।

के लिए आदमी पृष्ठों में अधिक जानकारी है auditctl, audit.rulesऔर ausearch।

— जेनी डी
स्रोत

2

ओह, ऑडिट लॉग पर भरोसा करने के लिए, उन्हें एक अलग सर्वर पर भेजा जाना चाहिए। मशीन पर रहने वाले कोई भी लॉग जहां एक अविश्वसनीय उपयोगकर्ता जड़ है पर भरोसा नहीं किया जा सकता है।

— जेनी डी

फिर भी आप विश्वास नहीं कर सकते कि एक समझौता किए गए सर्वर से क्या होता है या क्या नहीं।

— मैट

लेकिन जब तक यह समझौता नहीं हो जाता, तब तक आपके पास एक निशान होगा।

— जेनी डी

2

ऑप्स के मामले में तकनीकी रूप से जैसे ही वे भाग गए हैं, sudo su -तो आप एक वर्ग में वापस आ गए हैं

— मैट

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

— जेनी डी

2

sudo su -में हो जाएगा ~/.bash_historyअगर आपके खोल bash है।

echo 1234567zzहोगा /root/.bash_historyअगर जड़ खोल है मार।

इसका स्पष्टीकरण पहले ही गोल्डीलॉक्स द्वारा पोस्ट किया गया था।

— YoMismo
स्रोत

2

क्या आप चाहते हैं कि आप लॉग इन करें क्योंकि आपको लगता है कि यह सुरक्षा दोष है? क्या आपने इस कमांड के बारे में सोचा है? sudo bashबस के रूप में बुरा imho।

यदि आप इस बात से चिंतित हैं कि लोग सुडो के साथ क्या कर सकते हैं, तो आपको इसे उपयोग करने के लिए प्रतिबंधित करना होगा। आप उन कमांड्स को प्रतिबंधित कर सकते हैं जिन्हें वे निष्पादित कर सकते हैं। यदि यह आपकी चिंता करता है तो / bin / su तक पहुंच को प्रतिबंधित करें।

— एक्स तियान
स्रोत

1

इस बारे में क्या:

export HISTTIMEFORMAT="%d/%m/%y %T "
export PROMPT_COMMAND='builtin history 1 >> /var/log/sudo.log'
sudo -E su
unset PROMPT_COMMAND

या

export HISTTIMEFORMAT="%d/%m/%y %T "
export PROMPT_COMMAND='builtin history 1 >> /var/log/sudo.log' 
sudo -E su --preserve-environment -
unset PROMPT_COMMAND

या लंबे समय से एक लाइनर:

HISTTIMEFORMAT="%d/%m/%y %T " PROMPT_COMMAND='builtin history 1 >> /var/log/sudo.log' sudo -E su

sudo -E पर्यावरण को संरक्षित करता है PROMPT_COMMAND को प्रत्येक प्रांप्ट से पहले निष्पादित किया जाता है

— कोस्टा
स्रोत

पहले वाला मुझे कोई कंसोल नहीं देता है और अगर मैं दूसरा / /ot /.bashrc में डालता हूं तो मुझे CTRL + C को हिट करना होगा यदि मैं "सुडो सु -" के बाद रूट कंसोल प्राप्त करना चाहता हूं: कोई भी संभावना इसे ठीक करने के लिए (या इसमें "तिथि" फ़ंक्शन जोड़ने के लिए?)। बहुत धन्यवाद!

— newuser999

मुझे डर है कि आपने इसका दुरुपयोग किया। इसे और अधिक स्पष्ट करने के लिए संपादित किया।

— कोस्टा

1

यदि यह मदद करता है, तो आप sudoers के "NOEXEC" विकल्प का उपयोग कर सकते हैं।

आपको इसे परिभाषित करने की आवश्यकता है

USER_NAME         ALL=(ALL) NOEXEC : ALL

यह खोल से बच जाएगा और उपयोगकर्ता sudo -i या sudo -s या sudo su का उपयोग करने में सक्षम नहीं होगा -

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

— ankidaemon
स्रोत

0

आइए इसे जटिल न बनाएं: जब भी sudoकहा जाता है, यह इस तथ्य को किसी फ़ाइल में /var/log(आपके सिस्टम पर auth.log, मेरे ओएस एक्स बॉक्स पर है system.log) पर रिपोर्ट करता है। sudoअपने कमांडलाइन तर्कों की रिपोर्ट करता है, लेकिन उसे इस बात का कोई ज्ञान नहीं है कि एक इंटरैक्टिव कमांड के अंदर क्या हो सकता है su।

इसका मतलब यह नहीं है कि एक रूट सबशेल में क्या होता है इसका कोई रिकॉर्ड नहीं है: शेल कमांड शेल के इतिहास में सहेजे गए हैं। मेरे सिस्टम पर, रूट की हिस्ट्री सेविंग डिफ़ॉल्ट रूप से सक्षम है, इसलिए मुझे जो कुछ करना है ~root/.sh_history, उसके रिकॉर्ड के लिए देखना होगा (जब तक कि कोई इसके साथ छेड़छाड़ नहीं करता है, निश्चित रूप से, लेकिन वे समान रूप से अच्छी तरह से छेड़छाड़ कर सकते हैं /var/log)।

मुझे लगता है कि यह आपके लिए सबसे अच्छा समाधान है। यदि नहीं, तो auditd@ जेनी ने सुझाव दिया कि शहर में जाएं।

पुनश्च। यदि रूट का इतिहास पहले से सक्षम नहीं है, तो सक्षम करना यह निर्भर करता है कि वह किस शेल का उपयोग करता है। के लिए bash, सेट HISTORYऔर HISTFILESIZEएक बड़ी संख्या के लिए (डिफ़ॉल्ट 500 है, मेरा मैनुअल कहता है)। यदि आप चाहें, तो आप निर्दिष्ट कर सकते हैं कि HISTFILEएक पथ (डिफ़ॉल्ट $HOME/.sh_history) पर सेट करके इतिहास कहाँ सहेजा गया है

— एलेक्सिस
स्रोत

0

आप का उपयोग करके अपने सत्र का एक प्रकार बनाना चाहते हो सकता है script(1):

$ sudo su -
# script -t /tmp/my_typescript 2> /tmp/my_typescript.timing
Script started, file is /tmp/my_typescript
# echo foobar
foobar
# echo hello world
hello world
# exit
exit
Script done, file is /tmp/my_typescript

अब आप कर सकते हैं grep(ध्यान दें कि #संकेत वास्तव में दर्ज किए गए हैं /tmp/my_typescript):

$ grep echo /tmp/my_typescript
# echo foobar
# echo hello world

वैकल्पिक रूप से, आप पूरे सत्र को फिर से देख सकते हैं scriptreplay(1):

$ scriptreplay -t /tmp/my_typescript.timing /tmp/my_typescript

फ़ाइल /tmp/my_typescript.timingमें वह जानकारी होती है जब प्रत्येक कमांड को लागू किया गया हो। वहाँ की तरह आगे उपकरण हैं ttyrecया shelrहै कि और भी अधिक घंटियाँ और सीटी।

— tkrennwa
स्रोत