Many of our customers have Apache installations, large and small, and prefer to go with a software WAF rather than a device. Reasons will vary, but cost is always a concern and ModSecurity is free. :) You can pay Breach for rule support and commercial grade management appliances if you need it, cool stuff. What customers asked for though is a path to go from Sentinel identified vulnerabilities to custom ModSecurity rules (virtual patch) - VA+WAF.
Once Sentinel pinpoints the location of a vulnerability (class, url, parameter), its verified by our operations team, and a dynamically generated ModSecurity rule becomes part of the web-based reporting (see screenshot). The custom rule is a blacklist meta-character match narrowly focused on the vulnerable URL, parameter value (multiple params are supported), and class of attack. A parameter known to be vulnerable to SQL Injection probably has no legitimate use-case for receiving quotes, semicolons, dashes, parens, etc. Similar can be said for XSS.
Sentinel users then copy/paste the custom rule into their Apache config. We recommend the rule be tested in “pass” mode ensuring no false positives exist that might block legitimate traffic. Once confidence in the rule is established, which may take an hour to a couple days, “deny” mode can then be used to block attacks. False positives are minimal because only identified attack traffic where a vulnerability of that type is specifically known to exist in that location is affected. Finally the re-test button can test the single issue and should everything work properly the vulnerability status would be automatically closed out.
Hopefully in the coming months I’ll get some good case studies going and statistics to measure how the time-to-fix windows are shrunken.
8 comments:
Very very nice
I'd beware of false positives. This could cause DOS on a web site that implements automatic rules.
I always think automation is a bad idea when it comes to filtering unless of course AI is used and implemented well (But I don't think we're quite there yet).
@anonymous, thank you. We're hopeful we can knock out significant portions of XSS and SQLi this way.
@Gareth, this approach is not automatic though. Someone has to manually copy/paste the rule in and then when their ready, put it into deny mode, but only after testing first.
I've never had issues with mod_security other than the fact the way I have it set up does not include SQL injections. Everything else is nicely filtered and logged, but as I've said before it is not a replacement for securing one's code.
@andrew, agreed. Just looking to give people a little bit of time to improve the code without being easily exposed.
@Jeremiah
Ah, cool nice feature then :)
In reading through the rules... I saw the word xsshole...
a perfect term for those exploiting XSS.
apparently some of our developers have a sense of humor. :)
Post a Comment