I've installed the ModSecurity IIS module on a Windows Server 2012 VM. I have a simple test application running on its own app pool.

default.aspx -- Just a simple page that spits out the date/time.


<?xml version="1.0" encoding="UTF-8"?>
        <ModSecurity enabled="true" configFile="C:\inetpub\wwwroot\modsecurity.conf" />


SecRuleEngine On
SecRule ARGS:testparam "test" "id:1234,deny,status:403,msg:'Our test rule has triggered'"

When I browse to the site (e.g. http://localhost?testparam=test), I am presented with my test page instead of a 403. There is nothing logged in the Event Viewer.


It seems likely that you are a victim of this issue: https://github.com/SpiderLabs/ModSecurity/issues/787

Broco's answer is close, but it doesn't call attention to the most important part: overrideModeDefault="Allow". If you check your C:\Windows\System32\inetsrv\Config\applicationHost.config file, you will probably see

<section name="ModSecurity" overrideModeDefault="Deny" allowDefinition="Everywhere" /></sectionGroup>

This needs to be changed to "Allow" or else adding <ModSecurity ...> to your website's config file will essentially just disable ModSecurity.


Did you edit the C:\Windows\System32\inetsrv\config? You have to enable modsecurity there by adding

<section name="ModSecurity" overrideModeDefault="Allow" allowDefinition="Everywhere" /></sectionGroup>

Also your configuration files should never, EVER be in your wwwroot. Put it in a safe spot, eg.:

configFile="C:\Program Files\ModSecurity IIS\modsecurity_iis.conf"

Also note that according to documentation the file should be called modsecurity_iis.conf on Windows.

  • I assumed the MSI installer would have done that sort of high-level configuration, but I'll verify. I'm just using wwwroot for example, will reference the OWASP rules which were installed by the MSI. – Josh M. Mar 20 '18 at 13:46
  • Well it's kind of a bad idea to have an installer manipulate config files that have more than one configuration in them. Your options are basically to replace the file with your own configuration (which would delete every custom configuration that isn't default), append your changes (which doesn't work in this case) or do complicated searches for strings which could change in the future and may not be consistent between machines. That's why not changing anything and just document the configuration is mostly the way to go. Since it's xml, maybe some day someone writes a UI for that. – Broco Mar 20 '18 at 14:04
  • Just FYI the section is already defined in applicationHost, but overriding is disabled by default: ` <section name="ModSecurity" overrideModeDefault="Deny" allowDefinition="Everywhere" /></sectionGroup>` still doesn't work though. – Josh M. Mar 20 '18 at 14:41
  • Did you rename the file to modsecurity_iis.conf? – Broco Mar 20 '18 at 15:02
  • Yes, I'm pointing to the correct file and see errors in the event log which are related to OTHER web apps on the same server. My test app is the ONLY one which has ModSecurity enabled, yet it's not working (nothing in log and I can't get a 403 to occur). – Josh M. Mar 20 '18 at 15:05

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.