Mod security Block GET request to URI path

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.