Jędrzej Boguszyński

Malware to złośliwe oprogramowanie stworzone przez cyberprzestępców w celu uszkodzenia systemu, kradzieży poufnych danych lub uzyskania nieautoryzowanego dostępu do systemów. To już dawno przestało być „wirusem z internetu”, dziś to zaawansowane narzędzie biznesu cyberprzestępczego, używane zarówno przez hakerów amatorów, jak i wielkie grupy APT (Advanced Persistent Threats) wspierane przez zagraniczne rządy. Stanowi ono ogromne zagrożenie, ponieważ potrafi w kilka minut zablokować operacyjnie całą firmę, żądając wielomilionowych okupów (ransomware), lub tygodniami wykradać tajemnice handlowe i dane klientów, pozostając w całkowitym ukryciu (infostealer).

Jak się przed tym obronić? Odpowiedzią jest skuteczny, wielowarstwowy monitoring punktów końcowych.

Wazuh SIEM/XDR jako centralny system obrony

Otwartoźródłowy system Wazuh, oprócz bycia klasycznym rozwiązaniem klasy SIEM, posiada także zaawansowane funkcjonalności XDR (Endpoint Detection and Response). Już w swojej standardowej konfiguracji daje nam świetne mechanizmy obronne:

• File Integrity Monitoring (FIM): Monitoruje pliki w czasie rzeczywistym i alarmuje, gdy ktoś zmodyfikuje lub utworzy nowy plik w kluczowych katalogach systemu.
• Malware detection: Monitoruje katalogi systemowe i potrafi wykrywać m.in. rootkity (malware, którego zadaniem jest pozostanie w ukryciu i po cichu przejęcie kontroli nad systemem). Dodatkowo, po integracji z bazami CTI (Cyberthreat Intelligence), potrafi automatycznie sprawdzać skróty (hashe) plików pod kątem znanych zagrożeń.
• Skanowanie podatności: Przeszukuje system pod kątem dziur w oprogramowaniu i braku krytycznych poprawek bezpieczeństwa.
• Benchmarki CIS: Weryfikuje zgodność konfiguracji naszych endpointów z międzynarodowymi standardami bezpieczeństwa CIS i dostarcza konkretny feedback, co należy poprawić, aby utwardzić systemy.

Po co więc YARA?

Choć Wazuh wie, kiedy plik się pojawił i kto go stworzył, sam z siebie nie potrafi zajrzeć „do środka” pliku i przeanalizować jego zawartości. Integracja z narzędziem YARA dodaje nam tą funkcjonalność i pozwala na:

• Analizę wnętrza pliku: Wazuh standardowo może sprawdzać hash pliku (jego unikalny odcisk palca). Jeżeli jednak haker zmodyfikuje w kod malware, hash się zmieni i system może nie rozpoznać zagrożenia. YARA szuka wewnątrz plików konkretnych wzorców, sekwencji bajtów czy unikalnych ciągów tekstowych (stringów), co pozwala rozpoznać złośliwy kod, nawet jeśli został sprytnie zmodyfikowany.
• Natychmiastowy skan w czasie rzeczywistym: Połączenie obu narzędzi opiera się na automatyzacji. W momencie, gdy moduł FIM Wazuha wykryje nowy plik (lub zmianę w istniejącym), agent natychmiast przekazuje go jako obiekt do skanera YARA. Taka detekcja dzieje się w ułamku sekundy od momentu, gdy zagrożenie trafi na dysk.
• Własne, elastyczne reguły detekcji: Możesz pisać własne reguły YARA dopasowane do specyfiki Twojej firmy lub błyskawicznie wdrażać sygnatury publikowane przez społeczność cybersecurity zaraz po wykryciu nowego globalnego zagrożenia.

W skrócie: Wazuh odpowiada za kontekst i automatyzację (zauważa plik i uruchamia procedurę), a YARA wykonuje głęboką inspekcję i decyduje, czy zawartość jest bezpieczna. Ta synergia rozbudowuje podstawowe funkcjonalności Wazuha o potężne narzędzie do wykrywania malware w czasie rzeczywistym.

