Wykrywanie włamań na Linux z Wazuh i Suricata — HIDS, NIDS i automatyczna odpowiedź na zagrożenia

Wprowadzenie — po audycie czas na wykrywanie w czasie rzeczywistym

Przez ostatnie sześć artykułów z naszej serii o hartowaniu Linuksa przeszliśmy całkiem sporo: zabezpieczenie jądra (sysctl, Seccomp, Landlock), hartowanie SSH (OpenSSH 10, kryptografia postkwantowa, FIDO2), konfigurację zapory sieciowej (nftables), kontrolę dostępu MAC (SELinux, AppArmor), bezpieczeństwo kontenerów Docker (rootless, Seccomp, CIS) i wreszcie audyt i skanowanie podatności (Lynis, OpenVAS, OpenSCAP). To wszystko działa prewencyjnie — utrudnia życie atakującemu. Ale co, jeśli ktoś mimo wszystko znajdzie lukę?

No właśnie. Tu wchodzi system wykrywania włamań (IDS).

IDS to warstwa, która siedzi sobie w tle, monitoruje system i sieć w czasie rzeczywistym i — co najważniejsze — potrafi krzyczeć, gdy dzieje się coś podejrzanego. W tym artykule zbudujemy kompletny stos IDS oparty na dwóch świetnych narzędziach open source: Wazuh 4.14 (HIDS/SIEM/XDR) i Suricata 7 (NIDS/IPS). Przejdziemy przez instalację, konfigurację, integrację, tworzenie własnych reguł i mechanizm automatycznej odpowiedzi. Wszystko krok po kroku, na Ubuntu Server 24.04 LTS.

HIDS kontra NIDS — dlaczego potrzebujesz obu

Zanim zaczniemy grzebać w konfiguracji, warto zrozumieć podstawową różnicę między dwoma podejściami do wykrywania włamań:

• HIDS (Host-based Intrusion Detection System) — działa na poziomie hosta. Monitoruje logi systemowe, integralność plików, wywołania systemowe, konfigurację. Widzi zmiany, które świadczą o kompromitacji maszyny. Przykłady: Wazuh, OSSEC, AIDE.
• NIDS (Network-based Intrusion Detection System) — działa na poziomie sieci. Analizuje ruch sieciowy w czasie rzeczywistym, porównując pakiety z bazą sygnatur znanych ataków. Wyłapuje skanowanie portów, exploity, komunikację z C2, exfiltrację danych. Przykłady: Suricata, Snort, Zeek.

OK, ale czemu potrzebujesz obu? Bo HIDS widzi rzeczy niewidoczne dla NIDS — modyfikacje plików konfiguracyjnych, eskalację uprawnień, podejrzane procesy. Z kolei NIDS łapie ruch sieciowy zanim w ogóle dotrze do hosta — próby exploitów, lateral movement, komunikację z serwerami C&C. Dopiero połączenie tych dwóch daje pełną widoczność: od pakietu sieciowego po zmianę w /etc/shadow.

Mówiąc z własnego doświadczenia — kiedyś miałem sytuację, gdzie NIDS nie złapał niczego (ruch był szyfrowany), ale HIDS natychmiast zauważył zmianę w authorized_keys. Gdybym polegał tylko na jednym z nich, pewnie dowiedziałbym się o problemie znacznie później.

Architektura rozwiązania — Wazuh + Suricata

Nasza docelowa architektura wygląda tak:

• Wazuh Server (Manager + Indexer + Dashboard) — centralny punkt analizy. Zbiera dane od agentów, koreluje zdarzenia, generuje alerty i pokazuje je w panelu webowym. Wersja: 4.14.3 (luty 2026).
• Wazuh Agent — instalowany na każdym monitorowanym hoście. Zbiera logi, monitoruje integralność plików (FIM), wykrywa podatności i przesyła dane do Managera.
• Suricata — uruchomiona na monitorowanym hoście (albo na dedykowanym sensorze). Analizuje ruch sieciowy i zapisuje zdarzenia do pliku eve.json. Wersja: 7.0.14 (marzec 2026).
• Integracja — Agent Wazuh czyta logi Suricaty (eve.json), przesyła je do Managera, a ten dekoduje je wbudowanym dekoderem i generuje alerty widoczne w Dashboard. Proste i eleganckie.

