[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 :)