2

I am having difficulty creating a new mod security 2.5 rule.

My deployment: Apache server, Setup as a reverse proxy. (so the apache webserver __does not_ host the website. 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
  • Hi Arlion. Given the lack of answers, I'll vote in favour of migrating the question to ServerFault which is dedicated to system administration. –  Jun 17 '15 at 23:36
  • Thanks, the question has already been posted there with no answer. – Arlion Jun 18 '15 at 00:42
  • I think the issue is more on the question itself; you want to exclude all URI's from ModSecurity inspection; begs the question of why you want ModSecurity at all in this case as it will become completely redundant if instructed to not inspect any URI at all. – Oneiroi Jun 18 '15 at 14:15
  • The packet URI may be encrypted. But the remainder of the packet needs to still be subject to inspection. – Arlion Jun 18 '15 at 14:15
  • ModSecurity does not perform packet inspection, it is performing HTTP request inspection at the various stages of the HTTP transaction; I assume you wish to only negate false positives due to the URI? – Oneiroi Jun 18 '15 at 14:19
  • WAF is designed for deep packet inspection. Not only does it inspect just the HTTP Request and Response, but also the body of the payload. And you assumption is correct, I wish to negate false positives due to the URI being encrypted. – Arlion Jun 18 '15 at 14:23
  • The shortest method is to correlate your false positives and selectively disable the associated rules; it may be possible to negate URI inspection through source / rule modification however I could not give an direction here at this time. – Oneiroi Jun 18 '15 at 14:27
  • Let us [continue this discussion in chat](http://chat.stackexchange.com/rooms/24960/discussion-between-oneiroi-and-arlion). – Oneiroi Jun 18 '15 at 15:08

1 Answers1

0

Following the response in the comments on the original question;

In short it is not possible to negate the URI from inspection, ModSecurity is like other products rule/signature based.

What you can do however is get the ruleid for your false positives (from the apache error log for the VirtualHost) and perform a SecRemoveRuleById 123456 in your apache configuration, doing so will allow you to remove the false positives from being matched.

I would strongly suggest you do as selectively as possible via a LocationMatch directive or similar

Per chat, Hrvoje's shows an example or rule chaining which may be usefull

Community
  • 1
Oneiroi
  • 2,008
  • 1
  • 15
  • 28
  • Turning off rules compromises the WAF's ability to track legitimate exploits. This is not a solution and only penalizes the WAF for attempting to do its job. – Arlion Jun 18 '15 at 15:00
  • @Arlion hence the comment about using `LocationMatch` directive to ensure rules are only disabled for known falsepositives. – Oneiroi Jun 18 '15 at 15:04
  • In a location match I have to specify a URL in which I turn off a rule. Since all the websites have encrypted URIs, I would be turning off the rules globally. – Arlion Jun 18 '15 at 15:07
  • @Arlion, disabling inspection of URI is just as bad as disabling the rule in some cases, the URI can often be matched by signatures for known exploit locations; you can look at rule modification if you really must ignore the URI but that is not something I can help with. – Oneiroi Jun 18 '15 at 15:11