Visualizing malicious IP addresses

Original Article ↗ Hacker News Discussion ↗

Malicious SSH login attempts turn out to be a constant background noise for any internet-exposed server, largely driven by botnets and compromised IoT devices scattered across high-connectivity regions like China, India, the US, and parts of Europe. Commenters debate the value of defenses such as changing default ports, fail2ban, port knocking, VPNs/Tailscale, and SSH tarpits, while emphasizing fundamentals like key-only authentication, strict firewalling, and IP whitelisting. Many note that geolocated “attacker” IPs rarely indicate where human operators actually are, instead reflecting where poorly secured devices and major hosting providers are concentrated.

Attack Patterns and Sources

  • Many commenters report constant SSH login attempts on any public server, especially on port 22, sometimes tens of thousands of tries per IP even when password auth is disabled.
  • Specific Chinese IP ranges (e.g., ChinaNet Jiangsu, Tencent ASN) are widely recognized as heavy SSH brute-force sources; similar patterns are seen from other big Asian ISPs and popular cloud providers.
  • Several note that the map likely reflects where compromised IoT devices, DVRs, and cheap routers live, not where human “attackers” reside.
  • Geographic concentration is linked to population size, internet penetration, and major infrastructure hubs (e.g., Frankfurt / DE-CIX), not just “bad actors.”
  • Russia’s apparent absence is attributed to attackers tunneling through friendlier jurisdictions or botnets.

SSH Hardening and Access Models

  • Common advice: disable root and password logins, use SSH keys only, and optionally move SSH to a high, non-default port to cut noise.
  • Fail2ban is widely used; some see it as essential, others call it unnecessary complexity given key-only auth.
  • Port knocking and single-packet authentication divide opinions: some find them effective; others argue they’re fragile, easy to misconfigure, and redundant compared to VPN/IPsec.
  • Alternatives include: restricting SSH to known IP ranges, using VPS/cloud firewalls and APIs to open access dynamically, using VPNs (including Tailscale), and leveraging IPv6 with tight /32 or random /64 addressing.

Tarpits and Honeypots

  • SSH tarpits that slowly send banners to keep connections open are described; they seem to tie up bot connections for a while and provide satisfaction, though some doubt they still meaningfully impact attackers.

Legality and Ethics of Scanning

  • Disagreement over whether mass SSH login attempts are illegal: some compare it to walking into an unlocked house; others stress that intent and local law (e.g., UK/US computer-misuse statutes) matter, and enforcement is rare.

Tools, Visualization, and Data Handling

  • Suggestions include using Looker Studio, IPinfo tools/CLI, MaxMind or local GeoIP databases instead of per-IP network lookups.
  • Several mention similar homegrown dashboards, graph/embedding-based analysis, and that modern logging stacks can already produce such maps.

User Reactions and Best Practices

  • New admins are often shocked by the volume of hostile traffic.
  • Consensus: robust credentials and proper SSH configuration make brute-force attacks “background noise,” but further hardening mitigates software 0-days and log/CPU abuse.