Du har sannolikt redan datan som krävs för att fånga brute force-försök tidigt. Problemet är att du bara ser det i efterhand, begravt i loggar som du tänkte kolla ”sen”.
Den här automatiseringen för Slack-inloggningsvarningar träffar små IT-team först, men marketing ops och byråägare känner också av det när ett kundkonto låses eller en webbplats börjar kasta inloggningsfel. Du får ett tydligt Slack-meddelande när misslyckade inloggningar sticker iväg, med antal och de IP-adresser som är inblandade.
Nedan ser du exakt hur flödet körs, vad det automatiserar och hur mycket tid och risk du sparar när det bevakar dina loggar varje dag.
Så här fungerar automatiseringen
Hela n8n-workflowet, från trigger till slutligt resultat:
n8n Workflow Template: Slack-varningar vid misstänkta inloggningsspikar
flowchart LR
subgraph sg0["Schedule Flow"]
direction LR
n0@{ icon: "mdi:play-circle", form: "rounded", label: "Schedule Trigger", pos: "b", h: 48 }
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/httprequest.dark.svg' width='40' height='40' /></div><br/>Fetch Logs"]
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/code.svg' width='40' height='40' /></div><br/>Count Failed Logins"]
n3@{ icon: "mdi:swap-horizontal", form: "rounded", label: "Failed Logins Threshold?", 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/slack.svg' width='40' height='40' /></div><br/>Send Anomaly Alert"]
n1 --> n2
n0 --> n1
n2 --> n3
n3 --> n4
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 n3 decision
class n1 api
class n2 code
classDef customIcon fill:none,stroke:none
class n1,n2,n4 customIcon
Problemet: toppar av misslyckade inloggningar försvinner i bruset
De flesta team missar inte misstänkt inloggningsaktivitet för att de inte bryr sig. De missar den för att logggranskning är tråkig, ojämn och lätt att skjuta till imorgon. Du kanske skummar en dashboard en gång om dagen och blir sedan uppslukad av kundjobb, kampanjer eller en backlogg av ”snabba fixar”. Under tiden kan en bot försöka logga in hundratals gånger mot några få konton, och den enda ”varningen” du får är en missnöjd användare som inte kan logga in. Det handlar inte bara om förlorad tid. Det är den gnagande osäkerheten att du upptäcker mönstret för sent.
Friktionen byggs på. Här är var det fallerar i verkligheten.
- Du har ingen konsekvent rutin för att kontrollera loggar, så toppar kan ligga oupptäckta i timmar.
- När du väl tittar filtrerar och räknar du för hand, vilket bjuder in misstag och ”ungefär”‑gissningar.
- Även om du upptäcker ett problem måste du ändå sammanfatta det för någon annan (ofta i Slack) innan någon agerar.
- Utan IP-kontekst slösar du tid på att ta reda på om det är en riktig attack eller bara en användare som glömt sitt lösenord.
Lösningen: schemalagda loggkontroller som bara larmar i Slack när det spelar roll
Det här n8n-workflowet körs enligt ett schema (ofta var 15:e minut) och kontrollerar dina senaste loggar automatiskt. Det hämtar en färsk batch poster från din loggkälla via en HTTP-förfrågan och analyserar dem för att hitta misslyckade inloggningshändelser (till exempel händelser märkta login_failure). Därefter räknar det hur många misslyckanden som inträffade under tidsfönstret och plockar ut de unika IP-adresserna som är inblandade, så att du direkt ser om det är en enskild ”stökig” användare eller många distribuerade försök. Till sist jämför det antalet med en tröskel du väljer (till exempel ”mer än 5”). Om den passerar gränsen postar n8n en Slack-varning med siffror och IP-detaljer. Om inte avslutas flödet tyst och väntar på nästa körning.
Workflowet startar med en tidsstyrd trigger så att du inte är beroende av minnet. Sedan hämtar det loggar, beräknar totalsumman för misslyckade inloggningar och gör en enkel ”är detta misstänkt?”-kontroll. När det är det får Slack ett meddelande som teamet kan agera på direkt.
Det här får du: automatisering vs. resultat
| Vad det här workflowet automatiserar | Resultat du får |
|---|---|
|
|
Exempel: så här ser det ut
Säg att du normalt kontrollerar loggar 3 gånger per dag och att varje kontroll tar cirka 20 minuter när du väl har filtrerat, räknat misslyckanden och kopierat IP:n till Slack. Det blir ungefär en timme om dagen. Med det här workflowet som kör var 15:e minut blir ”kontrollen” att läsa ett Slack-meddelande endast när antalet går över din tröskel (till exempel 5). De flesta dagar blir det noll meddelanden. En dålig dag lägger du kanske 5 minuter på att bekräfta IP:n och låsa ner åtkomst, i stället för att upptäcka det flera timmar senare.
Det här behöver du
- n8n-instans (testa n8n Cloud gratis)
- Alternativ för egen drift om du föredrar det (Hostinger funkar bra)
- Slack för att leverera varningar till teamet.
- Logg-API-endpoint för att hämta senaste loggposter.
- API-token eller nyckel (hämtas från din loggplattform eller appinställningar).
Svårighetsgrad: Nybörjare. Du klistrar in en API-URL, lägger till inloggningsuppgifter och justerar ett tröskelvärde.
Vill du inte sätta upp detta själv? Prata med en automationsexpert (gratis 15-minuters konsultation).
Så fungerar det
En tidsstyrd körning drar igång allt. n8n triggar enligt schema (många team kör var 15:e minut) så att misstänkta mönster inte väntar på att någon ska komma ihåg.
Loggar hämtas från ditt system. Noden HTTP Request anropar din logg-API-endpoint och returnerar senaste poster i JSON, med den autentiseringsmetod ditt system kräver.
Workflowet räknar ut det som spelar roll. Ett litet kodsteg filtrerar fram misslyckade inloggningshändelser (som login_failure), räknar totalen och samlar unika IP:n så att varningen har riktig kontext.
Slack pingas bara när tröskeln passeras. If-kontrollen jämför antalet misslyckanden med din tröskel. Om det ser misstänkt ut postas ett Slack-meddelande i vald kanal; om det är normalt bakgrundsbrus händer ingenting.
Du kan enkelt ändra tröskeln för misslyckanden så att den matchar din risktolerans baserat på din normala baslinje. Se hela implementationsguiden nedan för anpassningsalternativ.
Steg-för-steg-guide för implementering
Steg 1: Konfigurera schematriggern
Ställ in arbetsflödet så att det körs automatiskt enligt ett tidsschema.
- Lägg till och öppna Timed Run Trigger.
- Ställ in schemaregeln så att den körs varje minut genom att använda intervallfältet: minutes med minutesInterval satt till
1. - Anslut Timed Run Trigger till Retrieve Log Entries.
Steg 2: Anslut loggdatakällan
Hämta de senaste loggposterna från ert loggservers-API.
- Lägg till och öppna Retrieve Log Entries.
- Ställ in URL till
https://api.yourlogserver.com/logs/recent?limit=100. - Lämna Options tomt om inte ert API kräver extra headers eller autentisering.
- Anslut Retrieve Log Entries till Compute Failed Login Totals.
Steg 3: Konfigurera bearbetningsnoden
Beräkna totalsummor för misslyckade inloggningar och skapa ett sammanfattningsmeddelande för larmning.
- Lägg till och öppna Compute Failed Login Totals.
- Klistra in JavaScript i Code exakt som det visas för att beräkna antal och sammanfattningstext:
- Ställ in Code till
const failedLogins = $json.data.filter(log => log.event === 'login_failure'); const uniqueIps = [...new Set(failedLogins.map(log => log.ip))]; const loginFailureCount = failedLogins.length; return [{ json: { loginFailureCount, uniqueIps, firstFailedAttemptTime: failedLogins[0]?.timestamp, lastFailedAttemptTime: failedLogins[loginFailureCount - 1]?.timestamp, summary: `Detected ${loginFailureCount} failed login attempts from ${uniqueIps.length} unique IP(s): ${uniqueIps.join(', ')}` } }]; - Anslut Compute Failed Login Totals till Validate Failure Threshold.
Steg 4: Konfigurera utdata och routning
Larma endast när misslyckade inloggningar överstiger er tröskel och skicka sedan Slack-meddelandet.
- Öppna Validate Failure Threshold och ställ in villkoret för att kontrollera misslyckade inloggningar.
- Ställ in Left Value till
{{ $json.loginFailureCount }}och operatorn till number greater than. - Ställ in Right Value till
5så att larm endast triggas över 5 misslyckanden. - Öppna Dispatch Slack Alert och ställ in Text till
🚨 *SECURITY ALERT: High Volume of Failed Logins Detected!* 🚨\nSummary: *{{ $json.summary }}*\nFirst attempt: *{{ $json.firstFailedAttemptTime }}*\nLast attempt: *{{ $json.lastFailedAttemptTime }}*. - Ställ in Select till
useroch User till ert Slack-användar-ID (ersätt[YOUR_ID]). - Credential Required: Anslut era slackApi-uppgifter i Dispatch Slack Alert.
Steg 5: Testa och aktivera ert arbetsflöde
Verifiera flödet end-to-end innan ni aktiverar det i produktion.
- Klicka på Execute Workflow för att köra ett manuellt test.
- Kontrollera att Retrieve Log Entries returnerar data och att Compute Failed Login Totals matar ut
loginFailureCount,uniqueIpsochsummary. - Bekräfta att Validate Failure Threshold routar items till Dispatch Slack Alert endast när
loginFailureCountär större än5. - Verifiera att Slack-meddelandet kommer fram med ifyllda fält för sammanfattning och tidsstämplar.
- Växla arbetsflödet till Active för att aktivera schemalagd övervakning.
Vanliga fallgropar
- Inloggningsuppgifter för HTTP Request kan löpa ut eller kräva specifika behörigheter. Om det slutar fungera: börja med att kontrollera inställningar för API-nyckel/token hos din loggleverantör och request-headers i noden ”Retrieve Log Entries”.
- Om du använder Wait-noder eller extern rendering varierar processtider. Öka väntetiden om efterföljande noder failar på tomma svar.
- Slack-åtkomst kan fallera om appen inte får posta i kanalen. Verifiera Slack-credential-scopes i n8n och bekräfta kanal-ID i ”Dispatch Slack Alert”.
Vanliga frågor
Cirka 30 minuter om din logg-API och Slack-åtkomst är klara.
Nej. Du klistrar främst in detaljerna för din logg-API och justerar tröskeln. Det inkluderade kodsteget är redan skrivet; du ändrar bara om ditt eventnamn skiljer sig från login_failure.
Ja. n8n har ett gratis alternativ för egen drift och en gratis provperiod på n8n Cloud. Cloud-planer börjar på 20 USD/månad för högre volym. Du behöver också räkna in eventuella API-kostnader för loggplattformen, som ofta ingår i din befintliga plan.
Två alternativ: n8n Cloud (hanterat, enklast att komma igång) eller egen drift på en VPS. För egen drift är Hostinger VPS prisvärd och hanterar n8n bra. Egen drift ger obegränsade körningar men kräver grundläggande serverhantering.
Ja, och det bör du. Du kan ändra tröskeln i steget ”Validate Failure Threshold”, och du kan byta eventfilter i ”Compute Failed Login Totals” om dina loggar använder en annan etikett än login_failure. Vanliga justeringar är separata trösklar för kontorstid, att exkludera kända kontors-IP:n och att lägga till en andra Slack-kanal för toppar med hög allvarlighetsgrad.
Oftast är det ett behörighetsproblem i Slack-appen, eller så är kanal-ID fel. Anslut din Slack-credential på nytt i n8n, bekräfta att appen får posta meddelanden och dubbelkolla att du riktar mot exakt kanal i ”Dispatch Slack Alert”. Om det fungerar i ett manuellt test men fallerar schemalagt, leta efter utgångna tokens eller säkerhetspolicies i arbetsytan som kräver ny autentisering.
Tillräckligt för de flesta små team, så länge du hämtar en rimlig batch vid varje körning.
Ofta, ja, om du behöver riktig filtrering och kontroll. Zapier och Make är utmärkta för enkla ”en händelse sker, skicka ett meddelande”-upplägg, men loggscanning kräver ofta schemalagd hämtning, datatolkning och villkorsstyrd routing, vilket kan bli krångligt (och dyrt) när det växer. n8n håller allt i ett workflow, och egen drift gör att du inte räknar varje litet steg mot en task-gräns. Dessutom är kodsteget viktigt här eftersom det låter dig räkna antal och unika IP:n på ett ställe. Om du är osäker, prata med en automationsexpert så pekar vi dig till det enklaste alternativet som fortfarande fungerar.
När det här väl kör är du klar med att ”kolla loggar” och kan börja reagera på riktiga signaler. Ärligt talat är det hela poängen.
Kontakta oss
Hör av dig, så diskuterar vi hur just din verksamhet kan dra nytta av alla fantastiska möjligheter som AI skapar.