谷歌云赠金号 GCP谷歌云WAF规则配置

听说你刚在GCP上部署了新服务，还没上线就收到三封安全告警邮件，内容分别是：“检测到SQL注入尝试”、“疑似目录遍历攻击”、“大量403请求来自同一IP段”……别慌，这不是黑客攻破了你的VM，而是你的应用——正裸奔在互联网上，连件防弹背心都没穿。

今天咱们不聊概念，不甩术语，就干一件事儿：给你的GCP应用套上一件合身、能动、还带报警闪光灯的WAF外套。主角是Google Cloud Armor（GCP官方WAF），不是第三方插件，不是Cloud CDN的附属品，是原生、可编程、能和全球边缘节点联动的真·WAF。

一、先搞清：WAF不是“开箱即用”，它是“开箱即调”

很多同学以为点几下“启用WAF”按钮，系统就自动给你拦掉所有黑客。错。WAF像交警——它认识红灯，但不认识你家楼下那辆总乱停的电瓶车。它需要你告诉它：谁该放行？谁该扣分？谁该直接拖走？

GCP的WAF规则，本质是一组match + action逻辑链。比如：“如果http.request.headers['User-Agent']包含sqlmap，且http.request.uri.path以/api/开头，则deny”。写得越细，拦得越准；写得太宽，可能把自家运维脚本也封了——别笑，真有人把*curl*全干掉了，结果监控脚本全挂。

二、控制台实操四步走：从零建一条“封杀恶意扫描器”的规则

Step 1：入口在哪？别去Compute Engine里翻！
路径是：Network Services → Cloud Armor → Security policies → Create security policy。注意：它不在负载均衡页面，也不在防火墙规则里——这是独立模块，专治七层流量。

谷歌云赠金号 Step 2：起个有灵魂的名字
别叫policy-123，建议按用途+环境命名，比如：waf-prod-block-scanners-v2。为什么带v2？因为v1你肯定要删——第一次写的规则，八成会误伤。

Step 3：加第一条规则（核心！）
点击Add rule，填这些关键项：

• Priority：数字越小优先级越高。建议从1000开始，留出前面空间给紧急封禁（如临时封IP用999）；
• Description：写人话！例如：Block known scanner UAs: sqlmap, nikto, dirb；
• Match condition：点Add expression，选Request header → User-Agent → contains → 填sqlmap；再点OR加第二条：contains nikto；第三条：contains dirb；
• Action：选Deny with HTTP 403（别选Redirect，那是钓鱼网站干的事）；
• Preview mode?：新手必勾！它不真拦截，只打日志，让你看这条规则每天会“误伤”多少次。

Step 4：绑定到后端服务
创建完策略后，去Backend services或Global external application load balancer里，找到你的负载均衡器，在Security policy下拉框中选中它——这一步漏了，WAF就是个摆设雕塑。

三、进阶技巧：别只盯着User-Agent

真正的WAF高手，会组合五种“感官”来识别坏人：

• 嗅觉（Header）：检查X-Forwarded-For是否伪造，Referer是否为空或异常域名；
• 听觉（Method & Path）：GET /wp-admin/admin-ajax.php?action=xxx？大概率是WordPress爆破；
• 视觉（Body & Query）：用request.query_string匹配union select、sleep(5)等关键词（注意大小写和编码绕过！）；
• 触觉（Rate limit）：同一IP 1分钟内请求/login超15次？直接rateLimit并返回429；
• 直觉（Geo & ASN）：某非洲小国ASN批量扫你API？geoip.region_code == "XX"一键屏蔽（但慎用，别把海外用户一起封了）。

四、血泪教训：那些让WAF变“自残工具”的典型错误

• 错误1：用contains匹配admin，结果把/user/profile?search=admin也干掉了
→ 改用matches regex，写^/admin/.*$，锚定路径开头。

• 错误2：封IP段写成192.168.1.0/24，结果把内网所有服务全断了
→ GCP里真实客户端IP经过多层代理，source_ip默认是CDN节点IP。要用http.request.headers['X-Forwarded-For']提取，并配合evaluatePreconfiguredExpr('sourcerange')做CIDR校验。

• 错误3：Preview模式开太久，以为“没报错=没问题”，正式启用后才发现监控告警炸了
→ Preview只记录，不拦截。上线前务必切回Enforce模式，盯2小时日志，确认无误再发朋友圈庆祝。

五、日志怎么查？别再手动翻Stackdriver了

进Logging → Logs Explorer，输入以下查询（复制粘贴就能用）：

resource.type="cdn" 
logName="projects/YOUR-PROJECT-ID/logs/cloudarmor.googleapis.com%2Frequests" 
jsonPayload.statusDetails="security_policy_rule_blocked"

然后点右上角Save query，以后一键打开。重点看：jsonPayload.ruleName（哪条规则触发）、jsonPayload.clientIP（攻击源）、jsonPayload.requestUrl（被扫接口）。发现误拦？立刻去规则里加AND NOT条件排除。

六、最后送你三条保命口诀

✅ 口诀一：宁可漏一千，不可错杀一个
先Preview，再Enforce；先封单IP，再扩CIDR；先拦UA，再审参数。

✅ 口诀二：规则越短，越不容易翻车
一条规则只做一件事。想同时拦UA+路径+参数？拆成三条，每条单独测试。

✅ 口诀三：WAF不是终点，是起点
它拦不住0day，也防不了业务逻辑漏洞。把它当成第一道哨兵，后面还得配Secret Manager管密钥、IAM最小权限、审计日志定期巡检——安全，从来不是单点突破，而是一张网。

好了，现在你可以关掉这篇，打开GCP控制台，新建第一条WAF规则了。记住：别怕删重来，GCP允许你每秒改10次策略——它比你的咖啡续杯还快。

祝你，代码无bug，WAF不误拦，半夜不收告警短信。