To block specific request methods, you will need to create a custom WAF rule and import it into the LoadMaster. Below is an example of a rule that will block all POST and GET requests to a VS. The WAF rule will be coded as follows:
SecRule REQUEST_METHOD "^POST$" "id:123,drop,msg:'A post request was received'"
Another way of doing this:
Example GET /secure/test/bla/bla/ example https://bla.bla.com/secure/test/bla/bla?www.test.com
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
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.
After pasting this into a text editor, save it as a .conf file extension. Import it into the LoadMaster under the Custom Rules section of the WAF Settings page. You can now assign this rule to a Virtual Sservice for production use.