Środowisko testowe

Aby praktycznie przedstawić proces konfiguracji oraz zweryfikować skuteczność integracji, przygotowałem dedykowane środowisko laboratoryjne. Składa się ono z dwóch kluczowych elementów:

1. Serwer Wazuh (Manager): Instalacja typu Standalone w wersji 4.14.5. Serwer pracuje w standardowej konfiguracji, co pozwoli Ci łatwo odtworzyć te kroki we własnym środowisku.
2. Endpoint (Klient): Maszyna z systemem Debian 13, na której zainstalowany jest wazuh-agent. To właśnie tutaj skonfigurujemy binaria skanera YARA oraz wdrożymy reguły detekcji. Na tym systemie przeprowadzimy również kontrolowany „atak”, wrzucając próbki złośliwego kodu, aby sprawdzić czujność naszego duetu.

Jak integracja działa za kulisami?

Zanim przejdziemy do konfiguracji, prześledźmy cykl życia takiego zdarzenia. Integracja opiera się na zamkniętej pętli logiki i automatyzacji, która działa w następujący sposób:

1. Detekcja zmiany (FIM): Gdy moduł File Integrity Monitoring wykryje powstanie nowego pliku lub modyfikację istniejącego w monitorowanych katalogach, agent generuje odpowiednie zdarzenie.
2. Wyzwalanie akcji (Active Response): Zdarzenie to uruchamia funkcję Active Response (moduł reagowania w czasie rzeczywistym). Funkcja ta automatycznie wywołuje skrypt yara.sh lokalnie na końcówce, na której doszło do incydentu.
3. Głęboka inspekcja (YARA): Skrypt przekazuje ścieżkę do podejrzanego pliku bezpośrednio do oprogramowania YARA. Skaner prześwietla plik na podstawie załadowanego zestawu reguł sygnaturowych.
4. Generowanie alertu: Jeżeli YARA rozpozna złośliwy kod, wynik skanowania jest natychmiast zapisywany do dedykowanego pliku logów. Log ten jest na bieżąco monitorowany przez agenta Wazuha, który przesyła go do serwera (Managera). Tam, zgodnie z regułami, generowany jest finalny alert o wykryciu malware.

Konfiguracja YARA na monitorowanym endpointcie

Skoro omówiliśmy już teorię i schemat działania, czas przejść do praktyki. Rozpoczniemy od przygotowania skanera YARA oraz konfiguracji agenta Wazuha na naszym endpoincie.

W pierwszej kolejności musimy przygotować system, instalując niezbędne biblioteki oraz pakiety narzędziowe:

apt install -y make gcc autoconf libtool libssl-dev pkg-config jq

Następnie pobieramy kod źródłowy YARA, kompilujemy go i instalujemy w systemie:

curl -LO https://github.com/VirusTotal/yara/archive/v4.5.5.tar.gz
tar -xvzf v4.5.5.tar.gz -C /usr/local/bin/ && rm -f v4.5.5.tar.gz
echo "/usr/local/lib" >> /etc/ld.so.conf && ldconfig
cd /usr/local/bin/yara-4.5.5/
./bootstrap.sh && sudo ./configure && sudo make && sudo make install && sudo make check

Aby upewnić się, że proces przebiegł pomyślnie, zweryfikujemy instalację, wywołując aplikację bezpośrednio z wiersza poleceń (CLI). Jeśli wszystko działa poprawnie, powinniśmy zobaczyć pomoc systemową programu:

Gdy skaner jest już gotowy do pracy, musimy przygotować „most” łączący go z Wazuhem. Wykorzystamy do tego mechanizm Active Response.

Przechodzimy do katalogu /var/ossec/active-response/bin/ na endpoincie i tworzymy w nim plik skryptu o nazwie yara.sh. Następnie wklejamy do niego poniższy kod, który będzie odpowiadał za przekazywanie informacji o wykrytych plikach do skanera:

