Somewhere on a hosting provider's /24, a scanner is working through port 22. It fails on one address, moves to the next in the block, fails again, and keeps walking. Every server it touches that has fail2ban configured with an automated reporting action fires off an abuse report. By evening, the operator's abuse desk holds a few hundred near-identical emails about the same box, each a slightly reworded "SSH brute force from your network."
Nobody reads them. Not because the abuse team is lazy, but because there's nothing left to read. Three hundred reports of one event carry about as much information as one report, and take three hundred times longer to get through.
Automated reporting didn't make that IP more likely to get actioned. It made every report about it less likely to.
That's the whole argument. Reporting abuse is worth doing. The way most of us do it now, on autopilot and at volume, is quietly making it worse.
Reporting got free, and free things get flooded
It used to take effort to report an abusive IP. You noticed the pattern in your logs, found the network's abuse contact, wrote the email, attached the evidence, and sent it. That friction was doing more work than anyone gave it credit for. It meant the reports that went out were the ones a person had decided were worth sending.
Then reporting became a line of config.
# Illustrative: add Fail2Ban's built-in complaint action to the normal ban action.
# This also requires its documented dependencies and a working mail setup.
action = %(known/action)s
complain[logpath="%(sshd_log)s"]
fail2ban, CrowdSec, honeypots, and mail feedback loops all turned "report this" into a background job that runs thousands of times a day with no human in the loop. High-volume automated reporting became easy. The amount of signal in each report did not necessarily improve.
This is the pattern behind every system that gets cheaper to use faster than it gets smarter. When the marginal cost of sending drops to zero, quantity stops tracking importance. Email spam works this way. So does the notification tray on your phone. Abuse reporting is now in the same bucket, and we got here with good intentions and a cron job.
Volume is not the same as signal
Here's the part that's easy to miss when your dashboard shows a satisfying count of reports sent. The receiving end is either a human with a finite number of hours, or an automated reputation system that's only as good as what you feed it. Both get worse under a firehose.
Think about what a lazy automated report actually contains. An IP. A timestamp in whatever timezone the reporting server happens to run in. A one-line reason like "brute force," and often no evidence at all. Sometimes it contains the reporter's own IP or email, pasted into a comment field by accident. Multiply that by every install reporting the same scanner, and the operator isn't reading intelligence. They're reading log exhaust.
You don't have to take my word for it. Look at what one of the best-known abuse-reporting databases had to build to cope. AbuseIPDB asks you to report a continuing attacker roughly once per day, not once per attempt. The same account cannot report the same IP more than once every 15 minutes, and if the same IP is reported again within 24 hours with the same comment, AbuseIPDB updates the original report's timestamp instead of creating another one. It tells reporters to limit comments to the key information about the abuse and warns against putting personal information into those comments. Its API also enforces rate limits with 429 Too Many Requests.
Those rules aren't decoration. They're scar tissue. Each one exists because undisciplined reporting was degrading the database, and the fix was to make reporters slow down and clean up. When the platform built to absorb abuse reports has to defend itself against abuse reports, the practice has a quality problem, not a volume shortage.
The people doing the reporting suspect it too. Search the sysadmin forums and the same question keeps turning up: is there any point to reporting an abusive IP at all? That doesn't come from people who don't care. It comes from people who've been firing reports into a void and noticed nothing changed.
The strongest case against me
There's a real argument on the other side, and it deserves a fair hearing.
More data beats less data. A reputation system that sees one IP reported by five hundred independent networks has stronger evidence than one that sees it once, even if most of those reports are sloppy. Deduplication and scoring exist precisely to turn noisy inputs into a usable signal, and they mostly work. Reporting, even imperfect reporting, raises the cost of running an attack, because a burned IP is a burned IP. Blocklists built from exactly this kind of crowdsourced volume do block a great deal of bad traffic.
All of that is true, and none of it rescues the specific failures. Dedup collapses the count, but it can't reconstruct evidence a report never carried. Scoring is only as good as its inputs, and a flood of context-free reports drags the average toward noise: a confidence number built on five hundred reports that all say "brute force" with no detail is a number about popularity, not about what the IP did. And the thing volume genuinely can't fix is the human desk. An operator who could have suspended a customer off one clear, actionable report instead closes the ticket, because the one good report is buried under three hundred that say nothing.
So the counter-argument mostly holds for the reputation databases and falls apart for the operators who can actually stop the abuser. That split is the point.
Report less, report better
The fix isn't to stop reporting. It's to treat a report as a message to a stranger who's short on time, and act like it.
Throttle. Report a continuing attacker once per source per day, not once per packet. Whatever your tool fires on, put a window in front of it.
Deduplicate by incident and abuse destination, not blindly by individual IP. If several addresses in the same network are performing the same behavior in the same time window and resolve to the same abuse desk, combine them into one report with the relevant IPs and evidence. Don't automatically collapse an entire routed prefix into one incident, though: the same network can contain different customers and unrelated abusive hosts.
Make it actionable in ten seconds. The offending IP, a UTC timestamp, what it did, the destination or affected system when that helps identify the event, and a few lines of real log. That's the core of the report. Leave out the opinions, threats, and unrelated personal information. If you're posting to a public reputation database, strip your own IP, email, and other PII from comments unless the service explicitly requires it. One report a human can act on immediately beats a hundred they have to decode.
Send it to the operator, not the void. The contact you want is the network operator responsible for the IP, not the registry and not the abuser. ABUSE has been a standardized network-operations mailbox name since RFC 2142 in 1997, although the actual abuse address for an IP may be a different contact registered with the relevant RIR. Resolving it yourself means using registry-aware WHOIS or RDAP data and handling the differences between registries. Or you can skip that plumbing: a single abuse-contact lookup returns the responsible abuse contact and network information directly.
Escalate only when it's earned. If the operator ignores a clean report, an upstream provider, hosting reseller, or relevant blocklist may be a reasonable next move depending on the incident. If the registered abuse contact itself is missing or invalid, raise that contact-data problem with the relevant RIR. Don't treat the RIR as an escalation desk simply because a valid abuse contact chose not to respond. Leading with the blocklist because it's the easiest button is how the noise started.
None of this is hard. It's just less than what your tooling does by default, and that's exactly the point.
What you're actually spending
The internet's abuse handling runs on two things you spend every time you hit send: a volunteer's attention, and the shared reputation data everyone downstream depends on. Both are finite, and a lazy report spends them for nothing. If you're going to automate reporting, and you should, automate the throttling and the formatting and the routing along with it. Otherwise you're not fighting the spam. You're just more of it.
Top comments (0)