Masz już Proxmoksa, klika VM-ek i kontenerów LXC działa stabilnie od miesięcy. Teraz chcesz dołożyć Wazuh, żeby wreszcie widzieć, co dzieje się na serwerach i stacjach roboczych, zamiast dowiadywać się o incydencie od klienta. Pierwsze pytanie, które pada w takiej sytuacji, brzmi: VM czy kontener? Odpowiedź nie jest kwestią gustu, tylko konkretnych ograniczeń technicznych, które warto znać, zanim wgrasz cokolwiek na produkcję.
Dlaczego nie LXC dla managera Wazuh?
Wazuh to w praktyce trzy elementy: manager (przyjmuje zdarzenia od agentów i je analizuje), indexer (silnik oparty o OpenSearch, dawniej Elasticsearch, który przechowuje i indeksuje dane) oraz dashboard. Indexer jest tu wąskim gardłem decyzji. OpenSearch chce mieć kontrolę nad pamięcią: blokowanie stron w RAM (memory lock), wyłączony swap, podniesiony limit vm.max_map_count. To ustawienia jądra, a kontener LXC dzieli jądro z hostem. W kontenerze uprzywilejowanym da się to obejść, ale kosztem bezpieczeństwa izolacji, a w nieuprzywilejowanym część z tych parametrów po prostu nie zadziała tak, jak powinna. Do tego dochodzi kwestia przewidywalności zasobów: JVM/OpenSearch lubi mieć stały, gwarantowany heap, a nie zasoby dzielone dynamicznie z sąsiednimi kontenerami na tym samym hoście. Dlatego manager z indexerem stawiamy jako osobną maszynę wirtualną z własnym jądrem. LXC sprawdza się świetnie gdzie indziej, między innymi do lekkich usług pomocniczych czy serwerów aplikacyjnych, o czym pisaliśmy szerzej przy okazji kontenerach LXC. Do samych agentów Wazuh architektura hosta nie ma znaczenia: agent instalujesz jako usługę na każdej maszynie, którą chcesz monitorować, niezależnie od tego, czy to VM, kontener, czy fizyczny serwer.
VM: ile CPU, RAM i miejsca na dysk
Dla typowej małej firmy, czyli od kilku do góra kilkudziesięciu monitorowanych hostów, w zupełności wystarczy jedna maszyna z całym stosem all-in-one (manager, indexer, dashboard razem). Realne minimum, które daje spokojną pracę: 4 vCPU i 8 GB RAM, z czego przynajmniej 4-6 GB powinno trafić do OpenSearch jako heap. Przy mniej niż 4 GB RAM na całą VM będziesz walczyć z wydajnością zapytań w dashboardzie już przy kilkunastu agentach. Dysk systemowy wystarczy 40-50 GB pod system i binaria. Jeśli spodziewasz się więcej niż 30-40 agentów albo dłuższej retencji logów, rozważ 6-8 vCPU i 16 GB RAM. Ustaw też dyskretnie CPU jako typ „host” w Proxmoksie, bo OpenSearch korzysta z instrukcji procesora, których emulowany typ może nie udostępniać, a to potrafi znacząco zaniżyć wydajność bez żadnego widocznego błędu w logach.
Osobny dysk na dane indeksu
Dane indexera potrafią rosnąć szybciej, niż się wydaje, zwłaszcza gdy włączysz moduły takie jak file integrity monitoring czy analizę logów z firewalla. Trzymanie ich na tym samym wirtualnym dysku co system to prosta droga do sytuacji, w której zapchany dysk zatrzymuje jednocześnie system operacyjny i indeksowanie. Praktyczne podejście: dodaj do VM drugi wirtualny dysk, zamontuj go pod katalog danych OpenSearch (domyślnie /var/lib/wazuh-indexer) i traktuj go jako osobny wolumin, który możesz w razie potrzeby powiększyć bez ruszania systemu. Jeśli masz w Proxmoksie storage na NVMe albo SSD, tam właśnie powinien wylądować ten dysk. Indexer generuje sporo losowych odczytów i zapisów przy wyszukiwaniu i agregacji, więc wolniejszy storage mechaniczny odczujesz przy pierwszym większym zapytaniu w dashboardzie.
Sieć i VLAN dla ruchu agentów
Agenci łączą się z managerem po porcie 1514 (zdarzenia) i 1515 (rejestracja), a dashboard słucha zwykle na 443. Nie ma powodu, żeby ten ruch szedł przez tę samą sieć co reszta firmowego trafficu biurowego. Sensowne jest wydzielenie osobnego VLAN-u dla komunikacji agent-manager, z regułą na firewallu, że tylko te dwa porty przechodzą z sieci użytkowników do VLAN-u managera, a reguła w drugą stronę jest domyślnie zablokowana. Sam dashboard warto trzymać dostępny wyłącznie z sieci administracyjnej albo przez VPN, a nie wystawiać na świat. W Proxmoksie taki VLAN podpinasz pod interfejs sieciowy VM na poziomie definicji vNIC, więc nie potrzebujesz do tego dodatkowego sprzętu, o ile Twój switch obsługuje tagowanie 802.1Q.
Backup managera: snapshoty i Proxmox Backup Server
Manager Wazuh to system, w którym po pewnym czasie masz zdefiniowane reguły, integracje, listy agentów i historię alertów. Odtwarzanie tego od zera po awarii to godziny pracy. Dlatego traktuj tę VM tak samo poważnie jak kontroler domeny czy serwer plików: regularne, automatyczne kopie w Proxmox Backup Server. Do samej PBS odsyłam do wpisu o tym, jak wyglądają kopie w Proxmox Backup Server bez dodatkowych licencji. Osobno warto zrobić nawyk ze snapshotów przed każdą większą zmianą: aktualizacja wersji Wazuh, zmiana konfiguracji indexera, migracja dysku danych. Snapshot w Proxmoksie zajmuje dosłownie chwilę, a w razie gdyby aktualizacja poszła nie tak, powrót do stanu sprzed zmiany to kwestia kilku kliknięć zamiast wieczoru spędzonego na naprawianiu klastra OpenSearch.
Aktualizacje bez przestoju
Wazuh dość regularnie wydaje aktualizacje, w tym poprawki bezpieczeństwa samego managera, więc odkładanie ich w nieskończoność nie jest dobrym pomysłem. Praktyczny schemat: snapshot VM, aktualizacja indexera, potem managera, potem dashboardu, w tej kolejności, zgodnie z dokumentacją Wazuh dla danej wersji. Krótka przerwa w przyjmowaniu zdarzeń podczas restartu usług jest normalna i trwa zwykle kilkadziesiąt sekund do kilku minut, agentów to nie wybija z połączenia na trwałe, bo buforują dane lokalnie i wysyłają je po odzyskaniu łączności z managerem. Jeśli zależy Ci na oknie serwisowym poza godzinami pracy biura, zaplanuj aktualizację wieczorem albo w weekend i zostaw snapshot przez dobę, zanim go skasujesz, na wypadek gdyby jakiś problem ujawnił się dopiero po kilku godzinach normalnej pracy.
Czy potrzebujesz wysokiej dostępności?
Dla zdecydowanej większości małych i średnich firm odpowiedź brzmi: nie, przynajmniej nie na start. Jeden dobrze zabezpieczony węzeł z Wazuh, regularnym backupem i przetestowanym planem odtworzenia daje realne bezpieczeństwo bez kosztów i złożoności klastra. Krótka przerwa w monitoringu podczas awarii hosta czy planowanej aktualizacji, kiedy odtwarzasz VM z backupu w kwadrans, to zupełnie inny poziom ryzyka niż utrata jedynej kopii danych. Klaster Wazuh z redundantnymi indexerami i managerem w trybie failover ma sens, gdy monitorujesz setki agentów albo gdy przestój monitoringu sam w sobie jest dla Ciebie nie do zaakceptowania, na przykład ze względu na wymogi regulacyjne. Jeśli masz już w firmie klaster Proxmox pod inne usługi, to naturalne środowisko, żeby w przyszłości rozważyć wyższy poziom dostępności też dla Wazuh, ale nie jest to krok, który trzeba stawiać od razu.
Co dalej w cyklu
W kolejnym wpisie zejdziemy o poziom niżej, do Uptime Kumy jako strony statusu i systemu powiadomień, który pod wymogi NIS2 staje się prostym, ale konkretnym dowodem na dotrzymanie ustalonego SLA.
W Zjawa.IT stawiamy Wazuh na Proxmoksie pod klucz: od doboru zasobów VM, przez sieć i backup, po strojenie reguł tak, żeby dashboard pokazywał realne zagrożenia, a nie tysiąc alertów dziennie, które nikt nie czyta. Napisz do nas.