Is Your Linux Server Under a DDoS Attack? Five Commands That Tell You, Tested in Our Lab

To tell whether a Linux server is under a DDoS attack, compare five numbers with what is normal for it: packets per second on the network card (sar -n DEV 1), half-open TCP connections (ss -Htan state syn-recv), SYN cookies and listen-queue drops (nstat), the connection-tracking table (conntrack -C) and a short packet sample (tcpdump -nn -c 100). A flood shows up as a sudden jump in packets per second from many sources, usually aimed at one port. If the attack is bigger than your uplink, nothing on the server can stop it, and the fix has to happen upstream.

Key facts before the commands:

• Most attacks are short and small: in the first half of 2026, 90.6% of network-layer attacks ended in under 10 minutes and 96.6% stayed under 500 Mbit/s, according to Cloudflare's H1 2026 report.
• Small is still enough: 500 Mbit/s fills half of a 1 Gbit/s server port on its own.
• The largest attacks are far beyond any single server: Cloudflare recorded 31.4 Tbit/s in its 2025 Q4 report and 935 attacks above 1 Tbit/s in H1 2026.
• We ran a SYN flood and a UDP flood against a test server in our own lab, and the numbers below are what these commands showed.

Is it an attack or just a busy day?

A traffic spike from real visitors and a flood can both make a server slow. Three signs point to an attack:

• Packets out of proportion to bandwidth. Real users download pages and files, so bytes per packet are high. Floods send millions of tiny packets.
• Many sources, one target. Thousands of addresses hitting one port, often with no matching outgoing requests from you.
• Traffic you never asked for. UDP packets arriving from source port 53, 123, 389 or 11211 are replies from DNS, NTP, CLDAP or memcached servers that someone else queried in your name. That is a reflection attack.

The commands below make each sign visible. Install them once, before you need them:

# as root on Debian or Ubuntu
apt update
apt install -y sysstat tcpdump conntrack iftop nload

Command 1: packets per second on the network card

# as root
sar -n DEV 1 5

This prints five one-second samples per interface. Watch rxpck/s (packets received per second) and rxkB/s (kilobytes received per second) on your main interface. A quiet web server sees hundreds or a few thousand packets per second.

In our lab, a UDP flood pushed the victim's interface to 122,347 packets per second and 66,191 kB/s, roughly 530 Mbit/s of junk aimed at port 53. During the SYN flood, the same counter showed 36,075 packets per second but only 1.9 MB/s. That gap is the signature of a SYN flood: huge packet rates, little bandwidth. For a live graph instead of samples, nload eth0 or iftop -n -i eth0 show the same thing on screen (replace eth0 with your interface name from ip -br link).

Command 2: half-open connections

# as root
ss -s
ss -Htan state syn-recv | wc -l

ss -s gives a one-screen summary of all sockets. The second line counts TCP connections stuck in the SYN-RECV state: the client said hello but never finished the handshake. A few is normal; thousands mean someone is sending SYN packets without completing connections.

A surprise from our test: during a SYN flood of tens of thousands of packets per second, this count stayed at 6. The reason is the next command. Linux defends itself with SYN cookies, so a low SYN-RECV number does not prove you are safe.

Command 3: SYN cookies and dropped connections

# as root
nstat -az TcpExtSyncookiesSent TcpExtListenOverflows TcpExtListenDrops

When a listening port's queue overflows, the kernel stops keeping state for new connections and answers with a SYN cookie instead, a setting called net.ipv4.tcp_syncookies that is on by default. TcpExtSyncookiesSent counts those answers. In our lab it jumped to 174,586 within four seconds of the flood starting, while the web server kept working. ListenOverflows and ListenDrops count connections the kernel had to throw away; if those climb, real visitors are being refused.

The kernel also writes it to its log once per port, as Possible SYN flooding on port ... Sending cookies. Look for it with:

# as root
dmesg -T | grep -E 'SYN flooding|nf_conntrack'

Command 4: the connection-tracking table

# as root
conntrack -C
cat /proc/sys/net/netfilter/nf_conntrack_max

If your server runs a stateful firewall (nftables or iptables rules that match on connection state, Docker, or most ufw setups), the kernel tracks every new connection in a table with a fixed size. The first number is how many entries are in use, the second the limit. When the table fills, the kernel logs nf_conntrack: table full, dropping packet and starts dropping new connections, real ones included.

This was the most dramatic number in our test: the table went from 0 to 174,434 entries in four seconds of SYN flood, against a limit of 262,144. A few more seconds and the server would have dropped every new connection, even though CPU and bandwidth were fine. The kernel documentation sizes the default limit from your RAM, so smaller servers fill up faster.

Command 5: look at the packets themselves

# as root
tcpdump -nn -i eth0 -c 100
tcpdump -nn -i eth0 -c 100 'tcp[tcpflags] & tcp-syn != 0'
tcpdump -nn -i eth0 -c 100 'udp and (src port 53 or src port 123 or src port 389 or src port 11211)'

