Precog bouncer. Asigned to the daemon of future cybercrimes. Obviously.

I’m using it. It’s good. Even without the cloud services the bouncer and scenarios are more powerful than fail2ban.

Shame about no self hosted web ui but someone posted here a project I’m ought to look up oncw I arrive home.

Also it’s again the false sense of security pf “if you don’t use vibed apps you’ll be fine”, making people forget basic security procedures.

I, for instance, had a service vulnerable and discontinued without noticing for months. It was something 100% made before LLM was a thing. Still had unpatched vulnerabilities and the project was abandoned. It was my fault for not checking more often is the services I host are safe or not.

It looks like good prices. But every single one is out of stock

Yeah, mostly for translation purposes.

I think I currently have gemma 4 set up.

I feel it’s a little dangerous, because it would give a false sense of security in [no-ai] projects.

We have all seen tons of projects 100% written without any AI that are very poorly coded and full of insecurities.

deleted by creator

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 any 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.

I don’t think you have a usecase for Anubis.

Anubis is mainly aimed against bad AI scrappers and some ddos mitigation if you have a heavy service.

You are getting hit exactly the same, anubis doesn’t put up a block list or anything. It just put itself in front of the service. The load on your server and the risk you take it’s very similar anubis or not anubis here. Most bots are not AI scrappers they are just proving. So the hit on your server is the same.

What you want is to properly set up fail2ban or, even better, crowdsec. That would actually block and ban bots that try to prove your server.

If you are just self-hosting with Anubis the only thing you are doing is deriving the log noise towards Anubis logs and making your devices do a PoW every once in a while when you want to use your services.

Being honest I don’t know what you are self hosting. But at least it’s something that’s going to get ddos or AI scrapped, there’s not much point with Anubis.

Also Anubis is not a substitute for fail2ban or crowdsec. You need something to detect and ban brute force attacks. If not the attacker would only need to execute the anubis challenge get the token for the week and then they are free to attack your services as they like.

I have it on docker with two volumes, ./config and ./cache

I back up those before each update.

A bad Jellyfin update should not mess with your media folder in anyway. Though you should have backups of those aswell as a rule of thumb.

I’ve been using jellyfin for years.

My best recommendation is DELAY UPDATES and back up before you update.

I have a history of updates breaking everything so you should be careful about them.

All software recommends backing up before an update, but for jellyfin the shit is real, you really want to back up.