Wazuh 4.14 Linuxissa: Opas SIEM/XDR-alustan asentamiseen ja tunkeutumisen havaitsemiseen

Johdanto: Koventaminen ei riitä — tarvitset myös havaitsemisen

Olet koventanut SSH-palvelimen, rakentanut nftables-palomuurin ja ottanut SELinuxin käyttöön pakottavassa tilassa. Hienoa — olet jo pitkällä. Mutta entä jos joku silti pääsee sisään? Tai entä jos laillinen käyttäjä muuttaa kriittistä konfiguraatiotiedostoa vahingossa?

Ilman aktiivista valvontajärjestelmää et tiedä siitä mitään. Ainakaan ennen kuin on liian myöhäistä.

Tietoturvan todellisuus vuonna 2026 on rehellisesti sanottuna aika karu: pelkkä ennaltaehkäisy ei riitä. Tarvitset havaitsemisen (detection), reagoinnin (response) ja jatkuvan valvonnan (continuous monitoring). Ja juuri tässä kohtaa Wazuh astuu kuvaan.

Wazuh on avoimen lähdekoodin tietoturvaalusta, joka yhdistää SIEM-ominaisuudet (Security Information and Event Management), XDR-kyvykkyydet (Extended Detection and Response), tiedostojen eheyden valvonnan, haavoittuvuuksien tunnistamisen ja vaatimustenmukaisuuden arvioinnin yhdeksi yhtenäiseksi järjestelmäksi. Se on ilmainen, skaalautuva ja tuotantovalmis — mikä on aika hyvä yhdistelmä.

Tässä oppaassa asennamme Wazuh 4.14:n Linux-palvelimelle, otamme käyttöön agentteja, konfiguroimme tiedostojen eheyden valvonnan, rakennamme SSH-hyökkäysten havaitsemisen ja automaattisen reagoinnin sekä suoritamme CIS-vaatimustenmukaisuustarkistuksia. Eli sukelletaan suoraan asiaan.

Wazuhin arkkitehtuuri ja komponentit

Kolme keskeistä komponenttia

Wazuh koostuu kolmesta pääkomponentista, jotka toimivat yhdessä muodostaen kattavan tietoturvavalvonnan:

• Wazuh Server (Manager) — Keskuspalvelin, joka vastaanottaa ja analysoi agenttien lähettämää dataa. Manager sisältää analyysimoottorin, sääntökannan ja aktiivisen reagoinnin moduulin. Filebeat-komponentti välittää hälytykset eteenpäin indeksoijalle.
• Wazuh Indexer — OpenSearch-pohjainen hakumoottori, joka tallentaa hälytykset, tapahtumat ja lokitiedot. Mahdollistaa nopean haun ja pitkäaikaisen säilytyksen.
• Wazuh Dashboard — Web-pohjainen käyttöliittymä, joka visualisoi tietoturvatapahtumat, hälytykset, haavoittuvuudet ja vaatimustenmukaisuuden tilan. Rakennettu OpenSearch Dashboardsin päälle.

Agenttipohjainen malli

Wazuh käyttää kevyitä agentteja, jotka asennetaan valvottaviin päätepisteisiin. Agentit keräävät lokitietoja, valvovat tiedostojärjestelmän eheyttä, suorittavat konfiguraatiotarkistuksia ja lähettävät kaiken datan managerille salatun yhteyden yli (portti 1514/TCP).

Manager käsittelee datan sääntöjoukkoja vastaan ja tuottaa hälytyksiä, jotka indeksoidaan ja visualisoidaan dashboardissa. Käytännössä tämä tarkoittaa, että sinun tarvitsee katsoa vain yhtä käyttöliittymää — vaikka valvottavia koneita olisi kymmeniä tai satoja.

Agentti tukee Linuxia, Windowsia, macOS:ää, Solarista ja BSD:tä, mutta tässä oppaassa keskitymme Linux-ympäristöön.

Järjestelmävaatimukset ja valmistelu

Laitteistovaatimukset (yhden solmun asennus)

Yhden solmun (all-in-one) asennuksessa kaikki kolme komponenttia asennetaan samalle palvelimelle. Tämä sopii pieniin ja keskisuuriin ympäristöihin — ja myös oppimiseen, joten jos vasta tutustut Wazuhiin, tämä on hyvä aloituspiste.

