Correo de fallo de VPN en FortiGate: filtre campos, no registros

Dentro de «envíame un correo cuando falle un inicio de sesión VPN» se esconden dos decisiones. La primera es cómo se entrega la notificación: un correo por evento, un resumen periódico o una alerta de un recopilador. La segunda es qué contiene el mensaje. Equivocarse en la primera inunda un buzón, y equivocarse en la segunda borra los campos que hacen que la alerta sea accionable. Ninguna de las dos decisiones exige suprimir la categoría de registro de VPN, que es el atajo que destruye en silencio el rastro de auditoría.

Tres formas de entrega y cuándo encaja cada una

Elija por quién responde y con qué rapidez puede hacerlo, no por qué opción es más fácil de configurar. Un solo FortiGate que protege una oficina puede justificar el correo por evento. La misma configuración en una pasarela que recibe intentos de relleno de credenciales produce miles de mensajes al día y acaba filtrada en una carpeta que nadie lee.

Parta del registro del evento, no de la línea de asunto

Lea un evento almacenado representativo en la versión que realmente ejecuta. La referencia de registros de FortiOS 7.4.8 identifica el fallo de inicio de sesión en SSL VPN como evento 39426, y sus campos incluyen action, user, remip, reason, tunneltype y vd. Diseñar un filtro a partir de un asunto de correo reenviado en lugar de ese registro es cómo la gente acaba coincidiendo con un nombre de campo que su firmware escribe de otra forma. Abra dos o tres fallos reales y confirme que los identificadores coinciden antes de escribir un desencadenador. Los cinco minutos que lleva son más cortos que una semana de alertas que saltan con el evento equivocado.

Una puntada de automatización une un desencadenador de registro de eventos con una acción, y el desencadenador es donde debe vivir la selección del evento. Añada solo las condiciones de campo adicionales que necesite su requisito; un desencadenador que filtra por un conjunto pequeño de campos sigue entregando un comportamiento no probado para el resto.

Construya un cuerpo compacto con sustituciones admitidas

En versiones que documentan la sustitución de campos de registro para acciones de correo, el cuerpo puede ser corto y seguir siendo útil. La forma de abajo es ilustrativa; confirme los nombres de atributo y la sintaxis de sustitución con la versión de firmware antes de aplicarla.

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

Una plantilla que muestra un campo vacío no demuestra que al evento le faltaran esos datos. Compruebe primero el nombre del campo y la sintaxis de sustitución, luego pruebe con un fallo controlado y lea el mensaje real. Añada la identidad del dispositivo y la hora de ocurrencia para que quien responda encuentre el registro completo sin adivinar qué unidad envió el correo.

Silencie el volumen sin borrar el registro

El control de ritmo, la agrupación y la correlación pertenecen a la capa de entrega. Subir la gravedad mínima del correo para todo es un instrumento contundente que oculta eventos no relacionados, y desactivar la categoría de registro de VPN es peor: los eventos dejan de escribirse del todo. Mantenga el destino de registro aprobado y la política de retención exactamente como estaban, y deje que el camino de notificación se vuelva más silencioso. Documente lo que suprimió, porque la siguiente persona encontrará un hueco en el buzón y necesita saber que fue deliberado.

Cuando el nuevo camino esté validado, retire cualquier regla de correo heredada que se solape mediante un cambio revisado. Terminar con dos caminos que saltan ambos, o con ninguno porque el viejo se desactivó primero, es un resultado habitual de hacer la limpieza antes de la prueba.

Lea un fallo como un fallo

Un evento de autenticación fallido no es una sesión VPN correcta, y un nombre de usuario en un evento no es una atribución verificada a una persona. Correlacione el motivo con inicios de sesión correctos, actividad conocida del usuario e intentos repetidos antes de declarar comprometida una cuenta, y diga en la alerta cuáles de esos comprobó.

Envíe la notificación solo a destinatarios autorizados. Los nombres de cuenta, los identificadores internos de dispositivo y las direcciones de origen son sensibles operativamente, y una lista de distribución que crece por comodidad se convierte en una vía de fuga. Un camino accionable más un rastro de auditoría intacto es todo el objetivo.