[audit] Śledzenie programów - autrace

Red Hat 6.x / CentOS 6.x

Reguły audytowe w systemie audit stwarzają bardzo duże możliwości weryfikacji co dzieje się z naszym systemie operacyjnym. Oczywiście muszą one zostać odpowiednio zdefiniowane, ale nie o definiowaniu chciałem tu pisać, a jedynie wykorzystać istniejące oprogramowanie do zademonstrowania ich możliwości.

Istnieje w systemie aplikacja, która wykorzystując te właśnie reguły umożliwia nam śledzenie działania oprogramowania systemowego, a w zasadzie nie tyle działania, co zdarzeń, jakie takiego działania są skutkiem.

autrace bo o nim mowa wywołuje podane jako parametr polecenie, zastępując na czas tego uruchomienia standardowe reguły audit własnymi - dedykowanymi do charakteru własnego działania. Po zakończeniu przywraca wcześniejsze definicje systemowe i informuje nas z jakim PID-em test przebiegał, podając gotową komendę, którą możemy wykonanie procesu prześledzić.

[root@server ~]# autrace /bin/ls /tmp
Waiting to execute: /bin/ls
hsperfdata_pkiuser  hsqldb.wEncXsNE  hsqldb.xu7Bamgr  kde-root  krb5cc_0  orbit-gdm  orbit-root  pulse-0mK8Vejz42eO  pulse-j4H4Y7P5exeT  virtual-root.ljcOAe
Cleaning up...
Trace complete. You can locate the records with 'ausearch -i -p 11804'

Pamiętając, że ausearch wyszukuje i przedstawia w zasadzie w niezmienionej postaci linie z /var/log/audit/audit.log, analizowanie tego typu przebiegów nie wydaje się być interesujące. Z pomocą przychodzi nam jednak aureport, którego raporty są przejrzyste i proste do zinterpretowania.

Musimy wykorzystać tu jedną z opcji ausearch, pozwalającą przeglądać wyszukane zdarzenia w formacie raw (opcja --raw), który z kolei aureport bez problemu interpretuje. Wynik jednego polecenia przekażemy bezpośrednio do drugiego:

[root@server ~]# ausearch --raw -p 11804 | aureport

Summary Report
======================
Range of time in logs: 08/30/2015 09:50:01.921 - 10/08/2015 08:47:42.597
Selected time for report: 08/30/2015 09:50:01 - 10/08/2015 08:47:42.597
Number of changes in configuration: 0
Number of changes to accounts, groups, or roles: 0
Number of logins: 0
Number of failed logins: 0
Number of authentications: 0
Number of failed authentications: 0
Number of users: 2
Number of terminals: 2
Number of host names: 1
Number of executables: 3
Number of files: 15
Number of AVC's: 0
Number of MAC events: 0
Number of failed syscalls: 2
Number of anomaly events: 0
Number of responses to anomaly events: 0
Number of crypto events: 0
Number of keys: 0
Number of process IDs: 1
Number of events: 125

Teraz, bez przeszkód możemy raportować dowolne eventy towarzyszące wykonaniu standardowego ls /tmp. Jak widać z ogólnej statystyki komenda używa 15 plików lub katalogów, sprawdźmy więc jakich:

[root@server ~]# ausearch --raw -p 11804 | aureport -i -f --summary

File Summary Report
===========================
total  file
===========================
3  /selinux
2  /tmp
1  /lib64/libattr.so.1
1  /lib64/libpthread.so.0
1  /lib64/libdl.so.2
1  /lib64/libc.so.6
1  /lib64/libacl.so.1
1  /lib64/libcap.so.2
1  /lib64/librt.so.1
1  /lib64/libselinux.so.1
1  /etc/ld.so.cache
1  /etc/ld.so.preload
1  (null)
1  /bin/ls
1  /usr/lib/locale/locale-archive

Niektóre z nich używane są kilkukrotnie.... ciekawe w jakiej kolejności :)

