DDoS mitigation with the runbook written before the attack.
BGP-level filtering, selective blackholing and traffic scrubbing at AS54098 — coordinated with upstreams we actually know.
- BGP filtering · flowspec · scrubbing
- RTBH via AS21700, AS6939, AS3257
- AS54098 · transit-layer mitigation
- runbook designed in advance
DDoS Mitigation, in plain terms.
Mitigation that starts at the transit layer. On AS54098 we can drop attack traffic at the edge with BGP flowspec and prefix-level filtering, request remote-triggered blackhole from AS21700 and our peering relationships at AS6939 Hurricane Electric and AS3257 GTT, and pull scrubbed traffic back to you over a clean path. The point is to stop the flood as far upstream as possible — not to absorb it at your firewall.
The work is mostly done before the page fires. We sit with your team, document the protected prefixes, agree on the trigger thresholds, and write down what 'acceptable collateral' looks like for each service. When traffic spikes, the on-call engineer follows a runbook you already approved instead of inventing policy in the middle of an incident.
Reporting is in human language. After the event you get a timeline, the sources we filtered, the upstreams that helped, and what we would change in the runbook for next time.
Common triggers for this engagement.
- 01Your application is internet-facing and downtime has a real cost
- 02Your firewall keeps getting asked to absorb volumetric traffic it cannot
- 03You need BGP-level filtering coordinated with your transit provider
- 04You want a runbook agreed in advance, not invented during the incident
Questions teams ask before signing.
How do you actually filter attack traffic?
Three layers. BGP flowspec and prefix filtering on AS54098 to drop obvious patterns at our edge. Remote-triggered blackhole coordinated with upstreams when the volume requires it. Scrubbing for traffic we want to keep — return path comes back to you clean.
What do I need to provide ahead of time?
Your protected prefixes, an ASN if you have one, contact rotation, and a sit-down to agree on thresholds and acceptable collateral. The runbook is written collaboratively so there is no improvisation when the alert fires.
Can you mitigate if I do not buy transit from you?
Often yes — by announcing protected space through us during an event, or via a scrubbing-only arrangement. The cleanest setup is full transit on AS54098, but we will work with what you have.
What do I get after an attack?
A written incident timeline, what we filtered and where, which upstreams helped, residual traffic patterns, and a short list of runbook changes we recommend. No charts that mean nothing.
What capacity do you actually have to absorb a flood?
Capacity is sized per engagement and disclosed under NDA — published numbers tend to mislead more than they inform. The strategy is layered: BGP filtering and RTBH at AS54098 to drop the volumetric component upstream, then selective scrubbing for the traffic worth keeping. If a flood is larger than we can absorb cleanly, we will say so before you sign — not during the incident.
Frequently scoped alongside this work.
IP Transit (BGP)
Full BGP transit on AS54098 with direct peering at Hurricane Electric and transit through GTT into the rest of the Tier-1 fabric. Bring your own ASN and prefixes — we handle the policy and the on-call.
24/7 NOC
Eyes on your network around the clock, run by the engineers who write the runbooks. Pages routed to humans, not a ticket queue — for incidents that need a real person at 3 a.m.
Cybersecurity Consulting
Architecture review, control-gap analysis, and incident readiness — paired with operators who understand the network the controls run on. We tell you which fixes are real and which are theater.
Security Architecture Review
A structured read of how identity, network, and data controls actually fit together — not how the policy says they should. We surface the gaps before a real attacker, or an auditor, does.