Jak rejestrować polecenia w „sudo su -”?

Jeśli ja:

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

Następnie widzę to w dziennikach:

[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] 

ale jeśli:

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

Nie widzę tego w dziennikach:

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

Moje pytanie: Jak mogę włączyć logowanie dla poleceń w „sudo su -”?

System operacyjny to Ubuntu 12.04, ale pytanie jest ogólne.

AKTUALIZACJA # 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]

Ponieważ korzystasz z systemu Ubuntu 12.04, spójrz na możliwości logowania we / wy aktywowane za pomocą opcji log_inputi log_output.

log_input

Jeśli jest ustawiony, sudouruchomi polecenie w pseudo tty i zarejestruje wszystkie dane wprowadzone przez użytkownika. Jeśli standardowe wejście nie jest podłączone do tty użytkownika, z powodu przekierowania we / wy lub ponieważ polecenie jest częścią potoku, wejście to jest również przechwytywane i przechowywane w osobnym pliku dziennika.

Dane wejściowe są rejestrowane w katalogu określonym przez iolog_diropcję ( /var/log/sudo-iodomyślnie) przy użyciu unikalnego identyfikatora sesji zawartego w normalnym wierszu dziennika sudo, z prefiksem TSID=. iolog_fileOpcja może być używany do sterowania formatu ID sesji.

Pamiętaj, że dane wejściowe użytkownika mogą zawierać poufne informacje, takie jak hasła (nawet jeśli nie są wyświetlane na ekranie), które będą przechowywane w pliku dziennika niezaszyfrowanym. W większości przypadków rejestrowanie danych wyjściowych polecenia za pomocą log_output jest wszystkim, czego potrzeba.

log_output

Jeśli jest ustawiony, sudouruchomi polecenie w pseudo tty i zarejestruje wszystkie dane wyjściowe wysyłane na ekran, podobnie jak polecenie script (1). Jeśli standardowe wyjście lub błąd standardowy nie jest podłączony do tty użytkownika, z powodu przekierowania we / wy lub ponieważ polecenie jest częścią potoku, dane wyjściowe są również przechwytywane i przechowywane w osobnych plikach dziennika.

Dane wyjściowe są rejestrowane w katalogu określonym przez iolog_diropcję ( /var/log/sudo-iodomyślnie) przy użyciu unikalnego identyfikatora sesji zawartego w normalnym wierszu dziennika sudo, z prefiksem TSID=. iolog_fileOpcja może być używany do sterowania formatu ID sesji.

Dzienniki wyjściowe można przeglądać za pomocą narzędzia sudoreplay (8), którego można również używać do wyświetlania lub przeszukiwania dostępnych dzienników.

REALIZACJA: potrzebna jest wersja Sudo co najmniej: 1.7.4p4.

/etc/sudoersmodyfikacja: Wszystko, co musisz zrobić, to dodać dwa tagi do wszystkich wymaganych pozycji sudoers (gdzie podano „su”, z poleceniem lub aliasem). LOG_INPUT i LOG_OUTPUT.

Przykład:

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

Dodaj następującą domyślną strukturę katalogu dziennika do sudoers:

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

Twoje grepdziałanie sudo su -kończy się niepowodzeniem, ponieważ nie jesteś uruchomiony echo 1234567zz, jesteś uruchomiony su -, który uruchamia powłokę. Powłoka następnie uruchamia twój echo.

Jest to celowe, a rejestrowanie każdego uruchomienia polecenia spowoduje zalanie twojego dziennika systemowego bezużytecznymi informacjami (zwykle jest mnóstwo programów uruchamianych za scenami, których normalnie nie widzisz).

Jeśli zmienisz grep na grep 'COMMAND=/bin/su -' *, zobaczysz go.

sudo su -jest także bezużytecznym użyciem su. sudo -irobi to samo.

Aby zwiększyć złożoność, oto trzy sposoby rejestrowania poleceń wydanych w „sudo su -”:

1. Polegaj na historii poleceń bash
2. Zainstaluj program do wykonywania rejestrowania
3. Skorzystaj z audytu SELinux

To, co jest odpowiednie, naprawdę zależy od tego, co próbujesz osiągnąć przy logowaniu.

1) Historia poleceń Bash

Chcesz skonfigurować facitlity historii, aby zapewnić utrzymanie wystarczającej liczby wierszy, nie nadpisywanie z różnych sesji, nie ignorowanie poleceń i odpowiednich znaczników czasu. (Patrz zmienne HIST * w podręczniku bash ). Łatwo go obalić, edytując plik historii, manipulując środowiskiem lub uruchamiając inną powłokę.

2) wykonać opakowanie

snoopylogger jest jeden. Dodaj zaznaczenie, /etc/profileże biblioteka rejestratora znajduje się w mapie pamięci procesu ( /proc/<pid>/maps), a jeśli nie, ustaw LD_PRELOADi uruchom ponownie (za pomocą exec $SHELL --login "$@"). Alternatywnie możesz dodać wpis do /etc/ld.so.preload z $LIB/snoopy.solub równoważnymi ścieżkami do 32/64-bitowych wersji snoopy.so.

Choć trudniejsze, LD_PRELOADwersja powyższej zmiennej środowiskowej może być nadal obalona przez manipulowanie środowiskiem wykonawczym, tak aby kod snoopy przestał działać.