• Prosessori: 64-bittinen x86_64 tai ARM64, vähintään 4 ydintä
• RAM: Vähintään 8 GB (suositus 16 GB)
• Levytila: Vähintään 50 GB SSD-levyä. Levytilan tarve riippuu hälytysmääristä — 80 työasemaa, 10 palvelinta ja 10 verkkolaitetta tuottavat noin 230 GB dataa 90 päivän ajalta.
• Verkko: Staattinen IP-osoite tai resoluutiokelpoinen hostname

Tuetut käyttöjärjestelmät

Wazuh 4.14 tukee seuraavia palvelinkäyttöjärjestelmiä:

• Ubuntu 22.04 LTS ja 24.04 LTS
• Debian 11 ja 12
• Red Hat Enterprise Linux 8 ja 9
• Rocky Linux ja AlmaLinux 8 ja 9

Palomuurisäännöt

Avaa tarvittavat portit ennen asennusta. Jos käytät nftables-palomuuria (kuten aiemmassa oppaassamme käsittelimme), lisää seuraavat säännöt:

# Wazuh Manager — agenttien liikenne
nft add rule inet filter input tcp dport 1514 accept
# Wazuh Manager — rekisteröinti
nft add rule inet filter input tcp dport 1515 accept
# Wazuh Indexer — sisäinen liikenne
nft add rule inet filter input tcp dport 9200 accept
# Wazuh Dashboard — web-käyttöliittymä
nft add rule inet filter input tcp dport 443 accept

Wazuh 4.14:n asentaminen (yhden solmun asennus)

Tapa 1: Automaattinen asennus (suositeltu)

Nopein tapa saada Wazuh käyntiin on käyttää virallista asennusassistenttia. Yksi komento asentaa kaikki kolme komponenttia — ja rehellisesti sanottuna tämä on lähes aina oikea valinta, ellei sinulla ole erityisiä syitä tehdä toisin:

# Lataa ja aja asennusassistentti
curl -sO https://packages.wazuh.com/4.14/wazuh-install.sh
sudo bash ./wazuh-install.sh -a

Asennusassistentti suorittaa seuraavat vaiheet automaattisesti:

1. Tarkistaa järjestelmävaatimukset
2. Generoi TLS-sertifikaatit komponenttien väliseen salaukseen
3. Asentaa ja konfiguroi Wazuh Indexerin
4. Asentaa ja konfiguroi Wazuh Managerin ja Filebeatin
5. Asentaa ja konfiguroi Wazuh Dashboardin

Asennuksen valmistuttua tulosteessa näkyvät kirjautumistiedot:

INFO: --- Summary ---
INFO: You can access the web interface https://:443
    User: admin
    Password: 
INFO: Installation finished.

Tärkeää: Tallenna salasana turvalliseen paikkaan heti asennuksen jälkeen. Olen itse nähnyt tilanteita, joissa salasana on unohtunut ja dashboardiin pääsy on vaatinut turhaa säätämistä. Voit myöhemmin vaihtaa sen dashboardin kautta.

Tapa 2: Vaiheittainen asennus

Jos tarvitset enemmän kontrollia asennusprosessiin, voit asentaa komponentit erikseen. Tämä on suositeltavaa tuotantoympäristöissä, joissa komponentit hajautetaan eri palvelimille.

Vaihe 1: Sertifikaattien luominen

# Lataa sertifikaattityökalu ja konfiguraatiotiedosto
curl -sO https://packages.wazuh.com/4.14/wazuh-certs-tool.sh
curl -sO https://packages.wazuh.com/4.14/config.yml

# Muokkaa config.yml — vaihda IP-osoitteet ja solmujen nimet
# Aja sertifikaattien generointi
bash ./wazuh-certs-tool.sh -A

Vaihe 2: Indexerin asennus

# Lisää Wazuh-repositorio (Debian/Ubuntu)
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" | \
  tee /etc/apt/sources.list.d/wazuh.list

apt-get update
apt-get -y install wazuh-indexer

# RHEL/Rocky/Alma
rpm --import https://packages.wazuh.com/key/GPG-KEY-WAZUH
# Lisää .repo-tiedosto ja asenna wazuh-indexer

Vaihe 3: Managerin ja Filebeatin asennus

# Debian/Ubuntu
apt-get -y install wazuh-manager filebeat

# Käynnistä Manager
systemctl daemon-reload
systemctl enable wazuh-manager
systemctl start wazuh-manager

# Tarkista tila
systemctl status wazuh-manager

Vaihe 4: Dashboardin asennus

apt-get -y install wazuh-dashboard

systemctl daemon-reload
systemctl enable wazuh-dashboard
systemctl start wazuh-dashboard

Asennuksen jälkeiset toimenpiteet

Tämä on yksi niistä asioista, jotka moni jättää tekemättä — ja katuu myöhemmin. Asennuksen jälkeen on suositeltavaa poistaa Wazuh-pakettirepositorio käytöstä, jotta vahingossa tapahtuvat päivitykset eivät riko tuotantoympäristöä:

# Debian/Ubuntu — poista repositorio käytöstä
sed -i 's/^deb/#deb/' /etc/apt/sources.list.d/wazuh.list
apt-get update

# RHEL/Rocky — poista repositorio käytöstä
sed -i 's/^enabled=1/enabled=0/' /etc/yum.repos.d/wazuh.repo

Agenttien käyttöönotto

Linux-agentin asentaminen

Agentit ovat Wazuhin tiedonkeruun ydin. Jokainen valvottava palvelin tai työasema tarvitsee oman agentin, ja onneksi asennus on melko suoraviivainen:

# Debian/Ubuntu
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" | \
  tee /etc/apt/sources.list.d/wazuh.list

apt-get update

# Asenna agentti ja määritä managerin osoite
WAZUH_MANAGER='192.168.1.100' apt-get -y install wazuh-agent

# Käynnistä agentti
systemctl daemon-reload
systemctl enable wazuh-agent
systemctl start wazuh-agent

# RHEL/Rocky/Alma
WAZUH_MANAGER='192.168.1.100' yum -y install wazuh-agent

systemctl daemon-reload
systemctl enable wazuh-agent
systemctl start wazuh-agent

Agentin tilan tarkistaminen

Varmista, että agentti on yhdistänyt manageriin onnistuneesti:

# Agentin puolella
systemctl status wazuh-agent

# Managerin puolella — listaa yhdistetyt agentit
/var/ossec/bin/agent_control -l

# Tuloste:
# ID: 001, Name: webserver01, IP: 192.168.1.50, Status: Active
# ID: 002, Name: dbserver01, IP: 192.168.1.51, Status: Active

Ryhmäpohjainen konfiguraatio

Suurissa ympäristöissä agentteja hallitaan ryhmien kautta. Tämä tekee elämästä huomattavasti helpompaa, koska konfiguraatio periytyy keskitetysti eikä sinun tarvitse muokata jokaista agenttia erikseen:

# Luo ryhmä
/var/ossec/bin/agent_groups -a -g webpalvelimet

# Lisää agentti ryhmään
/var/ossec/bin/agent_groups -a -i 001 -g webpalvelimet

# Ryhmäkohtainen konfiguraatio
# /var/ossec/etc/shared/webpalvelimet/agent.conf

Tiedostojen eheyden valvonta (FIM)

Miksi FIM on kriittinen?

Tiedostojen eheyden valvonta (File Integrity Monitoring, FIM) on mielestäni yksi Wazuhin ehdottomasti tärkeimmistä ominaisuuksista. Se havaitsee, kun kriittisiä järjestelmätiedostoja, konfiguraatioita tai sovellustiedostoja luodaan, muokataan tai poistetaan.

FIM on myös keskeinen vaatimus useissa tietoturvastandardeissa — puhutaan esimerkiksi PCI DSS 11.5:stä, NIST 800-53 SI-7:stä ja GDPR artikla 32:sta. Eli jos vaatimustenmukaisuus on sinulle tärkeä (ja pitäisi olla), FIM on pakollinen työkalu.

FIM:n toimintaperiaate

Wazuhin FIM-moduuli (wazuh-syscheckd) toimii kolmessa tilassa:

• Ajoitettu skannaus — Oletustila, jossa agentti laskee valvottujen tiedostojen tiivisteet (SHA256) ja vertaa niitä perusviivaan säännöllisin väliajoin. Oletuksena tämä tapahtuu 12 tunnin välein.
• Reaaliaikainen valvonta — Käyttää Linuxin inotify-rajapintaa havaitakseen muutokset välittömästi. Paras valinta kriittisille hakemistoille kuten /etc.
• Who-data-tila — Integroituu Linuxin auditd-järjestelmään tai eBPF:ään tunnistaakseen, kuka käyttäjä ja mikä prosessi teki muutoksen. Tarkin tila, mutta vaatii enemmän resursseja.

