What a DDoS attack is and how to protect your server

A DDoS (Distributed Denial of Service) attack makes a service unreachable by overwhelming it with requests from many sources. "Distributed" is the key word: the traffic does not come from one address, so you cannot solve it by blocking a single IP.

Before choosing a defence you need to know which layer is being targeted, because the two are solved in completely different places.

Network-layer attacks (L3/L4)

The aim is to fill your link. If your server has 1 Gbit of connectivity, sending 10 Gbit at it saturates the pipe.

Common forms: UDP floods, SYN floods, and DNS or NTP amplification.

The critical point: these attacks cannot be solved from inside the server. By the time the traffic reaches you the link is already full; an iptables rule behind a saturated pipe achieves nothing. The fix is scrubbing the traffic at the network level before it arrives — which happens in your provider's infrastructure.

Application-layer attacks (L7)

The aim is to exhaust processing power rather than bandwidth. The requests look like ordinary HTTP traffic, but they target the endpoints that cost the server most: search pages, login forms, filtered product listings.

The traffic volume can be low and the server still buckles. Because it resembles legitimate traffic, it is hard to distinguish.

At this layer there are things you can do server-side: rate limiting, WAF rules, caching, bot verification.

Are you under attack, or just busy?

The two get confused. To tell them apart, look at:

• Where the traffic comes from: Genuine growth usually comes from known sources. In an attack the geographic spread looks arbitrary.
• Which pages are requested: Real visitors browse. An attack hammers one endpoint.
• User agents: The same user agent repeating thousands of times is a strong signal.
• Conversion rate: If traffic is up tenfold but orders are flat, what arrived is not visitors.

For a quick look on the server:

bash# IP addresses making the most requests
awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -20

# Current connection counts
ss -ant | awk '{print $6}' | cut -d: -f1 | sort | uniq -c | sort -rn | head

Layers of defence

1. Network-level scrubbing. The only real answer to volumetric attacks, and it has to come from your provider. When renting a server, ask what the DDoS protection covers and up to what volume.

2. Reverse proxy / CDN. A layer like Cloudflare hides your server's real IP and filters traffic on its own network. For that to work your real IP must not leak — old DNS records, subdomains resolving straight to the IP, and headers on email sent from the server are the most common leaks.

3. Rate limiting. Simple but effective on the Nginx side:

textlimit_req_zone $binary_remote_addr zone=general:10m rate=10r/s;

server {
    location /login {
        limit_req zone=general burst=20 nodelay;
    }
}

4. Caching. A page served from cache runs no PHP. A well-configured cache substantially reduces the impact of L7 attacks.

5. Application hardening. Limit expensive queries, add authentication or delay to search endpoints, and cap attempts on login forms.

Plan before it happens

There is no time to write a plan during an attack. Prepare now:

• Your provider's emergency contact channel and response time
• The "protection mode" you will switch on (something like Cloudflare's Under Attack Mode)
• Who decides and who executes
• How you will tell customers if access is lost
• Where logs are retained — you need them for the post-incident review

Be realistic

No protection grants "complete immunity to DDoS"; a large enough attack strains any architecture. The goal is to absorb ordinary-scale attacks unnoticed and to shorten downtime during large ones.

To work out the right protection scope for your project, see our DDoS protection page or ask our team.