Jędrzej Boguszyński

Systemy z rodziny Linux stanowią obecnie fundament globalnej sieci, napędzając około 90% światowej infrastruktury. Ponieważ najczęściej pełnią one role środowisk krytycznych, zapewnienie im odpowiedniego poziomu bezpieczeństwa i ciągłego monitoringu jest absolutnym priorytetem. Doskonałym narzędziem do tego celu jest Wazuh – otwartoźródłowa platforma do wykrywania zagrożeń, monitorowania integralności i reagowania na incydenty.

Choć Wazuh już na starcie (out of the box) potrafi wyciągnąć ogromną wartość ze standardowych logów systemowych, to dopiero integracja z podsystemem auditd uwalnia jego pełny potencjał. Połączenie to pozwala na zaawansowaną analitykę działań użytkowników, natychmiastowe wykrywanie nadużyć uprawnień oraz śledzenie podejrzanych komend wykonywanych w czasie rzeczywistym.

Dlaczego Wazuh potrzebuje auditd?

Standardowe logi (syslog) doskonale sprawdzają się przy monitorowaniu ogólnej kondycji systemu, ale są ślepe na konkretne działania wewnątrz powłoki (shella) użytkownika. Integracja z auditd eliminuje tę martwą strefę, wzbogacając strumień telemetrii trafiający do platformy Wazuh o:

• Monitorowanie działań administratorów: Każda komenda wykonywana z uprawnieniami root jest rejestrowana na poziomie jądra systemu, a następnie analizowana przez silnik reguł Wazuh.
• Wykrywanie nadużyć uprawnień: Każda próba nieautoryzowanej eskalacji przywilejów zostanie natychmiast wychwycona dzięki szczegółowemu śledzeniu wywołań systemowych (syscalls).
• Zgodność z normami (PCI DSS, HIPAA, NIST): Szczegółowy audyt dostępu do plików oraz operacji systemowych to fundament wymagań stawianych przez najważniejsze frameworki regulacyjne.
• Widoczność po uwierzytelnieniu: Nawet jeśli logowanie przebiegło pomyślnie, Wazuh stale monitoruje aktywność wewnątrz sesji użytkownika, co pozwala na wykrycie nietypowych zachowań lub prób ataków wewnętrznych (insider threats).

Jak skonfigurować Auditd na końcówce?

Konfiguracja Auditd jest dosyć prosta. W moim home lab używam systemu Debian 13 i to na jego przykładzie pokażę Wam cały proces.

Najpierw musimy zainstalować Auditd z oficjalnego repo przy pomocy apt:

sudo apt install auditd audispd-plugins

Po zainstalowaniu otwieramy plik /etc/audit/audit.rules np przy pomocy nano.

nano /etc/audit/audit.rules

Choć w sieci można znaleźć gotowe, obszerne zestawy reguł (jak te rozwijane przez społeczność wokół projektów SOCFortress), na potrzeby tego wpisu przygotujemy dedykowany, lżejszy zestaw. Skupimy się na precyzyjnym wykrywaniu użycia polecenia sudo oraz śledzeniu aktywności konta root:

# Monitorowanie bezpośredniego uruchomienia pliku binarnego sudo
-w /usr/bin/sudo -p x -k sudo_execution

# Monitorowanie uruchamiania procesów (execve) przez konta nieuprzywilejowane, które podniosły uprawnienia
# Wykrywa komendy uruchomione PO tym, jak ktoś skutecznie przeszedł na roota (auid to pierwotny użytkownik, uid to aktualny użytkownik)
-a always,exit -F arch=b64 -S execve -F auid>=1000 -F auid!=4294967295 -F euid=0 -k sudo_root_activity
-a always,exit -F arch=b32 -S execve -F auid>=1000 -F auid!=4294967295 -F euid=0 -k sudo_root_activity

# Monitorowanie zmian w pliku konfiguracyjnym sudoers (próby modyfikacji uprawnień)
-w /etc/sudoers -p wa -k sudoers_changes
-w /etc/sudoers.d/ -p wa -k sudoers_changes

Po umieszczeniu naszych reguł w pliku, musimy zrestartować usługę Auditd. Warto też od razu skonfigurować ją, aby była automatycznie uruchamiana ze startem systemu.

sudo systemctl restart auditd
sudo systemctl enable auditd

Aby przetestować działanie Auditd, wystarczy użyć polecenie sudo lub przełączyć się na root’a. Jeżeli wszystko jest prawidłowo skonfigurowane, powinniśmy zacząć widzieć nowe wpisy pojawiające się w pliku /var/log/audit/audit.log.