[root@server ~]# ausearch --raw -p 11804 | aureport -i -f

File Report
===============================================
# date time file syscall success exe auid event
===============================================
1. 10/08/2015 08:47:42 /bin/ls execve yes /bin/ls root 3812
2. 10/08/2015 08:47:42 /etc/ld.so.preload access no /bin/ls root 3815
3. 10/08/2015 08:47:42 /etc/ld.so.cache open yes /bin/ls root 3816
4. 10/08/2015 08:47:42 /lib64/libselinux.so.1 open yes /bin/ls root 3820
5. 10/08/2015 08:47:42 /lib64/librt.so.1 open yes /bin/ls root 3828
6. 10/08/2015 08:47:42 /lib64/libcap.so.2 open yes /bin/ls root 3835
7. 10/08/2015 08:47:42 /lib64/libacl.so.1 open yes /bin/ls root 3843
8. 10/08/2015 08:47:42 /lib64/libc.so.6 open yes /bin/ls root 3850
9. 10/08/2015 08:47:42 /lib64/libdl.so.2 open yes /bin/ls root 3858
10. 10/08/2015 08:47:42 /lib64/libpthread.so.0 open yes /bin/ls root 3866
11. 10/08/2015 08:47:42 /lib64/libattr.so.1 open yes /bin/ls root 3874
12. 10/08/2015 08:47:42 /selinux statfs yes /bin/ls root 3901
13. 10/08/2015 08:47:42 /selinux statfs yes /bin/ls root 3902
14. 10/08/2015 08:47:42 /selinux stat yes /bin/ls root 3903
15. 10/08/2015 08:47:42 /usr/lib/locale/locale-archive open yes /bin/ls root 3906
16. 10/08/2015 08:47:42 /tmp stat yes /bin/ls root 3912
17. 10/08/2015 08:47:42 /tmp open yes /bin/ls root 3913

Kto by się spodziewał, że zwykły ls korzysta z 2 użytkowników? Ja się nie spodziewałęm, więc chętnie, przy okazji sprawdzę jakich:

[root@server ~]# ausearch --raw -p 11804 | aureport -i -u --summary

User Summary Report
===========================
total  auid
===========================
123  root
2  unset

Stosowanie samego autrace, jak mi się wydaje, jest mało przydatne. Czytanie i analizowanie logów jest męczarnią, a dla tak prostego programu jak ls log ten to niemal 180 linii. Jednak kierowanie takiego trace'a do narzędzia raportującego daje nam duże możliwości prostej i szybkiej weryfikacji, np. czy aby dana binarka nie grzebie nam w pliku, w którym nie powinna :)

[audit] Generowanie raportów audytowych - aureport

Red Hat 6.x / CentOS 6.x

System operacyjny poza możliwością wyszukiwania zdarzeń w logach audit daje nam możliwość prostego generowania raportów z tych zdarzeń. Narzędzie aureport, bo je mam na myśli, posiada sporą grupę opcji, dzięki której w czytelny sposób możemy przedstawić statystyki dla wybranego elementu, zaprezentowane w usystematyzowanej kolumnowej formie.

Jak w przypadku narzędzia ausearch tutaj również możemy wymusić interpretację niektórych pól przedstawianych w raporcie, i analogicznie będziemy to realizować przez dodanie parametru -i.

Podstawowym raportem generowanym przez aureport jest raport sumaryczny pokazujący ilościowe zestawienie zdarzeń różnego rodzaju:

[root@server ~]# aureport

Summary Report
======================
Range of time in logs: 08/24/2015 19:14:27.452 - 10/08/2015 07:21:05.686
Selected time for report: 08/24/2015 19:14:27 - 10/08/2015 07:21:05.686
Number of changes in configuration: 20
Number of changes to accounts, groups, or roles: 28
Number of logins: 56
Number of failed logins: 6
Number of authentications: 112
Number of failed authentications: 20
Number of users: 5
Number of terminals: 16
Number of host names: 8
Number of executables: 18
Number of files: 2
Number of AVC's: 7
Number of MAC events: 62
Number of failed syscalls: 0
Number of anomaly events: 6
Number of responses to anomaly events: 0
Number of crypto events: 913
Number of keys: 0
Number of process IDs: 1381
Number of events: 8933

