Attack types, and the check that ends each one.
Attacks on any online service fail differently depending on what the attacker is trying to run out: your bandwidth, your connection table, your CPU or your patience. Prism carries separate detection for each, and records the reason every dropped packet was dropped.
- Named vectors
- 25
- Attack classes
- 6
- Places a packet can be ended
- The upstream edge, then Layer 3, Layer 4 and Layer 7 on your server
- Recorded per drop
- The check that dropped it
Where each attack stops. Each line is one kind of attack, ended at the first check that recognises it.
The line travels left to right and stops at its gate, marked in ember. It never reaches the checks after that.
Order matters. The cheap questions come first, so the expensive one, reading the protocol itself, is only asked of traffic that already looked like a real conversation.
- Amplified reflectionSmall forged requests sent to open services elsewhere, so their much larger replies arrive at you.
- Blocked source or malformed packetA sender on your deny list, or a packet that is not structurally sane. Ended at the lowest possible cost.
- Spoofed UDP floodForged source addresses, one packet each, aimed at an open UDP port.
- Connection floodConnections opened and abandoned, or half-open handshakes that never complete.
- Protocol impostorRight port, plausible packet size, but not the protocol the port serves.
- Query floodA public listing or status endpoint hit far harder than any listing service would.
- Off-path HTTP requestsRequests to paths your service never serves, or with no client identity at all.
- Something never seen beforeA flood with no known signature, no matching rule and no precedent.
Choose an attack. See the gate that ends it. What the gate asks, and the line it leaves on the Attacks tab.
Spoofed UDP flood
Forged source addresses, one packet each, aimed at an open UDP port.
- Gate that ends it
- Layer 4, the transport
- The question it asks
- Is this a real conversation, or a packet pretending to be one?
- How it ends
- The source is challenged. A real client answers as a side effect of connecting normally; a forged source never does, because the reply goes to an address that never sent anything. On a UDP game port this is the first-packet challenge: under load an unknown source has its first packet dropped, a real client retransmits and gets through, a single-shot forged packet never does.
- What legitimate users notice
- Nothing. Clients already connected keep the trust they earned before the flood started.
- Source
- 203.0.113.7
- Target
- udp/30120
- Protection
- udp_challenge
- Packets
- 18,430
Amplified reflection
Small forged requests sent to open services elsewhere, so their much larger replies arrive at you.
- Gate that ends it
- The upstream edge, the network edge
- The question it asks
- Is this more than the link itself can carry?
- How it ends
- The bulk is absorbed upstream, where there is capacity to absorb it. What still reaches the machine meets the packet ceiling on your port rule.
- What legitimate users notice
- Nothing, as long as your ceilings are set above your own busy hour.
- Source
- Many sources
- Target
- udp/53
- Protection
- upstream + per_port_rate
- Packets
- 2.4M pps peak
Connection flood
Connections opened and abandoned, or half-open handshakes that never complete.
- Gate that ends it
- Layer 4, the transport
- The question it asks
- How many new connections is one source allowed to start, and how many may it hold?
- How it ends
- The new-connection rate and the connection ceiling on the rule. This is the attack that takes a server down while its bandwidth graph looks ordinary.
- What legitimate users notice
- Nothing. Established sessions are not counted against a new source.
- Source
- 198.51.100.23
- Target
- tcp/443
- Protection
- new_conn_rate
- Packets
- 6,210
Protocol impostor
Right port, plausible packet size, but not the protocol the port serves.
- Gate that ends it
- Layer 7, the protocol
- The question it asks
- Is this actually the service speaking?
- How it ends
- Protocol validation. A rate limit cannot see this attack, because every packet is individually reasonable. The validator can, because the flood never holds the conversation a real client holds.
- What legitimate users notice
- Nothing. This check reads the payload, not the volume.
- Source
- 203.0.113.88
- Target
- tcp/3389
- Protection
- protocol
- Packets
- 41,905
Query flood
A public listing or status endpoint hit far harder than any listing service would.
- Gate that ends it
- Layer 7, the protocol
- The question it asks
- Is this popularity, or one source asking thousands of times a second?
- How it ends
- Query flood detection with a per-source ceiling, so the endpoint keeps answering real listing services while one shouting source is cut off.
- What legitimate users notice
- Your service stays listed and its status keeps answering. That is the point of not simply closing the endpoint.
- Source
- 198.51.100.41
- Target
- udp/27015
- Protection
- query_rate
- Packets
- 9,884
Off-path HTTP requests
Requests to paths your service never serves, or with no client identity at all.
- Gate that ends it
- Layer 7, the protocol
- The question it asks
- Is this request one the service actually answers?
- How it ends
- Off-path and missing-identity checks on the HTTP side, before the request reaches your application.
- What legitimate users notice
- Nothing. Real browsers and API clients send a user agent and ask for paths the service does serve.
- Source
- 203.0.113.15
- Target
- tcp/443
- Protection
- http_offpath
- Packets
- 3,146
Something never seen before
A flood with no known signature, no matching rule and no precedent.
- Gate that ends it
- Layer 7, behavioural
- The question it asks
- Does this traffic share a shape that real clients do not?
- How it ends
- The zero-day engine derives the payload pattern while the attack is running and refuses traffic matching it, with no rule written in advance. Behavioural scoring and timing regularity work the same way.
- What legitimate users notice
- Nothing, and you do not have to file a ticket and wait for a rule.
- Source
- Many sources
- Target
- udp/9987
- Protection
- signature (derived)
- Packets
- 128,700
Every vector the filter names, by what it tries to exhaust. The reasons you will see on the Attacks tab when something is dropped.
Volumetric floods
4 vectorsMore than the link or the server can absorb. The largest are absorbed upstream; what arrives meets your port ceilings.
How it is separated: The largest are absorbed upstream, where 17 Tbps of capacity sits in front of every plan. What still arrives meets the ceilings on your port rules.
- Amplification
- Small forged requests sent to third-party services that answer with much larger replies aimed at you. Common against exposed query and DNS ports.
- Aggregate flood
- Raw packet volume at a port, from any number of sources, above what that port should ever receive.
- Per-source flood
- A single address sending far more than any real client would.
- Out-of-band flood
- Traffic aimed at a port using a framing the service never legitimately uses.
Spoofed and stateless traffic
3 vectorsPackets claiming an address that never sent them. A real client answers a challenge by connecting normally; a spoofed source cannot.
How it is separated: Challenging the source. A real client answers as a side effect of connecting normally; a spoofed source cannot, because the answer goes to an address that never asked.
- SYN flood
- TCP connection openers that are never completed, filling the connection table.
- Spoofed UDP
- UDP with forged source addresses, which has no handshake to fail.
- Fingerprint mismatch
- A packet whose transport-level characteristics do not match any real client stack claiming to send it.
Connection exhaustion
4 vectorsAimed at the finite number of connections a server can track. This is what takes a server down while its bandwidth graph looks normal.
How it is separated: The new-connection rate and connection ceilings on the rule. The cost is in connection setup, not traffic, which is why bandwidth graphs look normal while it happens.
- Connection flood
- Far more simultaneous connections from one source than a real client needs.
- New connection rate
- Connections opened faster than any human could, usually to force expensive setup work again and again.
- Distributed connection spread
- Many sources in the same network range opening connections together, each one individually unremarkable.
- Half-open and idle abuse
- Connections opened and then deliberately abandoned, or held open doing nothing, to occupy a slot.
Protocol abuse
6 vectorsTraffic that reaches the right port but is not the service speaking. Every packet is well formed, so a plain rate limit cannot see it.
How it is separated: Protocol validation. A plain rate limit cannot see this class, because every packet is individually well formed and under any threshold.
- Invalid protocol
- The payload does not match how the service actually behaves, checked by the validator for that protocol.
- Failed handshake ratio
- A source that keeps starting conversations it never correctly completes.
- Query flood
- The public listing and status endpoints hit far harder than any listing service would.
- Malformed connect
- Connection requests with fields that a real client never sends.
- Replayed connect
- The same connection request sent repeatedly, captured from a genuine client.
- Command abuse
- Valid protocol commands issued in a pattern designed to be expensive rather than to use the service.
Web and HTTP
3 vectorsFor any server running an HTTP service: a site, an API, or the web side of another service.
How it is separated: Request, identity and path checks on the HTTP side, before a request reaches your application.
- Request flood
- Requests per source, per connection or in total, above what the service should serve.
- Missing client identity
- Requests with no user agent at all, which no real browser or client application sends.
- Off-path requests
- Requests hammering paths the service does not serve, usually scanning or probing.
Behavioural and unknown
5 vectorsDetections that do not depend on recognising a specific attack, which is why a novel one does not have to be seen before it can be stopped.
How it is separated: Trust accumulated per source, and patterns derived during the attack itself. This is why a novel attack does not have to be recognised before it can be stopped.
- Behavioural scoring
- A source whose overall conduct does not resemble a client, judged across several signals rather than one.
- Timing regularity
- Traffic arriving on a machine-perfect cadence, which humans and real clients do not produce.
- Reputation
- A source that has already established a pattern of behaving badly against this server.
- Zero-day pattern
- A shape the filter derived during this attack, with no signature written in advance.
- Tier demotion
- A source that had earned trust and then stopped behaving like a client, losing it again.
Policy
3 reasonsNot attacks, but they share the same drop path, so they appear in the same view with their own reason.
- Blocked address
- A source on your deny list.
- Closed port
- Traffic to a port with no rule permitting it.
- Honeypot
- Traffic to a port that exists only to identify scanners, which no real client would ever contact.
Why the thresholds are not on this page. You get what each vector is. The numbers you tune are your own.
What each vector is, and the fact that it is detected, is useful to you. The exact number at which each one trips is mainly useful to somebody trying to sit just underneath it.
The numbers you do control are your own: the ceilings on each port rule, which you set from your busy-hour traffic, and which engines run on a rule. If a real user is ever dropped, Address lookup on the Attacks tab names the check that did it, and that is the one to tune.
Reference. The same list, maintained with the filter, in the help center.
- What the filter detectsThe full reference, including the policy reasons that share the same drop path.
- Reading the Attacks tabWhere these reasons appear against your own traffic.
- Protocol validationTurning the layer 7 checks on for a rule.
- When real users cannot connectIf a legitimate client is being caught by one of these.
Every one of these is filtered on every plan.
No add-on and no tier: the same 17 Tbps upstream and the same checks at the network driver, on VPS, VDS and bare metal.