Przykładowe logi z pliku:

type=USER_ACCT msg=audit(1779706987.334:170): pid=22535 uid=1001 auid=1001 ses=4 subj=unconfined msg='op=PAM:accounting grantors=pam_permit acct="test" exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/0 res=success'UID="test" AUID="test"
type=USER_CMD msg=audit(1779706987.334:171): pid=22535 uid=1001 auid=1001 ses=4 subj=unconfined msg='cwd="/home/test" cmd="/bin/bash" exe="/usr/bin/sudo" terminal=pts/0 res=success'UID="test" AUID="test"
type=CRED_REFR msg=audit(1779706987.334:172): pid=22535 uid=1001 auid=1001 ses=4 subj=unconfined msg='op=PAM:setcred grantors=pam_permit acct="root" exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/0 res=success'UID="test" AUID="test"
type=USER_START msg=audit(1779706987.334:173): pid=22535 uid=1001 auid=1001 ses=4 subj=unconfined msg='op=PAM:session_open grantors=pam_limits,pam_permit,pam_umask,pam_unix acct="root" exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/0 res=success'UID="test" AUID="test"

Integracja z wazuh-agent

Kiedy Auditd jest gotowy, możemy przejść do konfiguracji agenta Wazuh’a, działającego na naszym hoście.

Tutaj konfiguracja jest banalnie prosta: otwieramy plik /var/ossec/etc/ossec.conf i dodajemy nową sekcję <localfile>, wskazując na nasz plik audit.log.

<localfile>
    <location>/var/log/audit/audit.log</location>
    <log_format>audit</log_format>
</localfile>

Po modyfikacji konfiguracji naszego agenta musimy zrestartować jego usługę, aby wdrożyć zmiany:

sudo systemctl restart wazuh-agent

Wyjaśnienie: sekcja <localfile> służy do wskazania usłudze wazuh-agent, które pliki systemowe ma monitorować. W praktyce działa to tak, że agent „tailuje” plik .log i wysyła wszystkie nowe dane, które się w nim pojawią, prosto do usługi wazuh-manager działającej na naszym serwerze do dalszej analizy.

Konfiguracja dekoderów i reguł na serwerze

Skoro nasz host poprawnie generuje telemetrię, czas upewnić się, że serwer Wazuh odpowiednio zinterpretuje te dane i powiadomi nas o zagrożeniach.

Ogromną zaletą platformy Wazuh (w testowanej przeze mnie wersji 4.14.5) jest to, że posiada ona natywne dekodery dla formatu auditd. Oznacza to, że nie musimy ręcznie pisać wyrażeń regularnych (regex). Silnik Wazuha automatycznie rozbije surowy log z auditd na części pierwsze, wyciągając z niego kluczowe zmienne, takie jak pierwotny użytkownik (auid), komenda (cmd) czy przypisany przez nas identyfikator reguły (key).

Naszym zadaniem jest jedynie wskazanie Wazuhowi, które z tych przetworzonych zdarzeń powinny wywołać alert w panelu SOC. W tym celu zmodyfikujemy plik z lokalnymi regułami na serwerze: /var/ossec/etc/rules/local_rules.xml.

Wklejamy do niego następujący zestaw reguł dopasowanych do kluczy, które wcześniej ustawiliśmy w konfiguracji auditd.

<group name="audit,sudo_monitor,">

  <rule id="100601" level="12">
    <if_sid>80700</if_sid>
    <field name="audit.type">USER_CMD</field>
    <field name="audit.res">success</field>
    <description>Audyt: Użytkownik (AUID: $(audit.auid)) pomyślnie wykonał komendę przez SUDO: $(audit.cwd) -> $(audit.exe)</description>
    <mitre>
      <id>T1548.003</id>
    </mitre>
  </rule>

  <rule id="100602" level="10">
    <if_sid>80700</if_sid>
    <field name="audit.type">USER_CMD</field>
    <field name="audit.res">failed</field>
    <description>Audyt: NIEUDANA próba użycia SUDO przez użytkownika (AUID: $(audit.auid))</description>
    <group>access_denied,invalid_login,</group>
    <mitre>
      <id>T1078</id>
    </mitre>
  </rule>

  <rule id="100603" level="7">
    <if_sid>80700</if_sid>
    <field name="audit.type">USER_START</field>
    <field name="audit.acct">root</field>
    <description>Audyt: Otwarto sesję uprzywilejowaną (root) dla użytkownika $(audit.auid)</description>
  </rule>

</group>

