DDoS Protection

L7 (application layer) DDoS attacks use HTTP requests to exhaust origin resources. High-volume requests, slow-rate attacks like Slowloris, or targeted endpoint flooding fall into this category.

What does HEIMWALL do automatically?

Without any rules, HEIMWALL automatically applies: Managed Rules to block known attack signatures, the Threat List to stop malicious IPs, and a per-server raw request limit. The rules below add customisable thresholds on top of these automatic layers.

Basic Rules

# JS challenge for requests with a high bot score
IF   waf.bot_score ge 60
THEN js

# Rate limit the login endpoint
IF   http.request.base_uri == /login
THEN ratelimit 20/60s

# High bot activity from hosting IPs
IF   waf.client.ip_type == hosting
AND  waf.bot_score ge 50
THEN captcha

With these selections in the console:

• JS challenge for high bot score — Field Bot Score (0–100) · Operator greater or equal · Value 60 → Action JS Challenge
• Rate limit the login endpoint — Field Path (without query) · Operator equals · Value /login → Action Rate Limit (20 requests / 60 s)
• CAPTCHA for hosting + bot score — Field IP Infrastructure Type · Operator equals · Value hosting AND Field Bot Score (0–100) · Operator greater or equal · Value 50 → Action CAPTCHA

The js action is the lowest-friction way to filter out non-browser clients. Real browsers solve the JavaScript challenge and pass through; headless tools and raw HTTP clients get stuck. During an attack, lower the bot score threshold from 60 to 40 to widen the net.

Rate limiting the login endpoint prevents credential stuffing and brute-force attacks from being used as a DDoS vector. 20 requests per 60 seconds is a reasonable lower bound that covers normal user behavior.

High bot activity from hosting and data center IPs indicates the attack is being sent from rented cloud infrastructure. This combination almost never affects real end users.

Advanced Variant

# Cumulative signal: country + bot score
IF   ip.country in RU, CN
AND  waf.bot_score ge 40
THEN captcha

# Reduce concurrent request limit for a critical endpoint
IF   http.request.base_uri has_prefix /checkout
THEN maxconcurrent 20

With these selections in the console:

• Country + bot score CAPTCHA — Field Country · Operator in list · Value RU, CN AND Field Bot Score (0–100) · Operator greater or equal · Value 40 → Action CAPTCHA
• Concurrent limit for checkout — Field Path (without query) · Operator starts with · Value /checkout → Action Concurrent Request Limit (20)

Combining multiple signals reduces the risk of false positives. Traffic arriving from a specific country with a mid-to-high bot score is almost certainly an attack source; country alone or bot score alone can each cover legitimate clients in isolation.

maxconcurrent limits the number of simultaneous connections that can be open to an endpoint at the same time. On resource-intensive flows such as payments or checkout, this limit guarantees the origin continues to respond for legitimate users.

Tips

• During a DDoS, lower the Bot Score threshold to 40; normalize it after the attack subsides
• Use Concurrent Request Limit to protect critical endpoints from simultaneous load pressure on the origin side
• Exempt traffic with a bot score of 0–30; these are most likely real users