Quick reference
| Attack | Layer | What it targets | What stops it |
|---|---|---|---|
| UDP flood | 3/4 | Bandwidth | Upstream volumetric mitigation |
| DNS / NTP amplification | 3/4 | Bandwidth | Filtering reflected replies |
| SYN flood | 4 | Connection table | SYN proxy or SYN cookies |
| ICMP flood | 3 | Bandwidth and CPU | ICMP control at the edge |
| Fragment attack | 3 | Packet reassembly | Dropping fragments |
| HTTP flood | 7 | Web application | Per-source limits and caching |
| Game query flood | 7 | Game server | Query validation and caching |
| Connection exhaustion | 4/7 | Service connection slots | Per-source connection limits |
1. UDP flood
Huge volumes of UDP packets sent to random or specific ports. UDP has no handshake, so the packets are easy to forge and send in bulk. The aim is simply to fill the connection. It has to be absorbed upstream, because nothing on the server can help once the link is full.
2. DNS and NTP amplification
The attacker sends small queries to open DNS, NTP, memcached or similar servers with the victim's IP forged as the source. The replies are many times larger than the queries and all land on the victim. Because these replies come from known source ports, they can be recognised and dropped at the network edge.
3. SYN flood
Thousands of TCP connection requests that are never completed. Each one takes a slot in the server's table of half-open connections until there is no room for real clients. A SYN proxy completes the handshake in front of the server, so only clients that finish it get through.
4. ICMP flood
A flood of ping and other ICMP messages that uses up bandwidth and makes the server spend time replying. Limiting echo requests and dropping ICMP types that are only used for probing deals with it, while keeping the messages networks need to work properly.
5. Fragment attack
Packets deliberately broken into fragments, sometimes malformed or overlapping, so the target spends its resources trying to reassemble them. Game, voice and most VPN traffic never needs fragments, so they can usually be dropped outright.
6. HTTP flood
Large numbers of normal-looking web requests aimed at expensive pages such as search, login or checkout. Each request is valid on its own, which makes this harder to filter. Per-source request limits, caching and closing anything that does not need to be public all help.
7. Game query flood
Server-browser queries such as Steam's A2S requests, sent at a rate far above what real players produce. Every query makes the game server do work. Validating that queries are real and answering them from a cache in front of the server stops the flood without taking the server off the browser list.
8. Connection exhaustion
Many slow or idle connections opened to a service, such as a web server or game port, until it runs out of slots for real users. Per-source connection limits and closing services that do not need to be exposed are the main defences.
Multi-vector attacks
Most serious attacks combine several of these at once, for example an amplification flood to fill the link and a SYN flood to tie up whatever gets through. That is why protection needs to work in layers: absorb the volume upstream, filter at the edge, then validate what is left. See how Glitch Guard does this on the DDoS protection page.
Frequently Asked Questions
Next Steps
For the basics, read what is a DDoS attack. For a practical defence plan, see how to prevent DDoS attacks.
Want protection that is already set up?
Every Glitch Servers VPS and dedicated server comes with always-on DDoS mitigation and Glitch Guard per-IP filtering at no extra cost, and game servers and web hosting are protected as standard.