How to get the whole planet to send abuse complaints to your best friends
Abuse-report systems on the internet can be weaponized by attackers who spoof IP addresses, making innocent servers appear to be scanning or attacking others. Commenters describe how automated complaints, often triggered by trivial or easily spoofed traffic like single SYN packets to SSH, can lead to service suspensions, disproportionate responses, and headaches for operators of services like Tor relays. The thread highlights long-known but still-unfixed issues such as inadequate source-address filtering (BCP38), the difficulty of proving “it wasn’t me,” and the tension between preserving an open, low-friction internet and imposing stricter identity and trust requirements on network operators.
Nature of the spoofing / Tor context
- Attack uses spoofed SYN packets to make honeypots and scanners send abuse reports to unrelated Tor relay operators.
- Some think targeting Tor specifically is plausible (e.g., to increase relative share of malicious relays), others see it as generic trolling or abuse of reporting systems.
- Tor relay IPs are easy to enumerate via the public consensus; so are obvious targets.
Abuse reports and the “prove a negative” problem
- Many report that the standard response “it’s spoofed; my host isn’t attacking you” sounds identical whether you’re innocent or guilty.
- Providers often automate “respond or be suspended” workflows, sometimes taking servers offline on obviously impossible claims (e.g., traffic above physical link capacity).
- Some suggest stronger real‑world identity attestation (notaries, video calls), but others push back that this is costly, privacy‑hostile, and especially problematic for Tor operators.
What constitutes abuse (SYNs, scans, DoS)
- Strong disagreement on whether single SYNs or basic port scans are “abuse.”
- One side: port scans and lone SYNs are standard background noise; only DoS‑level traffic should trigger action.
- Other side: recon is the first step in attacks, so blocking or banning scanners is justified.
- Several note that automatic “ban on first SYN to SSH” rules quickly break legitimate services because of spoofed traffic.
ISP responsibilities, BCP38, and logging
- Thread repeatedly cites BCP38 (source address validation) as the real fix: last‑mile ISPs should block packets with spoofed source IPs.
- Debate over feasibility and incentives: most agree it’s technically simple at the edge but hard to enforce globally, especially for large or foreign networks.
- Some argue large providers could collectively refuse traffic from non‑compliant ASes; others doubt operators care enough.
- Disagreement on how much traffic metadata (e.g., NetFlow) ISPs should log to verify abuse claims vs cost and privacy concerns.
Internet design, policy, and trade‑offs
- One camp favors stronger liability and filtering responsibilities for ISPs; another warns this leads to a permissioned, tightly controlled internet.
- Several note the net’s robustness comes from tolerating some “brokenness,” and over‑optimizing for security could centralize power and harm openness.