Instalacja Wazuh krok po kroku: manager i agenci od zera

Klient dzwoni, że padł mu serwer plików i pyta, czy da się sprawdzić, kto się na niego logował w ostatnim tygodniu. Otwierasz logi ręcznie, przeszukujesz auth.log, próbujesz skleić obraz z kilku maszyn naraz i po godzinie masz tylko część odpowiedzi. Wazuh rozwiązuje dokładnie ten problem: zbiera logi i zdarzenia bezpieczeństwa ze wszystkich serwerów i stacji w jednym miejscu, za darmo, bez licencji na hosta czy agenta. W tym wpisie stawiamy całość od zera: managera z indexerem i dashboardem oraz dwóch pierwszych agentów, jednego na Linuksie, jednego na Windows.

Jak zbudowany jest Wazuh

Wazuh to trzy komponenty, które w małej firmie najczęściej stawia się razem, na jednej maszynie, w tak zwanym wariancie all-in-one:

• Wazuh indexer – baza oparta na silniku podobnym do OpenSearch, przechowuje wszystkie zdarzenia i loguje je do wyszukiwania.
• Wazuh manager – mózg systemu: odbiera dane od agentów, stosuje reguły detekcji, dekoduje logi i decyduje, co jest alertem, a co szumem.
• Wazuh dashboard – warstwa wizualna oparta na Kibanie/OpenSearch Dashboards, w której przeglądasz alerty, buduje raporty i zarządza agentami.

Do tego dochodzą agenci: lekki proces instalowany na każdym serwerze i stacji roboczej, który wysyła logi systemowe, wyniki skanów konfiguracji, informacje o zainstalowanym oprogramowaniu i (w kolejnym wpisie tego cyklu) zmiany w plikach do managera. W firmie na kilkanaście, kilkadziesiąt maszyn wariant all-in-one w zupełności wystarcza. Dopiero przy setkach agentów albo wymogu wysokiej dostępności warto rozdzielać indexer, manager i dashboard na osobne węzły, ale to temat na osobny, bardziej architektoniczny wpis.

Ile sprzętu potrzebuje mała firma

Oficjalne minimum Wazuh podaje dość skromne liczby, ale w praktyce, przy 10-30 agentach i realnym ruchu logów, lepiej zaplanować z zapasem:

• 4 vCPU – indexer i manager razem potrafią zjeść dwa rdzenie przy samym indeksowaniu, zostaw zapas na dashboard.
• 8-16 GB RAM – 8 GB to dolna granica dla kilkunastu agentów, przy 30+ agentach i dłuższej retencji celuj w 16 GB.
• Dysk SSD, osobny wolumen na dane – indexer zapisuje intensywnie, warto trzymać /var/lib/wazuh-indexer na osobnym dysku lub partycji, żeby logi nie zapchały systemowego roota.
• 50-100 GB miejsca na start – zależnie od liczby agentów i tego, jak długo chcesz trzymać historię zdarzeń (domyślna retencja indeksów to 90 dni).

Najwygodniej postawić na Proxmoksie osobną maszynę wirtualną z takimi zasobami, ma to tę zaletę, że w każdej chwili dorzucisz RAM albo powiększysz dysk bez reinstalacji systemu. Alternatywą, jeśli zależy Ci na oszczędności zasobów, jest kontener LXC, choć wtedy trzeba doczytać wymagania Wazuh względem jądra i sysctl, bo część ustawień indexera (np. vm.max_map_count) konfiguruje się na poziomie hosta, nie kontenera. Dla pierwszego wdrożenia polecam zwykłą VM z Ubuntu Server 22.04 lub 24.04, mniej niespodzianek.

Instalacja all-in-one krok po kroku

Zakładam świeżą maszynę z Ubuntu 22.04/24.04, minimum 4 vCPU i 8 GB RAM, dostęp do internetu i uprawnienia root. Cała instalacja sprowadza się do jednego skryptu:

• Zaloguj się na maszynę przez SSH i zaktualizuj system: apt update && apt upgrade -y.
• Pobierz i uruchom oficjalny skrypt instalacyjny: curl -sO https://packages.wazuh.com/4.9/wazuh-install.sh && sudo bash wazuh-install.sh -a. Flaga -a oznacza właśnie instalację all-in-one: indexer, manager i dashboard na jednej maszynie.
• Instalacja trwa od kilku do kilkunastu minut, zależnie od łącza i mocy CPU. Skrypt sam generuje certyfikaty i konfiguruje komunikację między komponentami.
• Na koniec skrypt wypisze hasło do konta admin dashboardu. Zapisz je od razu, bo domyślnie nie pojawi się drugi raz w logach.
• Sprawdź, że wszystkie usługi wstały: systemctl status wazuh-manager wazuh-indexer wazuh-dashboard.

Jeśli coś nie wystartuje, w dziewięciu na dziesięć przypadków przyczyną jest za mało RAM (indexer po prostu nie ma jak się podnieść) albo brak ustawienia vm.max_map_count na wartość co najmniej 262144, którą skrypt zazwyczaj ustawia sam, ale warto zweryfikować przez sysctl vm.max_map_count.