Na jego podstawie, bez wnikania w szczegóły poszczególnych zdarzeń możemy określić np. ile nieudanych prób logowania miało miejsce w okresie czasu wymienionym w samym raporcie - domyślnie zawsze wykorzystywany jest aktualny plik logu, więc data zakończenia powinna być aktualna. Każde z wymienionych typów zdarzeń możemy, przy użyciu odpowiednich opcji uszczegółowić i wyraportować.

Przejdźmy zatem do samych opcji programu, generujących raporty w odniesieniu do różnych pól audit.log.

* -au wygeneruje nam raport z prób autentykacji w systemie, np:

[root@server ~]# aureport -au -i

Authentication Report
============================================
# date time acct host term exe success event
============================================
1. 10/08/2015 03:53:38 root 192.168.1.6 ssh /usr/sbin/sshd yes 3252
2. 10/08/2015 03:53:38 root 192.168.1.6 ssh /usr/sbin/sshd yes 3255
3. 10/08/2015 06:45:59 root 192.168.1.111 ssh /usr/sbin/sshd no 3524
4. 10/08/2015 06:45:59 root 192.168.1.111 ssh /usr/sbin/sshd no 3525
5. 10/08/2015 06:46:02 root 192.168.1.111 ssh /usr/sbin/sshd no 3526
6. 10/08/2015 06:46:02 root 192.168.1.111 ssh /usr/sbin/sshd no 3527
7. 10/08/2015 06:46:06 root 192.168.1.111 ssh /usr/sbin/sshd no 3528
8. 10/08/2015 06:46:06 root 192.168.1.111 ssh /usr/sbin/sshd no 3529
9. 10/08/2015 06:46:25 root 192.168.1.111 ssh /usr/sbin/sshd yes 3540
10. 10/08/2015 06:46:25 root 192.168.1.111 ssh /usr/sbin/sshd yes 3543
11. 10/08/2015 06:46:33 test 192.168.1.111 ssh /usr/sbin/sshd no 3565
12. 10/08/2015 06:46:33 test 192.168.1.111 ssh /usr/sbin/sshd no 3566
13. 10/08/2015 06:46:34 test 192.168.1.111 ssh /usr/sbin/sshd yes 3567
14. 10/08/2015 06:46:34 test 192.168.1.111 ssh /usr/sbin/sshd yes 3570

Z zestawienia możemy odczytać datę próby logowania, użytkownika, ip z którego próba była podjęta, jaki program został użyty, czy autoryzacja zakończyła się sukcesem oraz ID eventu audit.
Trzeba podkreślić tu fakt, że raport przedstawia próby autentykacji, czyli każdorazową weryfikacją pary user-hasło. Np. podczas logowania poprzez ssh i pomyłki przy wpisywaniu hasła dostaniemy możliwość podania hasła jeszcze raz. Pierwsza, nieudana próba wprowadzenia hasła zostanie zalogowana - sytuację taką widać powyżej - autentykacja użytkownika test o godz. 06:46:33 nie udała się (podano błędne hasło) a sekundę później zakończyła się sukcesem (podano poprawne hasło w drugiej próbie dla tej samej sesji ssh). Podwojenie wpisów jest wynikiem samego procesu autentykacji, i jest zachowaniem normalnym.

* --failed to opcja, która ograniczy nam wyniki naszego raportu jedynie do elementów, które nie zakończyły się sukcesem, i możemy stosować ją w połączeniu z bodaj wszystkimi opcjami rodzajowymi raportów (przeciwieństwem jej jest opcja --success):

[root@server ~]# aureport -au -i --failed