#!/bin/bash
# Wazuh - Yara active response
# Copyright (C) 2015-2022, Wazuh Inc.
#
# This program is free software; you can redistribute it
# and/or modify it under the terms of the GNU General Public
# License (version 2) as published by the FSF - Free Software
# Foundation.


#------------------------- Gather parameters -------------------------#

# Extra arguments
read INPUT_JSON
YARA_PATH=$(echo $INPUT_JSON | jq -r .parameters.extra_args[1])
YARA_RULES=$(echo $INPUT_JSON | jq -r .parameters.extra_args[3])
FILENAME=$(echo $INPUT_JSON | jq -r .parameters.alert.syscheck.path)

# Set LOG_FILE path
LOG_FILE="logs/active-responses.log"

size=0
actual_size=$(stat -c %s ${FILENAME})
while [ ${size} -ne ${actual_size} ]; do
    sleep 1
    size=${actual_size}
    actual_size=$(stat -c %s ${FILENAME})
done

#----------------------- Analyze parameters -----------------------#

if [[ ! $YARA_PATH ]] || [[ ! $YARA_RULES ]]
then
    echo "wazuh-yara: ERROR - Yara active response error. Yara path and rules parameters are mandatory." >> ${LOG_FILE}
    exit 1
fi

#------------------------- Main workflow --------------------------#

# Execute Yara scan on the specified filename
yara_output="$("${YARA_PATH}"/yara -w -r "$YARA_RULES" "$FILENAME")"

if [[ $yara_output != "" ]]
then
    # Iterate every detected rule and append it to the LOG_FILE
    while read -r line; do
        echo "wazuh-yara: INFO - Scan result: $line" >> ${LOG_FILE}
    done <<< "$yara_output"
fi

exit 0;

Samo stworzenie skryptu to za mało – musimy jeszcze upewnić się, że proces agenta Wazuha będzie miał prawo go uruchomić. W tym celu ustawiamy odpowiedniego właściciela (użytkownika i grupę systemową) oraz nadajemy plikowi uprawnienia do wykonywania:

chmod 750 /var/ossec/active-response/bin/yara.sh
chown root:wazuh /var/ossec/active-response/bin/yara.sh

Ważne: Nadanie uprawnień 750 gwarantuje, że skrypt może być modyfikowany wyłącznie przez użytkownika root, a uruchamiany przez procesy w grupie wazuh, co zabezpiecza nasz mechanizm przed manipulacją ze strony nieuprawnionych użytkowników systemu.

Kiedy nasz skrypt-pomost jest już gotowy, musimy dostarczyć programowi YARA zestaw sygnatur, na podstawie których będzie on w stanie identyfikować złośliwe oprogramowanie.

Świetnym źródłem gotowych, profesjonalnych sygnatur jest darmowe repozytorium Valhalla od firmy Nextron Systems. Baza ta jest stale aktualizowana przez analityków zagrożeń i charakteryzuje się niezwykle wysoką skutecznością w wykrywaniu nowoczesnego malware. Reguły najlepiej umieścić w dedykowanym, bezpiecznym katalogu, do którego dostęp będą miały wyłącznie procesy systemowe Wazuha. W moim przypadku stworzyłem nową ścieżkę /var/ossec/active-response/yara/.

Do pobrania najnowszego, skonsolidowanego zestawu sygnatur bezpośrednio do nowo utworzonego katalogu możemy użyć poniższego polecenia curl:

curl 'https://valhalla.nextron-systems.com/api/v1/get' \
-H 'Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8' \
-H 'Accept-Language: en-US,en;q=0.5' \
--compressed \
-H 'Referer: https://valhalla.nextron-systems.com/' \
-H 'Content-Type: application/x-www-form-urlencoded' \
-H 'DNT: 1' -H 'Connection: keep-alive' -H 'Upgrade-Insecure-Requests: 1' \
--data 'demo=demo&apikey=1111111111111111111111111111111111111111111111111111111111111111&format=text' \
-o /var/ossec/active-response/yara/yara_rules.yar

