Hey everyone, I saw the news about the new botnet, "BlackNurse" (or at least that's what the article I read called it). It seems to be using a new mix of TCP and UDP floods, specifically targeting certain ports in a way that's evading a lot of standard perimeter defenses.
I'm a bit on edge because my team uses Akamai Prolexic for DDoS mitigation on our main analytics pipelines. Our data warehouse (BigQuery) and the ETL jobs (Airflow) that feed it are all behind their protection. If a new attack signature isn't caught, it could overwhelm our ingest endpoints and break everything downstream. I'm picturing failed tasks piling up and late data deliveries.
My main question is: does anyone here know how quickly Prolexic typically updates its signature sets for these new, major botnets? Is it automatic, or is there a lag? I tried checking the Akamai portal/API for any bulletins or update logs but couldn't find a clear "signature version" or timeline.
I'm also wondering about a safe pattern for us on the data pipeline side. Should we be implementing some additional, short-term rate-limiting in our own code as a fallback? Something like this in our API endpoint (which is the first step of our pipeline):
```python
from flask_limiter import Limiter
limiter = Limiter(app, key_func=get_remote_address)
@app.route('/ingest', methods=['POST'])
@limiter.limit("1000 per minute") # temporary, aggressive limit
def ingest_data():
# pipeline start logic
pass
```
Or is that overkill and I should just trust that Prolexic's updates are near-instantaneous? I don't want to add complexity, but I'm really nervous about breaking production. Any insights from others using Prolexic in a similar setup?
Prolexic's response time for genuinely new attack patterns can be a 12-24 hour window, from what I've seen on past calls. They're good, but automatic updates only cover variations of known signatures. A completely new vector like you're describing usually triggers a manual rule push from their SOC.
While you wait for their update, implementing a short-term rate limit at your endpoint is a solid defensive move. Just be careful not to throttle your legitimate ETL traffic.
For monitoring, you should watch your Prolexic metrics in Grafana for `mitigation_start_delay` on your specific IPs and ports. A spike there is your first signal they're catching something new. I'd also add an internal alert on your Airflow task failure rate, as that's your downstream canary.
Sleep is for the weak
Great points. For the rate limiting in your own code, just make sure you're not using the same IP-based logic Prolexic already handles. We had a case where we added app-level rate limiting and it started blocking legitimate traffic from our own CI/CD runners because they were all NAT'd behind a single IP.
You might also watch your cloud egress costs. If Prolexic misses the signature for a bit, you'll still get charged for the attack traffic flowing to your endpoint before it's dropped. Saw a nasty surprise on a bill once for that.
Check your Akamai portal for "Security Events" - they sometimes post manual mitigation notices there faster than a full signature update.
The 12-24 hour window mentioned is accurate, but the critical factor for your data pipelines is the operational impact of a full cycle. That window includes detection, analysis, rule creation, and staged deployment across their scrubbing centers. Even a 6-hour gap means your Airflow task queues could be saturated, leading to cascading delays that persist long after mitigation starts.
Instead of adding code-level rate limiting to your ingest endpoint, which introduces complexity, consider an architectural stopgap. Configure your load balancer or cloud endpoint (if you're on GCP) with a very conservative connection limit for the specific ports mentioned in the BlackNurse reports. This is a network-layer policy you can deploy and remove quickly without touching your application code, and it operates independently of Prolexic's IP-based logic. Just document the threshold clearly so your data engineering team knows it might slow high-volume batch jobs during an attack.
You mentioned checking for a "signature version" timeline. That doesn't exist publicly. Prolexic's updates are pushed as dynamic configurations, not versioned signatures. Your best indicator is the Security Events log in the portal, but for proactive monitoring, set an alert on a sustained increase in packets-per-second from unexpected geographical sources, even if they're being mitigated. That's often the precursor signal their SOC uses to trigger a manual review.
> "I tried checking the Akamai portal/API for any bulletins or update logs but couldn't find a clear 'signature version' or timeline."
That's because Prolexic's signature management is intentionally opaque to customers. The portal exposes a "mitigation status" dashboard and raw event logs, but not a versioned changelog of the rule set. You can infer updates by watching the `rule_id` field on individual mitigation events, but correlating that to a botnet name requires a support ticket or reading their SOC advisory emails (which you should subscribe to if you haven't already). The API does offer a `/network-lists` endpoint for custom lists, but not a global signature version.
On the rate-limiting question: I'd caution against adding application-level throttling in the ingest API itself for this exact reason user370 mentioned with NAT'd traffic. Your Airflow workers connecting from a fixed set of VMs could easily get caught. Instead, consider a GCP Cloud Armor policy applied to the HTTPS load balancer fronting your endpoint. Set a "rate-limit" rule with an enforce-on-key of `X-Forwarded-For` and a threshold that's 2x your peak legitimate throughput per IP. That buys you a safety net without touching your code.
One additional signal to monitor: if you're using Prolexic's "always-on" mode (vs on-demand), check the `bypass_volume` metric in their reports. A sudden drop in visited traffic combined with a flat line on dropped packets often indicates they've started blocking at a lower rate and haven't tuned the threshold yet. That's your window to escalate proactively.
I'm curious whether you've seen the CVE or vendor advisory for this yet, or is it still speculative? That usually drives their SOC SLA
That's a really good question. I'm in a similar boat with our reporting API, and I hadn't even thought about the data pipeline angle.
When you say > short-term rate-limiting in our own code as a fallback, I'm worried about that too. If our app logic starts rejecting requests because we hit our own limit, won't that just look like a failed job to Airflow? Then we'd still have to manually clear the queue or retry everything later. Feels like it could create more operational headaches.
Do you know which ports the article mentioned for BlackNurse? I want to check if ours are exposed.
I hadn't thought about the Airflow retry problem either. If the endpoint fails fast due to your own code limit, you're right, you'd just get a pile of failed tasks.
The port question is key. I can't find the original article now. Does anyone have a link? I saw it mentioned targeting specific services, not just random high ports.
Since you're on GCP, would something like Cloud Armor be a better stopgap than touching the app code? You could set a rule and turn it off later.
Exactly, that Airflow retry headache is a real concern. I'd look at your task's retry policy and error handling first, as a backstop.
The ports I saw were 19 (CHARGEN) and UDP 161 (SNMP). It's a weird combo, but worth a quick audit.
Since you're also on GCP, Cloud Armor is a solid idea for a network-layer rule without touching code. You can set a quick-and-dirty rule on those ports and nuke it once Prolexic catches up.
dk