-nn skips name lookups, which matter under load, and -c 100 stops after 100 packets so tcpdump cannot run away on a flooded machine. The second line shows only SYN packets, the third only UDP reflection traffic from DNS, NTP, CLDAP and memcached servers.

In our SYN flood sample, every packet came from a different, random address: 103.184.13.201, 140.145.239.123, 170.157.42.0 and so on. Those addresses are spoofed, so blocking them one by one is pointless. Save a sample for your provider instead:

# as root
tcpdump -nn -i eth0 -c 5000 -w /root/ddos-sample.pcap

What the attack types look like

What you can do on the server itself

Three things help against the attacks a single server can survive:

1. Keep SYN cookies on. Check with sysctl net.ipv4.tcp_syncookies; it should print 1. The kernel documentation warns that cookies are a defence, not a way to handle legitimate heavy load.
2. Rate-limit new connections. This nftables rule drops SYN packets to port 80 above 200 per second:

   # as root
   nft add table inet ddos
   nft add chain inet ddos input '{ type filter hook input priority -10; }'
   nft add rule inet ddos input tcp flags syn tcp dport 80 limit rate over 200/second counter drop
   nft list chain inet ddos input

   In our lab it dropped 1,557,868 SYN packets in five seconds of flood. Pick a limit well above your real peak, because the rule cannot tell attackers from customers, and remove it with nft delete table inet ddos when the attack is over.
3. Do not be part of someone else's attack. A DNS, NTP or memcached service open to the internet can be used as a reflector. Close what you do not need to serve publicly.

The hard limit: every one of these tools works after the packets have already crossed your link. If 2 Gbit/s of attack arrives at a 1 Gbit/s port, the port is full before the kernel sees a single packet, and no setting on the server changes that.

When the uplink is full: what to do next

1. Tell your provider. Send the target IP, the start time in UTC, the packet and bandwidth numbers from sar, and the pcap sample. Providers can filter upstream or, as a last resort, null-route the attacked IP.
2. Understand a null-route. A blackhole, signalled with the BGP community 65535:666 from RFC 7999, drops all traffic to the attacked address. It protects everyone else on the network, but your IP goes offline until the attack stops.
3. Put websites behind a reverse proxy or CDN, then allow ports 80 and 443 only from the proxy's addresses, and change the origin IP, which the attacker already knows. Our guide to reverse proxies on a VPS covers the proxy side.
4. Move the fight upstream for your own IP ranges. If you have your own prefixes, remote DDoS protection announces them from a large filtering network and hands you clean traffic over a tunnel. We offer this from Amsterdam: remote DDoS protection over a GRE tunnel, on Global Secure Layer, from 500 Mbit/s up to 10 Gbit/s.

Be ready before it happens

Numbers only mean something next to a baseline. Keep sysstat collecting so sar has history (on Debian 13 and Ubuntu, systemctl enable --now sysstat as root starts a timer that saves a sample every 10 minutes, and sar -n DEV then shows today's history), write down your normal packets per second and connection counts, and set up an outside monitor that alerts you when the server stops answering. Our guide to Uptime Kuma and Grafana from a second location does that in an afternoon.

Frequently asked questions

How do I know if my server is under a DDoS attack?

Compare packets per second (sar -n DEV 1), half-open connections (ss -Htan state syn-recv), SYN cookies (nstat) and the conntrack table (conntrack -C) with their normal values. A sudden jump in packets from many sources to one port, without matching real users, is an attack.

Can a firewall on the server stop a DDoS attack?

Only a small one. nftables rules and SYN cookies help while the attack is smaller than your network port. Once the link is full, packets are lost before the firewall sees them, and filtering has to happen at your provider or a protection network.

What is a SYN flood?

A SYN flood sends huge numbers of TCP connection requests that are never completed, usually from spoofed addresses, to fill the server's connection queues and tracking tables. In our test it used 36,000 packets per second but under 2 MB/s of bandwidth.

Why did my provider null-route my IP?

A null-route drops all traffic to one address so an attack on it does not hurt other customers on the same network. Your IP comes back when the attack stops; to stay online during attacks, the traffic has to be filtered upstream instead.

How long do DDoS attacks last?

Most are short. Cloudflare's H1 2026 report found 90.6% of network-layer attacks ended within 10 minutes, but campaigns often repeat, so a quiet hour does not mean it is over.

The short version

Install sysstat, tcpdump and conntrack today, note your normal numbers, and when the server slows down, check packets per second, SYN cookies, the conntrack table and a packet sample. Fix what the server can fix, and move what it cannot fix upstream. For servers in Amsterdam, Prishtina or Dublin, every RS Computers VPS is a full KVM machine where all these tools work, and if your own prefixes need protection, message us on Telegram.

← All articles