Fair enough. It’s a device small enough to keep on your body or close by, so physical security isn’t too big a worry I guess. Just be aware that if somebody does get access to it, they could just pop the microsd card out, write malware to unencrypted partitions, and extradite your sensitive documents once you unlock the LUKS partition. These are the kinds of “evil maid” attacks that secure boot and verified boot were meant to protect against, but unfortunately most SMBCs don’t have those capabilites (only ones I’m aware of that do, are RPi5 and most x86 SMBCS).

As for the firewall, could you use a VPN or tailscale to access your services? Then you could just point the DNS to your private IP. The services would be completely secure from the outside and you wouldn’t have to use a firewall.

Well I’m not trying to start a community around helping people, I’m just a participator. If I wanted to maximize the number of people I could help, I might move back to reddit

edit: a word

Hows the security? I’m guessing no encryption since it’s rather pointless without secure boot or verified boot.

Those saying “just self-host Matrix/Stoat/XMPP”, do not understand the power of network effects. If people are too lazy to sign up on your custom server, and you end up with 50% of the users you would have gotten if you used Discord, is that worth it? What if it was only 10%?

I wish there were a solution to this. Interoperability sounds nice until you have multiple competing standards (like Matrix and XMPP)

Got it. Access to docker.sock is definitely something to be wary of, or CAP_ADMIN, or access to certain host devices.

Worth mentioning though that Jellyfin usually has none of these.

With that setup, an attacker could mount the host filesystem to the container and would own the host from that container.

Can you elaborate more on this? Assuming an attacker is in the Jellyfin container with full remote code execution, how could they mount the host filesystem?

Instead of caddy -> auth OIDC -> services, can you do auth OIDC -> caddy -> services? That way you can put the auth OIDC in the DMZ VM, while putting caddy in the other VM with all the services? Alternatively maybe caddy (DMZ) -> auth OIDC (DMZ) -> caddy (LAN) -> services (LAN)

If you can’t, you can always use firewalls on the services VM to prevent services from talking to each other. Preventing them from talking to the internet can be achieved by putting them in an “internal” network (if using docker compose, set “internal: true” when defining the network)

I’m not sure I understand. First off I’m not the same person as GP. Second, the admins are proposing an AI tag, which I’m supportive of. I’m just saying that I am OK with AI-assisted projects being posted to this community (with the AI tag of course)

Fine, but others including myself want that slop as far away from here as possible

And there are people like me who are fine with moderate AI use and would rather judge the project themselves rather than have them rejected outright.

Maybe there should be a community poll

If I have a bare metal dedicated server, which has only access to IPs contained in my whitelist on a dedicated opnsense, I have less to wory about.

Sure, someone could still find a openbsd/opnsense exploit and get me, but my point is: complex systems break in complex ways, the more complex systems you use, the more attack surface u have, need to know and understand to control and mitigate it.

The way I would frame it is: using complex systems that you are unfamiliar with is risky. In your case, you are familiar with OPNsense and firewalls. So that may be the more secure option for you. But for somebody who isn’t familiar with firewalls, there are a lot of ways to mess up. For example, IP and mac spoofing is very easy. OPNsense and firewalls often don’t have very good defense against IP spoofing, especially if the malware is already inside your LAN (for example, a malicious app running on a smartphone).

Using proxmox and other virtualization platforms has one big advantage: you can experiment and play around and learn, without much risk. With a physical server, if you mess up and get infected, you may have to throw away the whole server. You can’t just re-install the OS, because the malware could have installed a rootkit or infected the bios or other firmware. But with a VM, if the VM gets infected you can just delete the VM and create a new one. One of the main goals of a hypervisor is to sandbox the VM, so that malware is contained.

“best” is of course subjective. Bare metal could be better, but imo the marginally smaller attack surface isn’t worth it. If the Qubes project trusts that a hypervisor is secure enough, then I trust it as well.

I run 10+ VMs all the time, no way am I going to buy 10 bare metal servers. The ability to create new secure environments on-demand is unbeatable.

