Urządzenia sieciowe to pierwsza linia obrony każdego środowiska IT typu on-premise, ale tysiące generowanych przez nie logów na sekundę (zwłaszcza jeśli urządzenie działa na brzegu sieci z publicznie wystawionym interfejsem) potrafią przytłoczyć nawet najlepszego administratora. Co z tego, że Twój FortiGate blokuje setki cyberzagrożeń dziennie, skoro te cenne informacje giną w gąszczu innych metryk? Tutaj do akcji wkracza Wazuh, otwartoźródłowy system SIEM/XDR.
W tym artykule dowiesz się, jak zintegrować potężny sprzętowy firewall nowej generacji (NGFW) z systemem Wazuh na przykładzie urządzenia FortiGate. Bez instalacji agentów, przy użyciu niezawodnego protokołu Syslog. Mimo że integracja pokazana jest na przykładzie rozwiązania od firmy Fortinet, cały schemat wygląda niemal identycznie w przypadku systemów innych producentów, takich jak Cisco czy HPE. Różnice sprowadzają się głównie do komend służących do konfiguracji, każdy vendor ma w końcu swoją, lekko odmienną składnię.
Dlaczego Wazuh?
Wazuh to otwartoźródłowa platforma bezpieczeństwa łącząca w sobie funkcje systemu XDR (Extended Detection and Response) i SIEM (Security Information and Event Management). Pozwala ona zbierać dane na temat bezpieczeństwa z całej naszej infrastruktury IT, korelować je ze sobą, wizualizować, a także (po odpowiedniej konfiguracji) automatycznie reagować na zagrożenia. Jest to aktualnie wiodący produkt tego typu w świecie open source cybersecurity. Platforma jest niezwykle wszechstronna i bez problemu można ją dostosować do potrzeb organizacji czy zintegrować z innymi rozwiązaniami. W kontekście naszego tematu Wazuh posłuży jako silnik do zbierania i analizowania logów z firewalli FortiGate. Kiedy system wykryje naruszenie bezpieczeństwa zdefiniowane w regułach, wyzwoli alert, który natychmiast poinformuje zespół SOC (lub administratorów IT) o incydencie wymagającym reakcji.
Architektura integracji
Sama architektura integracji urządzeń sieciowych z Wazuhem jest dosyć prosta, opiera się ona, tak jak wspomniałem wcześniej, na protokole Syslog. Nieważne, czy tak jak w moim przypadku korzystasz z FortiGate’a, czy ze sprzętu innych vendorów, integracja w każdym z tych przypadków wygląda identycznie.
Mamy tutaj tak naprawdę trzy opcje:
- Lokalny Syslog i monitorowanie pliku: Możemy skonfigurować usługę
rsyslogna tym samym hoście, na którym działawazuh-manager, zapisywać logi z sieci do oddzielnego pliku.log, a potem wskazać ten plik managerowi do analizy. - Bezpośrednia wysyłka do managera: Możemy skonfigurować syslog receiver bezpośrednio w
wazuh-managerzei przesyłać do niego logi prosto z urządzenia sieciowego. - Wysyłka przez zewnętrzny kolektor: Możemy postawić oddzielny serwer z usługą
rsyslog, skierować tam ruch z urządzenia sieciowego, a następnie za pomocą zainstalowanego na tym serwerzewazuh-agentaprzekazywać logi dowazuh-manageraw celu analizy.
Wybór odpowiedniego podejścia zależy od skali organizacji, liczby urządzeń sieciowych i oczywiście wolumenu generowanych logów. Moja rada wygląda następująco:
- Mała infrastruktura (kilka urządzeń sieciowych): Jeśli Twój Wazuh monitoruje niewielką liczbę endpointów i ma bezpośrednią komunikację po LAN-ie z urządzeniami sieciowymi, skorzystaj z natywnego syslog receivera bezpośrednio w
wazuh-managerze. - Średnia infrastruktura (powyżej 100 endpointów i więcej sieciówki): W takim scenariuszu lepiej skonfigurować osobną usługę
rsyslogna tym samym serwerze, na którym działa Wazuh. Logi z sieci warto zapisywać do dedykowanego pliku.log, który następnie będzie analizowany przezwazuh-managera. To podejście pozwoli Ci zachować porządek, pliki tekstowe można łatwo rotować i szybko weryfikować, czy ruch z firewalli w ogóle spływa. W przypadku bezpośredniej wysyłki do managera wszystkie zdarzenia sieciowe trafiają do jednego „wora” wraz z logami z pozostałych systemów. - Duża infrastruktura (podział na VLAN-y, strefy DMZ i restrykcyjna polityka sieciowa): Najlepszą opcją będzie wdrożenie osobnych serwerów Syslog (kolektorów) dla konkretnych grup urządzeń. Możesz postawić taki serwer per site lub per strefa, zbierać na nim logi lokalnie, a następnie przy pomocy
wazuh-agentówbezpiecznie przesyłać je do centralnego managera. W tym modelu na firewallach pomiędzy strefami wystarczy otworzyć tylko jeden port (1514/TCP) dla ruchu między kolektorem a managerem Wazuha. Co ważne, hosty pełniące rolę kolektorów możesz wrzucić do jednej grupy w panelu Wazuha, co ogromnie ułatwia centralne zarządzanie ich konfiguracją.
Konfiguracja serwera Wazuh
Konfigurację przedstawię w dwóch wariantach: z wykorzystaniem wewnętrznego syslog receivera w wazuh-managerze oraz przy użyciu osobnej usługi rsyslog działającej na tym samym hoście.
Wariant A: Konfiguracja syslog receivera bezpośrednio w wazuh-managerze
W pierwszym kroku musimy zalogować się na serwer Wazuha przez SSH i otworzyć do edycji plik /var/ossec/etc/ossec.conf. Jeśli wolisz interfejs graficzny, możesz zrobić to też bezpośrednio w panelu Wazuha, przechodząc do zakładki Server Management -> Settings -> Edit configuration.
W pliku konfiguracyjnym, wewnątrz głównego bloku <ossec_config>, dodajemy sekcję <remote>, w której definiujemy nasz odbiornik Syslog. Za pomocą tagu <allowed-ips> wskazujemy adres IP lub całą podsieć, z której chcemy zezwolić na komunikację (czyli wysyłanie logów).
Ze względów bezpieczeństwa najlepiej zawęzić tę konfigurację do konkretnych adresów IP urządzeń sieciowych. Jeżeli masz więcej niż jedno takie urządzenie, w sekcji <remote> możesz dodać kilka linii z tagiem <allowed-ips>, każdą dla osobnego adresu.
<ossec_config>
<remote>
<connection>syslog</connection>
<port>514</port>
<protocol>udp</protocol>
<local_ip>192.168.0.60</local_ip>
<allowed-ips>192.168.0.0/24</allowed-ips>
</remote>
</ossec_config>UDP vs TCP – który protokół wybrać?
W tym miejscu warto na chwilę zatrzymać się przy wyborze protokołu transportowego: UDP czy TCP?
- Protokół UDP działa na zasadzie „wyślij i zapomnij”. Host źródłowy nadaje pakiety w stronę celu bez weryfikacji, czy odbiorca w ogóle je odebrał. Jest to rozwiązanie idealne do przesyłania dużych strumieni danych w krótkim czasie. Wadą jest jednak ryzyko, że przy dużym obciążeniu sieci część pakietów może zostać bezpowrotnie utracona, o czym system nas nie powiadomi.
- Protokół TCP stawia na niezawodność. Przed wysłaniem danych następuje tzw. trójstronny uścisk dłoni (3-way handshake). Urządzenia potwierdzają nawiązanie sesji, a każdy odebrany pakiet musi zostać potwierdzony przez odbiorcę. Dzięki temu mamy pewność, że żaden log nie zginie po drodze. Niestety, ze względu na swoją architekturę, TCP generuje znacznie większy narzut na sieć i potrafi mocno obciążyć procesor (CPU) serwera odbierającego przy masowym napływie danych.
Moja rekomendacja: Do odbierania Sysloga bezpośrednio zdecydowanie polecam korzystanie z protokołu UDP. Pozwoli to zminimalizować obciążenie wazuh-managera. Urządzenia sieciowe, zwłaszcza firewalle brzegowe, potrafią generować gigantyczne wolumeny logów i narzut związany z potwierdzeniami TCP mógłby niepotrzebnie spowolnić działanie całego SIEM-a.
Po wprowadzeniu zmian musimy zrestartować usługę wazuh-managera, aby nowa konfiguracja zaczęła obowiązywać. Podobnie jak wcześniej, możemy to zrobić również z poziomu interfejsu graficznego (UI), klikając przycisk Restart Manager w widoku edycji konfiguracji.
sudo systemctl restart wazuh-managerPo tym jak nasz manager się zrestartował, możemy sprawdzić czy nasz syslog nasłuchuje na odpowiednim porcie komendą ss:
test@wazuh:~# sudo ss -tulp
Netid State Recv-Q Send-Q Local Address:Port Peer Address:Port Process
udp UNCONN 0 0 192.168.0.60:bootpc 0.0.0.0:* users:(("dhcpcd",pid=2644,fd=3))
udp UNCONN 0 0 192.168.0.60:syslog 0.0.0.0:* users:(("wazuh-remoted",pid=11354,fd=4))
udp UNCONN 0 0 [2a02:a314:c591:9e80::541f]:dhcpv6-client [::]:* users:(("dhcpcd",pid=1158,fd=3))
udp UNCONN 0 0 [2a02:a314:c591:9e80:1ef8:5ec4:6dd1:75d9]:dhcpv6-client [::]:* users:(("dhcpcd",pid=1119,fd=3))
udp UNCONN 0 0 [fe80::b6a9:2460:51ca:ae67]%enp0s8:dhcpv6-client [::]:* users:(("dhcpcd",pid=1003,fd=3))
tcp LISTEN 0 128 0.0.0.0:1515 0.0.0.0:* users:(("wazuh-authd",pid=11244,fd=6))
tcp LISTEN 0 128 0.0.0.0:1514 0.0.0.0:* users:(("wazuh-remoted",pid=11353,fd=4))
tcp LISTEN 0 2048 0.0.0.0:55000 0.0.0.0:* users:(("python3",pid=11195,fd=44))
tcp LISTEN 0 128 0.0.0.0:ssh 0.0.0.0:* users:(("sshd",pid=795,fd=6))
tcp LISTEN 0 511 0.0.0.0:https 0.0.0.0:* users:(("node",pid=622,fd=19))
tcp LISTEN 0 4096 *:9300 *:* users:(("java",pid=678,fd=616))
tcp LISTEN 0 2048 [::]:55000 [::]:* users:(("python3",pid=11195,fd=46))
tcp LISTEN 0 128 [::]:ssh [::]:* users:(("sshd",pid=795,fd=7))
tcp LISTEN 0 4096 *:9200 *:* users:(("java",pid=678,fd=618))Wariant B: Konfiguracja usługi rsyslog na serwerze Wazuh
Jeżeli chcemy użyć oddzielnej usługi, musimy ją najpierw zainstalować na hoście Wazuha. W większości nowoczesnych dystrybucji Linuksa rsyslog jest obecny domyślnie, ale jeśli go brakuje, zainstalujesz go jedną komendą:
sudo apt update && sudo apt install rsyslogTworzymy nowy plik pod odbieranie logów z naszych urządzeń sieciowych w katalogu /etc/rsyslog.d/. Pliki umieszczone w tym folderze są automatycznie dołączane podczas startu usługi na końcu głównego pliku konfiguracyjnego. Dzięki temu możemy zachować porządek, zwłaszcza gdy konfigurujemy wiele odbiorników rsyslog. W moim przypadku plik będzie nosił nazwę fortigate.conf.
W pliku umieszczamy następującą konfigurację:
# Define the Template
template(name="FortigateFile" type="string" string="date=%$now% %msg%\n")
# Define the Ruleset for Fortigate
ruleset(name="fortigate_ruleset") {
action(type="omfile"
file="/var/log/fortigate/syslog.log"
template="FortigateFile")
stop # CRITICAL: Prevents logs from falling through to other configs
}
# Bind the input port to the specific ruleset
input(type="imudp" port="514" ruleset="fortigate_ruleset")Wyjaśnienie pliku konfiguracyjnego:
- Sekcja
template: Opisuje strukturę logów odbieranych z firewalli FortiGate. Definiuje ona format, w jakim chcemy zapisywać przychodzące wiadomości w pliku tekstowym (w tym przypadku dodajemy na początku czytelną datę). - Sekcja
ruleset: To zestaw reguł, który staje się niezastąpiony, gdy naszrsyslogodbiera logi z wielu różnych źródeł. Pozwala on precyzyjnie odseparować strumienie danych i decydować, które wiadomości trafiają do konkretnych lokalizacji. W naszym przypadku wszystkie logi sieciowe powiązane z tą regułą będą zapisywane w osobnym pliku/var/log/fortigate/syslog.log. Znajdujący się na końcu wpisstopto kluczowy element, dba o to, aby te logi nie „przeleciały” do domyślnych plików systemowych Linuksa (takich jak/var/log/syslog). - Sekcja
input: Wskazuje, na jakim porcie (w tym przypadku standardowym514) oraz protokole (imudp, czyli UDP) ma nasłuchiwać nasz odbiornik, a także wiąże ten port z wcześniej przygotowanym zestawem reguł (fortigate_ruleset).
Gdy mamy już przygotowany plik konfiguracyjny, musimy uruchomić usługę rsyslog (lub zrestartować ją, jeżeli działała już wcześniej) i upewnić się, że prawidłowo nasłuchuje ona na wskazanym porcie.
sudo systemctl enable rsyslog
sudo systemctl restart rsyslogTak jak poprzednio, stan nasłuchiwania usługi możemy zweryfikować poleceniem ss -tulpn.
Ważna uwaga: Pamiętajmy, że w systemach Linux dwa różne procesy nie mogą jednocześnie nasłuchiwać na tym samym porcie i protokole. Jeżeli w poprzednim kroku testowałeś Wariant A (wewnętrzny odbiornik w wazuh-managerze), musisz usunąć lub zakomentować tamtą sekcję <remote> w pliku ossec.conf i zrestartować managera, zanim spróbujesz uruchomić usługę rsyslog. W przeciwnym razie rsyslog nie będzie mógł zająć portu 514 i zgłosi błąd (Address already in use).
Zanim zaczniemy wysyłać logi do rsysloga, warto od razu zająć się tematem rotowania plików. Jeśli o to nie zadbamy, po kilku dniach może się okazać, że nasz plik logów na tyle „spuchł”, że zajął większość przestrzeni dyskowej na serwerze. W tym celu wykorzystamy systemową usługę o nazwie logrotate. Jeżeli nie masz jej jeszcze zainstalowanej na swoim serwerze, możesz to zrobić jednym z poniższych poleceń:
sudo apt install logrotatePo instalacji musimy zdefiniować reguły, według których nasze pliki będą rotowane. Podobnie jak wcześniej, tworzymy w tym celu nowy, dedykowany plik w folderze /etc/logrotate.d/. Dla jasności najlepiej nazwać go po prostu fortigate.
W pliku umieszczamy następującą konfigurację:
/var/log/fortigate/syslog.log {
daily
rotate 0
compress
delaycompress
missingok
notifempty
create 0640 root root
postrotate
systemctl kill -s HUP rsyslog.service
endscript
}Wyjaśnienie pliku konfiguracyjnego:
- Ścieżka (
/var/log/fortigate/syslog.log): Wskazuje konkretny plik tekstowy, który ma podlegać automatycznemu procesowi rotacji. daily: Określa częstotliwość rotowania, w tym przypadku proces będzie uruchamiany codziennie.rotate 0: Definiuje liczbę archiwalnych (zrotowanych) plików, jakie system ma przechowywać na dysku. Wartość0oznacza, że stary plik jest natychmiast usuwany po zakończeniu cyklu. To celowy zabieg: logi z tego pliku są na bieżąco przekazywane i analizowane przez Wazuha, więc to tam znajduje się ich bezpieczne archiwum. Dzięki temu nie dublujemy danych i oszczędzamy cenne miejsce na dysku.compressidelaycompress: Włączają kompresję archiwalnych logów (do formatu.gz). Opcjadelaycompressodkłada kompresję o jeden cykl, co przydaje się, gdy jakiś proces jeszcze przez chwilę próbuje pisać do starego pliku. Warto z tego skorzystać jeżeli chcemy przechowywać archiwalne pliki.missingok: Sprawia, że jeśli plik logu z jakiegoś powodu chwilowo nie istnieje (np. FortiGate akurat nic nie wysłał), system nie zgłosi błędu i przejdzie do kolejnych zadań.notifempty: Blokuje rotację, jeżeli plik jest całkowicie pusty.create 0640 root root: Instrukcja dla systemu, aby zaraz po zrotowaniu (wyczyszczeniu) starego pliku, utworzył nowy, pusty plik z uprawnieniami0640, przypisując go do użytkownika i grupyroot.- Sekcja
postrotate/endscript: Kluczowy blok wykonawczy. Po wykonaniu rotacji wysyła do usługirsyslogsygnałHUP(kill -s HUP). Zmusza to demonarsyslogdo odświeżenia deskryptorów plików i rozpoczęcia zapisu do nowo utworzonego, czystego pliku. Bez tego rsyslog wciąż próbowałby pisać do starego, usuniętego już z widoku pliku.
Po stworzeniu pliku konfiguracyjnego musimy zrestartować (lub po prostu uruchomić) usługę logrotate oraz upewnić się, że będzie ona startowała automatycznie wraz z systemem operacyjnym.
sudo systemctl enable logrotate
sudo systemctl restart logrotatePro-tip dla administratorów: W zależności od dystrybucji Linuksa, logrotate może działać jako klasyczny demon lub jako usługa wywoływana cyklicznie przez systemowy zegar (systemd-timer). Jeśli po restarcie komenda systemctl status logrotate pokaże stan inactive (dead), nie przejmuj się, to normalne. Oznacza to, że system odpali ją automatycznie raz na dobę. Możesz zweryfikować stan samego timera komendą: systemctl status logrotate.timer.
Kiedy obie usługi działają już prawidłowo, musimy skonfigurować samego wazuh-managera. Wskażemy mu plik utworzony przez rsysloga, aby system mógł w czasie rzeczywistym zaciągać i analizować logi spływające z urządzenia FortiGate. W tym celu ponownie otwieramy do edycji plik /var/ossec/etc/ossec.conf (lub przechodzimy do edycji konfiguracji w panelu graficznym Wazuha) i wewnątrz głównego bloku <ossec_config> dodajemy następującą sekcję:
<ossec_config>
<localfile>
<log_format>syslog</log_format>
<location>/var/log/fortigate/syslog.log</location>
</localfile>
<ossec_config>Po zapisaniu pliku musimy zrestartować managera komendą:
sudo systemctl restart wazuh-managerWarto wiedzieć: Pomimo że w tym przykładzie konfigurowaliśmy usługę rsyslog bezpośrednio na serwerze Wazuh, cały proces przebiega identycznie w przypadku wdrożenia dedykowanego serwera do zbierania logów (Log Collector). Jedyna różnica polega na tym, że ścieżkę do pliku logów wskazujemy w pliku ossec.conf wazuh-agenta działającego na tym wydzielonym hoście, a nie w konfiguracji centralnego wazuh-managera.
Bezpieczeństwo przesyłanych logów
W tym miejscu warto ponownie się zatrzymać i przyjrzeć kwestii bezpieczeństwa przesyłania danych. Tradycyjny protokół Syslog jest rozwiązaniem starszego typu i nie szyfruje natywnie logów, które wędrują przez sieć do zdalnego hosta. Oznacza to, że logi przesyłane pomiędzy FortiGate a Wazuh-receiverem lub usługą rsyslog są przesyłane jawnym tekstem (plain text). Aby temu zaradzić, warto dodatkowo zabezpieczyć transmisję, np. wykorzystując Nginx jako Reverse Proxy oraz certyfikaty SSL/TLS.
Pełną instrukcję krok po kroku, jak to skonfigurować, znajdziecie w moim osobnym wpisie: https://jedrzejboguszynski.pl/2026/04/jak-bezpiecznie-przesylac-logi-do-systemu-wazuh/
Jeżeli logi trafiają do dedykowanego serwera, który pełni funkcję kolektora (Log Collector), to oczywiście odcinek trasy FortiGate <-> Log Collector musimy zabezpieczyć w wyżej wymieniony sposób. Natomiast o dalszy ruch sieciowy na trasie Wazuh-agent <-> Wazuh-manager nie musimy się już martwić, jest on w pełni bezpieczny, ponieważ agent domyślnie szyfruje całą swoją komunikację z centralnym serwerem.
Konfiguracja urządzenia FortiGate
Logujemy się do panelu webowego naszego urządzenia FortiGate i otwieramy konsolę CLI (bezpośrednio przez interfejs graficzny, po SSH lub dowolną inną dostępną metodą). Pamiętajcie, że do wykonania poniższych działań wymagane będzie konto z pełnymi uprawnieniami administracyjnymi na urządzeniu.
Najpierw musimy skonfigurować, jakie logi chcemy wysyłać do naszego Wazuha. To, jakie funkcjonalności posiada Wasz NGFW FortiGate, zależy głównie od wykupionej licencji. W moim przypadku chcę wysyłać wszystko: od logów standardowego ruchu sieciowego (info), aż po wykrycia czy blokady ataków przez system Intrusion Detection & Prevention (IPS).
Konfigurujemy to w CLI za pomocą następujących komend:
config log syslogd filter
set severity information # Captures info, notices, warnings, and errors
set forward-traffic enable # All firewall policy traffic logs
set local-traffic enable # Traffic generated by the FortiGate itself
set multicast-traffic enable
set sniffer-traffic enable
set anomaly enable # IPS/DoS sensor logs
set voip enable
endOczywiście możemy to wszystko skonfigurować również w interfejsie graficznym (GUI) urządzenia, ale użycie CLI jest po prostu o wiele szybsze.
Następnie musimy skonfigurować samą usługę syslogd na urządzeniu, aby wysyłała ona logi do naszego zdalnego odbiornika (receivera). Robimy to za pomocą następujących komend w CLI:
config log syslogd setting
set status enable
set server 192.168.0.60 # Your syslog receiver address
set mode udp # This enables UDP
set port 514 # Standard port for syslog
set facility local7
set format default
endPo wprowadzeniu konfiguracji możemy bezpiecznie zamknąć konsolę. FortiGate (w przeciwieństwie do urządzeń niektórych innych producentów) nie wymaga ręcznego zapisywania zmian, ponieważ każda zatwierdzona komenda jest stosowana i zapisywana natychmiast. Możemy więc od razu przejść do weryfikacji, czy generowane logi prawidłowo lądują w miejscu docelowym.
Jak sprawdzić czy logi trafiają do celu?
Jeżeli korzystaliście z wbudowanego odbiornika Syslog w wazuh-managerze (Wariant A), musicie najpierw włączyć opcję <logall> w głównej konfiguracji managera (ossec.conf). Opcja ta zmusza Wazuha do zapisywania absolutnie wszystkich przychodzących zdarzeń – nawet tych, które nie wygenerowały żadnego alertu. Po zapisaniu zmian i restarcie usługi wystarczy uruchomić podgląd na żywo pliku archiwum:
tail -f /var/ossec/logs/archive/archive.logJeśli wszystko skonfigurowaliście poprawnie, powinniście zacząć widzieć tam spływające surowe logi z FortiGate’a.
W przypadku użycia dedykowanej usługi rsyslog (Wariant B), sprawa jest prostsza. Weryfikację przeprowadzamy bezpośrednio na utworzonym wcześniej pliku celowym:
tail -f /var/log/fortigate/syslog.logKonfiguracja dekoderów i reguł w systemie Wazuh
Zazwyczaj, kiedy podpinamy pod Wazuha nowe data source, musimy najpierw samodzielnie skonfigurować dekodery (aby wazuh-manager potrafił zrozumieć surowe logi i rozbić je na poszczególne pola) oraz reguły (zestaw instrukcji, na podstawie których wykrywane i alertowane są zagrożenia). Na szczęście Wazuh w najnowszej wersji (na dzień pisania artykułu 4.14.5) posiada już wbudowane dekodery i bazowy zestaw reguł dla urządzeń firmy Fortinet.
Jednak na potrzeby naszego laboratorium nadpiszemy domyślne reguły i podniesiemy ich poziom. Pozwoli to na precyzyjne wykrywanie i alarmowanie o atakach typu brute-force wymierzonych zarówno w usługę SSL-VPN, jak i w sam panel administracyjny naszego FortiGate.
Otwieramy do edycji plik /var/ossec/etc/rules/local_rules.xml (lub w interfejsie graficznym Wazuha przechodzimy do Server management -> Rules -> Manage rules files i wybieramy do edycji plik local_rules.xml), a następnie wklejamy do niego poniższe reguły:
<group name="fortigate,syslog">
<rule id="81606" level="10" overwrite="yes">
<if_sid>81603</if_sid>
<action>login</action>
<status>failed</status>
<description>Fortigate: Admin HTTPS Login failed.</description>
<group>authentication_failed,gdpr_IV_32.2,invalid_login,nist_800_53_AC.7,</group>
</rule>
<rule id="81614" level="10" overwrite="yes">
<if_sid>81603</if_sid>>
<match>ssl-login-fail</match>
<description>Fortigate: SSL VPN user Login failed.</description>
<group>authentication_failed,gdpr_IV_32.2,invalid_login,nist_800_53_AC.7,</group>
</rule>
</group>Wyjaśnienie struktury reguł:
level– określa poziom ważności wyzwolonego alertu (w skali od 0 do 15). Poziom 10 oznacza średni stopień krytyczności, co gwarantuje, że zdarzenie od razu pojawi się w głównych panelu Wazuha z odpowiednio przypisanym priorytetem.overwrite="yes"– informuje Wazuha, że nadpisujemy domyślną, istniejącą już regułę o tym samym ID, zamiast tworzyć nową od zera.if_sid– wskazuje na regułę bazową (w tym przypadku81603, dostarczaną automatycznie out-of-the-box), z której nasza reguła dziedziczy podstawowe dopasowania dekodera dla FortiGate.description– czytelny opis alertu, czyli dokładnie ta wiadomość, którą administrator zobaczy w dashboardzie Wazuha po wyzwoleniu reguły.group– przypisuje alert do konkretnych grup i standardów bezpieczeństwa. Dzięki tagom takim jakgdpr_IV_32.2czynist_800_53_AC.7zdarzenia automatycznie zasilą wbudowane w Wazuha dashboardy zgodności i ułatwią późniejsze filtrowanie pod kątem compliance.
Po dodaniu nowych reguł musimy zrestartować usługę wazuh-manager (lub w interfejsie graficznym kliknąć Save, co w nowszych wersjach platformy wykona soft reload i bezpiecznie przeładuje nowo załadowane reguły).
sudo systemctl restart wazuh-managerJeżeli chcemy przetestować, czy nasze reguły działają prawidłowo, możemy wziąć surowy log, który trafił z FortiGate do Wazuha, i wkleić go w zakładce Server management -> Ruleset Test. Tester reguł od razu pokaże nam, jaki dekoder został użyty dla naszego logu oraz w którą dokładnie regułę wpadło analizowane zdarzenie.
Jeżeli używacie urządzeń innych producentów, dla których Wazuh nie ma wbudowanych reguł, a nie chcecie tworzyć ich od zera, zazwyczaj wystarczy szybkie wyszukanie w Google. Wazuh ma bardzo prężnie działającą społeczność i z pewnością ktoś przed Wami stworzył już dla tych urządzeń odpowiedni zestaw reguł i udostępnił go np. na GitHubie.
Możecie też dołączyć do oficjalnego kanału Slack Wazuh Community i poprosić o wsparcie, na pewno znajdzie się ktoś, kto chętnie podzieli się swoimi regułami lub pomoże Wam w ich prawidłowym skonstruowaniu. Link do kanału możecie znaleźć TUTAJ.
Detekcja ataków w praktyce: Wykrywanie brute-force na SSL-VPN
Kiedy mamy już skonfigurowane przesyłanie logów z urządzenia FortiGate do naszej platformy Wazuh oraz wdrożone odpowiednie reguły wykrywania zagrożeń, możemy przejść do testów integracji. Zrobimy to na przykładzie wykrywania nieudanych logowań do panelu administracyjnego oraz usługi SSL-VPN wystawionej do świata.
⚠️ Ważna uwaga dotycząca bezpieczeństwa oraz kontekstu prezentowanych danych: Poniższe zrzuty ekranu, które Wam zademonstruję, pochodzą z realnej infrastruktury produkcyjnej, znajdującej się pod ciągłym ostrzałem botnetów. Na potrzeby testów celowo wystawiliśmy na świat panel administracyjny jednego z urządzeń (które zostało całkowicie odizolowane od reszty naszej infrastruktury), aby dokładnie przeanalizować skalę, częstotliwość oraz adresy IP, z których nadchodzą ataki.
Pamiętajcie jednak o kluczowej zasadzie: o ile usługa SSL-VPN wystawiona na świat to standard (w końcu chcemy, aby nasi pracownicy mogli bezpiecznie łączyć się z firmą z dowolnego miejsca), o tyle panel administracyjny HTTPS nigdy nie powinien być dostępny bezpośrednio z internetu w środowisku produkcyjnym!
Globalne botnety bez przerwy skanują publiczne adresy i automatycznie próbują przejąć nad nimi kontrolę. Co gorsza, urządzenia FortiGate regularnie borykają się z krytycznymi podatnościami (które w realiach biznesowych nie zawsze są łatane natychmiast), wystawienie interfejsu zarządzania na świat w środowisku firmowym to bezpośrednie proszenie się o poważny incydent bezpieczeństwa.
Wykrycie 3 prób nieudanego zalogowania do panelu zarządzania
Po wykryciu serii nieudanych prób logowania (i automatycznym zablokowaniu atakującego przez mechanizmy obronne FortiGate’a), natychmiast otrzymamy odpowiednie powiadomienie w panelu Wazuha.
Każdy alert możemy oczywiście rozwinąć, aby dokładnie zapoznać się ze wszystkimi informacjami wyciągniętymi ze zdarzenia. Oprócz pełnej, surowej treści logu znajdziemy tam m.in. adres IP, z którego nadszedł atak. Dzięki temu możemy precyzyjnie określić, z jakich krajów pochodzi ruch generowany przez atakujących, lub użyć tego adresu jako filtru w widoku Discover, aby sprawdzić, czy dany agresor nie wykonuje innych podejrzanych działań w pozostałych obszarach naszej infrastruktury.
Możemy również odpowiednio zareagować i dodać wykryty adres IP do czarnej listy (blocklisty) bezpośrednio na naszym firewallu. W praktyce jest to jednak często walka z wiatrakami, botnety nieustannie rotują swoimi adresami. O wiele skuteczniejszym rozwiązaniem jest wykorzystanie zebranych informacji do zablokowania na FortiGate całego obszaru geograficznego (kraju lub regionu), z którego napływają ataki.
Wykrywanie nieudanych prób logowania do SSL-VPN
Po wykryciu próby zalogowania się do usługi SSL-VPN przy użyciu nazwy nieistniejącego użytkownika, natychmiast otrzymamy o tym powiadomienie w panelu Wazuha.
Tak jak poprzednio, każdy alert możemy oczywiście rozwinąć, aby wyświetlić szczegółowe informacje o zdarzeniu. Zebrane w ten sposób metadane stanowią doskonałą podstawę, którą możemy później bezpośrednio wykorzystać w procesie obsługi incydentów.
Widok Threat Hunting
Dzięki temu, że do naszych reguł zostały przypisane odpowiednie grupy, są sie automatycznie agregowane we wbudowanym widoku Threat Hunting w systemie Wazuh. W tym miejscu, za pomocą czytelnych wizualizacji graficznych, możemy wygodnie przeanalizować, jak dokładnie rozkładają się nasze alerty związane z zagrożeniami. Mamy tu również niezwykle przejrzyste podsumowanie liczników udanych oraz nieudanych prób logowania do naszych systemów.
Klikając bezpośrednio na wykresie w sekcję Authentication failure, możemy od razu zaaplikować odpowiedni filtr, a następnie przejść do zakładki Events, aby przeanalizować wszystkie nieudane próby logowania. Z tego poziomu (wybierając ikonę lupy) zyskujemy możliwość szczegółowego prześwietlenia każdego konkretnego zdarzenia.
Zgodność z wymogami regulacyjnymi i prawnymi
Dzięki odpowiednim grupom przypisanym do naszych reguł, generowane alerty są automatycznie mapowane pod kątem konkretnych wymogów zgodności z normami prawnymi, takimi jak m.in. RODO (GDPR). W rezultacie, zaglądając do dedykowanego panelu poświęconego danej normie w systemie Wazuh, możemy od razu sprawdzić, do których artykułów oraz sekcji regulacji zostały przypisane nasze zdarzenia.
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.