Site alerts allow you to define thresholds for when to flag an IP address and how to treat subsequent requests from that IP.
How do system alerts work?
As requests with attack signals are sent to our backend, we track the number of signals that are seen from an IP across all agents.
|Interval||Threshold||Frequency of Check|
|1 minute||50||Every 20 seconds|
|10 minutes||350||Every 3 minutes|
|1 hour||1,800||Every 20 minutes|
When the number of malicious requests from an IP reaches one of these thresholds, the IP will be flagged and subsequent malicious requests will be blocked (or logged if your agent mode is set to “not blocking”) for 24 hours.
Note: Requests containing only anomaly signals are not counted towards IP flagging thresholds.
How do site alerts work?
The thresholds for the system alerts are based on historical patterns that we’ve seen across all customers, but the default thresholds may not apply to every application.
Site Alerts can be used to set lower or higher thresholds to alert and optionally block requests from an IP.
How do I configure a site alert?
If your role is User or above, configure a site alert by going to Site Rules > Site Alerts and clicking New alert.
Choose any attack or anomaly signal and set a threshold and interval for when to flag an IP. Once an IP is flagged, for attack signals, choose to either log subsequent requests or block subsequent malicious requests from that IP. Anomaly signals can only log subsequent requests.
What is the precedence of alerts?
The alert (either system or custom) with the lowest threshold and smallest interval for a given action (“block” or “log”) will be checked first. If an IP is flagged, it won’t be reflagged by any other alerts until that flag is lifted (in 24 hours).
Note: “Blocking” and “logging” alerts are considered different types of alerts. This means that you can log (but not block) if Signal Sciences sees 25 SQLi in a minute, while we’ll still block subsequent requests from an IP if we see over 50 SQLi in a minute.