W produkcji Suricata często stoi na dedykowanym sensorze sieciowym (z portem SPAN/mirror), ale tutaj zainstalujemy wszystko na jednym hoście, żeby pokazać pełny proces integracji. Jak będziesz skalować do wielu hostów — wystarczy doinstalować dodatkowych agentów Wazuh i sensory Suricata.

Wymagania sprzętowe i systemowe

Minimalne wymagania dla serwera Wazuh all-in-one (Manager + Indexer + Dashboard):

• CPU: 4 rdzenie (8 zalecane)
• RAM: 8 GB (16 GB zalecane)
• Dysk: 50 GB (100 GB+ zalecane — Indexer potrafi sporo najeść, bo przechowuje wszystkie alerty)
• System: Ubuntu Server 24.04 LTS (lub 22.04 LTS)
• Sieć: statyczny adres IP, dostęp do portów 443 (Dashboard), 1514/TCP (komunikacja agent-server), 1515/TCP (rejestracja agentów)

Suricata na tym samym hoście dokłada stosunkowo niewiele (~500 MB RAM przy średnim ruchu), ale jeśli masz naprawdę duży przepływ danych (powyżej 1 Gbps), lepiej wydzielić osobną maszynę.

Instalacja Wazuh 4.14 — serwer all-in-one

Wazuh dostarcza oficjalny skrypt instalacyjny, który automatycznie wdraża wszystkie trzy komponenty na jednym hoście. Nie trzeba się męczyć z ręczną konfiguracją — przynajmniej na start. Zaczynamy od przygotowania systemu:

# Aktualizacja systemu
sudo apt update && sudo apt upgrade -y

# Konfiguracja firewalla
sudo ufw allow 443/tcp    # Dashboard (panel webowy)
sudo ufw allow 1514/tcp   # Komunikacja agent-server
sudo ufw allow 1515/tcp   # Rejestracja agentów
sudo ufw reload

# Pobranie i uruchomienie instalatora Wazuh
curl -sO https://packages.wazuh.com/4.14/wazuh-install.sh
sudo bash ./wazuh-install.sh -a

Skrypt zrobi za nas całą robotę — zainstaluje i skonfiguruje wszystkie komponenty. Po zakończeniu wyświetli dane logowania do panelu Dashboard. Zapisz je od razu! Domyślny użytkownik to admin, a hasło jest generowane losowo (i uwierzcie mi, nie chcecie go szukać potem w logach).

Sprawdźmy, czy wszystko ruszyło:

# Sprawdzenie statusu komponentów
sudo systemctl status wazuh-manager
sudo systemctl status wazuh-indexer
sudo systemctl status wazuh-dashboard

# Weryfikacja nasłuchiwanych portów
sudo ss -tlnp | grep -E ':(443|1514|1515)\s'

Jeśli wszystko poszło dobrze, panel Wazuh Dashboard jest dostępny pod adresem https://<IP-SERWERA>:443.

Instalacja Wazuh Agent na monitorowanym hoście

Jeśli monitorujesz osobny serwer (nie ten, na którym stoi Manager), musisz zainstalować na nim agenta:

# Dodanie repozytorium Wazuh
curl -s https://packages.wazuh.com/key/GPG-KEY-WAZUH | gpg --no-default-keyring \
  --keyring gnupg-ring:/usr/share/keyrings/wazuh.gpg --import && \
  chmod 644 /usr/share/keyrings/wazuh.gpg

echo "deb [signed-by=/usr/share/keyrings/wazuh.gpg] https://packages.wazuh.com/4.x/apt/ stable main" | \
  sudo tee /etc/apt/sources.list.d/wazuh.list

sudo apt update

# Instalacja agenta z podaniem adresu Managera
sudo WAZUH_MANAGER="192.168.1.100" apt install wazuh-agent -y

# Uruchomienie i włączenie agenta
sudo systemctl daemon-reload
sudo systemctl enable wazuh-agent
sudo systemctl start wazuh-agent

