A sudden jump to hundreds of times in the traffic reaching your server is not always good news. If your site stops responding on a Tuesday night that falls outside any campaign period, what you are facing is probably not organic demand but a DDoS attack. In this guide we go step by step through what DDoS is, how to tell the attack types apart, and which measure actually works where.
What is DDoS?
DDoS (Distributed Denial of Service) is an attempt to overwhelm a server, a network, or an application with fake traffic coming from a large number of sources, leaving it unable to serve real users. The critical word here is “distributed”: the traffic does not come from a single computer but from botnets made up of thousands of compromised devices. That is why blocking a single IP address does not solve the problem.
The first step in choosing the right defense is to separate attacks into two main groups: volumetric attacks that target bandwidth, and L7 attacks that target the application itself.
Volumetric attacks
The goal is simple: fill your line. Techniques such as UDP flood, SYN flood, and DNS and NTP amplification generate gigabits of junk traffic per second and clog your connection. It makes no difference how powerful your server is; the pipe is already full before the packets even reach the operating system.
These attacks are measured in Gbps (bandwidth) or PPS (packets per second). Stopping a volumetric attack that exceeds the capacity of your line from inside the server is physically impossible; this is the point where the line-level protection we discuss below comes into play.
Application layer (L7) attacks
L7 attacks are more insidious. Instead of filling bandwidth, they consume your application’s processor, memory, and database resources with HTTP requests that look legitimate. A few thousand requests per second, directed at a search page that triggers database queries, can bring even a powerful server to its knees.
Techniques such as Slowloris keep connections deliberately slow and occupy the web server’s connection pool. Because no large peak appears on the traffic graph, L7 attacks are harder to notice; detection most often relies on behavioral analysis.
How do you recognize the symptoms of DDoS?
The first signs are usually these: page load time suddenly rises to 10-15 seconds, the SSH connection drops or becomes very slow, the web server starts returning 502/503 errors, and the traffic graph shows an unexplained spike. None of them is proof on its own; seeing several of them at the same time is cause for alarm.
If you can still reach the server, a few commands will clarify the picture:
# Summary of connection states
ss -s
# Half-open connections in the SYN_RECV state (a sign of SYN flood)
ss -nt state syn-recv | wc -l
# IP addresses opening the most connections
ss -ntu | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -nr | head -20When you suspect L7, the web server logs are the best witness. Clusters of IP addresses that send dozens of requests per second to the same URL and carry an empty or unusual User-Agent are typical bot behavior:
# Busiest IP addresses in the last 10,000 requests (Nginx)
tail -n 10000 /var/log/nginx/access.log | awk '{print $1}' | sort | uniq -c | sort -nr | headMeasures to take on the server side
In-server measures are effective against L7 attacks and small-scale L4 attacks. Most of the settings below require root access; if you use shared hosting, this layer is your provider’s responsibility. If you want to manage the rules yourself, a VDS with root access gives you that flexibility.
Kernel and network stack settings
The first line of defense against SYN flood is the operating system itself. Add the following lines to the /etc/sysctl.conf file and apply them with sysctl -p:
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_max_syn_backlog = 4096
net.ipv4.tcp_synack_retries = 2SYN cookies prevent half-open connections from consuming memory. They are enabled by default on most modern distributions, but checking takes only seconds.
Rate limiting on the web server
Nginx’s limit_req module limits the request rate per IP address and considerably reduces the impact of an HTTP flood. Protect expensive endpoints in particular, such as search, login, and form pages:
limit_req_zone $binary_remote_addr zone=general:10m rate=10r/s;
server {
location /search {
limit_req zone=general burst=20 nodelay;
}
}Against Slowloris, lowering the client_header_timeout and client_body_timeout values (to 10 seconds, for example) makes the connection pool harder to occupy.
Automatic blocking: Fail2ban and the firewall
Fail2ban monitors the logs and automatically blocks IP addresses that exceed the threshold through iptables or nftables. The nginx-limit-req and nginx-botsearch filters that ship with it for Nginx are a good starting point.
Be measured when writing permanent rules: mobile users behind CGNAT can share the same IP address, and aggressive blocking turns real visitors away as well. Keeping block durations short and increasing them for repeat violations is a safer balance.
The role of line-level protection
Everything described so far has a limit: in-server measures can only manage the traffic that reaches the server. When a volumetric attack of tens of Gbit/s arrives at a 1 Gbit/s port, your iptables rule no longer carries any weight; the line is already full. This is why the real defense against volumetric attacks is carried out at the data center and network level.
Line-level protection means that traffic is analyzed on the network backbone before it reaches the server, that packets carrying an attack signature are filtered out, and that suspicious traffic is separated. Network capacity is the determining factor here: the wider the backbone, the greater the margin for absorbing and managing an attack. SunucuCenter’s infrastructure, installed in the Equinix data center in Istanbul, runs with a total network capacity of 80 Gbit/s; when you suspect an attack, you can reach the 24/7 support team immediately.
For projects that are exposed to attack, such as game servers, e-commerce sites, and API services, a dedicated server that fully isolates resources is a more solid foundation in terms of both performance and network management flexibility.
Which measure for which attack?
| Attack type | Layer | Effect of in-server measures | Primary solution |
|---|---|---|---|
| SYN flood | L4 | Partly managed with SYN cookies | Line-level filtering |
| UDP / amplification flood | L3-L4 | Ineffective; the line fills up before the server | Filtering on the network backbone |
| HTTP GET/POST flood | L7 | High; rate limiting + automatic blocking | Rate limiting and behavioral analysis |
| Slowloris | L7 | High; timeout settings | Web server configuration |
The table gives a clear rule: with L7 attacks, in-server measures handle the larger part of the job, while with volumetric attacks the ball is entirely on the network side. The layered approach that combines the two is the most resilient.
Frequently asked questions
Can a small website also become a DDoS target?
Yes. Botnets scan the internet automatically; what determines target selection is not the size of a site but how exposed it is. Ransom-driven attacks and sabotage by competitors can hit small e-commerce sites as well. If you use shared Linux hosting, this layer is managed by your provider; even so, do not hesitate to ask which protections are offered.
Is a CDN enough on its own for DDoS protection?
Partly. A CDN distributes static content and mitigates a portion of L7 attacks. However, if the IP address of the origin server has leaked, an attacker can bypass the CDN and go directly to the server. Think of a CDN not as a solution on its own but as one of the layers that works together with line-level protection and in-server measures.
Does restarting the server during an attack help?
No. A restart only clears the accumulated connections; as long as the attack traffic continues, the problem returns within minutes. The correct order is this: identify the attack type with the commands, put rate limiting and blocking rules into effect, and if you suspect a volumetric attack, contact your provider’s support team without losing time.
Leave a Reply