Authentication Report
============================================
# date time acct host term exe success event
============================================
1. 10/08/2015 06:45:59 root 192.168.1.111 ssh /usr/sbin/sshd no 3524
2. 10/08/2015 06:45:59 root 192.168.1.111 ssh /usr/sbin/sshd no 3525
3. 10/08/2015 06:46:02 root 192.168.1.111 ssh /usr/sbin/sshd no 3526
4. 10/08/2015 06:46:02 root 192.168.1.111 ssh /usr/sbin/sshd no 3527
5. 10/08/2015 06:46:06 root 192.168.1.111 ssh /usr/sbin/sshd no 3528
6. 10/08/2015 06:46:06 root 192.168.1.111 ssh /usr/sbin/sshd no 3529
7. 10/08/2015 06:46:33 test 192.168.1.111 ssh /usr/sbin/sshd no 3565
8. 10/08/2015 06:46:33 test 192.168.1.111 ssh /usr/sbin/sshd no 3566

* -l pokazuje nam statystyki logowania userów. W odróżnieniu od opcji -au przedstawione są tu faktyczne próby logowania - jeśli logowanie jest raportowane jako nieudane oznaczać to może, że np. hasło zostało podane błędnie trzykrotnie i serwer odnówił autoryzacji użytkownika, np:

[root@server ~]# aureport -l -i

Login Report
============================================
# date time auid host term exe success event
============================================
1. 10/08/2015 03:53:38 root 192.168.1.6 /dev/pts/0 /usr/sbin/sshd yes 3260
2. 10/08/2015 06:46:06 root 192.168.1.111 ssh /usr/sbin/sshd no 3533
3. 10/08/2015 06:46:25 root 192.168.1.111 /dev/pts/1 /usr/sbin/sshd yes 3548
4. 10/08/2015 06:46:35 root 192.168.1.111 /dev/pts/1 /usr/sbin/sshd yes 3579

* -c zaraportuje zmiany w konfiguracji - niezbyt czytelne i bez dalszej analizy chyba nieprzyatne

* -e wyświetli nam listę wszystkich eventóv w formie raportu

* -k wyświetli raport z występujących w logu kluczy reguł - możliwych do zdefiniowania indywidualnie wraz z niestandardowymi regułami. W przypadku, kiedy nie zdefiniowaliśmy własnych reguł ta opcja jest w zasadzie bezużyteczna, gdyż predefiniowane reguły nie używają kluczy.

* -m jest raportem przedstawiającym zmiany w kontach użytkowników. Raportowane są tu dodania kont, grup, usunięcia ich czy zmiany hasła.

* -n ciekawy raport prezentujący nietypowe w rozumieniu systemu zachowania. Co prawda sam raport nie mówi nam co spowodowało anomalię, ale daje nam możliwość zbadania tego faktu podając event ID zdarzenia, oraz dając możliwość zweryfikowania jak na taką anomalię system zareagował. Reakcję możemy sprawdzić wywołująć aureport z opcją -r.

* -p jest raportem PID-ów procesów

* -s to raport z SYSCALL-i

* --summary to bardzo przydatna opcja, pozwalająca na pogrupowanie i podliczenie wystąpień w konkretnym raporcie. Zapewnia nam dodatkową gradację szczegółowości raportów pomiędzy raportem sumarycznym i szczegółowym. Dla przykładu sumaryczny raport logowań:

[root@server ~]# aureport -i -l --summary

Login Summary Report
============================
total  auid
============================
36  root
19  test
3  unset
2  admin
2  test2

Niestety nie wszystkie raporty działają z tą opcją.
Co ciekawe, w przypadku raportów z logowań uwzględniane są nie tylko konta lokalne, ale również te autoryzujące się w źródłach zewnętrznych (jak np. w tym przypadku konta z IPA - konto admin)

* --tty wspomnianu już został przy okazji modułu pam_tty_audit. Służy do raportowania "klawiatury" użytkownika, który został w tymże module skonfigurowany.

* -tm raportuje terminale wykorzystywane przez system

* -ts [data] [godzina] to, tak jak w przypadku ausearch ogranicznik czasu wyświtlania raportu - time start. Możemy tu jako parametru użyć interesującej nas daty lub godziny, ale również aliasów: now, recent (10 minut temu), today (dziś od godz. 00:00:01), yesterday, last-week, last-month, last-year.

* -te [data] [godzina], czyli time end. Przyjmuje on parametry identyczne jak -ts

Pozostałe opcje zdają się być mniej użyteczne, ale warto je poznać, choćby dla uświadomienia sobie pełnych możliwości aureport. Standardowo w tym celu odeślę Cię do manuala systemowego, bo to nieocenione źródło informacji, które zawsze jest pod ręką.

[audit] Wyszukiwanie zdarzeń i interpretacja logów audytowych

Red Hat 6.x / CentOS 6.x

System audytowy loguje swoje wiadomości do pliku /var/log/audit/audit.log. Wpisy te zawierają dużo informacji różnego rodzaju i zależnie od typu zdarzenia jakie zaszło w systemie mogą nieznacznie różnić się pomiędzy sobą, dlatego analizowanie samego logu wymaga dokładnego wczytania się w jego treść. System oferuje różnego rodzaju narzędzia raportujące na podstawie tego logu, ale znajomość składni pliku może niekiedy okazać się przydatna.

Typowy wpis w audit.log wygląda podobnie do poniższego:

type=SYSCALL msg=audit(1440437032.702:20): arch=c000003e syscall=1 success=yes exit=1 a0=3 a1=7ffd651b08d0 a2=1 a3=7ffd651af650 items=0 ppid=2583 pid=2800 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=1 comm="setenforce" exe="/usr/sbin/setenforce" subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=(null)

Możemy w nim wyróżnić kilka charakterystycznych elementów:
* type=SYSCALL to typ wiadomości audytowej. Tutaj akurat wiadomość tyczy się wywołania systemowego, ale typów tych jest wiele.
* msg=audit(1440437032.702:20) zawiera w sobie znacznik czasu oraz ID wiadomości. Znacznik czasu znajduje się przed znakiem dwukropka i wyznacza liczbę sekund "od epoki". Za dwukropkiem znajdziemy ID wiadomości.
Znacznik czasu, jeśli zachodzi taka potrzeba możemy "zdekodować" używając systemowego polecenia date:

[root@ipaclient1 ~]# date --date=@1440437032.702
Mon Aug 24 19:23:52 CEST 2015

* arch to znacznik architektury procesora w notacji hexadecymalnej - c000003e oznacza x86_64
* syscall=1 to typ wywołania systemowego
* success=yes to efekt działania tego wywołania - w naszym wypadku wywołanie zakończyło się sukcesem
* exit=1 to exit code przesłany przez nasze wywołanie
* pola a0 - a3 to pierwsze cztery argumenty danego syscalla w notacji hexadecymalnej
* items=0 informuje nas o ilości wpisów danego typu dla danego eventu
* ppid to Parent Process ID dla procesu wywołującego nasz SYSCALL
* pid to Process ID
* auid to tzw. Audit User ID, czyli oryginalny UID użytkownika który nadawany jest po jego zalogowaniu do systemu i przekazywany do końca sesji
* uid oraz gid to UID iraz GID (group ID) użytkownika, który rozpoczął proces który audytujemy
* euid oraz egid to efektywny user ID oraz group ID
* fsuid oraz fsgid to file system uid i gid
* suid i sgid  pokazują set uid oraz set gid dla procesu
* tty to oczywiście terminal z którego proces rozpoczęto
* ses to ID sesji
* comm="setenforce" to commandline'owa komenda, która została użyta do wywołania naszego procesu
* exe to oczywiście ścieżka do wykonanej binarki
* subj przedstawia nam kontekst selinuxa z jakim analizowany proces się rozpoczął
* key jest definiowanym w regule audytowej kluczem/nazwą danej reguły (bliżej poznamy podczas tworzenia własnych reguł)