FIM-konfiguraatio käytännössä

Muokkaa agentin konfiguraatiotiedostoa /var/ossec/etc/ossec.conf ja lisää valvottavat hakemistot <syscheck>-lohkon sisälle:

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

  <!-- Kriittiset järjestelmähakemistot — reaaliaikainen valvonta -->
  <directories check_all="yes" realtime="yes" report_changes="yes">/etc</directories>
  <directories check_all="yes" realtime="yes" report_changes="yes">/usr/bin</directories>
  <directories check_all="yes" realtime="yes" report_changes="yes">/usr/sbin</directories>
  <directories check_all="yes" realtime="yes">/boot</directories>

  <!-- Web-palvelimen sisältö — who-data (kuka muutti?) -->
  <directories check_all="yes" whodata="yes" report_changes="yes">/var/www</directories>

  <!-- Ohita väliaikaiset ja lokitiedostot -->
  <ignore>/etc/mtab</ignore>
  <ignore type="sregex">.log$|.swp$</ignore>

  <!-- Tiedostotyyppirajoitus (valvo vain tiettyjä päätteitä) -->
  <nodiff>/etc/ssl/private</nodiff>
</syscheck>

Parametrien selitykset lyhyesti:

• check_all="yes" — Valvo kaikkia attribuutteja: koko, oikeudet, omistaja, aikaleima ja tiiviste.
• realtime="yes" — Käytä inotify-rajapintaa reaaliaikaiseen valvontaan.
• whodata="yes" — Käytä auditd-integraatiota käyttäjätietojen keräämiseen.
• report_changes="yes" — Tallenna tiedostojen sisältömuutosten diff-tulosteet.

Käynnistä agentti uudelleen muutosten jälkeen:

systemctl restart wazuh-agent

FIM-hälytysten tarkastelu

Kun FIM havaitsee muutoksen, se tuottaa hälytyksen, joka sisältää muutetun tiedoston polun, muutoksen tyypin (lisäys, muokkaus, poisto), vanhat ja uudet attribuutit sekä diff-tulosteet (jos report_changes on käytössä). Dashboardin File Integrity Monitoring -moduulissa näet kaikki tapahtumat kolmessa näkymässä: Inventory, Dashboard ja Events.

SSH-hyökkäysten havaitseminen ja automaattinen reagointi

Sisäänrakennettu SSH-hyökkäystunnistus

Wazuhissa on valmiit säännöt SSH-kirjautumisyritysten valvontaan. Jos olet joskus katsonut SSH-lokeja tuotantopalvelimella, tiedät kuinka paljon brute force -yrityksiä tulee jatkuvasti. Tärkeimmät sääntö-ID:t ovat:

• Sääntö 5551 — Yksittäinen SSH-kirjautumisvirhe (taso 5)
• Sääntö 5712 — SSH brute force -hyökkäys, tuntematon käyttäjä. Laukeaa kahdeksan epäonnistuneen yrityksen jälkeen samasta IP-osoitteesta kahden minuutin sisällä (taso 10)
• Sääntö 5763 — SSH brute force -hyökkäys, olemassa oleva käyttäjä (taso 10)

Sääntö 5712 on komposiittisääntö, joka korreloi useita tapahtumia ajan yli. Se sisältää automaattisesti MITRE ATT&CK -mappauksen (T1110 — Brute Force / Credential Access) ja vaatimustenmukaisuustunnisteet (GDPR, HIPAA, PCI-DSS, NIST 800-53). Aika näppärää.

Aktiivisen reagoinnin konfigurointi

Pelkkä havaitseminen ei riitä — haluamme myös estää hyökkääjän automaattisesti. Wazuhin Active Response -moduuli suorittaa skriptejä valvotuissa päätepisteissä, kun tietty sääntö laukeaa.

Konfiguroi se managerin /var/ossec/etc/ossec.conf-tiedostossa:

<ossec_config>
  <!-- Määrittele komento -->
  <command>
    <name>firewall-drop</name>
    <executable>firewall-drop</executable>
    <timeout_allowed>yes</timeout_allowed>
  </command>

  <!-- Aktiivinen reagointi SSH brute force -hyökkäykseen -->
  <active-response>
    <command>firewall-drop</command>
    <location>local</location>
    <rules_id>5712,5763</rules_id>
    <timeout>600</timeout>
  </active-response>