Oczywiście zamień 192.168.1.100 na adres IP swojego serwera Wazuh. Po kilku sekundach agent powinien pojawić się w panelu Dashboard w sekcji Agents. Jeśli się nie pojawia — sprawdź, czy firewall nie blokuje portu 1514.

Instalacja i konfiguracja Suricata 7

Suricatę instalujemy na monitorowanym hoście — tam, gdzie chcemy podglądać ruch sieciowy.

Instalacja Suricata

# Dodanie oficjalnego PPA
sudo add-apt-repository ppa:oisf/suricata-stable -y
sudo apt update

# Instalacja Suricata
sudo apt install suricata -y

# Weryfikacja wersji
suricata --build-info | head -5

Identyfikacja interfejsu sieciowego

# Sprawdzenie aktywnego interfejsu
ip -brief addr show | grep UP

Zanotuj nazwę interfejsu (np. eth0, ens18, enp0s3) — za chwilę będzie potrzebna w konfiguracji.

Konfiguracja suricata.yaml

Główny plik konfiguracyjny Suricaty to /etc/suricata/suricata.yaml. Jest dość obszerny, ale kluczowe sekcje do dostosowania to tak naprawdę tylko kilka:

sudo nano /etc/suricata/suricata.yaml

Zmodyfikuj te parametry:

# 1. Zdefiniuj sieć wewnętrzną (HOME_NET)
vars:
  address-groups:
    HOME_NET: "[192.168.1.0/24,10.0.0.0/8]"
    EXTERNAL_NET: "!$HOME_NET"

# 2. Włącz logowanie EVE JSON (domyślnie włączone)
outputs:
  - eve-log:
      enabled: yes
      filetype: regular
      filename: eve.json
      types:
        - alert:
            payload: yes
            payload-printable: yes
            packet: yes
        - dns
        - tls
        - files
        - ssh
        - flow

# 3. Ustaw interfejs sieciowy
af-packet:
  - interface: eth0   # Zmień na swój interfejs
    cluster-id: 99
    cluster-type: cluster_flow
    defrag: yes

Pobranie reguł Emerging Threats

Suricata korzysta z zestawów reguł (sygnatur) do identyfikacji zagrożeń. Najpopularniejszy darmowy zestaw to Emerging Threats Open i szczerze mówiąc, na początek w zupełności wystarczy:

# Aktualizacja reguł za pomocą suricata-update
sudo suricata-update

# Sprawdzenie liczby załadowanych reguł
sudo suricata-update list-sources
sudo grep -c "^alert" /var/lib/suricata/rules/suricata.rules

Komenda suricata-update automatycznie pobiera i instaluje najnowsze reguły ET Open. W produkcji warto wrzucić ją do crona i uruchamiać codziennie:

# Automatyczna codzienna aktualizacja reguł
echo "15 3 * * * root suricata-update && systemctl reload suricata" | \
  sudo tee /etc/cron.d/suricata-rules-update

Wyłączenie offloadingu karty sieciowej

To jest taki krok, o którym łatwo zapomnieć, a potrafi napsuć sporo krwi. Offloading (GRO, LRO, TSO) powoduje, że Suricata widzi połączone, duże pakiety zamiast pojedynczych — co drastycznie zmniejsza skuteczność detekcji:

# Wyłączenie offloadingu (zamień eth0 na swój interfejs)
sudo ethtool -K eth0 gro off lro off tso off

# Aby zmiana była trwała, dodaj do /etc/network/interfaces lub networkd
# Lub utwórz usługę systemd:
sudo tee /etc/systemd/system/suricata-offload.service <<EOF
[Unit]
Description=Disable NIC offloading for Suricata
After=network.target

[Service]
Type=oneshot
ExecStart=/usr/sbin/ethtool -K eth0 gro off lro off tso off
RemainAfterExit=yes

[Install]
WantedBy=multi-user.target
EOF

sudo systemctl enable suricata-offload.service

Uruchomienie Suricata

# Test konfiguracji
sudo suricata -T -c /etc/suricata/suricata.yaml

# Uruchomienie usługi
sudo systemctl enable suricata
sudo systemctl start suricata

# Weryfikacja
sudo systemctl status suricata
sudo tail -f /var/log/suricata/eve.json | head -20

