FortiGate VPN-felmejl: filtrera fält, inte loggar
Välj aviseringens form, bygg den från fälten i händelse 39426 och dämpa sedan volymen utan att stänga av VPN-logkkategorin eller granskningsspåret.
I «mejla mig när en VPN-inloggning misslyckas» gömmer sig två beslut. Det första är hur aviseringen levereras: ett mejl per händelse, en periodisk sammanfattning eller en varning från en insamlare. Det andra är vad meddelandet innehåller. Fel på det första dränker en brevlåda, och fel på det andra raderar fälten som gör varningen användbar. Ingen av besluten kräver att VPN-logkkategorin undertrycks, och det är genvägen som tyst förstör granskningsspåret.
Tre leveransformer och när var och en passar
| Form | Passar när | Kostnad |
|---|---|---|
| Automatiseringsmejl per händelse | låg volym, ett team svarar | en skur av försök blir en brevlådeöversvämning |
| Schemalagd sammanfattning | rutinkontroll, trendbevakning | ingen ser ett försök pågå |
| Insamlarvarning med korrelation | hög volym, delad SOC | ännu ett system som måste matas och trimmas |
Välj efter vem som svarar och hur snabbt den kan, inte efter vilket alternativ som är enklast att konfigurera. En enda FortiGate som skyddar ett kontor kan motivera mejl per händelse. Samma konfiguration på en gateway som tar emot försök att fylla i stulna inloggningsuppgifter producerar tusentals meddelanden om dagen och filtreras till en mapp som ingen läser.
Börja vid händelseposten, inte vid ämnesraden
Läs en representativ lagrad händelse på den version du faktiskt kör. FortiOS 7.4.8-loggreferensen identifierar misslyckad inloggning mot SSL VPN som händelse 39426, och fälten omfattar action, user, remip, reason, tunneltype och vd. Att designa ett filter från ett vidarebefordrat mejlämne i stället för från den posten är hur folk till slut matchar ett fältnamn som deras firmware stavar annorlunda. Öppna två eller tre verkliga fel och bekräfta att identifierarna stämmer innan du skriver en trigger. De fem minuter det tar är kortare än en vecka av varningar som utlöses på fel händelse.
En automatiseringssöm kopplar en händelseloggtrigger till en åtgärd, och triggern är platsen där händelsevalet hör hemma. Lägg bara till de extra fältvillkoren som ditt krav behöver; en trigger som filtrerar på en liten uppsättning fält levererar fortfarande otestat beteende för resten.
Bygg en kompakt kropp av stödda ersättningar
I versioner som dokumenterar loggfältsersättning för mejlåtgärder kan kroppen vara kort och ändå användbar. Formen nedan är illustrativ; bekräfta attributnamnen och ersättningssyntaxen mot din firmwareversion innan du använder den.
config system automation-trigger
edit "ssl-vpn-login-fail"
set event-type event-log
set logid 39426
next
end
config system automation-action
edit "mail-vpn-fail"
set action-type email
set email-to "[email protected]"
set email-subject "SSL-VPN login failed"
set message "Account: %%log.user%% | Source: %%log.remip%% | Reason: %%log.reason%%"
next
end
En mall som visar ett tomt fält bevisar inte att händelsen saknade dessa data. Kontrollera fältnamnet och ersättningssyntaxen först, testa sedan med ett kontrollerat fel och läs det faktiska meddelandet. Lägg till enhetsidentitet och tidpunkt så att en svarare hittar hela posten utan att gissa vilken enhet som skickade mejlet.
Dämpa volymen utan att radera posten
Hastighetskontroll, gruppering och korrelation hör till leveranslagret. Att höja den lägsta mejlallvarligheten för allt är ett trubbigt verktyg som döljer orelaterade händelser, och att stänga av VPN-logkkategorin är värre: händelserna slutar helt att skrivas. Behåll det godkända loggmålet och bevarandeprincipen exakt som de var, och låt i stället aviseringsvägen bli tystare. Dokumentera vad du undertryckte, för nästa person hittar en lucka i brevlådan och måste veta att det var avsiktligt.
När den nya vägen är validerad, avveckla varje överlappande gammal mejlregel genom en granskad ändring. Att sluta med två vägar som båda utlöses, eller med ingen eftersom den gamla stängdes av först, är ett vanligt resultat av att städa före testet.
Läs ett fel som ett fel
En misslyckad autentiseringshändelse är inte en lyckad VPN-session, och ett användarnamn i en händelse är inte verifierad tillskrivning till en person. Korrelera orsaken med lyckade inloggningar, känd användaraktivitet och upprepade försök innan du förklarar ett konto komprometterat, och säg i varningen vilka av dessa du kontrollerade.
Skicka aviseringen endast till behöriga mottagare. Kontonamn, interna enhetsidentifierare och källadresser är operativt känsliga, och en distributionslista som växer av bekvämlighet blir en läckväg. En användbar väg plus ett intakt granskningsspår är hela målet.