</ossec_config>

Mitä tämä konfiguraatio käytännössä tekee:

1. Kun sääntö 5712 tai 5763 laukeaa (SSH brute force havaittu)
2. firewall-drop-skripti suoritetaan paikallisesti agentissa, jota hyökättiin
3. Hyökkääjän IP-osoite estetään iptables/nftables-säännöllä
4. Esto poistetaan automaattisesti 600 sekunnin (10 minuutin) jälkeen

Käynnistä manager uudelleen:

systemctl restart wazuh-manager

Aktiivisen reagoinnin testaaminen

Voit testata SSH brute force -tunnistusta turvallisesti toiselta koneelta. Huomaa kuitenkin, että testaaminen kannattaa tehdä vain omassa ympäristössä — älä koskaan kohdista tätä palvelimiin, joihin sinulla ei ole lupaa:

# Testikoneelta — yritä kirjautua väärillä tunnuksilla
for i in $(seq 1 10); do
  ssh olematon_kayttaja@kohdepalvelin 2>/dev/null
done

# Tai käytä Hydraa kontrolloidussa ympäristössä
# HUOM: Käytä VAIN omassa testiympäristössäsi!
hydra -l testuser -P /tmp/sanalistata.txt kohdepalvelin ssh

Tarkista Active Response -loki:

# Agentin puolella
tail -f /var/ossec/logs/active-responses.log

# Tuloste:
# Thu Feb 27 10:15:32 UTC 2026 /var/ossec/active-response/bin/firewall-drop add
# - 203.0.113.50 1740650132.12345 5712

Vaatimustenmukaisuuden arviointi (SCA)

CIS-vertailuarvojen automaattinen tarkistus

Wazuhin Security Configuration Assessment (SCA) -moduuli suorittaa automaattisia konfiguraatiotarkistuksia CIS-vertailuarvojen (Center for Internet Security Benchmarks) perusteella. Se vertaa järjestelmän todellista tilaa suositeltuihin tietoturva-asetuksiin ja raportoi poikkeamat.

Wazuh 4.14 sisältää valmiit SCA-käytännöt muun muassa seuraaville:

• CIS Ubuntu Linux 22.04 LTS ja 24.04 LTS
• CIS Red Hat Enterprise Linux 8 ja 9
• CIS Debian Linux 11 ja 12
• CIS Rocky Linux ja AlmaLinux

SCA-tarkistuksen tasot

CIS-vertailuarvot jakautuvat kahteen tasoon:

• Taso 1 (Level 1) — Perusturvallisuus yleisiin ympäristöihin. Esimerkkeinä käyttämättömien tilien poistaminen, salasanakäytäntöjen vahvistaminen ja tarpeettomien palveluiden sammuttaminen.
• Taso 2 (Level 2) — Edistyneet kontrollit korkean turvallisuuden ympäristöihin. Esimerkiksi täysi levysalaus, audit-lokitus ja tiukennetut ytimen parametrit.

SCA:n tulokset

SCA-tarkistus tuottaa jokaiselle kontrollille yhden neljästä tilasta:

• Pass — Järjestelmän konfiguraatio vastaa CIS-suositusta.
• Fail — Konfiguraatio poikkeaa suosituksesta. Hälytys sisältää nykyisen tilan, odotetun tilan ja korjausohjeet.
• Not applicable — Tarkistus ei koske kyseistä järjestelmää.
• Error — Tarkistus epäonnistui (esim. puuttuvat oikeudet).

Dashboardin Configuration Assessment -moduulissa näet kokonaispistemäärän prosentteina. Tyypillinen oletusasennus saa noin 35–45 %. Joo, se kuulostaa alhaiselta — mutta juuri se osoittaa, miksi koventaminen on niin tärkeää.

Mukautettu SCA-käytäntö

Voit myös kirjoittaa omia SCA-käytäntöjä YAML-muodossa. Tämä on todella hyödyllistä, jos organisaatiollasi on omia sisäisiä standardeja, joita CIS ei kata. Tässä esimerkki käytännöstä, joka tarkistaa SSH-koventamisen:

# /var/ossec/etc/shared/default/custom-ssh-sca.yml
policy:
  id: "custom_ssh_hardening"
  file: "custom-ssh-sca.yml"
  name: "SSH-koventamisen tarkistus"
  description: "Tarkistaa SSH-palvelimen koventamisasetukset"
  references:
    - https://www.cisecurity.org

