Mod安全阻止GET请求到URI路径 [英] Mod security Block GET request to URI path

查看:220
本文介绍了Mod安全阻止GET请求到URI路径的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我需要阻止某个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\?.+\ 
phase:1,id:92,t:none,t:urlDecode,t:小写,t:normalizePath,deny,status:403,msg:403访问拒绝',链
SecRule REQUEST_METHOD@streq postt:none,t:小写

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

  SecRule REQUEST_URI!@rx ^(:?\\ \ secure\ / test\ / bla\ / bla\?。+)$\ 
阶段:1,id:91,t:none,t:urlDecode,t:小写, t:normalizePath,deny,status:403,msg:'403 Access Denied',链
SecRule REQUEST_METHOD@streq postt:none,t:小写

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



在secound规则中,我是否需要添加@ RX !@ rx和@rx

解决方案

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


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


我不知道这意味着什么,你可以将它改写为更有意义吗?你说网址会包含另一个域吗?



例如这部分内容:

 @ streq \ / secure\ / test \ / bla \ / bla\。+

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

 \ / secure \ / test\ / bla \ / bla \?。+

我也不认为你需要避开正斜线,但应该不会这样做。



你还有这个:

  SecRule REQUEST_METHOD@streq postt:none,t:lowercase

当您要阻止获得发布 >请求?


在secound规则中,我是否需要添加@rx?什么是
之间的差异!@rx和@rx


@rx表示接下来是一个正则表达式。说它是默认的,所以不需要包含,因为除非另外提供@命令,否则将假定@rx。



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


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

  SecRule REQUEST_URI!@rx ^(:??\ / secure \ / test \ / bla\ / bla\?。+)$\ 
阶段:1,id:91,t:none,t:urlDecode,t:小写,t:normalizePath,拒绝,状态:403,msg:'403

访问被拒绝,链
SecRule REQUEST_METHOD @streq postt:none,t:lowercase


不, 匹配第一个正则表达式也是一个帖子应该被阻止。



因此POST请求/任何东西都会被阻止。
GET请求/任何东西都不会被阻塞。
这似乎与你想要的完全相反!
虽然/ secure / test / bla / bla /的POST仍然会被允许,因为它不符合第一条规则,因此可以通过。



我真的认为你需要了解ModSecurity的基本知识,因为你显然很难理解这一点。



ModSecurity规则的基本语法是:

  SecRule \ 
VARIABLE_TO_CHECK \
VALUE_TO_CHECK_FOR \
ACTION_TO_TAKE_IF_MATCHED \

$ p
$ b

$ \\ b
$ b

使用\\ ul>
  • VARIABLE_TO_CHECK可以是任何ModSecurity变量列表
    https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual#Variables


  • 默认情况下,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)。

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

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

    所以这个规则会拒绝任何以/ 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安全阻止GET请求到URI路径的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

    查看全文
    登录 关闭
    扫码关注1秒登录
    发送“验证码”获取 | 15天全站免登陆