0

Good Morning,

I am currently on creating a new mod security 2.5 rule.

My deployment: I have an Apache server in reverse proxy mode. This Apache server does not host the websites. Instead, I proxy the requests to another server that answers the web requests.

The web server uses authentication tokens to rewrite the website URL to a secure URL.

75.75.75.75 - - [01/May/2015:10:55:14 -0400] "GET /record/example.svc/js HTTP/1.1" 200 1786 "https://example.org/example.aspx?XOW%5eLdz%3c2%2f1%2f42%2527kbmhtbffJfx%3e0%2527qpkf%5ejc%3e2%2527Cfruho%60uhpmXOW%5eLdz%3c2%2f1%2f42%2527RptsbfVQU%60Jfx%3e193%2527qpkf%5ejc%3e2%2527RptsbfVQU%60Ejqts%60Bihmc%60Mblf%3cSdrtfru%1fTbpqjmh"

The Problem:

Modsecurity currently scans the URI. Due to the nature of the random URIs, a lot of false positives have been produced. To prevent this, I want to exempt all URIs from scanning.

Since the rewrite, redirect and authentication token are all being generated on the webserver (And this how we want to keep it), how do I inform mod security that these headers are legitimate and do not scan them?

75.75.75.75 - - [01/May/2015:10:55:52 -0400] "GET /thing.aspx?XOW%5eLdz%3c375%25cddnnd%60ttds%5ebt%60he%3c5%2f58328 HTTP/1.1" 200 15100 "https://example.org/example.aspx?XOW%5eLdz%3c2%2f1%2f42%2527kbmhtbffJfx%3e0%2527qpkf%5ejc%3e2%2527Cfruho%60uhpmXOW%5eLdz%3c2%2f1%2f42%2527RptsbfVQU%60Jfx%3e193%2527qpkf%5ejc%3e2%2527RptsbfVQU%60Ejqts%60Bihmc%60Mblf%3cSdrtfru%1fTbpqjmh"

 75.75.75.75 - - [01/May/2015:10:55:52 -0400] "GET /example/example.svc/js HTTP/1.1" 200 1786 "https://example.org/example.aspx?XOW%5eLdz%3c375%25cddnnd%60ttds%5ebt%60he%3c5%2f58328"
Arlion
  • 590
  • 1
  • 4
  • 17

2 Answers2

0

As far as I'm aware it is not possible to blanket ignore any particular part of the request (be it URI or any parameters) from all configured ModSecurity rules. While that may be useful it would likely open up a number of security holes.

So you just need to see which rules are failing and add white list exceptions for those rules.

If you give examples of some of the failing rules I might be able to suggest how to go about that if you need help with this.

Barry Pollard
  • 4,461
  • 14
  • 26
0

We ended up solving this issue by using another rule to not scan the URI.

SecRuleUpdateTargetById 950120 !ARGS:REQUEST_URI

This way this particular rule would not scan the URI but would still be scan the rest of the packet. It should be noted that this rule needs to be replicated for every rule you have.

Arlion
  • 590
  • 1
  • 4
  • 17