Integracja Suricata z Wazuh — połączenie NIDS i HIDS

Teraz najciekawszy moment: podłączymy Suricatę do Wazuh. Cały pomysł polega na tym, że agent Wazuh odczytuje logi Suricaty i przesyła je do Managera. Edytuj plik konfiguracyjny agenta:

sudo nano /var/ossec/etc/ossec.conf

Dodaj poniższy blok gdzieś wewnątrz sekcji <ossec_config>:

<!-- Integracja Suricata -->
<localfile>
  <log_format>json</log_format>
  <location>/var/log/suricata/eve.json</location>
</localfile>

Restart agenta:

sudo systemctl restart wazuh-agent

I to w zasadzie tyle. Od tego momentu Wazuh automatycznie parsuje zdarzenia Suricaty swoim wbudowanym dekoderem. Alerty pojawiają się w Dashboard w sekcji Security Events z tagiem suricata. Bez żadnej dodatkowej konfiguracji po stronie serwera — to jest naprawdę dobrze zaprojektowane.

Weryfikacja integracji

Wygenerujmy testowy alert, żeby mieć pewność, że wszystko gra. Z innej maszyny w sieci odpal skanowanie portów:

# Z maszyny atakującej (inny host w sieci)
nmap -sS -p 1-1000 192.168.1.200

W ciągu kilku sekund w panelu Wazuh Dashboard powinien wyskoczyć alert Suricata typu ET SCAN. Można to też sprawdzić z linii poleceń:

# Na serwerze Wazuh — wyszukanie alertów Suricata
sudo cat /var/ossec/logs/alerts/alerts.json | \
  python3 -m json.tool | grep -A5 "suricata"

Monitorowanie integralności plików (FIM) z eBPF

Jedna z najfajniejszych funkcji Wazuh to File Integrity Monitoring (FIM) — mechanizm wykrywający modyfikacje krytycznych plików systemowych. Od wersji 4.12 Wazuh obsługuje eBPF jako backend FIM, co daje wykrywanie zmian w czasie rzeczywistym bez zależności od auditd. (A kto pracował z auditd, ten wie, że to bywa... kapryśne.)

Domyślna konfiguracja FIM w /var/ossec/etc/ossec.conf monitoruje podstawowe katalogi. Rozszerzmy ją:

<syscheck>
  <disabled>no</disabled>
  <frequency>300</frequency>
  <scan_on_start>yes</scan_on_start>

  <!-- Katalogi krytyczne -->
  <directories realtime="yes" check_sha256sum="yes">/etc</directories>
  <directories realtime="yes" check_sha256sum="yes">/usr/bin</directories>
  <directories realtime="yes" check_sha256sum="yes">/usr/sbin</directories>
  <directories realtime="yes" check_sha256sum="yes">/boot</directories>
  <directories realtime="yes" check_sha256sum="yes">/var/ossec/etc</directories>

  <!-- Krytyczne pliki pojedyncze -->
  <directories realtime="yes" check_sha256sum="yes">/etc/passwd</directories>
  <directories realtime="yes" check_sha256sum="yes">/etc/shadow</directories>
  <directories realtime="yes" check_sha256sum="yes">/etc/sudoers</directories>
  <directories realtime="yes" check_sha256sum="yes">/etc/ssh/sshd_config</directories>

  <!-- Ignorowanie katalogow o duzej zmiennosci -->
  <ignore>/etc/mtab</ignore>
  <ignore>/etc/resolv.conf</ignore>
  <ignore type="sregex">^/etc/.*\.swp$</ignore>
</syscheck>

Atrybut realtime="yes" włącza monitorowanie ciągłe — z eBPF (jeśli jądro obsługuje) lub inotify jako fallback. Co ważne, Wazuh potrafi też zidentyfikować który użytkownik i który proces dokonał modyfikacji. Przy analizie incydentów to jest absolutnie bezcenne.

Tworzenie własnych reguł Wazuh dla alertów Suricata

Wbudowane reguły Wazuh dla Suricata (grupa suricata, ID 86601–86604) obsługują podstawowe scenariusze, ale w produkcji to trochę za mało. Warto tworzyć własne reguły dopasowane do specyfiki swojej infrastruktury.

