How UDP Flood, SYN Flood and Amplification Attacks Work

Understanding how a DDoS attack actually hurts you is the first condition of stopping it. The sentence "we are under attack" tells you nothing on its own: UDP flood, SYN flood and amplification work through entirely different mechanisms, exhaust different resources, and demand different defences. A measure that stops one may do nothing at all against another. This guide explains how these three attack types work at the packet level, how to tell them apart, and which layer you need to defend at for each.

Start with the basic question: what are they consuming?

The most practical way to understand these attacks is to ask which resource they target. There are three, and your server becomes unreachable when any of them runs out:

• Bandwidth: The capacity of your network link. Once saturated, legitimate traffic cannot get in.
• Connection state: The tables where the operating system tracks open connections. Once full, no new connection can be accepted.
• Processing power: CPU and application threads. Once exhausted, the server stops responding.

UDP flood and amplification primarily target bandwidth. SYN flood, by contrast, exhausts connection state without consuming much bandwidth at all — which is why it can be effective with a very small traffic volume. This distinction underpins the whole layer discussion; for the wider picture, see our comparison of Layer 4 and Layer 7 DDoS attacks.

SYN Flood: exploiting the TCP handshake

How the three-way handshake works

A normal TCP connection is established in three steps. The client sends a SYN packet, the server replies with SYN-ACK, and the client confirms with ACK. At the second step the server has a problem: while waiting for that final confirmation, it has to remember the connection. So it allocates a record in the kernel and marks the connection as "half-open".

How the attacker breaks this step

In a SYN flood, the attacker sends thousands of SYN packets and never answers any of them with an ACK. Because the source IP addresses are spoofed, the SYN-ACK packets the server sends go to non-existent or unrelated addresses. The server allocates a record for each one and waits until timeout.

The result: the half-open connection queue (backlog) fills up. Once it is full, the server begins rejecting SYN packets from legitimate users too. From the outside the server looks completely down, even though your link is nearly idle. That is what makes SYN flood insidious — you may not see a dramatic spike on your traffic graph at all.

SYN cookies: not holding state in memory

The classic defence developed against this attack is SYN cookies. The idea is elegant: instead of reserving memory for a half-open connection, the server encodes the connection details into the sequence number of the SYN-ACK packet, so it does not need to keep a record at all. If the client really does return with an ACK, the server reconstructs the connection from that number. Spoofed SYN packets never come back, so they consume no resources. On Linux this behaviour is controlled by net.ipv4.tcp_syncookies and is enabled by default on most modern distributions.

UDP Flood: the price of a connectionless protocol

UDP has no handshake. A packet arrives, it is processed, and that is it. Because this design lowers latency, services such as game servers, DNS and VoIP rely on UDP. The same design creates two security problems.

First, the source IP address is trivially spoofable. In TCP a handshake cannot be completed from a forged address, but UDP has no such verification step. Second, the server has no opportunity to validate the sender before processing the packet.

What happens during the attack

The attacker sends a high volume of UDP packets to random or specific ports on the target. Two distinct kinds of damage occur:

• Packets to closed ports: The operating system tries to generate an ICMP "port unreachable" response for each one. That consumes both CPU and outbound bandwidth.
• Packets to an open port: Packets arriving on the port your game server listens on go straight to the application. The application has to parse every packet; even when they are invalid, this burns CPU and slows the game loop.

This is exactly why game servers are targeted so often: the port is already open, the protocol is already UDP, and the single-threaded game loop is a bottleneck. We covered why HTTP-based solutions such as Cloudflare fall short in this scenario in our article on Cloudflare and the UDP reality.

Amplification: small question, enormous answer

Amplification is the technique that lets an attacker multiply the bandwidth available to them many times over. The largest volumetric attacks are produced this way.

Reflection and amplification are not the same thing

Two concepts are frequently conflated:

• Reflection: The attacker spoofs the source IP as the victim's address and sends a request to a third-party server. That server innocently sends its reply to the victim. The real origin of the attack is hidden.
• Amplification: On top of reflection, the chosen protocol's response is far larger than its request. The attacker sends a small packet; the victim receives a much bigger one.

Used together, an attacker can direct traffic at a target that far exceeds the capacity of their own link.

Which protocols are abused?

