The Web Application Firewall (WAF) is an essential tool for identifying and preventing malicious HTTP traffic within HTTP(S) farms. It analyzes traffic patterns and enforces advanced security policies through organized sets of rules applied to these farms. After decrypting SSL packets, the WAF scrutinizes the rules, allowing it to apply patterns to the HTTP body within SSL traffic.

The RELIANOID IPDS package includes the OWASP ModSecurity Core Rule Set, which comes pre-loaded and ready for use. Users also have the flexibility to create custom rulesets for comprehensive system protection against various attacks. For more details on OWASP rules, refer to the OWASP ModSecurity Project. Additionally, the RELIANOID WAF module extends its functionality beyond HTTP protection to include advanced HTTP content handling features, such as redirects and rewrites.

WAF Rulesets View #

The WAF rulesets view provides an overview of the available rulesets and their assigned farm services:

Name. A descriptive identifier for a ruleset. Click to access the editing form.
Farms. The farms to which the rule is applied. Expand the farm list using the upward arrow next to the FARMS column header. Limited to 20 characters by default.
Status. The status of the ruleset, indicated by color codes:

• Green. Enabled. The ruleset is active and being checked for the assigned farms.
• Red. Disabled. The ruleset is inactive and not affecting the farms.

Actions. Available actions for the WAF ruleset status:

• Edit. Modify the ruleset settings or assign a farm service if needed.
• Restart. Reinitialize a WAF rule.
• Start. Apply the WAF ruleset.
• Delete. Remove a ruleset.

Understanding OWASP CRS Ruleset System #

The OWASP CRS rulesets comprises generic attack detection rules, offering a foundational level of protection for any web application.

Modes of operation #

The OWASP CRS pre-loaded rulesets operates in two modes:

Anomaly Scoring Mode (default): This mode is recommended for its accurate log information and flexible blocking policies. Also known as “collaborative detection mode,” it assigns an ‘anomaly score’ to each matching rule. At the end of inbound and outbound rule evaluations, the anomaly score triggers blocking actions, typically resulting in a default 403 error.

Self-Contained Mode: This mode applies actions instantly. While reducing resource usage, it sacrifices flexibility in blocking policies and detailed audit logs (only the first detected threat is logged). Rules follow the disruptive action you specify (e.g., deny, drop). The first matching rule executes this action, often leading to evaluation cessation after the initial match, similar to many IDSs.

Basic OWASP CRS Rulesets #

These pre-loaded protection rules are arranged based on preferences. If you opt to use them, kindly consider and apply them in the following manner:

REQUEST-90-CONFIGURATION
REQUEST-901-INITIALIZATION
# Apply any other OWASP ruleset based on what you want to protect
REQUEST-949-BLOCKING-EVALUATION
RESPONSE-959-BLOCKING-EVALUATION
RESPONSE-980-CORRELATION # for logging purposes, enable this only for troubleshooting.

Within the OWASP Core Rule Set, the REQUEST-901-INITIALIZATION ruleset serves as a foundational element, offering an extensive array of options for configuring the overall behavior of the security rules. It provides users with the flexibility to fine-tune settings to align with specific security needs, forming the backbone of the rule configuration process. Moving to REQUEST-949-BLOCKING-EVALUATION and RESPONSE-959-BLOCKING-EVALUATION rulesets, these play a critical role in the proactive security posture by evaluating and executing blocking actions based on anomaly scores. They contribute significantly to the OWASP Core Rule Set’s capability to identify and prevent potential threats in real-time. Complementing these, RESPONSE-980-CORRELATION ruleset focuses on correlating and analyzing responses, enhancing the OWASP Core Rule Set’s overall ability to detect and respond effectively to evolving security challenges. Together, these rulesets empower users to implement a robust and adaptable security framework for their web applications.

Understanding Paranoia Levels, Sampling and Anomaly Score #

The Paranoia Level setting allows you to specify the intensity of rule checks, influencing anomaly scores. Higher Paranoia Levels enhance security by enabling more rules but may increase the risk of blocking legitimate traffic due to false positives. Recommendations for each level:

Paranoia Level 1 (default): Suitable for beginners, diverse installations, and standard security setups, with rare false positives.
Paranoia Level 2: Recommended for moderate to experienced users seeking comprehensive coverage and heightened security. Expect some false positives.
Paranoia Level 3: Aimed at experienced users handling false positives, for installations with high security needs.
Paranoia Level 4: Advised for experienced users protecting installations with very high security requirements, but likely to produce a high number of false positives requiring resolution before going live.