checks:
  - id: 10001
    title: "SSH root-kirjautuminen on estetty"
    description: "PermitRootLogin pitää olla 'no'"
    rationale: "Root-kirjautuminen SSH:n kautta lisää hyökkäyspintaa"
    remediation: "Aseta PermitRootLogin no tiedostossa /etc/ssh/sshd_config"
    condition: all
    rules:
      - 'f:/etc/ssh/sshd_config -> r:^\s*PermitRootLogin\s+no'

  - id: 10002
    title: "SSH-salasanakirjautuminen on estetty"
    description: "PasswordAuthentication pitää olla 'no'"
    rationale: "Avainpohjainen todennus on turvallisempi"
    remediation: "Aseta PasswordAuthentication no tiedostossa /etc/ssh/sshd_config"
    condition: all
    rules:
      - 'f:/etc/ssh/sshd_config -> r:^\s*PasswordAuthentication\s+no'

  - id: 10003
    title: "SSH-protokollan versio 2 on pakollinen"
    description: "Vain SSH-protokolla 2 sallitaan"
    condition: all
    rules:
      - 'not f:/etc/ssh/sshd_config -> r:^\s*Protocol\s+1'

Haavoittuvuuksien tunnistaminen

Vulnerability Detector -moduuli

Wazuhin haavoittuvuuksien tunnistusmoduuli vertaa agenttien keräämää ohjelmistoinventaariota tunnettuihin haavoittuvuustietokantoihin (CVE). Se tunnistaa automaattisesti, onko valvottaviin päätepisteisiin asennettu ohjelmistoja, joissa on tunnettuja tietoturvaongelmia.

Moduuli käyttää useita lähteitä:

• National Vulnerability Database (NVD) — NIST:n ylläpitämä CVE-tietokanta
• Jakelun omat tiedotteet — Ubuntu, Debian, Red Hat, SUSE
• CISA KEV — Tunnetut aktiivisesti hyödynnetyt haavoittuvuudet

Konfigurointi managerissa

Haavoittuvuuksien tunnistus konfiguroidaan managerin /var/ossec/etc/ossec.conf-tiedostossa:

<vulnerability-detector>
  <enabled>yes</enabled>
  <interval>5m</interval>
  <run_on_start>yes</run_on_start>

  <!-- NVD-tietokanta -->
  <provider name="nvd">
    <enabled>yes</enabled>
    <update_interval>1h</update_interval>
  </provider>

  <!-- Ubuntu-haavoittuvuudet -->
  <provider name="canonical">
    <enabled>yes</enabled>
    <os>jammy</os>
    <os>noble</os>
    <update_interval>1h</update_interval>
  </provider>

  <!-- Red Hat -haavoittuvuudet -->
  <provider name="redhat">
    <enabled>yes</enabled>
    <os>8</os>
    <os>9</os>
    <update_interval>1h</update_interval>
  </provider>
</vulnerability-detector>

Haavoittuvuushälytykset näkyvät dashboardin Vulnerability Detection -moduulissa, jossa ne on järjestetty vakavuuden (Critical, High, Medium, Low) mukaan. Jokaisesta haavoittuvuudesta näet CVE-tunnisteen, kuvauksen, CVSS-pistemäärän ja korjausohjeet — eli kaikki mitä tarvitset priorisointiin ja korjaamiseen.

Mukautettujen sääntöjen kirjoittaminen

Sääntöjen rakenne

Wazuhin sääntömoottori käyttää XML-pohjaisia sääntötiedostoja. Mukautetut säännöt kirjoitetaan tiedostoon /var/ossec/etc/rules/local_rules.xml. Sääntö koostuu tunnistimesta (ID), tasosta (level), kuvauksesta ja yhdestä tai useammasta ehdosta:

