Wdrożenie Wazuh w małej firmie: architektura, tuning i typowe błędy

Wdrożenie Wazuh w małej firmie to najczęściej jeden serwer all-in-one (indexer, server i dashboard) obsługujący kilkadziesiąt agentów, instalowany oficjalnym skryptem. Sama instalacja jest prosta. Właściwa praca to rozsądny rollout agentów, strojenie reguł, żeby alerty nie zamieniły się w szum, i zabezpieczenie samego Wazuha.

Co robi Wazuh i czego nie zrobi za ciebie

Wazuh to otwarta platforma SIEM/XDR. Agent na serwerze lub laptopie zbiera zdarzenia, serwer (manager) dekoduje je i porównuje z regułami, wynik trafia do indexera, a ty oglądasz go w dashboardzie. W jednym narzędziu dostajesz kilka funkcji:

• Analiza logów: syslog, dzienniki Windows, logi serwerów WWW i aplikacji. Reguły wychwytują m.in. próby logowania na nieistniejące konta, eskalację uprawnień czy serie nieudanych uwierzytelnień.
• File Integrity Monitoring (FIM): moduł syscheck śledzi zmiany plików, uprawnień i sum kontrolnych. Na serwerze WWW to jeden z najszybszych sposobów, żeby zauważyć podrzucony plik, o czym więcej w tekście o backdoorach i web shellach PHP.
• Wykrywanie podatności: inwentarz pakietów z agentów jest porównywany z bazą CVE.
• Security Configuration Assessment (SCA): ocena konfiguracji systemów według polityk opartych m.in. na benchmarkach CIS.
• Active response: automatyczna reakcja na alert, np. czasowe zablokowanie adresu IP na firewallu hosta.

Wazuh nie zastąpi człowieka, który czyta alerty. Dostajesz silnik detekcji i magazyn danych, ale decyzję, co jest incydentem, podejmuje ktoś z zespołu albo zewnętrzny partner. Jeśli nikt nie ma na to czasu, ustal to przed instalacją.

Architektura Wazuh: all-in-one czy instalacja rozproszona

Wazuh składa się z agentów i trzech komponentów centralnych:

• Wazuh indexer: silnik wyszukiwania oparty na OpenSearch, przechowuje alerty i zdarzenia (API na porcie 9200).
• Wazuh server: odbiera dane od agentów (1514/TCP), rejestruje nowe agenty (1515/TCP), analizuje zdarzenia i wystawia API na porcie 55000.
• Wazuh dashboard: interfejs webowy, domyślnie na porcie 443.

Instalacja all-in-one stawia te trzy komponenty na jednej maszynie. Dla firmy z kilkudziesięcioma hostami to rozsądny wybór: jedna maszyna do kopii zapasowych, aktualizacji i nadzoru. Wadą jest brak odporności na awarię, bo gdy serwer stoi, tracisz jednocześnie zbieranie danych i wgląd w historię.

Kiedy rozdzielić komponenty i klastrować indexer

Rozdziel komponenty, gdy indexer zaczyna zabierać managerowi pamięć i dysk albo gdy liczba agentów wychodzi poza zakres, dla którego dokumentacja podaje parametry pojedynczej maszyny. Klaster indexera ma sens wtedy, gdy kilka godzin bez dostępu do danych bezpieczeństwa jest dla ciebie nie do przyjęcia.

Jeśli klastrujesz, planuj trzy węzły indexera, nie dwa. Indexer dziedziczy po OpenSearch mechanizm kworum: decyzje o stanie klastra wymagają większości węzłów uprawnionych do głosowania, więc para węzłów nie przetrwa awarii jednego z nich. Szczegóły wyjaśnia tekst o monitoringu logów w ELK, OpenSearch i Grafanie. Klaster managerów to osobna decyzja, zwykle potrzebna dopiero przy większej skali.

Wymagania sprzętowe Wazuh: ile zasobów zaplanować

Dokumentacja Wazuh 4.14 podaje dla instalacji all-in-one z 90 dniami indeksowanych danych takie parametry:

Dla samego indexera dokumentacja podaje minimum 4 GB RAM i 2 rdzenie, a rekomendowane 16 GB RAM i 8 rdzeni. Zajętość dysku szacuje według liczby alertów na sekundę: około 3,7 GB na 90 dni dla serwera, 1,5 GB dla stacji roboczej i 7,4 GB dla urządzenia sieciowego. Przykład z dokumentacji: 80 stacji, 10 serwerów i 10 urządzeń sieciowych to około 231 GB.

