Correo de fallo de VPN en FortiGate: filtre campos, non rexistros

Dentro de «envíame un correo cando falle un inicio de sesión VPN» escóndense dúas decisións. A primeira é como se entrega a notificación: un correo por evento, un resumo periódico ou unha alerta dun colector. A segunda é que contén a mensaxe. Equivocarse na primeira inunda unha caixa de correo, e equivocarse na segunda borra os campos que fan que a alerta sexa accionable. Ningunha das dúas decisións require suprimir a categoría de rexistro de VPN, que é o atallo que destrúe silenciosamente o rastro de auditoría.

Tres formas de entrega e cando encaixa cada unha

Escolla por quen responde e con que rapidez pode facelo, non por que opción é máis fácil de configurar. Un só FortiGate que protexe unha oficina pode xustificar o correo por evento. A mesma configuración nunha pasarela que recibe intentos de recheo de credenciais produce miles de mensaxes ao día e acaba filtrada nun cartafol que ninguén le.

Parta do rexistro do evento, non da liña de asunto

Lea un evento almacenado representativo na versión que realmente executa. A referencia de rexistros de FortiOS 7.4.8 identifica o fallo de inicio de sesión en SSL VPN como evento 39426, e os seus campos inclúen action, user, remip, reason, tunneltype e vd. Deseñar un filtro a partir dun asunto de correo reenviado en lugar dese rexistro é como a xente acaba coincidindo cun nome de campo que o seu firmware escribe doutro xeito. Abra dous ou tres fallos reais e confirme que os identificadores coinciden antes de escribir un desencadeante. Os cinco minutos que leva son máis curtos que unha semana de alertas que saltan co evento equivocado.

Unha puntada de automatización une un desencadeante de rexistro de eventos cunha acción, e o desencadeante é onde debe vivir a selección do evento. Engada só as condicións de campo adicionais que necesite o seu requisito; un desencadeante que filtra por un conxunto pequeno de campos segue entregando un comportamento non probado para o resto.

Constrúa un corpo compacto con substitucións admitidas

Nas versións que documentan a substitución de campos de rexistro para accións de correo, o corpo pode ser curto e seguir sendo útil. A forma de abaixo é ilustrativa; confirme os nomes de atributo e a sintaxe de substitución coa versión de firmware antes de aplicala.

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

Un modelo que mostra un campo baleiro non demostra que ao evento lle faltasen eses datos. Comprobe primeiro o nome do campo e a sintaxe de substitución, logo probe cun fallo controlado e lea a mensaxe real. Engada a identidade do dispositivo e a hora de ocorrencia para que quen responda atope o rexistro completo sen adiviñar que unidade enviou o correo.

Silencie o volume sen borrar o rexistro

O control de ritmo, a agrupación e a correlación pertencen á capa de entrega. Subir a gravidade mínima do correo para todo é un instrumento contundente que oculta eventos non relacionados, e desactivar a categoría de rexistro de VPN é peor: os eventos deixan de escribirse de todo. Manteña o destino de rexistro aprobado e a política de retención exactamente como estaban, e deixe que o camiño de notificación se volva máis silencioso. Documente o que suprimiu, porque a seguinte persoa atopará un oco na caixa de correo e necesita saber que foi deliberado.

Cando o novo camiño estea validado, retire calquera regra de correo heredada que se solape mediante un cambio revisado. Terminar con dous camiños que saltan ambos, ou con ningún porque o vello se desactivou primeiro, é un resultado habitual de facer a limpeza antes da proba.

Lea un fallo como un fallo

Un evento de autenticación fallido non é unha sesión VPN correcta, e un nome de usuario nun evento non é unha atribución verificada a unha persoa. Correlacione o motivo con inicios de sesión correctos, actividade coñecida do usuario e intentos repetidos antes de declarar comprometida unha conta, e diga na alerta cales deses comprobou.

Envíe a notificación só a destinatarios autorizados. Os nomes de conta, os identificadores internos de dispositivo e os enderezos de orixe son sensibles operativamente, e unha lista de distribución que medra por comodidade convértese nunha vía de fuga. Un camiño accionable máis un rastro de auditoría intacto é todo o obxectivo.