Following the Mafiaboy attacks, I have had a week of conversations with people who run small and mid-sized ISPs. The mood is different from any conversation I have had on this topic before. The phrase that keeps coming up is "we now have to do something". The follow-up question — "do what exactly?" — is the one this post is for.
If you are an ISP operations team that has just been told the ISP must respond to the new threat landscape, here is the checklist. In rough order of impact-per-effort.
1. Source-address validation at the edge
BCP 38. Egress filtering. The single highest-impact thing an ISP can do.
For every customer-facing interface, configure the router to drop packets whose source address does not belong to that customer's allocated range. The configuration is one access-control list per interface. The cost in CPU is essentially zero. The customer-facing impact is essentially zero — well-behaved customers never send packets with wrong source addresses anyway.
If every operator did this, source-spoofed denial-of-service attacks would become structurally impossible. They would be replaced by attacks using real (compromised-host) addresses, which are easier to filter at the receiver. The threat landscape would meaningfully shift.
We have been recommending this for over two years. The reasons it has not happened are organisational, not technical. The recommendation is now to do it this quarter, not to plan for it.
2. Outbound flood detection at the customer level
Most ISPs already have traffic-shaping infrastructure for QoS purposes. Use it for security. Watch outbound traffic per customer; alert on customers whose outbound rate suddenly spikes.
A cable-modem user who normally generates 50 kbit/s of outbound traffic and is suddenly generating 500 kbit/s of outbound traffic for ten minutes is, almost certainly, a compromised host being used as a flood source. The ISP can identify this in near-real-time with simple monitoring.
The response can be:
- Automated: throttle the customer's outbound rate to a sensible cap until investigated.
- Manual: page an operator to look at it.
- Intermediate: send the customer an automated email and apply soft throttling that can be lifted on request.
The specific response matters less than having a response. Today most ISPs have no visibility into per-customer outbound anomalies. The cost of building this is modest; the benefit is substantial.
3. Honeypots on customer-facing ranges
An ISP has thousands of unallocated IPs in their customer ranges. Putting a honeypot on a small selection of these — say, 10 per /24 — gives the ISP an immediate signal whenever a host on their own network starts scanning. The scanner hits the honeypot; the honeypot logs the scan; the ISP knows which of their own customers is now compromised.
This is a warning system for compromised customer hosts. The compromised hosts will eventually be used in attacks; catching them at the scan-and-recruit stage gives time to remediate before they become problems. This is not a hypothetical idea — academic researchers have been running variations of this for years. The operational deployment at ISP scale is the gap.
4. Customer-side filtering, optional but encouraged
Many ISPs offer their customers a basic firewall service — block inbound traffic to common service ports, leave the customer free to make outbound connections. This protects customers from being scanned and exploited, which prevents them from becoming part of the next attack pool.
Making this an opt-out service rather than opt-in would have a substantial defensive effect. Most home users do not need inbound traffic to their machine. The ones who do (running their own services) can opt out.
The operational difficulty is configuring per-customer firewalls. Modern access concentrators can do this; older ones cannot without significant effort. The investment pays back over time as the customer compromise rate drops.
5. Coordinated incident-response capability
When an attack hits, the target ISP needs to talk to the attacking ISP fast. Today this is phone calls between operators who happen to know each other. The capability to build:
- A canonical list of every ISP's NOC contact (phone number, email, escalation path).
- An authenticated communication channel for sharing attack details. Not encrypted email; not a public forum; some kind of mutually-trusted real-time channel.
- Standardised reporting formats for attack data, so that the receiving ISP can act on the information quickly.
- Mutual filtering agreements: ISP A asks ISP B to apply emergency filters; ISP B does so on a known SLA.
None of this exists at internet-wide scale. Some of it exists informally between large carriers. The next step is to formalise and broaden it.
6. Subscriber-line filtering on outbound port 25
A growing fraction of compromised home hosts are used as spam relays. Their owners do not know; the ISP does not see it because it is just "outbound port 25 traffic".
Filtering subscriber-line outbound port 25, except to the ISP's own mail server, is operationally cheap and dramatically reduces spam-relay capacity. Subscribers who legitimately run their own mail server can be exempted on request — the request itself filters the population to the small fraction who actually need it.
Several ISPs have started doing this. The operational support burden is non-zero but manageable. The contribution to the broader internet's spam volume reduction is significant.
7. Logging and retention discipline
When an attack hits, investigation depends on logs. Many ISPs do not retain enough logs to investigate something that happened a week ago. The operational disciplines:
- NetFlow records on all customer interfaces, retained for a minimum of 30 days.
- DHCP lease records correlating IP to MAC and customer, retained as required by law.
- Customer authentication records.
- Border router logs of dropped traffic, retained for at least 7 days.
The storage cost is modest. The benefit is the ability to actually answer the questions an investigation needs to answer.
8. Customer education
The least technical of these but in some ways the highest-leverage. Most home users have no idea their host is compromised. The ISP is in a position to:
- Notify customers when a compromise is detected.
- Provide cleanup tools and instructions.
- Educate customers proactively about basic measures (anti-virus, software updates, password hygiene).
- Make compromise easier to report from the customer side, so neighbours can flag suspicious activity.
This is unglamorous work. It also reduces the compromised-host pool, which is the only structural lever an ISP has against the long-tail population of attackers.
What an ISP should not do
A few things that come up regularly and which I think are misguided.
Inbound filtering of common attack patterns. Tempting but problematic. Filtering at the perimeter helps the ISP's own infrastructure but does not help customers; in fact it can hide problems that customers should be aware of. Better: filter at customer edge (with their consent), not at ISP edge.
Unilateral disconnection without notification. Cutting off a compromised customer without warning is fast but burns goodwill and can disrupt legitimate services on the same line. A gradual response — alert, throttle, offer remediation, then disconnect if unresponsive — produces better outcomes.
Silent traffic redirection or modification. Some ISPs are tempted to silently redirect attack traffic to mitigation appliances. This works technically but creates trust problems and visibility issues. Be explicit about what is being filtered and why.
The economics
None of the above is free. The ISP that does all of this will pay measurable costs in capital expenditure, operational expenditure, and customer support burden. The question is who pays.
In the current arrangement, the ISP that does this work pays for it; the benefit accrues to the broader internet community. This is the same misalignment that has prevented adoption for years.
The Mafiaboy attacks have changed the conversation by making the commercial benefit visible. ISPs that fail to do this work will, eventually, be losing customers — both because end users will demand cleaner upstream infrastructure, and because business customers will require it as a condition of peering.
The transition will be uneven. Some ISPs will move quickly; some will not. The ones that do will, eventually, gain a reputational advantage that compounds.
For any operator at an ISP reading this — push for at least items 1, 2, and 6 in this quarter. They are technically straightforward, organisationally tractable, and represent the bulk of the available improvement at low cost. Items 3 through 5 are real projects but lower urgency. The rest are ongoing work for years.