防火墙日志截图帮忙看看

看一下

看着这个是攻击日志，源地址是1.1.2.1，排查下这个地址

威胁日志 给命中了。

排除下有没有安全问题吧，没有的话 可以忽略 

请求 URL： /wp-content/plugins/wordfenceClass.php?file=../../wp-config.php 这是针对 Wordpress 的本地文件包含 / 目录遍历扫描（LFI），攻击者尝试读取wp-config.php拿到数据库账号密码，属于互联网上非常泛滥的自动化扫描器 / 爬虫探测。

日志动作：允许，日志，说明防火墙只是识别到这个攻击特征，没有拦截，只记录告警。 源 IP：公网 IP 111.26.205.168，目的 IP：1.1.1.252（就是你的防火墙管理地址），目的端口 443。

为什么会大量冒出这类日志（核心原因）

你的组网关键点：路由器做端口映射，把公网 443 端口映射到防火墙管理地址 1.1.2.252（防火墙透明串接在路由和核心之间）

1. 你把防火墙管理 443 直接暴露公网 互联网上有大量自动化扫描机器人，7×24 扫全网 443 端口，只要扫到开放 443，就会批量扔 Wordpress、php 类漏洞 Payload，试探是不是 WP 网站。 扫描器不管后端是什么设备，它只管发这套常见 EXP，报文穿过透明防火墙，防火墙 DPI 入侵防御引擎识别到 URL 特征，就生成这条威胁日志。 👉 不是内网有网站，是扫描器把你的防火墙管理口当成了 Wordpress 网站在踩漏洞。
2. 防火墙是透明模式，流量直接透传，入侵防御策略配置是alert-only（仅日志，放行），所以每条扫描报文都会生成一条日志，扫描器批量发包，日志就刷屏。
3. 扫描是公网批量爬虫，不是定向攻击，属于互联网常态 “噪音扫描”，但风险点在于：防火墙管理 HTTPS 直接对公网开放本身就是高危配置。

风险说明

• 当前这条 Payload 本身无法利用：你的目标是防火墙管理页面，不是 Wordpress，不存在wordfenceClass.php文件，这个探测不会拿下防火墙；
• 但是：公网直接暴露防火墙 443 管理，后续扫描器会持续尝试：弱口令爆破、SSL 漏洞、防火墙自身 CVE、管理接口漏洞，风险持续存在。

整改方案（按优先级）

✅方案 1【推荐，根治日志 + 消除风险】

删除路由器上 443 到防火墙管理地址的端口映射 防火墙管理严禁直接对公网开放。以后远程管理改成：

• IPsec/SSL VPN 先拨入内网，VPN 连通后再访问 1.1.2.252 管理；
• 或者只放通固定运维公网 IP 到 443（ACL 白名单），拒绝所有其他公网源访问防火墙 443。

映射删掉之后，公网流量到不了防火墙 443，这类扫描日志直接消失。

✅方案 2 暂时不想删映射，先优化 IPS 策略

1. 在入侵防御策略里，把这条 “敏感目录 / 文件访问” 的动作，从【允许，日志】改成 阻断 + 日志；

⚠️注意：只是阻断这条特征，扫描器还会换别的 payload 扫，日志只是少一部分，根源风险还在。

2. 配置 ACL，只允许运维固定公网 IP 访问 1.1.2.252:443，其余公网源全部拒绝。

✅方案 3 日志降噪（不解决安全风险，只减少告警刷屏）

如果短时间没法改映射，可以在 IPS 策略里，针对这个特征配置抑制日志，但不推荐，掩盖告警不利于发现真正攻击。

补充排查点

1. 确认：内网有没有 Wordpress 站点，是否路由器还有其他 443 映射指向内网服务器；如果内网有 WP 网站，那日志是扫网站的，就要给网站打补丁、加固 Wordfence 插件； 从这条日志目的 IP = 防火墙管理地址来看，目标是防火墙本身，不是内网网站。
2. 透明模式下防火墙 DPI 检测 HTTPS 报文：如果没有配置 SSL 解密，部分 HTTPS payload 识别不全；但这个扫描是 URL 明文在握手之后，引擎可以识别出 URI 特征，所以能产生日志。

一句话总结

日志刷屏根源：你把防火墙 HTTPS 管理 443 端口映射暴露在公网，全网自动化扫描机器人批量对 443 端口投放 Wordpress 漏洞探测包，防火墙 IPS 检测到攻击特征、只告警不拦截，大量日志产生。最大风险不是这条 LFI 能成功，而是防火墙管理面直接暴露公网。