Windows Local Rule Installation
Requirements
IIS
Modsecurity 2.9.3 or above
Windows Server 2016 or above
Manual Installation: IIS
Step 1: Download ModSecurity
Download ModSecurity https://updates.atomicorp.com/channels/rules/binaries/
Note
Please contact support before using a third party or source build of modsecurity. Third party builds may not be compatible.
Step 2: Install ModSecurity
Before installing ModSecurity make sure you have Visual Studio 2013+ Runtime (vcredist) installed. Vcredist can be downloaded here: http://www.visualstudio.com/downloads/download-visual-studio-vs (note that, there are two different versions 32 and 64b).
Note
Launch the MSI installer
Note
Any installation errors or warning messages are logged in the application event log under ‘ModSecurityIIS Installer’ source.
Step 3: Download and Extract Atomicorp Ruleset
Using your Atomicorp license credentials, download the latest modsec* ruleset from https://updates.atomicorp.com/channels/rules/iis-latest/
Note
Rules are updated daily, and available in both tar.bz2 and .zip archives.
Step 4: Configure ModSecurity Main Config File
Create/Edit this file in your modsecurity root directory:
C:\Program Files\ModSecurity IIS\modsecurity_iis.conf
This file should include these lines:
Include modsecurity.conf Include windows\*asl*.conf
Step 5: Configure ModSecurity
Create/Edit “C:\Program Files\ModSecurity IIS\modsecurity.conf” with the following:
SecRuleEngine On
SecRequestBodyAccess On
SecRequestBodyLimit 13107200
SecRequestBodyNoFilesLimit 131072
SecRequestBodyInMemoryLimit 131072
SecRequestBodyLimitAction Reject
SecPcreMatchLimit 150000
SecPcreMatchLimitRecursion 150000
SecResponseBodyMimeType text/plain text/html text/xml
SecResponseBodyLimit 524288
SecResponseBodyLimitAction ProcessPartial
SecTmpDir c:\inetpub\temp
SecDataDir c:\inetpub\temp
SecAuditEngine RelevantOnly
SecAuditLogRelevantStatus "^(?:5|4(?!04))"
SecAuditLogParts ABIJDEFHZ
SecArgumentSeparator &
SecCookieFormat 0
SecStatusEngine On
Step 6: Create the Whitelist File
Create this file in your rules directory C:\Program Files\ModSecurity IIS\windows\:
whitelist.txt
This file contains a list of IPs you want to exclude from ALL rules. That means those IPs can do anything to your system - so be very very careful about what IPs you add to this list. This is a dangerous thing to do. The format of the file is a single IP, per line.
Note
On some Windows platforms the @ipmatch system does not work correctly. Some IIS versions will report the remote systems IP in this format:
ip:port
Step 7: Install the Rules
Active rules are contained in C:\Program Files\ModSecurity IIS\windows\
Remove any previous installations of rules
When updating, ensure previous rules C:\Program Files\MosSecurity IIS\windows\ have been deleted
Also, if you have installed any third party modsecurity rules, ensure they are using rule id’s that are assigned to them. Modsecurity requires a unique id for each rule, rule ID collisions will return the following error:
ModSecurity: Found another rule with the same idThis means either that someone else is using the same rule id’s assigned to our ruleset by the modsecurity project (our official range is 300000-399999), or you have loaded our rules twice.
Recommended Minimum Rulesets
The following is the recommended minimum ruleset to copy to C:\Program Files\ModSecurity IIS\windows\:
00_asl_00_global_tune.conf 10_asl_antimalware.conf 10_asl_rules.conf 11_asl_adv_rules.conf 20_asl_useragents.conf 30_asl_antispam.conf 50_asl_rootkits.conf 60_asl_recons.conf 61_asl_recons_dlp.conf 99_asl_jitp.conf
For ModSecurity 2.9.0 and up, the following are additionally recommended to C:\Program Files\ModSecurity IIS\windows\:
00_asl_00_global.conf 00_asl_threat_intelligence.conf 00_asl_zz_strict.conf 00_asl_z_antievasion.conf 01_asl_content.conf 03_asl_dos.conf 09_asl_rules.conf 10_asl_antimalware.conf 10_asl_rules.conf 11_asl_adv_rules.conf 11_asl_data_loss.conf 12_asl_adv_xss_rules.conf 20_asl_useragents.conf 30_asl_antispam.conf 50_asl_rootkits.conf 51_asl_rootkits.conf 60_asl_recons.conf 61_asl_recons_dlp.conf 98_asl_adv_redactor.conf 99_asl_jitp.conf
For environments with a high-performance/Local DNS resolver the following Active threat intelligence rules are recommended C:\Program Files\ModSecurity IIS\windows\:
00_asl_z_searchengines.conf 00_asl_z_aa_threat_intelligence.conf 99_asl_zzzz_threat_intelligence.conf
Note
Some of these rulesets are designed to work with advanced security management systems such as Atomic Protector and may not work completely without an advanced management system.
Step 8: Test your WebServer
Run iisreset.exe to ensure that IIS restarts. On some systems you may need to stop and restart IIS for your modsecurity configuration to load.
Test to see if the rules are loaded
Make sure you have the rules installed exactly as described on this page. This test may not work if you have not followed these instructions. (If you have not installed any third party tools that configure, install or manage modsecurity then your rules are installed correctly and you do not need to review the instructions on this page. If you have manually altered your modsecurity configuration then you will need to review this entire article.)
Make sure all rules are enabled.
Test from a non-whitelisted system
Run the following test:
Step 1) On a different system from where the rules are installed, and that is not whitelisted, access this url for your system:
http://your_systems_name_or_ip/foo.php?foo=http://www.example.comIf the rules are properly loaded, you should get a 403 error, if you do not get a 403 error, the rules are not loaded correctly and you need to check your configuration to ensure that you have followed the instructions above correctly.
What to do if you do not get a 403 error?
If you get a different error, such as a 404 error or a 5xx series error check your configuration. The following are common causes of this:
You have rules disabled.
Your IP is whitelisted. There is a rule whitelisting the system you are conducting this test from. Whitelisting tells the WAF to ignore everything from that source.
Local error message is different. You or someone else may have configured your system to use a different error message. Check your configuration, and make sure it exactly matches the ones on this wiki. IF you are using kind of plugin that does not return a 403 when a connection is rejected, and you must use this, then you will need to manually check your mod_security logs to see if your test is being rejected by modsecurity. If it is, then your rules are working correctly and you can ignore the error code.
Third party addons. You have third party rules or addons installed with your modsecurity configuration that are changing the responses. Remove all third party addons, and make sure your configuration exactly matches the instructions on this page
The system is not configured to load the rules. This is common with custom configurations. Check to make sure your webserver is configured to load the rules. Keep mind that modsecurity will still generate generic messages even though the rules are not loaded. For example, if all you see are events like this:
--70c19f31-A-- [01/Jan/2013:11:19:13 --0300] roiKIi6Ni3EKFZSKpSUs2iEb 1.2.3.4 34978 5.6.7.8 80 --70c19f31-B-- HEAD / HTTP/1.1 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) Accept: */* --70c19f31-F-- HTTP/1.1 403 Forbidden X-Powered-By: PHP/5.4.20 Expires: Thu, 19 Jan 2001 02:12:00 GMT Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0 Pragma: no-cache Connection: close Content-Type: text/html --70c19f31-H-- Stopwatch: 1383338363503919 358184 (- - -) Stopwatch2: 1383338363503919 358184; combined=2144, p1=37, p2=2053, p3=0, p4=0, p5=53, sr=0, sw=1, l=0, gc=0 Producer: ModSecurity for Apache/2.7.5 ( http://www.modsecurity.org/). Server: Apache Engine-Mode: "ENABLED" --70c19f31-Z--In this example, no rule is being triggered, but modsecurity is logging a basic 403 error. It will do this if the modsecurity configuration is loaded, but not the rules. So if you see this happening on your system, and you have ruled out all other issues in this list, it means your custom configuration isnt loading the rules.
Atomic Protector will automatically configure modsecurity correctly. So if you are having problems configuring modsecurity yourself, then we recommend you use Atomic Protector to setup modsecurity for you.
Notes on Scanner Rulesets
99_asl_scanner.conf 99_asl_z_adv_scanner.conf
Atomic Protector includes malware upload scanning, rules subscriptions do not.
If you wish to use this ruleset, and you are not using Atomic Protector, then you will need to create a script to pass the files to clamd and read the result. Make sure you have clamd installed and configured correctly to list on a TCP port, or if you use a socket, make sure apache can read/write to this socket or as a last resort, run clamd as root. Using this file will force all web uploads on your system to go thru clamav to look for malware, viruses, etc. If you dont need that, then you can leave this config file out.
Real time malware upload protection is included in Atomic Protector and uses a faster method than the older style modsecurity scripting method above. So if you need realtime malware upload protection (for web, FTP, or even realtime), then upgrade to Atomic Protector which includes highspeed malware upload protection, full support, automatic and hassle free installation. Atomic Protector also protects against any form of upload of malware, including HTTP, HTTPS, SSH and FTP uploads and includes our real-time malware detection and prevention system which will detect and block any malicious software running on the system in realtime. This is just one of the many many features of Atomic Protector.