Why I rate-limit every self-hosted service (and you should too)

The author emphasizes the importance of rate-limiting every self-hosted service to prevent various types of attacks. He learned this lesson the hard way, as an exposed instance of Jellyfin without rate-limiting became vulnerable to credential stuffing bots. To mitigate these threats, he uses fail2ban on all public-facing services, monitoring log files for failed login patterns and banning offending IP addresses at the firewall level.

The author outlines a generic fail2ban configuration for most services and provides specific jails for applications like Jellyfin, Vaultwarden, and Plex. For services that already have built-in brute-force protection, he layers fail2ban on top for additional security. He also uses Nginx to rate-limit login attempts at the reverse-proxy level, further limiting the number of requests from a single IP.

For services hosted behind Cloudflare, he takes advantage of the free tier's DDoS protection, bot management, and rate limiting rules to add another layer of defense. He logs ban events to a centralized Loki/Grafana setup and escalates the bantime or blocks entire IP ranges if needed.

The author acknowledges that rate-limiting does not protect against zero-day exploits, compromised credentials, or attacks via VPNs. To address these concerns, he recommends patching services quickly, using two-factor authentication (2FA) on all accounts, and considering VPN-only exposure's inherent risks.

Overall, the author argues that the cost of implementing these measures is minimal (around $0 and ~3 hours of one-time setup), while the benefits are significant. He concludes that following these five steps will make self-hosted services far safer than 95% of other homelabs.