# How DDoS Shield works

> How DDoS Shield decides which traffic reaches a floating IP, through protection modes, profiles, rules and rate limits.

Source: https://www.coritan.com/docs/ddos-shield/how-ddos-shield-works/

DDoS Shield filters the traffic sent to your floating IPs. It runs at Coritan's points of presence, where traffic enters our network, so it drops an attack before the attack reaches your instance or server. It is on for every floating IP on your account from the moment we assign it, whether or not the floating IP is attached.

This page explains what DDoS Shield checks and what decides the outcome for each address. [Change a floating IP's DDoS protection](/docs/floating-ips/shield-settings/) shows how to change the settings.

## What DDoS Shield covers

| Traffic to | Filtered by DDoS Shield |
|---|---|
| A floating IP attached to an instance or a server | Yes |
| A floating IP that is not attached | Yes |
| The IPv4 address that comes with a Cloud Compute instance | Yes |
| Each host address of a subnet | Yes |
| The shared address of a Container Apps server | No |

The address that comes with a Cloud Compute instance is a floating IP, so DDoS Shield filters it like any other. A subnet has one set of settings for all of its hosts ([How subnets work](/docs/floating-ips/subnets/)).

A Container Apps server without a floating IP is reached on the shared address of its machine. That traffic goes to the machine directly and does not pass through DDoS Shield ([How the Coritan network works](/docs/platform/network/#traffic-to-a-shared-address)). To put a server behind DDoS Shield, attach a floating IP to it.

Protection belongs to the floating IP, not to the machine. When you move a floating IP to another instance or server, its settings move with it ([Attach and detach a floating IP](/docs/floating-ips/attach-and-detach/)).

DDoS Shield does not filter the traffic your instance or server sends. Your DDoS Shield settings also do not apply to join addresses and web proxies: those run on Coritan's edge, which protects them in its own way ([Game server protection](/docs/ddos-shield/game-protection/), [TCP proxy protection](/docs/ddos-shield/tcp-proxy/)).

## Filtering is always on

Every packet meets the same checks at all times. Nothing switches on when an attack starts, and there is nothing to request: the checks apply from the first packet of an attack, and a rate limit applies as soon as a sender goes over it.

When DDoS Shield drops traffic to an address at a high rate, it records an *attack event*. The **Events** tab of DDoS Shield lists them ([Read attack events](/docs/ddos-shield/attack-events/)). An event is a record of what we dropped, and it does not change how we filter.

## Profiles

A *profile* holds the settings that decide what happens to traffic for an address: its protection mode, its rate limits, its rules and what happens when no rule matches. Each address uses one profile at a time.

*Platform default profile*
: The profile every address starts on. We set it, and you cannot change it.

*Per-address profile*
: A profile of the address's own, which **Customise** on the address's **Shield** tab creates at no charge. Its settings apply to that address alone ([Give the address its own profile](/docs/floating-ips/shield-settings/#give-the-address-its-own-profile)).

*Custom profile*
: A paid service that holds one set of settings for every address you bind to it, and adds blocked sources ([Order and use a custom profile](/docs/ddos-shield/custom-profiles/)).

## Protection modes

A profile's *protection mode* sets how much of the filtering applies to its addresses:

| Mode | Packet checks | Rate limits | Rules and blocked sources |
|---|---|---|---|
| **Standard** | Yes | The platform's | Yes |
| **Custom** | Yes | The profile's | Yes |
| **Passthrough** | No | No | No |

In every mode, **Passthrough** included, we drop packets that cannot be real traffic: a malformed IPv4 header, a packet whose sender is the address it is sent to, and a packet to or from a broadcast or multicast address, or from `0.0.0.0`. These drops do not appear as attack events.

> [!WARNING]
> With **Passthrough**, an attack on the address reaches your instance or server in full.

## What DDoS Shield drops

In **Standard** and **Custom**, traffic to an address goes through three stages in this order. A packet that one stage drops never reaches the next, so a rule cannot let through a packet that a check or a rate limit dropped.

1. Packet checks drop traffic that attacks use and normal traffic does not:
   - packets that carry IP options
   - packets whose time to live (TTL) is too low
   - packets from addresses that are never used on the internet, such as `10.0.0.0/8` and `192.168.0.0/16`
   - IP fragments
   - protocols other than TCP, UDP and ICMP, such as GRE and ESP
   - TCP packets with a combination of flags that no real connection sends, such as SYN with FIN
   - UDP packets with an oversized payload
   - UDP packets sent from the ports that reflection attacks use ([Reflection ports](#reflection-ports))
   - packets whose TCP, UDP or ICMP header is cut short
2. Rate limits drop what a sender, or all senders together, send over a limit ([Rate limits](#rate-limits)).
3. Rules decide what happens to the rest. Sources that a custom profile blocks are dropped first. Then the most specific rule that matches decides, and **When no rule matches** decides for traffic that no rule matches ([How rules are applied](/docs/floating-ips/shield-settings/#how-rules-are-applied)).

Traffic that passes all three stages goes on to your instance or server. We drop the rest without a reply to the sender.

You cannot turn a single check off. **Passthrough** turns all of them off at once, with the rate limits and the rules.

## Rate limits

Each address has four rate limits:

| Limit | What it counts |
|---|---|
| Per source | Packets from one sender to the address. |
| Aggregate | All packets to the address together. |
| SYN per source | New TCP connections from one sender. |
| ICMP per source | Pings and other ICMP packets from one sender. |

In **Custom**, the profile's limits apply, and you can change them ([Rate limits](/docs/floating-ips/shield-settings/#rate-limits)). In **Standard**, the platform's own limits apply instead. A limit allows short bursts of up to twice its rate and drops the rest.

A platform-wide limit also caps the packets one sender may send to all the addresses we filter together, whatever each address's profile says. Traffic over it appears in attack events as `global_rate_limit`.

## Reflection ports

In a *reflection attack*, the attacker sends small requests to public services, such as DNS or NTP servers, with your address forged as the sender. The services send their much larger answers to your address, and the answers come from the service's own port. In **Standard** and **Custom**, DDoS Shield therefore drops every UDP packet sent to your address from one of the ports below. Your rules cannot let these packets through.

The list is about the port a packet comes from. A service on your address that listens on one of these ports, such as a game server on `27015`, still receives its players, whose packets come from other ports. Replies to requests that your machine sends from the floating IP to these ports are dropped, though, so a DNS lookup, an NTP time sync or an IPsec or OpenVPN tunnel on these ports fails ([Troubleshooting](/docs/floating-ips/shield-settings/#troubleshooting)).

| Port | Service |
|---|---|
| `17` | QOTD (Quote of the Day) |
| `19` | Chargen |
| `53` | DNS |
| `111` | Portmap (rpcbind) |
| `123` | NTP |
| `137` | NetBIOS Name Service |
| `161` | SNMP |
| `389` | CLDAP |
| `500` | ISAKMP (IPsec key exchange) |
| `520` | RIP |
| `1194` | OpenVPN |
| `1434` | Microsoft SQL Server Browser |
| `1900` | SSDP (UPnP) |
| `3283` | Apple Remote Desktop |
| `3702` | WS-Discovery |
| `4500` | IPsec NAT traversal |
| `5353` | mDNS |
| `5683` | CoAP |
| `10001` | Ubiquiti discovery |
| `11211` | Memcached |
| `17185` | VxWorks debug agent (wdbrpc) |
| `27015` | Source Engine query |
| `37810` | Dahua DVR |

If a service on the address needs one of these ports, [contact support](/docs/support/conversations/).

## Limits

- DDoS Shield filters IPv4 traffic. The addresses you order in the dashboard are IPv4 only.
- It reads packet headers: addresses, ports, protocols, flags and sizes. It does not look inside connections, so it cannot stop an attack made of requests that look real, such as a flood of HTTP requests to a website. A web proxy checks each HTTP request with its web application firewall and turns away clients that send too many ([How web proxies work](/docs/proxies/web-proxies/)).
- You cannot change the platform default profile, the packet checks or the list of reflection ports.