Mod security 阻止对 URI 路径的 GET 请求 [英] Mod security Block GET request to URI path

问题描述

我需要阻止某个 URI 路径的 GET 请求.我正在使用异常模式，但我使用的是直块规则，我无法让规则正常工作

示例 GET/secure/test/bla/bla/示例 https://bla.bla.com/secure/test/bla/bla?www.test.com

SecRule REQUEST_URI "@streq \/secure\/test\/bla\/bla\?.+" \阶段:1,id:92,t:none,t:urlDecode,t:lowercase,t:normalizePath,deny,status:403,msg:'403 Access Denied',chain"SecRule REQUEST_METHOD "@streq post" "t:none,t:lowercase"

我可以用像这样的 reg 表达式来写这个吗?

SecRule REQUEST_URI "!@rx ^(:?\/secure\/test\/bla\/bla\?.+)$" \阶段:1,id:91,t:none,t:urlDecode,t:lowercase,t:normalizePath,deny,status:403,msg:'403 Access Denied',chain"SecRule REQUEST_METHOD "@streq post" "t:none,t:lowercase"

这些都不起作用，我不知道为什么，我需要以不同的方式编写正则表达式吗?

在第二条规则中是否需要添加"@rx?"!@rx 和@rx

有什么区别

解决方案

所以这是这个问题的延续:modsecurity 创建规则禁用 GET 请求

<块引用>

example GET/secure/test/bla/bla/示例https://bla.bla.com/secure/test/bla/bla/bla?www.test.com

我不知道这是什么意思.你能把它改写得更有意义吗?您是说 URL 将包含另一个域?

您提供的示例有几处错误.例如这部分:

"@streq \/secure\/test\/bla\/bla\?.+"

@streq 表示这是一个直接的字符串比较.所以你不能使用 ?.+ 部分 - 我猜这看起来是正则表达式的一部分?如果你想要一个正则表达式，那么这是默认的，所以不要包含 @streq 位:

"\/secure\/test\/bla\/bla\?.+"

我也不认为你需要逃避正斜杠，但这样做应该没有坏处.

你也有这个:

SecRule REQUEST_METHOD "@streq post" "t:none,t:lowercase"

当您想阻止 get 请求时，为什么要检查 post?

<块引用>

在第二条规则中我是否需要添加@rx?有什么区别在 "!@rx 和 @rx

之间

@rx 表示下面是一个正则表达式.正如我所说，它是默认值，因此不需要包含，因为除非提供另一个 @ 命令，否则将假定 @rx.

!@rx 表示应该不匹配正则表达式 - 即将此规则应用于与此正则表达式不匹配的任何请求.

<块引用>

我可以用像这样的 reg 表达式来写这个吗?

SecRule REQUEST_URI "!@rx ^(:?\/secure\/test\/bla\/bla\?.+)$" \阶段:1,id:91,t:none,t:urlDecode,t:lowercase,t:normalizePath,deny,status:403,msg:'403

拒绝访问',chain"SecRule REQUEST_METHOD "@streq post" "t:none,t:lowercase"

没有.这表示任何不匹配第一个正则表达式并且应该阻止帖子的内容.

因此对/anything 的 POST 请求将被阻止.并且不会阻止对/anything 的 GET 请求.这似乎与您想要的完全相反！尽管 POST 到/secure/test/bla/bla/仍将被允许，因为它与第一条规则不匹配，因此被允许通过.

我真的认为您需要学习 ModSecurity 的基础知识，因为您显然很难理解这一点.

ModSecurity 规则的基本语法是:

SecRule \VARIABLE_TO_CHECK \VALUE_TO_CHECK_FOR \ACTION_TO_TAKE_IF_MATCHED \

使用 \ 允许您将一条规则分隔为多个线路以提高可读性.