<!-- /var/ossec/etc/rules/local_rules.xml -->
<group name="custom,syslog,">

  <!-- Havaitse sudo-käyttö epätavallisina aikoina -->
  <rule id="100001" level="10">
    <if_sid>5402</if_sid>
    <time>22:00-06:00</time>
    <description>Sudo käytetty työajan ulkopuolella (yö)</description>
    <group>authentication,pci_dss_10.2.5,</group>
  </rule>

  <!-- Havaitse uuden käyttäjän luominen -->
  <rule id="100002" level="8">
    <if_sid>5901</if_sid>
    <match>useradd</match>
    <description>Uusi käyttäjätili luotu järjestelmään</description>
    <group>account_changed,pci_dss_8.1.2,</group>
  </rule>

  <!-- Havaitse kriittisen tiedoston poisto -->
  <rule id="100003" level="12">
    <if_sid>554</if_sid>
    <match>/etc/passwd|/etc/shadow|/etc/sudoers</match>
    <description>Kriittinen järjestelmätiedosto poistettu</description>
    <group>syscheck,pci_dss_11.5,</group>
  </rule>

</group>

Sääntöjen testaaminen wazuh-logtest-työkalulla

wazuh-logtest on korvaamaton työkalu sääntöjen kehittämiseen ja vianetsintään. Olen käyttänyt sitä lukemattomia kertoja, ja se on säästänyt paljon turhaa arvailua. Se mahdollistaa lokimerkintöjen testaamisen sääntöjä vastaan ilman todellisten hälytysten luomista:

# Käynnistä logtest
/var/ossec/bin/wazuh-logtest

# Syötä testitapahtuma
Type one log per line

Feb 27 10:30:00 webserver01 sshd[1234]: Failed password for invalid user admin from 203.0.113.50 port 22 ssh2

**Phase 1: Completed pre-decoding.
**Phase 2: Completed decoding.
       name: 'sshd'
       parent: 'sshd'
       srcip: '203.0.113.50'
       srcuser: 'admin'
**Phase 3: Completed filtering (rules).
       id: '5710'
       level: '5'
       description: 'sshd: Attempt to login using a non-existent user'
       groups: '['syslog', 'sshd', 'invalid_login', 'authentication_failed']'
       firedtimes: '1'
       mail: 'false'

Suorituskyvyn optimointi

Suurten ympäristöjen virittäminen

Kun hallinnoit satoja tai tuhansia agentteja, managerin suorituskyky voi muodostua pullonkaulaksi. Olen nähnyt ympäristöjä, joissa tapahtumia on alkanut tippua, koska oletusasetukset eivät yksinkertaisesti riitä. Tässä kriittiset optimointiparametrit tiedostossa /var/ossec/etc/internal_options.conf:

# Analyysimoottorin jonokoko (oletus 16384)
analysisd.queue_size=131072

# Työntekijäsäikeiden määrä (oletus 4)
analysisd.worker_pool_size=8

# Syscheckd:n lepotila skannauskierrosten välillä
syscheck.sleep=2
syscheck.sleep_after=15

# Remoted-daemonin puskurikoko
remoted.recv_counter_flush=128

Resurssien valvonta

Seuraa managerin resurssien käyttöä näistä tiedostoista:

# Pudotettujen tapahtumien seuranta
cat /var/ossec/var/run/wazuh-analysisd.state | grep events_dropped
# events_dropped='0'   <-- Tämän pitää olla nolla

# Hylättyjen agenttiviestin seuranta
cat /var/ossec/var/run/wazuh-remoted.state | grep discarded_count
# discarded_count='0'  <-- Tämän pitää olla nolla

Jos jompikumpi arvo on suurempi kuin nolla, se on selvä merkki siitä, että managerin resursseja pitää lisätä tai kuorma jakaa useammalle solmulle klusteriarkkitehtuurin avulla.

Integrointi YARA:n ja Suricatan kanssa

YARA: Haittaohjelmien tunnistaminen tiedostomuutoksista

Tämä on yksi niistä ominaisuuksista, jotka tekevät Wazuhista todella monipuolisen. Yhdistämällä FIM:n ja YARA-sääntömoottorin voit rakentaa automaattisen haittaohjelmatunnistusputken:

1. FIM havaitsee muutoksen hakemistossa /var/www/uploads/
2. Wazuh laukaisee Active Response -skriptin yara.sh
3. YARA skannaa tiedoston sääntöjoukkoa vastaan
4. Tulokset lähetetään takaisin managerille hälytykseksi

Tämä lähestymistapa on resurssitehokas, koska YARA-skannaus kohdistuu vain uusiin tai muutettuihin tiedostoihin — ei koko tiedostojärjestelmään. Verrattuna jatkuvaan täyden järjestelmän skannaukseen ero resurssien kulutuksessa on merkittävä.