Przykład 1: Reguła dla wykrycia skanowania portów

Własne reguły dodajemy w pliku /var/ossec/etc/rules/local_rules.xml na serwerze Wazuh:

<group name="suricata-custom,">

  <!-- Alert o wysokim priorytecie dla skanowania portow -->
  <rule id="100100" level="10">
    <if_sid>86601</if_sid>
    <match>ET SCAN</match>
    <description>Suricata: wykryto skanowanie portow - $(src_ip) -> $(dst_ip)</description>
    <group>ids,nids,scan,</group>
  </rule>

  <!-- Alert krytyczny dla wykrycia exploita -->
  <rule id="100101" level="14">
    <if_sid>86601</if_sid>
    <match>ET EXPLOIT</match>
    <description>Suricata KRYTYCZNY: wykryto probe exploita - $(src_ip)</description>
    <group>ids,nids,exploit,</group>
  </rule>

  <!-- Alert dla komunikacji C2 -->
  <rule id="100102" level="15">
    <if_sid>86601</if_sid>
    <match>ET MALWARE</match>
    <description>Suricata KRYTYCZNY: wykryto komunikacje z malware/C2 - $(src_ip)</description>
    <group>ids,nids,malware,</group>
  </rule>

  <!-- Korelacja: wielokrotne alerty Suricata z jednego IP -->
  <rule id="100103" level="12" frequency="5" timeframe="120">
    <if_matched_sid>86601</if_matched_sid>
    <same_source_ip/>
    <description>Suricata: wielokrotne alerty z jednego IP $(src_ip) w ciagu 2 minut</description>
    <group>ids,nids,correlation,</group>
  </rule>

</group>

Po dodaniu reguł — restart Managera:

sudo systemctl restart wazuh-manager

Automatyczna odpowiedź na zagrożenia — Active Response

A teraz moja ulubiona część. Kluczową przewagą Wazuh jest moduł Active Response, który potrafi automatycznie reagować na wykryte zagrożenia. Najczęściej stosowana odpowiedź to firewall-drop — automatyczne blokowanie źródłowego IP za pomocą iptables/nftables. Działa to zaskakująco dobrze.

Konfiguracja Active Response na serwerze Wazuh

Edytuj /var/ossec/etc/ossec.conf na serwerze Wazuh Manager:

<!-- Definicja komendy firewall-drop -->
<command>
  <name>firewall-drop</name>
  <executable>firewall-drop</executable>
  <timeout_allowed>yes</timeout_allowed>
</command>

<!-- Active Response: blokowanie IP po wykryciu exploita -->
<active-response>
  <command>firewall-drop</command>
  <location>local</location>
  <rules_id>100101,100102</rules_id>
  <timeout>1800</timeout>
</active-response>

<!-- Active Response: blokowanie IP po wielokrotnych alertach -->
<active-response>
  <command>firewall-drop</command>
  <location>local</location>
  <rules_id>100103</rules_id>
  <timeout>3600</timeout>
</active-response>

Co tu się dzieje:

• rules_id 100101, 100102 — próby exploitów i komunikacja z malware powodują natychmiastowe zablokowanie IP na 30 minut.
• rules_id 100103 — wielokrotne alerty z jednego IP to blokada na 1 godzinę.
• location: local — blokada dzieje się na hoście, na którym wykryto zagrożenie.
• timeout — po upływie czasu blokada jest automatycznie zdejmowana (co jest ważne, bo nie chcesz permanentnie blokować IP, które mogło być spoofowane).

Restart Managera po zmianach:

sudo systemctl restart wazuh-manager

Weryfikacja Active Response

Przetestujmy, czy to naprawdę działa. Z innej maszyny:

# Z maszyny atakujacej — szybkie skanowanie SYN
nmap -sS -T4 -p 1-10000 192.168.1.200

A na monitorowanym hoście sprawdzamy:

# Sprawdzenie logów Active Response
sudo tail -f /var/ossec/logs/active-responses.log

# Sprawdzenie zablokowanych IP w iptables
sudo iptables -L INPUT -n --line-numbers | grep DROP

