做过几年后端的兄弟都知道，公网就是个“黑暗森林”。你的服务器只要挂个公网 IP 裸奔，不出十分钟，绝对有无数个脚本小子和肉鸡开始拿扫描器对着你疯狂输出。爆破 SSH、扫 .env 文件、测 SQL 注入……这都是基操。
更恶心的是那种针对业务接口的 Layer 7 CC 攻击。平时看着风平浪静，一搞活动，短信接口被刷爆，数据库连接池被拖死，凌晨三点被监控告警的夺命连环 Call 叫醒，那滋味谁懂？
最近忍无可忍，给手头负责的一个项目套了个 gmssh WAF。今天不扯什么高大上的“零信任架构”、“全景态势感知”，就纯从干活的角度，看着后台的真实监控数据，聊聊这玩意儿到底能不能解决咱们的痛点。
一、 满屏的扫描日志
先看一眼“防护事件”的日志截图。对，这就是每天真实发生在服务器上的背景噪音。
- 看归属地： 立陶宛、葡萄牙，还有国内的各种云厂商 IP。很明显，这是一些自动化僵尸网络在无差别扫网。
- 看触发类型：
恶意扫描器防御、目录扫描防御（疯狂试探你的 404 链接）、XSS 防御、命令执行拦截。说白了，就是些没技术含量的自动化 Payload，想碰运气捡漏。 - 处理动作： 大部分是“仅拦截”，随它去。但注意看中间那条，触发了
机器人防护后，直接给上了 “临时封锁”（也就是关小黑屋）。这点很对脾气，对于那种高频死磕的爬虫，直接拉黑 IP 才是最省资源的。
以前没 WAF 的时候，这些垃圾请求全打在 Nginx 和后端的 Tomcat/Go 进程上，白白浪费 CPU 和带宽。现在 WAF 在最外层直接给掐了，后端日志干净了不少。
二、 硬核防 CC 才是保命利器
大部分 WAF 防防 SQLi 和 XSS 都没啥问题，但真遇到懂行的黑客专门针对你某个慢查询接口搞 CC 攻击，很多传统 WAF 就歇菜了（因为请求本身是合法的）。
gmssh 这里的“全局配置”是我觉得最实用的地方，完全是顺着后端的业务痛点来设计的：
- URL级 / API级 CC 防御： 这是真保命的功能。比如你的
/api/v1/login或者/api/v1/send_sms接口被盯上了，你可以针对这几个重灾区单独设限（比如 10秒内同一个 IP 只能请求 5 次）。它甚至能优于全局白名单生效，这意味着就算是有合作的第三方 IP，如果对方业务跑飞了疯狂请求，也能被按住，防止把你拖死。 - 人机验证（验证码拦截）： 这个太懂行了。当你没法精准判定某个 IP 是不是真人操作，但它的请求频率又很恶心时，直接给这个 URL 套个人机验证。是真人就点一下验证码，是 Python
requests写的爬虫直接原地卡死。防薅羊毛神技。 - 静态文件防护： 默认放行
JS、CSS、JPG这些静态资源。这很科学，静态资源本来就应该丢给 CDN 或者不用拦截，WAF 如果连一张图都要去过一遍正则引擎，不仅浪费 WAF 的性能，还会增加业务的 TTFB（首字节时间）延迟。
三、 大屏看板
最后说说首页的那个数据大屏。
说句掏心窝子的话，一线干活的研发和运维，平时谁有空盯着这种折线图看？只要告警群里没动静，我们就默认天下太平。
但是！这个大屏在关键时刻极其有用——尤其是向老板汇报的时候。
老板不懂什么是 XSS，也不懂什么是 CC，但他能看懂“历史拦截次数 37 次”、“今日拦截请求量”。当你指着这条平稳的吞吐量曲线，告诉老板：“昨天有一波来自立陶宛的恶意扫描，试图拿下我们的服务器权限，但被 WAF 在边缘节点直接清洗掉了，业务完全没受影响。”
这不比你解释半天底层代码怎么写的要强得多？（手动狗头）
