0

I'm just reading up about - and experimenting with - modsecurity and hoping someone can educate a little about the method behind the madness.

The approach I'd ordinarily take with any firewall is to whitelist what I want to occur whilst blocking all else. Nothing I've read about modsecurity seems to take this approach, the focus seems wholely based around the rules matching known threats, with the exclusion based around disabling the appropriate IDs. I find this puzzling so I'm sure I have misunderstood the nature of either the threat or the program.

Surely the most water-tight modsecurity setup would be to match all expected requests whilst (.*?) everything else?

Andrew Schulman
  • 8,561
  • 21
  • 31
  • 47
befuddled
  • 1
  • 1
  • How do you know what's a valid request? – Michael Hampton Feb 12 '15 at 17:08
  • Well this is what i mean about the nature of the threat. For example my site involves user posting into a mysql db. The user input is all properly escaped prior to input so why can i not just match that POST request format as valid and block every other POST request rather than rely on a rule matching a known threat? – befuddled Feb 12 '15 at 17:23

1 Answers1

0

The approach you want can be done with ModSecurity. However if your application is 100% secure then you've no real need of a WAF like ModSecurity (why bother whitelisting the POST requests you want to allow in ModSecurity when you can just do this in the application?).

Generic ModSecurity rulesets like the OWASP rule set are designed to pick up generic threats rather than block or allow specific access to your URLs. They will not be designed for your application and specific setup. Specific rules can be added on top of them. Saying that there is still a lot of value in generic rulesets in that they have a lot of cumulative knowledge in them. You say your requests are "properly escaped" but that's not as easy a task as that simple statement makes out. There are various ways of getting around escaping (URL encoding, back slashing, double back slashing...etc), and each is different depending on all the pieces in your environment. The SQL injection checks in the OWASP rulesets for the example, have been built up over years and refined by the community around it. Also just because you have good escape checks on SOME area of the app doesn't mean that developers have remembered to do that for EVERY parameter/field. Or that the web or app server doesn't have some vulnerability before it even reaches your app.

Generally ModSecurity is an extra layer of protection for the fact that web servers kind of have to be open by their very nature. You cannot whitelist only good requests while blacklisting bad ones easily because of the open and differing nature of the web and how two similar requests (whether good or bad) can look completely different depending on who is sending them. You pretty much have to allow HTTP/HTTPS connections, you have to allow arguments like parameters and cookies, you have to allow GET requests though could restrict POST requests to specific URLs as you say.

ModSecurity allows you to have generic checks, allows you to have specific checks (though my personal preference would be to put those in the web app as much as possible unless a lot easier to implement in ModSecurity), and also has the added advantage in allowing you to quickly implement new tests and checks as the situation changes (e.g. zero day vulnerabilities, specific attacks and errors your spot with logging) giving you time to do the proper patch/fix later.

Think if it refining the attack surface. The main firewall restricts to port 80/443, your webserver and ModSecurity further strip out "bad requests", the application then does it's checks and finally you get to do what the app was intended for.

Yes it ideally we'd only whitelist allowed requests but the reality is that that is easier said than done...

Barry Pollard
  • 4,461
  • 14
  • 26