Tworzenie własnych reguł Suricata

Oprócz reguł ET Open możesz (i powinieneś) tworzyć własne reguły Suricata dopasowane do swojej infrastruktury. Utwórz plik na reguły lokalne:

sudo nano /etc/suricata/rules/local.rules

Kilka przykładowych reguł na dobry początek:

# Wykrycie proby logowania SSH z nietypowego portu zrodlowego
alert tcp $EXTERNAL_NET any -> $HOME_NET 22 (msg:"LOCAL - SSH connection from external network"; \
  flow:to_server,established; \
  sid:1000001; rev:1; classtype:policy-violation;)

# Wykrycie zapytania DNS do podejrzanej domeny (przyklad: mining pool)
alert dns $HOME_NET any -> any any (msg:"LOCAL - DNS query to known mining pool"; \
  dns.query; content:"pool.minergate.com"; nocase; \
  sid:1000002; rev:1; classtype:trojan-activity;)

# Wykrycie ruchu wychodzacego na porcie 4444 (typowy dla reverse shell)
alert tcp $HOME_NET any -> $EXTERNAL_NET 4444 (msg:"LOCAL - Outbound connection on port 4444 (possible reverse shell)"; \
  flow:to_server,established; \
  sid:1000003; rev:1; classtype:trojan-activity;)

# Wykrycie duzego transferu danych wychodzacych (potencjalna exfiltracja)
alert tcp $HOME_NET any -> $EXTERNAL_NET any (msg:"LOCAL - Large outbound data transfer detected"; \
  flow:to_server,established; \
  dsize:>50000; \
  sid:1000004; rev:1; classtype:policy-violation;)

Dodaj plik do konfiguracji Suricata i przeładuj:

# Dodanie pliku regul do suricata.yaml
# W sekcji rule-files dodaj:
#   - /etc/suricata/rules/local.rules

# Przeladowanie Suricata (bez restartu — zachowuje sesje)
sudo suricatasc -c reload-rules

Tuning produkcyjny — redukcja false positives

W środowisku produkcyjnym (no i tu zaczyna się prawdziwa zabawa) największym wyzwaniem jest szum alertów. Alert fatigue to realna rzecz — jeśli system generuje setki fałszywych alarmów dziennie, ludzie zaczynają je ignorować, i wtedy prawdziwy atak przechodzi niezauważony.

Suricata — wyłączanie szumnych reguł

# Sprawdzenie najczestszych alertow (top 20)
sudo cat /var/log/suricata/eve.json | \
  python3 -c "
import json, sys, collections
sids = collections.Counter()
for line in sys.stdin:
    try:
        e = json.loads(line)
        if e.get('event_type') == 'alert':
            sids[e['alert']['signature_id']] += 1
    except: pass
for sid, count in sids.most_common(20):
    print(f'SID {sid}: {count} alertow')
"

# Wylaczenie szumnych regul w suricata-update
echo "1:2210059" | sudo tee -a /etc/suricata/disable.conf
echo "1:2013504" | sudo tee -a /etc/suricata/disable.conf
sudo suricata-update
sudo suricatasc -c reload-rules

Wazuh — filtrowanie alertów o niskim priorytecie

<!-- W /var/ossec/etc/rules/local_rules.xml -->
<!-- Wyciszenie szumnych alertow Suricata (level 0 = brak alertu) -->
<rule id="100110" level="0">
  <if_sid>86601</if_sid>
  <match>ET INFO</match>
  <description>Suricata: wyciszony alert informacyjny</description>
</rule>

Białe listy IP

Adresy IP znanych skanerów bezpieczeństwa, systemów monitoringu i zaufanych sieci trzeba dodać do białej listy Wazuh. W przeciwnym razie Active Response może zablokować wasz własny Nessus w połowie skanu (tak, zdarzyło mi się to):

<!-- W /var/ossec/etc/ossec.conf na serwerze Manager -->
<global>
  <white_list>10.0.0.0/8</white_list>
  <white_list>192.168.1.50</white_list>  <!-- Skaner Nessus -->
  <white_list>192.168.1.51</white_list>  <!-- System monitoringu -->
</global>