Traktuj te liczby jako punkt startowy. Zajętość rośnie, gdy włączysz archiwizację wszystkich zdarzeń, a nie tylko alertów, albo podepniesz głośne źródła, takie jak firewall czy Suricata z logowaniem przepływów. Po dwóch tygodniach sprawdź faktyczny przyrost indeksów i dopiero wtedy ustal retencję.

Jak wdrożyć agentów Wazuh bez chaosu

1. Zacznij od pilota. Wybierz kilka hostów różnego typu: serwer WWW, serwer plików, dwa laptopy. Przez tydzień obserwuj, co generują.
2. Włącz hasło rejestracji. Bez niego każdy, kto dotrze do portu 1515, może zarejestrować agenta.
3. Grupuj agenty. Grupy, np. linux-web czy windows-stacje, pozwalają rozsyłać wspólną konfigurację przez agent.conf zamiast edytować każdy host osobno.
4. Przypnij wersję. Dokumentacja gwarantuje zgodność tylko wtedy, gdy manager jest w tej samej lub nowszej wersji niż agent. Zablokuj pakiet albo wyłącz repozytorium Wazuh po instalacji.
5. Rozszerzaj falami. Najpierw serwery, potem stacje robocze. Każda fala to nowe źródła szumu do wystrojenia.

Na managerze włącz uwierzytelnianie hasłem, dodając w /var/ossec/etc/ossec.conf blok <auth><use_password>yes</use_password></auth>. Dalej wygląda to tak (Wazuh 4.14, Debian/Ubuntu z dodanym repozytorium Wazuh, polecenia jako root):

# na managerze
echo "TwojeHasloRejestracji" > /var/ossec/etc/authd.pass
chmod 640 /var/ossec/etc/authd.pass
chown root:wazuh /var/ossec/etc/authd.pass
systemctl restart wazuh-manager

# na monitorowanym hoście
WAZUH_MANAGER="10.0.0.2" WAZUH_REGISTRATION_PASSWORD="TwojeHasloRejestracji" \
  WAZUH_AGENT_GROUP="linux-web" apt-get install wazuh-agent
systemctl daemon-reload
systemctl enable --now wazuh-agent
apt-mark hold wazuh-agent

Hasło podane w linii poleceń zostaje w historii powłoki. Przy wdrożeniu przez Ansible trzymaj je w zaszyfrowanym vaulcie, a na Windows przekaż te same zmienne do instalatora MSI w narzędziu do dystrybucji oprogramowania.

Strojenie reguł Wazuh: jak ograniczyć szum alertów

Po pierwszym tygodniu zobaczysz, że większość alertów pochodzi z kilku reguł. Typowe źródła: skanery podatności i monitoringu, zadania cron, konta serwisowe logujące się co minutę, kopie zapasowe zmieniające tysiące plików. Nie wyłączaj całych reguł. Wycisz konkretny, znany przypadek.

Własne reguły trzymaj w /var/ossec/etc/rules/local_rules.xml, bo ten plik przetrwa aktualizację, i nadawaj im identyfikatory od 100000 do 120000. Reguła potomna z poziomem 0 wycisza alert tylko dla wskazanego źródła:

<group name="local,sshd,">
  <rule id="100100" level="0">
    <if_sid>5710</if_sid>
    <srcip>10.0.5.20</srcip>
    <description>Skaner 10.0.5.20: ignoruj logowania na nieistniejące konta</description>
  </rule>
</group>

Żeby zmienić poziom istniejącej reguły, skopiuj ją do local_rules.xml z tym samym ID i atrybutem overwrite="yes". Dokumentacja zaznacza, że tą metodą nie nadpiszesz pól if_sid, if_group i pokrewnych. Każdą zmianę sprawdź narzędziem /var/ossec/bin/wazuh-logtest na przykładowej linii logu, a potem zrestartuj managera.

Druga dźwignia to FIM. Nie monitoruj w czasie rzeczywistym katalogów, które z natury ciągle się zmieniają: cache, sesji, logów. Pilnuj kodu aplikacji, konfiguracji i binariów, a zmienne podkatalogi wyklucz opcją ignore.

Ustal też próg powiadomień. Reguły Wazuh mają poziomy od 0 do 15, więc powiadomienia na e-mail czy Slacka ustaw od wysokiego poziomu, a resztę przeglądaj w dashboardzie. Wyciszenia trzymaj w repozytorium Git z krótkim uzasadnieniem, bo za pół roku nikt nie będzie pamiętał, po co powstała reguła 100100.

Hardening Wazuh: zabezpiecz narzędzie, które widzi wszystko

Wazuh ma dostęp do logów całej firmy, a jego API potrafi uruchamiać akcje na agentach. Przejęty serwer SIEM to dla atakującego mapa sieci i sposób na zatarcie śladów. Zadbaj o minimum:

