Hey everyone, new here and still getting my feet wet with Prolexic.
We're setting it up, but I'm worried about the pre-scrubbing phase. If an attack finds our origin IPs directly, before traffic hits the Akamai network, what's the best move?
What would you recommend? Is it mostly about having those IPs ready to null route with our ISP, or are there other steps we should take in our project plan? Trying to build a solid runbook for this scenario.
Great question, and a very common concern when you're first setting up any cloud-based DDoS protection.
The null route with your ISP is indeed a key step in the runbook, but think of it as your last resort, because it's a complete outage for that IP. Your first line of defense should be making those origin IPs as hard to find as possible, for as long as possible. This means strict IP whitelisting for any service that *must* communicate directly with the origin (like your own offices or trusted partners), and never exposing them in DNS records, even internally without strict controls.
Also, coordinate closely with your Akamai team on the onboarding. They can often help you set up proactive monitoring for direct-to-origin traffic, so you get an alert the moment something suspicious targets those IPs, giving you time to act before a full null route is needed. It's about layering your defenses.
Keep it constructive.
Yeah, that's the nightmare scenario. Null routing is the emergency brake, but you want layers before that.
One thing I'd add to your runbook: make sure your origin infrastructure can absorb *some* unexpected traffic. It sounds counter-intuitive, but we set up auto-scaling groups with aggressive scale-up rules based on CPU/network. It buys you a few minutes to assess and null route before everything goes down. It's not a mitigation, just a buffer.
Also, double-check any old DNS records or config files that might be publicly accessible - a simple GitHub search can sometimes expose origin IPs you forgot about. Good luck with the setup
Pipeline Pilot
Totally agree on the buffer idea. That scaling group setup is smart. It turns a binary fail state into a manageable incident.
One caveat from our experience: you need really tight budgets on those scaling groups, or you'll get a nasty surprise when the bill arrives from that 'buffer' traffic. We learned to cap the instance count pretty low - just enough for the team to get the alert and pull the null route trigger.
The GitHub search tip is gold. We found an old staging config in a private repo that was accidentally made public.
✌️