Denial Of Service Policy
The Denial of Service (DoS) policy prevents attackers from flooding your network to prevent legitimate network traffic to your APIs. For example, malicious clients could send huge payloads designed to consume resources and bandwidth to your network.
When you create a DoS policy, you configure a time span and action to take when the error types you configure are encountered. If the policy encounters more errors than your configured threshold coming from the same IP address, the policy can either drop the connection silently (doesn’t attempt the TLS connection), or drop the connection immediately and return a 503 error.
The DoS policy determines the source of the request in the following three ways:
-
TCP Message - source IP address
-
Source IP address header field
-
Proxy Protocol IP address
Since the source of the request is based on the IP address, if an attacker spoofs the source IP address, the DoS Policy cannot prevent the attack.
Prerequisites
To configure and use the security policies, you must:
-
Have the Anypoint Security - Edge entitlement for your Anypoint Platform account.
If you don’t see Security in Management Center, contact your customer success manager to enable Anypoint Security for your account.
-
Have Runtime Fabric on VMs/Bare Metal with inbound traffic configured. Anypoint Runtime Fabric is a container service that automates the deployment and orchestration of Mule apps and API gateways.
Refer to the Runtime Fabric documentation.
Runtime Fabric requires the Anypoint Integration Advanced package or a Platinum or Titanium subscription to Anypoint Platform.
-
Enable inbound traffic on Runtime Fabric to allow Mule apps and API gateways to listen on inbound connections.
Rules, Thresholds, and Escalations
To understand how to configure a DoS policy, you need to understand when and why a client’s message is filtered by your DoS policy.
The when is determined by the window you configure, and the why is determined by the DoS threshold.
You can configure a time interval window when you configure the different errors for your DoS policy. The time interval is measured in seconds and determines, after receiving an error alert, that a DoS attack is taking place and applies your configured action to the attacker’s message.
The DoS actions that you can configure include:
-
None
If you do not create rules, no action is taken. -
Limit its messages
This rule restricts the specified client’s message rate until the end of the time window you configure (for the rest of the specified time window or indefinitely). -
Block all messages
The policy rejects all the client’s message requests until the end of the time window you configure (for the rest of the specified time window or indefinitely).
After the specified interval of time expires, the policy does not enforce shape- or block-interval.
Within each window, you can configure the number of errors that you want to allow within the time window. This number of errors is a DoS count. You can configure up to three DoS windows for each type of DoS error. Within each window, the policy can apply one of the DoS actions to the client’s message requests whenever your configured DoS count is met.
For example, you can configure a 60 second window (1 minute interval), and configure the policy so that if 2 protocol errors happen within that time window ("2" is then your DoS count), all further requests from the client are rejected (apply a Block-Forever action).
You can configure up to three different rules for each error. Each rule corresponds to escalation levels. Rule A is the lowest escalation level and Rule C is the highest escalation level.
When configuring a rule with a higher escalation level than Rule A, you can set up the interval for those rules based on the interval of the preceding rule (Rule A for Rule B, and Rule B for Rule C).
For example, you can set Rule B to be two intervals of Rule A, which means that if Rule A has an interval of 60 seconds, then Rule B will have a 120 seconds interval.
Additionally, you can configure a different DoS count for each rule, which introduces the concept of thresholds.
Each rule has a different threshold:
-
For Rule A, the threshold is the value of the DoS count when a DoS action is applied within Rule A.
-
For Rule B, the threshold is the value of the Rule B DoS count when a DoS action is applied in Rule B.
Keep in mind, that a Rule B DoS count is the number of Rule A DoS actions taken within that Rule B. -
For Rule C, the threshold is the value of the Rule C DoS count when a DoS action is applied in Rule C, and also that a Rule C DoS count is the number of Rule B DoS actions taken within that Rule C.
Based on this, window escalation occurs when a DoS threshold is violated.
Escalate Policy Violations as Errors
If you have a DoS policy configured, HTTP protocol errors (malicious protocol violation attempts), IP Allowlist, WAF, and HTTP Limits policy violations escalate to DoS. Some policies provided by API Gateway escalate to DoS as well. See the table below for a specific mapping of violations and error escalations:
| Violation | Escalates as |
|---|---|
Anypoint Security Policy |
|
IP Allowlist Policy |
Authentication Error |
HTTP Limits Policy |
Protocol Error |
Errors at the Endpoint Level |
|
HTTP Protocol Errors at endpoint |
Protocol Errors |
TLS Handshake Errors at endpoint |
Protocol Errors |
Requests received at the exposed endpoint with unroutable API Paths |
Routing Errors |
API Gateway Provided Policy |
|
Client ID Enforcement |
Authentication Error |
Mule OAuth 2.0 Access Token |
Authentication Error |
OpenAM OAuth 2.0 Token Enforcement Policy |
Authentication Error |
OpenID Connect OAuth 2.0 Token Enforcement |
Authentication Error |
PingFederate OAuth 2.0 Token Enforcement |
Authentication Error |
Basic Authentication: Simple |
Authentication Error |
Basic Authentication: LDAP |
Authentication Error |
IP Blocklist |
Content Error |
IP Allowlist |
Content Error |
JSON Threat Protection |
Content Error |
XML Threat Protection |
Content Error |
Rate Limiting and Throttling - SLA-Based Policies concepts |
QoS Error |
Rate Limiting and Throttling |
QoS Error |
Throttling and Rate Limiting |
QoS Error |
Configure a DoS Policy
-
Navigate to Anypoint Security, click Create Policy, and select Denial Of Service.
The process of applying a DOS Policy has six different screens.Save every screen before leaving it, or you lose your changes on that screen. -
Click General on the left navigation bar:
-
Add a name for your policy in the Name field.
-
Set up a time interval, in seconds, in Rule A Time Period.
This time interval is the threshold at which your policy begins to block requests if it encounters the number of errors that you configure for each type of error. -
Use the Max Sources To Monitor field to set up a maximum number of IP address to track.
The DoS policy can be configured to track up to 500000 IP addresses. -
Use the Reject Message Action drop-down menu to select the type of response the policy returns when dropping a client connection. You have two options:
-
Drop Silently: The policy drops the connection silently and avoids making the TLS handshake altogether. The policy avoids making the connection for the TCP packets with source IP address in AWS ELB Proxy Protocol headers, or for source IP address taken from the TCP packet. This is the most efficient way to terminate the client’s connection, as the policy avoids reading the attacker’s request.
-
Send HTTP 503: The policy terminates the connection and returns a
503 (Service Unavailable)response to the client. This requires a TLS connection to be made, which is resource expensive.The DoS policy must connect and read the source IP headers in the HTTP message, such as ‘x-forwarded-for’ or ‘forwarded’, before applying a DoS action, if the following is true:
-
Your applications are behind a load balancer.
-
The load balancer is not AWS ELB supporting Proxy Protocol V1 or AWS NLB.
This is true whether or not you specified Drop Silently for the Reject Message Action.
-
-
-
-
Now you can configure your policy to take action for the different error types.
Error Types
When you configure the DoS policy, you can configure different error types, which correspond to existing security policies. For example, the Protocol Errors correspond to HTTP Limits policy violations. When you configure the different error types, you are configuring the threshold at which policy violations are sent (escalated) to the DoS policy for action. See Rules, Thresholds, and Escalations. The way you configure the errors determines what action is taken when the configured threshold is met.
| Error | Description |
|---|---|
Protocol Errors |
When a client sends malformed protocol messages. An HTTP Limits policy violation is escalated to the DoS policy as Protocol Errors. |
Routing Errors |
When a client sends a message request which cannot be successfully routed to an application. Violations to IP blocklist/allowlist or RAML validation policies in API Manager are escalated to the DoS policy as Routing Errors. |
Authentication Errors |
Anytime an authentication or authorization failure occurs. Violations to LDAP, HTTP, OAuth, OpenAM, or Ping Federate authentication policies in API Manager are escalated to the DoS policy as Authentication Errors. |
QoS Errors |
Whenever a Quality of Service (QoS) error occurs. Violations to a rate limiting, or SLA based, or Ping Federate policy at the API Manager level are escalated to the DoS policy as QoS Errors. |
Content Errors |
Content errors happen when the client sends corrupt data that doesn’t conform to a schema and/or violates a Content Attack Prevention policy. Violations to a JSON or XML threat protection policy at the API Manager level are escalated to DoS as Content Errors. |
WAF Errors |
Configure actions to apply to WAF errors, for example, blocking an IP address for a specified time interval. Violations to response or request rulesets are escalated to DoS as WAF Errors. |