Zabbix, Graylog czy Wazuh — co do czego

Najprostszy sposób, żeby je rozróżnić, to pytanie, na co odpowiadają. Zabbix mówi, jak się mają systemy. Graylog mówi, co się w nich wydarzyło. Wazuh mówi, czy coś w tym wygląda podejrzanie.

Każde z tych pytań wymaga innych danych i innego sposobu pracy z nimi. Metryki zbiera się w regularnych odstępach, logi napływają strumieniem, a zdarzenia bezpieczeństwa ocenia się pod kątem wzorców. Jeden system nie obsłuży dobrze wszystkich trzech, choć producenci narzędzi chętnie sugerują inaczej.

Zabbix zbiera dane liczbowe i sprawdza dostępność. Ile jest miejsca na dyskach, jak rośnie obciążenie procesora, czy usługa odpowiada, ile trwa odpowiedź bazy. Z tego powstają wykresy i progi, które informują, gdy coś zbliża się do granicy.

To najczęściej pierwsze narzędzie w firmie, bo odpowiada na najprostsze pytanie: czy wszystko działa i czy wystarczy nam zasobów. Wdrożenie zaczyna się zwykle od podłączenia serwerów i usług krytycznych, a z czasem dochodzą macierze, przełączniki i drukarki sieciowe.

Zabbix ma też słabość, o której warto wiedzieć: nie nadaje się do czytania logów. Potrafi wykryć, że usługa nie odpowiada, ale nie powie, dlaczego przestała.

Graylog zbiera logi z wielu źródeł w jedno miejsce i pozwala w nich szukać. Zamiast logować się kolejno na pięć serwerów i przeglądać pliki, wpisujesz zapytanie i widzisz zdarzenia ze wszystkich systemów obok siebie, w kolejności czasu.

Praktyczna wartość wychodzi w dwóch sytuacjach. Pierwsza to szukanie przyczyny: aplikacja zgłasza błąd, a w logach obok widać, że pół minuty wcześniej baza odrzuciła połączenia. Druga to wykrywanie zdarzeń, które nie generują alertu: nieudane logowania, nietypowe połączenia, powtarzające się błędy, których nikt nie zauważył, bo nie zatrzymały usługi.

Graylog wymaga jednego świadomego ustalenia na starcie: co wysyłamy. Jeżeli zbierzemy wszystko, magazyn zapełni się w tygodnie i przestanie być użyteczny.

Wazuh patrzy na te same dane, ale z innego powodu. Interesuje go bezpieczeństwo: nieudane próby logowania, zmiany w krytycznych plikach, nietypowe procesy, ślady prób nieautoryzowanego dostępu. Działa jak system korelujący zdarzenia z wielu źródeł i dopasowujący je do znanych wzorców.

Druga funkcja, którą warto znać, to kontrola integralności plików. Wazuh potrafi zauważyć, że w katalogu systemowym zmienił się plik, którego nikt nie powinien ruszać. W połączeniu z oprogramowaniem szantażującym, które szyfruje dane partiami, taka informacja pojawia się wcześniej niż wezwanie od użytkownika.

Najwięcej daje tam, gdzie logi zbierane są z systemów, które naprawdę warto obserwować — im lepiej dobrany zakres, tym trafniejsze sygnały i mniej szumu. Warto wiedzieć, co Wazuh pokazuje, i mieć kogoś, kto reaguje na to, co zgłosi.

W firmie z kilkoma serwerami i jednym systemem, który realnie boli, wystarcza Zabbix. Podłączamy hosty, ustawiamy progi i to zwykle daje największy zwrot za najmniejszą pracę.

Gdy dochodzi kilka aplikacji i pojawia się pytanie „dlaczego to padło”, sens ma Graylog. Rosnąca liczba logów bez centralnego miejsca oznacza, że diagnoza każdego problemu zajmuje godziny zamiast minut.

Wazuh wchodzi tam, gdzie firma ma dane, których wyciek albo zaszyfrowanie kosztowałoby więcej niż wdrożenie — albo gdzie wymagania zewnętrzne każą pokazać, że zdarzenia bezpieczeństwa są rejestrowane. W małej firmie bez takich wymagań bywa krokiem trzecim, nie pierwszym.

Tak i najczęściej właśnie tak się to robi. Wszystkie trzy narzędzia działają na wolnych licencjach i można je uruchomić na tej samej infrastrukturze. Kluczowe jest rozdzielenie zadań, żeby nie zbierać tych samych danych dwa razy.

Typowy układ: Zabbix pilnuje metryk i dostępności, Graylog zbiera logi aplikacji i systemów, Wazuh zajmuje się logami bezpieczeństwa i integralnością plików. Część logów trafia tylko do jednego z nich — nie ma sensu przesyłać ich wszędzie, bo to podwaja pracę i koszt magazynu.

Czasem granica bywa płynna. Jeżeli Zabbix wystarcza do wykrywania nietypowych zdarzeń, Wazuh może nie być potrzebny w pierwszym etapie. Decyduje to, jaki efekt chcesz osiągnąć, a nie ile narzędzi uda się uruchomić.

Nie zastąpią kopii zapasowych. Monitoring pokazuje, że coś przestało działać, ale nie odtworzy danych. Nie zastąpią też procedur: jeśli po alercie nikt nie wie, co zrobić, narzędzie tylko dokumentuje problem szybciej.

Nie są również całodobowym nadzorem bezpieczeństwa. Alerty trzeba odbierać, progi dostrajać, a zdarzenia oceniać. Im mniej osób ma to robić, tym większe znaczenie ma dobranie wąskiego, trafnego zakresu — lepiej trzy alerty tygodniowo, które ktoś realnie obsłuży, niż trzysta, które wszyscy ignorują.

Kolejność, która się sprawdza: najpierw inwentaryzacja tego, co chcesz widzieć i co ma się dziać po alercie, potem wybór narzędzia pod te potrzeby, a na końcu konfiguracja i kalibracja progów po pierwszych tygodniach pracy.

Warto też zapisać, kto odbiera alerty i w jakich godzinach. To jedno zdanie zmienia projekt bardziej niż wybór platformy.

Jeśli chcesz porównać, jak taki zakres przekłada się na pracę i koszt, zaczynamy od artykułu o tym, z czego składa się koszt monitoringu. Zakres usługi opisujemy na stronie wdrożeń monitoringu i cyberbezpieczeństwa, a pytania można zadać przez stronę kontaktu.