Installing ModSecurity on IIS7.X
ModSecurity is an open-source web application firewall that has been widely deployed on Apache based web servers to protect web applications from security vulnerabilities and has recently been made available in a stable version for IIS based servers from version 7.X and above. However, installing ModSecurity on your windows cloud servers running IIS7.X could be problematic and I wanted to provide a little guidance around installing it and getting it running an initial ruleset in monitor and report mode only.
As always: This is based on my experiences installing this and your experiences may differ, so your mileage may vary and remember always have a good backup before installing any new software on your server.
Why would I need/want ModSecurity on my web server?
Today over 70% of all attacks are carried out over the web application level. This includes things like sql injection, cross site scripting and bruteforce login attempts. Today’s web servers are able to provide really good logging of who has visited your site and what pages they went to, but when hackers visit your site and start uploading malicious content or exploits against your web applications (DotNetNuke, WordPress, Joomla, Ecommerce, etc) you’re left without any information and often only find out about the attacks when it’s too late. At Applied Innovations, we use multiple layers of security on our servers including a network edge IPS device but ModSecurity can still provide added protection and in the event you’re not behind an IPS fill this void and provide full logging of the HTTP requests and responses so you can see exactly what’s being sent over. But it doesn’t stop there.
ModSecurity will also monitor all of your HTTP traffic in real time in order to detect attacks and can even provide protection against anomalies, unusual behavior and common web application attacks. ModSecurity relies on a ruleset that provides protection against common attacks as they are discovered and frequently you can deploy a new rule in a matter of minutes where patching a vulnerable web application could take weeks. ModSecurity provides you the ability to protect your application immediately while still providing your developers time to update and test the code necessary to fix the application.
Installing ModSecurity on Windows Server
Microsoft’s Web Platform Installer (WebPI) has become the defacto tool when deploying a new web server. You can quickly install and configure a wide range of applications and scenarios using it and it has really streamlined deployment of new servers. ModSecurity can be deployed using WebPI by simply clicking ModSecurity in WebPI, clicking on the install button:
BUT DON’T GO RUSHING OFF TO DO THAT JUST YET.
You’re going to want to make sure your pre-requisites are in place first. Before you install ModSecurity, you’ll want to install the Visual Studio 2010 runtime libraries. If you’re on a 32bit OS (Windows Server 2008 and IIS7) you’ll install just the 32 bit runtimes. If you’re on a 64bit OS and only run 64bit application pools, you’ll install just the 64 bit runtimes. But if you’re on a 64bit OS and run both 32bit and 64bit application pools, you’ll want to install both the 32bit and 64bit version.
Before installing ModSecurity install the Visual Studio 2010 Runtime(s):
- 32-bit OS: http://www.microsoft.com/en-us/download/details.aspx?id=5555
- 64-bit OS: http://www.microsoft.com/en-us/download/details.aspx?id=14632
During my testing I did find that ModSecurity had a missing dependancy on my machine “Wlanapi.dll” This was installed by installing the “Wireless LAN Service” as follows:
- Open Server Manager
- Select Features | Add Feature
- Select Wireless LAN Service
- Install, Close and call it a day.
My recommendation is install the Visual Studio Runtimes first. If your server throws a 503 error, then install the wlanapi.dll as described above. My process was install the 64bit runtimes, install the wlanapi.dll and then install the 32bit runtimes and my install finally started working. It’s certainly possible you don’t need wlanapi.dll and I haven’t tested further, just yet.
Now go ahead and run the WebPI installer and install ModSecurity. Load your site and make sure the site loads. You’ll also want to check the application log and make sure mod security loaded. Is all good? If not just roll back your applicationhost.config file. either remove the three lines that include ModSecurity or go to c:\inetpub\history and restore the most recent backup of your applicationhost.config file into c:\windows\system32\inetsrv\config
Official installation guidance can be found here: https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual#wiki-Installation_for_Microsoft_IIS
Configuring our ModSecurity Ruleset
ModSecurity installs its ruleset in c:\inetpub\wwwroot\owasp_crs\ you can either operate with the files here or you can move them to some other location. Before actaully enabling our rules though, let’s set them into “DETECT ONLY” mode so that ModSecurity will only perform detection but not take any action to modify or disrupt the connection. open modsecurity.conf in the above referenced folder and the first line should read:
SecRuleEngine DetectionOnly
When we’re ready to activate ModSecurity We’ll change DetectionOnly to On.
Creating a Test Rule
Before we enable ModSecurity, we’re going to want to create a test rule so we can verify it’s working. The rule we’ll create is:
SecRule ARGS, "zzz" phase:1,log,deny,status:503,id:1
We’ll place this rule in the file modsecurity.conf at the very bottom of the page.
NOTE: Make sure you uncheck the “Read-Only” properties on this file before trying to save the file. Then after you save the file, set it back to read-only!
It’s important we make this change before enabling ModSecurity as we’ll have to restart the website’s application pool each time we change the ruleset for the changes to get loaded.
Enabling ModSecurity for our website.
In the ruleset folder (c:\inetpub\wwwroot\owasp_crs) we’ll also see modsecurity_iis.conf. We’ll use this rule to enable ModSecurity for our website (and it includes the modsecurity.conf file so don’t worry we don’t our changes will be included). Inside the web.config file in the wwwroot of our website we’re going to modify it to include:
<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<system.webServer>
<ModSecurity enabled="true"
configFile="c:\inetpub\wwwroot\owasp_crs\modsecurity_iis.conf" />
</system.webServer>
</configuration>
If your web.config already has a system.webServer section (and it probably does) then you’re just going to add:
<ModSecurity enabled="true"
configFile="c:\inetpub\wwwroot\owasp_crs\modsecurity_iis.conf" />
before the </system.webServer> line and then save the file. The change should take immediately.
Verifying ModSecurity is loaded and detecting issues
After you enable ModSecurity you can verify it’s loaded by triggering our test rule. IN my case I went to http://www.mydomain.com/index.php?a=ZZZ. ModSecurity keeps all of it entries in the Windows Event Log so viewing that I found:
[client 192.100.0.47:10911] ModSecurity: Warning. Pattern match “zzz” at ARGS:a. [file “c:\inetpub\wwwroot\owasp_crs\modsecurity.conf”] [line “215”] [id “1”] [hostname “HYPVXXXX”] [uri “/testing.aspx?a=zzz”] [unique_id “17798225729515689548”]
But that wasn’t the only alert I saw.. Within moments of loading ModSecurity I also started seeing a number of other entries, many of which were false positives for ScriptResource.axd which is the AJAX clientside script routines and not something we’d want to block, so I edited that rule.
Editing ModSecurity To Allow ScriptResource.AXD
ScriptResource.AXD is used for the AJAX clientside script routines. So I edited the file “modsecurity_crs_10_setup.conf” and removed .axd/ from line 275. Saved the file, set it back to read-only and then recycled my application pool. No more .AXD false positive
Tuning ModSecurity
Before we actually enable ModSecurity, I’ll leave it running in detection mode for a few days, tuning the ruleset by editing rules as I see them come up as false positives and eventually have a ruleset that looks good for my server. Then as 0-day exploits come out (that’s zero day exploits) or new attacks (like the widespread wordpress bruteforce attacks currently happening) I’ll be able to adjust my rules and protect my site even further.
More Resources
Much of the information to get us this far happened because of the information sharing others have made on the Internet. I used the following resources:
- ModSecurity Installation guide: https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual#wiki-Installation_for_Microsoft_IIS
- Configuring ModSecurity: http://blog.spiderlabs.com/2012/07/announcing-the-availability-of-modsecurity-extension-for-iis.html
- Testing/Configuring ModSecurity: http://cyberoperations.wordpress.com/2013-class/07-iis-7-5-on-windows-2008-r2-with-modsecurity-2-7-2/
Where to go from here?
First, I’d love to hear you were looking for a a new virtual server running Windows Server 2012 and purchased from AppliedI. I’d also love to hear any feedback or experiences you had with ModSecurity and any additional tips you’d might like to share. We’ve only scratched the surface. Oh and don’t forget to subscribe to my blog and follow me on twitter to learn about new posts as they come out.
