Denial Of Service Policy | MuleSoft Documentation
# 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  
Rate Limiting and Throttling  
Throttling and Rate Limiting  
## Configure a DoS Policy
  1. 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.   
---  
  2. Click **General** on the left navigation bar:
    1. Add a name for your policy in the **Name** field.
    2. 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.
    3. 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.
    4. 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**.  
---  
  3. 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. This includes when the client sends a bad certificate during an SSL handshake, authentication or authorization failure in an AAA policy, or when a WS-Security Verify policy fails to verify a WS-Security signature. Violations to LDAP, HTTP, OAuth, OpenAM, or Ping Federate authentication policies in API Manager are escalated to the DoS policy as **Authentication Errors**. IP Allowlist policy violations also escalate as authentication errors.  
Whenever a Quality of Service (QoS) error occurs. For example, a client may try to force a lot of QoS errors by dropping packets to degrade the TCP service, damaging your TCP performance. 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**.  
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**.  
## See Also
  * IP Allowlist Policy
  * HTTP Limits Policy
  *   * Enable DoS for a WAF Policy