RELIANOID Web Application Firewall #

The Web Application Firewall (WAF) functions as a crucial tool in identifying and preventing malicious HTTP traffic within HTTP(S) farms. By analyzing patterns, it enforces advanced security policies on organized sets of rules, which are then applied to HTTP farms. After decrypting SSL packets, the WAF rules are scrutinized, enabling the application of patterns to the HTTP body within SSL traffic.

The RELIANOID IPDS package incorporates the OWASP ModSecurity Core Rule Set, pre-loaded and ready for use, while users retain the flexibility to create custom rulesets for comprehensive system protection against diverse attacks. To explore further details on OWASP rules, users can refer to the OWASP Modsecurity Project. Additionally, it’s worth noting that the RELIANOID WAF module extends its functionality beyond HTTP protection to encompass advanced HTTP content manipulation, including redirects and rewrites.

WAF Rulesets View #

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

Name. A descriptive name to identify a ruleset. Click on it to enter the editing form.
Farms. The Farms to which the rule is applied. You may expand the farm list using an upward arrow placed adjacent to the FARMS column header on its right. By default is limited to 20 characters.
STATUS. Ruleset status is represented by the following status color codes:

• Green. Means ENABLED. The ruleset is being checked for the farms that are using it.
• Red. Means DISABLED. The ruleset is not enabled, thus it is not having any effect on the farm.

Actions. Allowed actions for the status of the WAF rules:

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