How to get the whole planet to send abuse complaints to your best friends

Original Article ↗ Hacker News Discussion ↗

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.