Turkey (Türkçe) 
Your website will not load, SSH commands respond slowly and customers write that they cannot reach the server. The first suspicion is often a DDoS attack. Yet the same symptoms can come from a broken script, a full disk, a genuine traffic surge caused by a campaign, or a wrong firewall rule. This guide answers how to tell if you are under a DDoS attack in concrete terms: which symptoms to look for, which commands to run on a Linux server, how to rule out false alarms, and what to do in the first half hour if the attack is real.
This article is general technical information. Every attack is different; in a critical incident it is safest to work together with your hosting provider's network team.
A distributed denial of service attack uses artificial traffic from many sources to leave a server, an application or a network link unable to respond. The goal is not to steal data but to make the service unreachable. Attacks fall into three main groups:
| Type | What it does | Typical symptom |
|---|---|---|
| Volumetric | Fills the bandwidth (UDP floods, reflection attacks) | The server is alive but nothing can be reached from outside; port saturation |
| Protocol (connection table) | Exhausts the connection setup mechanism (SYN flood) | Many half-open connections, new connections timing out |
| Application layer | Sends heavy requests to the web application (HTTP flood) | CPU and database maxed out while network traffic stays moderate |
This distinction matters because the diagnosis and the fix depend on the type. You cannot fix a volumetric attack on the server; an application layer attack, on the other hand, can be softened largely on the server and in your web server settings.
A single symptom is not proof. Seeing two or three together raises the suspicion considerably.
Build your next project on a solid server
Explore VDS plans in Istanbul with KVM virtualization and a 1 Gbps port.
Explore VDS rental plansMany suspected attacks turn out to be something else. Before you react, run these five checks:
For a broader approach to finding out why a server slowed down, see the 10-minute server performance diagnosis guide.
uptime
top -o %CPU
free -h
df -hIf the load average is far above the number of cores and web server or database processes are eating the CPU, an application layer problem is likely. If resources are calm but nobody can connect, the problem is on the network line.
ss -s
ss -tn state established | awk '{print $4}' | cut -d: -f1 | sort | uniq -c | sort -nr | head -20The first command gives a summary of total connections. The second counts established connections per source IP. Hundreds of connections from one address are suspicious; thousands of different addresses can point to a distributed attack. The column number in this command can vary with the version and output format, so check the output by eye once.
ss -n state syn-recv | wc -l
ss -n state time-wait | wc -lA large number of connections in the SYN-RECV state is the classic fingerprint of a SYN flood. On a normal server this number is usually very low.
cat /proc/net/dev
sudo apt install -y iftop nload
sudo iftop -i eth0 -nNPYour interface may not be called eth0; confirm with ip -br link. If inbound traffic is close to the port speed while server resources are comfortable, the attack is starting on the line before it ever reaches the server. In that case the only thing you can do is inform your provider.
sudo tcpdump -i eth0 -nn -c 2000 -w /root/incident.pcap
sudo tcpdump -nn -r /root/incident.pcap | awk '{print $3}' | cut -d. -f1-4 | sort | uniq -c | sort -nr | headThe first command records a short capture of 2,000 packets; keeping the capture limited ensures you do not fill the disk. Seeing which port and which protocol (TCP SYN, UDP, ICMP) the attack traffic targets is the most valuable information you can give your provider.
tail -n 20000 /var/log/nginx/access.log | awk '{print $1}' | sort | uniq -c | sort -nr | head -20
tail -n 20000 /var/log/nginx/access.log | awk '{print $7}' | sort | uniq -c | sort -nr | head -20The first lists the IPs making the most requests, the second the most requested paths. If you use Apache the log path may be /var/log/apache2/access.log or different depending on the distribution. Thousands of requests piling onto one path are the clearest evidence of an application layer attack.
| Observation | Likely situation | Suggested first step |
|---|---|---|
| Inbound traffic at port speed, server idle | Volumetric attack | Tell your provider immediately; nothing to fix on the server |
| Very high SYN-RECV count | SYN flood | Check SYN cookies, set a connection limit in the firewall, notify the provider |
| Web server and database at the CPU ceiling, traffic moderate | HTTP flood or slow request attack | Request limiting, caching, a rule for the targeted path |
| High traffic, varied pages, real sessions | Probably a legitimate visitor surge | Add caching and resources; do not block on an attack assumption |
| Many requests from a single IP | A simple bot or malicious crawler | Block that IP and keep the log |
The examples below slow down small and medium HTTP attacks; they have no effect against a volumetric attack.
# Nginx: per-IP request limit (http block)
limit_req_zone $binary_remote_addr zone=general:10m rate=10r/s;
limit_conn_zone $binary_remote_addr zone=perip:10m;
# server or location block
limit_req zone=general burst=20 nodelay;
limit_conn perip 30;# Linux: see the SYN cookies state
sysctl net.ipv4.tcp_syncookies
# Temporarily block a single IP
sudo ufw deny from 203.0.113.50The address here is a documentation example. Tune the limits to your own real traffic; a limit that is too tight blocks legitimate visitors as well. For firewall and access settings, the Linux server security guide is a useful starting point.
Need more headroom than a VDS?
Look at dedicated servers in Istanbul with browser-based remote console access.
Explore dedicated serversIf a server's port is 1 Gbps, an attack that sends more data than that port can carry fills the line. At that point the packets cannot reach the server even if its processor is completely idle, because the congestion happens before the server. That is why setting up a firewall, writing an iptables rule or rebooting the server does nothing against volumetric attacks. Filtering this kind of traffic has to happen at the network level, before the traffic reaches the server. Our general guide to protecting against DDoS attacks and our article on DDoS protection for game servers cover this angle in more depth.
Sometimes the problem is not an attack but latency or packet loss somewhere along the route. Reading ping and MTR results correctly tells you whether the problem is on your server or in the middle of the path. For details, read the ping test and MTR guide.
The way to recognise a DDoS attack is to turn the symptoms into numbers: connection count, source distribution, packet type, CPU load and network saturation. If your resources are comfortable but the line is full, a volumetric attack is likely; if the CPU is full while the network is moderate, an application layer attack is likely. In every case keep records, do not shut down, give your provider accurate information and check for signs of unauthorised access.
How do I tell a DDoS attack from a legitimate traffic spike?
Real visitors spread across different pages, browser identities and sensible session behaviour. In an attack you usually see requests hammering the same path, with similar headers, no sessions and a very large number of source addresses.
Does a DDoS attack damage the server or steal data?
The goal of a DDoS attack is to make a service unavailable, not to steal data. Attacks are sometimes used as a distraction, though, so it is good practice to also check login records and unexpected changes while one is under way.
Can I protect the server against DDoS myself?
Request limiting and firewall rules at the application layer soften small attacks. Volumetric attacks that fill your bandwidth must be filtered at the network level before they reach the server, which cannot be solved on the server alone.
Is shutting the server down the right move during an attack?
Usually not. It serves the attacker's goal and erases the evidence you need for diagnosis. First work out the traffic type, stop unnecessary services and contact your provider.
Which logs should I keep?
Keep access and error logs, firewall counters, a short packet capture and the time window of the incident. They are needed both for the details you pass to your provider and for later analysis.
What should I check first when my server slows down?
Start with resource usage (CPU, memory, disk, connection count), then move on to the direction and type of network traffic. Misconfiguration, a broken script and backup jobs are also common causes of slowness.