And bare metal does have security disadvantages too. It has a physical attack surface that a VM does not. For example, defending against usb attacks. Of course for a VM, the hypervisor/host can be attacked physically, but you only need to worry about securing that one. Securing 10 physical servers is a lot more work than securing just one, so you’re more likely to get lazy, slip up, etc.

Moonlight/sunshine can be used for remote desktop, and doesn’t have many controversies that I can remember, far less than Rustdesk at least. You just don’t get the free relay servers, which some might call a plus.

Don’t get me wrong, I personally still consider Rustdesk a viable alternative, I just think the controversies are recent enough and concerning enough that they should be brought up for consideration.

As for the forgive/forget bit, don’t mind it that was just me poking at Lemmy’s hypocrisy a bit

Rustdesk did have some massive controversies in the past, like:

• installing root certificates without fully understanding the implications
• ignoring AGPL for their proprietary bits
• and other questionable decisions

Which raises doubts as to how trustworthy the development team is.

And while some other people say “it’s ok that was in the past they fixed it”, keep in mind that most of Brave Browser’s controversies were in the past, and yet lemmy still hasn’t forgiven them yet…so I’d like to know how long it takes for lemmy to forgive past mistakes

deleted by creator

You’re not wrong but when you use somebody else’s config you use somebody else’s…configuration. Like if they use ProtonVPN, you’ll need to use ProtonVPN as well. If they use Usenet instead of torrents, that’s what you’ll get as well. If somebody uses Podman instead of Docker, etc etc. So this is why it can be more difficult than just ripping configs from strangers.

This is the classic problem where the more flexibility a program has, the more fragmentation comes out of it. The *arr stack is complicated for this reason. It’s a million different pieces that can be configured in a million different ways. Something like Nextcloud is much more plug-and-play. I’ve been doing self-hosting for years now and even I find *arr a chore to deal with.

Though nothing wrong with referencing other people’s configs to get a sense of what it’s supposed to look like. Start simple, look for somebody who has a radarr + qbittorrent + gluetun stack working, and go from there.

Nobody believes virtualization is perfect, it’s just the best we got because:

• smaller attack surface
• security is the priority over adding new features (the opposite of most other development cycles)
• in practice we have seen how secure it is relative to other systems like the kernel

And anyways, even a separate physical computer can be hacked. If it has networking, there could be a vulnerability in the networking stack. Just making an outbound tcp connection can be enough to be pwned.

I think the closest thing we have to an “invincible” system is seL4, but I rarely hear about amybody using them

copy fail allows VMs to infect the host system? I thought it was a kernel vulnerability, not a hypervisor vulnerability. Containers and LXCs share the kernel with the host, full VMs do not. So a kernel exploit allows container escape but not VM escape.

Kernel exploits happen a few times a year. Hypervisor exploits and VM escapes are VERY rare.

Using SSH for clustering is optional. You can just use normal VMs. You don’t have to install SSH into the VM, you can view it through proxmox. The only difference between a VM and a separate physical machine is the hypervisor, so the only security difference is the security of the hypervisor. And as I mentioned, hypervisor exploits are very rare.

Edit: for a sense of perspective, think about this. Almost every major tech company in the world relies on hypervisors for security. Qubes OS, known in the privacy/security world as one of if not the most secure OSes, relies on the hypervisor for security. An easily exploitable hypervisor escape would be a vulnerability on the scale of the XZ utils backdoor (which was unsuccessful). I have not seen a vulnerability of that scale since heartbleed.

Edit2: a word

I recommend proxmox. One VM for sensitive private data and backups, one VM for stuff exposed to the internet

Depending on the number of devices you have, your threat model, it can be helpful to set up a security hierarchy. So you only need to worry about securing the devices at the top of the hierarchy, and can play loose and careless with the devices lower down. That way it’s less likely to lose everything due to one mistake

Even if you have a password for your ssh key, malware on your system can just wait until you enter the password.

My point is that SSH access is very powerful, and effectively means that the security of the SSH server is reduced to the security of the SSH client. If your SSH client is pwned, so is your server. If you have 10 devices each with ssh access to each other, then if any one device is pwned, all devices are pwned as well.

This is not the case for systems designed for file sharing only. For example with syncthing, if one device gets pwned, all it can do is send files to the other devices.