WAF settings can be configured for each Virtual Service. Follow these steps to configure the WAF in a Virtual Service:

  1. In the main menu of the LoadMaster UI, go to Virtual Services >View/Modify Services.
  2. Click Modify on the relevant Virtual Service (or on the relevant SubVS in the SubVSs section of the Virtual Service).
  3. Expand the WAF section.

  4. By default, WAF is disabled. To enable WAF, select Enabled.
    Note: When using WAF in a Microsoft Exchange environment, ensure to enable WAF at the SubVS level to avoid issues with ActiveSync because standard WAF is unable to interpret the protocols used by ActiveSync.
    Note: In general, WAF should be enabled at the SubVS level of the Virtual Service (not at the main Virtual Service level). You should not enable WAF on a parent Virtual Service and SubVS at the same time.

    The maximum number of WAF-enabled Virtual Services is the total (unused or available) RAM (in MB)/512 MB. For example: 8 GB/512 MB = 16 WAF-enabled Virtual Services. When the maximum is reached, no additional Virtual Services can be enabled with WAF.

    A message displays if there is insufficient memory available to enable WAF.

    A message is displayed next to the Enabled check box displaying how many WAF-enabled Virtual Services exist and the maximum number of WAF-enabled Virtual Services that can exist. If the maximum number of WAF-enabled Virtual Services is reached, the Enabled check box is grayed out.

  5. Specify the Audit mode.
    There are three audit modes:
    • No Audit: No data is logged.
    • Audit Relevant: Logs data that is of a warning level and higher.
    • Audit All: Logs all data through the Virtual Service.

    Selecting the Audit All option produces a large amount of log data. We do not recommend selecting the Audit All option for normal operation. However, the Audit All option can be useful when troubleshooting a specific problem.

  6. Specify the Anomaly Scoring Threshold.
    Note: For each request, every triggered detection raises the anomaly score. Most rules have a score of 5. If the cumulative anomaly score per request hits the configured limit, the request will be blocked. The default value is 100 and the allowable range is 1 to 10000.
  7. The Paranoia Level can be set in Advanced Settings, but the value is displayed here for informational purposes.
  8. Enable or disable rules in the Manage Rules section. When finished making changes, click Apply.

    Rules are grouped in the Request Rules section as per the OWASP numbering system. Rule groups or Individual rules within each ruleset can be enabled/disabled as required. To enable a rule or group of rules, select the relevant check box. If you have previously enabled/disabled rules in that ruleset, within that Virtual Service – the rules retain their previous settings.

    Note: Some rules or rule sets may have dependencies on other rules. There is no dependency check in the LoadMaster when rules are disabled - before disabling any rule, be aware of any rule chains or dependencies.

    There is a Run First check box available for custom rules. If the Run First check box is enabled for a custom rule, the rule will be run first, before the OWASP Core Rule Set (CRS). If the Run First check box is disabled for a custom rule, the custom rule runs after the CRS. The Run First check box is disabled by default.

    In the Workloads section there are several workloads available.

    If custom rules exist, they can be enabled or disabled within the Custom Rules section.

    To filter rules, enter text in the Rule Filter text box. Only rules containing that text will be shown. You can select the filtered rules by clicking Set All or deselect the filtered rules by clicking Clear All. Click Apply to apply the changes.

    Clicking Reset will reverse any changes that you have made that have not been applied.

  9. Specify the Hourly Alert Notification Threshold and click Set Alert Threshold.

    This is the number of incidents per hour before sending an alert. Setting this to 0 disables alerting.

  10. To enable the IP Reputation Blocking rule set, select the IP Reputation Blocking check box.

    In Web Application Firewall > Access Settings you can download and install the latest IP reputation file. If Enable IP Reputation Blocking is selected for a Virtual Service, client addresses are checked against the IP access list file and are blocked if a match is found.

Advanced Settings

Click Advanced Settings to configure the advanced OWASP settings.

  1. Specify whether or not to Inspect HTTP POST Request Bodies.

    The Inspect HTTP POST Request Bodies option is disabled by default. If you enable this option, three more check boxes become available that allow you to enable the processing of JavaScript Object Notation (JSON), Extensible Markup Language (XML) requests, and other content types.

  2. Request Body Size Limit: This option allows you to set the maximum size of POST request bodies that the WAF engine will allow through. Higher values require more memory resources and may impact WAF engine performance. The default value is 1048576 bytes. The range of valid values is 1024 to 52428800.
  3. Select Process HTTP Responses to enable checking of the responses from the server to the client.

    Enabling the Process HTTP Responses option makes two more options (E - Intended Response Body and F- Response Headers) available in the Audit Parts options.

    The processing of response data can be CPU and memory-intensive and may impact performance.

  4. Select the Blocking Paranoia Level to define how strictly the ModSecurity engine implements each rule.

    The default Paranoia Level value is set at 1. With each paranoia level increase, the CRS enables stricter implementations of the rules, giving you a higher level of security. However, higher paranoia levels also increase the possibility of blocking some legitimate traffic due to false positives. If you use higher paranoia levels, you will likely need to add some exclusion rules for certain applications that need to receive complex input patterns.

  5. Select the Executing Paranoia Level that defines the paranoia level at which the ModSecurity engine checks/verifies the requests coming from the servers. The results of the checks will be logged but the Executing Paranoia Level is not used to determine what traffic will be blocked.

    Though the Executing Paranoia Level can be higher than the Blocking Paranoia Level, it cannot be lower. A higher Executing Paranoia Level enables users to see which rules would be triggered at a higher Paranoia level without blocking traffic.

  6. Audit Parts: A single string that contains the sections that are to be entered in the WAF audit log for each request. The supported values are A, B, E, F, H, K, and Z, though only the values B, E, F, and H can be enabled or disabled.

    For further information regarding the Audit Parts, please refer to https://github.com/SpiderLabs/ModSecurity/wiki/ModSecurity-2-Data-Formats

  7. PCRE Match Limit: Set the PCRE Match Limit value and click Set PCRE Match Limit. The default value is 10000. The maximum value is 9999999.

    This setting sets the maximum iterations that the internal PCRE engine uses before failing a match. A lower value may cause a valid match to fail, whereas a higher value may cause the WAF engine to run slower. This setting can be used to protect against Denial of Service (DoS) attacks using complex regular expressions.

  8. JSON Depth Limit: Set the JSON Depth Limit value and click Set JSON Depth Limit. The default value is 10000.

    This value sets the maximum depth that will be accepted during JSON parsing. Lower values may cause a valid match to fail. Higher values may cause the WAF engine to run slower. The range of valid values is 1000 to 99999.

  9. Countries to block: Based on GEO IP information, you can select countries that should not be allowed access. Click the Select All button to block the access for all countries or select individual countries from the country list that are to be blocked and click Set Excluded Countries.

False Positive Analysis

This feature allows users to perform false positive analysis against their applications to obtain enhanced visibility of attacks and fine-tune protection. Click the Click here to perform False Positive Analysis button to check False Positives against any Virtual Service that runs OWASP CRS rules.

Rule Counts

The Rule Counts section displays information on any rules that are being triggered by requests. The Rule ID, the paranoia level the rule is running under, the number of hits per requests that have triggered the rule, and the message or match for the request are displayed for each rule that is triggered.

Clicking Show Rule in the Operation column displays the contents of the rule file associated with the triggered rule. This opens in a separate tab and the URL contains the triggered rule id.

The rule can be disabled by clicking Disable Rule.

Reset FPA Counters

Reset all False Positive Analysis Counters (Anomaly Histogram and Latest Events) for the Virtual Service. Clearing the Latest Events does not remove the logs from the LoadMaster, they are still available under System Configuration > Logging Options > System Log Files > WAF Event Log File.

Anomaly Histogram

The first row of the Anomaly Histogram section displays how many requests have been run without triggering a rule.

Each subsequent row gives details of rules that have been triggered and are affecting the Anomaly Score. Each row shows the cumulative Anomaly Score, the number of requests that have triggered the rule, and the rule details.

Latest Events (newest at top)

This section displays the event details for each rule that is triggered. These messages are in the standard ModSecurity log format and contain the anomaly score, the warning message, the attack state, and the paranoia level.

Download

Click Download to download the displayed WAF event log details.