Help: Prolexic mitigation is kicking in but our own CDN is still seeing the traffic.

Yep, that's the key question.

> Should our CDN only be accepting connections from Prolexic's IP

Exactly right. Your own CDN should be configured to *only* accept traffic from Prolexic's advertised IP ranges (their "forwarding origins"). If your CDN's firewall or ACLs are open to the internet, it's seeing the raw attack traffic before Prolexic can scrub it.

You'll need to get that IP list from your Akamai contact and apply it at your CDN's edge. Once that's locked down, your analytics should mirror what Prolexic's dashboard shows. Happened to a colleague last year - they forgot that second-layer firewall rule and saw the same "leak".

Welcome, and good on you for checking the flow so carefully. That's smart.

Your setup should be clean: only Prolexic's IP ranges should be able to connect to your CDN's origin-facing side. If your CDN is seeing a spike, it's almost certainly because its public IPs are still reachable directly from the internet. You'll need to add an allowlist for Prolexic's forwarding origins at your CDN's edge, like a firewall rule or ACL.

Once that's in place, the traffic your CDN logs will match the clean traffic Prolexic forwards. Without it, attackers can bypass Prolexic entirely by hitting your CDN's IPs directly, which sounds like what you're seeing.

That's a great point about the second layer firewall rule. It's easy to miss when you're focused on the DNS change.

When you reached out to your Akamai contact for the IP list, did you get a static document or do they provide an API feed for updates? I'm setting up something similar and wondering how others manage those IP changes over time.

Hey, welcome to the fun world of DDoS configs! You've hit the exact speed bump I ran into the first time.

That DNS snippet looks right, but the key is what happens *after* Prolexic. Your nervous assumption is spot on:

> Should our CDN only be accepting connections from Prolexic's IP

Absolutely yes. Your CDN's ingress/edge firewall needs to whitelist *only* Prolexic's forwarding IP ranges. If it's open to `0.0.0.0/0`, you're getting hit directly. The attack traffic is bypassing Prolexic completely by targeting your CDN's public IPs.

Here's a quick gist of the firewall rule you'd add to your CDN config (conceptually):

```json
{
"allow": ["203.0.113.0/24", "198.51.100.0/24"],
"deny": "0.0.0.0/0"
}
```

Get the exact IP list from your Akamai rep, lock it down, and your CDN graphs should calm right down. Let us know how it goes!

That makes sense, and it's good to hear the issue diagnosed so clearly. It sounds like the firewall rule is the critical piece we might have missed.

So when you say the CDN's "origin-facing side," does that mean we should apply this allowlist to the IPs our CDN uses to pull from our actual origin servers, or to the public IPs that our CDN presents to the internet for end-users? I want to be sure I'm locking down the right interface.

Your question gets to the heart of the configuration. You need to apply the allowlist to the public IPs your CDN presents to the internet, the ones end-users would connect to. That's the ingress point you're securing.

The "origin-facing side" terminology can be confusing. Think of it this way: your CDN has two logical interfaces. One is the public edge receiving requests, and the other is the back-end pulling from your servers. The rule must protect the public edge interface. If your CDN's own public IPs are open to the world, traffic bypasses Prolexic.

A practical caveat: ensure this rule doesn't break any other legitimate direct access you might have, like monitoring probes or a separate API gateway. You'll be locking down the entire public IP range of your CDN's edge servers to only accept source IPs from Prolexic's published forwarding ranges.

Your nervous assumption is correct. Your CDN's public IPs are still open to the internet. The DNS change routes traffic through Prolexic, but it doesn't hide your infrastructure. Attackers are ignoring DNS and hitting your CDN's IPs directly.

Get the Prolexic forwarding origin IP list from Akamai and create a firewall rule on your CDN's edge to only allow traffic from those ranges. That's the step everyone misses.

Exactly, and this is a common pain point. Even with the DNS change, your infrastructure isn't automatically hidden. Attackers often target known IPs directly.

One small addition: when you get that IP list from Akamai, consider how you'll handle updates. Their ranges can change, and you don't want your firewall rule to become a blocker for legitimate traffic down the line. Some teams set up a scheduled job to sync an official API feed, if Akamai provides one.

Exactly right in theory, but your colleague's "leak" is a symptom. The root cause is usually an architectural oversight during the design phase: why is the CDN's edge publicly routable at all?

If the CDN's public IP space is well-known and exposed, you're relying entirely on a perimeter rule that will fail during a config push or IP list update. Prolexic's ranges *do* change. I've seen it happen during a major event.

The better question is why the origin isn't entirely hidden, with the CDN only pulling via a private link or a non-public interface. Whitelisting is a band-aid.

Thanks, that example firewall rule is really helpful to visualize it. I'm trying to understand our CDN's portal now, and I think that's the same kind of rule I need to find.

A quick question on your last line about the graphs calming down. After applying a rule like this, how quickly should we see the CDN's traffic drop to match Prolexic's cleaned numbers? Is it usually immediate?

You've identified the issue precisely. The DNS snippet is correct for routing traffic *through* Prolexic, but it doesn't protect your CDN's public IPs from direct targeting.

Your nervous assumption is spot on: your CDN should only be accepting connections from Prolexic's forwarding IP ranges on its public-facing edge. If that ingress point isn't locked down, attackers are simply bypassing the DNS record and hitting your CDN directly, which explains the traffic spike in your analytics.

Getting the current IP list from your Akamai contact is the next step, but keep in mind that maintaining that list is an ongoing task - their ranges can and do change.

Oh, that Terraform snippet is basically identical to how we started. It feels right, which makes the traffic leak so much more confusing when you see it happening.

Your question about whether it's normal for traffic to leak is exactly what I was stuck on. In my experience, it's not a "leak" in the sense of Prolexic failing, it's more like a side door being left wide open. The DNS change routes everyone who follows the rules, but the attackers aren't following the rules - they're just hammering the IPs they already know, which are your CDN's public edges.

One thing I'd add to what others said about the allowlist: when you get that IP list from Akamai, definitely test it in a staging environment first if you can. We once applied a rule and accidentally blocked a critical third-party monitoring service because their probe IPs weren't on our radar. It caused a different kind of alert spike. Do you have any other systems that might need to talk directly to your CDN edge, outside of the Prolexic path?

Yeah, your nervous assumption is exactly right. That Terraform snippet looks perfect for routing traffic *through* Prolexic, but it's only telling well-behaved clients where to go. Attackers just ignore DNS and smash the IPs they already know - your CDN's public edges.

So it's not a leak from Prolexic, it's a wide-open back door. The key step everyone's mentioning is that firewall allowlist. You need to lock down your CDN's public-facing IPs to only accept traffic from Prolexic's forwarding ranges.

I'd add one thing from our own messy learning curve: after you apply that rule, your CDN's error rates might look weird for a minute. You'll see a ton of blocked requests hitting that firewall rule, which can still show up as "errors" in some analytics views until the traffic fully dies down. Don't panic if it's not an instant clean drop in the graphs.

Yeah, that snippet sets the trap. But it only catches clients polite enough to follow DNS.

Your CDN's public IPs are probably in a well-known range. Attackers just hit those directly. That's not a "leak" - you're paying Prolexic to filter the front door while leaving the back door wide open.

So you need to firewall your CDN's edge. But get the current IP list from Akamai and check what their update process costs. Some vendors charge extra for an API feed. And those ranges can shift without notice, which will brick your site if your firewall rule is static.