IP Blocking¶
When enabled, the IP Blocking feature allows you to use the HIT action in your rules.
The idea behind this feature is to allow users to not just allow or deny requests based on a single rule, but to allow to evaluate a visitor's behavior across multiple requests and to issue a longer blocking period after a certain threshold is reached.
The WAF holds a list of visitor IP addresses and their associated HIT Score in memory (or in a caching database for horizontal scaling). The score has a configurable TTL (time-to-live) after which it is reset to zero, if no rule adds more points to the score in the given time period.
You can define thresholds for certain levels of scores to then issue a blocking response that is valid for a configurable amount of time. Combined with the TTL of the score, this feature allows you to first block a visitor for a short period of time, and then gradually increase the block time as the visitor continues to violate the rules.
HIT actions can either add or subtract points from the visitor's score.
Configuration¶
This feature has its own configuration section in the global configuration file:
ip_blocking:
# Master toggle for IP blocking.
enabled: true
# How long HIT scores persist per IP. Each new HIT refreshes the TTL.
score_ttl: "1h"
# Block thresholds - The highest matching threshold determines the block duration.
thresholds:
- name: light-offender
threshold: 10
duration: "5m"
- name: heavy-offender
threshold: 50
duration: "1h"
- name: persistent-offender
threshold: 100
duration: "24h"
# (Optional) Named IP lists to block on a static basis
# static_lists:
# - "known-bad"
#
# (Optional) Custom block response. Falls back to policy.defaults.deny.
# response:
# status_code: 403
# body_from_file: "/etc/rescaled-waf/pages/blocked.html"
# headers:
# X-Blocked-By: rescaled-waf
#
# Persist blocklist and scores to disk on shutdown, reload on startup.
persistence:
enabled: false
# file_path: "/var/lib/rescaled-waf/ip-block-state.json"
Persistence¶
In case you're operating rescaled WAF standalone (just a single instance), you can enable persistence to store the blocklist and scores in a file. This allows you to restart the service without losing any data. When horizontally scaling, this option is not necessary, because the state is stored in a caching database anyway.
Rules¶
Our GPR (General Purpose Rules) already include a number of rules that should be generically applicable to most WAF deployments.
In order to prevent potential attackers to try to access a potentially requestable .env file or files from a .git directory, you can e.g. compose a rule that looks like this:
Whenever an attacker tries to access a file (or directory) that matches the given regular expression, they will accumulate a score of +25 points for their request IP address. Based on the example thresholds shown above, this would immediately result in a blocking response and a subsequent block for all requests from that IP address for the next 5 minutes.
After a second attempt, the score would go up to 50 points, thus resulting in another immediate block followed by a subsequent blocking period of 1 hour.
To learn more about how to write rules, please refer to our rule building guide.
Block from IP List¶
You can also statically configure certain IP Lists to be blocked by default. That way you don't need to maintain a separate rule to match against the IP list and issue a DENY action. You should only use this functionality, if you want to use the IP Blocking feature anyway, as it adds a bit of performance overhead compared to when the feature isn't enabled.