What You Get After Running an SSH Honeypot for 30 Days

Original Article ↗ Hacker News Discussion ↗

Exposing SSH or web ports on an Internet‑facing server reliably attracts constant automated attacks within minutes, from brute‑force login attempts to scans for old PHP, WordPress and Apache vulnerabilities. Commenters trade strategies for making self‑hosting safer and less noisy — from disabling password logins, using SSH keys, VPNs, WireGuard/Tailscale, fail2ban and port knocking to Cloudflare tunnels, geoblocking and honeypots like Cowrie or endlessh. A recurring theme is that while no software can be perfectly secure, sensible hardening and defense‑in‑depth can make small personal or business servers reasonably safe despite the background radiation of global bot traffic.

Background Internet Noise and Attack Patterns

  • Many report that any exposed service (SSH, HTTP, SMTP) is probed within minutes; logs quickly fill with thousands of attempts.
  • Common HTTP noise: WordPress /wp-login.php and plugin exploits, old Apache/Nginx CGI paths, generic scrapers, and referrer spam.
  • SMTP servers see near-constant brute-force login attempts and relay abuse attempts.
  • SSH sees large-scale credential stuffing against root and common usernames, often from Chinese, Russian, and hosting-provider IP ranges, coordinated via botnets.

How Dangerous is Exposing Ports?

  • One camp: exposing 80/443 is “normal”; main risk is the web apps, not the web server, especially when serving static content with up‑to‑date nginx/Caddy.
  • Another camp is wary of any direct exposure, preferring VPNs, reverse tunnels (Cloudflare), or mesh VPNs (WireGuard/Tailscale), treating “no public port” as the safest default.
  • Some argue it’s fine to self-host if you patch diligently, understand your stack, and accept residual zero‑day and DoS risk.

SSH Hardening Practices and Debates

  • Widely recommended: disable password auth, use key-only logins, keep OpenSSH updated, and often move SSH off port 22 or behind VPN/port knocking.
  • Fail2ban and similar tools are polarizing:
    • Pro: reduces log noise and CPU use; blocks obvious brute forcers; helpful for juniors.
    • Con: offers little real security against modern, distributed attacks; can be DoS’d or misconfigured; seen by some as “security theater.”
  • Strong random passwords are considered technically safe, but less practical and more error‑prone than keys; bots tend to stop probing servers that refuse password auth.

Blocking and Filtering Strategies

  • Techniques include: IP blocklists, ASN- and country-level blocks, tarpits (e.g., endless SSH banners), and dedicated honeypots.
  • Supporters say broad geoblocking and blocking “internet scanners” significantly reduce unwanted traffic and protect limited resources.
  • Critics note collateral damage: CGNAT and VPNs mean you may block entire ISPs or countries, harming legitimate users and travel use cases.

Security Philosophy and Self‑Hosting

  • Ongoing argument: “no truly secure software” vs. “defense in depth can make systems robust enough.”
  • Some view widespread breaches as proof most software is insecure and emphasize isolation, monitoring, and not over-trusting any single layer.
  • Others warn against excessive paranoia, arguing that basic hardening and auto‑updates are sufficient for small personal/home servers.