Nie jesteś zalogowany.
Jeśli nie posiadasz konta, zarejestruj je już teraz! Pozwoli Ci ono w pełni korzystać z naszego serwisu. Spamerom dziękujemy!
Prosimy o pomoc dla małej Julki — przekaż 1% podatku na Fundacji Dzieciom zdazyć z Pomocą.
Więcej informacji na dug.net.pl/pomagamy/.
Strony: 1
Cześć,
Mam pytanie czy jest możliwość skonfigurowania pliku historii dla użytkownika roota na wzór czegoś w stylu np. Każdy użytkownik loguje się do serwera swoim kontem domenowym, poprzez sudo su wchodzi na roota, siedząc na roocie zapisywane są w pliku historii informacje o tym jakich poleceń użył konkretny użytkownik domenowy będąc jednocześnie na roocie? Mam nadzieję że w miarę jasno to wytłumaczyłem i wiadomo o co chodzi.
przykładowo aby np. do historii roota dodać informację o zmianach jakie wykonał konkretny użytkownik wykorzystując usera root ?
1027 2016-07-26 username1 12:45:54 ssh serv1 1028 2016-07-26 usernam2 13:47:59 df -hl 1029 2016-07-26 username213:48:08 host serv2 1030 2016-07-26 username1 13:49:54 ping serv2 1031 2016-07-26 username1 13:52:44 rm -rf /home/user1 1032 2016-07-26 username2 11:50:43 ssh serv3
Z góry dzięki za wszelką pomoc.
Offline
Tak, jak piszesz, to chyba nie, a przynajmniej nic mi o tym nie wiadomo. Ja bym rozwiązał to przez tworzenie osobnego pliku dla każdego z użytkowników (doklejenie wartości SUDO_USER do nazwy pliku)
Offline
Znacznie lepiej zintegrować audit.d + ossec - szczególnie na wielu maszynach.
Offline
Jeśli chodzi o śledzenie z punktu widzenia bezpoieczeństwa to jak najbardziej. Jednak aditd to duża kobyła i śledzi na poziomie wywołań systemowych. Odniosłem wrażenie, że koledze Kamil2685 chodziło raczej o prostsze rozwiązanie.
Offline
jurgensen napisał(-a):
Tak, jak piszesz, to chyba nie, a przynajmniej nic mi o tym nie wiadomo. Ja bym rozwiązał to przez tworzenie osobnego pliku dla każdego z użytkowników (doklejenie wartości SUDO_USER do nazwy pliku)
SUDO_USER to niezły pomysł, ale ja bym kombinował logowanie komend roota do sysloga, i tam w logach postarał się schować zmienną SUDO_USER, a w syslogu całość posłać do SQLa np modułem omysql z rsyloga.
W ten sposób można by dosyć sprawie sortować i sprawdzać co, kto i kiedy zmalował.
Plik historii każdy może usunąć będąc na roocie, swój albo cudzy, a do bazy danych i konfigu rsyslog wcale nie musi mieć dostępu, da się to ograniczyć nawet dla powłoki roota, wykorzystując np Apparmora albo SELinuxa, czy choćby RBAC z Grseca.
Tu chyba jest kilka sposobów na rozwiązanie tej kwestii z auditd i bez.
http://serverfault.com/questions/470755/log-all-com … ction-servers
Trzeba jednak pamiętać, że oprócz sudo jest jeszcze su.....
Pozdro
;-)
Ostatnio edytowany przez Jacekalex (2016-07-28 19:11:58)
Offline
Jeśli chodzi o rozwiązanie Jacekalex, to była kiedyś łatka na Bash, która wysyłała wprowadzane polecenia do sysloga.
Offline
jurgensen napisał(-a):
Jeśli chodzi o rozwiązanie Jacekalex, to była kiedyś łatka na Bash, która wysyłała wprowadzane polecenia do sysloga.
Nie tylko łatka:
* Found these USE flags for app-shells/bash-4.3_p42-r1:
U I
- - afs : Add OpenAFS support (distributed file system)
- - bashlogger : Log ALL commands typed into bash; should ONLY be used in
restricted environments such as honeypots
- - examples : Install examples, usually source code
+ + mem-scramble : Build with custom malloc/free overwriting allocated/freed
memory
+ + net : Enable /dev/tcp/host/port redirection
+ + nls : Add Native Language Support (using gettext - GNU locale
utilities)
- - plugins : Add support for loading builtins at runtime via 'enable'
- + readline : Enable support for libreadline, a GNU line-editing library
that almost everyone wants
- - vanilla : Do not add extra patches which change default behaviour; DO
NOT USE THIS ON A GLOBAL SCALE as the severity of the
meaning changes drastically
Nie wiem tylko, jak w samym Bashu się konfiguruje format takiego loga, żeby miał w sobie zmienną SUDO_USER.
Jeżeli sam kombinujesz z log_command i trap, to nie ma tego problemu.
Offline
Strony: 1