We have a multi-layered approach to DDoS mitigation that applies to all our locations and services.
- Large upstream links and always-on upstream filters
We use large upstream links wherever we can, and all of our upstreams filter most of the common reflection traffic for us -- the big stuff like DNS, NTP, and SSDP -- so that we don't even see it.
- Default, always-on filters at our own network edge
We have our own filters that are a bit more specific, which clean up any traffic from those reflection attacks which might still get through and block common attacks against specific services, such as game servers on specific UDP ports.
- Global block list
We have a carefully-curated list of IP addresses that we block based on their participation in DDoS attacks. This allows us to block traffic from many botnet-based attacks without the traffic having to go any further.
- Automatic detection and mitigation based on signatures
Our system monitors for spikes in traffic and responds by looking at traffic samples. If traffic matches a known signature, a filter is implemented directly on our core router to prevent it from reaching the target, and the customer is notified with a post to the service's Events log. This happens within seconds of an attack occurring and covers most "layer 3" through "layer 7" attacks.
- NFO-defined manual filters
When necessary, we can manually review recorded traffic samples and implement a manual filter to block an attack against a specific customer. We can also manually implement rate-limits or define other permanent filters to block repeat attacks from getting through.
- Customer-defined manual filters
Customers on VDSes, and those who run managed Linux game servers, can make external packet captures and define their own external firewall rules through a powerful Firewall page in our control panel. (Customers can also implement firewall rules inside the unmanaged OS on any machine or VDS, of course.)
- OS- and application-level filters
When necessary, we can define further filters for customers on Linux machines, including stateful filters. This can be done manually or through scripted solutions (such as on webserver machines). Most games also have mechanisms that can be used to block specific IP addresses or clients, as well.
- A stopgap measure: RTBH
When all else fails, when an attack is particularly large and causing collateral damage for other customers, our system will put in place a remote-triggered black hole to block all traffic to a customer. This is a temporary stopgap measure. We manually review all null-routes and mitigate these attacks in whatever ways we can, in order to prevent further RTBH actions from being needed.
In contrast, we do all our mitigation in-house and know precisely what we are doing. Our system is ever-evolving and widely considered the best available.