Linux Auditing System – Monitorowanie zmian w systemie za pomocą auditd

By | 9 listopada 2011

Często zdarza się, że chcemy sprawdzić kto zmieniał, podglądał czy tworzył nowe pliki w systemie. Co więcej, chcemy być o tym informowani na bieżąco zwłaszcza przy plikach konfiguracyjnych czy dostępie do logów. Na pomoc przychodzi nam usługa auditd.

Audit Daemon pozwala na tworzenie reguł dzięki którym dowiemy się kto, kiedy i czym edytował, podglądał czy tworzył plik. Całość jest odkładana w logu /var/log/audit/audit.log

w dość niezrozumiałym formacie, jednak dostępne w pakiecie narzędzia pozwalają na „human readable” odczyt.

1. Instalacja
Ale zacznijmy od początku. Instalacja pakietu może odbyć się za pomocą dostępnych narzędzi systemowych (takich jak yum, apt czy zypper) jak również ze źródeł.

Z racji tego, iż poniższy post piszę pod kątem systemu CentOS 6 będę bazował na yum’ie.

Aby zainstalować cały pakiet, wykonujemy:

(w systemie CentOS 6 paczka ta powinna już być zainstalowana).

2. Uruchomienie
Po instalacji w katalogu /etc/audit/ znajdują się pliki konfiguracyjne:

 

W pliku auditd.conf konfigurujemy całą usługę zaś w pliku audit.rules możemy wstawiać nasze reguły tak, aby po restarcie serwera czy usługi były one zachowane.
Aby sprawdzić czy usługa chodzi wykonujemy:

Z tej linijki możemy wyczytać, iż usługa jest wyłączona. Mówią o tym dwa parametry: enabled, który ma wartość 0 oraz pid który ma również wartość zerową. Aby uruchomić usługę wykonujemy a następnie sprawdzamy:

Jak widać, usługa ma status enabled=1 oraz ma przydzielony ID procesu czyli pid=2670.

3. Wykorzystanie auditd do monitorowania zmian na plikach
Wszystkie zmiany w regułach auditd wykonujemy za pomocą polecenia auditctl.
Załóżmy sytuację: chcemy monitorować kto wprowadza zmiany w pliku /etc/motd. Tworzymy więc regułę, która „nasłuchuje” zmian w pliku (wykorzystywanie praw w – write). A więc do roboty:

Co robi powyższa reguła? W skrócie:
-w /etc/motd – parametrem -w (watch) wskazujemy jaką lokalizację chcemy monitorować.
-p w – parametrem -p (permissions) wskazujemy na jakie uprawnienia ma być „uczulony” auditd
-k etc_motd_watch – parametrem -k (key) nazywamy naszą regułę. Dobrą wskazówką jest nazywanie kluczy w sposób mówiący czego ona dotyczy (w późniejszym czasie ułatwi nam to przeszukiwanie eventów).

Aby wyświetlić aktualnie stworzone reguły wykonujemy:

W powyższym przykładnie monitorujemy konkretny plik. Nie ma zaś żadnego problemu aby obserwował cały katalog. Reguła w przypadku chęci obserwowania całego katalogu wygląda następująco:

Aby usunąć pojedyncze wpisy wykonujemy:

(małe w zamieniamy na duże W).

Aby usunąć wszystkie wpisy wykonujemy:

Możemy również na stałe zablokować możliwość usuwania oraz edytowania zasad poprzez włączenie auditd w trybie „read only”:

4. Przeszukiwanie zebranych informacji
Jak już wcześniej wspomniałem gromadzone logi nie są zbyt czytelne (chodzi o ich skupienie, brak godzin i dat). Owszem da się z nich wyczytać to co chcemy, ale nie w przejrzystej. Aby przetestować funkcjonalność wykonajmy więc test na założonych regułach.
Utwórzmy więc plik o nazwie test_auditd w katalogu /etc a następnie sprawdźmy (po kluczu reguły) jakie zostało wyłapane zdarzenie.

