Diagnosing Issues with ModSecurity in Azure Websites

In the previous post ,we talked about using ModSecurity in Azure Websites. ModSecurity rules and configuration can get quite complex, especially if you are copying pieces from external sources. Typically, you want to start with a simple configuration for ModSecurity, test it out and then work your way up to more complex configurations. This will help you keep track of changes and help you diagnose failures. Here are some tips to help you figure out what might possibly have gone wrong.

How do I know what ModSecurity is doing to my HTTP requests and responses?

Setting the SecRuleEngine to DetectionOnly gives developers a great way to test what your rules would do without blocking any incoming requests. The DetectionOnly output is usually sent to event logs, which in Azure Websites is redirected to the d:\home\LogFiles directory in your site. You can download these logs through FTP to get a detailed log of what rules are triggering. If you want more verbose logs you can add the configuration options below to your .conf file

SecDebugLogd:\home\site\wwwroot\modsecurity\logs SecDebugLogLevel 9

This is a global setting and can cause serious performance issues in your website for even moderate traffic. So it is better to use conditional debug settings as shown in the examples below, unless there is no live traffic to your site. To scope down debug logging for to a particular client IP address, you can use:

SecRule REMOTE_ADDR "@ipMatch 192.168.1.1" "phase:1,id:1234,t:none,nolog,pass,ctl:debugLogLevel=9"

To scope down debug logging if a specific parameter is present on your request, you can use:

SecRule ARGS:debug_log "@streq on" "phase:1,id:1235,t:none,nolog,pass,ctl:debugLogLevel=9"

You can refer to the ModSecurity documentation to get more details on what the log levels mean. Note: These settings write data to your content directory, so if you have a storage quota on your website, you run the risk of hitting this based on your configuration and request volume.

Why are my ModSecurity rules not triggering?

Here are a few steps you can take to help diagnose issues with rules not triggering. 1. Is your web.config correct? Make sure your configuration sections in your web.config files are correct, and if you have copied sections from multiple places, make sure the XML is merged correctly and the configuration is in the expected section. 2. Do you have the right paths for your ModSecurity Include files? The OWASP CRS rules that are available for free from the ModSecurity website have Include directives in their .conf file that point to other .conf files to include. If you are using these files as-is, you will need to edit the location of the Include directives to point to the correct location, e.g Include d:\home\sites\wwwroot\ 3. Is it a particular rule that is not triggering? You can use the SecDebugLog setting to diagnose what ModSecurity is doing for each HTTP request or response for each of your rules. Use this for diagnosing issues with specific rules. You can always set ctl:debugLogLevel=9 for specific rules as shown in the examples above as well.