The exploited protocols are UDP services left exposed to the internet that perform no authentication:

• DNS: Queries sent to open resolvers that produce large responses.
• NTP: The monlist command in older versions returns a long client list from a single request.
• Memcached: Cache servers left exposed to the internet, which carry the highest known amplification ratios.
• SSDP: Misconfigured UPnP devices, particularly consumer routers and cameras.
• CLDAP: Directory services exposed to the internet.

The amplification ratio varies from tens to tens of thousands of times depending on protocol and configuration. That is why the defence discussion focuses less on "how many times" and more on "what happens when my link is full".

Why is it so hard to stop?

Amplification traffic technically arrives from legitimate servers. The source addresses belong to real DNS or NTP hosts. A simple IP blocklist therefore does not work: the list changes constantly, and you risk blocking genuine infrastructure. On top of that, by the time the traffic reaches your server your link is already saturated.

How to tell the three apart

To work out quickly which one you are facing during an incident, look for these signs:

• High packet rate, low bandwidth, many half-open connections: Most likely a SYN flood. You will see numerous SYN_RECV states in netstat or ss output.
• Link fully saturated, small packet sizes, many distinct source IPs: UDP flood.
• Link fully saturated, large packet sizes, source IPs belonging to well-known services and concentrated on a single source port (53, 123, 11211): Amplification.
• Traffic looks normal but the application will not respond: You are probably dealing with an L7 attack rather than L4.

Which defence belongs at which layer?

Network level: the only real answer for volumetric attacks

With UDP flood and amplification, it is already too late once the packets reach your server. Filtering has to happen upstream, before the traffic enters your link. That depends on your hosting provider's infrastructure — our game server services and dedicated server solutions run on DDoS-protected network infrastructure.

Server level: SYN flood and noise reduction

• Make sure SYN cookies are enabled.
• Tune connection tracking (conntrack) limits to match your server's capacity.
• Close every port you do not use at the firewall; drop packets to closed ports silently instead of generating an ICMP response.
• Apply rate limiting to game and management ports.
• Restrict management access (SSH, RDP) by source IP.

Hardware headroom: the last line

You need processor and storage headroom to absorb whatever residual traffic slips through the filter. Because game servers in particular run their main loop on a single core, high single-core performance is decisive. Our AMD Ryzen 9 9950X based Turkey-location VDS options are configured for exactly this scenario with DDR5 memory and NVMe M2 SSD storage.

Frequently Asked Questions

What is the most practical difference between a SYN flood and a UDP flood?

A SYN flood fills your connection table with very little traffic; a UDP flood aims to saturate your link directly. The first can be mitigated substantially through server configuration, the second requires filtering at the network level.

If I block all UDP traffic at my firewall, does that solve it?

No. The packets have already reached your link; even if the firewall drops them, the bandwidth has been consumed. And since your game server also uses UDP, you would be blocking legitimate players too.

Should I report the servers attacking me in an amplification attack?

Those servers are usually not the culprit but poorly configured third parties. Notifying their owners is useful for the internet in the long run, but it will not stop an attack in progress.

Why is source IP spoofing still possible?

Because source address validation is left to the discretion of network operators and is not enforced everywhere in the world. That is why reflection attacks remain effective.

How do I tell whether my server is under attack?

Monitor packet rate, bandwidth and connection-state counters together. Which of the three looks abnormal tells you directly what kind of attack you are facing.

Do these attacks affect services other than the game server?

Yes. If a website, database or voice server runs on the same machine, they all share the same link and are affected together. Separate critical services where you can.

Summary

A SYN flood fills the connection table by leaving TCP handshakes half-finished, doing serious damage with very little traffic; its defence lies largely on the server side. A UDP flood exploits the connectionless protocol's inability to verify senders, consuming both your link and your CPU. Amplification is the method that reaches the highest volumes, with the attacker generating enormous responses from third-party servers using tiny requests. For the latter two, the only realistic defence is filtering the traffic at the network level before it reaches your server. In-server hardening and hardware headroom complement that — they do not replace it.

If you want to host your project on DDoS-protected network infrastructure, take a look at our game server packages, or get in touch to work out the right solution for your current setup. Our 24/7 support team can also advise you on what to do while an attack is underway.