###############################
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).


  .. image:: ../../images/iis/01-install.png
  .. note:: Launch the MSI installer


  .. image:: ../../images/iis/03-install.png
  .. 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/

  .. image:: ../../images/iis/04-install.png


  .. 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:

   .. code-block:: console
   
      C:\Program Files\ModSecurity IIS\modsecurity_iis.conf

This file should include these lines:

   .. code-block:: console
   
      Include modsecurity.conf 
      Include windows\*asl*.conf    
	  
	  
----------


**Step 5: Configure ModSecurity**

Create/Edit "C:\\Program Files\\ModSecurity IIS\\modsecurity.conf" with the following:

.. code-block:: console

   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\\:

   .. code-block:: console
   
      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:
   
      .. code-block:: console
	  
         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:

        .. code-block:: console
		
           ModSecurity: Found another rule with the same id

     This 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\\:

   .. code-block:: console
   
      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\\:

   .. code-block:: console
   
      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\\:

   .. code-block:: console
   
      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:

         .. code-block:: console
		 
            http://your_systems_name_or_ip/foo.php?foo=http://www.example.com

       If 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:

      .. code-block:: console

         --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 isn't 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**

   .. code-block:: console
   
      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.	  