Suricata: Verkkoliikenteen valvonta

Wazuh integroituu myös Suricata-verkkopohjaisen tunkeutumisen havaitsemisjärjestelmän (NIDS) kanssa. Suricata analysoi verkkoliikennettä ja Wazuh kerää sen hälytykset, yhdistää ne muuhun tietoturvadataan ja visualisoi kokonaisuuden dashboardissa.

Tämä yhdistelmä tarjoaa sekä isäntäpohjaisen (HIDS) että verkkopohjaisen (NIDS) havaitsemiskyvykkyyden — ja juuri tämä kokonaisuus tekee Wazuhista niin vahvan vaihtoehdon kaupallisille ratkaisuille.

Käyttöönotto Docker Composella

Jos haluat kokeilla Wazuhia nopeasti ilman perinteistä asennusta, Docker Compose on erinomainen vaihtoehto. Tämä sopii erityisen hyvin testiympäristöihin ja CI/CD-putkiin:

# Kloonaa virallinen Docker-konfiguraatio
git clone https://github.com/wazuh/wazuh-docker.git -b v4.14.3
cd wazuh-docker/single-node

# Generoi sertifikaatit
docker compose -f generate-indexer-certs.yml run --rm generator

# Käynnistä koko pino
docker compose up -d

# Tarkista kontit
docker compose ps
# NAME                 STATUS
# wazuh.manager        Up (healthy)
# wazuh.indexer        Up (healthy)
# wazuh.dashboard      Up (healthy)

Dashboard on saatavilla osoitteessa https://localhost:443 oletustunnuksilla. Muutamassa minuutissa sinulla on täysin toimiva Wazuh-ympäristö.

Usein kysytyt kysymykset

Mikä ero on Wazuhilla ja OSSEC:lla?

Wazuh syntyi OSSEC:n haarukointina (fork) ja on sen moderni seuraaja. Wazuh lisää OSSEC:iin RESTful API:n, natiivin OpenSearch-integraation, klusterituen, parannetun monisäikeistyksen ja web-dashboardin. OSSEC on edelleen toimiva työkalu yksinkertaisiin asennuksiin, mutta uusiin käyttöönottoihin Wazuh on selkeästi parempi valinta vuonna 2026.

Paljonko Wazuh kuluttaa resursseja?

Agentti on yllättävän kevyt — se käyttää tyypillisesti 50–100 MB muistia ja alle 5 % prosessoritehosta. Manager-palvelimen resurssitarve riippuu agenttien määrästä: 100 agentille riittää 4 ydintä ja 8 GB RAM, mutta yli 500 agentin ympäristöissä klusteriarkkitehtuuri ja vähintään 16 GB RAM on käytännössä pakollinen.

Voinko käyttää Wazuhia ilman dashboardia?

Kyllä, ehdottomasti. Wazuh Manager toimii itsenäisesti ja tuottaa hälytyksiä tiedostoon /var/ossec/logs/alerts/alerts.json. Voit integroida hälytykset mihin tahansa SIEM-järjestelmään, sähköpostiin tai pikaviestimeen API:n tai Filebeatin kautta. Dashboard on kuitenkin erittäin hyödyllinen visualisoinnissa ja tutkinnassa, joten suosittelen sitä lämpimästi.

Miten Wazuh havaitsee nollapäivähaavoittuvuudet?

Suoraan sanottuna Wazuhin haavoittuvuuksien tunnistusmoduuli perustuu tunnettuihin CVE-tietoihin, joten se ei suoraan havaitse nollapäivähaavoittuvuuksia. Sen sijaan FIM, anomalian havaitseminen, mukautetut säännöt ja Suricata-integraatio voivat havaita epätavallista käyttäytymistä, joka saattaa viitata nollapäivähyökkäykseen.

Kerroksellinen puolustus on avain — ja Wazuh tarjoaa siihen erinomaiset työkalut.

Tukeeko Wazuh Kubernetes-ympäristöjä?

Kyllä. Wazuh tarjoaa virallisen Helm-chartin Kubernetes-klusteriin käyttöönottoa varten. Agentti voidaan ajaa DaemonSet-resurssina jokaisessa solmussa, ja se valvoo sekä isäntäkonetta että konttiympäristöä. Wazuh tukee myös konttien ajonaikaisen turvallisuuden valvontaa, mikä on nykyaikaisissa ympäristöissä lähes välttämätöntä.