Jeżeli Wazuh pokazuje wiele podobnych alertów, pierwszym krokiem jest sprawdzenie, co je wywołuje. Ten sam komunikat w dashboardzie może pochodzić z różnych hostów lub czynności. Zanim zmienisz regułę, wybierz powtarzające się zdarzenie, zbierz jego surowy log i ustal, które pola pozwalają odróżnić zwykłą pracę administratora od zdarzenia wymagającego reakcji.
Rozpoznaj drogę zdarzenia
Agent lub inne źródło dostarcza log. Dekoder wydobywa z niego pola, a reguła ocenia warunki i może wygenerować alert. Zapisz dla kilku przykładów: źródło, host, czas, identyfikator reguły, poziom alertu i pola użyte przy dopasowaniu. Porównaj przypadek, który chcesz ograniczyć, z podobnym zdarzeniem, które nadal ma alarmować.
Przykład: zadanie administracyjne wykonuje znane konto techniczne na wskazanym serwerze w ustalonym oknie. Jeśli podobny alert powstanie na innej stacji albo dla innego konta, nadal ma pozostać widoczny. Warunki reguły powinny więc odpowiadać rzeczywistemu wzorcowi, a nie samej nazwie narzędzia czy całej kategorii logów.
Zmiana i test
Wazuh opisuje własne reguły w pliku /var/ossec/etc/rules/local_rules.xml dla mniejszych zmian; dla większych zestawów zaleca osobne pliki w katalogu reguł. Dokumentacja przewiduje dla własnych reguł identyfikatory z zakresu 100000–120000. Przed edycją zachowaj kopię pliku i zanotuj, jaka reguła jest punktem wyjścia. Nie kopiuj bez potrzeby całego dostarczonego zestawu reguł.
Narzędzie wazuh-logtest pozwala podać próbkę logu i zobaczyć wynik dekodowania oraz dopasowania reguł. Przygotuj co najmniej trzy próbki:
- Zdarzenie, dla którego nowa reguła powinna zadziałać.
- Podobne zdarzenie z innego hosta lub konta, którego nie wolno ukryć.
- Zdarzenie niepowiązane, potwierdzające brak przypadkowego dopasowania.
Zapisz oczekiwany i otrzymany identyfikator reguły oraz poziom alertu. Dopiero po przejściu tych testów zastosuj zmianę na serwerze zgodnie z dokumentacją. wazuh-logtest czyta zapisane reguły do testu, natomiast działający manager wymaga ponownego uruchomienia, aby używać zmian przy generowaniu alertów. Po wdrożeniu ponów test w rzeczywistym strumieniu danych i sprawdź, czy nie zniknęły istotne alarmy.
Rekomendacja praktyczna: każda korekta powinna mieć właściciela, opis przyczyny, próbki pozytywne i negatywne oraz prostą drogę wycofania. To ogranicza ryzyko, że ciche wyciszenie stanie się trwałą luką w monitoringu.
Wcześniejszy artykuł o Wazuh Active Response dotyczy etapu ewentualnej automatycznej reakcji.