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]
sudo su -
, może również usunąć wszystkie wpisy w dzienniku dotyczące jego działań. Jeśli chcesz mieć 100% pewności w logowaniu, musiszsudo
mocno ograniczyć isudo su
całkowicie zabronić .Odpowiedzi:
Ponieważ korzystasz z systemu Ubuntu 12.04, spójrz na możliwości logowania we / wy aktywowane za pomocą opcji
log_input
ilog_output
.REALIZACJA: potrzebna jest wersja Sudo co najmniej: 1.7.4p4.
/etc/sudoers
modyfikacja: 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:
Dodaj następującą domyślną strukturę katalogu dziennika do
sudoers
:źródło
Twoje
grep
działaniesudo su -
kończy się niepowodzeniem, ponieważ nie jesteś uruchomionyecho 1234567zz
, jesteś uruchomionysu -
, który uruchamia powłokę. Powłoka następnie uruchamia twójecho
.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życiemsu
.sudo -i
robi to samo.źródło
grep 'COMMAND=/bin/su -' *
(lub bezgrep 'COMMAND=/bin/su -' /var/log/auth.log
) :sudo -
) jest zarejestrowane, a zaktualizowane dane wyjściowe to pokazują. To wszystko, o czym tu mówimy. W innych poleceń, takich jakecho
po przełączeniu użytkownikomsudo -
, nie są polecenia sudo, a tym samym (jak na moją odpowiedź) Nie jesteś zalogowanyauth.log
.sudo
Rejestrowane będą tylko pojedyncze polecenia poprzedzone wcześniej . Taksudo echo
jest zalogowany, ale po prostuecho
nie jest, niezależnie od tego, że przeszedłeś do superużytkownika.Aby zwiększyć złożoność, oto trzy sposoby rejestrowania poleceń wydanych w „sudo su -”:
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, ustawLD_PRELOAD
i uruchom ponownie (za pomocąexec $SHELL --login "$@"
). Alternatywnie możesz dodać wpis do /etc/ld.so.preload z$LIB/snoopy.so
lub równoważnymi ścieżkami do 32/64-bitowych wersji snoopy.so.Choć trudniejsze,
LD_PRELOAD
wersja 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 .
źródło
Ponieważ to właśnie
sudo
rejestrowanie; loguje polecenia sudo. W pierwszym przypadkusudo echo
jest zalogowany. W drugim przypadkusudo su
jest zalogowany (poszukaj go/var/log/auth.log
).su
to „zmień użytkownika”, domyślnie na root. Cokolwiek zrobisz po tym , nie przejdziesudo
. To tak samo, jakbyś zalogował się jako root; samo logowanie jest rejestrowane, ale nie każde polecenie.źródło
Jak powiedzieli inni,
sudo
nie 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:ETA: Pamiętaj, że rejestrowanie wszystkiego wpłynie na wydajność, więc prawdopodobnie będziesz chciał to nieco ograniczyć. Zobacz
man auditctl
przykłady.Jeśli chcesz rejestrować tylko wywołania systemowe, w których oryginalny identyfikator użytkownika nie jest rootem, użyj tego:
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.rules
aausearch
.źródło
sudo su -
więc wrócisz do punktu wyjściasudo su -
będzie,~/.bash_history
jeśli twoja powłoka jest bash.echo 1234567zz
będzie,/root/.bash_history
jeśli powłoka roota jest bash.Wyjaśnienie tego zostało już opublikowane przez goldilocks.
źródło
Czy chcesz, aby Su logował się, ponieważ uważasz, że jest to usterka bezpieczeństwa? Czy myślałeś o tym poleceniu?
sudo bash
tak 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.
źródło
A co z tym:
lub
lub długi jednowarstwowy:
sudo -E chroni środowisko PROMPT_COMMAND jest wykonywany przed każdym monitem
źródło
Jeśli to pomoże, możesz użyć opcji sudoers „NOEXEC”.
Musisz to zdefiniować jako
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.
źródło
Nie komplikujmy tego: za każdym razem, gdy
sudo
jest wywoływany, zgłasza ten fakt w jakimś pliku w/var/log
(w twoim systemie jestauth.log
, w moim systemie OS Xsystem.log
).sudo
zgłasza argumenty wiersza poleceń, ale nie ma wiedzy o tym, co może się wydarzyć w poleceniu interaktywnym, takim jaksu
.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_history
zapisu 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
, ustawHISTORY
iHISTFILESIZE
na wystarczająco dużą liczbę (domyślnie jest to 500, mówi moja instrukcja). Jeśli chcesz, możesz określić miejsce zapisywania historii, ustawiającHISTFILE
ścieżkę (domyślnie$HOME/.sh_history
)źródło
Możesz utworzyć maszynopis swojej sesji, używając
script(1)
:Teraz możesz
grep
(pamiętaj, że#
monity są faktycznie zapisane/tmp/my_typescript
):Alternatywnie możesz nawet ponownie obejrzeć całą sesję za pomocą
scriptreplay(1)
:Plik
/tmp/my_typescript.timing
zawiera informacje o wywołaniu każdego polecenia. Istnieją również inne narzędzia, takie jakttyrec
alboshelr
że mają jeszcze więcej wodotryski.źródło