Pakiet auditd
Monitoring Linux Ubuntu 20.04 LTS za pomocą auditd jest niezwykle przydatny. Pakiet auditd to system audytujący dla systemu Linux, który umożliwia monitorowanie zdarzeń związanych z pracą systemu np:
- operacjami wykonanymi na plikach,
- operacjami wykonanymi na katalogach,
- wywołaniami poleceń systemowych,
Kompletna lista zdarzeń jakie mogą być monitorowane jest znacznie dłuższa, w kolejnych postach dodam więcej informacji. Tutaj opiszę podstawowy monitoring Linux Ubuntu 20.04 LTS za pomocą auditd.
Pakiet auditd jest dostępny w wielu dystrybucjach, często też instaluje się automatycznie w podstawowej wersji danej dystrybucji.
W dalszej części artykułu posłużę się przykładami opartymi o instalację auditd na systemie Ubuntu 20.04 LTS. Jeśli masz inną dystrybucję systemu Linux to zwróć uwagę na ścieżki do plików konfiguracyjnych oraz polecania związane z zarządzaniem usługą auditd (uruchamianie, restartowanie i zatrzymywanie usługi). W Twojej dystrybucji składania poleceń może się różnić.
Rekomenduje najpierw wykonać aktualizacji repozytorium pakietów (ja pracuje na zwykłym użytkowniku, pakiety instaluje za pomocą:
sudo apt updateNastępnie zainstalować pakiet auditd:
sudo apt install auditd -yPo poprawnej instalacji poniżej zweryfikowałem czy usługa uruchomiła się automatycznie. Wydałem polecenie:
sudo systemctl status auditd.serviceA uzyskany wynik potwierdza że usługa działa poprawnie.
tematy.it@auditd:~$ sudo systemctl status auditd.service
● auditd.service - Security Auditing Service
Loaded: loaded (/lib/systemd/system/auditd.service; enabled; vendor preset: enabled)
Active: active (running) since Sat 2023-02-25 10:00:45 UTC; 2h 57min ago
Docs: man:auditd(8)
https://github.com/linux-audit/audit-documentation
Main PID: 2695 (auditd)
Tasks: 2 (limit: 6853)
Memory: 1.5M
CGroup: /system.slice/auditd.service
└─2695 /sbin/auditd
Feb 25 10:00:45 auditd augenrules[2709]: backlog_wait_time 15000
Feb 25 10:00:45 auditd augenrules[2709]: enabled 1
Feb 25 10:00:45 auditd augenrules[2709]: failure 1
Feb 25 10:00:45 auditd augenrules[2709]: pid 2695
Feb 25 10:00:45 auditd augenrules[2709]: rate_limit 0
Feb 25 10:00:45 auditd augenrules[2709]: backlog_limit 8192
Feb 25 10:00:45 auditd augenrules[2709]: lost 0
Feb 25 10:00:45 auditd augenrules[2709]: backlog 0
Feb 25 10:00:45 auditd augenrules[2709]: backlog_wait_time 0
Feb 25 10:00:45 auditd systemd[1]: Started Security Auditing Service.
Przykłady konfiguracji auditd związane z monitorowaniem plików
Czas dodać kilka reguł, które pozwolą zaobserwować działanie usługi auditd.
Zaczniemy od monitorowania zmian dla konkretnego pliku. Jak wiadomo w katalogu /etc trzymane są pliki konfiguracyjne odpowiadające za wiele aspektów pracy systemu operacyjnego. Dlatego w kontekście cyberbezpieczeństwa na pewno warto monitorować zmiany dotyczące plików w tym katalogu. W dalszej części niniejszego wpisu posłużę się regułami które pozwolą monitorować plik /etc/group.
Jeszcze krótki listing zdarzeń jakie możliwe są do monitorowania w kontekście plików:
- r – monitorowanie zdarzeń związanych z odczytem pliku,
- w – monitorowanie zdarzeń związanych z zapisem pliku,
- x – monitorowanie zdarzeń związanych z wykonaniem pliku,
- a – monitorowanie zdarzeń związanych ze zmianą atrybutów pliku.
Ponieważ plik /etc/group jest plikiem którego odczyt jest niezbędny dla wielu komponentów w systemie operacyjnym Linux, monitorowanie odczytu zostanie pominięte w testach. Nie będziemy też monitorować uruchomienia pliku który nie jest z zasady plikiem wykonywalnym. Dobrą praktyką jest unikanie generowania nadmiarowych informacji w logach, ponieważ może to utrudnić wykrycie i reakcję na naprawdę istotne zdarzenia.
Testujemy monitoring pliku /etc/group
Zacznijmy od dodania reguły dla naszego przykładu.
sudo auditctl -w /etc/group -p wa -k monitoring_groupPoniższym poleceniem sprawdzam czy reguła jest aktywna:
sudo auditctl -lPoniższy wynik potwierdza że reguła jest aktywna:
-w /etc/group -p wa -k monitoring_groupW dalszym kroku otworzyłem plik /etc/group w edytorze nano, a następnie zapisałem go (bez wprowadzania zmian). Teraz poszukam zdarzenia za pomocą polecenia:
sudo ausearch -k monitoring_groupWynik jest następujący:
time->Sat Feb 25 20:09:16 2023
type=CONFIG_CHANGE msg=audit(1677355756.323:612): auid=1001 ses=6 op=add_rule key="monitoring_group" list=4 res=1
----
time->Sat Feb 25 20:13:50 2023
type=PROCTITLE msg=audit(1677356030.467:625): proctitle=6E616E6F002F6574632F67726F7570
type=PATH msg=audit(1677356030.467:625): item=1 name="/etc/group" inode=263690 dev=08:03 mode=0100644 ouid=0 ogid=0 rdev=00:00 nametype=NORMAL cap_fp=0 cap_fi=0 cap_fe=0 cap_fver=0 cap_frootid=0
type=PATH msg=audit(1677356030.467:625): item=0 name="/etc/" inode=262145 dev=08:03 mode=040755 ouid=0 ogid=0 rdev=00:00 nametype=PARENT cap_fp=0 cap_fi=0 cap_fe=0 cap_fver=0 cap_frootid=0
type=CWD msg=audit(1677356030.467:625): cwd="/home/tematy.it"
type=SYSCALL msg=audit(1677356030.467:625): arch=c000003e syscall=257 success=yes exit=3 a0=ffffff9c a1=555dfe0c5cd0 a2=241 a3=1b6 items=2 ppid=4047 pid=4048 auid=1001 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=6 comm="nano" exe="/usr/bin/nano" key="monitoring_group"
Jak widać polityka monitoringu zadziałała.
Kolejny test – zmienię atrybuty pliku za pomocą polecenia:
sudo chown tematy.it:root /etc/groupZdarzenia zarejestrowane w logu:
time->Sat Feb 25 21:12:45 2023
type=PROCTITLE msg=audit(1677359565.371:696): proctitle=63686F776E0074656D6174792E69743A726F6F74002F6574632F67726F7570
type=PATH msg=audit(1677359565.371:696): item=0 name="/etc/group" inode=263690 dev=08:03 mode=0100644 ouid=0 ogid=0 rdev=00:00 nametype=NORMAL cap_fp=0 cap_fi=0 cap_fe=0 cap_fver=0 cap_frootid=0
type=CWD msg=audit(1677359565.371:696): cwd="/home/tematy.it"
type=SYSCALL msg=audit(1677359565.371:696): arch=c000003e syscall=260 success=yes exit=0 a0=ffffff9c a1=55e170bd2120 a2=3e9 a3=0 items=1 ppid=4262 pid=4263 auid=1001 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts1 ses=101 comm="chown" exe="/usr/bin/chown" key="monitoring_group"
Oraz jeszcze jeden test – przekopiowałem plik /etc/group do katalogu /tmp, tam go zmodyfikowałem, następnie nadpisałem zmodyfikowanym plikiem ten oryginalny w lokalizacji /etc/group. Taka czynność też została zarejestrowana:
time->Sat Feb 25 21:33:54 2023
type=PROCTITLE msg=audit(1677360834.387:53): proctitle=6370002F746D702F67726F7570002F6574632F67726F7570
type=PATH msg=audit(1677360834.387:53): item=0 name="/etc/group" inode=263690 dev=08:03 mode=0100644 ouid=0 ogid=0 rdev=00:00 nametype=NORMAL cap_fp=0 cap_fi=0 cap_fe=0 cap_fver=0 cap_frootid=0
type=CWD msg=audit(1677360834.387:53): cwd="/home/tematy.it"
type=SYSCALL msg=audit(1677360834.387:53): arch=c000003e syscall=257 success=yes exit=4 a0=ffffff9c a1=7ffc881748e2 a2=201 a3=0 items=1 ppid=2587 pid=2588 auid=1001 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=6 comm="cp" exe="/usr/bin/cp" key="monitoring_group"
Przykłady konfiguracji auditd związane z monitorowaniem poleceń
Zacznijmy od dodania reguły dla naszego przykładu. Będziemy logować wszystkie komendy które zostaną wywołane za pomocą polecenia sudo.
sudo auditctl -a always,exit -F exe=/usr/bin/sudo -F arch=b64 -S execve -k execution_user_bin_sudogdzie opcje: a – loguj zawsze, po zakończeniu wywołania polecenia, F – to ścieżka do pliku którego wykonanie chcemy monitorować oraz architektura systemu, S monitorowanie wywołań syscall i k -przypisanie do nazwy po której będziemy monitorować regułę.
Poniżej weryfikacja co zostało zarejestrowane przy pomocy polecenia:
sudo ausearch -k execution_user_bin_sudoWynik poniżej:
time->Sun Feb 26 21:43:47 2023
type=PROCTITLE msg=audit(1677447827.270:518): proctitle=7375646F006175736561726368002D6B00657865637574696F6E5F757365725F62696E5F7375646F
type=PATH msg=audit(1677447827.270:518): item=1 name="/lib64/ld-linux-x86-64.so.2" inode=5114909 dev=08:03 mode=0100755 ouid=0 ogid=0 rdev=00:00 nametype=NORMAL cap_fp=0 cap_fi=0 cap_fe=0 cap_fver=0 cap_frootid=0
type=PATH msg=audit(1677447827.270:518): item=0 name="/usr/bin/sudo" inode=5121581 dev=08:03 mode=0104755 ouid=0 ogid=0 rdev=00:00 nametype=NORMAL cap_fp=0 cap_fi=0 cap_fe=0 cap_fver=0 cap_frootid=0
type=CWD msg=audit(1677447827.270:518): cwd="/home/tematy.it"
type=EXECVE msg=audit(1677447827.270:518): argc=4 a0="sudo" a1="ausearch" a2="-k" a3="execution_user_bin_sudo"
type=SYSCALL msg=audit(1677447827.270:518): arch=c000003e syscall=59 success=yes exit=0 a0=55df71b32de0 a1=55df719fbc70 a2=55df71af9420 a3=8 items=2 ppid=1944 pid=3982 auid=1001 uid=1001 gid=1001 euid=0 suid=0 fsuid=0 egid=1001 sgid=1001 fsgid=1001 tty=pts0 ses=7 comm="sudo" exe="/usr/bin/sudo" key="execution_user_bin_sudo"Narzędzie ausearch – czytelne raportowanie
W pakiecie auditd znajduje się program ausearch który za pomocą poniższych przełączników wyświetli nam niezbędne logi w bardziej czytelnej formie:
sudo ausearch -k monitoring_group | aureport -f -iWynik:
File Report
===============================================
# date time file syscall success exe auid event
===============================================
1. 02/25/2023 21:33:54 /etc/group openat yes /usr/bin/cp tematy.it 53
2. 02/25/2023 21:37:37 /etc/group openat yes /usr/bin/nano tematy.it 73
3. 02/25/2023 21:37:54 /etc/group fchownat yes /usr/bin/chown tematy.it 80
4. 02/25/2023 21:41:18 /etc/group fchownat yes /usr/bin/chown tematy.it 99
W kwestii logowania wywołań poleceń przy pomocy polecenia sudo (a więc z poleceń wywołanych z podwyższonymi uprawnieniami) z pomocą może przyjść taka komenda:
sudo cat /var/log/audit/audit.log |grep EXECVEW wyniku widać dokładnie jakie komendy zostały poprzedzone poleceniem sudo:
type=EXECVE msg=audit(1677447699.414:504): argc=3 a0="sudo" a1="cat" a2="/var/log/audit/audit.log"
type=EXECVE msg=audit(1677447746.393:511): argc=4 a0="sudo" a1="ausearch" a2="-k" a3="execution_user_bin_sudo"
type=EXECVE msg=audit(1677447827.270:518): argc=4 a0="sudo" a1="ausearch" a2="-k" a3="execution_user_bin_sudo"
type=EXECVE msg=audit(1677448342.735:531): argc=3 a0="sudo" a1="ping" a2="www.wp.pl"
type=EXECVE msg=audit(1677448346.777:538): argc=3 a0="sudo" a1="cat" a2="/var/log/audit/audit.log"Reguły auditd – zapis do pliku
W powyższym artykule zostały zaproponowane reguły, które są aktywne do momentu restartu usługi auditd, ręcznego skasowania za pomocą polecenia sudo auditctl -D, lub ponownego uruchomienia systemu operacyjnego. Jeśli chcemy zachować nasze reguły, należy zapisać je do pliku za pomocą poniższego polecenia:
sudo auditctl -l | sudo tee -a /etc/audit/rules.d/tematyka.it.rulesPodumowanie monitoring Linux Ubuntu 20.04 LTS za pomocą auditd
Powyższy opis to skrócone i płytkie wprowadzenie w temat. Otrzymane wyniki pozwalają potwierdzić że miało miejsce zdarzenie związane z tym co nas interesuje – z plikiem lub wywołaniem dane polecenia. Jednak samo ustalenie co dokładnie się stało, oraz kto za to podpowiada może wymagać wykonania dodatkowych czynności, oraz szerszego przedstawienia bardzo szczegółowych informacji z logu auditid. To co przedstawiono w artykule może Cię zainteresować i pozwoli zbudować rozwiązanie niezbędne do spełnienia wymogów np. norm PCIDSS i ISO27001. W kolejnych wpisach przedstawię temat opisując więcej szczegółów.