Wazuh på Linux i 2026: Komplet Guide til Installation, Filovervågning og Indtrængningsdetektion

Verificer forbindelsen

# På agenten — tjek status
sudo systemctl status wazuh-agent

# På manageren — list tilsluttede agenter
sudo /var/ossec/bin/agent_control -l

Agenten skal dukke op som "Active" på manageren inden for et par minutter. Hvis den ikke gør det, er det næsten altid et firewall-problem — dobbelttjek at port 1514 og 1515 er åbne.

Filovervågning (FIM): Konfiguration og best practices

File Integrity Monitoring er, efter min mening, en af Wazuhs mest værdifulde funktioner. FIM-modulet overvåger filer og mapper for ændringer og slår alarm, når nogen opretter, ændrer eller sletter overvågede filer. Det beregner kryptografiske checksums og sammenligner dem mod en baseline — enkelt men utroligt effektivt.

Tre overvågningstilstande

Wazuh tilbyder tre tilstande til filovervågning, og valget afhænger af dit specifikke sikkerhedsbehov:

• Scheduled (planlagt): Fuld scanning med fast interval (standard: hver 12. time). Laveste ressourceforbrug, men ændringer opdages først ved næste scan.
• Realtime: Bruger Linux inotify til at opdage ændringer i næsten realtid. Velegnet til dynamiske konfigurationsfiler og webapplikationsrødder.
• Whodata: Udvidelse af realtime, der også registrerer hvem og hvilken proces der foretog ændringen. Bruger enten Linux Audit-subsystemet eller eBPF (nyt fra Wazuh 4.12+). Det er den tilstand, jeg oftest anbefaler til produktionsmiljøer.

Grundlæggende FIM-konfiguration

Rediger agentens konfigurationsfil /var/ossec/etc/ossec.conf og tilpas <syscheck>-blokken:

<syscheck>
  <!-- Scanning hvert 6. time (21600 sekunder) -->
  <frequency>21600</frequency>

  <!-- Kritiske systemfiler — whodata for fuld attribution -->
  <directories check_all="yes" whodata="yes" report_changes="yes">/etc</directories>
  <directories check_all="yes" whodata="yes" report_changes="yes">/usr/bin</directories>
  <directories check_all="yes" whodata="yes" report_changes="yes">/usr/sbin</directories>

  <!-- Webapplikationer — realtime -->
  <directories check_all="yes" realtime="yes">/var/www</directories>

  <!-- Ignorer støjende filer -->
  <ignore>/etc/mtab</ignore>
  <ignore>/etc/resolv.conf</ignore>
  <ignore type="sregex">.log$</ignore>

  <!-- Whodata-provider: brug eBPF hvis tilgængeligt -->
  <whodata>
    <provider>ebpf</provider>
    <restart_audit>yes</restart_audit>
    <startup_healthcheck>yes</startup_healthcheck>
    <queue_size>50000</queue_size>
  </whodata>
</syscheck>

eBPF vs. Audit som whodata-provider

Wazuh 4.12 introducerede eBPF som alternativ til Linux Audit. eBPF kører direkte i kernen og giver hurtigere hændelsesindsamling uden eksterne afhængigheder — og det mærker man i praksis. Hvis eBPF ikke er tilgængeligt (f.eks. på ældre kerner), falder Wazuh automatisk tilbage til Linux Audit eller inotify.

For servere med Linux-kerne 5.10 eller nyere anbefales eBPF. For ældre systemer fungerer Audit-provideren stadig fint.

Genstart agenten efter ændringer

# Valider konfigurationen først
sudo /var/ossec/bin/wazuh-control info

# Genstart agenten
sudo systemctl restart wazuh-agent

# Verificer at FIM-modulet kører
sudo cat /var/ossec/logs/ossec.log | grep syscheck | tail -5

Loganalyse og detektionsregler

Udover filovervågning analyserer Wazuh logfiler fra operativsystemet og applikationer i realtid. Agenten indsamler logs fra kilder som /var/log/auth.log, /var/log/syslog og journald, og sender dem til manageren for regelbaseret analyse.

Standardregler dækker overraskende meget

Wazuh leveres med over 4.000 detektionsregler, der automatisk mapper til MITRE ATT&CK-frameworket. Det er en af de ting, der virkelig sætter det fra konkurrenterne. Nogle af de vigtigste regelgrupper for Linux:

• SSH brute-force: Alarmer ved gentagne fejlslagne login-forsøg (regel-ID 5710-5712)
• Rootkit-detektion: Scanner for kendte rootkit-signaturer og mistænkelige kernel-moduler
• Privilegieeskalering: Overvåger sudo-brug og ændringer i brugerrettigheder
• Webserver-angreb: Detekterer SQL injection, XSS og directory traversal i Apache/Nginx-logs
• Filintegritet: Alarmer ved uautoriserede ændringer i overvågede filer og mapper

Tilføj tilpassede logkilder

Du kan nemt tilføje yderligere logfiler til overvågning i agentens ossec.conf:

<localfile>
  <log_format>syslog</log_format>
  <location>/var/log/nginx/access.log</location>
</localfile>

<localfile>
  <log_format>syslog</log_format>
  <location>/var/log/nginx/error.log</location>
</localfile>

<localfile>
  <log_format>json</log_format>
  <location>/var/log/myapp/audit.json</location>
</localfile>

Opret en tilpasset detektionsregel

Du kan også oprette dine egne regler på manageren i /var/ossec/etc/rules/local_rules.xml. Her er et eksempel, der slår alarm ved ændringer i SSH-konfigurationen (noget man næsten altid vil vide om):

<group name="custom_fim,">
  <rule id="100010" level="12">
    <if_sid>550</if_sid>
    <field name="file">/etc/ssh/sshd_config</field>
    <description>SSH-konfigurationsfilen er blevet ændret</description>
    <mitre>
      <id>T1098</id>
    </mitre>
  </rule>
</group>

Genstart manageren for at aktivere nye regler:

sudo systemctl restart wazuh-manager

Aktiv respons: Automatisk blokering af angribere

Det her er nok den funktion, der imponerer mest, når man ser Wazuh i aktion for første gang. Aktiv respons giver mulighed for automatisk at reagere på detekterede trusler. I stedet for blot at logge et angreb kan Wazuh faktisk gøre noget ved det — blokere IP-adresser, terminere processer eller køre tilpassede scripts.

Eksempel: Bloker IP efter SSH brute-force

Tilføj følgende konfiguration til managerens /var/ossec/etc/ossec.conf:

<ossec_config>
  <active-response>
    <command>firewall-drop</command>
    <location>local</location>
    <rules_id>5712</rules_id>
    <timeout>3600</timeout>
  </active-response>
</ossec_config>

Denne konfiguration instruerer Wazuh i at blokere enhver IP-adresse, der udløser regel 5712 (SSH brute-force), via en firewall-drop i 3600 sekunder — altså én time. Blokeringen fjernes automatisk, når timeout udløber. Smart og effektivt.

Verificer aktiv respons

# Se aktive blokeringer
sudo cat /var/ossec/logs/active-responses.log

# List aktuelt blokerede IP-adresser (iptables)
sudo iptables -L INPUT -n | grep DROP

# Fjern en blokering manuelt
sudo /var/ossec/active-response/bin/firewall-drop delete - - 192.168.1.50

Tilpasset aktiv respons-script

Du kan også oprette dine egne respons-scripts. Her er et praktisk eksempel, der sender en Slack-notifikation ved kritiske alarmer:

#!/bin/bash
# /var/ossec/active-response/bin/slack-notify.sh

LOCAL=$(dirname $0)
cd $LOCAL
cd ../

ALERT_FILE=$1
WEBHOOK_URL="https://hooks.slack.com/services/DIN/WEBHOOK/URL"

# Læs alarmdata
ALERT_MSG=$(cat ${ALERT_FILE} | /var/ossec/framework/python/bin/python3 -c \
  "import sys,json; d=json.load(sys.stdin); print(d.get('rule',{}).get('description','Ukendt alarm'))")

# Send til Slack
curl -s -X POST -H "Content-type: application/json" \
  --data "{\"text\":\"Wazuh-alarm: ${ALERT_MSG}\"}" \
  "${WEBHOOK_URL}"

exit 0;

Wazuh vs. OSSEC vs. AIDE: Hvilket værktøj skal du vælge?

Det her spørgsmål dukker op igen og igen, så lad os tage en direkte sammenligning af de tre mest populære open source-værktøjer til host-baseret sikkerhedsovervågning på Linux:

Wazuh er det klare førstevalg for de fleste miljøer i 2026. Det er aktivt udviklet (seneste version 4.14.4, marts 2026), har enterprise-klar skalerbarhed, et moderne web-dashboard, native integration med OpenSearch/ELK, færdige compliance-skabeloner og aktiv respons. Fungerer til alt fra 10 til 10.000+ endpoints.

OSSEC er stadig et solidt HIDS, men udviklingen er reelt gået i stå (seneste stabile version 3.8.0 fra januar 2021). Det mangler moderne dashboard, cloud-/container-overvågning og native compliance-skabeloner. Bedst til små, simple opsætninger — eller hvis du bare vil lære koncepterne.

AIDE er udelukkende en filintegritetschecker. Ingen loganalyse, ingen aktiv respons, ingen agent-arkitektur. Den kører på en enkelt maskine og sammenligner filsystemets aktuelle tilstand med en forudbygget database. Kan være nyttig som et letvægtskomplementær til andre værktøjer på hærdede servere med minimalt footprint.

Kort sagt: for de fleste produktionsmiljøer er anbefalingen klar — vælg Wazuh. Du får et komplet sikkerhedsøkosystem i ét værktøj, med aktiv udvikling og et stort community bag sig.

Integration i din eksisterende infrastruktur

En ting, jeg virkelig sætter pris på ved Wazuh, er hvor godt det spiller sammen med de værktøjer, man allerede bruger:

• Ansible: Brug Ansible-roles til at deploye agenter automatisk på nye servere. Wazuh tilbyder officielle Ansible-roles på GitHub.
• Docker og Kubernetes: Wazuh kan overvåge Docker-containere og Kubernetes-klynger. Med version 4.14.4 er Docker-integrationsreglerne blevet opdateret til bedre detektionsdækning.
• CI/CD-pipelines: Integrer Wazuhs sårbarhedsscanning i din DevSecOps-pipeline via Wazuh API (port 55000).
• SIEM-forwarding: Wazuh kan forwarde alarmer til eksterne SIEM-systemer via Syslog eller direkte Elasticsearch-integration.

Eksempel: Automatiseret agent-deployment med Ansible

# wazuh-agent-playbook.yml
---
- hosts: linux_servers
  become: yes
  vars:
    wazuh_manager_ip: "192.168.1.100"
  tasks:
    - name: Tilføj Wazuh GPG-nøgle
      ansible.builtin.rpm_key:
        key: https://packages.wazuh.com/key/GPG-KEY-WAZUH
        state: present
      when: ansible_os_family == "RedHat"

    - name: Installer Wazuh-agent
      ansible.builtin.yum:
        name: wazuh-agent
        state: present
      environment:
        WAZUH_MANAGER: "{{ wazuh_manager_ip }}"
      when: ansible_os_family == "RedHat"

    - name: Start og aktiver Wazuh-agent
      ansible.builtin.systemd:
        name: wazuh-agent
        state: started
        enabled: yes

Deaktiver automatiske opdateringer efter installation

Et lille tip, der kan spare dig for hovedpine: Wazuh anbefaler at deaktivere automatiske pakkeopdateringer for at undgå utilsigtede opgraderinger, der kan bryde kompatibiliteten mellem manager og agenter.

# Ubuntu — deaktiver repository
sudo sed -i "s/^deb /#deb /" /etc/apt/sources.list.d/wazuh.list
sudo apt update

# RHEL — deaktiver repository
sudo sed -i "s/^enabled=1/enabled=0/" /etc/yum.repos.d/wazuh.repo

Planlæg i stedet kontrollerede opdateringer, hvor du først opgraderer manageren og derefter agenterne. En vigtig detalje: manageren skal altid være på en version, der er lig med eller nyere end agenterne.

Ofte stillede spørgsmål

Hvad er forskellen mellem Wazuh og en traditionel firewall?

En firewall (f.eks. nftables eller UFW) kontrollerer netværkstrafik ved at tillade eller blokere forbindelser baseret på regler. Wazuh er derimod et indtrængningsdetektionssystem, der overvåger hvad der sker inde på serveren — filændringer, logmønstre, procesaktivitet og systemkonfiguration. De to komplementerer hinanden: firewallen er din ydre mur, og Wazuh er dit overvågningskamera indendørs.

Hvor mange ressourcer bruger Wazuh-agenten?

Wazuh-agenten er overraskende letvægt. Under normale forhold bruger den typisk 35-60 MB RAM og minimal CPU (under 2 % på moderne hardware). Ressourceforbruget stiger kortvarigt under planlagte FIM-scanninger, men det påvirker sjældent produktionsbelastninger mærkbart.

Kan Wazuh erstatte kommercielle SIEM-løsninger?

For mange organisationer — ja, faktisk. Wazuh tilbyder logindsamling, korrelation, alarmering, compliance-rapportering og et moderne dashboard. For store enterprise-miljøer med tusindvis af datakilder og komplekse korrelationskrav kan en dedikeret SIEM dog stadig være nødvendig. I det tilfælde kan Wazuh fungere som en datakilde, der forwarder alarmer til dit primære SIEM.

Understøtter Wazuh overvågning af cloud-miljøer?

Ja. Wazuh kan overvåge AWS, Azure og GCP via native integrationer. Det inkluderer overvågning af CloudTrail-logs, S3-bucket-konfigurationer og Azure Activity Logs. Agenter kan også deployes på cloud-instanser præcis som på fysiske servere.

Hvordan opdaterer jeg Wazuh sikkert uden nedetid?

Wazuh understøtter rullende opgraderinger. Opgradér altid manageren først, derefter indexeren og dashboardet, og til sidst agenterne. Agenter er bagudkompatible med nyere manager-versioner, så dine endpoints forbliver overvåget under hele processen. Og selvfølgelig — test altid opgraderingen i et staging-miljø først.