• Hasła. Asystent instalacji generuje losowe hasła i zapisuje je w pliku wazuh-passwords.txt w archiwum instalacyjnym. Przenieś je do menedżera haseł i usuń archiwum z serwera. Wdrożenie w Dockerze startuje z domyślnym hasłem opisanym w dokumentacji, więc zmień je przed pierwszym uruchomieniem w sieci. Służy do tego wazuh-passwords-tool.sh.
• Certyfikaty TLS. Komponenty komunikują się po TLS z certyfikatami z własnego CA, generowanymi przez wazuh-certs-tool.sh. Klucz prywatny CA nie powinien zostawać na serwerze produkcyjnym.
• Dostęp sieciowy. Dashboard i API (55000) udostępnij tylko z sieci administracyjnej lub przez VPN. Port 9200 indexera nie powinien być osiągalny spoza serwerów Wazuh. Porty 1514 i 1515 otwieraj tylko dla sieci, w których są agenty.
• Konta i role. Każda osoba ma własne konto, bez współdzielonego admin. Analityk przeglądający alerty nie potrzebuje uprawnień do zmiany konfiguracji.
• Aktualizacje i kopie. Śledź wydania 4.14.x, rób snapshoty indeksów i kopię katalogu /var/ossec/etc z regułami i konfiguracją.
• Nadzór nad nadzorem. Alert o rozłączonym agencie traktuj poważnie. Wyłączenie agenta to jeden z pierwszych kroków, jakie wykonuje intruz.

Integracje Wazuh: Suricata, e-mail i Slack

Wazuh widzi hosty, a nie ruch sieciowy. Uzupełnieniem jest Suricata: agent na maszynie z sensorem czyta jej log eve.json, a wbudowany dekoder JSON rozkłada pola bez pisania własnego dekodera. Jak postawić sam sensor, opisuje poradnik Suricata IDS/IPS. Na agencie dodaj:

<ossec_config>
  <localfile>
    <log_format>json</log_format>
    <location>/var/log/suricata/eve.json</location>
  </localfile>
</ossec_config>

Powiadomienia na Slacka konfigurujesz blokiem integration w ossec.conf managera. Ustaw próg poziomu, inaczej kanał szybko utonie w wiadomościach:

<integration>
  <name>slack</name>
  <hook_url>https://hooks.slack.com/services/XXX/YYY/ZZZ</hook_url>
  <level>10</level>
  <alert_format>json</alert_format>
</integration>

Z e-mailem jest haczyk: Wazuh nie obsługuje serwerów SMTP wymagających uwierzytelnienia, takich jak Gmail. Dokumentacja zaleca lokalny relay, np. Postfix, który loguje się do właściwego serwera pocztowego. Adresy ustawiasz w sekcji global, a minimalny poziom alertu w email_alert_level sekcji alerts.

Wbudowane integracje obejmują też PagerDuty, VirusTotal, Shuffle i Maltiverse, a własne skrypty podpinasz pod nazwą zaczynającą się od custom-.

Najczęstsze błędy przy wdrożeniu Wazuh

• Instalacja na próbę na maszynie z 4 GB RAM, która potem po cichu zostaje produkcją.
• Brak planu retencji. Gdy dysk indexera się zapełnia, indeksy przechodzą w tryb tylko do odczytu i nowe alerty przestają się zapisywać.
• Active response włączone dla wszystkich agentów bez listy wyjątków. Pierwszy fałszywy alarm blokuje serwer monitoringu albo bramę. Dokumentacja wprost każe skonfigurować white_list i testować reguły przed automatyzacją reakcji.
• Wyłączanie całych reguł zamiast wyciszania konkretnych źródeł.
• Dashboard i API wystawione do internetu ze współdzielonym kontem administratora.
• Agent nowszy niż manager po automatycznej aktualizacji systemu.
• Brak osoby odpowiedzialnej za przegląd alertów. Bez tego Wazuh jest drogim archiwum logów. Jeśli IT w firmie działa bardziej na gaszeniu pożarów niż według planu, zacznij od tekstu o opanowaniu chaosu w IT.
• Brak weryfikacji detekcji. Test penetracyjny albo choćby kontrolowana symulacja pokaże, czy przy realnym ataku alerty w ogóle się pojawiają.

Firmom bez własnego zespołu bezpieczeństwa zwykle najlepiej służy model, w którym wdrożenie i strojenie robi ktoś z doświadczeniem, a przegląd alertów odbywa się regularnie po stronie firmy lub partnera. Takie wdrożenia prowadzimy w ramach usług bezpieczeństwa.