Attack types
What the network filters, and how that maps onto the attack types the API reports.
Two different vocabularies describe the same traffic, and they do not line up one-to-one. This page is both of them.
What the network filters
| Class | Examples |
|---|---|
| Volumetric | TCP floods on any flag combination — ACK, PSH, SYN, RST, URG — UDP, ICMP, GTP and ESP floods, Ping of Death, teardrop |
| Reflection and amplification | DNS, NTP, SSDP/UPnP, SNMP, LDAP, Chargen, QUIC, RIP, TFTP, memcached |
| Resource exhaustion | Malformed and truncated packets, IP fragmentation, invalid TCP flag combinations, bad checksums, bogus TCP/UDP flags, invalid ports, reserved source addresses |
| Game-specific | A2S source floods and A2S GETSUM, FiveM exhaustion, handshake abuse, HTTP Slowloris, NetBIOS |
The first three are handled by the network whether or not you configure anything. The fourth is where a filter on the right port earns its keep, because "valid for this game's protocol" is not a question a generic scrubber can answer.
What the API calls an attack
Attack history and attack webhooks report a much
coarser attack_type, derived from the primary IP protocol observed in the
sampled traffic:
attack_type | Protocol |
|---|---|
UDP Flood | 17 |
TCP Flood | 6 |
ICMP Flood | 1 |
GRE Flood | 47 |
Unknown | anything else, or no clear majority |
attack_type is a protocol label, not a classification of the attack. A DNS
amplification and a plain UDP flood are both UDP Flood; an A2S source flood is
also UDP Flood. Do not build alerting logic that assumes the string names a
technique.
The useful discriminators on an attack record are the ones alongside it —
top_ports says which service was aimed at, top_sources says how distributed it
was, and peak_pps against peak_bps separates a packet-rate attack from a
bandwidth one. A high peak_pps with a low peak_bps is small packets in
volume, which is the shape that exhausts a server rather than a link.
Carpet bombs
An attack spread thinly across many addresses in one of your prefixes is a carpet bomb, and reporting it as dozens of unrelated single-address events would bury the fact that it is one campaign. When enough distinct addresses inside a prefix you announce come under attack within the same short window, we treat the prefix as under a carpet bomb for the next several minutes:
- per-address attack emails collapse into one carpet-bomb notification, rather than one message per address
- private attack webhooks carry an aggregate block — the prefix, how many addresses are involved, the combined peaks, and the set of attack types seen across all of them
The individual attack records are still written, so attack history shows every address. The aggregate is what tells you they belong together.
This applies to prefixes you announce. An address that reaches you through a service has no owned prefix to aggregate against, so it is always reported on its own — see Ownership.