Część pól ma oczywiste przełożenie na elementy procesu, więc analiza takiego wpisu nie będzie problemem, poza tym, że ilość danych spowoduje, że czas potrzebny do takiej analizy będzie dość znaczący.

Wyszukiwanie zdarzeń audit - ausearch

Paza zwykłym grepowaniem logu audit.log mamy możliwość przeszukiwania tegoż logu za pomocą narzędzia systemowego o nazwie ausearch. Ma ono taką przewagę nad zwykłym grepem, że potrafi interpretować część pól logu, np. zamieniając uid usera na jego nazwę czy prezentować datę wystąpienia w czytelnym formacie.

Najprzydatniejszymi operatorami komendy są moim zdaniem:
* -i powodujący interpretację pól logu
* -a event_id wyszukujący w logu wpisy dla konkretnego zdarzenia
* -c comm_name  wyszukujący wpisy dla konkretnej komendy commandline'a
* -k klucz wyszukująca po kluczu/nazwie reguły
* -p PID szukająca po PID procesu
* -x /sciezka/do/binariów szukająca zdarzeń generowanych przez konkretne binarium
* -ts [data] [godzina] lub -te [data] [godzina] ograniczające czasowo wyszukiwanie - ts to 'time start', analogicznie te to 'time end'. Przydatne mogą okazać się tu możliwe do użycia słowa kluczowe określające czas. Do wyboru mamy now, recent, today, yesterday, this-week, this-month oraz this-year. Aliasy, poza recent i now to czas zaczynający się 1 sekundę po północy odpowiednio dziś, wczoraj, pierwszego dnia tygodnia (zależnie od ustawień lokalnych), pierwszego dnia miesiąca czy roku. Recent oznacza 10 minut przed aktualną godziną. Oczywiście nic nie stoi na przeszkodzie, aby podać konkretną datę i godzinę (zgodnie z naszym formatem systemowym).

Opcji jest więcej, i naturalnie opisane są w manualu dla ausearch.
Korzystając z przytaczanego wcześniej wpisu sprawdźmy działanie ausearch. Na początek sprawdźmy jakie wpisy znajdziemy dla komendy setenforce:

[root@ipaclient1 ~]# ausearch -i -c setenforce
----
type=SYSCALL msg=audit(08/24/2015 19:23:52.702:20) : arch=x86_64 syscall=write success=yes exit=1 a0=0x3 a1=0x7ffd651b08d0 a2=0x1 a3=0x7ffd651af650 items=0 ppid=2583 pid=2800 auid=root uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=pts0 ses=1 comm=setenforce exe=/usr/sbin/setenforce subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=(null)
type=MAC_STATUS msg=audit(08/24/2015 19:23:52.702:20) : enforcing=0 old_enforcing=1 auid=root ses=1

Możemy też zweryfikować co jeszcze w danym procesie się działo, wyszukując wpisów dotyczących konkretnego ID zdarzenia. Jak wynika z analizy pól logu ID takie znajdziemy w polu msg=audit(1440437032.702:20), i będzie nim wartość widniejąca po dwukropku:

[root@ipaclient1 ~]# ausearch -i -a 20
----
type=SYSCALL msg=audit(08/24/2015 19:23:52.702:20) : arch=x86_64 syscall=write success=yes exit=1 a0=0x3 a1=0x7ffd651b08d0 a2=0x1 a3=0x7ffd651af650 items=0 ppid=2583 pid=2800 auid=root uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=pts0 ses=1 comm=setenforce exe=/usr/sbin/setenforce subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=(null)
type=MAC_STATUS msg=audit(08/24/2015 19:23:52.702:20) : enforcing=0 old_enforcing=1 auid=root ses=1
----
type=CRED_ACQ msg=audit(08/29/2015 14:57:02.602:20) : user pid=2983 uid=root auid=root ses=1 subj=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 msg='op=PAM:setcred acct=root exe=/usr/sbin/sshd hostname=192.168.1.6 addr=192.168.1.6 terminal=ssh res=success'
----
type=CRYPTO_KEY_USER msg=audit(08/31/2015 09:47:39.839:20) : user pid=2090 uid=root auid=root ses=1 subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 msg='op=destroy kind=server fp=97:8b:22:1c:92:9d:f9:b7:b5:96:ee:f2:c5:3b:d5:59 direction=? spid=2090 suid=root  exe=/usr/sbin/sshd hostname=? addr=192.168.1.6 terminal=pts/0 res=success'
----
type=CRYPTO_KEY_USER msg=audit(08/31/2015 09:51:39.095:20) : user pid=2081 uid=root auid=root ses=1 subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 msg='op=destroy kind=server fp=97:8b:22:1c:92:9d:f9:b7:b5:96:ee:f2:c5:3b:d5:59 direction=? spid=2081 suid=root  exe=/usr/sbin/sshd hostname=? addr=192.168.1.6 terminal=pts/0 res=success'
----
type=CRYPTO_KEY_USER msg=audit(08/31/2015 10:34:17.588:20) : user pid=2085 uid=root auid=root ses=1 subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 msg='op=destroy kind=server fp=97:8b:22:1c:92:9d:f9:b7:b5:96:ee:f2:c5:3b:d5:59 direction=? spid=2085 suid=root  exe=/usr/sbin/sshd hostname=? addr=192.168.1.6 terminal=pts/0 res=success'
----
type=CRYPTO_KEY_USER msg=audit(08/31/2015 11:03:31.530:20) : user pid=2090 uid=root auid=root ses=1 subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 msg='op=destroy kind=server fp=97:8b:22:1c:92:9d:f9:b7:b5:96:ee:f2:c5:3b:d5:59 direction=? spid=2090 suid=root  exe=/usr/sbin/sshd hostname=? addr=192.168.1.6 terminal=pts/0 res=success'
----
type=CRYPTO_KEY_USER msg=audit(08/31/2015 20:25:27.072:20) : user pid=2197 uid=root auid=root ses=1 subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 msg='op=destroy kind=server fp=97:8b:22:1c:92:9d:f9:b7:b5:96:ee:f2:c5:3b:d5:59 direction=? spid=2197 suid=root  exe=/usr/sbin/sshd hostname=? addr=192.168.1.6 terminal=pts/0 res=success'
----
type=LOGIN msg=audit(08/31/2015 20:30:21.466:20) : pid=2085 uid=root subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 old auid=unset new auid=root old ses=unset new ses=2
----
type=USER_AUTH msg=audit(09/21/2015 16:45:31.927:20) : user pid=2386 uid=root auid=unset ses=unset subj=system_u:system_r:local_login_t:s0-s0:c0.c1023 msg='op=PAM:authentication acct=root exe=/bin/login hostname=? addr=? terminal=tty1 res=success'
----
type=CRYPTO_KEY_USER msg=audit(09/22/2015 02:06:57.511:20) : user pid=2201 uid=root auid=root ses=1 subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 msg='op=destroy kind=server fp=97:8b:22:1c:92:9d:f9:b7:b5:96:ee:f2:c5:3b:d5:59 direction=? spid=2201 suid=root  exe=/usr/sbin/sshd hostname=? addr=192.168.1.6 terminal=pts/0 res=success'
----
type=CRYPTO_KEY_USER msg=audit(09/22/2015 22:55:13.412:20) : user pid=2196 uid=root auid=root ses=1 subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 msg='op=destroy kind=server fp=97:8b:22:1c:92:9d:f9:b7:b5:96:ee:f2:c5:3b:d5:59 direction=? spid=2196 suid=root  exe=/usr/sbin/sshd hostname=? addr=192.168.1.6 terminal=pts/0 res=success'
----
type=CRYPTO_KEY_USER msg=audit(09/23/2015 20:54:36.517:20) : user pid=2198 uid=root auid=root ses=1 subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 msg='op=destroy kind=server fp=97:8b:22:1c:92:9d:f9:b7:b5:96:ee:f2:c5:3b:d5:59 direction=? spid=2198 suid=root  exe=/usr/sbin/sshd hostname=? addr=192.168.1.6 terminal=pts/0 res=success'

