Rozmowa, którą słyszymy regularnie: „mamy już Zabbixa, po co nam jeszcze coś do bezpieczeństwa, skoro on i tak wszystko monitoruje”. Albo odwrotnie: „postawiliśmy Uptime Kumę, więc monitoring mamy z głowy”. Żadne z tych zdań nie jest prawdą, bo Wazuh, Zabbix i Uptime Kuma odpowiadają na trzy zupełnie różne pytania. Zanim wybierzesz, co wdrożyć w swojej firmie, warto zrozumieć, gdzie kończy się jedno narzędzie, a zaczyna drugie, bo dublowanie funkcji kosztuje tyle samo czasu co luka w pokryciu.
Trzy różne pytania, nie trzy warianty tego samego
Najprostszy sposób, żeby to poukładać w głowie: każde z tych narzędzi pilnuje innego pytania.
- Uptime Kuma pyta: czy usługa w ogóle odpowiada?
- Zabbix pyta: czy infrastruktura, która tę usługę obsługuje, ma się dobrze?
- Wazuh pyta: czy ktoś próbuje się do tej infrastruktury włamać albo już to zrobił?
To trzy różne warstwy tego samego systemu. Strona WWW może odpowiadać (Uptime Kuma zielony), a serwer pod spodem może mieć dysk zapełniony w 95% i za chwilę się wywrócić (to widzi Zabbix). Serwer może mieć świetne parametry, a jednocześnie ktoś od tygodnia loguje się na niego z Wietnamu próbując haseł brute force (to złapie Wazuh, nie Zabbix i nie Kuma). Żadne narzędzie z osobna nie daje pełnego obrazu.
Uptime Kuma: czy usługa żyje
Uptime Kuma sprawdza dostępność z zewnątrz albo z wewnątrz sieci: pinguje adres, odpytuje port, sprawdza kod HTTP strony, czasem certyfikat SSL. Jeśli usługa nie odpowiada w oczekiwanym czasie, wysyła powiadomienie i pokazuje to na publicznej stronie statusu. To narzędzie dla klienta, który chce wiedzieć „czy sklep internetowy działa”, i dla właściciela firmy, który chce dostać SMS-a, zanim zadzwoni do niego zdenerwowany kontrahent. Nie interesuje go, dlaczego usługa padła, tylko sam fakt, że padła. Konfiguracja zajmuje dosłownie kilkanaście minut, a szczegóły stawiania tego narzędzia od zera opisaliśmy we wpisie o Uptime Kuma. Dla mikrofirmy, która ma jedną stronę WWW i jeden serwer pocztowy, to bywa pierwszy i wystarczający krok, żeby przestać dowiadywać się o awarii od klienta.
Zabbix: czy infrastruktura ma się dobrze
Zabbix idzie o poziom głębiej. Zbiera metryki: obciążenie CPU, zużycie RAM, wolne miejsce na dysku, temperaturę kontrolera RAID, stan usług systemowych, ruch sieciowy, kolejki w bazie danych. Nie tylko mówi „jest źle teraz”, ale też pokazuje trend: dysk, który zapełnia się w tempie 2% tygodniowo, i za sześć tygodni będzie problem, jeśli nikt nie zareaguje. To narzędzie do planowania pojemności, wychwytywania powolnej degradacji i budowania sensownych progów alarmowych zamiast gaszenia pożarów po fakcie. Zabbix świetnie sprawdza się też tam, gdzie infrastruktura IT styka się z fizycznym budynkiem, na przykład w monitoringu z automatyką budynkową, o czym pisaliśmy przy okazji integracji z monitoringu z automatyką. Jeśli chcesz do tego dorzucić czytelne wykresy i dashboardy, warto od razu postawić Zabbix z Grafaną, bo surowe wykresy Zabbixa są funkcjonalne, ale Grafana robi z nich coś, co realnie ogląda się na co dzień.
Wazuh: czy ktoś próbuje wejść tam, gdzie nie powinien
Wazuh to zupełnie inna kategoria: bezpieczeństwo i wykrywanie zagrożeń. Zbiera logi ze wszystkich serwerów i stacji, koreluje je, szuka wzorców typowych dla ataku: nieudane logowania powtarzające się w krótkim czasie, zmiany w plikach systemowych, nowe konto administratora dodane o trzeciej w nocy, ruch do znanego adresu C2. Pilnuje integralności plików, wykrywa podatności w zainstalowanym oprogramowaniu, pomaga odtworzyć chronologię incydentu, gdy już do czegoś dojdzie. Zabbix zobaczy, że CPU serwera skoczył do 100%, ale nie powie Ci, czy to backup, czy kopanie kryptowaluty przez złośliwe oprogramowanie. Wazuh to rozróżni, bo patrzy na to, co się faktycznie dzieje w systemie, nie tylko na liczby.
Zestawienie różnic
Żeby nie zgadywać, które narzędzie sięgnie po dany problem, warto mieć to w jednym miejscu:
- Pytanie, na które odpowiada: Uptime Kuma – czy usługa odpowiada; Zabbix – czy zasoby i wydajność są w normie; Wazuh – czy ktoś narusza bezpieczeństwo.
- Źródło danych: Uptime Kuma sprawdza z zewnątrz (ping, HTTP, port); Zabbix zbiera metryki przez agenta, SNMP lub API; Wazuh analizuje logi i zdarzenia systemowe.
- Typowy alert: Uptime Kuma – „strona nie odpowiada od 3 minut”; Zabbix – „dysk zapełniony w 92%, trend rosnący”; Wazuh – „15 nieudanych logowań SSH w minutę z jednego adresu”.
- Horyzont czasowy: Uptime Kuma działa w czasie rzeczywistym i pyta „teraz”; Zabbix pokazuje trendy i historię tygodni/miesięcy; Wazuh koreluje zdarzenia i rekonstruuje chronologię incydentu.
- Kogo interesuje wynik: Uptime Kuma – właściciela i klienta (dostępność usługi); Zabbix – administratora infrastruktury (kondycja sprzętu i usług); Wazuh – osobę odpowiedzialną za bezpieczeństwo i zgodność.
Jak to się łączy pod NIS2
NIS2 wymaga wykrywania incydentów i zgłaszania ich w określonych terminach, a do tego potrzebna jest widoczność na wszystkich trzech poziomach naraz. Sama dostępność usługi (Uptime Kuma) nie wystarczy, bo strona może działać normalnie, mimo że w tle trwa eksfiltracja danych. Sama wydajność infrastruktury (Zabbix) też nie wystarczy, bo atakujący często działa tak, żeby nie obciążać zasobów i nie wzbudzać podejrzeń. Dopiero warstwa bezpieczeństwa (Wazuh) daje odpowiedź na pytanie, czy to, co się dzieje, jest incydentem w rozumieniu przepisów. Razem te trzy narzędzia dają pełny obraz: co widzi klient, co widzi administrator i co widzi zespół bezpieczeństwa, a to właśnie ten pełny obraz audytor NIS2 chce zobaczyć podczas kontroli.
Rekomendowany zestaw i kolejność wdrażania
Dla małej firmy sensowna kolejność wygląda tak:
- Krok 1: Uptime Kuma. Stawiasz w godzinę, zero kosztów licencyjnych, natychmiastowa wartość: przestajesz dowiadywać się o awarii od klienta.
- Krok 2: Zabbix (najlepiej z Grafaną). Wymaga trochę więcej czasu na konfigurację agentów i progów, ale daje wgląd w kondycję sprzętu i pozwala planować wymianę dysku czy rozbudowę RAM, zanim awaria zaskoczy Cię w piątek wieczorem.
- Krok 3: Wazuh. Najbardziej złożony do wdrożenia, wymaga strojenia reguł, żeby nie zalać się fałszywymi alarmami, ale bez niego nie masz realnej odpowiedzi na pytanie o incydenty bezpieczeństwa, a to właśnie ten element jest kluczowy dla zgodności z NIS2.
Dla firmy na kilkanaście, kilkadziesiąt stanowisk taki zestaw, uruchomiony w tej kolejności, w kilka tygodni daje kompletny obraz infrastruktury bez przepłacania za komercyjne platformy typu „wszystko w jednym”, które i tak zwykle trzeba dodatkowo dostroić pod specyfikę firmy.
Nie duplikuj tych samych funkcji w trzech miejscach
Częsty błąd: ktoś konfiguruje w Zabbixie alert na nieudane logowania SSH, bo „przecież Zabbix też umie czytać logi”, i jednocześnie ma do tego samego Wazuha. Efekt to dwa różne alerty o tym samym zdarzeniu, wysyłane do dwóch różnych osób, z dwoma różnymi progami czułości. Zasada jest prosta: dostępność zostaje w Uptime Kumie, wydajność i zasoby w Zabbixie, bezpieczeństwo i logi w Wazuh. Jeśli zauważysz, że konfigurujesz w jednym narzędziu coś, co już robi inne, to sygnał, żeby się zatrzymać i sprawdzić, czy nie duplikujesz pracy, którą i tak trzeba będzie utrzymywać przy każdej zmianie.
Co dalej w cyklu
Same narzędzia zainstalowane obok siebie to jeszcze nie system reagowania na incydenty. W kolejnym wpisie pokażemy, jak skonfigurować ten monitoring tak, żeby realnie wspierał zgłoszenie incydentu w wymaganych przez NIS2 terminach 24 i 72 godzin, czyli jak z alertu zrobić udokumentowaną procedurę, a nie tylko powiadomienie w Telegramie.
Dobranie właściwego narzędzia do właściwego zadania i spięcie ich w jeden spójny system zajmuje więcej czasu niż instalacja każdego z osobna. W Zjawa.IT stawiamy monitoring dostępności, wydajności i bezpieczeństwa pod klucz, jako jeden spójny zestaw dopasowany do wielkości Twojej firmy, a nie trzy przypadkowo poukładane narzędzia. Napisz do nas.