modsecurity阻塞但没有记录违法行为
因此，并不是没有日志，实际上有许多违规行为记录，这只是我与几个人遇到的问题。数以百万计的请求中有10次违规行为。为了使Modsecurity和后端违规之间的区分变得容易，我将SecdeFaultAction更改为406的状态，就像魅力一样。
这不是性能问题，Modsecurity服务器处于自动缩放组中，几乎没有征税。我可以在我们的Kinesis日志中看到406发送给用户的返回代码，并在其浏览器中实际看到406。不过没有相应的modscurity违反行为。
ModSecurity服务器都落后于负载平衡器，并且看不到用户IP，无论如何我都没有任何DOS或IP声誉。
我唯一需要继续的事情是，当我们发现这些特定用户登录时会触发
"request": "GET /a/environment_settings.js HTTP/2.0", "id": "930120"
"Matched Data: <omitted> found within REQUEST_COOKIES:access_token: <omitted>
。
SecRuleUpdateTargetByTag "attack-lfi" "!REQUEST_COOKIES:access_token"
930120 这个用户。不幸的是，我没有什么可继续的，因为当他们获得406时，没有记录。有一次941150会默默增加异常计数器，但该规则在这里没有发挥作用。我想知道是否还有其他规则可能会默默增加。或关于如何调试此问题的任何想法。
So it's not that there are no logs, there are actually many violations logged, its just an issue I'm having with a few people; 10s of violations out of millions of requests. To make it easy to differentiate between modsecurity and backend violations I changed SecDefaultAction to a status of 406, works like a charm.
It's not a performance issue, the modsecurity servers are in an auto-scaling group and hardly taxed. I can see in our Kinesis logs the return code of 406 being sent to the user, as well as actually seeing the 406 in their browser. There is no corresponding modsecurity violation though.
The modsecurity servers are all behind load balancers and dont see the users IPs, I dont have any DOS or IP Reputation on anyway.
The only thing I really have to go on is, while we were in DetectionOnly these particular users would trigger a 930120 when they logged in.
"request": "GET /a/environment_settings.js HTTP/2.0", "id": "930120"
"Matched Data: <omitted> found within REQUEST_COOKIES:access_token: <omitted>
We turned the rule on and I wrote the following in crs-after:
SecRuleUpdateTargetByTag "attack-lfi" "!REQUEST_COOKIES:access_token"
Everybody was fine logging in except for this one user. Unfortunately I have nothing to go on because while they get a 406, nothing is logged for it. At one time 941150 would silently increment the anomaly counter but that rule isn't in play here. I was wondering if there are any other rules that may silently increment. Or any thoughts on how to debug this.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
OWASP MODSECURITY CORE规则集合在这里开发。要使用CRS规则930120解决假阳性，您可以执行以下操作：
将以下调整规则放入CRS之后（您就在这里）。
我强烈建议可以在此处找到CRS共同领导基督徒的调整教程： https：/ /www.netnea.com/cms/apache-tutorials/ 。在这里，您还会找到一个调整备忘单。
在日志中，您应该看到增加异常分数的规则。不应该有一个规则默默增加。
OWASP ModSecurity Core Rule Set dev-on-duty here. To resolve the false positive with the CRS rule 930120 you can do the following:
Put the following tuning rule into crs-after (you're right here).
I highly recommend the tuning tutorials of CRS co-lead Christian that can be found here: https://www.netnea.com/cms/apache-tutorials/. There you'll also find a tuning cheat sheet.
In the logs you should see the rules that increment the anomaly score. There shouldn't be a rule that increments silently.