DDoS protection for a dedicated server: L3, L4, L7

DDoS protection works on three levels. L3 and L4 filter packet garbage — UDP floods, reflected replies, SYN floods — and that happens inside the provider network, upstream of your port. L7 inspects HTTP requests that are already established and rejects clients that only imitate a browser. The first two levels save the uplink, the third saves the application, and neither substitutes for the other.

The German and US sites run L3/L4 filtering; plans from Pro upward add L7.
The French site uses Anti-DDoS Arbor, which absorbs volumetric attacks at the network level.
A server cannot defend itself against a volumetric attack: once the uplink is saturated, your rules no longer matter.

How the levels differ

Level	Typical attacks	Where it is filtered	What breaks without protection
L3 (network)	ICMP flood, IP fragments, reflection through open services	Provider network, upstream of the server port	Uplink saturated, the whole server unreachable
L4 (transport)	SYN flood, ACK flood, UDP flood, amplification	Provider network plus the server kernel	Connection table overflows, new sessions refused
L7 (application)	HTTP flood, slow requests, hammering heavy pages	Reverse proxy, WAF, the application itself	CPU and database pegged on modest traffic

The numbers differ by orders of magnitude: a volumetric L3/L4 attack is measured in gigabits and millions of packets per second, while an L7 attack needs only 3,000-5,000 requests per second to take down a dynamic site. How port speed relates to real load is covered in the article on server uplinks and traffic caps.

What is included at each ZevsHost site

Location	Base protection	L7
Germany (Dusseldorf)	L3/L4	On Dedicated Pro DE and above
USA	L3/L4	On Dedicated Pro US and Enterprise US
France (Strasbourg)	Anti-DDoS Arbor	Filtering at the network level

The L3/L4 baseline is present on every plan, including Dedicated Start DE at $49 and Dedicated Start US at $59. Full configurations per plan are on the dedicated servers page.

Telling an attack from a traffic spike

A genuine spike raises request volume while address, referrer and response-code distributions stay normal. An attack almost always shows a skew: one URL, one User-Agent, identical request sizes, or thousands of half-open connections.

# connection states: a pile of SYN-RECV means a SYN flood
ss -ant | awk '{print $1}' | sort | uniq -c | sort -rn

# top 20 addresses by connection count
ss -ant | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -rn | head -20

# packets and bytes per second on the interface
sar -n DEV 1 5
ip -s link show eth0

The full toolkit for digging into network problems is described in the article on network diagnostics in Linux.

What to configure on your side

Kernel: surviving a SYN flood

cat << 'EOF' > /etc/sysctl.d/90-antiddos.conf
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_max_syn_backlog = 8192
net.ipv4.tcp_synack_retries = 2
net.core.somaxconn = 8192
net.netfilter.nf_conntrack_max = 524288
EOF

sysctl --system
sysctl net.ipv4.tcp_syncookies net.core.somaxconn

Packet-level limits

# nftables: cap the rate of new SYNs and connections per source
nft add table inet ddos
nft add chain inet ddos input '{ type filter hook input priority -10 ; policy accept ; }'
nft add rule inet ddos input tcp flags syn limit rate over 2000/second drop
nft add rule inet ddos input tcp dport 443 ct state new meter conns '{ ip saddr limit rate over 50/second }' drop

Application: nginx limits

# in the http section
limit_req_zone $binary_remote_addr zone=perip:20m rate=10r/s;
limit_conn_zone $binary_remote_addr zone=connperip:20m;

# in the server section
limit_req zone=perip burst=30 nodelay;
limit_conn connperip 20;
limit_req_status 429;

# validate the config and reload without dropping connections
nginx -t && systemctl reload nginx

Do not block an attack by country or by large subnets on a live server. A single /16 often belongs to a mobile carrier or a cloud provider that also carries your ordinary customers, payment webhooks and monitoring checks. Blocking such a block looks like "the attack stopped", while in reality you cut off part of your revenue and will not see it in the logs, because those requests never reach the web server. The correct order: rate limits first (limit_req, limit rate), then targeted bans on specific addresses, and only then broad blocks, time-boxed and written down in the calendar. To confirm you did not cut off real users: the share of 429 and 403 responses in the log stays within a few percent, and a curl from an external vantage point in each target country returns 200.

When you need an external layer

If the attack comes over HTTP and your own limits already hurt real users, move the load onto an external filter: it absorbs the traffic and only vetted requests reach the server. Setting that up is covered in the article on DDoS protection with Cloudflare.

The origin must then stay hidden: if the real IP is known, the attack simply bypasses the filter. Close ports 80 and 443 to every source except the filter networks, and do not leave the old address in subdomain DNS records, in mail headers, or in SSL certificates issued for the bare IP.

Key takeaways

L3/L4 protects the uplink and is filtered in the provider network; L7 protects the application and is configured by you.
Germany and the USA run L3/L4 with L7 added from Pro upward; France uses Anti-DDoS Arbor.
Enable tcp_syncookies, nftables rate limits and nginx limit_req before an incident, not during one.
Blocking large subnets is a last resort: it silently cuts off genuine customers.