Po pomyślnym pobraniu sygnatur musimy oczywiście zabezpieczyć plik, nadając mu odpowiednie uprawnienia i przypisując właściwego właściciela. Zapewni to, że nikt nieuprawniony nie zmodyfikuje naszych reguł detekcji. Możemy to zrobić za pomocą poniższych poleceń:

chown -R root:wazuh /var/ossec/active-response/yara/
chmod 640 /var/ossec/active-response/yara/yara_rules.yar

Ważne: W tym przypadku dla pliku z regułami stosujemy uprawnienia 640 (rw-r-----). Oznacza to, że root może plik edytować (np. podczas aktualizacji bazy), a procesy z grupy wazuh mają do niego wyłączne prawo do odczytu (read), co w zupełności wystarczy skanerowi do przeprowadzenia inspekcji.

Gdy mechanizm Active Response oraz sygnatury YARA są już w pełni przygotowane, pozostaje nam skonfigurować element, który będzie inicjował cały proces – moduł FIM. Wszelkich zmian dokonujemy w pliku konfiguracyjnym agenta Wazuha, który na systemach Linux znajduje się w ścieżce /var/ossec/etc/ossec.conf. Wewnątrz głównego bloku <ossec_config> musimy odnaleźć lub dodać sekcję odpowiedzialną za monitorowanie integralności plików i umieścić w niej następujące parametry:

<syscheck>
   <directories realtime="yes">/etc,/usr/bin,/usr/sbin</directories>
   <directories realtime="yes">/bin,/sbin,/boot</directories>
   <directories realtime="yes">/tmp,/var/temp,/root/</directories>
</syscheck>

Wskazują one agentowi, które katalogi ma stale monitorować w czasie rzeczywistym (realtime="yes"). Oczywiście listę ścieżek możesz (i powinieneś) elastycznie dopasować do specyfiki swojego środowiska oraz zasobów, które w danej chwili chcesz objąć szczególną ochroną (np. katalogi domowe użytkowników, foldery aplikacji webowych czy katalogi tymczasowe).

Po zapisaniu zmian w pliku ossec.conf musimy oczywiście zrestartować usługę agenta Wazuha, aby nowa konfiguracja została załadowana i zaczęła aktywnie działać. Na systemie Debian wykonamy to za pomocą menedżera usług systemctl:

systemctl restart wazuh-agent

Konfiguracja serwera Wazuh

Po pomyślnym przygotowaniu endpointu możemy przenieść się na serwer centralny, aby skonfigurować usługę Wazuh Manager. Aby nasza integracja w pełni spełniała swoje zadanie, musimy wyposażyć menedżer w odpowiednie mechanizmy interpretacji danych: dekodery i reguły.

Dekodery pełnią kluczową funkcję w ekosystemie Wazuh, analizują surowe logi przychodzące ze skanera YARA, „rozbijają” je na części pierwsze i wyciągają z nich kluczowe zmienne.

Aby dodać nasze dekodery otwieramy plik /var/ossec/etc/decoders/local_decoders.xml na serwerze Wazuh i wklejamy do niego następujące definicje:

<decoder name="yara_decoder">
  <prematch>wazuh-yara:</prematch>
</decoder>

<decoder name="yara_decoder1">
  <parent>yara_decoder</parent>
  <regex>wazuh-yara: (\S+) - Scan result: (\S+) (\S+)</regex>
  <order>log_type, yara_rule, yara_scanned_file</order>
</decoder>

Kiedy Wazuh Manager rozumie już strukturę logów dostarczanych przez Yarę i potrafi sprawnie wyizolować z nich najważniejsze parametry, potrzebujemy reguł, które na tej podstawie wygenerują właściwy alert w naszym panelu SOC.

Otwieramy plik /var/ossec/etc/rules/local_rules.xml i dodajemy do niego definicje reguł, które będą odpowiedzialne za kategoryzację zdarzeń i przypisanie im odpowiedniego poziomu priorytetu (alertu):