Dashboard i wizualizacja — co monitorować na co dzień

Po wdrożeniu kompletnego stosu IDS, panel Wazuh Dashboard staje się twoim centralnym punktem monitorowania. Oto widoki, na które warto zaglądać codziennie (albo przynajmniej regularnie):

• Security Events — przegląd wszystkich alertów (HIDS + NIDS) z filtrowaniem po poziomie, źródle, regule.
• Integrity Monitoring — zmiany w plikach krytycznych. Kto, co, kiedy zmienił.
• Vulnerability Detection — wykryte podatności na monitorowanych hostach z linkami do CVE.
• Threat Hunting — zaawansowane wyszukiwanie w danych historycznych.
• Active Responses — dziennik automatycznych reakcji (zablokowane IP, wykonane komendy).

Warto też skonfigurować powiadomienia e-mail albo integrację z komunikatorami (Slack, Teams) dla alertów poziomu 10 i wyżej. Bo co z tego, że system wykryje atak o 3 w nocy, jeśli nikt tego nie zobaczy do rana?

<!-- Konfiguracja e-mail w ossec.conf -->
<global>
  <email_notification>yes</email_notification>
  <smtp_server>smtp.example.com</smtp_server>
  <email_from>[email protected]</email_from>
  <email_to>[email protected]</email_to>
  <email_maxperhour>12</email_maxperhour>
</global>

<email_alerts>
  <email_to>[email protected]</email_to>
  <level>10</level>
  <do_not_delay/>
</email_alerts>

Najlepsze praktyki wdrożeniowe

Parę rzeczy, które warto wiedzieć zanim puścisz to na produkcję. Część z tych lekcji nauczyłem się na własnych błędach:

1. Zaczynaj w trybie detekcji, nie prewencji — przez pierwsze 2-4 tygodnie uruchom Suricata w trybie IDS (nie IPS). Pozwoli to zebrać baseline ruchu i wyłapać false positives zanim włączysz aktywne blokowanie. Serio, nie pomijaj tego kroku.
2. Aktualizuj reguły codziennie — nowe sygnatury w ET Open pojawiają się kilka razy dziennie. Cron jest twoim przyjacielem.
3. Monitoruj wydajność Suricata — sprawdzaj statystyki dropped packets: sudo suricatasc -c dump-counters | grep capture.kernel_drops. Jeśli masz powyżej 1%, to sygnał, że Suricata nie nadąża z analizą ruchu i pora pomyśleć o optymalizacji (więcej wątków, szybszy dysk, dedykowana maszyna).
4. Separuj ruch zarządzania od monitoringu — używaj osobnych interfejsów sieciowych dla komunikacji agent-manager i dla przechwytywania ruchu. Mieszanie tych dwóch to proszenie się o kłopoty.
5. Regularnie przeglądaj alerty — sam system IDS nie zapewnia bezpieczeństwa. Bez regularnej analizy przez człowieka nawet najlepszy stos narzędzi jest bezużyteczny. To nie jest kwestia techniczna, to kwestia procesu.
6. Dokumentuj wyjątki — każda reguła dodana do disable.conf i każdy wpis na białej liście powinny mieć datę i uzasadnienie. Za pół roku nie będziesz pamiętał, dlaczego wyłączyłeś daną regułę.
7. Testuj regularnie — przeprowadzaj kontrolowane testy penetracyjne, żeby sprawdzić, czy system faktycznie wykrywa i reaguje na realne ataki. Teoria to jedno, praktyka to drugie.

Podsumowanie

Wdrożenie stosu Wazuh + Suricata to naturalny kolejny krok po hartowaniu systemu i audycie bezpieczeństwa. Połączenie HIDS (monitorowanie hosta) i NIDS (monitorowanie sieci) daje naprawdę solidną widoczność — od pakietu sieciowego po zmianę w pliku konfiguracyjnym. A mechanizm Active Response zamienia pasywną detekcję w aktywną obronę, automatycznie blokując źródła ataków.

Ale pamiętaj: IDS to nie „ustaw i zapomnij".