Nie będę tu dokonywał analizy wyników zapytania, ponieważ nie to było celem tego tekstu. Opierając się na nim możesz natomiast dość sprawnie sam sprawdzić co działo się w systemie...

Pluggable authentication modules (PAM) - rejestrowanie poczynań użytkowników - pam_tty_audit

Red Hat 6.x / CentOS 6.x

Ciekawym modułem PAM pozwalającym rejestrować poczynania użytkownika w sposób wręcz paranoiczny jest pam_tty_audit.

Moduł konfigurujemy poprzez określenie jako opcji loginu lub loginów użytkowników których chemy śledzić. Działa on jedynie dla typu session, i w taki sposób go skonfigurujemy.

Konfiguracja odbywa się w znanych już plikach /etc/pam.d/system-auth oraz /etc/pam.d/password-auth:

session     optional      pam_keyinit.so revoke
session     required      pam_tty_audit.so enable=test,test2
session     required      pam_limits.so

Przytoczony powyżej przykład spowoduje logowanie działań użytkowników test oraz test2.

Do dyspozycji posiadamy opcje konfiguracyjne:
* enable= - określa oddzielone przecinkiem loginy użytkowników, których chcemy śledzić. Możliwe jest użycie wildcarda * definiującego wszystkich userów w systemie.
* disable= - loginy użytkowników, których śledzić nie chcemy
* log_passwd - standardowo nie są logowane wpisywane przez użytkownika hasła - tą opcją możemy ten stan zmienić

Kolejność wystąpienia opcji enable i disable jest istotna i determinuje zachowanie modułu. Należy pamiętać, że są parsowane w kolejności podania, a każda z nich nadpisuje listę użytkowników z poprzedniej. Inne zatem działanie będzie miała składnia enable=* disable=root logując wszystkich poza rootem, a inne disable=root enable=* logując wszystkich bez wyjątku.

Do przeglądania zalogowanych zdarzeń używać będziemy narzędzia dedykowanego do generowania raportów audytowych z usługi auditd, a mianowicie aureport. Zastosowanie opcji -i powoduje "interpretację" uid usera, czyli jego podmianę na nazwę użytkownika.

[root@server pam.d]# aureport --tty -i

TTY Report
===============================================
# date time event auid term sess comm data
===============================================
1. 10/07/2015 17:26:09 2480 test ? 331 bash <ret>,<ret>,<ret>,"ll",<ret>,"csd /.",<backspace>,<backspace>,<backspace>,<backspace>,<backspace>,"d /tmp",<ret>,"ll",<ret>,"cd o",<tab>,<ret>,"ll",<ret>,<up>,<up>,<tab>,<tab>,"g",<tab>,<ret>,"l",<backspace>,<^D>
2. 10/07/2015 18:46:47 2576 test ? 341 less "q"
3. 10/07/2015 18:46:48 2577 test ? 341 bash "test",<ret>,"man test",<ret>,<^D>
4. 10/07/2015 19:02:43 2699 test ? 348 bash "ll",<ret>,"touch test",<ret>,<^D>
5. 10/07/2015 19:02:57 2725 test2 ? 349 bash "ll",<ret>,"pwd",<ret>,"touch test",<ret>,<^D>

Jak widać na przykładzie logowanie jest bardzo dokładne i w podstawowej opcji obejmuje niciśnięcie przez użytkownika każdego klawisza, jeśli wpisywane znaki nie są częścią hasła.