<group name="yara,">
  <rule id="108000" level="0">
    <decoded_as>yara_decoder</decoded_as>
    <description>Yara grouping rule</description>
  </rule>
  <rule id="108001" level="15">
    <if_sid>108000</if_sid>
    <match>wazuh-yara: INFO - Scan result: </match>
    <description>File "$(yara_scanned_file)" is a positive match. Yara rule: $(yara_rule)</description>
  </rule>
</group>

Po skonfigurowaniu mechanizmu interpretacji logów, ostatnim krokiem jest spięcie wszystkiego w całość za pomocą funkcji Active Response.
To właśnie ta konfiguracja inicjuje całą automatyzację: mówi Managerowi, jaki skrypt ma uruchomić na agencie oraz w reakcji na jaki konkretny alert (czyli zdarzenie z modułu FIM) ma to nastąpić.

Otwieramy główny plik konfiguracyjny serwera /var/ossec/etc/ossec.conf i wewnątrz bloku <ossec_config> dopisujemy następującą konfigurację:

<command>
    <name>yara_linux</name>
    <executable>yara.sh</executable>
    <extra_args>-yara_path /usr/local/bin -yara_rules /var/ossec/active-response/yara/yara_rules.yar</extra_args>
    <timeout_allowed>no</timeout_allowed>
  </command>

  <active-response>
    <disabled>no</disabled>
    <command>yara_linux</command>
    <location>local</location>
    <rules_id>550,554</rules_id>
  </active-response>

Wyjaśnienie: W sekcji <command> wskazujemy nazwę naszego skryptu yara.sh, który wcześniej umieściliśmy w katalogu active-response na agencie. Z kolei w sekcji <active-response> definiujemy, że skrypt ma uruchomić się lokalnie (<location>local</location>) w momencie, gdy system zarejestruje alerty FIM o określonych identyfikatorach (standardowo np. 550 dla nowych plików).

Po zapisaniu wszystkich zmian w pliku ossec.conf musimy zrestartować usługę Wazuh Managera, aby serwer wczytał nowe reguły Active Response, dekodery oraz zmodyfikowaną konfigurację. Wykonamy to za pomocą poniższego polecenia:

systemctl restart wazuh-manager

Testowanie działania integracji

Aby sprawdzić, czy nasz duet działa bez zarzutu, przeprowadzimy kontrolowany test. W tym celu pobierzemy próbkę złośliwego oprogramowania bezpośrednio z oficjalnego repozytorium Wazuha i umieścimy ją w jednym z katalogów, które objęliśmy monitoringiem FIM na naszym endpoincie.

Idealnym kandydatem do takich testów jest webshell. To stosunkowo bezpieczna próbka, ponieważ do spowodowania szkód wymaga zazwyczaj działającej infrastruktury Command-and-Control (C2) oraz serwera WWW.

Ważne (bezpieczeństwo przede wszystkim): Pamiętaj, aby pod żadnym pozorem nie uruchamiać pobranego pliku. Naszym celem jest wyłącznie sprawdzenie samej detekcji statycznej. Gdy tylko upewnisz się, że alert pojawił się w panelu Wazuh Dashboard, natychmiast usuń próbkę z dysku testowej maszyny.

Przejdźmy na nasz endpoint, do jednego z monitorowanych przez FIM katalogów (w moim przypadku /tmp) i użyjmy polecenia curl, aby pobrać testowy plik webshella

curl -s -XGET "https://raw.githubusercontent.com/wazuh/wazuh-documentation/refs/heads/4.14/resources/samples/webshell" -o webshell

Gdy tylko plik zostanie zapisany na dysku, w tle błyskawicznie wykona się cała zaprojektowana przez nas sekwencja działań. Moduł FIM wychwyci zdarzenie, Active Response przekaże je do skanera YARA, a ten po wykryciu dopasowania sygnatury zwróci log, który natychmiast zostanie zaczytany przez Wazuh Manager’a.