Pierwsze logowanie do dashboardu

Wchodzisz przeglądarką pod adres https://adres_serwera (port 443, certyfikat będzie samopodpisany, przeglądarka pokaże ostrzeżenie, akceptujesz je przy pierwszym wejściu). Logujesz się loginem admin i hasłem wygenerowanym przy instalacji. Pierwszy ekran to widok „Wazuh” z modułami po lewej stronie: Security events, Integrity monitoring, Vulnerability detection i tak dalej. Na start interesuje Cię głównie zakładka Agents, w której zobaczysz jednego agenta, samego managera monitorującego sam siebie. To dobry moment, żeby zmienić hasło admina na własne w ustawieniach konta, zanim dodasz kolejnych użytkowników.

Dodawanie agenta na Linux

W dashboardzie wejdź w Agents → Deploy new agent, wybierz dystrybucję (Debian/Ubuntu, RHEL/CentOS itd.), architekturę i wpisz adres IP swojego managera. System sam wygeneruje gotową komendę do wklejenia na docelowej maszynie, coś w rodzaju:

• wget https://packages.wazuh.com/4.x/apt/pool/main/w/wazuh-agent/wazuh-agent_4.9.x_amd64.deb
• instalacja pakietu z parametrem WAZUH_MANAGER wskazującym adres managera
• uruchomienie usługi: systemctl enable wazuh-agent && systemctl start wazuh-agent

Po chwili nowy agent pojawi się na liście w dashboardzie ze statusem „Active”. Jeśli status utknie na „Never connected”, sprawdź firewall, o czym niżej.

Dodawanie agenta na Windows

Procedura jest analogiczna: w kreatorze wybierasz „Windows”, dostajesz link do instalatora MSI i gotową komendę PowerShell z parametrami adresu managera i (opcjonalnie) nazwy agenta. Instalator uruchamiasz z uprawnieniami administratora, po instalacji usługa WazuhSvc startuje automatycznie. Na stacjach roboczych warto od razu ustawić nazwę agenta zgodną z nazwą komputera w Active Directory, ułatwia to później filtrowanie alertów po dziale czy lokalizacji.

Sprawdzenie, że zdarzenia faktycznie spływają

Wróć do dashboardu, moduł Security events, i odśwież widok po kilku minutach od uruchomienia agenta. Powinieneś zobaczyć pierwsze zdarzenia: logowania, zmiany w usługach, wyniki wstępnego skanu konfiguracji (SCA). Jeśli lista jest pusta mimo statusu „Active” agenta, sprawdź w zakładce agenta zakładkę „Ossec log” po stronie managera (plik /var/ossec/logs/ossec.log) – zwykle widać tam od razu, czy problem jest po stronie sieci, czy konfiguracji reguł.

Typowe potknięcia

• 🚩 Za mało RAM na start: indexer potrafi się wysypywać przy 4 GB, a logi błędów nie zawsze wprost mówią „brak pamięci”. Jeśli usługa wazuh-indexer nie startuje, sprawdź RAM w pierwszej kolejności.
• 🚩 Brak osobnego wolumenu na dane: przy kilkudziesięciu agentach system root potrafi zapełnić się logami indeksowania w kilka tygodni. Zaplanuj osobną partycję pod dane od razu przy instalacji.
• 🚩 Firewall blokujący port agenta: manager nasłuchuje na porcie 1514/TCP (dane agentów) i 1515/TCP (rejestracja nowych agentów). Jeśli w sieci masz segmentację VLAN albo firewall sprzętowy między stacjami a serwerem Wazuh, te dwa porty muszą być otwarte w obie strony.
• ✅ Certyfikat samopodpisany to nie błąd: ostrzeżenie przeglądarki przy pierwszym wejściu do dashboardu jest normalne, docelowo możesz podpiąć własny certyfikat, ale nie jest to wymagane do działania.
• ✅ Domyślna retencja 90 dni: jeśli potrzebujesz trzymać dane dłużej (np. do audytu), zaplanuj to od razu w polityce indeksów, żeby nie stracić historii po trzech miesiącach.

Co dalej w cyklu

Manager stoi, agenci raportują, konsola pokazuje pierwsze zdarzenia, to dobry fundament. W kolejnym wpisie zajmiemy się monitoringiem integralności plików (FIM) w Wazuh, czyli mechanizmem, który wykryje nieautoryzowaną zmianę w plikach systemowych czy konfiguracyjnych zanim zrobi to atakujący.

Wdrożenie SIEM-u wygląda prosto na papierze, ale diabeł tkwi w szczegółach: dobraniu reguł, ograniczeniu fałszywych alarmów i integracji z resztą infrastruktury. W Zjawa.IT stawiamy monitoring bezpieczeństwa pod klucz, od pierwszej maszyny wirtualnej po działającą konsolę z sensownymi alertami. Napisz do nas.