3

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.

web.config

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

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.

Josh M.
  • 679
  • 1
  • 10
  • 21

2 Answers2

1

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.

Broco
  • 1,999
  • 13
  • 21
  • 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: `
    ` 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
1

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.

default.kramer
  • 126
  • 2