Lol

Did you just add ‘blindly passing traffic’ to your statement? Did you read my comment about can help?

Move on, joker.

The selfhosted guys are correct with that. Of course its not a magic pill, but it can help to minimize the attack surface immensely with little effort.

Edit: while open ports can easily be enumerated, a reverse proxy often requires knowledge of the right server name. In tls1.3 those are not transferred in clear. Depending on your thread scenario you might want to consider doh/dot etc.

Reverse proxies can require client certs, which lift the security benefit to something like a vpn. Even basic auth adds a high threshold to attackers and is simple even for random users to work with. All this is functionality many services don’t offer natively - as they assume a reverse proxy anyway I guess.

Idle windows is so damn heavy on io :(

Didnt find any /s there. That’s one of the reasons why I dislike docker, it supports not understanding stuff. But then that’s just me, who wants to understand stuff. Enabling less tech savvy ppl is also great I guess.

I kind of lost interest when they found out that in a distributed system you can’t delete things

Just stumbled upon this: https://jellyfin.org/docs/general/post-install/networking/

Base URL

Running Jellyfin with a path (e.g. https://example.com/jellyfin) is supported.

caution Base URL is known to break HDHomeRun, the DLNA plugin, Sonarr, Radarr, and MrMC.

so: yes, it works. but most likely: no you don’t want this.

Clearly a problem on the VM. Run

dhclient -v ens18; for i in $(seq 60); do ip a s dev ens18; sleep 1; done

Just to see if its broken immediately or if another process probably fks it up later

Use dhclient -v to See the client side, check logs in the DHCP Server. Sniff maybe.

usually port knocking opens the relevant port to the client IP that is knocking. So it makes a lot of sense to have the knocking done by the requesting client. In many situations knocking from your mobile while behind the same NAT as your jellyfin client will do the trick, but if you have different IPv6 on those devices etc, it won’t.

Also: if you assume your DNS lookups are sniffed - so are your port knocks. If you don’t, spare the extra work. But then, if you like port knocking - keep knocking, nothing wrong about it :D

You telling me jellyfin Clients can’t handle client certs but can port knock?

My proposal is for maxing ux on the client side while being properly hidden.

If jellyfin Clients can do URLs, sure

Just posted on the top level, should have been here:

Random subdomain, wildcard cert

If client certificates and basic auth is not supported by jellyfin:

• reverse proxy
• strong random subdomain
• wildcard certificate
• tls1.3 only
• doh/dot only

1-3 make random scanners unable to find your service, 4&5 even hide it from your ISP. Dot/doh service will still know your subdomain, so be your own dot/doh ! :D

Ports are closed by firewalls, and if you need to port forward on your home router this is a non-issue anyway

meh, how can that be :-( I’m still in the process of setting things up with jellyfin, didnt know…

Just put it behind a proxy and require a user cert? Bit of a burdon on the client side, admittedly

How comes you don’t have a baby? Was it eaten by fascists, maybe?