Skip to main content
Version: Next

Advanced WAF Deployments

This guide covers advanced CrowdSec WAF deployment strategies for organizations looking to gradually enhance their web application security posture. Learn how to progressively improve your WAF configuration from basic virtual patching to comprehensive multi-layer protection.

This guide assumes you have completed the General Setup and have a functional basic WAF deployment.

About OWASP Core Rule Set (CRS)​

The OWASP Core Rule Set (CRS) is a set of generic attack detection rules for use with ModSec-compatible web application firewalls. CRS aims to protect web applications from a wide range of attacks, including the OWASP Top Ten, with minimal false positives.

Key features of OWASP CRS:

  • Comprehensive Coverage: Protects against SQL injection, XSS, command injection, path traversal, and many other attack types
  • Generic Detection: Uses pattern-based rules that detect attack techniques rather than specific exploits
  • Mature Ruleset: Actively maintained by the OWASP community with regular updates
  • Configurable Sensitivity: Supports paranoia levels to balance security vs false positives
  • Wide Compatibility: Works with various WAF engines including CrowdSec's AppSec component

CRS vs Virtual Patching:

  • Virtual Patching: Targets specific known vulnerabilities (CVEs) with minimal false positives
  • CRS: Provides broad attack pattern detection with comprehensive coverage but may require tuning

In CrowdSec, CRS rules can be deployed in two modes:

  • Out-of-band: Analyzes traffic without blocking, triggers bans after multiple violations
  • In-band: Blocks malicious requests immediately at detection time

Security Enhancement Path​

CrowdSec WAF supports multiple deployment strategies that can be implemented progressively:

1. Basic Virtual Patching (Quickstart)​

Current State: Blocking protection against known CVEs

2. Enhanced Detection (Out-of-band CRS)​

Next Step: Add comprehensive attack detection without performance impact

  • Add: crowdsecurity/appsec-crs-inband (out-of-band) alongside existing virtual patching
  • Mode: Non-blocking analysis + behavioral banning
  • Coverage: OWASP Top 10 + comprehensive attack patterns + specific CVE protection
  • Performance: No latency impact ⚡
  • Security: Layered approach - virtual patching + generic attack detection

3. Maximum Protection (In-band CRS)​

Advanced: Full blocking protection with comprehensive coverage

  • Modify: Use crowdsecurity/appsec-crs-inband for blocking CRS while keeping virtual patching
  • Mode: Immediate blocking of all detected attacks (both generic and CVE-specific)
  • Coverage: Maximum protection with instant response 🛡️
  • Security: Dual-layer blocking - virtual patching handles specific vulnerabilities, CRS covers generic attack patterns
  • Consideration: Might require tuning to minimize false positives

Implementation Guide​

Step 2: Adding Out-of-band CRS​

Enhance your existing virtual patching deployment by adding comprehensive attack detection as an additional security layer:

Install CRS collection
sudo cscli collections install crowdsecurity/appsec-crs

The crowdsecurity/appsec-crs collection includes:

  • crowdsecurity/crs: AppSec config that loads CRS rules in out-of-band mode
  • crowdsecurity/crowdsec-appsec-outofband: Scenario that bans IPs after 5+ out-of-band rule violations

Update your WAF acquisition configuration to include both rule sets:

/etc/crowdsec/acquis.d/appsec.yaml
appsec_configs:
  - crowdsecurity/appsec-default     # Virtual patching rules (in-band blocking)
  - crowdsecurity/crs                # OWASP CRS rules (out-of-band detection)
labels:
  type: appsec
listen_addr: 127.0.0.1:7422
source: appsec
name: myAppSecComponent
Restart CrowdSec
sudo systemctl restart crowdsec

Benefits of this layered configuration:

  • Layer 1: Immediate protection against known vulnerabilities (virtual patching)
  • Layer 2: Comprehensive attack pattern detection (CRS out-of-band)
  • Complementary Coverage: Virtual patching rules catch specific CVEs that CRS generic rules might miss
  • Behavioral analysis and repeat offender banning
  • No performance impact on legitimate traffic

How to Test Step 2: Out-of-band CRS Detection​

After implementing the layered configuration, verify both protection layers are working correctly:

Test 1: Virtual Patching Layer (Immediate Blocking)

Test that virtual patching rules block requests immediately by trying to access sensitive files:

# Test .env file access (common vulnerability)
curl -v "http://your-app.com/.env"
curl -v "http://your-app.com/api/../.env"

Expected result: These requests should be immediately blocked with HTTP 403 Forbidden.

Test 2: CRS Out-of-band Detection Layer

The crowdsecurity/crs collection brings general detection for OWASP top10 attacks, which can be tested:

# Replace with your application URL
TARGET="http://your-app.com"

# SQL injection attempts (trigger multiple CRS rules)
curl "$TARGET/?id=1'+OR+'1'='1"

Expected results:

  • Detailed Alert is created (see cscli alerts list)
