国际威胁情报动态】FortiManager FGFM 未授权设备注册攻击：授权验证、日志留痕与修复核查

背景

近期边界安全设备仍是国际攻击活动中的高频入口。围绕 FortiManager FGFM 服务的攻击尤其值得关注：攻击者利用管理端对设备身份校验不足的问题，将未授权设备注册到 FortiManager，继而读取受管设备配置、凭据材料及网络拓扑信息。公开披露的典型问题为 CVE-2024-47575，影响面主要集中在对外暴露 TCP/541、允许未知设备注册且未及时升级的 FortiManager 环境。

这类事件不应只按“管理平台单点漏洞”处理。配置一旦泄露，攻击者通常会继续分析 VPN、管理口、地址对象、路由和内部网段，形成从边界设备到内网的后续攻击链。以下内容用于已获授权的漏洞验证和事件排查，不包含利用载荷。

问题定位

排查时先回答四个问题：FGFM 是否暴露到非管理网络、是否出现未知序列号注册、是否发生异常配置读取、相关管理凭据是否已被视为泄露。

授权验证步骤

验证目标是确认暴露面和控制措施是否有效，不要在生产环境尝试注册伪造设备。首先从指定测试节点执行端口可达性检查，并同步保存防火墙、负载均衡和 FortiManager 日志。

# 仅从已授权测试地址验证 TCP/541 暴露面
nmap -Pn -sT -p 541 --reason 192.0.2.10

# 验证管理路径，避免使用全网段扫描
nc -vz -w 3 192.0.2.10 541

# FortiManager CLI：核对版本、受管设备和当前会话
get system status
diagnose dvm device list
diagnose sys session list | grep ':541'

# 若具备经批准的系统日志读取权限，按 FGFM 及注册关键词筛查
grep -Eai 'fgfm|register|serial|unauthori|unknown' /var/log/fgfmd* | tail -n 300

端口开放本身不等于漏洞成立。应结合产品版本、厂商公告、未知设备拒绝策略和访问控制共同判断。扫描结果还需与防火墙会话日志交叉验证，避免被中间设备的端口代理或健康检查误导。

日志留痕与攻击链分析

建议以“源地址—设备序列号—注册时间—配置操作—后续登录”为主线建立时间轴。重点关注非管理网段访问 TCP/541、同一源地址尝试多个序列号、未知设备注册后立即触发配置同步，以及异常源地址随后访问 SSL VPN、SSH、HTTPS 管理端口等行为。

# 示例：在集中日志平台中聚合 TCP/541 连接
index=firewall dest_port=541 action=allowed
| stats count min(_time) as first_seen max(_time) as last_seen
  values(dest_ip) as targets by src_ip
| where count > 3

# 示例：关联 FGFM 访问与后续管理面活动
index=firewall (dest_port=541 OR dest_port=443 OR dest_port=22)
| transaction src_ip maxspan=30m
| search dest_port=541

上述查询需要按实际字段名调整。若存在 NAT，应同时保留转换前后地址、会话 ID 和设备时间；如果日志只记录出口 NAT 地址，需结合代理、VPN 和 DHCP 日志还原具体终端。所有设备应校准 NTP，否则事件时间线容易出现偏差。

关键配置核查

支持相应配置项的版本可拒绝未知设备。变更前应确认 FortiManager 版本、HA 状态及现有设备纳管流程，避免影响新设备上线。

config system global
    set fgfm-deny-unknown enable
end

# 修改后再次核查全局配置
show system global

同时在上游防火墙将 TCP/541 限制到明确的 FortiGate 管理地址或专用管理网段，不建议仅依赖互联网源地址黑名单。对于跨地域设备，可通过站点 VPN 或管理专线承载 FGFM 流量，并设置默认拒绝规则。

风险处置与修复建议

• 按照 Fortinet PSIRT 公告升级到对应产品分支的已修复版本，不要只套用临时访问控制代替升级。
• 立即隔离来源不明的受管设备记录，导出设备列表、管理员审计日志、FGFM 日志及防火墙会话后再删除，避免破坏证据。
• 若日志显示未知设备成功注册或读取配置，应按失陷事件处理，而不是普通漏洞整改。轮换 FortiManager 管理员密码、设备管理凭据、VPN 预共享密钥、API Token、证书私钥及配置中可恢复的密钥材料。
• 检查是否存在新增管理员、异常脚本、策略包修改和未授权配置下发，并将当前配置与可信基线进行差异比对。
• 对配置中暴露的内网地址、域控、堡垒机和 VPN 入口开展定向狩猎，重点检查来自异常地址的认证失败、成功登录及权限提升记录。
• 在边界策略中为 TCP/541 设置独立日志规则，记录允许与拒绝事件；日志至少发送到外部集中平台，避免设备本地日志被覆盖。

修复完成的判断标准不只是“版本已升级”，还应包括未知设备注册被拒绝、TCP/541 仅对授权地址可达、历史异常已完成溯源、泄露凭据已轮换，以及日志告警能够被实际触发。

总结

FGFM 相关攻击反映出当前威胁活动对边界管理平面的持续关注。授权验证应控制在版本确认、网络可达性、配置核查和日志关联范围内；一旦发现未知设备注册及配置读取迹象，应立即提升为事件响应。最有效的防线仍是修复版本、管理面隔离、拒绝未知设备、外部日志留存和凭据轮换的组合，而不是单一 IOC 封禁。

这类 FGFM 未授权注册通常对应 CVE-2024-47575。排查时不要只看设备是否出现在“未授权设备”列表里，攻击者注册后可能继续读取配置、执行脚本或删除设备记录。

建议按下面几个点核查：

1. 先确认注册是否有业务授权。 对 FortiManager 中近期新增、重新注册或序列号变化的设备，逐一核对 FortiGate 序列号、来源 IP、ADOM、首次出现时间和变更工单。来源 IP 可能经过 NAT，不能单独作为可信依据。

   get system status
   diagnose dvm device list
   show system global

2. 导出并保全日志后再删除可疑设备。 在事件日志中重点搜索 unregistered、unknown device、device added、install、script、admin 等字段，并关联同一时间段的管理员登录、管理员账户变更、脚本执行、策略包安装和配置导出记录。不同版本日志描述略有差异，建议至少覆盖告警前后 7 天。
3. 从网络侧确认谁在连接 FGFM。 FGFM 默认使用 TCP/541，可在 FortiManager 上短时抓包，核对连接源是否都属于受管 FortiGate：

   diagnose sniffer packet any 'tcp port 541' 4 0 l

   如果 FortiManager 的 541 端口直接暴露在公网，应优先在上游防火墙收敛，只允许各分支 FortiGate 的管理地址或 VPN 地址访问。
4. 拒绝未知设备注册。 在确认现有合法设备已纳管后启用：

   config system global
       set fgfm-deny-unknown enable
   end

   这项配置是缓解措施，不等同于修复；启用前要评估新设备上线、RMA 替换和 ZTP 流程，避免正常设备被拒绝。

修复方面，应升级到对应分支的安全版本：7.6.1、7.4.5、7.2.8、7.0.13、6.4.15、6.2.13 或更高版本，实际以 Fortinet 最新公告和设备支持矩阵为准。升级后建议做一次反向验证：使用未预授权的测试设备连接 TCP/541，确认 FortiManager 拒绝注册，同时检查事件日志是否产生拒绝记录。

如果已经发现陌生序列号、异常脚本或非计划配置导出，不建议只做升级和删设备。FortiManager 中可能保存下发到 FortiGate 的 VPN PSK、本地账户、SNMP、LDAP/RADIUS 等配置，应按泄露事件处理：轮换 FortiManager 管理员凭据、API Token、受管设备凭据以及配置中可复用的密钥，并检查是否新增管理员、修改信任主机或植入计划任务。