Monitoring Linux Ubuntu 20.04 LTS za pomocą auditd

(tematyka.it)Linux

Pakiet auditd

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.

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 update

Następnie zainstalować pakiet auditd:

sudo apt install auditd -y

Po poprawnej instalacji poniżej zweryfikowałem czy usługa uruchomiła się automatycznie. Wydałem polecenie:

sudo systemctl status auditd.service

A 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_group

Poniższym poleceniem sprawdzam czy reguła jest aktywna:

sudo auditctl -l

Poniższy wynik potwierdza że reguła jest aktywna:

-w /etc/group -p wa -k monitoring_group

W 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_group

Wynik 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/group

Zdarzenia 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_sudo

gdzie 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_sudo

Wynik 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 -i

Wynik:

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 EXECVE

W 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.rules

Podumowanie

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.

Dodaj komentarz

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *