daniskarma
@daniskarma@lemmy.dbzer0.com
- Comment on Most slopcode projects are abandoned and deleted within months of release 5 days ago:
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.
- Comment on Storage?! In this economy!? 1 week ago:
It looks like good prices. But every single one is out of stock
- Comment on Security considerations about hosting Immich from home 4 weeks ago:
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.
- Comment on Security considerations about hosting Immich from home 4 weeks ago:
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.
- Comment on Continuwuity 5 weeks ago:
When they have good names they get stolen.
Try took up about gemini protocol.
- Comment on PewDiePie releases Codex/ClaudeCode/Cursor killer, Odysseous (FOSS) 5 weeks ago:
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.
- Comment on The first publicly open instance 1 month ago:
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.
- Comment on Internal network monitoring 1 month ago:
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.
- Comment on The first publicly open instance 1 month ago:
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.