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 shows how to change the settings.

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).

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). 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).

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, TCP proxy protection).

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). An event is a record of what we dropped, and it does not change how we filter.

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).

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).

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

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.

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)
   • 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).
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).

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.

Each address has four rate limits:

In Custom, the profile's limits apply, and you can change them (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.

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).

If a service on the address needs one of these ports, contact support.

• 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).
• You cannot change the platform default profile, the packet checks or the list of reflection ports.