• VARIABLE_TO_CHECK 可以是 ModSecurity 变量列表中的任何一个(https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual#变量)

• VALUE_TO_CHECK_FOR 默认是正则表达式.虽然可以例如，更改为直接字符串比较.这将是与 VARIABLE_TO_CHECK 的值相比，如果它与ACTION_TO_TAKE_IF_MATCHED 将运行，如果不匹配则ModSecurity 将停止处理此请求的此规则并移动进入下一条规则.

• ACTION_TO_TAKE_IF_MATCHED 是操作列表(https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual#Actions).每个规则都必须有一个 id，然后通常要么阻止请求匹配以上(使用 deny)或白名单请求(使用允许).

例如:

SecRule \REQUEST_URI \"^/secure/test/bla/bla/.*" \ID:1234，拒绝"

将拒绝对/secure/test/bla/bla/的任何请求(GET 和 POST).

如果您想检查两个变量，那么您需要将两个不同的规则链接在一起，在这种情况下，任何破坏性操作(例如拒绝)仅在完整链匹配所有规则时才会发生 - 但令人困惑的是，第一个规则必须说明要采取的最终行动.

SecRule \REQUEST_URI \"^/secure/test/bla/bla/.*" \ID:1234，拒绝，链"安全规则\REQUEST_METHOD \得到"

因此，此规则将拒绝对以/secure/test/bla/bla/开头的任何位置的任何请求，这也是 GET 请求.

在构建链式规则时，它很快就会变得混乱，因此建议您首先测试每个单独的规则，以确认它在适当的情况下被阻止，然后将它们链接在一起.

正如我之前建议的，我强烈建议您购买并阅读 ModSecurity 手册 教您 ModSecurity 的工作原理.

I need to block the GET request for a certain URI path. I'm using anomaly mode, but im using a straight block rule, I cannot get the rule to work properly

example GET /secure/test/bla/bla/ example https://bla.bla.com/secure/test/bla/bla?www.test.com

SecRule REQUEST_URI "@streq \/secure\/test\/bla\/bla\?.+" \
 "phase:1,id:92,t:none,t:urlDecode,t:lowercase,t:normalizePath,deny,status:403,msg:'403 Access Denied',chain"
SecRule REQUEST_METHOD "@streq post" "t:none,t:lowercase"

Can I write this with a reg expression like so ?

SecRule REQUEST_URI "!@rx ^(:?\/secure\/test\/bla\/bla\?.+)$" \
 "phase:1,id:91,t:none,t:urlDecode,t:lowercase,t:normalizePath,deny,status:403,msg:'403 Access Denied',chain"
SecRule REQUEST_METHOD "@streq post" "t:none,t:lowercase"

These are not working and I cannot figure out why, do I need to write the regular expression in a different way?

In the secound rule do I need to add "@rx? whats the difference betweeen "!@rx and @rx

解决方案

So this is a continuation of this question: modsecurity create rule disable GET request

example GET /secure/test/bla/bla/ example
https://bla.bla.com/secure/test/bla/bla?www.test.com

I have no idea what this means. Can you rewrite it to be more meaningful? Are you saying the URL will contain another domain?

There's several things wrong with the examples you have given. For example this part:

"@streq \/secure\/test\/bla\/bla\?.+"

The @streq means this is a straight string comparison. So you cannot use ?.+ parts - which look to be part of regular expressions I guess? If you want a regular expression then that's the default so don't include the @streq bit:

"\/secure\/test\/bla\/bla\?.+"

I also don't think you need to escape the forward slashes but should do no harm to do that.

Also you have this:

SecRule REQUEST_METHOD "@streq post" "t:none,t:lowercase"

Why are you checking for post when you want to block get requests?

In the secound rule do I need to add "@rx? whats the difference betweeen "!@rx and @rx

@rx means what follows is a regular expression. As I say it is the default so doesn't really need to be included as @rx will be assumed unless another @ command is provided.

!@rx means the regular expression should not be matched - i.e. apply this rule to any request which does not match this regular expression.

Can I write this with a reg expression like so ?

SecRule REQUEST_URI "!@rx ^(:?\/secure\/test\/bla\/bla\?.+)$" \
 "phase:1,id:91,t:none,t:urlDecode,t:lowercase,t:normalizePath,deny,status:403,msg:'403

Access Denied',chain" SecRule REQUEST_METHOD "@streq post" "t:none,t:lowercase"

No. this says anything which does not match the first regular expression and also is a post should be blocked.

So POST request to /anything will be blocked. And GET request to /anything will not be blocked. This seems to be the exact opposite of what you want! Though a POST to /secure/test/bla/bla/ will still be allowed as it will not match the first rule and so be allowed through.

I really think you need to learn the basics of ModSecurity as you are obviously struggling to understand this.

The basic syntax of a ModSecurity rule is:

SecRule \
  VARIABLE_TO_CHECK \
  VALUE_TO_CHECK_FOR \
  ACTION_TO_TAKE_IF_MATCHED \

With the \ allowing you to separate a rule over several Iines for readability.

• VARIABLE_TO_CHECK can be any of a list of ModSecurity variables (https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual#Variables)

• VALUE_TO_CHECK_FOR is a regular expression by default. Though can be changed to be a straight string comparison for example. It will be compared to the value of the VARIABLE_TO_CHECK and if it matches the ACTION_TO_TAKE_IF_MATCHED will be run, if it doesn't match then ModSecurity will stop processing this rule for this request and move on to the next rule.

• ACTION_TO_TAKE_IF_MATCHED is a list of actions (https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual#Actions). Each rule must have an id and then usually either blocks requests that match above (using deny) or white lists requests (using allow).

So for example:

SecRule \
  REQUEST_URI \
  "^/secure/test/bla/bla/.*" \
  "id:1234,deny"

Will deny any requests to /secure/test/bla/bla/ (GET and POST).

If you want to check two variables then you need to chain two different rules together, and in this case any disruptive actions (e.g. deny) only happens if the full chain matches for all rules - but confusingly the first rule must state the ultimate action to take.

SecRule \
  REQUEST_URI \
  "^/secure/test/bla/bla/.*" \
  "id:1234,deny,chain"
 SecRule \
    REQUEST_METHOD \
    "GET"

So this rule will deny any requests to any location starting with /secure/test/bla/bla/ which is also a GET request.

When building chained rules it can quickly get confusing so suggest you test each individual rule first to confirm it blocks as appropriate and then chain the, together.

As I advised before, I strongly suggest you buy and read the ModSecurity handbook to teach you how ModSecurity works.

这篇关于Mod security 阻止对 URI 路径的 GET 请求的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！