Syslog powinien zostać wysłany z pudełka, aby zawartość była godna zaufania.

3) skontrolowany

Nieco łatwiejsze do skonfigurowania niż opakowanie wykonawcze, ale trudniejsze do wyodrębnienia informacji. Oto odpowiedź na pytanie, które najprawdopodobniej naprawdę zadajesz: „Czy istnieje sposób na zarejestrowanie wpływu, jaki użytkownik wywarł na system po jego wydaniu sudo su -”. Syslog powinien zostać wysłany z pudełka, aby zawartość była godna zaufania.

Ta odpowiedź na błąd serwera wydaje się być dość kompleksową konfiguracją do użytku z auditd.

Istnieją inne sugestie dotyczące podobnego pytania na temat błędu serwera .

Dlaczego?

Ponieważ to właśnie sudorejestrowanie; loguje polecenia sudo. W pierwszym przypadku sudo echojest zalogowany. W drugim przypadku sudo sujest zalogowany (poszukaj go /var/log/auth.log).

suto „zmień użytkownika”, domyślnie na root. Cokolwiek zrobisz po tym , nie przejdzie sudo. To tak samo, jakbyś zalogował się jako root; samo logowanie jest rejestrowane, ale nie każde polecenie.

Jak powiedzieli inni, sudonie można tego zrobić.

Zamiast tego użyj auditd. Jeśli chcesz zalogować wszystko wykonane przez roota (w tym np. Rzeczy zrobione przez crontab), użyj tego:

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

ETA: Pamiętaj, że rejestrowanie wszystkiego wpłynie na wydajność, więc prawdopodobnie będziesz chciał to nieco ograniczyć. Zobacz man auditctlprzykłady.

Jeśli chcesz rejestrować tylko wywołania systemowe, w których oryginalny identyfikator użytkownika nie jest rootem, użyj tego:

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

Dzienniki zwykle kończą się w /var/log/audit/audit.log. Możesz je przeszukiwać za pomocą ausearch.

Nie ma więcej informacji na stronach dla człowieka auditctl, audit.rulesa ausearch.

sudo su -będzie, ~/.bash_historyjeśli twoja powłoka jest bash.

echo 1234567zzbędzie, /root/.bash_historyjeśli powłoka roota jest bash.

Wyjaśnienie tego zostało już opublikowane przez goldilocks.

Czy chcesz, aby Su logował się, ponieważ uważasz, że jest to usterka bezpieczeństwa? Czy myślałeś o tym poleceniu? sudo bashtak samo złe imho.

Jeśli martwisz się tym, co ludzie mogą zrobić z sudo, musisz ograniczyć jego użycie. Możesz ograniczyć polecenia, które mogą wykonywać. Ogranicz dostęp do / bin / su, jeśli Cię to martwi.

A co z tym:

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

lub

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

lub długi jednowarstwowy:

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

sudo -E chroni środowisko PROMPT_COMMAND jest wykonywany przed każdym monitem

Jeśli to pomoże, możesz użyć opcji sudoers „NOEXEC”.

Musisz to zdefiniować jako

USER_NAME         ALL=(ALL) NOEXEC : ALL

Zapobiegnie to ucieczce powłoki i użytkownik nie będzie mógł używać sudo -i lub sudo -s lub sudo su -

Ma to jednak pewną wadę, jednak każda ucieczka pocisku zostanie wyłączona. za wykonanie skryptu z poziomu skryptu również zostanie odrzucone.

Nie komplikujmy tego: za każdym razem, gdy sudojest wywoływany, zgłasza ten fakt w jakimś pliku w /var/log(w twoim systemie jest auth.log, w moim systemie OS X system.log). sudozgłasza argumenty wiersza poleceń, ale nie ma wiedzy o tym, co może się wydarzyć w poleceniu interaktywnym, takim jak su.

Nie oznacza to, że nie ma zapisu tego, co dzieje się w podpowłoce głównej: Polecenia powłoki są zapisywane w historii powłoki. W moim systemie zapisywanie historii roota jest domyślnie włączone, więc wszystko, co musiałbym zrobić, to poszukać ~root/.sh_historyzapisu tego, co zostało zrobione (chyba że ktoś oczywiście go sfałszował, ale równie dobrze mógł go sfałszować /var/log).

Myślę, że to najlepsze rozwiązanie dla Ciebie. Jeśli nie, idź do miasta z auditd, jak sugerował @Jenny.

PS. Jeśli historia roota nie jest jeszcze włączona, jej włączenie zależy od używanej powłoki. Dla bash, ustaw HISTORYi HISTFILESIZEna wystarczająco dużą liczbę (domyślnie jest to 500, mówi moja instrukcja). Jeśli chcesz, możesz określić miejsce zapisywania historii, ustawiając HISTFILEścieżkę (domyślnie $HOME/.sh_history)

Możesz utworzyć maszynopis swojej sesji, używając 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

Teraz możesz grep(pamiętaj, że #monity są faktycznie zapisane /tmp/my_typescript):

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

Alternatywnie możesz nawet ponownie obejrzeć całą sesję za pomocą scriptreplay(1):

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

Plik /tmp/my_typescript.timingzawiera informacje o wywołaniu każdego polecenia. Istnieją również inne narzędzia, takie jak ttyrecalbo shelrże mają jeszcze więcej wodotryski.