Zacznę od pokreślenia, iż log został wydobyty poleceniem:

Poszczególne eventy są oddzielonie myślnikam (—-). A więc zacznijmy analizować to co dostaliśmy.
Pierwsza sekcja (type=CONFIG_CHANGE) informuje nas o tym, że dodano nową regułę o nazwie etc_watch (op=”add rule” key=etc_watch).
Następna sekcja tyczy się już wyłącznie utworzenia nowego pliku. Pogrubionym tekstem oznaczyłem to co nas interesuje, czyli:
– nazwa obiektu zaobserwowanego (name=test_auditd)
– nazwa lokalizacji (name=/etc)
– z jakiej lokalizacji zauważono zmianę (type=CWD msg=audit(11/07/2011 11:04:22.670:46) : cwd=/etc)
– nazwa rzeczywista użytkownika oraz z jakiego użytkownika wykonano zdarzenie (auid=mike uid=root gid=root)
– nazwa polecenia oraz ścieżka do pliku ( comm=touch exe=/bin/touch)
– jakiego klucza tyczy się zaobserwowane zdarzenie (key=etc_watch)

Za pomocą polecenia „ausearch” możemy również wyświetlać wszelkie informacje które znajdują się w audit.log.
Aby wyświetlić listę w formie „human readable” wykonujemy:

Możemy również określić zakres czasowy z którego chcemy uzyskać logi:

W celu wyświetlenia danych z danego przedziału czasowego wykorzystujemy przełącznik ausearch -ts. Możemy podać w nim takie wartości jak: 12:00, today, 7/11/2011.

Możemy wykorzystać również przełącznik -te określając koniec przedziału czasowego.

5. Informacje z SELinux
W logu audit.log znajdziemy również wszystkie informacje które przekazuje nam SELinux. Za pomocą narzędzi z pakietu audit możemy również wyszukiwać zdarzenia którymi zasypuje nas SELinux (o ile nie został on wyłączony podczas instalacji :-)).
Znając kontkesty wykorzystywane przez nasze aplikacje, możemy sprawdzić jakie zdarzenia zostały wygenerowane. Dla przykładu:
w konfiguracji serwera www HTTPD dopisałem linijkę

Teoretycznie demon powinien po restarcie wystartować i nasłuchiwać na tym porcie. Jednak reguły SELinuksa (o ile nie został ten port dopuszczony) nie pozwalają nasłuchiwać na innym porcie niż 80, 443 czy też 8080.
Sprawdźmy więc jakie zdarzenie zostało wygenerowane:

W powyższym kodzie zaznaczyłem linijki które nas informują o zablokowaniu dostępu do portu (avc: denied {name_bind}).

Nie znajdąc konktekstu SELinuksa możemy również wyszukiwać informacji po jej type:

Audit Daemon jest narzędziem podstawowym podczas zabezpieczania systemów oraz monitorowania ich bezpieczeństwa oraz dostępności. Podczas projektowania wewnętrznego systemu bezpieczeństwa powinniśmy uwzględnić osobny projekt użycia Audit demona jak również SELinuksa. Istnieje wiele rozwiązań podwyższających bezpieczeństwo systemów. Większość z nich istnieje już w systemie a więc nie musimy rozglądać się za dedykowanym oprogramowaniem. Użycie auditd powinno wliczać się do hardenowania systemów linuksowych.

Przedstawione powyżej rozwiązania nie są jedynymi które dostarcza auditd. Możemy również monitorować wywołania systemowe (syscalls), śledzenie procesów, wykonywanych funkcji. Zapraszam do zapoznania się z wiecznie pożytecznym man auditctl

🙂

2 thoughts on “Linux Auditing System – Monitorowanie zmian w systemie za pomocą auditd

  1. mike Post author

    Szczerze mówiąc nie, ale z tego co widzę to auth2db zajmuje się logami autoryzacyjnymi i wsadza je do bazy (ble). Polecał bym raczej OSSECa jako IDS/HIDS/FIM a jako web interface Prelude Prewikka 🙂

    Reply

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *