I augusti 2026 ligger Sverige högst i Norden på antal rapporterade cyberincidenter enligt en DNV-rapport, och Verizons DBIR 2026 räknar in över 22 000 dataintrång globalt under mätperioden. Ryde-hacket läckte 4,5 miljoner nordiska konton och Miljödata-attacken drabbade 200 kommuner och 870 000 privatpersoner. Gemensamt för de flesta av dessa fall är att intrånget pågick i veckor eller månader innan någon upptäckte det. Ett eget SIEM-system (Security Information and Event Management) är det verktyg som faktiskt kortar den tiden, och Wazuh är den öppna källkod-plattform flest säkerhetsteam väljer när budgeten inte räcker till Splunk eller Microsoft Sentinel.
Den här guiden visar hur du installerar, härdar och driftsätter Wazuh 4.14.7 från grunden. Du får kommandoraderna, konfigurationsfilerna och de vanligaste felen samlade på ett ställe, byggt för ett svenskt eller nordiskt team som vill gå från noll till ett fungerande detektionslager på en eftermiddag.
Vi går igenom installationen steg för steg, förklarar vad varje komponent faktiskt gör, och visar ett komplett exempelprojekt för 25 agenter som du kan skala upp eller ner efter din egen miljö. Du behöver inga tidigare SIEM-kunskaper, bara grundläggande Linux-vana och en server att jobba mot. Guiden täcker allt från den första installationskommandot till hur du tolkar de första larmen, felsöker vanliga problem och håller systemet uppdaterat över tid.
Varför fler nordiska team bygger sitt eget SIEM 2026
Ett SIEM samlar loggar från servrar, brandväggar, molntjänster och slutpunkter på ett ställe och korrelerar dem mot kända attackmönster. Utan det upptäcker de flesta organisationer ett intrång via en extern part, till exempel en kund eller en brottsbekämpande myndighet, inte via sina egna system. En Nordic CISO-rapport som Shattered.io tidigare skrivit om visade att tiden från publicerad sårbarhet till aktiv exploatering har rasat med 95 procent sedan 2023. Angriparna är snabbare. Försvaret måste bli det också.
Problemet är kostnaden. Kommersiella SIEM-lösningar tar betalt per gigabyte inloggad data, och för ett företag med några hundra endpoints blir notan snabbt sex- eller sjusiffrig per år. Wazuh är licensierat under GPLv2, helt gratis att köra, och byggt på samma tre-lagersarkitektur som de flesta betalda alternativ: en manager som tar emot och analyserar loggar, en indexerare (OpenSearch) som lagrar och söker i data, och en dashboard för visualisering. För mindre och medelstora nordiska bolag som omfattas av NIS2 är det ofta den enda realistiska vägen till kontinuerlig övervakning.
Branschorganisationer som SANS Institute har länge pekat på att tid till upptäckt, inte tid till patchning, är den enskilt viktigaste variabeln för hur dyrt ett intrång blir. Ju längre en angripare rör sig obemärkt i nätverket, desto fler system hinner de nå och desto mer data hinner de flytta ut. Ett SIEM ändrar inte hotbilden, men det ger teamet ett faktiskt tillfälle att agera innan skadan sprider sig till hela infrastrukturen.
En tidigare WEF-relaterad rapport som Shattered.io skrivit om visade att endast omkring 19 procent av organisationer globalt bedömer sig ha tillräcklig cyberresiliens, samtidigt som Sverige ändå toppade den nordiska rankningen. Det säger något om läget i hela regionen snarare än om enskilda bolag. Gapet mellan att känna sig förberedd och att faktiskt ha ett fungerande detektionslager på plats är precis det en installation som denna guide är tänkt att stänga.
Vad är Wazuh, och hur skiljer det sig från Splunk och Sentinel
Wazuh startade som en fork av OSSEC 2015 och har sedan dess vuxit till en fullständig XDR-plattform (Extended Detection and Response). Det betyder att det inte bara samlar loggar, utan också gör filintegritetsövervakning, sårbarhetsskanning, konfigurationsrevision och kan trigga automatiska motåtgärder. Version 4.14.7, släppt 29 juli 2026, lade till förbättrat stöd för molnloggar från Azure och Google Cloud samt snabbare indexering vid höga datavolymer. Hela projektet, inklusive källkoden till agenten, managern och regelverket, ligger öppet på GitHub, vilket gör det möjligt att läsa exakt vad varje detektionsregel faktiskt gör innan du litar på den.
Skillnaden mot Splunk och Microsoft Sentinel handlar mest om driftsmodell och pris. Splunk och Sentinel är molnbaserade eller hybridbaserade tjänster där du betalar löpande för intag av data. Wazuh installerar du själv, on-premise eller i din egen molnmiljö, och du äger all data. Nackdelen är att du också äger underhållet: patchning, skalning och regeljustering blir ditt ansvar snarare än leverantörens.
Det finns också ett mellanting. Wazuh Inc., företaget bakom projektet, erbjuder en hanterad molnversion för team som vill slippa sköta indexerarkluster och uppgraderingar själva, mot en löpande avgift. För de flesta bolag under några hundra endpoints är kostnadsbesparingen med att självhosta ändå så pass stor att det väger upp den extra driftbördan, särskilt om ni redan har någon i teamet med Linux-erfarenhet.
Wazuh är inte det enda gratisalternativet på marknaden. Elastic Security och Graylog löser liknande problem men med olika avvägningar värda att känna till innan du bestämmer dig.
| Plattform | Grundlicens | Styrka | Svaghet |
|---|---|---|---|
| Wazuh | Gratis (GPLv2) | Inbyggd FIM, SCA och active response | Mindre polerat gränssnitt än betalda alternativ |
| Elastic Security | Delvis gratis, avancerade funktioner bakom licens | Kraftfull sökning och visualisering | Kräver egen agentlösning för XDR-funktioner |
| Graylog | Gratis grundversion | Enkel loggaggregering | Saknar inbyggd hotdetektering och FIM |
Om ditt primära behov är loggsökning och visualisering utan mycket säkerhetslogik ovanpå kan Graylog vara enklare att komma igång med. Vill du ha djup textanalys och redan investerat i Elastic-stacken kan Elastic Security vara ett naturligt val. För team som specifikt vill ha hotdetektering, filintegritet och automatiska motåtgärder utan att betala för tilläggsmoduler är Wazuh fortfarande det mest kompletta alternativet ur lådan.
Många nordiska säkerhetsteam landar dessutom i en hybridlösning över tid: Wazuh för endpoint- och serverdetektering, kompletterat med ett separat nätverksbaserat intrångsdetekteringssystem för trafik som aldrig passerar en agent, till exempel äldre IoT-utrustning eller industriella styrsystem som inte stödjer agentinstallation alls. Ingen enskild plattform täcker hela hotytan på egen hand, och det är sällan realistiskt att förvänta sig det heller.
| Egenskap | Wazuh 4.14.7 | Microsoft Sentinel | Splunk Enterprise |
|---|---|---|---|
| Licenskostnad | Gratis, öppen källkod | Betalt per GB intag | Betalt per GB intag |
| Driftmodell | Self-hosted / egen molnmiljö | SaaS i Azure | SaaS eller self-hosted |
| MITRE ATT&CK-mappning | Inbyggd | Inbyggd | Via tillägg |
| Filintegritetsövervakning | Inbyggd (FIM) | Kräver Defender-integration | Kräver tillägg |
| Molnleverantörens inlåsning | Ingen | Hög (Azure) | Låg till medel |
Prisskillnaden är verklig snarare än teoretisk. I en tidigare jämförelse på Shattered.io mellan Sentinel och Splunk låg kostnaden på ungefär 4 dollar per GB för Sentinel mot omkring 80 000 dollar per år för en mellanstor Splunk-installation. Wazuh tar bort den posten helt, men du betalar med egen driftstid istället för fakturor.
Förutsättningar: mjukvara, hårdvara och kunskap
Innan du börjar behöver du en server, ett par agenter att övervaka och grundläggande kunskap om Linux-kommandoraden. Wazuhs officiella dokumentation anger 4 GB RAM och 2 CPU-kärnor som minimum för själva indexerarnoden. För en komplett all-in-one-installation som ska hantera cirka 25 agenter och 90 dagars historik rekommenderar Wazuhs eget utbildningsmaterial 4 CPU-kärnor, 8 GB RAM och 50 GB diskutrymme, gärna SSD.
Tänk på diskvalet redan från start. En traditionell hårddisk klarar visserligen kraven på papper, men OpenSearch gör tunga skrivoperationer kontinuerligt, och en SSD gör skillnaden mellan en dashboard som svarar direkt och en som hackar sig igenom stora sökningar. Om du kör i en molnmiljö som AWS eller Azure väljer du helt enkelt en instanstyp med SSD-baserad lagring från början, det kostar marginellt mer men sparar timmar av frustration senare.
| Komponent | Minimum | Rekommenderat (25 agenter, 90 dagar) |
|---|---|---|
| Operativsystem | Ubuntu 22.04 LTS | Ubuntu 24.04 LTS |
| CPU | 2 kärnor | 4 kärnor |
| RAM | 4 GB | 8 GB |
| Diskutrymme | 20 GB | 50 GB SSD |
| Nätverk | Portarna 443, 1514, 1515 öppna | Samma, plus 55000 för API |
Kunskap du bör ha innan du börjar
- Grundläggande Linux-kommandon (sudo, systemctl, curl, tar)
- Förståelse för hur brandväggsregler och portar fungerar
- Grundkunskap om YAML- och XML-syntax för konfigurationsfiler
- Root- eller sudo-åtkomst till den server du installerar på
Vilka loggkällor du bör prioritera först
Ett vanligt nybörjarmisstag är att försöka koppla in allt på en gång, från kontorsskrivare till interna testservrar. Börja istället med källorna som faktiskt brukar synas i verkliga intrång, och bygg ut därifrån när grunden fungerar stabilt.
| Prioritet | Källa | Varför den kommer först |
|---|---|---|
| 1 | Internetexponerade servrar (webb, VPN, e-post) | Vanligaste väg in för angripare |
| 2 | Domänkontrollanter och identitetsservrar | Kompromettering här ger full nätverksåtkomst |
| 3 | Molnkontologgar (AWS CloudTrail, Azure Activity Log) | Ofta förbisedda men avslöjar kontokapning snabbt |
| 4 | Slutanvändarnas arbetsstationer | Vanlig startpunkt för phishing-baserade intrång |
| 5 | Interna testmiljöer och utvecklingsservrar | Lägre prioritet, men bör täckas innan produktionslansering |
Den här ordningen speglar också hur de flesta verkliga intrångskedjor faktiskt rör sig, från en internetexponerad tjänst, via stulna autentiseringsuppgifter, till bredare åtkomst i nätverket. Genom att täcka de första tre nivåerna innan resten är utrullad får du täckning på de punkter där en attack med störst sannolikhet både börjar och eskalerar.
Wazuh-arkitekturen: fyra komponenter du bör känna till
Wazuh består av fyra delar som pratar med varandra. Wazuh-agenten installeras på varje enhet du vill övervaka och skickar händelser vidare. Wazuh-manager tar emot händelserna, kör dem mot ett regelverk med tusentals fördefinierade signaturer, och avgör vad som ska larma. Wazuh-indexeraren, byggd på OpenSearch, lagrar och indexerar all data för snabb sökning. Wazuh-dashboarden ger dig gränssnittet där du ser larm, bygger visualiseringar och konfigurerar regler.
Kommunikationen mellan agent och manager sker krypterat över en egen kö på port 1514, medan registrering av nya agenter sker på port 1515. Det innebär att du inte behöver öppna traditionella syslog-portar mot internet, all trafik går genom Wazuhs eget protokoll som redan är utformat för att fungera över opålitliga nätverk och återuppta anslutningen automatiskt om en agent tillfälligt tappar kontakten.
I en liten installation kan alla fyra komponenter köra på samma server, det som Wazuh kallar en all-in-one-installation. När miljön växer förbi omkring 100 agenter delar de flesta team upp indexeraren på egna noder för att hålla söktider nere.
Det är värt att förstå denna fyrdelade struktur innan du börjar installera, eftersom felsökning nästan alltid handlar om att peka ut vilken av de fyra komponenterna som faller bort. Ett larm som aldrig dyker upp i dashboarden kan bero på att agenten inte skickar data, att managern inte behandlar den korrekt, att indexeraren inte lagrar den, eller att dashboarden helt enkelt inte visar rätt tidsfönster. Att kunna isolera var i kedjan problemet ligger sparar timmar jämfört med att gissa sig fram.
Steg 1–3: Förbered värden och kör installationsskriptet
Börja med en ren Ubuntu 24.04-server. Uppdatera paketen, sätt en statisk hostname och kontrollera att klockan är synkroniserad. Wazuh är känsligt för tidsskillnader mellan noder, så en felaktig klocka orsakar konstiga fel längre fram.
# Steg 1: uppdatera systemet och sätt hostname
sudo apt update && sudo apt upgrade -y
sudo hostnamectl set-hostname wazuh-manager
sudo timedatectl set-ntp true
# Steg 2: kontrollera minne och diskutrymme
free -h
df -h /
# Steg 3: hämta och kör det officiella installationsskriptet
curl -sO https://packages.wazuh.com/4.14/wazuh-install.sh
sudo bash wazuh-install.sh -aFlaggan -a kör en all-in-one-installation som sätter upp manager, indexerare och dashboard i ett svep. Processen tar mellan 10 och 20 minuter beroende på hårdvara. Skriptet laddar ner paket från Wazuhs officiella repo, så en stabil internetuppkoppling gör installationen snabbare och mindre benägen att haverera halvvägs. Kör aldrig skriptet på en server som redan hanterar produktionstrafik, testa alltid mot en dedikerad maskin eller virtuell instans först.
Ett typiskt utdrag från terminalen mot slutet av installationen ser ut ungefär så här, och det är just detta du letar efter för att bekräfta att alla tre komponenter startade korrekt:
INFO: --- Summary ---
INFO: You can access the web interface https://<wazuh-dashboard-ip>
User: admin
Password: kJ8pR2vXmT9qLzN4
INFO: Installation finished.Dyker den här sammanfattningen aldrig upp, gick något fel längre upp i loggen. Skrolla tillbaka och leta efter rader som börjar med ERROR, oftast handlar det om otillräckligt minne eller en port som redan är upptagen.
Steg 4–5: Hämta lösenord och säkra installationen
När installationsskriptet är klart skriver det ut ett admin-lösenord i terminalen. Spara det direkt, för det visas inte igen. Om du missade det ligger det i en lösenordsfil på servern.
# Steg 4: hämta admin-lösenordet om du missade det
sudo tar -xvf wazuh-install-files.tar
sudo cat wazuh-install-files/wazuh-passwords.txt | grep -A1 "user: admin"
# Steg 5: logga in på dashboarden
# Öppna https://<server-ip> i webbläsaren
# Användarnamn: admin
# Lösenord: från filen ovanByt admin-lösenordet direkt efter första inloggningen via Wazuh API:et eller dashboardens användarhantering. Skapa sedan en separat läsbehörig användare för teammedlemmar som bara ska titta på larm, så slipper du dela ut fullständig adminaccess i onödan. Kontrollera också att dashboarden bara är nåbar från ditt interna nätverk eller via VPN, inte öppen mot internet.
Passa också på att rotera det interna kommunikationslösenordet mellan indexeraren och dashboarden, som installationsskriptet också genererar automatiskt. Alla dessa uppgifter ligger i samma lösenordsfil, och den bör flyttas till en säker lagringsplats, till exempel en lösenordshanterare, och sedan raderas från servern istället för att ligga kvar i klartext i hemkatalogen.
Steg 6–7: Installera din första agent (Linux och Windows)
Med managern uppe är nästa steg att koppla på agenter. En agent är ett litet program som körs på varje övervakad enhet och skickar loggar, filändringar och systeminformation till managern. Processen skiljer sig något mellan Linux och Windows.
# Steg 6: installera Wazuh-agent på en Ubuntu/Debian-server
curl -o wazuh-agent.deb https://packages.wazuh.com/4.x/apt/pool/main/w/wazuh-agent/wazuh-agent_4.14.7-1_amd64.deb
sudo WAZUH_MANAGER='wazuh-manager-ip' dpkg -i ./wazuh-agent.deb
sudo systemctl daemon-reload
sudo systemctl enable wazuh-agent
sudo systemctl start wazuh-agentPå Windows laddar du ner MSI-paketet från samma versionsgren och installerar det via PowerShell med samma manager-IP som parameter. Efter installationen visar dashboardens sida Agents att den nya enheten är ansluten och skickar data, vanligtvis inom en minut. Om du hanterar många Windows-maskiner samtidigt går samma kommando lika bra att köra via Group Policy eller ett verktyg som Intune, du behöver bara byta ut manager-IP:t mot en variabel som pekar mot rätt miljö.
# Windows: installera agent via PowerShell (kör som administratör)
Invoke-WebRequest -Uri https://packages.wazuh.com/4.x/windows/wazuh-agent-4.14.7-1.msi -OutFile wazuh-agent.msi
msiexec.exe /i wazuh-agent.msi /q WAZUH_MANAGER='wazuh-manager-ip'
Start-Service -Name WazuhSvcEtt exempel på hur en frisk agent ser ut i dashboardens API-svar:
{
"id": "004",
"name": "web-server-02",
"ip": "10.0.4.22",
"status": "active",
"os": { "platform": "ubuntu", "version": "24.04" },
"version": "Wazuh v4.14.7",
"lastKeepAlive": "2026-08-25T09:14:02Z"
}Steg 8–9: Filintegritetsövervakning och sårbarhetsdetektering
Filintegritetsövervakning (FIM) larmar när filer i utvalda mappar skapas, ändras eller raderas, vilket är precis det beteende som ransomware och backdoors uppvisar. Lägg till mapparna du vill bevaka i agentens konfigurationsfil ossec.conf. Bevaka systemkataloger, webbrotmappar och konfigurationsfiler, men undvik att övervaka tillfälliga mappar eller loggkataloger som ändras konstant, annars fylls dashboarden med brus istället för signal.
<!-- ossec.conf på agenten, steg 8 -->
<syscheck>
<frequency>43200</frequency>
<directories check_all="yes" realtime="yes">/etc,/usr/bin,/usr/sbin</directories>
<directories check_all="yes">/var/www/html</directories>
<ignore>/etc/mtab</ignore>
</syscheck>Aktivera sedan sårbarhetsdetektering på managern, steg 9. Modulen jämför installerade paketversioner på varje agent mot kända CVE-databaser och flaggar system som kör sårbar mjukvara, samma logik som ligger bakom CISAs KEV-katalog fast applicerad på din egen miljö. Efter första skanningen ser du en rangordnad lista över vilka agenter som har flest kritiska sårbarheter, vilket gör det enkelt att prioritera patchningsarbetet utan att gissa.
# Aktivera vulnerability detection i /var/ossec/etc/ossec.conf på managern
<vulnerability-detection>
<enabled>yes</enabled>
<index-status>yes</index-status>
<feed-update-interval>60m</feed-update-interval>
</vulnerability-detection>
sudo systemctl restart wazuh-managerSteg 10–11: Security Configuration Assessment och MITRE ATT&CK-mappning
Security Configuration Assessment (SCA), steg 10, kör automatiska kontroller mot härdningsstandarder som CIS Benchmarks och rapporterar avvikelser, till exempel öppna SSH-root-inloggningar eller svaga lösenordspolicyer. Modulen är påslagen som standard i Wazuh 4.14.7 och kräver ingen extra konfiguration för att börja skanna. Resultatet visas som en procentuell efterlevnadsgrad per agent, vilket gör det enkelt att visa upp framsteg för ledningen utan att behöva förklara varje enskild teknisk detalj.
Steg 11 handlar om att koppla varje larmtyp till en teknik i MITRE ATT&CK, ramverket för hur riktiga angripare rör sig genom ett nätverk. Wazuh mappar sina inbyggda regler mot ATT&CK version 19.2, som uppdaterades i augusti 2026, vilket gör det möjligt att se om ett larm handlar om initial åtkomst, lateral rörelse eller dataexfiltrering direkt i dashboarden. Den mappningen gör det också enklare att förklara ett larm för icke-tekniska kollegor, “misslyckade inloggningar” blir “ett försök till initial åtkomst enligt ett känt angreppsmönster”.
| ATT&CK-taktik | Exempel på Wazuh-regel | Typisk källa |
|---|---|---|
| Initial Access | Misslyckade SSH-inloggningar från ny geografi | Autentiseringsloggar |
| Persistence | Ny cron-post eller schemalagd uppgift | FIM / syscheck |
| Privilege Escalation | Sudo-körning från ovanlig binär | Systemloggar |
| Exfiltration | Stora utgående dataöverföringar utanför kontorstid | Nätverkslogg / brandvägg |
Steg 12: Bygg aktiva svar som blockerar angripare automatiskt
Active Response låter Wazuh agera direkt när ett larm når en viss allvarlighetsgrad, till exempel genom att blockera en IP-adress i brandväggen. Det är det sista steget i grundinstallationen och det som gör skillnaden mellan att bara se en attack och faktiskt stoppa den medan den pågår.
# /var/ossec/etc/ossec.conf på managern
<command>
<name>firewall-drop</name>
<executable>firewall-drop</executable>
<timeout_allowed>yes</timeout_allowed>
</command>
<active-response>
<command>firewall-drop</command>
<location>local</location>
<rules_id>5763</rules_id>
<timeout>600</timeout>
</active-response>Regel 5763 i exemplet ovan motsvarar upprepade misslyckade SSH-inloggningar, en klassisk brute force-signatur. Sätt alltid en timeout på blockeringen så att en legitim användare som skrivit fel lösenord inte låses ute permanent. Testa regeln i en isolerad miljö innan du aktiverar den mot produktionstrafik.
Du kan bygga fler active response-kommandon på samma sätt för andra scenarier, till exempel att automatiskt avsluta en misstänkt process, koppla bort en enhet från nätverket, eller kvarantänera en fil som flaggats av filintegritetsövervakningen. Börja alltid med det säkraste alternativet, IP-blockering med kort timeout, innan du bygger ut till mer drastiska åtgärder som kan påverka legitim drift om en regel triggas felaktigt.
Komplett projekt: bygg ett litet SOC för 25 agenter
Sätt ihop stegen ovan till ett konkret exempel: ett litet nordiskt SaaS-bolag med 80 arbetsstationer, 10 servrar och 10 nätverksenheter, alltså liknande skala som Wazuhs eget referensexempel för 90 dagars historik. Enligt Wazuhs officiella dokumentation landar diskbehovet för den mixen på ungefär 231 GB över 90 dagar, beroende på hur många larm per sekund varje enhetstyp genererar.
Koppla dessutom på e-postnotiser för kritiska larm redan i den här fasen, så att teamet inte behöver ha dashboarden öppen dygnet runt för att upptäcka en pågående attack. Ett enkelt exempel på hur det konfigureras i managerns huvudkonfiguration:
# /var/ossec/etc/ossec.conf: e-postnotiser för larm över nivå 12
<global>
<email_notification>yes</email_notification>
<email_to>[email protected]</email_to>
<smtp_server>smtp.ditt-foretag.se</smtp_server>
<email_from>[email protected]</email_from>
</global>
<alerts>
<email_alert_level>12</email_alert_level>
</alerts>Nivå 12 fångar upp allvarliga händelser som brute force-attacker eller kritiska sårbarheter, utan att fylla inkorgen med de lägre larmnivåerna som hör hemma i dashboarden snarare än i mejlen.
| Enhetstyp | Antal | Larm per sekund (APS) | Disk per enhet, 90 dagar |
|---|---|---|---|
| Arbetsstationer | 80 | 0,1 | 1,5 GB |
| Servrar | 10 | 0,25 | 3,7 GB |
| Nätverksenheter | 10 | 0,5 | 7,4 GB |
Projektet delas lämpligen upp i tre faser. Fas ett täcker installation och grundhärdning enligt steg 1–5 ovan, vanligtvis klart samma dag. Fas två rullar ut agenter gruppvis, börja med de mest kritiska servrarna innan arbetsstationerna. Fas tre lägger till FIM, SCA och active response, samt en första genomgång av vilka larm som faktiskt kräver mänsklig uppmärksamhet, så att teamet inte dränks i falska positiva från dag ett.
Så tolkar du din första vecka med larm
De första dagarna efter en Wazuh-driftsättning kommer larmbilden se skrämmande ut. En helt normal miljö genererar hundratals händelser om dagen bara från rutinmässig systemadministration, schemalagda backuper och automatiska uppdateringar. Det är förväntat, inte ett tecken på att något är fel med installationen.
Sortera larmen efter allvarlighetsgrad (level 0–15 i Wazuhs skala) och börja bara titta på nivå 10 och uppåt den första veckan. Skapa sedan undantagsregler för de larm som visar sig komma från kända, godkända processer, till exempel ett backupverktyg som rör vid systemfiler varje natt. Efter ungefär två veckor brukar de flesta team ha en dashboard som visar mellan 5 och 20 relevanta larm per dag istället för hundratals, vilket är den nivå där ett litet team faktiskt hinner granska varje enskild händelse.
Kostnaden att räkna med, trots att mjukvaran är gratis
Wazuh kostar inget i licensavgifter, men det är inte samma sak som att det är gratis att driva. Serverkostnaden för hårdvaran eller molninstanserna som beskrivs i tabellen ovan är den mest uppenbara posten, men den största kostnaden över tid är personaltid: någon behöver justera regler, granska larm och underhålla systemet löpande.
Räkna med att avsätta några timmar i veckan för regeljustering under de första månaderna, och därefter några timmar i månaden för löpande underhåll när miljön har stabiliserat sig. För ett litet team utan dedikerad säkerhetspersonal är det värt att jämföra den tiden mot vad en molnbaserad SIEM-tjänst hade kostat i licensavgifter innan ni bestämmer er för self-hosting. I många fall vinner Wazuh ändå, men det är sällan helt kostnadsfritt i praktiken.
Glöm inte heller bort uppgraderingskostnaden i tid. Nya Wazuh-versioner släpps regelbundet, och att hoppa över för många versioner i rad gör själva uppgraderingsprocessen betydligt krångligare än att följa med löpande. Planera in ett uppgraderingsfönster varje kvartal snarare än att vänta tills en kritisk säkerhetsuppdatering tvingar fram det akut.
Fem vanliga fallgropar när du driftsätter Wazuh
- Larmtrötthet från dag ett. Att slå på alla standardregler direkt ger hundratals larm per timme i en normal miljö. Börja med ett fåtal högkritiska regelgrupper och utöka gradvis, annars slutar teamet stänga av notiser helt istället för att läsa dem.
- Ingen tidssynkronisering mellan noder. Skillnader i systemklockan gör att händelser hamnar i fel ordning i indexeraren och korrelationsregler slutar fungera korrekt. Kontrollera NTP-status på samtliga noder som en del av den vanliga hälsokontrollen.
- För liten disk från start. Många underskattar hur snabbt loggvolymen växer när fler agenter kopplas på, vilket leder till att indexeraren slutar ta emot data mitt i månaden. Räkna hellre med marginal från dag ett än att utöka disken akut under produktion.
- Dashboarden exponerad mot internet. En admin-inloggning som nås utan VPN eller IP-begränsning är själv en attackyta, inte bara ett övervakningsverktyg. Ett SIEM som själv blir hackat är förstås värre än att inte ha ett alls.
- Ingen ägare för regeljustering. Ett SIEM som ingen underhåller blir en logg-samling ingen tittar på. Utse en person eller ett team som äger regelverket löpande, och boka in en återkommande genomgång varje månad även när larmbilden känns lugn.
Felsökning: åtta vanliga fel och hur du löser dem
- Agent visas som “disconnected”. Kontrollera att port 1514 och 1515 är öppna mellan agent och manager, och att agentens tjänst faktiskt körs med
systemctl status wazuh-agent. En brandvägg mellan nätverkssegment är den vanligaste boven. - Dashboarden svarar inte efter installation. Vänta minst fem minuter efter installationsskriptet är klart, OpenSearch-indexeraren tar tid att initiera fullt ut första gången. Ett omstart av tjänsten löser problemet om väntetiden inte hjälper.
- “Unable to connect to Wazuh API” i dashboarden. Kontrollera att API-tjänsten lyssnar på port 55000 och att lösenordet i dashboardens konfiguration matchar det som sattes vid installationen. Verifiera även att brandväggen tillåter trafik lokalt mellan dashboard och manager.
- Inga FIM-larm trots ändrade filer. Syscheck körs enligt ett schema, standard var tolfte timme. Sätt
realtime="yes"på kritiska mappar för omedelbar upptäckt istället, men undvik det på stora mappar med hög skrivfrekvens. - Diskutrymmet tar slut på indexerarnoden. Sätt upp en index lifecycle-policy (ILM) som automatiskt raderar eller arkiverar index äldre än din retentionspolicy. Kontrollera diskanvändningen med
df -hsom en del av veckorutinen tills policyn är på plats. - Falska positiva från vanliga administrationsverktyg. Lägg till specifika undantag i regelfilerna istället för att stänga av hela regelgrupper, annars tappar du täckning på riktiga hot. Dokumentera varje undantag med en kommentar om varför det lades till.
- Agent-installationen misslyckas med certifikatfel. Kontrollera att serverns och agentens klockor är synkade, TLS-handskakningen avvisas ofta vid stora tidsskillnader. Kör
timedatectlpå båda sidor för att jämföra. - Hög CPU-belastning på managern. Vanligtvis orsakat av för breda syscheck-mappar eller för många aktiva dekoderregler samtidigt. Begränsa omfattningen och mät om innan du skalar upp hårdvaran, en felkonfigurerad regel kostar oftast mer prestanda än fler agenter gör.
Avancerade tips: skalning, API och hotintelligens
När miljön växer förbi en enda nod börjar de flesta team separera indexeraren till ett eget kluster med tre noder för redundans, samma mönster som rekommenderas för de flesta OpenSearch-baserade system i produktion. Wazuh API:et gör det möjligt att automatisera hela den processen, från att lägga till agenter till att hämta larmstatistik för egna dashboards eller ticketsystem.
Ett tre-nods indexerarkluster ger dig redundans om en nod går ner, samtidigt som söktiderna hålls nere även när datavolymen växer. Många team lägger dessutom till en index lifecycle-policy tidigt, så att gamla index automatiskt flyttas till billigare lagring eller raderas efter retentionsperioden istället för att fylla disken manuellt varje kvartal.
# Hämta senaste larmen via Wazuh API
curl -k -X GET "https://wazuh-manager-ip:55000/security/user/authenticate" \
-u wazuh:wazuh-wui-password
# Använd token från svaret i nästa anrop:
curl -k -X GET "https://wazuh-manager-ip:55000/alerts?limit=10" \
-H "Authorization: Bearer <token>"Koppla in externa hotintelligens-flöden
Wazuh kan berikas med externa hotflöden via integrationsmodulen, till exempel VirusTotal för filhash-kontroller eller Slack och e-post för larmnotiser i realtid. Det gör att teamet inte behöver sitta och bevaka dashboarden manuellt, larmen kommer till kanalen ni redan använder dagligen. Många team kopplar även på ramverk som NIST Cybersecurity Framework som referens när de bygger upp sin egen struktur för hur olika larmnivåer ska hanteras och eskaleras internt.
Wazuh, NIS2 och GDPR: vad kräver lagen egentligen
NIS2-direktivet, som Shattered.io tidigare gått igenom i detalj för svenska bolag, kräver att omkring 6 000 företag i Sverige har processer för att upptäcka och anmäla incidenter inom snäva tidsramar. Direktivet samordnas på EU-nivå av ENISA, som också publicerar vägledning för vilka tekniska kontroller som förväntas finnas på plats. Ett SIEM som Wazuh löser inte compliance-kravet i sig, men det ger den logg- och larmdata som en NIS2-incidentplan bygger på. Utan detektion finns det ingen incident att anmäla i tid, bara ett intrång som upptäcks långt senare.
Samma resonemang gäller GDPR. Om personuppgifter läcker har du enligt svensk och europeisk rätt 72 timmar på dig att anmäla till Integritetsskyddsmyndigheten, IMY. Den klockan startar när du borde ha upptäckt intrånget, inte när du faktiskt gjorde det. Ett fungerande SIEM krymper det gapet radikalt jämfört med att förlita sig på att någon extern part hör av sig.
Loggarna som Wazuh samlar in blir dessutom bevismaterial i efterhand. När IMY eller en revisor frågar exakt när ett intrång startade, vilka system som berördes och vilka data som flyttades, är det skillnaden mellan att kunna svara inom timmar och att behöva gissa baserat på minnesanteckningar från ett stressat incidentteam.
Vanliga frågor
Är Wazuh verkligen helt gratis att använda?
Ja, kärnplattformen är licensierad under GPLv2 och kostar inget att ladda ner, installera eller köra, oavsett hur många agenter du kopplar på. Wazuh Inc. säljer support och molnhosting som separata tjänster, men de är valfria. Den enda löpande kostnaden du garanterat har är serverdriften och den tid ditt team lägger på underhåll.
Klarar en enda server att driva Wazuh för ett litet företag?
Ja, för upp till omkring 25–50 agenter räcker en all-in-one-installation med 4 CPU-kärnor och 8 GB RAM enligt Wazuhs egna riktlinjer. Större miljöer bör separera indexeraren till egna noder innan prestandan börjar märkbart försämras.
Hur lång tid tar installationen från start till fungerande dashboard?
Räkna med 30–45 minuter för en van Linux-användare, inklusive nedladdning, installation och första inloggning. Att sedan finjustera regelverket och minska falska positiva tar snarare dagar till veckor, precis som beskrivs i avsnittet om din första vecka med larm ovan.
Kan Wazuh ersätta en brandvägg eller ett antivirusprogram?
Nej. Wazuh är ett detektions- och responssystem, inte ett förebyggande skyddslager. Det kompletterar brandväggar och antivirus genom att upptäcka det som redan tagit sig förbi dem, och kan i vissa fall agera automatiskt via active response när ett hot väl identifierats.
Fungerar Wazuh för molnmiljöer som AWS eller Azure?
Ja, Wazuh 4.14.7 har inbyggda moduler för att samla in loggar från AWS CloudTrail, Azure Activity Log och Google Cloud, utöver traditionella agent-baserade servrar och arbetsstationer. Det gör plattformen användbar även för team som kör helt molnbaserad infrastruktur utan egna fysiska servrar.
Behöver jag programmeringskunskap för att skriva egna regler?
Grundläggande XML-syntax räcker för de flesta anpassade regler och dekoder. Mer avancerad automatisering, som integrationer mot externa system via API:et, underlättas av grundläggande skriptkunskap i till exempel Python eller Bash, men är inget krav för att komma igång med grundfunktionerna.
Hur skiljer sig Wazuh från en enkel loggserver som bara samlar in data?
En loggserver lagrar data passivt. Wazuh analyserar den mot regelverk i realtid, korrelerar händelser mellan olika källor och kan agera automatiskt via active response, vilket en ren loggsamling aldrig gör på egen hand. Skillnaden märks tydligast första gången ett verkligt intrångsförsök faktiskt fångas upp i realtid istället för att upptäckas i efterhand.
Räcker Wazuh för att uppfylla NIS2-kraven helt på egen hand?
Nej. Wazuh ger detektionsdata, men NIS2 kräver också dokumenterade processer, riskbedömningar och en anmälningsrutin. Se det som den tekniska grunden en fungerande incidentplan bygger vidare på, inte en genväg förbi resten av regelverket.
Checklista innan du går live
Innan du kallar installationen klar och lutar dig tillbaka, gå igenom den här listan. Den fångar upp de vanligaste sakerna team missar mellan en fungerande testinstallation och en driftsäker produktionsmiljö, och bygger direkt vidare på de fallgropar och felsökningspunkter som beskrivits tidigare i guiden.
Skriv gärna ut listan eller lägg den i ett internt dokument som teamet kan bocka av gemensamt, snarare än att en enskild person går igenom den ensam. En andra uppsättning ögon fångar ofta detaljer som annars missas, särskilt när det gäller nätverksåtkomst och vilka portar som faktiskt är stängda mot internet.
- Admin-lösenordet är bytt och sparat i en lösenordshanterare, inte i klartext på servern
- Dashboarden är endast nåbar via VPN eller ett begränsat internt nätverk
- Minst de mest kritiska servrarna har en aktiv, ansluten agent
- FIM bevakar system- och konfigurationskataloger, inte tillfälliga mappar
- En index lifecycle-policy är på plats så disken inte fylls upp av misstag
- Active response är testat i en isolerad miljö innan det aktiveras mot produktion
- Ett team eller en person är utsedd att äga regeljustering löpande
- Larmnotiser går till en kanal, till exempel e-post eller Slack, som faktiskt bevakas