cscli alerts list output
+-------+--------------------+--------------------------------------------------------------+---------+------------------------------+-----------+----------------------+
|   ID  |        value       |                            reason                            | country |              as              | decisions |      created_at      |
+-------+--------------------+--------------------------------------------------------------+---------+------------------------------+-----------+----------------------+
| 62419 | Ip:xxx.xx.xx.xx    | anomaly score out-of-band: sql_injection: 10, anomaly: 10,   | FR      | 5410 Bouygues Telecom SA     |           | 2025-09-09T14:41:07Z |
...
  • Detailed Alert is visible in console
Details

Alert Console view timeline

Test 3: Verify Scenario Behavior

The crowdsecurity/crowdsec-appsec-outofband scenario will ban IPs triggering the CRS on more than 5 distinct requests on a short period, which can be tested:

for i in {1..6}; do curl "$TARGET/?id=1'+OR+'1'='1"; done

Expected results:

  • Alerts are created for each request
  • Decision is created by the 6th request
cscli alerts list output
───────┬────────────────────┬──────────────────────────────────────────────────────────────┬─────────┬──────────────────────────────┬───────────┬──────────────────────╮
│   ID  │        value       │                            reason                            │ country │              as              │ decisions │      created_at      │
├───────┼────────────────────┼──────────────────────────────────────────────────────────────┼─────────┼──────────────────────────────┼───────────┼──────────────────────┤
│ 62427 │ Ip:xxx.xx.xx.xx    │ crowdsecurity/crowdsec-appsec-outofband                      │ FR      │ 5410 Bouygues Telecom SA     │ ban:1     │ 2025-09-09T14:51:11Z │
│ 62426 │ Ip:xxx.xx.xx.xx    │ anomaly score out-of-band: sql_injection: 10, anomaly: 10,   │ FR      │ 5410 Bouygues Telecom SA     │           │ 2025-09-09T14:51:12Z │
│ 62425 │ Ip:xxx.xx.xx.xx    │ anomaly score out-of-band: sql_injection: 10, anomaly: 10,   │ FR      │ 5410 Bouygues Telecom SA     │           │ 2025-09-09T14:51:11Z │
│ 62424 │ Ip:xxx.xx.xx.xx    │ anomaly score out-of-band: sql_injection: 10, anomaly: 10,   │ FR      │ 5410 Bouygues Telecom SA     │           │ 2025-09-09T14:51:11Z │
│ 62423 │ Ip:xxx.xx.xx.xx    │ anomaly score out-of-band: sql_injection: 10, anomaly: 10,   │ FR      │ 5410 Bouygues Telecom SA     │           │ 2025-09-09T14:51:11Z │
│ 62422 │ Ip:xxx.xx.xx.xx    │ anomaly score out-of-band: sql_injection: 10, anomaly: 10,   │ FR      │ 5410 Bouygues Telecom SA     │           │ 2025-09-09T14:51:11Z │
│ 62421 │ Ip:xxx.xx.xx.xx    │ anomaly score out-of-band: sql_injection: 10, anomaly: 10,   │ FR      │ 5410 Bouygues Telecom SA     │           │ 2025-09-09T14:51:11Z │

Step 3: CRS In-band (Blocking Mode)​

For organizations requiring maximum protection, configure CRS rules to block requests immediately by installing the in-band CRS collection:

Install CRS in-band collection
sudo cscli collections install crowdsecurity/appsec-crs-inband

Update Acquisition Configuration​

Modify your acquisition to use the in-band CRS configuration:

/etc/crowdsec/acquis.d/appsec.yaml
appsec_configs:
  - crowdsecurity/appsec-default     # Virtual patching rules (in-band blocking)
  - crowdsecurity/crs-inband         # OWASP CRS rules (in-band blocking)
labels:
  type: appsec
listen_addr: 127.0.0.1:7422
source: appsec
name: myAppSecComponent
Restart CrowdSec
sudo systemctl restart crowdsec

How to Test Step 3: CRS In-band Blocking​

After configuring CRS for in-band (blocking) mode, test that both virtual patching and CRS rules provide immediate blocking:

Test 1: Virtual Patching Layer (Still Blocking)

Verify virtual patching continues to work:

# These should still be immediately blocked
curl -v "http://your-app.com/.env"

Expected result: HTTP 403 Forbidden immediately.

Test 2: CRS In-band Blocking

Test that CRS rules now block requests immediately (no more out-of-band delay):

TARGET="http://your-app.com"

# SQL injection - should be blocked immediately
curl -v "$TARGET/?id=1' OR '1'='1"

# XSS - should be blocked immediately  
curl -v "$TARGET/?q=<script>alert('xss')</script>"

# Command injection - should be blocked immediately
curl -v "$TARGET/?cmd=; cat /etc/passwd"

# Path traversal - should be blocked immediately
curl -v "$TARGET/?file=../../../etc/passwd"

Expected behavior:

  • All requests above: Immediately blocked with HTTP 403 Forbidden
  • No delay: Unlike out-of-band mode, blocking is instant
  • Dual protection: Both virtual patching AND CRS rules provide immediate blocking

In-band CRS blocking provides maximum protection but requires:

  • Thorough testing in a staging environment
  • Gradual rollout to production traffic
  • Monitoring and tuning to prevent blocking legitimate requests
  • Whitelisting capabilities for false positives

Next Steps​

Once you've implemented advanced deployments: