Kingsfordweg 151, 1043GR Amsterdam, The Netherlands ● 24/7 support — support@novogara.com
Knowledge base

What you can do about DDoS

We filter the large attacks upstream. The ones that get through are usually small, clever and aimed at the most expensive thing your application does.

The division of labour

Volumetric attacks — floods designed to fill the pipe — are absorbed at backbone level before they reach you. That is included on every server; see DDoS filtering.

What filtering cannot distinguish is a few thousand requests per second that look exactly like real users, aimed at your search endpoint. That is an application problem and the defences are yours.

Know what your expensive endpoints are

Every application has a handful: search, report generation, password reset, anything that writes, anything that calls a third party. An attacker finds them by trying.

Find them first, with the slow log — see PHP-FPM tuning — and then make them cheap, cached, or rate limited. One uncached search endpoint can take down a machine that would shrug off ten times the traffic on cached pages.

Rate limiting that works

In nginx:

limit_req_zone $binary_remote_addr zone=login:10m rate=5r/m;

and in the location: limit_req zone=login burst=5 nodelay;

Limit by what you are protecting: per address for login, per account for expensive operations, globally for the thing that must never be overwhelmed. Return 429 rather than timing out, so legitimate clients can back off properly.

Behind a proxy, make sure you are limiting on the real client address and that you trust X-Forwarded-For only from your own proxy — see nginx pitfalls.

Cache aggressively

A request served from cache costs almost nothing. The single most effective anti-DDoS measure for a content site is a page cache that serves anonymous traffic without waking the application at all. See caching and CDNs.

Hide the origin if you use a proxy

If you front your site with a CDN or scrubbing service, that is defeated the moment someone finds your real address — and old DNS records, mail headers and certificate transparency logs all leak it. Firewall your origin to accept HTTP only from the proxy's ranges.

Prepare before, not during

  • Know your normal traffic shape, so abnormal is obvious — see understanding your traffic
  • Have a static maintenance page you can switch to in one command
  • Keep a rate-limit configuration ready to enable, tested on staging
  • Know how to reach us at three in the morning, and have the machine identifier to hand

Tell us early

If you are under attack, open a ticket and say so. We can see the traffic from the network side, which is a view you do not have, and we can often filter a pattern upstream of your port. An engineer answers at any hour — support@novogara.com.


Still stuck? Mail support@novogara.com — an engineer answers, at any hour. Back to the knowledge base