[OWASP-Columbia] Anyone have experience using the OWASP rules with ModSecurity on IIS?

William Scalf wscalf at gmail.com
Wed Jun 15 15:22:12 UTC 2016

Nevermind. It took some digging, but my problem wasn't with ModSecurity or
the OWASP rules - it was IIS internals. The ModSecurity configuration
section was apparently locked (by default?) and so the individual websites
weren't allowed to override it. I'm guessing the apparent changes in
behavior I was getting were incidental ... in any case, it's working now.


On Tue, Jun 14, 2016 at 9:00 PM, William Scalf <wscalf at gmail.com> wrote:

> I'm getting all kinds of bizarre behavior around the ModSecurity
> configuration section, though I'm hoping it's because this is my first time
> using it and I'm just doing something wrong. It looks like a really
> promising piece of software.
> So, the settings that go in the actual web.config file are pretty basic -
> it's a single element with 'enabled' and 'configFile' attributes that goes
> in the system.webServer sectiongroup. Okay. if I just do that, it appears
> to initialize ModSecurity but never loads the rules referenced by the
> configFile attribute. *But*, if I create an empty system.webServer
> sectiongroup under a location tag, put the element there and point it to
> the OWASP rules that get installed in the ModSecurity IIS folder, it loads
> them ... but when I try giving it a path to a different file for different
> rules (say, to set up overrides per website in addition to the OWASP rules,
> or even a simple config file with one rule in it for testing purposes),
> it..appears to keep reading the OWASP rules from the ModSecurity IIS
> folder, even after restarting the application pool, IIS, and Windows. In
> fact, I'm not sure it ever actually used the configFile attribute.
> I don't get why this is going on, and unfortunately, almost all of the
> documentation is for apache. I'm finding a few things for IIS, but they're
> all "happy path" type things that..aren't really helping here.
> Thoughts?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.owasp.org/pipermail/owasp-columbia/attachments/20160615/ad51ff21/attachment.html>

More information about the OWASP-Columbia mailing list