Po zapisaniu zmian musimy zrestartować menedżer Wazuha, aby system załadować nową konfigurację i zaczął aktywnie monitorować nadchodzące zdarzenia:

sudo systemctl restart wazuh-manager

Weryfikacja działania reguł

Aby upewnić się, że wszystko działa prawidłowo, przeprowadzimy prosty test. Na monitorowanym hoście generujemy zdarzenie systemowe, podnosząć uprawnienia do roota:

Już po kilku sekundach w panelu Wazuh’a powinien pojawić się nowy alerty.

Jako że nasze reguły przypisują zdarzeniom odpowiednią grupę oraz ID z matrycy MITRE ATT&CK, platforma automatycznie klasyfikuje każdy incydent. Ułatwia to analitykowi błyskawiczną ocenę powagi sytuacji oraz zrozumienie kontekstu ataku. Wizualizację wszystkich istotnych z punktu widzenia bezpieczeństwa zdarzeń, spływających z naszych agentów, możemy przeanalizować w dedykowanym panelu Threat Hunting.

Rozwiązywanie problemów (Troubleshooting)

Jeśli mimo generowania zdarzeń na hoście alerty nie pojawiają się w panelu Wazuh, problem można szybko zdiagnozować za pomocą dwóch metod:

1. Testowanie reguł (Ruleset Test)

W panelu głównym przejdź do Server Management -> Ruleset Test i wklej surowy log z auditd. To narzędzie w czasie rzeczywistym pokaże Ci, czy Wazuh prawidłowo dopasowuje dekoder oraz która reguła odpowiada za wyzwolenie alertu.

2. Włączenie logowania wszystkich zdarzeń (logall)

Domyślnie Wazuh odrzuca logi, które nie wywołują alertów. Aby sprawdzić, czy surowa telemetria w ogóle dociera do menedżera, możesz wymusić zapisywanie każdego przychodzącego zdarzenia. W pliku /etc/ossec.conf na serwerze zmień wartość parametru logall:

<ossec_config>
  <global>
    <logall>yes</logall>
  </global>
</ossec_config>

Po restarcie menedżera (sudo systemctl restart wazuh-manager), wszystkie surowe logi zaczną trafiać do pliku /var/ossec/log/archives/archives.log, możesz je podglądać na żywo za pomocą komendy:

tail -f /var/ossec/logs/archives/archives.log

⚠️ Ważne: Po zakończeniu diagnostyki koniecznie wyłącz funkcję logall (zmień z powrotem na no). W środowiskach produkcyjnych plik archives.log bardzo szybko przybiera na wadze, co może prowadzić do wyczerpania przestrzeni dyskowej i wpłynąć na stabilność działania platformy Wazuh.

Duża ilość hostów = trudność wdrożenia

Minusem rozwiązania Auditd jest oczywiście to, że musi być ono zainstalowane i skonfigurowane osobno na każdym serwerze lub endpoincie z systemem Linux. Przy małej skali, rzędu 30 hostów, nie jest to problemem, ale jeżeli liczycie Wasze serwery w setkach, sprawa robi się poważniejsza.

Najlepszym rozwiązaniem jest tutaj wdrożenie Ansible lub innego narzędzia do automatyzacji zarządzania infrastrukturą (które przy takiej skali już dawno powinniście mieć wdrożone). Przy pomocy Ansible możemy przygotować jeden prosty playbook, który po uruchomieniu na wszystkich serwerach automatycznie zainstaluje, a następnie skonfiguruje usługę Auditd zgodnie z naszymi wymaganiami.

Jeżeli chodzi o masową integrację zbierania logów z audit.log przy pomocy Wazuh-agenta, sprawa jest jeszcze prostsza. Wystarczy w Wazuh UI utworzyć grupę hostów w zakładce Agents management -> Groups i dodać do niej nasze maszyny. Kiedy grupa jest gotowa, możemy kliknąć przycisk „Edit group configuration” i dodać w niej naszą konfigurację <localfile>.

Po zapisaniu zmian Wazuh-manager skontaktuje się z agentami na końcówkach i dołączy nową konfigurację do ich głównego pliku ossec.conf, a następnie zrestartuje usługi. Dzięki temu nie musimy wykonywać tych czynności ręcznie na każdym hoście z osobna.

Przydatne linki:

• Wazuh SIEM/XDR – oficjalna strona produktu, tutaj znajdziesz specyfikację i pełną dokumentację systemu.
• Program Ambasadorów Wazuh – dołącz do społeczności open-source i pomóż nam rozwijać system Wazuh.