DDoS protection for websites: what actually works

DDoS stopped being a problem only for large platforms long ago. Ordering an attack of 10,000 requests per second costs less than dinner out, and the motive is often nothing more than seasonal competition. Let us look at which measures produce a real effect and which only create the illusion of protection.

Three levels of attack, three different answers

Volumetric attacks (L3/L4) flood your channel with junk traffic: UDP floods, reflected requests through open DNS resolvers. Only external filtering helps here — your server physically will not receive legitimate packets if the channel is saturated. Protocol attacks exhaust connection resources: SYN floods, slow Slowloris requests. Application-layer attacks (L7) look like ordinary HTTP requests but target the heaviest operations: catalogue search, filters, PDF generation. L7 is the hardest to tell apart from genuine users.

What does not work

• Simply scaling up the server. The attack scales more cheaply than your infrastructure.
• Blocking IPs by hand. A botnet of tens of thousands of addresses will exhaust your patience long before it exhausts its pool.
• Country-level blocking as the only measure. Half the traffic comes from rented VPS instances inside the country.
• A captcha on every page. Conversion drops further than it would from the attack itself.

What works: filtering at the perimeter

The basic working setup is a protection service in front of the site that absorbs the traffic, strips out the junk and passes you a clean stream. The key detail people miss: once it is connected, you must close off direct access to the server's real IP, allowing inbound traffic only from the filter's subnets. Otherwise the attacker finds the origin address through DNS history or mail headers and hits you around the protection. We always check this when setting up infrastructure.

What works: sound application architecture

Resilience to L7 is built into the code. Page caching at the web server level removes 90% of the load: serving ready-made HTML is a thousand times cheaper than assembling it from the database. Rate limiting on heavy endpoints — search, login, forms — cuts off automated floods. Heavy operations move into background queues. There is a good collection of frontend performance and caching practices on web.dev, and much of it directly improves attack resilience too.

Limits worth setting today

• A rate limit on the login form: no more than 5 attempts per minute per address.
• A cap on request body size — this cuts off part of the upload-based attacks.
• Timeouts on slow headers and request bodies — a direct counter to Slowloris.
• A limit on simultaneous connections from a single IP.
• Caching of catalogue and home pages for at least 60 seconds for unauthenticated visitors.

What it costs

Basic protection bundled into a hosting or CDN plan runs from nothing to a few thousand roubles a month, and it is enough against low-budget attacks. Specialised filtering with a volume guarantee costs between 15,000 and 100,000 roubles a month depending on bandwidth and tier. Compare that with the losses: an online store turning over 3 million roubles a month loses around 100,000 roubles per day of downtime, not counting the ranking drop caused by being unreachable.

A plan for when it happens

Write down in advance: who decides to switch on enhanced mode, who has access to the filter panel at night, and where the site fails over to if filtering cannot cope. A static holding page with contact details and the sales phone number on separate hosting costs almost nothing and saves sales. If there is nobody to keep the infrastructure in shape, that is exactly what ongoing maintenance covers. You can discuss a specific configuration here.