FortiGate VPN-feil-e-post: filtrer felt, ikke logger

To beslutninger ligger i «send meg en e-post når en VPN-innlogging feiler». Den første er hvordan varselet leveres: én e-post per hendelse, et periodisk sammendrag eller et varsel fra en innsamler. Den andre er hva meldingen inneholder. Tar du feil i den første, oversvømmes en postkasse, og tar du feil i den andre, sletter du feltene som gjør varselet handlingsrettet. Ingen av beslutningene krever å undertrykke VPN-loggbetegnelsen, som er snarveien som stille ødelegger revisjonssporet.

Tre leveringsformer og når hver passer

Velg etter hvem som svarer og hvor raskt de kan, ikke etter hvilket alternativ som er enklest å konfigurere. Én enkelt FortiGate som beskytter ett kontor kan rettferdiggjøre e-post per hendelse. Samme konfigurasjon på en gateway som mottar forsøk på å fylle inn stjålne påloggingsdata produserer tusenvis av meldinger om dagen og ender i en mappe ingen leser.

Start ved hendelsesposten, ikke ved emnelinjen

Les en representativ lagret hendelse på versjonen du faktisk kjører. FortiOS 7.4.8-loggreferansen identifiserer mislykket innlogging på SSL VPN som hendelse 39426, og feltene inkluderer action, user, remip, reason, tunneltype og vd. Å designe et filter fra et videresendt e-postemne i stedet for fra den posten er hvordan folk ender med å matche et feltnavn som fastvaren deres staver annerledes. Åpne to eller tre reelle feil og bekreft at identifikatorene stemmer før du skriver en trigger. De fem minuttene det tar er kortere enn en uke med varsler som fyrer på feil hendelse.

En automatiseringssting kobler en hendelseslogg-trigger til en handling, og triggeren er stedet der hendelsesvalget hører hjemme. Legg bare til de ekstra feltbetingelsene kravet ditt trenger; en trigger som filtrerer på et lite sett felt leverer fortsatt uutprøvd atferd for resten.

Bygg en kompakt kropp av støttede erstatninger

I versjoner som dokumenterer loggfelterstatning for e-posthandlinger, kan kroppen være kort og likevel nyttig. Formen nedenfor er illustrativ; bekreft attributtnavnene og erstatningssyntaksen mot fastvareversjonen din før du tar den i bruk.

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 mal som viser et tomt felt beviser ikke at hendelsen manglet disse dataene. Sjekk feltnavnet og erstatningssyntaksen først, test deretter med én kontrollert feil og les den faktiske meldingen. Legg til enhetsidentitet og tidspunkt, slik at en responsansvarlig finner hele posten uten å gjette hvilken enhet som sendte e-posten.

Demp volumet uten å slette posten

Hastighetskontroll, gruppering og korrelasjon hører til leveringslaget. Å heve den minste e-postalvorligheten for alt er et grovt verktøy som skjuler urelaterte hendelser, og å slå av VPN-loggbetegnelsen er verre: hendelsene slutter helt å bli skrevet. Behold det godkjente loggmålet og oppbevaringspolicyen nøyaktig som de var, og la i stedet varslingsveien bli stillere. Dokumenter hva du undertrykte, for den neste personen finner et hull i postkassen og må vite at det var med vilje.

Når den nye veien er validert, avvikle enhver overlappende gammel e-postregel gjennom en gjennomgått endring. Å ende med to veier som begge fyrer, eller med ingen fordi den gamle ble slått av først, er et vanlig resultat av å gjøre oppryddingen før testen.

Les en feil som en feil

En mislykket autentiseringshendelse er ikke en vellykket VPN-økt, og et brukernavn i en hendelse er ikke verifisert tilskrivning til en person. Korreler årsaken med vellykkede innlogginger, kjent brukeraktivitet og gjentatte forsøk før du erklærer en konto kompromittert, og si i varselet hvilke av disse du sjekket.

Send varselet bare til autoriserte mottakere. Kontonavn, interne enhetsidentifikatorer og kildeaddresser er operativt sensitive, og en distribusjonsliste som vokser av bekvemmelighet blir en lekkasjevei. Én handlingsrettet vei pluss et intakt revisjonsspor er hele målet.