Michael Calce, known online as Mafiaboy, brought down the biggest sites on the web in a matter of days. On 7 February 2000 he launched a project he called Rivolta and pointed it at Yahoo, at the time the most visited site on the web. Yahoo was down for about an hour. Over the following days he added eBay, CNN, Dell, E*TRADE and Amazon. The interesting part is not that he was fifteen, although the case ended up being run by the FBI and commented on by the US president, and in September 2001 he was sentenced to eight months in open custody. The interesting part is how he did it. The traffic never came from his computer in Montreal. It came from roughly two hundred university networks he had taken control of, which meant there was no single source to block.
Most discussions about the resilience of digital services start with performance. How many cores, how much memory, what kind of disks, how much throughput. That is understandable, because performance is easy to measure and easy to buy. The problem is that when something actually happens, the result looks like this:
ping example.com -t
Pinging example.com [203.0.113.10] with 32 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Ping statistics for 203.0.113.10:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss)Four lines that look exactly the same whether the cause is a burnt-out power supply, a configuration mistake, or a coordinated attack from thousands of devices around the world. Your customers do not tell them apart. Your partners do not tell them apart. And the regulator does not ask about the cause first, it asks how long the service was down and when you reported the incident.
This is the difference between the technical and the managerial view of availability. Technically these are different problems with different solutions. From a business point of view they are a single line item: the service was down, the revenue did not arrive, trust took a hit and somebody will have to explain why.
Server performance does not fix the network capacity in front of it
You can run infrastructure capable of billions of operations per second. You can have redundant power, redundant connectivity and a second site. And none of it will protect you when you are facing a distributed attack launched from dozens of locations at once, with thousands of requests per second from each of them.
The reason is mundane, which is exactly why it gets overlooked so often. The attack is not aimed at your processor, it is aimed at the path leading to it. Once the link is saturated, the edge router is overwhelmed or the connection table on the firewall is exhausted, it makes no difference what is happening behind them. Your server can be sitting there with nothing to do and the service will still be unavailable. Investing in performance does not solve this problem, it only moves it a little further along and makes it more expensive.
Resilience is therefore not built in one place. It is built in three layers that follow on from each other, each solving something the previous one cannot: where the traffic flows, what gets dropped from it, and how you prove the whole thing works.
Layer one: where your traffic actually goes
Before you start dealing with filtering, it pays to deal with topology. If all traffic heads to a single place, the attacker only needs to saturate that single place. From their point of view that is cheap, easy to plan, and these days a rented botnet will do it for a few hundred dollars. Your entire defence then rests on whether one uplink can absorb whatever the whole world decides to send it.
This is where DNS comes in, which is, ironically, the part of the infrastructure most companies consider settled and have not looked at in years. Yet DNS is what decides where the client goes before it opens a single connection.
WEDOS.ZONE is an authoritative DNS with dozens of nodes distributed around the world. As a result, a global attack coming from dozens of locations never converges on a single point. It spreads across the nearest nodes of our network, meaning wherever each attacking segment has the shortest path, and that is where we catch it and filter it out. The attack capacity dissolves into the network before it ever touches your infrastructure, and your uplink need not even be aware that anything happened.
There is a side effect that tends to please the finance director more than the technical one: you are not paying for surplus capacity you use a few times a year.
Layer two: where volumetric protection ends
Volumetric attacks at layers three and four can be filtered out by plenty of providers today. It is a well-mapped discipline and the marketing numbers look good in it, because terabits per second sound impressive. The real problem starts a little higher up, at application layer L7. That is to say, exactly where your logins, your payments, your APIs and your data live.
An attack at the application layer does not look like an attack. It looks like a customer. It completes a proper TLS handshake, sends headers that pass every check, and requests pages a legitimate visitor might well request. It just requests far more of them, and it picks precisely the ones that are most expensive to process: search, catalogue filtering, report generation, anything that reaches into the database. A hundred thousand such requests per second carry less volume than one decent UDP flood and do considerably more damage.
Filtering this layer is significantly harder, and not only in technological terms. It requires continuous tuning based on how a particular application and a particular customer base behave, because the line between an impatient user and an attacker is thin and a badly set rule will cost you legitimate orders. This is not something you configure once at deployment.
WEDOS.PROTECTION covers the full spectrum from volumetric attacks up to the application layer, and it is operated and tuned by our team, not by a template from the documentation.
If your provider mostly talks about gigabits of filtered traffic, they are talking about layers L3 and L4. Ask them what happens to the requests that get through and look just like your customers.
Layer three: what you cannot evidence, you did not do
Resilience you cannot evidence will not hold up in an audit or in front of the board. The sentence “we have protection in place” is not a measurable parameter and it will not stand up in an annual report or in a response to a regulator. Availability in percent, outage length in minutes and time from detection to response will.
Monitoring is therefore not a technical add-on but a management instrument. Without it you do not know whether your protection worked or whether nobody happened to attack you that day. You do not know whether the outage hit all your customers or just one region. And above all you have nothing in hand to prove any of it once the incident is over.
WEDOS.ONLINE covers everything from watching individual services to a full monitoring centre with your own status page for customers and partners. That status page tends to be underrated, yet it is exactly what decides whether you spend an hour of an outage answering phone calls, or whether customers read for themselves what is going on and when it will be resolved. Availability stops being an impression and becomes a number you can put into a contract and into a report.
One vendor, one jurisdiction, one line of accountability
These three layers can of course be assembled from three different vendors. It works fine as long as nothing is happening. During an incident, though, you discover that DNS is pointing somewhere other than the mitigation assumes, that monitoring is reporting an outage one of the vendors cannot see, and that finding out whose fault it is takes longer than fixing it. Integration in crisis mode is the most expensive thing you can buy.
The second issue is jurisdiction. The question of where your data physically sits and which law your provider answers to has stopped being academic. For essential and important entities under NIS2, accountability for the supply chain has moved to company management, and that chain reaches all the way to the firm filtering your traffic.
What we can evidence on our side:
- WEDOS is listed in the register of qualified DDoS protection providers maintained by the German federal office BSI under § 3 of the BSIG act.
- Operations and data processing take place within the EU and the company has no parent entity outside the European Union.
- Our services support continuity and incident reporting requirements under NIS2 and the CRA.
Where to start
You do not need to rebuild your entire infrastructure. It is more useful to start with a question every operator can answer: how many points along the path to your service have to fail before it stops working? If the answer is “one”, you know where your priority lies, no matter how much performance sits behind it.