Efekt tej operacji zobaczysz bezpośrednio w konsoli webowej Wazuha. Nowo wygenerowany alert bezpieczeństwa powinien wyglądać następująco:

Warto również pamiętać, że alerty przypisane do grupy yara nie giną w gąszczu innych zdarzeń – są automatycznie agregowane i wizualizowane w dedykowanym widoku „Malware detection” w Wazuh Dashboard.

Moduł ten dostarcza analitykom bezpieczeństwa czytelne, globalne podsumowanie detekcji złośliwego oprogramowania na wszystkich monitorowanych agentach w infrastrukturze. Dzięki skonsolidowanym wykresom, statystykom najpopularniejszych zagrożeń oraz osi czasu, operator SOC może błyskawicznie ocenić aktualny stan bezpieczeństwa organizacji i sprawnie odsiać incydenty o najwyższym priorytecie.

Automatyczna aktualizacji reguł YARA

Każdy, kto choć trochę orientuje się w realiach cyberbezpieczeństwa, doskonale wie, że system detekcji jest tylko tak dobry, jak aktualna jest jego baza zagrożeń. Dokładnie ta sama zasada dotyczy sygnatur YARA. Aby nasza integracja niosła realną wartość dla organizacji i nadążała za nowymi zagrożeniami, musimy zadbać o regularne odświeżanie reguł na endpointach.

Najprostszym, a zarazem najbardziej niezawodnym sposobem na automatyzację tego procesu jest stworzenie zadania w harmonogramie cron (cron job) na każdym monitorowanym hoście. Dzięki temu system będzie mógł codziennie – na przykład w godzinach nocnych, gdy obciążenie infrastruktury jest najmniejsze – samodzielnie pobierać najnowsze sygnatury z repozytorium Valhalla za pomocą polecenia curl.

Odpowiednim podejściem jest zebranie całej logiki w jeden prosty skrypt Bash. Może on wyglądać następująco:

#!/bin/bash
#Pobranie aktualnych reguł
curl 'https://valhalla.nextron-systems.com/api/v1/get' \
-H 'Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8' \
-H 'Accept-Language: en-US,en;q=0.5' \
--compressed \
-H 'Referer: https://valhalla.nextron-systems.com/' \
-H 'Content-Type: application/x-www-form-urlencoded' \
-H 'DNT: 1' -H 'Connection: keep-alive' -H 'Upgrade-Insecure-Requests: 1' \
--data 'demo=demo&apikey=1111111111111111111111111111111111111111111111111111111111111111&format=text' \
-o /var/ossec/active-response/yara/yara_rules.yar
#Zmiana uprawnień pliku
chown -R root:wazuh /var/ossec/active-response/yara/
chmod 640 /var/ossec/active-response/yara/yara_rules.yar

Plik zapisujemy np. jako /opt/scripts/update_yara.sh i nadajemy mu uprawnienia do wykonywania (chmod +x)

chmod +x /opt/scripts/update_yara.sh

Następnie, aby skonfigurować jego okresowe uruchamianie w harmonogramie systemowym, otwieramy crontab użytkownika root:

nano /etc/crontab

I dodajemy regułę, która wywoła nasz skrypt każdej nocy, na przykład o godzinie 02:30:

30 2 * * * root bash /opt/scripts/update_yara.sh

Pułapka wdrożeniowa: Reguły YARA a systemy EDR/Antywirusowe

Warto wspomnieć o istotnym niuansie, który może zaskoczyć Cię w środowisku produkcyjnym. Jeżeli Twoje systemy operacyjne są dodatkowo chronione przez zewnętrzne, wysokopoziomowe oprogramowanie antywirusowe lub system klasy EDR, może ono potraktować pobrany plik yara_rules.yar jako… aktywne zagrożenie. Wynika to z faktu, że plik ten zawiera tysiące surowych sygnatur oraz unikalnych ciągów znaków charakterystycznych dla prawdziwego malware.

