20/05/2024
In this article Curious about Signal Sciences Web Application Firewall? Let's break it down! This article will guide you through the essentials of Signal Sciences Web Application Firewall.
Signal Science Signal :
A Signal is a descriptive tag about a request, a request gets one or multiple tags based on rules a request triggers.
Defined Systems signals
Attack Signal
Triggered by malicious request attack payloads, to hack, destroy, disable, steal…
Here’s an example of such request with a URL with an attempt of SQL Injection :
https://www.example.com/search?q=SELECT+*+FROM+users+WHERE+username='$username'
Anomaly Signal
These signals indicate unusual or potentially malicious activities that don’t fit into specific attack categories, but are still suspicious.
Examples include:
- Failed attempts to access admin page :
like https://example.com/wp-admin
- Requests with Invalid encoding :
UTF-8: A common exploit vector involves sending invalid byte sequences that break UTF-8 encoding rules. For example, a lone byte %C3 which is not followed by a valid continuation byte.
Request example :
POST /login HTTP/1.1
Host: example.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 40
username=%27%20OR%201=1;%20--%20&password=test
Here, %27 represents an apostrophe, which could be part of a SQL injection payload.
Exploit: The application might concatenate the injected payload directly into a SQL query, leading to SQL injection.
- Malformed data in the request body, which might indicate a malicious request
Like incorrect JSON data send to an API in order to cause the server to throw an error, potentially leading to a denial of service if the server does not handle such errors gracefully. In some cases, improperly handled parsing errors could be exploited to reveal internal server information or cause unexpected behavior.
Both Attack Signals and Anomaly Signals are referred to as System Signals, as they are built into the system.
SigSci Custom Signals
Defined by users, are tagged to requests that match user-defined conditions.
Custom signals are created at either the corporation level (Corp Signals) or the site level (Site Signals). They can be used to tag specific requests based on custom rules. This tagging helps in identifying and managing unusual or malicious traffic more effectively.
Examples :
Blocking Web Crawlers:
- Scenario : If a site owner notices vulnerability scans from requests that do not use the proper hostname, they can create a custom signal to tag valid hostname requests.
-
Rule : Tag traffic that includes the domain acmecorp.com with a signal like Organization Domains.
-
Blocking Rule : Any request without the Organization Domains signal is blocked, effectively filtering out suspicious traffic that targets the IP directly.
Tagging Anonymous Email Domains :
- Scenario : To reduce fraudulent account registrations, a rule can be created to tag sign-ups using disposable email domains.
-
Rule : Tag requests with emails from known disposable domains with a signal like Disposable Email.
-
Action : Block or further inspect these requests, preventing the creation of fake accounts.
Thresholds
Thresholds determine when to trigger an action. For example, a threshold could be « 10 or more requests within 60 seconds. » Default attack thresholds are provided but can be customized. The default thresholds are:
Signal Science Rules :
Rules are settings that define conditions to block, allow, or tag requests either permanently or for a certain period.
System Rules
System rules are predefined in the tool, when applied they can generate System Signals for an Attac or Anomaly.
Request Rules
These rules let you set specific conditions to block, allow, or tag requests either permanently or for a certain time. In the UI, these rules are grouped together.
Type :
Conditions :
Actions :
Select the Action(s) that will happen when the conditions are met
Exclusion Rules
Signal Exclusion Rules let users specify which requests should have System Signals tags removed from them. This helps reduce false positives. For instance, you can remove the XSS Attack Signal from endpoints where users are expected to submit valid scripts.
Rate Limit Rules
Rate Limit Rules allow users to set conditions to either block requests or log them with a rate-limit signal if they exceed a specified threshold within a certain time window. For instance, a threshold could be « 10 or more requests within 60 seconds. » If any IP sends 10 or more requests within the last 60 seconds, it triggers related rules, such as Custom Signals or blocking requests from that IP. Many of our rules rely on thresholds like this for their logic.
Rate Limit applies at the Site Level
Templated Rules
Partially pre-made rules. When you fill them out, they let you block requests, flag IPs for blocking or logging, or tag specific types of requests. These rules are useful for managing registrations, logins, and virtual patches in customer applications by setting up simple rules. There are three types of templates: API, ATO (Account Take Over), & CVE (Common Vulnerabilities and Exposures).
Systems Alters and Site Alerts
System Alerts are preset thresholds for the number of requests with attack signals over time. You can adjust these thresholds in your Site Settings under Attack Thresholds. This rule lets users pick any attack, anomaly, or custom signal and set a threshold and interval for when to flag and alert, and optionally block subsequent attacks from an IP.
SigSci’s architecture
SigSci is built to be flexible. This means you can choose where to put the software that deals with incoming requests. This software comes in two parts: Modules and Agents. They work together to sort through requests and block bad ones.
Step 1
A request arrives, then the barrel man (module) detects the request and informs the captain (agent) about the request.
The module (barrel man) : Receives the Request, Sends Req to Agent and Enforces Agent Decision
Step 2
The captain (agent) asks the Admiralty (sites) what should be done with that request, intercept it, let it though.
The agent (Captain) : Applies Rules, Generates Signals, Decide Allow/Block
The sites (Admiralty) : Those Signals and a host of other data will migrate up to the Site level and the Corp level.
Corp level
Starting with the Corp, this is the customer account. Collected here are settings for common account elements like Access Tokens and User Management, along with Signal Sciences specifics like Corp Monitoring, Corp Rules, and Sites. Corp Monitoring allows users to see metrics at an account level.
The Corp Rules are all the user-defined rules, as discussed earlier, that will be applied across the Corp via each Site
Within each Corp, users can set up multiple Sites. A Site, aka workspace, can be for a single web application, a bundle of web applications, API, or microservice that Signal Sciences can protect from attacks.
Corp – Sites
Like with Corps, Sites can have their own level of Rules that can be configured. The Site’s Rules are bundled with the Corp’s Rules and passed to the linked Agents. Agents send back data to pass through the Site for Site level monitoring, which could then be rolled up into Corp level Monitoring too.
Agent Mode
Blocking Mode : Applying rules to : Block request yes – Log request yes
Logging Mode : Applying rules to : Block request no – Log request yes
Off Mode : Applying rules to : Block request no – Log request no
All agents under a site can be set to one of these modes. When an Agent is set to Off Mode, the linked Module will fail-open ensuring traffic is not blocked.
Monitor attacks
- Suspicious IPs are IPs with requests, containing signals, numbering below the configured Attack Thresholds.
- Flagged IPs are IPs with requests, containing signals, numbering at or above the configured Attack Thresholds.
Flagged IPs will stay flagged for 24 hours, unless configured otherwise. Even if the number of requests with attack signals falls below the threshold, the IP will stay Flagged until the configure duration finishe
