Klient wdraża Wazuh, agenci raportują z serwerów, dashboard wygląda imponująco. Tydzień później w skrzynce leży 4 tysiące alertów dziennie i nikt już ich nie otwiera. To najczęstszy scenariusz świeżo postawionego SIEM-u: system działa technicznie poprawnie, ale generuje tyle szumu, że administrator przestaje reagować na cokolwiek. A to gorsze niż brak monitoringu, bo daje złudne poczucie bezpieczeństwa. Wazuh sam z siebie nie wie, co jest ważne w Twojej infrastrukturze – trzeba go tego nauczyć.
Skala poziomów alertów: co naprawdę znaczy „level 7”
Każda reguła w Wazuh ma przypisany poziom od 0 do 15. To nie jest kosmetyka, tylko podstawa całej filozofii dostrajania. Poziom 0 oznacza zdarzenie, które ma być zignorowane (np. potwierdzenie, że coś zadziałało poprawnie). Poziomy 1-3 to informacje o niskim znaczeniu: logowanie użytkownika, standardowy restart usługi. Te zdarzenia warto zbierać do analizy retrospektywnej, ale nie zasługują na powiadomienie w czasie rzeczywistym.
Poziomy 4-6 to obszar „zauważ, ale się nie spiesz” – błędy konfiguracji, odrzucenia firewalla, użycie sudo. Realna eskalacja zaczyna się dopiero od poziomu 7: tu trafiają zdarzenia, których pojedynczo nie wolno ignorować, np. wielokrotne nieudane logowania czy alert z systemu IDS. Poziomy 9-11 sygnalizują coś poważniejszego, jak wzorzec ataku brute force albo wykrycie znanej sygnatury malware. Poziomy 12-14 to zdarzenia krytyczne: próby ataku na poziomie jądra systemu, podejrzenie kompromitacji. Poziom 15 rezerwuje się dla sytuacji wymagających natychmiastowej reakcji, praktycznie potwierdzonego włamania.
Sensowna zasada wyjściowa dla małej firmy: powiadomienia w czasie rzeczywistym (mail, Slack, SMS) tylko od poziomu 7 wzwyż, ewentualnie od 10 jeśli infrastruktura jest większa i nawet poziom 7 generuje zbyt dużo ruchu. Wszystko poniżej trafia do logów i dashboardu, gdzie można to przejrzeć raz dziennie albo raz w tygodniu, a nie w trybie alarmowym.
Dlaczego więcej alertów to nie sukces
Wazuh domyślnie ma naprawdę dużą bibliotekę reguł (dla popularnych systemów operacyjnych, aplikacji, urządzeń sieciowych) i część z nich w konkretnym środowisku po prostu nie pasuje. Serwer aplikacyjny, który regularnie restartuje worker procesy zgodnie z konfiguracją, wygeneruje setki „alertów”, które w rzeczywistości są normalną pracą systemu. Jeśli nikt tego nie wyczyści, zespół uczy się jednej rzeczy: alerty z Wazuh można ignorować. To jest moment, w którym monitoring przestaje działać, mimo że technicznie działa bez zarzutu.
Podobny mechanizm znasz zapewne z innych narzędzi: przy progach i wyzwalaczach w Zabbixie obowiązuje ta sama zasada – im więcej fałszywych trafień, tym szybciej ktoś wyłączy powiadomienia zamiast je poprawić. Dobry monitoring, czy to SIEM, czy prosty monitoring dostępności, wygrywa nie liczbą wykrytych zdarzeń, tylko liczbą trafnych powiadomień, na które ktoś realnie zareagował.
Jak dostrajać reguły w praktyce
Wazuh pozwala pisać własne reguły XML w katalogu reguł lokalnych (domyślnie local_rules.xml), tak żeby nie modyfikować reguł domyślnych i nie stracić ich przy aktualizacji. Trzy najczęściej używane mechanizmy dostrajania to:
- Wyciszanie (suppress/ignore): jeśli konkretne zdarzenie jest znane i akceptowalne (np. skrypt backupowy codziennie o 2:00 loguje się jako root), tworzysz regułę nadpisującą, która obniża jej poziom do 0 albo w ogóle wyklucza z przetwarzania.
- Progi (threshold, frequency): zamiast alarmować przy każdym nieudanym logowaniu, ustawiasz regułę, która odpala się dopiero po np. 5 nieudanych próbach w ciągu 120 sekund z tego samego adresu IP. To eliminuje pojedyncze literówki użytkowników i zostawia realne próby ataku.
- Priorytety i grupowanie: reguły można łączyć w grupy (np. wszystko związane z SSH, wszystko związane z bazą danych) i różnicować poziom w zależności od kontekstu – inny priorytet dla serwera produkcyjnego, inny dla środowiska testowego.
W praktyce dostrajanie to proces ciągły, nie jednorazowa konfiguracja. Pierwsze dwa-trzy tygodnie po wdrożeniu warto poświęcić na przegląd najczęściej powtarzających się alertów niskiego poziomu i decydowanie, które z nich są szumem, a które sygnałem, że coś w infrastrukturze wymaga poprawy (a nie ukrycia w regule).
Cztery reguły, które warto mieć od pierwszego dnia
Zamiast próbować dostroić wszystko naraz, dobrze zacząć od kilku reguł, które faktycznie łapią realne zagrożenia i rzadko fałszywie alarmują:
- Seria nieudanych logowań: kilka nieudanych prób logowania (SSH, RDP, panel administracyjny) w krótkim czasie z jednego źródła. To klasyczny sygnał ataku brute force i jeden z najbardziej wartościowych alertów, jakie SIEM może wygenerować.
- Eskalacja uprawnień: użycie sudo lub su przez konto, które normalnie tego nie robi, albo dodanie użytkownika do grupy administratorów poza godzinami pracy. Takie zdarzenia zdarzają się rzadko i prawie zawsze zasługują na sprawdzenie.
- Zmiana pliku krytycznego: Wazuh ma wbudowany moduł integralności plików (FIM), który wykrywa modyfikacje w katalogach takich jak /etc/passwd, pliki konfiguracyjne serwera WWW czy klucze SSH. Każda taka zmiana poza znanym oknem serwisowym powinna generować alert.
- Uruchomienie podejrzanego procesu: narzędzia typu netcat, procesy uruchamiane z katalogów tymczasowych, nietypowe polecenia PowerShell na Windowsie. Tu warto połączyć regułę z listą znanych, dopuszczalnych procesów administracyjnych, żeby nie łapać własnych skryptów utrzymaniowych.
Te cztery kategorie pokrywają większość realnych incydentów w małej i średniej firmie, a jednocześnie są na tyle rzadkie w normalnej pracy systemu, że nie zasypią skrzynki. Reszta reguł domyślnych może zostać na niższym poziomie priorytetu i trafiać wyłącznie do logów.
Mniej, ale trafnie
Cel dostrajania Wazuha nie jest taki, żeby zredukować liczbę alertów do zera. Chodzi o to, żeby każdy alert, który trafia na telefon administratora, faktycznie wymagał reakcji. Firma z dziesięcioma serwerami, która dostaje trzy sensowne powiadomienia tygodniowo i reaguje na wszystkie, jest bezpieczniejsza niż firma, która dostaje sto powiadomień dziennie i nie otwiera żadnego. To brzmi jak oczywistość, ale w praktyce większość wdrożeń SIEM w małych firmach kończy się właśnie na etapie „za dużo szumu, olewamy to”.
Co dalej w cyklu
W kolejnym wpisie pokażemy, dokąd te dobrze dostrojone alerty powinny w ogóle trafiać: integracje Wazuha ze Slackiem, mailem i SMS-em, żeby powiadomienie dotarło do właściwej osoby we właściwym kanale, zanim zdąży się zgubić w skrzynce.
Jeśli wdrożenie i dostrajanie Wazuha brzmi jak coś, na co Twoja firma nie ma czasu (a większość małych firm nie ma), w Zjawa.IT stawiamy monitoring bezpieczeństwa pod klucz: od instalacji agentów, przez napisanie reguł dopasowanych do Twojej infrastruktury, po skonfigurowanie sensownych powiadomień. Napisz do nas.