DDoS protection, enforced by state.
Every packet crossing AS202520 is checked against a live connection-tracking table. Traffic that can't prove it belongs to a real session — spoofed SYNs, ACK and RST storms, reflected DNS and NTP, out-of-window TCP — is dropped at our edge, before it ever reaches your port.
State is the filter
A stateless firewall asks whether a packet looks allowed. A stateful firewall asks whether it belongs to a conversation that actually exists. Floods are, almost by definition, traffic with nothing behind it — which is exactly what the state table is built to recognise.
Connection tracking
Every flow gets a row: 5-tuple, TCP state, sequence window, rate and age. A live table decides what may pass — not a static ACL written months ago.
Out-of-state drops
SYN-ACK, ACK, PSH-ACK, RST and FIN floods carry no matching entry. They are INVALID the moment they arrive and get dropped at line rate.
SYN proxy
Under a SYN flood we complete the handshake on the target's behalf. Only clients that can actually finish a three-way handshake earn state — spoofed sources never do.
Reflection immunity
A DNS, NTP, SSDP, CLDAP, memcached or chargen reply to a query nobody sent matches nothing. Amplified reflection dies at the edge, whatever its ratio.
Rate and quota policy
Per-source and per-destination ceilings on new connections, concurrent state and packet rate stop state tables and application backlogs from being exhausted.
Protocol validation
Header sanity, fragment reassembly, illegal flag and option combinations, per-protocol semantics — crafted and malformed packets are rejected before deep processing.
Four verdicts, every packet
Connection tracking reduces an attack to a sorting problem. Each packet resolves to one of four states, and only one of them is where flood traffic can hide.
| State | What it means | What happens |
|---|---|---|
| NEW | First packet of a flow with no prior entry | Accepted under rate and quota policy, then tracked |
| ESTABLISHED | Matches a tracked, two-way conversation | Forwarded — your real users live here |
| RELATED | Legitimately spawned by a tracked flow | Forwarded — keeps FTP, ICMP errors and SIP media working |
| INVALID | No matching entry, or impossible for the flow it claims | Dropped — where the overwhelming majority of a flood lands |
What the filter stops
Attacks arrive on three different layers and fail for three different reasons. Nothing here needs a signature update to be recognised — an attack that cannot hold a session cannot pass a state check.
Volumetric floods
Raw bandwidth and packet rate, usually spoofed and usually amplified. Absorbed upstream of your port, where there is room to absorb it.
- UDP floods to open and closed ports
- ICMP / ping and smurf floods
- IP fragment and teardrop floods
- DNS, NTP, SSDP, CLDAP reflection
- memcached, chargen, QOTD amplification
- GRE and IP-in-IP encapsulation floods
- Spoofed source-address floods
Protocol and state attacks
Cheap for the attacker, brutal for a stateless edge: they exhaust connection tables and listen backlogs rather than links. This is where connection tracking is decisive.
- SYN floods, with or without spoofing
- SYN-ACK, ACK and PSH-ACK floods
- RST and FIN floods
- Out-of-window and out-of-state TCP
- TCP fragment and malformed-flag attacks
- Connection floods and state exhaustion
- Sockstress and zero-window attacks
- Slowloris, slow POST and slow read
Application floods
Fewer packets, real handshakes, expensive requests. Rate policy, quotas and protocol validation cut the volume down to what your application can actually serve.
- HTTP and HTTPS GET / POST floods
- TLS handshake and renegotiation floods
- DNS query floods and NXDOMAIN water torture
- SIP INVITE and REGISTER floods
- Game query floods — A2S, RakNet, Minecraft handshake
- Login, search and API abuse patterns
Built for the networks that get hit
Access networks, hosting platforms and game infrastructure absorb the bulk of what gets launched on the internet — usually not because of who they are, but because of who sits behind them.
ISPs and operators
One attacked subscriber saturates the uplink and takes the whole POP with it.
Filtering happens at our edge, upstream of your access links — the flood never reaches the segment it was meant to congest, and the rest of your subscribers never notice.
Hosting and colocation
A single targeted customer degrades every neighbour sharing the rack or the aggregation switch.
Policy is applied per prefix and per IP, so mitigation is contained to the target. No blanket nullroute, no collateral outage for tenants who did nothing wrong.
Game hosting
UDP-heavy, latency-sensitive, and attacked constantly by the players themselves.
State tracking plus protocol validation separates real client sessions from query floods and spoofed UDP — instead of the blunt alternative of dropping UDP and killing the game.
E-commerce and SaaS
Checkout, login and search endpoints go down at exactly the worst moment.
Connection quotas and rate policy hold request volume to what your application can serve, while established customer sessions stay up throughout the event.
VoIP and SIP
INVITE and REGISTER floods exhaust the SBC long before the link fills.
Signalling floods are cut at the edge and related media flows are tracked properly, so calls in progress survive the attack rather than dropping with it.
DNS and infrastructure
Query floods and NXDOMAIN water torture starve resolvers that everything else depends on.
Per-source query rate policy and reflection immunity keep authoritative and recursive servers answering, including when they are the amplifier being abused.
The mitigation path
What actually happens between a flood leaving a botnet and your equipment not noticing.
- 01
Ingest
Your traffic reaches AS202520 over transit, internet exchanges and direct peering — the same paths described in our peering policy, with no separate scrubbing detour to set up.
- 02
Baseline
Flow telemetry on every edge port builds a picture of what normal looks like for each prefix: packet and bit rates, protocol mix, source spread, connection churn.
- 03
Detect
Deviation from that baseline, together with well-known attack signatures, triggers mitigation automatically. No ticket, no phone call, no waiting for someone to notice.
- 04
Enforce
The stateful engine applies its verdicts to the targeted prefix: out-of-state drops, SYN proxying, rate and quota policy, protocol validation. Everything else on the network is untouched.
- 05
Deliver
Clean traffic continues to your port. Sessions established before the attack started stay established — the goal is an event you read about afterwards, not one you watch live.
- 06
Escalate, if it comes to that
For extreme cases we can blackhole a targeted address on request, trading one IP for the health of the rest of your network. It is a last resort, not the first move.
How it is delivered
No appliance to rack, no DNS change, no traffic redirect to arrange. If you are connected to AS202520, you are already behind the filter.
- Mitigation mode
- Always-on, inline at our edge
- Address families
- IPv4 and IPv6
- Enforcement
- Stateful connection tracking + SYN proxy
- Detection input
- Flow telemetry on every edge port
- Trigger
- Automatic — no customer action required
- Blast radius
- Per-prefix and per-IP policy
- Session handling
- Established sessions preserved during mitigation
- Redirect delay
- None — traffic is already on the filtered path
- Escalation
- Customer-requested blackholing for extreme events
- Reporting
- Attack window, vectors and volumes on request
The things engineers ask first
Short answers, no marketing arithmetic.
Tell us what you run, and what keeps hitting it.
Send your ASN or prefixes, the services behind them and — if you have it — a capture or a graph from the last incident. We will come back with what the filter would have done to it.