FortiGate VPN 失败邮件：过滤字段，而不是日志

选择通知形式，用事件 39426 的字段来构建，然后在不关闭 VPN 日志类别或审计线索的情况下压低邮件量。

「VPN 登录失败时给我发邮件」这句话里藏着两个决定。第一个是通知怎么送达：每个事件一封邮件、定期摘要，还是由采集器发出告警。第二个是邮件里放什么。第一个选错会淹没邮箱，第二个选错会删掉让告警可执行的那些字段。这两个决定都不需要压制 VPN 日志类别——那条捷径会在无声中破坏审计线索。

三种投递形式及各自适用时机

形式适用时机代价
按事件触发的自动化邮件量小，一个团队就能响应一波尝试就会变成邮箱洪水
定时摘要例行复核、观察趋势没人能看到正在进行的尝试
带关联的采集器告警量大，共享 SOC又多一套需要喂养和调优的系统

选择依据应该是谁来响应、响应能有多快，而不是哪个选项最容易配置。只保护一个办公室的一台 FortiGate，按事件发邮件是合理的。同样的配置放在一台承受撞库尝试的网关上，每天会产生数千封邮件，最后被过滤进没人看的文件夹。

从事件记录开始，而不是从主题行开始

在实际运行的版本上读一条有代表性的已存储事件。FortiOS 7.4.8 日志参考把 SSL VPN 的登录失败识别为事件 39426，其字段包括 action、user、remip、reason、tunneltype 和 vd。用转发的邮件主题而不是那条记录来设计过滤器，正是人们最终去匹配一个固件拼写不同的字段名的原因。先打开两三次真实失败，确认标识符一致，再写触发器。花掉的五分钟，比一周里对着错误事件触发的告警要短。

自动化拼接把事件日志触发器与动作连在一起，而触发器正是事件筛选该待的地方。只添加需求确实需要的额外字段条件；只过滤少量字段的触发器，对其余部分依然会带来未经测试的行为。

用受支持的替换构建精简正文

在记录了邮件动作的日志字段替换的版本中，正文可以很短却依然有用。下面的形式只是示例；采用之前，先对照固件版本确认属性名和替换语法。

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

模板渲染出空字段，并不能证明事件缺少那项数据。先检查字段名和替换语法，再用一次受控失败做测试，并读实际收到的邮件。加上设备标识和发生时间，响应者就不必猜是哪台设备发的邮件，也能找到完整记录。

压低邮件量，但不要删除记录

速率控制、分组和关联属于投递层。为所有邮件统一提高最低严重级别是一把钝器，会连带掩盖不相关的事件；而关闭 VPN 日志类别更糟：事件根本不再被写入。按原样保留已批准的日志目的地和保留策略，改为让通知路径安静下来。把你压制了什么写进文档，因为下一个人会在邮箱里发现缺口，需要知道那是有意为之。

新路径验证通过后，通过经过评审的变更下线任何重叠的旧邮件规则。最后变成两条路径同时触发，或者因为先停用了旧路径而两条都不触发，都是把清理放在测试之前的常见结果。

把失败当作失败来读

认证失败事件不是成功的 VPN 会话，事件里的用户名也不是对某个人的已核实归因。在宣布账户被入侵之前，先把原因与成功登录、已知用户活动和重复尝试做关联，并在告警里说明你核对了其中哪几项。

只把通知发给获授权的收件人。账户名、内部设备标识和源地址在运营上都属敏感信息，而为了方便不断扩大的分发列表会变成泄露通道。一条可执行的路径，加上完整的审计线索，就是全部目标。

相关文章