4

我已经参考https://cloud.google.com/armor/docs/rules-language-reference设置了 Google Cloud Armor 安全策略。它工作得很好。检测到来自我办公室的模拟 SQL 注入攻击，随后的访问被阻止。Stackdriver 日志条目显示“拒绝”的相应强制安全策略结果，并且应用的表达式 ID 为“owasp-crs-v030001-id942421-sqli”。关键WAF规则如下：

evaluatePreconfiguredExpr('xss-stable') && evaluatePreconfiguredExpr('sqli-stable')

有一点我无法控制。在我的模拟攻击之后，我办公室的所有访问都被一路封锁。一旦我将 Cloud Armor 安全策略与 LB 分离并重新附加到 LB，我办公室的访问仍然被阻止。删除该安全策略并重新创建它并没有帮助。这意味着存在一个看不见的 SQLi 和 XSS 攻击者持久数据库，并且我的办公室 IP 可能已在其中注册，从而导致“所有时间”的拒绝。

问题是：如何在不修改规则的情况下从那个看不见的“SQLi 和 XSS 黑名单”数据库中删除我的 IP 以重新获得后端访问权限？在我们的 Cloud Armor 生产操作中，曾经被禁止的 IP 在其攻击源被移除后可能希望重新获得对目标后端服务的访问权限。

当然，如果我添加比 WAF 规则更高优先级的权限规则，我可以重新获得对目标后端的访问权限，但是会绕过 WAF 检查，这不是我想要的。

提前感谢您的宝贵时间。

栗岛

4

1 回答 1

2

我遇到了类似的情况，几乎得出了和你一样的结论——有某种隐藏的黑名单。但是在玩了更多之后，我发现，相反，我的请求中的一些其他非恶意 cookie 正在触发owasp-crs-v030001-id942421-sqli（“受限 SQL 字符异常检测（cookies）：超出特殊字符的数量（3）”——后来owasp-crs-v030001-id942420-sqli（ “受限制的 SQL 字符异常检测（cookies）：特殊字符数超出（8）”）。不是隐藏的黑名单。

据我所知，这两条规则使用 Cookies 标头中“特殊”字符的数量，而不是每个 cookie 中特殊字符的数量。此外，用于每个 cookie 的等号也算作特殊字符。与分号相同。恼人的。

所以这个请求会触发942420：

curl 'https://example.com/' -H 'cookie: a=a; b=b; c=c; d=d; e=e;'

这将触发 942421：

curl 'https://example.com/' -H 'cookie: a=a; b=b;'

所以最好禁用这两个规则，比如

evaluatePreconfiguredExpr('sqli-canary', [
 'owasp-crs-v030001-id942420-sqli',
 'owasp-crs-v030001-id942421-sqli'
])
于 2020-11-24T18:05:50.040 回答