Att driftsätta Wazuh-regler ”på det försiktiga sättet” betyder oftast samma tråkiga loop: hämta filen, kopiera den till managern, validera, starta om och berätta sedan för teamet vad som hände. Och på något sätt går det ändå sönder vid sämsta möjliga tillfälle.
Detection engineers känner av det här först, men SOC-ansvariga och MSSP-operatörer får också hantera konsekvenserna. Den här Wazuh-deploy-automatiseringen gör en GitHub-commit till en kontrollerad driftsättning, med validering och en Telegram-uppdatering du faktiskt kan lita på.
Nedan ser du hur flödet går från ”commit pushad” till ”regel driftsatt och verifierad”, vad som kontrolleras längs vägen och hur du anpassar det till dina egna godkännanderegler.
Så fungerar automatiseringen
Hela n8n-workflowet, från trigger till slutresultat:
n8n Workflow Template: GitHub till Telegram: säkrare Wazuh-regelutskick
flowchart LR
subgraph sg0["Github Flow"]
direction LR
n0["<div style='background:#f5f5f5;padding:10px;border-radius:8px;display:inline-block;border:1px solid #e0e0e0'><img src='https://flowpast.com/wp-content/uploads/n8n-workflow-icons/github.dark.svg' width='40' height='40' /></div><br/>Github Trigger"]
n1["<div style='background:#f5f5f5;padding:10px;border-radius:8px;display:inline-block;border:1px solid #e0e0e0'><img src='https://flowpast.com/wp-content/uploads/n8n-workflow-icons/code.svg' width='40' height='40' /></div><br/>Extract Changed Files"]
n2["<div style='background:#f5f5f5;padding:10px;border-radius:8px;display:inline-block;border:1px solid #e0e0e0'><img src='https://flowpast.com/wp-content/uploads/n8n-workflow-icons/httprequest.dark.svg' width='40' height='40' /></div><br/>Download Rule"]
n3@{ icon: "mdi:cog", form: "rounded", label: "Upload a file", pos: "b", h: 48 }
n4["<div style='background:#f5f5f5;padding:10px;border-radius:8px;display:inline-block;border:1px solid #e0e0e0'><img src='https://flowpast.com/wp-content/uploads/n8n-workflow-icons/telegram.svg' width='40' height='40' /></div><br/>❌ Failure Message"]
n5["<div style='background:#f5f5f5;padding:10px;border-radius:8px;display:inline-block;border:1px solid #e0e0e0'><img src='https://flowpast.com/wp-content/uploads/n8n-workflow-icons/telegram.svg' width='40' height='40' /></div><br/>✅ Success Message"]
n6@{ icon: "mdi:cog", form: "rounded", label: "Restart Wazuh_manager", pos: "b", h: 48 }
n7@{ icon: "mdi:cog", form: "rounded", label: "Deploying the Rules", pos: "b", h: 48 }
n8@{ icon: "mdi:cog", form: "rounded", label: "Rule Validation", pos: "b", h: 48 }
n9["<div style='background:#f5f5f5;padding:10px;border-radius:8px;display:inline-block;border:1px solid #e0e0e0'><img src='https://flowpast.com/wp-content/uploads/n8n-workflow-icons/telegram.svg' width='40' height='40' /></div><br/>Rules deployment failed"]
n10@{ icon: "mdi:cog", form: "rounded", label: "No Operation, do nothing", pos: "b", h: 48 }
n11@{ icon: "mdi:swap-horizontal", form: "rounded", label: "Valid Commit for Deployment", pos: "b", h: 48 }
n12@{ icon: "mdi:swap-horizontal", form: "rounded", label: "Rule Validation check", pos: "b", h: 48 }
n13@{ icon: "mdi:swap-horizontal", form: "rounded", label: "Final Confirmation check", pos: "b", h: 48 }
n2 --> n3
n3 --> n8
n0 --> n11
n8 --> n12
n7 --> n6
n1 --> n2
n6 --> n13
n12 --> n7
n12 --> n9
n13 --> n5
n13 --> n4
n11 --> n1
n11 --> n10
end
%% Styling
classDef trigger fill:#e8f5e9,stroke:#388e3c,stroke-width:2px
classDef ai fill:#e3f2fd,stroke:#1976d2,stroke-width:2px
classDef aiModel fill:#e8eaf6,stroke:#3f51b5,stroke-width:2px
classDef decision fill:#fff8e1,stroke:#f9a825,stroke-width:2px
classDef database fill:#fce4ec,stroke:#c2185b,stroke-width:2px
classDef api fill:#fff3e0,stroke:#e65100,stroke-width:2px
classDef code fill:#f3e5f5,stroke:#7b1fa2,stroke-width:2px
classDef disabled stroke-dasharray: 5 5,opacity: 0.5
class n0 trigger
class n11,n12,n13 decision
class n2 api
class n1 code
classDef customIcon fill:none,stroke:none
class n0,n1,n2,n4,n5,n9 customIcon
Problemet: Wazuh-regeldeploys är sköra och bullriga
Regeldriftsättning låter enkelt tills du gör det varje vecka. Någon ändrar en XML-regel, kopierar den till Wazuh-managern, gör en snabb ”ser okej ut”-kontroll, startar om tjänster och väntar sedan på att se om något börjar brinna. Om valideringen hoppades över eller gjordes olika av olika personer märker du det först efter att omstarten misslyckas eller att managern vägrar ladda regler. Ännu värre: teamet får en halv berättelse i chatten: ”Jag deployade något, jag tror det funkade.” Den osäkerheten är dyr i SecOps eftersom den stjäl uppmärksamhet precis när du behöver fokus.
Friktionen byggs på. Här är var det fallerar i verkligheten.
- Manuell kopiering och omstarter blir lätt 30–60 minuter per deploy, särskilt när någon måste fjärransluta och dubbelkolla sökvägar.
- Felaktig XML kan slinka igenom och trigga en misslyckad omladdning, vilket skapar en mini-incident när larm slutar bete sig som de ska.
- Det finns ingen konsekvent revisionslogg, så i efterhand gissar du vilken commit som faktiskt hamnade i produktion.
- Notiser är ofta vaga, vilket gör att SOC ändå pingar ingenjören för status och sammanhang.
Lösningen: commit-till-deploy med validering och Telegram-bevis
Det här workflowet bevakar din GitHub-aktivitet och deployar bara när du uttryckligen ber om det. En commit kommer in, workflowet letar efter en deploy-signal (som #deploy-wazuh) och verifierar att författaren har rätt att pusha regler. Därefter tar det reda på vilka regelfiler som ändrats, laddar ner XML-innehållet från GitHub och överför filen till din Wazuh-manager via SSH. Innan det rör produktionsregler kör det validering (med standard XML-lintning) så trasig syntax aldrig når managern. Om valideringen godkänns deployar workflowet regeluppsättningen, startar om Wazuh-tjänsten, verifierar att allt laddas och skickar en tydlig Telegram-uppdatering med vad som ändrades och vad som hände. Om något misslyckas får teamet snabbt felorsaken, inte efter en massa gissande.
Workflowet startar på GitHub commit-triggern. Det förgrenar sig baserat på ”är detta en deploy-commit och är författaren godkänd”, och kör sedan en validera → deploya → starta om-sekvens. Telegram får ett lyckat- eller misslyckat-meddelande på slutet, så det blir inget mysterium.
Det här får du: automatisering vs. resultat
| Vad det här workflowet automatiserar | Resultaten du får |
|---|---|
|
|
Exempel: så här ser det ut
Säg att ditt team levererar Wazuh-regeluppdateringar två gånger i veckan. Manuellt tar det oftast 10 minuter att hämta rätt fil, cirka 15 minuter att kopiera den till servern och placera den rätt, ytterligare 10 minuter för validering och omstart, och sedan 10 minuter fram och tillbaka i chatten. Räkna med ungefär 45 minuter per deploy. Med det här workflowet är ”jobbet” att lägga till #deploy-wazuh i commit-meddelandet och pusha; resten körs hands-off och teamet får en Telegram-uppdatering när det är klart. Du granskar fortfarande regeländringen i GitHub, men servertrixandet försvinner till stor del.
Det här behöver du
- n8n-instans (prova n8n Cloud gratis)
- Alternativ för self-hosting om du föredrar det (Hostinger fungerar bra)
- GitHub för att trigga deploys från commits
- Telegram för att skicka uppdateringar om lyckad/misslyckad deploy
- SSH-åtkomst till Wazuh Manager (använd en SSH-nyckel på managern)
Kunskapsnivå: Medel. Du kopplar konton, lägger in inloggningsuppgifter och är bekväm med att ange SSH-detaljer och filsökvägar.
Vill du inte sätta upp det här själv? Prata med en automatiseringsexpert (gratis 15-minuters konsultation).
Så fungerar det
En GitHub-commit startar allt. Workflowet lyssnar efter nya commits och letar efter en deploy-markör i meddelandet så att vanliga commits inte råkar röra produktion.
Godkännandekontroller sker tidigt. En allow-lista verifierar commit-författaren och workflowet avslutas tyst om commiten inte ska deploya. Ingen dramatik.
Workflowet hämtar och validerar regelfilerna. Det identifierar vilka XML-filer som ändrats, laddar ner dem från GitHub, överför dem till Wazuh-managern och kör XML-validering så felaktiga regler inte går vidare.
Driftsättning och omstart automatiseras och rapporteras. Om valideringen godkänns deployar workflowet regeluppsättningen, startar om Wazuh-tjänsten och skickar Telegram-uppdateringar vid lyckat eller misslyckat resultat med tillräckligt med detaljer för att kunna agera.
Du kan enkelt ändra godkännandelogiken för att kräva en andra granskare eller begränsa deploys till vissa grenar utifrån dina behov. Se hela implementationsguiden nedan för anpassningsalternativ.
Steg-för-steg-guide för implementering
Steg 1: Konfigurera GitHub-triggern
Konfigurera arbetsflödet så att det startar när en GitHub-händelse inträffar och styr kvalificerande commits in i deploy-spåret.
- Lägg till och öppna GitHub Event Trigger för att definiera den webhook-baserade triggern för repository-händelser.
- Inloggningsuppgifter krävs: Anslut era GitHub-inloggningsuppgifter (noden kräver autentisering även om inga är konfigurerade i arbetsflödet).
- Anslut GitHub Event Trigger till Validate Commit for Deploy för att starta gate-logiken.
- I Validate Commit for Deploy definierar ni villkoren som kvalificerar en commit för deploy.
- Styr true-grenen till Derive Modified Files och false-grenen till No-Op Exit.
Steg 2: Koppla GitHub-data till filhämtning
Omvandla commit-data till en fillista och hämta sedan regelfilen från ert repository eller er lagring.
- Öppna Derive Modified Files och implementera kodlogiken som extraherar sökvägar till ändrade regelfiler från GitHub-payloaden.
- Anslut Derive Modified Files till Fetch Rule File för att hämta regelfilens innehåll.
- I Fetch Rule File konfigurerar ni HTTP-förfrågan för att hämta regelfilen (URL, metod och headers baserat på ert repo eller er lagring).
- Inloggningsuppgifter krävs: Anslut era inloggningsuppgifter för HTTP Request (om regelkällan är privat krävs autentisering).
Steg 3: Konfigurera regelvalidering och deploy-routing
Flytta regelfilen till målsystemet, validera den och avgör om deploy ska fortsätta.
- Öppna Transfer Rule File och konfigurera SSH-anslutningen och överföringskommandot.
- Inloggningsuppgifter krävs: Anslut era SSH-inloggningsuppgifter för Transfer Rule File, Validate Rule Set, Deploy Rule Set och Restart Wazuh Service.
- Anslut Fetch Rule File till Transfer Rule File och därefter till Validate Rule Set.
- Konfigurera Validate Rule Set för att köra valideringskommandot på serversidan.
- I Rule Check Branch definierar ni villkoren för godkänd/underkänd. Styr true-grenen till Deploy Rule Set och false-grenen till Deployment Failed Alert.
Steg 4: Konfigurera utdataåtgärder och notifieringar
Deploya reglerna, starta om tjänster och skicka notifieringar om lyckat eller misslyckat resultat via Telegram.
- Konfigurera Deploy Rule Set för att applicera regeluppsättningen på servern.
- Anslut Deploy Rule Set till Restart Wazuh Service för att läsa om regler efter deploy.
- Öppna Final Approval Gate och definiera er slutliga logik för godkänd/underkänd för att styra notifieringar.
- Styr true-grenen från Final Approval Gate till ✅ Success Notice och false-grenen till ❌ Failure Notice.
- Konfigurera Deployment Failed Alert, ✅ Success Notice och ❌ Failure Notice med meddelandeinnehåll och chatt-ID:n.
- Inloggningsuppgifter krävs: Anslut era Telegram-inloggningsuppgifter för alla Telegram-noder.
Steg 5: Testa och aktivera ert arbetsflöde
Verifiera hela deploy-kedjan från GitHub till server och säkerställ att notifieringar triggas korrekt.
- Klicka på Execute Workflow och trigga en GitHub-händelse (t.ex. en commit som ändrar en regelfil).
- Bekräfta att körvägen går från GitHub Event Trigger → Validate Commit for Deploy → Derive Modified Files → Fetch Rule File → Transfer Rule File → Validate Rule Set → Rule Check Branch → Deploy Rule Set → Restart Wazuh Service → Final Approval Gate.
- Verifiera att en lyckad körning avslutas vid ✅ Success Notice och en misslyckad körning avslutas vid ❌ Failure Notice eller Deployment Failed Alert beroende på gren.
- När allt är verifierat, växla arbetsflödet till Active för att aktivera produktionskörningar.
Vanliga fallgropar
- GitHub-inloggning och scopes spelar roll. Om workflowet inte kan hämta filer, kontrollera först behörigheterna för GitHub-token och repo-åtkomstinställningarna.
- Om du använder Wait-noder eller extern rendering varierar processningstider. Öka väntetiden om nedströmsnoder fallerar på tomma svar.
- SSH-deployar fallerar av enkla skäl: fel sökvägar, saknade sudo-rättigheter eller en roterad nyckel. Testa SSH-uppgifterna mot Wazuh-managern och bekräfta att kommandot för service-omstart fungerar icke-interaktivt.
Vanliga frågor
Cirka en timme om du redan har GitHub, Telegram och SSH-åtkomst redo.
Nej. Du klistrar mest in inloggningsuppgifter, anger filsökvägar och justerar ett par godkännandekrav.
Ja. n8n har ett gratis self-hosted-alternativ och en gratis provperiod på n8n Cloud. Molnplaner börjar på $20/månad för högre volym. Du behöver också räkna med vanliga infrastrukturkostnader som din Wazuh-server och VPS-hosting (ingen betald AI-API krävs för själva deployflödet här).
Två alternativ: n8n Cloud (hanterat, enklast att sätta upp) eller self-hosting på en VPS. För self-hosting är Hostinger VPS prisvärt och hanterar n8n bra. Self-hosting ger dig obegränsat antal körningar men kräver grundläggande serverdrift.
Ja, och det är en vanlig justering för MSSP:er. Du kan förgrena efter ”Final Approval Gate” och styra driftsättningar till olika SSH-mål baserat på repo, mappnamn eller branch. Vissa team mappar ”dev/staging/prod” till separata managers, medan andra deployar till flera managers parallellt. Se bara till att Telegram-meddelanden är miljöspecifika så att ingen misstar en dev-deploy för produktion.
Oftast är det ett tokenproblem: utgångna inloggningsuppgifter, saknat repo-scope eller att token inte kan läsa filsökvägarna du begär. Skapa en ny token, uppdatera den i n8n och bekräfta att workflowet pekar på rätt repo och branch. Om det bara fallerar under intensiva perioder kan du slå i API-gränser, så lägg till en kort fördröjning eller minska hur många filer du hämtar per körning.
Gott om för normalt regelarbete: dussintals filer per deploy är inga problem så länge din Wazuh-manager och GitHubs API-gränser hänger med.
Oftast, ja, eftersom det här inte är en enkel ”skicka ett meddelande när X händer”-automatisering. Du kör grindade godkännanden, filhämtning, SSH-överföringar, validering på servern och service-omstarter, vilket innebär att du behöver förgreningslogik och steg som passar infrastruktur. n8n passar den stilen bra och kan self-hostas, så du betalar inte per liten åtgärd när du skalar. Zapier eller Make kan fungera för Telegram-notis-delen, men de är klumpiga för själva deploymekaniken. Om du vill ha hjälp att välja, prata med en automatiseringsexpert.
När detta väl är på plats slutar driftsättning av Wazuh-regler att vara en ”försiktig ritual” och blir en kontrollerad, repeterbar åtgärd. Ditt team får tydlighet i Telegram, och du får tillbaka din tid.
Kontakta oss
Hör av dig, så diskuterar vi hur just din verksamhet kan dra nytta av alla fantastiska möjligheter som AI skapar.