Blocking

Unlike other security products you may have seen before, Signal Sciences’ customers actually use our product in blocking mode.

What is a decision?

Instead of the legacy approach of blocking any incoming request that matches a regex, Signal Sciences takes an alternative approach by focusing on eliminating attackers’ ability to use scripting and tooling. When an incoming request contains an attack, a snippet of that request is sent to the Signal Sciences backend (see the Data Redactions FAQ to learn how this is done in a safe and private manner). The backend aggregates attacks from across all of your agents, and when enough attacks are seen from a single IP address, the backend reaches a decision to flag that IP address. Agents will pull those decisions and either log (when the agent mode is set to “not blocking”) or block (when set to “blocking”) all subsequent requests from that IP address that contain attacks.

How do I trust the decisions you make?

Our console provides transparency about which IP address we flagged, when and why we flagged it, and what action we took (log or block, depending on which mode you’re in).

What is the difference between “blocking” and “not blocking”?

When an IP address is flagged, “blocking” mode takes action by automatically blocking subsequent requests containing attacks for 24 hours after the decision has been reached by the backend. Because “blocking” mode only blocks requests containing attacks, legitimate traffic is still allowed through. Attacks are blocked by returning a unique HTTP 406 response code. By using the unique 406 response code—as opposed to a 404 or 500—your operations team won’t get paged thinking there’s an outage or issue with your application.

Agents can also be set to “not blocking” mode. In “not blocking” mode, charts in the console and decisions on flagged IP addresses appear in the event list and alert notifications to provide visibility into all attacks. Once a decision has been reached, subsequent attacks from flagged IP addresses are only logged, not blocked. Additionally, requests will not be blocked by any custom rules you have created to immediately block requests. If those rules are designed to also tag requests for visibility, requests will continue to be tagged.

Why would I want to use blocking mode?

You can see the decisions we reach while the agent mode is set to “not blocking”, so you’ll feel comfortable with how we’re identifying attacks before you switch to “blocking”. Additionally, since “blocking” still allows legitimate traffic through (i.e. requests that don’t contain attacks), running in blocking mode doesn’t negatively impact your application.

How do I change agent modes?

Owners can change the agent mode for all sites, while Admins and Users can change the agent mode for any sites they are member of. See Corp Management for more information.

1. In the top navigation of the console, click the agent mode.
2. Click on Manage. The agent configurations menu page appears.
3. Select Blocking, Not blocking, or Off.
4. Click Update.

What are the IP address flagging thresholds?

As requests with attack signals are sent to our backend, we track the number of signals that are seen from an IP address across all agents.

When the number of malicious requests from an IP address reaches one of the following thresholds, the IP address will be flagged and subsequent malicious requests will be blocked (or logged if the agent mode is set to “not blocking”) for 24 hours:

Note: Requests containing only anomaly signals are not counted towards IP address flagging thresholds.

How are block rules different than blocking mode?

Block rules block all requests from a given IP address. Block rules are never created automatically by Signal Sciences; all blocking rules are created by the customers themselves.

What are allow rules?

Allow rules give you the ability to allow all requests from certain IP address ranges or individual parameters, so they won’t show up in the console or affect decisions. Typical use cases are allowlisting an IP address range used for scanning, or parameters that might resemble attacks but are actually valid inputs in the application.

What is the precedence of allow and block rules?

When two conflicting rules are created, the allow rules will always take precedence over the block rules. For example, if you create a rule to block a range of IP addresses and a rule to allow one specific IP address within that range, requests from that IP address will be allowed because the allow rule takes precedence.

How do I change the default block duration for flagged IP addresses?

By default new flagged IP addresses are added to the blocklist (whether the agent mode is set to “blocking” or “not blocking”) for 24 hours. This default timeframe can be updated via API or a support request on a per site basis.

How do I configure the blocking mute period?

In some cases you may want to disable blocking during a specific time period to accommodate scheduled vulnerability scans of your applications. There are two ways to achieve this.

First, blocking mode can be disabled via our API. Scan automation scripts can include a call to the API to disable blocking mode before scheduled scans start.

Second, if scanner IP addresses are known then these IP addresses can be allowlisted by creating rules to allow them in the console.

How do I configure the time to lift IP address flag?

By default a flagged IP address will be removed from the flagged IP address list in 24 hours. This time period can be configured via our API by setting the blockDurationSeconds value when calling the update site by name endpoint.

What if I have a field that looks like SQL? How can I ensure it’s not blocked?

You can create signal exclusions to exclude requests matching your parameters from being tagged with certain signals.

Are flagged IP addresses tracked between customers?

Whenever an IP address is flagged by any Signal Sciences customer, we record that IP address as a known potential bad actor and make its status known across our whole network. If that same IP address is seen on another customer’s workspace, we indicate that it’s been identified as a potential threat by tagging it with the SigSci IP signal.

What happens when I see false positives?

These are very rare in practice, but we take them seriously. File a support ticket immediately. We can address these quickly on our end, and you won’t have to update the agent to see the changes take effect.