To raise the blocking paranoia level, navigate to the REQUEST-901-INITIALIZATION Ruleset, then Edit in raw mode and modify rule ID 901120. Replace setvar:’tx.blocking_paranoia_level=1′ with your preferred level.

By employing the detection paranoia level, one can run rules from a higher paranoia level without factoring them into the anomaly scoring. This flexibility enables the incorporation of rules from paranoia level 2 into a finely tuned system at paranoia level 1, mitigating concerns about potential false positives that might escalate the score beyond the established threshold. As a default configuration, the detection paranoia level aligns with the blocking paranoia level. To increase the detection paranoia level, navigate to the REQUEST-901-INITIALIZATION Ruleset, then Edit in raw mode and modify rule ID 901125. Replace setvar:’tx.detection_paranoia_level=%{TX.blocking_paranoia_level}’ with your preferred level (ex. setvar:’tx.detection_paranoia_level=2′).

Each rule in the CRS is assigned a severity level, with default scoring points indicating the impact on the anomaly score when a rule matches. The severity levels and their corresponding scores are as follows:

CRITICAL: Anomaly Score of 5, primarily from application attack rules (93x and 94x files).
ERROR: Anomaly Score of 4, predominantly generated by outbound leakage rules (95x files).
WARNING: Anomaly Score of 3, mainly triggered by malicious client rules (91x files).
NOTICE: Anomaly Score of 2, primarily resulting from protocol rules (92x files).

In anomaly mode, these scores accumulate, allowing a single request to trigger multiple rules. Adjustments to these default points are generally unnecessary but can be customized based on specific requirements.

It can be defined the cumulative anomaly score at which an inbound request or outbound response will be blocked. By default, most detected inbound threats receive a critical score of 5, while smaller violations carry lower scores. At the default blocking thresholds, the CRS behaves similarly to previous versions, blocking and logging requests with a single critical rule match. Adjusting the blocking thresholds to higher values, such as 7 or 10, can make the CRS less sensitive, requiring multiple rule matches before blocking. However, caution is advised, as raising thresholds may allow some attacks to bypass rules or policies. Alternatively, a recommended deployment strategy involves initially setting high anomaly scoring thresholds (>100) and gradually lowering them as confidence in the system grows, offering a proactive approach to enhancing security over time.

By default, inbound anomaly score threshold is set to 5 and outbound anomaly score threshold is set to 4. To modify the inbound anomaly score threshold, navigate to the REQUEST-901-INITIALIZATION Ruleset, then Edit in raw mode and modify rule ID 901100. Replace setvar:’tx.inbound_anomaly_score_threshold=5′ with your preferred level (ex. setvar:’tx.inbound_anomaly_score_threshold=4′). The same way for the outbound anomaly score threshold with the rule ID 901110 replacing setvar:’tx.outbound_anomaly_score_threshold=4′.

The Early Anomaly Scoring Mode Blocking allows for an early assessment of request and response anomaly scores at the conclusion of phase:1 and phase:3, respectively, instead of waiting until the end of phase:2 and phase:4. Enabling this mode permits immediate blocking if the anomaly threshold is reached during the early evaluation, bypassing the execution of phase 2 (and phase 4, respectively). To activate early blocking, enable rule ID 901115 within REQUEST-901-INITIALIZATION ruleset, which sets the variable tx.early_blocking to 1 (disabled by default). It’s crucial to note that early blocking may conceal potential alerts, as payloads triggering phase 2 (or phase 4) alerts won’t be evaluated if early blocking is engaged. Disabling early blocking in the future may reveal new alerts from phase 2.

The Easing In / Sampling Percentage feature is designed to mitigate potential issues when integrating the CRS into an existing live site, such as false positives and unexpected performance impacts. To cautiously introduce the CRS, you can initially enable it for a limited number of requests. Once any issues are addressed, and confidence in the setup is established, you can gradually increase the ratio of requests subjected to the ruleset. Adjust the percentage of requests processed by the Core Rules by setting tx.sampling_percentage at the rule ID 901130 within REQUEST-901-INITIALIZATION ruleset; the default is 100, meaning every request undergoes CRS checks. The selection of checked requests is based on a pseudo-random number generated by ModSecurity. If a request is allowed to pass without CRS checking, it won’t have an entry in the audit log for performance reasons, but an error log entry is recorded. To disable the error log entry, issue the specified directive after including the CRS.