边缘防护之外的应用层加固思路

我踩过这个坑，而且踩得挺深。去年给一个客户站点开了宝塔的站点防火墙，第二天后台登录直接 403，上传附件卡死，异步接口报错。当时我第一反应是“先关掉再说”，手指都放到开关上了，硬是忍住了。因为我知道，关掉容易，再打开时那些被挡住的攻击也会一起回来。

后来我把这套流程捋顺了，现在遇到拦截基本不慌。

先说一个最容易搞混的判断：浏览器直接弹出宝塔那个拦截提示页，或者返回标准的 403，大概率是防火墙在边缘层拦的；如果是 500、502，或者应用自己吐出来的错误 JSON，那先别动防火墙，去查后端运行环境和数据库。这一步分错了，后面全是无用功。

确认是防火墙拦的，就做一件事：让业务同事把刚才那次操作原样再走一遍，同时记下精确到秒的时间、公网 IP、完整 URL 和请求方式。然后进防火墙插件的拦截日志，按 IP 和时间筛，看命中的是哪条规则——是 SQL 注入、XSS、POST 过滤，还是 CC 防御，具体卡在请求头、URL 参数还是表单体。有一次我死活找不到原因，最后发现是同事用 Postman 测试，User-Agent 被爬虫策略一票否决了，这种“冤枉”真的很常见。

找到证据再动手，而且一定要小步走。我的习惯是：只对那个出问题的路径做排除，比如某个保存接口频繁误触 SQL 规则，就在 URL 白名单里限定这一条路径跳过这一条规则，其他检查照旧。第三方回调这种固定来源的，用 IP 白名单加回调 URL 的组合放行，别把公开接口整个敞开。最忌讳的就是全局关掉某类防御，或者把业务目录整体放行——看着省事，其实是把门卸了。

改之前先截图或导出配置，写清楚改了哪条、针对哪个路径。改完用一模一样的请求体、IP 和客户端环境复测，确认响应码正常。然后拿一个明显带攻击特征的测试请求去访问非白名单路径，验证防护没被整体拉低。接下来两三个小时盯着实时日志，看有没有新的变相拦截，也看这条路径有没有被扫描工具盯上。一旦出现异常，按记录回滚，重新设计放行粒度。

最后说句实话：拦截日志只能说明流量在边缘被挡了，不代表后端漏洞修好了。那些高频触发拦截的入口，还是得在代码层做参数化查询、数据净化和权限校验。防火墙是缓冲，不是终点。