Site alerts

Site alerts monitor and handle requests from IP addresses that have been tagged with specific signals. Specifically, when the number of requests from an IP address meets the signal count threshold for a site alert, the IP address is flagged and select, subsequent requests from the IP address are blocked or logged for a set period of time.

The Events page lists all IP addresses that were flagged in the past 30 days, and the Observed Sources page provides an overview of all IP addresses that have been or soon will be flagged on your site.

Types of site alerts

There are two types of site alerts:

• System: site alerts that we've defined to monitor and handle requests from IP addresses that contain attack signals.
• Custom: site alerts that you define to monitor and handle requests from IP addresses that contain specific signals.

About system site alerts

System site alerts target attackers’ ability to use scripting and tooling. Specifically, they:

• monitor and flag IP addresses that exhibit repeat malicious behavior.
• handle requests from flagged IP addresses.

Flagging occurs when enough attacks are seen from a single IP address. More explicitly, we track the number of attack signals that are seen from a single IP address. When the number of attack signals associated with the IP address reaches one of our thresholds, we flag and blocklist that IP address.

After an IP address has been flagged, subsequent requests that are from the flagged IP address and that are tagged with an attack signal are either blocked or logged depending on the Agent mode setting. Specifically, requests with an attack signal are blocked if the agent mode is Blocked and logged if the agent mode is Not Blocking.

By default, malicious traffic from the IP address is blocked or logged for 24 hours. You can change the default time that blocklisted IP addresses are blocked by updating the blockDurationSeconds field via our API.

Limitations and considerations

When working with system site alerts, keep the following things in mind:

• Requests that have only been tagged with anomaly and custom signals are not counted towards flagging thresholds.
• 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.
• When an IP address is flagged by any Next-Gen WAF customer, we record that IP address as a known potential bad actor and make its status known across our whole network by tagging it with the Network Effect (SigSci IP) anomaly signal.

About custom site alerts

You can create custom site alerts to monitor and handle requests from IP addresses that contain specific signals. A custom site alert outlines:

• the criteria that must be met for an IP address to be flagged. For example, flag an IP address when there are 25 SQL Injection attack signals in 1 minute.
• how to handle requests from IP addresses that are flagged. You can either log subsequent requests or block subsequent requests containing attack signals from the IP address.
• how long to block or log subsequent requests from flagged IP addresses.

Limitations and considerations

When working with custom site alerts, keep the following things in mind:

• Custom site alerts are only included with the Professional and Premier platforms. They are not included as part of the Essential platform.
• Accounts are limited to 50 custom site alerts per site.
• Users with an Observer role cannot configure custom site alerts.
• With the Premier platform, you can block all requests from IP addresses that have been flagged for events using request rules with the Site Flagged IP (SITE-FLAGGED-IP) anomaly signal.

Adding a site alert

To create a custom site alert, complete the following steps:

1. Log in to the Signal Sciences console.

2. From the Sites menu, select a site.

3. From the Rules menu, select Site Alerts.

4. Click Add site alert.

   

5. Fill out the Add form as follows:

   • In the Long name field, enter a descriptive name for the alert (e.g., Increase in failed logins).
   • From the Signal menu, select the signal that the site alert should track.
   • In the Threshold field, enter how many requests containing the signal should be detected before the IP address is flagged.
   • From the Interval menu, select the number of minutes during which signals from the IP address are counted to determine if the threshold has been met.
   • Under When an IP hits the threshold, select whether the alert should log subsequent requests or block subsequent requests containing attack signals from the IP address. If you selected a custom or anomaly signal as the Signal, then you will only be able to log subsequent requests from the IP.
   • Under Take action for, select how long the IP address should be flagged. By default, IP addresses are flagged for 24 hours. You can set a custom duration by selecting Custom duration and choosing a duration.
   • Leave the Notifications checkbox selected to send an external notification (e.g., email and Slack) when the site alert is triggered. Deselect the checkbox to not send any external notifications.
   • Click the Status switch to enable the site alert.

6. Click Save alert.

Site alert precedence

When multiple site alerts exist, the Signal Sciences agent uses the following logic to determine which site rules should take precedence:

• The site alert with the lowest threshold and smallest interval for a given action (i.e., block or log) will be checked first.
• Site alerts with a block action do not compete for precedence against site alerts with a log action.
• After a site alert with a block action flags an IP address, other site alerts with a block action can't flag that IP address until the existing flag is lifted.
• After a site alert with a log action flags an IP address, other site alerts with a log action can't flag that IP address until the existing flag is lifted.
• A site alert with a block action and a site alert with a log action can both flag the same IP address.

Preventing specific IP addresses from being flagged

To prevent an IP address from being flagged by site alerts, create a request rule with an allow action. For example, let's say you plan to scan your web application for vulnerabilities. To ensure the scanning IP address isn't flagged, you can create a request rule with an allow action.