Inside our in-house Anti-DDoS: how an attack gets absorbed

A DDoS attack does not knock on the door. It shows up as a wall of traffic, often tens of gigabits per second, aimed at a single IP address. Our job is to make sure that wall never reaches your server. This post explains how we do it, without the marketing gloss.

Why we built it ourselves

Most hosting providers rent mitigation from a third party and route traffic through it only when an attack is detected. That works, but it adds latency, adds a vendor to the incident path and usually comes with a per-attack cap.

We chose to run mitigation in-house, at the edge of our own network, in every location. It is always on, it is included in every plan and our engineers can tune it the moment an attack pattern changes.

The three stages of a mitigation

1. Detection

Flow data from our edge routers is analysed continuously. Each protected prefix has a baseline built from its normal traffic: packets per second, protocol mix, source distribution. When traffic for an address deviates sharply from that baseline, an alert fires within a few seconds.

2. Diversion

Once an attack is confirmed, the affected prefix is announced to our scrubbing layer via BGP. Clean and dirty traffic now take the same path through the filters, while everything else on the network keeps flowing normally.

3. Scrubbing

The filters drop what is clearly malicious (amplification floods, malformed packets, spoofed sources) and rate limit what is suspicious. Legitimate packets are forwarded to your server unchanged.

What you see during an attack

In most cases, nothing. Your service stays reachable and your players or visitors do not notice. You will receive a notification in the client area with the start time, the peak volume and the attack vector, so you have a record for your own logs.

The best mitigation is the one your users never hear about.

What we cannot filter for you

Network-level protection stops floods, not application bugs. A login endpoint that can be hammered with expensive requests, or a WordPress install with an unpatched plugin, needs protection inside the application too. For web workloads we recommend:

• rate limiting at the reverse proxy (limit_req on nginx, for example);
• caching anything that can be cached;
• keeping software up to date, always.

Questions?

If you run something unusual, like a custom UDP protocol or a niche game, open a ticket. Our network team can add a dedicated filter profile so your traffic is recognised as legitimate from day one.