Wazuh jako SIEM: pierwsze wdrożenie krok po kroku

Zanim wdrożyłem Wazuh produkcyjnie, mieliśmy zerową widoczność zdarzeń bezpieczeństwa poza logami rozproszonymi po serwerach, które nikt nie przeglądał regularnie. Klasyczny stan „logi są, ale nikt ich nie czyta, dopóki coś się nie wydarzy”. Wazuh wybraliśmy głównie dlatego, że jest open-source (bez kosztu licencji per endpoint, co przy setkach hostów robi ogromną różnicę), ma dojrzały agent i integruje się natywnie z OpenSearch jako backendem do przechowywania i przeszukiwania danych.

Architektura, zanim ruszyłem z instalacją

Wazuh składa się z trzech komponentów, które łatwo pomylić na starcie: Wazuh manager (mózg — reguły, dekodery, korelacja), Wazuh indexer (fork OpenSearch, przechowuje przetworzone zdarzenia) i Wazuh dashboard (interfejs). Na małą instalację wszystko może stać na jednej maszynie, ale już przy kilkuset agentach warto rozdzielić indexer na osobny węzeł — indeksowanie zdarzeń jest zdecydowanie bardziej zasobożerne niż sama korelacja reguł.

agenci (Linux/Windows) ──► Wazuh manager (reguły, dekodery, aktywna odpowiedź)
                                    │
                                    ▼
                          Wazuh indexer (OpenSearch)
                                    │
                                    ▼
                          Wazuh dashboard (Kibana-podobny UI)

Instalacja managera i pierwsi agenci

Skrypt instalacyjny od Wazuh (all-in-one dla środowiska testowego, potem osobne kroki dla produkcji) załatwia większość roboty, ale certyfikaty TLS między komponentami trzeba wygenerować i zweryfikować ręcznie — to jedno z miejsc, gdzie skrót „zrobię to później” kończy się nieszyfrowaną komunikacją, o której zapominasz do audytu.

# rejestracja nowego agenta na managerze
/var/ossec/bin/manage_agents -a -n app-prod-01 -i any

# na hoście klienckim — instalacja i wskazanie managera
WAZUH_MANAGER='wazuh.internal.example.com' apt-get install wazuh-agent -y
systemctl enable --now wazuh-agent

Pierwsze „aha” przyszło szybko: sam fakt zainstalowania agenta na kilkudziesięciu serwerach od razu wygenerował lawinę alertów domyślnych reguł — nieudane logowania SSH, zmiany w /etc/passwd, restarty usług. Domyślny zestaw reguł Wazuh jest bogaty, ale nastawiony szeroko — bez dostrojenia zalewa dashboard szumem, w którym ginie sygnał.

Dostrajanie reguł — najważniejszy etap

Pierwszy tydzień to była głównie walka z fałszywymi alarmami, nie z prawdziwymi zagrożeniami. Cron zadania restartujące usługi generowały alerty na poziomie ostrzeżenia, mimo że były planowane i nieszkodliwe. Rozwiązaniem nie jest wyłączanie reguł hurtowo, tylko pisanie lokalnych wyjątków w local_rules.xml, które precyzyjnie wykluczają znany, akceptowalny wzorzec, zamiast wyciszać całą kategorię zdarzeń:

<group name="local,syslog,">
  <rule id="100010" level="0">
    <if_sid>5501</if_sid>
    <user>ansible</user>
    <description>Restart usługi przez znane konto serwisowe Ansible — zignorowane</description>
  </rule>
</group>

Warunek na konkretnego użytkownika (ansible) jest tu kluczowy — wyjątek działa tylko dla znanego, zaufanego źródła zmiany, a nie dla dowolnego restartu usługi. To jest dokładnie ten poziom precyzji, którego certyfikacja Wazuh Expert (Securitum, lipiec 2025) uczy w praktyce — nie „jak wyłączyć hałas”, tylko jak modelować reguły tak, żeby sygnał zostawał widoczny.

File Integrity Monitoring (FIM)

FIM okazał się jedną z tych funkcji, których wartość doceniasz dopiero po pierwszym realnym incydencie testowym. Konfiguracja monitoruje wskazane katalogi i pliki pod kątem zmian — utworzenia, modyfikacji, usunięcia, zmiany uprawnień:

<syscheck>
  <directories check_all="yes" realtime="yes">/etc</directories>
  <directories check_all="yes">/usr/bin,/usr/sbin</directories>
  <ignore>/etc/mtab</ignore>
  <ignore>/etc/random-seed</ignore>
</syscheck>

realtime="yes" na /etc daje niemal natychmiastowy alert o zmianie pliku konfiguracyjnego, co jest bezcenne przy podejrzeniu nieautoryzowanej zmiany. Ale realtime FIM na całym systemie plików to zły pomysł — obciążenie i szum rosną drastycznie. Świadomy wybór katalogów pod monitoring w trybie realtime, i pozostałe (rzadziej zmieniane, ale wciąż istotne) sprawdzane okresowo, to kompromis, który się sprawdza.

Pierwszy prawdziwy „aha” moment FIM złapał zmianę w /etc/cron.d/ na jednym z serwerów, której nikt z zespołu świadomie nie wprowadził. Okazało się, że to był efekt uboczny nieudanej aktualizacji pakietu, nie atak — ale czas między powstaniem alertu a identyfikacją przyczyny wynosił kilkanaście minut, zamiast dni, które zajęłoby wykrycie tego przypadkiem. To był moment, w którym reszta zespołu przestała traktować SIEM jako „projekt IT”, a zaczęła jako narzędzie, z którego faktycznie korzysta.

Integracja z istniejącą infrastrukturą

Agentów Wazuh wdrożyłem stopniowo, grupami przez Ansible (o samym Ansible piszę osobno w tekście o automatyzacji wdrożeń) — najpierw serwery testowe, potem produkcyjne, na końcu stacje robocze administratorów. Grupy agentów w Wazuh (osobna konfiguracja agent.conf per grupa) pozwoliły mieć inny zestaw reguł FIM dla serwerów bazodanowych niż dla web-frontów, bez utrzymywania osobnych profili konfiguracyjnych ręcznie na każdym hoście.

Klaster i load balancing managerów, których nauczyłem się przy certyfikacji Wazuh Expert, wdrożyłem dopiero po kilku miesiącach działania na pojedynczym managerze — kiedy liczba agentów i wolumen zdarzeń zaczęły uzasadniać rozłożenie obciążenia. Load balancer przed klastrem managerów Wazuh to standardowe zadanie dla HAProxy, o którym piszę w osobnym porównaniu HAProxy i Nginx — health check na porcie agentów (1514) pilnuje, żeby żaden nowy agent nie próbował rejestrować się na martwym węźle.

Aktywna odpowiedź — z rozwagą

Wazuh potrafi automatycznie reagować na zdarzenia (Active Response) — na przykład blokować adres IP po kilku nieudanych próbach logowania. To potężna funkcja i jednocześnie ta, którą włączałem najostrożniej. Pierwsza konfiguracja aktywnej odpowiedzi na produkcyjnym środowisku bez dokładnego dostrojenia progu mogła zablokować adres skanera bezpieczeństwa uruchamianego przez nas samych podczas audytu — false positive z realnymi konsekwencjami operacyjnymi. Aktywną odpowiedź włączałem etapami: najpierw tylko logowanie decyzji bez wykonania (dry-run), potem wdrożenie z białą listą adresów wewnętrznych, na końcu pełne działanie.

SIEM, który generuje alerty czytane przez nikogo, nie jest SIEM-em — jest tylko kosztem infrastruktury. Pierwsze tygodnie po wdrożeniu Wazuh poszły nie na instalację, tylko na to, żeby dashboard pokazywał rzeczy, które faktycznie warto przeczytać.

Certyfikat Wazuh Expert uporządkował mi wiedzę, którą wcześniej miałem fragmentarycznie z praktyki — szczególnie w obszarach, do których na co dzień nie miałem powodu sięgać: RBAC z granularnymi rolami, Security Configuration Assessment (SCA) do audytu zgodności z benchmarkami CIS, i integracja z Cyber Threat Intelligence do wzbogacania alertów o kontekst z zewnętrznych źródeł. Teoria z certyfikacji i praktyka z produkcyjnego wdrożenia uzupełniły się nawzajem — bez wcześniejszego wdrożenia certyfikat byłby czystą teorią, bez certyfikatu wdrożenie zatrzymałoby się na podstawowej konfiguracji.