daniskarma

I have many services that doesn’t “need” to be public, as public facing for one specific reason. TLS.

A lot of the times android apps won’t connect to http directions, not even local ones, and require a proper https connection with a well known CA.

For that I put the services behind a caddy reverse proxy to get a valid tls certificate.

And them I do the trick, and basically on caddy reject all connection that’s not local. Thus, making the supposedly “public” site a practical “local” one.

Once there I just connect through wireguard.

I have that but with caddy.

On the caddyfile you can put to only serve the site to certain IPs and reject the others with any status normally 403 or 404.

Attackers probe the site, but all they get it’s a connection error.

When they have good names they get stolen.

Try took up about gemini protocol.

It’s great for solo roleplaying.

I mean. Not great. But it’s something you can interact with in a way that’s not possible without other people. So that’s something.

I think Pixelfed can sit nicely behind a reverse proxy, to reduce exposure.

I don’t know if there are prebuilt scenarios for pixelfed in crowdsec or fail2ban but it shouldn’t be so hard to at least write something to prevent bruteforce.

I’m in the process of building a monitoring system with grafana stack.

Right now I have monitoring panels for some common metrics and logs. I am yet to set up alerts.

The idea being that if something goes wrong some metric will grow up unexpectedly, for instance network traffic. And I would get a notification.

What I’m still considering is what would I consider abnormal behavior, so I could set up the thresholds.

What do you want to expose, something static or dynamic?

It would be a service you wrote or some stablish project?

I would recommend running whichever service you want to expose through a reverse proxy, traefik or caddy. That way you have some sort of “chocking point” where you can control what’s going and it’s already handling some security for you.

The service should be kept updated.

Then you need a ips (intrusion prevention system). Most famous are fail2ban or crowdsec. You feed the ips the service logs and the reverse proxy logs, and ban ips that try to do something strange. I use crowdsec with a bunch of scenarios and their block lists.

At the end you should only have a couple of ports open to the internet. Usually 80 and 443, and whichever port you use for the vpn, i recommend wireguard. So people should only connect to you via 80 or 443 and those ports should be binded to the reverse proxy. Everything else should never be able to enter your network.

If you have all that and keep everything updated the attack surface becomes really small. You’ll get spam bots trying to probe for vulnerabilities but if you keep everything updated they won’t find anything.

Depending on how many people you want to access your service you could also do some aggressive geoblocking, to reduce the number of bot attacks.

The biggest risk here would be a vulnerability on the reverse proxy or the service you use. Keep an eye out for cve and update things regularly. If a vulnerability allows for remote code execution, then mitigation becomes almost impossible besides a good backup plan. If your vpn fails on you you are also fucked. But wireguard is pretty well secured. Bot scans shouldn’t even be able to know you have wg because pings and connections attempts fail silently without proper authentication.