Remote access with Caddy, Duckdns vs Tailscale for security?

[Balinus]

Hello! 

So, I have a security related question. Until now (mainly, since I first installed Jellyfin 3 weeks ago!), I used Tailscale to share my home Jellyfin server with my family. However, it is max 3 users and thus looked at the whole Caddy, duckdns, etc guides and successfully (and surprinsigly!) have a public domain name that points to my Jellyfin server. 

I was wondering, how secure that is? I ran the testtls.com suite of tests, everything was green except a yellow msg about "Secure Renegociation- WARN- OpebSSL Handshake didnt succeed". 

First, is this warning important? And secondly, what would be the best practice here? (see config below).

I use duckdns, then ports forwarding of 80 and 443 to internal IP. Caddy is configured to do the reverse proxy and with the config file of Caddy, I use the dns provider add-on for tls cert. I also have a cron script for dynamic dns with duckdns. 


Perhaps a 3rd question: is Tailscale more secure or my config is quite enough? Ideally, I want something secure, but with more than 3 users.

[Balinus]

The warning mentioned

   

[Balinus]

Finally, my Caddyfile configuration:

Code:

my-servername.duckdns.org {

        reverse_proxy 127.0.0.1:8096

        # Enable the static file server. Not sure it is necessary, haven't tested without it yet.
        file_server

        tls {
                dns duckdns PERSONAL-API-KEY
        }


}

[TheDreadPirate]

That specific warning is nothing to worry about.

The dangers of exposing your server to the Internet are simultaneously exaggerated but also very real.

Keep your server up-to-date, keep caddy up-to-date, keep jellyfin up-to-date, hide users from the Jellyfin login screen (default), use good password hygiene. 99.9999% of attacks are no longer effective.

The most common thing you will encounter are low effort script kiddies looking for unpatched Windows 7 systems and the like. Or unpatched systems in general using known, often very old, vulnerabilities. Which is completely mitigated by updating as soon as possible.

For the rest, you can take the additional step of setting up fail2ban to scan your Jellyfin logs for failed login attempts and then IP ban once they reach a threshold.

https://jellyfin.org/docs/general/networking/fail2ban/

A lot of other software, not just Jellyfin, can make use of fail2ban and there are often fail2ban config examples out there on the Internet for a lot of the software you might be self-hosting.

Another thing you could do is have Caddy run on another port other than port 443. Since you are using DNS challenges for your certs you don't need to use port 443. Regardless if you are using DNS challenges or not since Caddy can do TLS challenges you just straight up don't need to open port 80. Since a lot of script kiddies only scan common service ports, running on a random port significantly reduces the number of attempts that even reach your server. Though this has the annoyance that all clients need to append your URL with the port number.

FWIW, I have NEVER had rando's attempting to log in to Jellyfin while running on a random port.

Again, take security seriously. But also don't worry too much.

[Balinus]

Thanks! Very useful. My system is using Ubuntu Server LTS. I have the habit of updating my system often, so I should be good. Thanks for the other tips, I will implement them:

- Not forwarding the port 80
- Using an arbitrary port other than 443
- Good password(s)
- Setting fail2ban (didn't know about that)

I also already setted a maximum of login attempt to 5. Not sure it's that useful though.

Perhaps a question about updating. The Caddy version I used is the one "provided" with the dns add-on (here: https://caddyserver.com/download). My guess is that I will have to manually download each new version and replace the one on my system? The other software are using PPA repos, so should update with a regular sudo apt update/upgrade commands)

Thanks again, it is comforting to read that, if I take the right steps, the server will be secure.

[TheDreadPirate]

I use Nginx, so definitely not a Caddy expert. A cursory read of Caddy's docs, and the DuckDNS module git, doesn't make clear what the "right" or best way is to update Caddy when using a DNS module. You're probably better served by asking on the Caddy forum.

[Balinus]

I use Nginx, so definitely not a Caddy expert.  A cursory read of Caddy's docs, and the DuckDNS module git, doesn't make clear what the "right" or best way is to update Caddy when using a DNS module.  You're probably better served by asking on the Caddy forum.

Thanks, will do!

[Balinus]

For reference, here's the thread I started on Caddy Community forum.

https://caddy.community/t/best-way-to-in...dule/30701

[InTrusta]

Don't have a solution, just wanted to give an fyi for tailscale. You can only add 3 users to tailscale, but you can add a lot more users through direct access to your NAS/Server. I think its around 100 or so. And it's even better, because normally i don't want my friends to see all my machienes in my taislcale network. I only want to give them access to my NAS.

I had the same problem as you and was about to set up the whole duckydns/reverse proxy setup, but then i read i can just add way more friends directly to the machiene. And i prefer tailscale because it's just super secure.

[Duvel]

For reference, here's the thread I started on Caddy Community forum.

https://caddy.community/t/best-way-to-in...dule/30701

If you want to use a DNS module you should build your own caddy image that includes the stuff for your specific DNS provider.

All custom images for all supported DNS providers are there : https://github.com/orgs/caddy-dns/repositories?type=all

You can add any other module you'd like to build the image you need

For instance my DNS provider is Infomaniak, and I also use the Crowdsec bouncer module on my Caddy to detect and block known attacks scenarios and offenders IPs, and so I build my caddy image with this docker command :

Code:

  FROM caddy:builder AS builder
 
  RUN xcaddy build \
      --with github.com/caddy-dns/infomaniak \
      --with github.com/hslatman/caddy-crowdsec-bouncer/http
 
  FROM caddy:latest
 
  COPY --from=builder /usr/bin/caddy /usr/bin/caddy

Once your image is cooked, you should also configure properly the DNS parameters using a tls{} in your Caddyfile, for instance this is mine for infomaniak

Code:

*.domain.tld, domain.tld {

    crowdsec # this executes the CrowdSec module; if an IP is denied, it won't get access to the reverse proxy

        tls {
                dns infomaniak my_very_long_api_key_provided_by_infomaniak
                propagation_delay 60s
                propagation_timeout -1
        }

The parameters for your DNS might be different than mine, and you should find how to configure yours by yourself. There's generally some explanations on the readme of each caddy-dns sub-github