Volumetric floods
L3/L4SYN and UDP floods that simply fill the pipe; the bulk of attacks (roughly three-quarters are network-layer).
Infrastructure · DDoS
Attacks absorbed at the edge — automatically, and honestly.
DDoS protection keeps a flood of malicious traffic from taking you offline. VV Internet Hosting builds it into the network: the common attacks are absorbed automatically at our edge, with on-server filtering, BGP FlowSpec, and blackhole routing, and the rare hyper-volumetric case is escalated to upstream scrubbing. We are honest about what actually hits a hosting server — usually a few gigabits, not the headline terabits — and about what no single network can absorb alone.
In short
- The records are outliers. The biggest disclosed hit ~31.4 Tbps for 35 seconds; what hits ordinary servers is mostly under 10 Gbps.
- A 3 Gbps flood saturates a 1 Gbps uplink. The everyday threat is small traffic aimed at a link that cannot carry it — and that we absorb at the edge.
- Mitigation must be automatic. Attacks are over in minutes or seconds; human reaction is too slow, so detection and filtering run in seconds.
- Layered defence. On-server filtering, then FlowSpec, then blackhole, then scrubbing — each engages only when the previous is insufficient.
- Honest about scale. No single network absorbs 30 Tbps; we escalate the extreme to scrubbing and say so plainly.
What is a DDoS attack, and what does it threaten?
A distributed denial-of-service attack points traffic from many machines at a target all at once, trying to exhaust something before real users can get through. What it exhausts varies: the raw bandwidth of your uplink, the capacity of the network gear in the path, or the application itself as it tries to answer a storm of requests. The aim is not to break in; it is simply to make you unavailable, which for anyone whose revenue or reputation depends on being online is damage enough.
It helps to hold two facts at once. The threat has grown genuinely alarming at the top end, with botnets that can briefly muster more traffic than some countries' entire internet. And yet the attack most likely to hit your server is small and ordinary. Good protection has to respect both — be ready for the rare monster without pretending the everyday flood is one, and without charging you for capacity you will never need.
There is a second target worth naming: the link itself. Even an attack too small to trouble a big network can knock over a server whose uplink is a gigabit or two, because the flood does not need to beat your CPU — it only needs to fill the road in front of it. That is why DDoS is best thought of as a capacity problem at the edge rather than a problem on the box, and why the defence belongs in the network, ahead of the server, where there is room to drop the junk.
The threat in 2026, in proportion
The top end is real and worth stating plainly. The largest attack publicly disclosed reached about 31.4 Tbps and over 200 million requests per second from the Aisuru-Kimwolf botnet in December 2025 — and it lasted roughly 35 seconds. Records jumped more than 700% in about 14 months (from ~3.8 Tbps in late 2024), and one network alone mitigated tens of millions of attacks in 2025, up over 120% year over year. Today's mega-attacks come from Turbo-Mirai-class IoT botnets like Aisuru-Kimwolf — an estimated 1–4 million infected Android TVs and home routers.
What makes this dangerous is not only size but economics. Attacks are cheap and automated: DDoS-for-hire advertises 1 Tbps+ for under $50 a day, and AI 'DDoS-as-a-service' lets non-technical users launch them with a prompt — an attacker-to-defender cost ratio measured in the thousands to one. Downtime is expensive — on the order of tens of thousands of dollars per minute for businesses that depend on being online. The industries most in the firing line are telecom / carriers, it & service providers, gaming, gambling, financial services, and generative-AI providers — but the cheapness of attacks means almost anyone can be targeted by almost anyone, for almost any reason.
It is worth keeping the frightening numbers in their box, though. A record built from millions of hijacked televisions making one telecom's life miserable for thirty-five seconds is real, but it is not the weather your server lives in day to day. The useful takeaway from the 2026 picture is not panic; it is that attacks are now cheap, fast, and automated enough that protection has to be standing and automatic, because the next one could arrive at any hour without warning or motive.
But what actually hits a server like yours?
Something far smaller, almost always. The headline numbers are outliers. The attacks that actually hit hosting servers, game servers, and small operators are mostly small: a large majority land under 10 Gbps. That sounds modest until you realise a 3 Gbps flood completely saturates a 1 Gbps uplink — so the everyday threat is not the 31 Tbps monster, it is the 3 Gbps flood aimed at a link that cannot carry it.
This is the single most useful thing to understand about DDoS, because it changes what good protection looks like. You do not, for most workloads, need a contract with a planet-scale scrubbing cloud sized for 30 terabits. You need an edge that quietly absorbs the gigabit-scale floods that make up the overwhelming majority of real attacks, automatically, before they ever reach your uplink — and a clear, honest plan for the rare day something larger arrives. That is exactly how we have built it.
Sizing protection to the long tail rather than the headline also keeps the economics honest. Provisioning every customer as though a thirty-terabit flood were imminent would cost a fortune and protect almost no one better, because almost no one faces that. Matching the edge to the gigabit-scale reality, and keeping a real escalation path for the exception, is both cheaper and more honest than selling fear — and it means the protection you pay for is the protection you actually use.
Why does mitigation have to be automatic?
Because there is no longer time for a human to be in the loop. Attacks have also become short and sharp. The median lasts only minutes, a large share are under five minutes, and the record-setting flood was over in 35 seconds. That closes the window for anyone to notice and react by hand — mitigation has to be automatic and measured in seconds, not minutes.
A few years ago an on-call engineer could watch a graph climb, recognise an attack, and trigger a response while it was still building. Against a flood that peaks and ends inside a minute, that workflow loses every time — by the time anyone has acknowledged the alert, the damage is done and the attacker has moved on. So the detection and the first layers of filtering run by themselves, in seconds, and people step in for judgement and tuning rather than for the reflex. Automation is not a luxury here; it is the only thing fast enough.
There is a subtler reason too. Because attacks are short, attackers often fire a brief burst to probe defences, watch how a target reacts, and then return with something tuned to what they learned. Automatic mitigation that responds identically and instantly every time gives them nothing to learn from, whereas a slow, improvised response is itself a signal. Consistency at machine speed is part of the defence, not just a convenience.
The vectors
What we defend against
Attacks are not one thing, and the defence differs by type. These are the shapes that show up, reviewed 2026-06.
Reflection / amplification
L3/L4Abusing CLDAP, NTP, DNS, SNMP, or Memcached to multiply a small request into a large response aimed at you.
Application-layer (L7)
L7HTTP floods and tricks like HTTP/2 Rapid Reset that look like real requests; the hardest to tell from legitimate traffic, and rising fast.
Carpet bombing
L3/L4Spreading low-volume floods across a whole /24 or /16 so each address stays under detection thresholds while the aggregate saturates peering.
Packet-rate (PPS) floods
L3/L4High packet-per-second floods, often from compromised routers, that exhaust forwarding capacity even at modest bandwidth.
How do you tell attack traffic from legitimate users?
This is the hard part of mitigation, and where it earns its keep. The blunt instrument is to drop everything to a targeted address, which stops the attack and also stops your real users — useful only as a last resort. Everything better is about separating the flood from the genuine traffic mixed into it, using packet characteristics, behaviour, and rate. Volumetric and amplification floods often carry tell-tale signatures — odd packet sizes, spoofed sources, protocols you do not use — that a surgical rule can match and drop while real connections pass untouched.
Application-layer attacks are harder, because each request looks plausible on its own. There the tools are rate limits, connection accounting, behavioural baselines, and bot detection that notice when a thousand "users" behave identically. The risk to manage is false positives — blocking real customers while chasing an attacker — so the goal is always the most specific rule that works, verified against legitimate traffic still flowing, rather than the biggest hammer available. Getting that balance right is the difference between mitigation and a self-inflicted outage.
We lean on the surgical end of that spectrum — FlowSpec rules matched to the attack — precisely so that stopping a flood does not mean taking yourself offline to do it. The blunt tools stay in the kit for genuine emergencies, not as the everyday answer.
The defence
How we mitigate, layer by layer
Cheapest and fastest first, escalating only as far as each attack requires — so the common case is handled instantly and the rare case is handled honestly.
1
On-server filtering — iptables/nftables, SYN cookies, connection and rate limits
Absorbs smaller floods at the host instantly, with no rerouting.
2
Edge ACLs & BGP FlowSpec — surgical rules pushed to edge routers
Match by protocol, port, packet size, or source and drop or rate-limit attack traffic before it reaches the server, keeping good traffic flowing (RFC 5575).
3
Remote-triggered blackhole (RTBH) — null-route a targeted IP at the edge
Last resort: it drops all traffic to the attacked address to protect everything else — the target is sacrificed to save the network.
4
Upstream / cloud scrubbing — divert to anycast scrubbing capacity
For volumetric attacks beyond local capacity, traffic is diverted (BGP or GRE) to scrubbing centres that filter and return clean traffic.
Scrubbing runs always-on (all traffic flows through it — simple but adds cost and latency) or on-demand (diverted only during an attack — cheaper, but with a 'mitigation gap' until diversion engages). Sub-second automatic detection that triggers diversion by API closes that gap.
edge1# exabgp — announce mitigation (excerpt)
flow {
route drop-udp-amp {
match {
source 0.0.0.0/0;
destination 203.0.113.10/32;
protocol udp;
packet-length >900;
}
then { discard; } # surgical: drop the flood, keep good traffic
}
}
# last resort — blackhole a single target IP at the upstream
neighbor 198.51.100.2 {
announce route 203.0.113.10/32 community [65000:666];
}
# 65000:666 = RTBH: drop everything to that IP, save the restUnder attack
What happens when an attack hits
The sequence runs mostly without us touching it — which is the point.
- 1
Detect in under a second
Per-server and edge telemetry watch packet and request rates continuously; an anomaly is flagged in roughly a second, not after a human notices.
- 2
Classify the attack
The system identifies the vector — volumetric, amplification, L7, or packet-rate — so the response matches the attack instead of guessing.
- 3
Filter at the host or edge
Smaller floods are absorbed on the server; larger ones get surgical FlowSpec rules at the edge that drop the attack while legitimate traffic keeps flowing.
- 4
Escalate only if needed
If volume exceeds what the edge can carry, traffic is diverted to upstream and scrubbing capacity automatically — each layer engages only when the previous one is insufficient.
- 5
Keep you informed
You see what is happening and what we are doing, rather than learning about it by opening a ticket.
- 6
Review afterwards
Each incident is analysed to tune rules and baselines so the next one is handled faster.
What about the truly massive attacks?
This is where most marketing gets dishonest, so we will be blunt. No single server, and no single data centre, can absorb a multi-terabit flood on its own — the physics do not allow it. We absorb the common attacks at our edge automatically, and for the rare hyper-volumetric case we escalate to upstream and specialist scrubbing capacity rather than pretending a single network swallows 30 Tbps. We are honest about scale: we are not a planet-spanning scrubbing cloud, and when your risk profile genuinely needs one, we will say so.
In practice that means a layered relationship with scale. Our edge handles the gigabit-class floods that are the daily reality, the moment they start. When something genuinely hyper-volumetric appears, the path is to divert to upstream and specialist scrubbing capacity sized for it — and for a web property facing heavy application-layer attacks, an anycast WAF or CDN in front of the origin is the right tool. Anycast spreads an attack across many sites instead of letting it land on one, and hides origins behind the edge; it is core to resilient DNS and large-scale absorption. Anycast proxying via a CDN protects web (HTTP/HTTPS) traffic, while game, VoIP, and raw-IP services need BGP-level protection. We would rather build you the correct layered answer than sell a single box and call it invincible.
None of this means you are exposed in the gap between our edge and a scrubbing cloud. The escalation path is arranged in advance, not improvised mid-incident, so a flood that outgrows the edge is handed upward automatically rather than after a frantic round of phone calls. What we refuse to do is paper over the boundary with a slogan; you deserve to know exactly which attacks we stop ourselves and which we stop by escalating, so the plan holds on the day it is tested.
DDoS, clean IPs, and your email
Attack resilience and deliverability are quietly connected. A network that absorbs attacks cleanly, handles abuse quickly, and keeps compromised or hostile traffic off its address space protects the reputation of that space — and reputation is exactly what decides whether your mail reaches the inbox. A provider that lets attacks and abuse fester ends up with blocklisted IPs, which hurts every customer who sends from them.
So the same discipline that keeps you online during a flood also keeps your addresses trusted: monitoring, fast remediation, and refusing to let one bad actor degrade everyone else's space. It is the reason DDoS protection, clean addressing, and deliverability all live on the same well-run network rather than being bolted together from parts. See the network →
It also shapes who we are willing to host. A provider that takes anyone who pays, including the spammers and abusers that attract attacks and blocklistings, is quietly degrading the network for every legitimate customer on it. Being selective about acceptable use is not prudishness; it is how the shared asset — the reputation of the address space and the headroom of the links — stays good for the people who use it properly.
Do you need a separate DDoS service or a CDN?
For most workloads, no — the protection in the network covers the attacks you will actually face, and adding a second layer would be cost without benefit. The honest exceptions are specific. If you run a public web property that draws heavy, sophisticated application-layer attacks, an anycast WAF or CDN in front of your origin is built for exactly that and worth adding. If your risk profile is genuinely extreme — a frequent target of hyper-volumetric campaigns — a dedicated scrubbing provider sized for terabits is the right call.
What ties those together is matching the tool to the threat instead of buying every layer by default. We will tell you which camp you are in, help you wire in a CDN or scrubbing relationship when it is warranted, and otherwise leave you with the protection that comes with the server — and the money you would have spent insuring against an attack you were never going to see.
What we run, and what we will not claim
Every server sits behind always-on edge absorption that handles the common attacks automatically, with on-server filtering, BGP FlowSpec, and blackhole routing available, sub-second detection, and visibility so you can see what is happening rather than guess. It comes with the machine, in the regions we operate, because protection that is an afterthought is protection that arrives late.
What we will not claim is to be a planet-spanning scrubbing cloud that swallows any attack ever conceived. No one honest can. For the rare hyper-volumetric case we escalate to upstream and specialist capacity, and when your risk profile genuinely needs a dedicated scrubbing provider or a CDN in front of your origin, we will tell you and help you wire it in. The goal is for you to stay online through the attacks you will actually face, measured against your real exposure — not to win a brochure contest about terabits.
And as with everything else we run, the honest scoping is the feature. You will know what is included with the server, what an escalation to scrubbing would involve, and where the line sits, before you ever face an attack — so the protection is something you can plan around rather than a promise you only get to test in an emergency. Predictability under pressure is the whole point.
Questions
DDoS, answered plainly
The questions teams ask before they trust a network with uptime.
What is a DDoS attack?
A distributed denial-of-service attack floods a target with traffic from many sources at once, trying to exhaust its bandwidth, its network equipment, or the application itself until real users cannot get through. It comes in three broad shapes: volumetric floods that fill the pipe, protocol attacks that exhaust network resources, and application-layer attacks that look like real requests. The goal is always the same — make you unavailable.
How big are attacks now?
The largest disclosed reached about 31.4 terabits per second in December 2025 and lasted only 35 seconds, driven by an IoT botnet of millions of devices. Records have grown more than 700% in little over a year. But those are outliers: the attacks that actually hit ordinary servers are mostly small, and that is the threat we are built around for most customers.
What size of attack actually hits a server like mine?
Usually a modest one. A large majority of attacks land under 10 Gbps, which sounds small until you note that a 3 Gbps flood completely saturates a 1 Gbps uplink. The everyday danger is not the record-breaking monster; it is a few gigabits aimed at a link that cannot carry it, and that is exactly what our edge absorbs automatically.
Why does mitigation have to be automatic?
Because attacks are now short and sharp. The median lasts only minutes, many are over in under five, and the record flood ended in 35 seconds. That is far too fast for someone to notice and react by hand, so detection and filtering have to be automatic and measured in seconds. Human-in-the-loop mitigation arrives after the damage is done.
Can you stop a 31 Tbps attack?
Honestly, no single server or data centre can absorb a multi-terabit flood alone — the physics do not allow it. We absorb the common attacks at our edge automatically, and for the rare hyper-volumetric case we escalate to upstream and specialist scrubbing capacity. We will not pretend one network swallows 30 Tbps, and if your risk genuinely needs a planet-scale scrubbing cloud, we will tell you.
Is protection always-on or only during an attack?
Our common-case absorption is always-on at the edge, so there is no gap waiting for someone to flip a switch. For very large diversions to scrubbing, automatic sub-second detection triggers the reroute, which avoids the lag that on-demand-only setups suffer at the start of an attack. The aim is that ordinary floods never reach you and large ones are escalated before they bite.
What about layer-7 (application) attacks?
Application-layer floods that mimic real requests are the hardest to separate from legitimate traffic, and they are rising. They need request-rate limits, behavioural analysis, and bot detection rather than raw bandwidth filtering. We handle the common cases; for heavy, sophisticated L7 against a web property, an anycast WAF or CDN in front of the origin is often the right addition, and we will help you set that up.
Does DDoS protection cost extra?
Edge absorption of the common attacks is part of the network, not an upsell — it comes with the server. Large-scale scrubbing for the rare hyper-volumetric event involves real upstream cost, so that is scoped to your risk rather than bundled as a vague promise. We would rather price what we can actually deliver than advertise infinite protection nobody can provide.
Tell us what staying online is worth.
What you run, who might target it, and what an hour of downtime costs — and we will size protection to your real exposure, not to a headline.