W moim przypadku dokładnie taki problem generował Microsoft Defender for Cloud na maszynach wirtualnych z systemem Linux w chmurze Azure. Z jednej strony zależało klientowi na globalnej ochronie dostarczanej przez Defendera, a z drugiej – na lokalnych, elastycznych możliwościach detekcji, jakie daje duet Wazuh + YARA.

Jeśli w Twoim środowisku dojdzie do podobnego konfliktu i antywirus zacznie blokować lub usuwać plik z sygnaturami, rozwiązanie jest proste: musisz dodać pełną ścieżkę do pliku yara_rules.yar (lub cały dedykowany katalog /var/ossec/active-response/yara/) do listy wyjątków (exclusions) w polityce bezpieczeństwa nadrzędnego oprogramowania ochronnego. Pozwoli to obu systemom współpracować ramię w ramię, bez wzajemnego zakłócania swojej pracy.

Skalowanie rozwiązania: Masowa konfiguracja endpointów

Jednym z głównych wyzwań przy wdrażaniu integracji Wazuha z silnikiem YARA jest fakt, że całe środowisko wykonawcze – czyli samą binarię skanera, skrypty Active Response oraz strukturę katalogów – należy domyślnie skonfigurować bezpośrednio na każdym chronionym endpoincie. O ile w małym środowisku laboratoryjnym nie stanowi to większego problemu, o tyle w strukturach korporacyjnych zarządzających setkami czy tysiącami systemów, ręczna konfiguracja każdego hosta byłaby syzyfową pracą.

Aby wdrożenie przyniosło organizacji realną wartość i było łatwe w utrzymaniu, kluczowe jest wykorzystanie systemów do automatyzacji i zarządzania konfiguracją:

• Dla systemów Linux: Najlepszym podejściem jest przygotowanie dedykowanego playbooka w narzędziu Ansible. Może on w pełni zautomatyzować proces: od instalacji paczki yara, przez wdrożenie struktury katalogów i skryptu yara.sh, aż po konfigurację lokalnego pliku ossec.conf i dodanie zadania w cronie.
• Dla systemów Windows: W środowiskach domenowych dystrybucję niezbędnych plików (binariów YARA dla Windows, skryptów PowerShell) oraz modyfikację rejestru czy plików konfiguracyjnych agenta najlepiej zrealizować centralnie za pomocą Polityk Grupowych (GPO) lub systemów zarządzania klasą endpointów (np. Microsoft Intune).

Dzięki takiemu podejściu, wdrożenie zaawansowanej detekcji malware w czasie rzeczywistym na setkach maszyn staje się kwestią zaledwie kilku kliknięć lub jednego uruchomienia skryptu wdrożeniowego.

Warto również pamiętać, że sam Wazuh posiada potężny, wbudowany mechanizm ułatwiający zarządzanie konfiguracją na dużą skalę. Mowa o konfiguracji grupowej.

Z poziomu managera możemy połączyć nasze endpointy w dedykowane grupy (np. według systemu operacyjnego lub pełnionej roli), a następnie edytować wspólny plik z politykami o nazwie agent.conf. Wszelkie bloki konfiguracyjne (w tym sekcję <syscheck> odpowiedzialną za monitorowanie FIM czy wyzwalacze Active Response), które umieścimy w tym pliku, zostaną automatycznie zsynchronizowane i połączone z lokalnymi plikami ossec.conf na wszystkich maszynach przypisanych do danej grupy.

Połączenie tego mechanizmu z zewnętrzną automatyzacją (np. do jednorazowego wdrożenia samych skryptów i binariów YARA) drastycznie skraca czas potrzebny na objęcie ochroną nowo stawianych maszyn w organizacji.

Przydatne linki:

• Wazuh SIEM/XDR – oficjalna strona produktu, tutaj znajdziesz specyfikację i pełną dokumentację systemu.
• Program Ambasadorów Wazuh – dołącz do społeczności open-source i pomóż nam rozwijać system Wazuh.