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, the backend reaches a decision to flag that IP. 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 that contain attacks.
How do I trust the decisions you make?
Our console provides transparency about which IP 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”?
All agents are set to “not blocking” mode by default. Visibility is provided into all attacks via charts in the console, and decisions on flagged IPs are displayed via the event list and alert emails. Once a decision has been reached, subsequent attacks are logged, not blocked.
“Blocking” mode takes action by automatically dropping subsequent requests containing attacks for 24 hours after the decision has been reached by the backend. Attacks are blocked by returning a unique HTTP 406 response code, not 404 or 500, so that your Operations team doesn’t get paged thinking there’s an outage or issue with the application. Because we don’t block legitimate traffic from the flagged IP, our customers have the confidence to use blocking mode. You can choose to block all traffic from an IP by creating a block rule.
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?
To switch agent modes, click on the agent mode in the top navigation and then click on Manage. Then select Blocking, Not blocking, or Off.
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.
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 across all agents.
When the number of malicious requests from an IP reaches one of the following thresholds, the IP will be flagged and subsequent malicious requests will be blocked (or logged if the agent mode is set to “not blocking”) for 24 hours:
|Interval||Threshold||Frequency of Check|
|1 minute||50||Every 20 seconds|
|10 minutes||350||Every 3 minutes|
|1 hour||1,800||Every 20 minutes|
Note: Requests containing only anomaly signals are not counted towards IP 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 ranges or individual parameters, so they won’t show up in the console or affect decisions. Typical use cases are allowlisting an IP 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 IPs?
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 flag?
By default a flagged IP will be removed from the flagged IP 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 IPs tracked between customers?
Whenever an IP 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 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.