Microsoft Azure Websites now supports ModSecurity web application firewall for your websites. Author custom application firewall rules or consume commercial rules to protect your web application against web vulnerabilities and exploits.
What is ModSecurity?
“ModSecurity is an open source, cross-platform web application firewall (WAF) module. Known as the “Swiss Army Knife” of WAFs, it enables web application defenders to gain visibility into HTTP(S) traffic and provides a powerful rules language and API to implement advanced protections.” For those familiar with IIS or ASP.NET request filtering or UrlScan, ModSecurity is a similar tool that supports a much richer syntax for writing rules to filter inbound HTTP requests or outbound HTTP responses. ModSecurity uses an event-based programming language syntax that allows the user to define “SecRules” that use various operators (such as Regular Expressions) to inspect inbound and outbound HTTP(S) data. For more details you can visit their website at http://www.modsecurity.org/.
Why do I need ModSecurity?
ModSecurity provides many benefits, but one of its key uses is to perform “Virtual Patching” which is a security policy enforcement layer which prevents the exploitation of a known vulnerability. Essentially this gives you a way of filtering out vulnerability exploit attempts independently from your web application’s logic. Eg: If there is an outbreak of automated SQL injection attacks, it would be easy for you to configure ModSecurity rules to filter out these requests from even reaching your application logic, even if you were sure there are no SQL injection bugs in your web application code.
How do I use ModSecurity in Azure Websites?
Using ModSecurity in Azure Websites is as easy as adding the following configuration lines to your application’s web.config file.
<configuration>
<system.webServer>
<ModSecurity enabled=”true” configFile=”D:\home\site\wwwroot\secrules.conf” />
system.webServer>
configuration>
On Azure websites, the d:\home\site\wwwroot directory points to your webiste’s root directory. The configFile attribute points to the ModSecurity configuration file to use for this particular site and contains ModSecurity settings as well as the rules that are applied.
Additionally, ModSecurity is usually configured to read and write various files in a directory that you may not want to serve out. To block these files from being served you should add the following configuration in your web.config file.
<configuration>
<system.webServer>
<security>
<requestFiltering>
<hiddenSegments>
<add segment=”modsecurity” />
hiddenSegments>
<fileExtensions>
<add fileExtension=”.conf” allowed=”false” />
fileExtensions>
requestFiltering>
security>
system.webServer>
configuration>
This will block requests to the ModSecurity directory in your content directory from being served to clients.
What goes in the ModSecurity .conf files?
ModSecurity has rule sets available on http://www.modsecurity.org/rules.html. The core rule set is free and the commercial rules are paid for. You can download the core rule set to get an idea of what goes into the .conf files. Following is an example of an extremely basic configuration file secrules.conf.
SecRuleEngine DetectionOnly
SecRequestBodyAccess Off
SecTmpDird:\home\site\wwwroot\modsecurity\temp\
SecDataDird:\home\site\wwwroot\modsecurity\temp\
SecRule REQUEST_URI|ARGS “bad_arg” “log,deny,id:12345,msg:’Access Denied’”
The SecRuleEngine setting tells what ModSecurity should do when a rule is triggered. Setting it to DetectionOnly means that requests or responses will not be blocked, but anything that would trigger a rule would be logged in the event log so that you can tell what rules are being triggered and which are not as part of your requests. You can set this value to On to enable the blocking behavior or set it to Off to completely disregard the rules.
The SecRequestBodyAccess option tells if ModSecurity rules are allowed to access the request body as part of their rules or not. As you might guess, turning this off can improve both memory and CPU performance at the cost of not being able to evaluate rules based on the Request Body of the HTTP request. Allowing scanning of request entity body is a distinguishing feature between Request Filtering in IIS and ModSecurity, so if you have rules that want to analyze the entity body, you need to make sure you turn this setting on.
The SecTmpDir and SecDataDir allow you to set the directory where ModSecurity will store its temporary and persistant data.
The SecRule line is the actual filtering rule and it operates on an incoming HTTP request against the REQUEST_URI and ARGS (query string parameters). If it finds the string “bad_arg” anywhere in these places it takes the action “log,deny,msg:’Access Denied’” which basically will deny the request and log it with the Access Denied message in the log.
You can always go look at ModSecurity documentation to get a list of all the options and a more detailed description.
What are OWASP CRS rules and how do I use them?
The OWASP ModSecurity Core Rules Set (CRS) provides generic protection from unknown vulnerabilities found in web applications. Several of these protections might already be offered at other layers like request filtering in http.sys or IIS, or web application logic. Because they are generic in nature it is intended as just a starting point and the site admin / developer needs to add / remove / modify these rules as applicable to the application that is meant to be protected.
You can download the configuration files for the core rule set from the ModSecurity website here. If you download the zip file you will see a bunch of folders with .conf and .data files. Each of the .conf files contains one or more rules and they are organized by rule category. You can create a modsecurity\rules directory in your content folder and then copy all the files and folders from the zip file under here. You can use FTP or other mechanisms like Microsoft Web Deploy to achieve this. Once you have the files copied here you can activate rules by using the include directive from the .conf file you configured in web.config above.If, for example, you wanted to include all the rules in the base_rules directory and just the wordpress rule in the slr_rules directory, you would add the following lines to the start of your secrules.conf file.
Included:\home\site\wwwroot\modsecurity\rules\base_rules\*.conf
Included:\home\site\wwwroot\modsecurity\rules\slr_rules\modsecurity_crs_46_slr_et_wordpress_attacks.conf
Some of the .conf files have commented sections or reference .data files that you can update. For example, the modsecurity_crs_35_bad_robots.conf in the base_rules directory references the modsecurity_35_bad_robots.data file that contains a list of User-Agents that you would like to block. There is also a modsecurity_iis.conf file in the core rules set that you can use to setup all the CRS rules for your site.
Are there any restrictions on ModSecurity’s use?
Currently, ModSecurity module is available for all categories of Azure Websites including the free tier. The important thing to note however is that the module runs within your IIS worker process on Azure websites; so any throttles and restrictions that apply to your worker process are also applicable to ModSecurity. So for the free tier, there is a cap on CPU minutes per day consumption for your site, and these would apply to ModSecurity running in the worker process as well.
ModSecurity by itself is not of much use unless you configure it with rules. In this aspect it is exactly like RequestFiltering in IIS except that it won’t be configured with any default rules. You will need to add these rules yourself and you can check the section below on how to setup a barebones configuration or use the OWASP core rule set. Depending on how complex your rules are and what portions of the HTTP request or response it operates on, it could have performance impact on your website’s performance. So it is good to have very targeted rules to decrease the additional overhead of matching HTTP requests and responses against your rules.