Capability · Anti-DDoS
A connection passes through four distinct moments on its way through EdgeGuard's gateway — each one defended by a mechanism built specifically for it. All four are per-source decisions. None of them, even working perfectly, can see a flood that stays under every individual ceiling while overwhelming the service in aggregate. That's a different vantage point, watching a different thing, and this is how it works.
All four gates — fingerprinting, SYN cookies, Challenge ACK, and a per-source established-session ceiling — verified live against real traffic.
The scheduler that keeps the watchtower running continuously, the escalation that tightens a flagged service's ceilings, and comparing a gateway against its siblings.
A pgvector/cosine-similarity nearest-neighbor search for cold-starting a new gateway's baseline — dropped for plain grouped SQL aggregates.
01
Every connection the gateway handles passes through the same four moments in its life, and each one gets a mechanism built for exactly that moment — not one generic rule stretched across all four.
02
Every gate above makes a per-sourcedecision — judging the one connection, or the one source IP, in front of it. That's exactly right for a single attacker. It's the wrong granularity for 200 bots, each individually unremarkable, each comfortably under every ceiling, all hitting the same service at once. No single gate was ever built to see the sum of everything that passed through it — tightening any one gate's threshold either misses a distributed flood entirely or starts punishing real traffic long before it catches one.
03
Detector 1 compares a service's current packet rate and connection-arrival pattern against its own recent history — an exponentially-weighted baseline updated in-process, on the gateway, with zero database round-trips on the decision path. Run against real traffic on a test gateway:
| Window | Packets/sec | Connection-gap CV | Deviation score |
|---|---|---|---|
| Steady baseline | ~30–37 | ~0.002–0.006 | not flagged |
| Burst | 403.16 | 2.8324 | 2076.8 (threshold 3.0) |
Caught decisively, and without needing to know anything about where the traffic originated — only that the service's own shape had broken.
04
A detector that watches the whole service, by design, has no source to point at — unlike gates 1 through 4, it never had source-level identity to begin with. The response works at the same level it detects: by default, it logs and alerts, and a person decides. The opt-in escalation temporarily tightens gate 4's per-source ceiling, specifically for the flagged service, for a bounded window, then reverts. It can't remove the 200 bots surgically. Squeezing every source hitting that one service is enough to cut the flood's aggregate throughput without touching anything else on the same gateway.
05
Not automatic yet
The numbers above came from running the detector by hand against a real burst. The scheduler that keeps it running continuously — correct window cadence, periodic snapshots, the escalation and its revert timer — isn't built.
A real blind spot, named honestly
A self-comparison can't see a baseline that's already drifted — if an attack ramps slowly enough to get folded into “normal” before anyone notices, the gateway stops flagging it by definition. Comparing a gateway against its siblings serving the same service, elsewhere in the same org, closes exactly that gap — decided, not yet built.