As part of our recent release of ModSecurity v2.7.2, not only did we fix many bugs (CHANGES), but
this is also the first version where we labeled the IIS7 version as STABLE release quality! You can download the 2.7.2 MSI Installer here. Microsoft's IIS Engieering Team conducted extensive testing and opened many JIRA tickets.
All of these tickets have been fixed and closed. Here are some of the items we addressed:
21 Jan 2013 - 2.7.2-------------------* IIS version is now stable.* Fixed IIS version does not pass through POST data to ASP.NET when SecRequestBodyAccess is set to On (MODSEC-372).* Fixed IIS version HTTP Request Smuggling protection does not work (MODSEC-344).* Fixed IIS version PHP Injection Attack (958976) protection does not work (MODSEC-346).* Fixed IIS version Request limit protections are not working (MODSEC-349).* Fixed IIS version Outbound protections are not working (MODSEC-350).* Added IIS version better installer.
This is a huge achievement and I wanted to take a moment to thank both Greg Wroblewski (Microsoft Security Research and Defense) who was the lead developer of the port of ModSecurity to IIS7 and also Breno Silva Pinto (Trustwave SpiderLabs Research) who acted as the ModSecurity subject matter expert during development.
2012 Toolsmith Tool of the Year Award: ModSecurity for IIS
Best Practice Recommendations from Microsoft
Microsoft recently released a TechNet article entitled "Security Best Practices to Protect Internet Facing Web Servers" and in it recommended the following:
Application-oriented security: WAF (Web Application Firewall), just next to the web app/site, that will allow to harden the requests control, and tighten the filter to match the specificities of the web application. ModSecurity for IIS7 (see: http://www.modsecurity.org/ ) is an example of a tool that can be used for robust audit logging of HTTP(S) transactions and virtual patching of identified vulnerabilities. Along with the bundled OWASP ModSecurity Core Rule Set (CRS), it offers essential protections against application layer attacks and information leakages.
All IIS7 admins should install ModSecurity to gain better visibility into HTTP(S) transactions and offer an expedited mechanism to deploy protections for new attacks or vulnerabilities. Trustwave SpiderLabs is a MAPP program participant and we develop ModSecurity virtual patches for a number of web server/application vulnerabilties released by Microsoft in the Patch Tuesday pre-notification data. These virtual patching rules are included within our commercial ModSecurity rules feed, so IIS7 users may utilize our rules as well to protect their environments.
ModSecurity vs. URLScan
An interesting legacy issue that needs to be addressed is this - IIS7 administrators should use ModSecurity rather than relying upon URLScan. URLscan provides extremely basic input filtering for the following:
- The HTTP request method or verb
- The file name extension of the requested resource
- Suspicious URL encoding
- Presence of non-ASCII characters in the URL
- Presence of specified character sequences in the URL
- Presence of specified headers in the request
Here is an example URLScan configuration file to detect basic SQL Injection strings:
URLScan has the following limitations with regards to protections:
- Can not inspect POST request bodies. This means that it can not inspect any parameter data sent in POST payloads. Needless to say, this leaves open a huge hole in any inspections.
- Can not inspect Outbound response data. This means that you can not identify data leakages or what data was exposed to the client.
It was for these two main reasons that the we ported ModSecurity to the IIS7 platform. With ModSecurity installed, you can also use the OWASP ModSecurity CRS to implement better coverage for a wide range of application-layer attacks such as SQL Injection.