To żywy element infrastruktury bezpieczeństwa, który wymaga ciągłego tuningu, aktualizacji reguł i regularnej analizy alertów. Inwestycja się jednak opłaca — w erze, gdy średni czas od włamania do wykrycia (dwell time) wynosi ponad 200 dni, każda minuta szybszej detekcji ma realne znaczenie. Dosłownie każda.

W kolejnym artykule zajmiemy się bezpieczeństwem pipeline'ów CI/CD i praktykami DevSecOps — bo hartowanie infrastruktury to dopiero połowa sukcesu. Druga połowa to zabezpieczenie procesu, który tę infrastrukturę tworzy i aktualizuje. Do zobaczenia.

FAQ — najczęściej zadawane pytania

Czym różni się Wazuh od OSSEC?

Wazuh zaczął jako fork OSSEC, ale od tamtego czasu uszedł naprawdę daleko. Dziś to pełna platforma SIEM/XDR z wbudowanym panelem Dashboard, natywną integracją z Elasticsearch/OpenSearch (Wazuh Indexer), modułem wykrywania podatności, wsparciem eBPF w FIM, integracją z CTI (Cyber Threat Intelligence) i aktywnie rozwijanym Active Response. OSSEC nadal działa i jest prostszym narzędziem HIDS — ale jeśli potrzebujesz czegoś więcej niż podstawowy monitoring hosta, Wazuh jest po prostu lepszym wyborem.

Czy Suricata może działać jako IPS (system zapobiegania włamaniom)?

Tak, jak najbardziej. W trybie IPS Suricata aktywnie blokuje ruch pasujący do reguł, zamiast tylko o nim informować. Działa wtedy inline — cały ruch przechodzi przez nią, a pakiety pasujące do reguł typu drop lub reject są blokowane w czasie rzeczywistym. Wymaga to konfiguracji af-packet z opcją copy-mode: ips i dwóch interfejsów sieciowych (lub NFQueue). Ale — i mówię to z naciskiem — najpierw przetestuj konfigurację w trybie IDS. Blokowanie prawidłowego ruchu produkcyjnego to nie jest sytuacja, w której chcesz się znaleźć.

Ile zasobów potrzebuje Wazuh w środowisku produkcyjnym?

To zależy od liczby agentów. Dla do 25 agentów: 4 CPU, 8 GB RAM, 50 GB dysku. Dla 25–100 agentów: 8 CPU, 16 GB RAM, 200 GB dysku. Ponad 100 agentów? Wtedy warto rozdzielić komponenty (Manager, Indexer, Dashboard) na osobne serwery. Największym pożeraczem zasobów jest Wazuh Indexer (w gruncie rzeczy to Elasticsearch pod maską), który przechowuje wszystkie alerty. Regularna rotacja indeksów i sensowna polityka retencji danych to absolutna konieczność.

Jak zintegrować Wazuh z istniejącym stosem nftables?

Domyślnie Active Response używa iptables do blokowania IP. Jeśli twój system korzysta z nftables (jak opisywaliśmy w artykule o hartowaniu firewalla), trzeba trochę pogrzebać w skryptach. Utwórz dedykowaną tabelę i zbiór nftables (nft add table inet wazuh-blocked, nft add set inet wazuh-blocked blocklist { type ipv4_addr\; flags timeout\; }) i zmodyfikuj skrypt /var/ossec/active-response/bin/firewall-drop, żeby używał nft add element zamiast iptables -I. Dzięki temu automatyczne blokowanie będzie spójne z resztą konfiguracji firewalla. To trochę pracy, ale warto.

Czy mogę uruchomić Suricata w kontenerze Docker?

Można, ale z pewnymi zastrzeżeniami. Suricata w kontenerze potrzebuje dostępu do interfejsu sieciowego hosta (tryb --network host) i uprawnień NET_ADMIN oraz NET_RAW. Jest oficjalny obraz jasonish/suricata na Docker Hub, więc deployment jest prosty. Natomiast tryb IPS inline jest trudniejszy do ogarnięcia w kontenerze, a wydajność przechwytywania pakietów może być niższa niż przy instalacji natywnej. Na potrzeby testów i mniejszych środowisk — jasne, czemu nie. Ale w produkcji z poważnym ruchem sieciowym? Lepiej instalacja natywna.