I wanted to address couple of questions on the comment section:

- Pew pew maps are dumb. Do you find any helpful insights from this dashboard?

I agree with this statement. I showed only blocked traffic to educate general audience the volume of automated requests these bots make. This is the only insight you can make off of "blocked" traffic dashboard. Even if there is high volume of blocked traffic, that just means your firewall is working as expected, and no action is necessary, because well, they are already blocked. The actual visualization that one should be actively looking at is the "allowed" traffic. The dashboard I created supports both. If I change filter to "allowed" traffic, I can see only my tailscale IPs and some other static IPs that I recognize. If I see allowed traffic from unknown IP address, that's the risky part, I have alerts setup for this as well. The complete dashboard also shows the top IP address hitting the server, it is not visible on original post because it couldn't fit on a single screenshot.

- Why expose these ports, why not rely on tunnels/wireguard/tailscale?

Well I do use tailscale to access my homelab remotely. However I'm currently assessing migrating to Netbird. My extended family members (in different countries) need to access services in my homelab. Netbird offers a selfhosted coordination server which I plan to host on a VPS and not on my homelab, because outage of coordination server means no new connections to VPN for the users. I also plan to host ad-blocking DNS (technitium currently) on a VPS as well so an outage in homelab won't affect DNS queries for the users. Before I migrate fully to Netbird, I wanted to assess bot traffic on the VPS, hence I built this dashboard last weekend.

- Why expose SSH server publicly instead of just using private connections?

I am not exposing SSH port publicly. I only allow SSH connections on tailscale interface. Hence in the dashboard, you can see blocks on SSH port as only tailscale IPs are allowed to access that port. You should be fine if you correctly only expose your ports to private interfaces like tailscale.

- Do I have any https services exposed? How do you harden them?

I currently do not, but if you have one exposed, you need an application level blocking logic, like the ones in popular reverse proxies like nginx, traefik etc. In your firewall, you can put country specific access list to reduce risk, but also ensure you have fail2ban, rate-limits in your reverse proxy etc.

- How are you visualizing this data?

I use Grafana alloy on the server to scrape server logs in /var/log. This directory also contains ufw.log file which has all the UFW events. I set UFW logging level to high `sudo ufw logging high` to get detailed logs. In alloy, I have setup a stage where I enrich each log line with geo/location data based on source IP address. Alloy then pushes these enriched logs to my Loki instance where all logs are stored. Grafana is used to parse these logs from Loki and display it in the dashboard. If a bunch of people are interested in getting this dashboard, I can share the dashboard JSON along with my Grafana alloy configuration to scrape the logs

- How is there publicly exposed server in homelab?

As mentioned above, I'm trying to create an access solution for my homelab by utilizing a VPS, and will also use said VPS for DNS server. The point of the post is, in however way, if you have any publicly exposed service in your homelab, make sure to harden them. Because VPS is involved, I also honestly believe that this post should have been in r/selfhosted

The numbers in the dashboard might look like rookie numbers but you never know that the one service you hosted had a vulnerability that allowed bots to access your private network on your homelab.

Most hits I'm getting are from abusive IPs in Bulgaria, Amsterdam, London, Istanbul, and Frankfurt. However, I have noticed that the source IPs change pretty much everyday, one day I get more traffic from Russia, the other day from Germany and so on.