General Security concerns. what to do next?

1. Caddy version (caddy version):

v2.2.0 h1:sMUFqTbVIRlmA8NkFnNt9l7s0e+0gw+7GPIrhty905A=

2. How I run Caddy:

I run a JellyFin server with and use caddy server as a reverse proxy to it. Jellyfin and Caddy are on the same Windows 10 box. I have NoIP with a free DNS name to point to my jellyfin/caddy setup. – JellyFin has a baseURL set to my value that is in the caddyfile.

a. System environment:

Windows 10.

b. Command:

caddy start

c. Service/unit/compose file:

nothing- just using caddy start on windows.

d. My complete Caddyfile or JSON config:

{
email  xxxxxxxxxxxxxx@gmail.com 
}


melbatoast.hopto.org {
	encode gzip
		log {
			output file C:\caddy\logs\hopto_access.log {
				roll true				# Rotate logs, enabled by default
				roll_size_mb 5		    # Set max size 5 MB
				roll_gzip true			# Whether to compress rolled files
				roll_local_time true	# Use localhost time
				roll_keep 10			# Keep at most 10 log files
				roll_keep_days 21		# Keep log files for 21 days 
			}
		}
		
    redir /eggplantView /eggplantView/
	
    reverse_proxy /eggplantView/* localhost:8096 
}

3. The problem I’m having:

I access my site by https://melbatoast.hopto.org/eggplantView

I have my site down right now, while I think things through. I am just trying to figure out what i need to do to enhance my security. Is there a way to send an error or something back if the client goes to my site directly without using the /eggplantview baseURL.

I noticed that accessing https://melbatoast.hopto.org, or a nonused baseURL https://melbatoast.hopto.org/eggToast just goes to a blank page in the browser. Is there a way to send back some response, like an error? Should I send back an error? Basically, I want to make the remote client or browser think that nothing is there unless they hit my baseURL exactly. I would appreciate any ideas on what I can do next.

Also, on a related note, am I using the log system in an efficient manner? Do I need the “encode gzip”?

4. Error messages and/or full log output:

none.

5. What I already tried:

  1. I have JellyFin accounts with Strong passwords.
  2. I have the baseURL that i can configure in JellyFin so I can make it more robust and non-standard. that way hitting my DNS doesn’t just get access to my Jellyfin server
  3. I looked at Fail2Ban to be able to block IP’s that try to brute force my login id’s. But Fail2Ban doesn’t seem to work on Windows 10. I did notice that caddy prints out a nice log file is someone makes a bad login attempt on my jellyfin server. does anyone know of a way to block IP’s that abuse my login?
Line 33303: 2020/11/05 02:31:22.401	error	http.log.access.log0	handled request	{"request": {"remote_addr": "167.88.10.180:32320", "proto": "HTTP/2.0", "method": "POST", "host": "melbatoast.hopto.org", "uri": "/jelly/Users/authenticatebyname", "headers": {"X-Emby-Authorization": ["MediaBrowser Client=\"Jellyfin Web\", Device=\"Safari iPhone\", DeviceId=\"TW96aasd;lk0-29342094tjkas;k2032o4203492348204ajsdxssssjsjsjsjsjs0303M0NjYyNDI1\", Version=\"10.6.4\""], "Content-Length": ["32"], "Accept-Language": ["en-us"], "Referer": ["https://melbatoast.hopto.org/eggplantView/web/index.html"], "Accept": ["application/json"], "Content-Type": ["application/json"], "Origin": ["https://melbatoast.hopto.org"], "User-Agent": ["Mozilla/5.0 (iPhone; CPU iPhone OS 14_0 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/14.0 Mobile/15E148 Safari/604.1"], "Accept-Encoding": ["gzip, deflate,...

6. Links to relevant resources:

It just occurred to me. Should I have something about X-XSS-Protection in there? if so then how?

I see no problems with security for your current setup, frankly.

Some reading materials on using Caddy in a home network:

Yep, just handle the requests with a request matcher.

A common pattern is to do something like this:

example.com {
	redir /foo /foo/
	handle /foo/* {
		reverse_proxy localhost:8096
	}

	handle {
		# Any other requests are caught by this
	}
}

I recommend making use of subdomains instead of subpaths though, like jellyfin.melbatoast.hopto.org or whatever. It’s a cleaner solution, and avoid potential issues with apps that don’t behave well when proxied in a subpath. See this article for an explanation:

There’s not really much to do for “efficiency”, the defaults should already be good enough (i.e. you probably don’t need to override the roll options at all)

It’s not required, but it does compress responses and therefore takes up less bandwidth, and is usually faster due to lowered data transfer times.

Security by obscurity is not really that useful. If you have authentication on your Jellyfin server, it’s good enough.

There’s not really much tooling out there yet to handle Caddy’s style of logs unfortunately.

I don’t use any IP blocking tool for my home networking setup, and I have no problems. It’s not usually that common to get hit with lots of traffic. You probably won’t need to worry about it.

1 Like

Thanks, your tips helped a lot. Now my site only responds with my jellyfin server if the user goes to my specific baseURL. Anything else, even the normal root goes to my 404 respond. Nice!

So only https://melbatoast.hopto.org/eggplantView or https://melbatoast.hopto.org/eggplantView/ goes to my jellyfin.

{
email  xxxxxxxxxxxxxx@gmail.com 
}


melbatoast.hopto.org {

	encode gzip
		log {
			output file C:\caddy\logs\hopto_access.log {
				roll true				# Rotate logs, enabled by default
				roll_size_mb 5		        # Set max size 5 MB
				roll_gzip true			# Whether to compress rolled files
				roll_local_time true	        # Use localhost time
				roll_keep 10			# Keep at most 10 log files
				roll_keep_days 21		# Keep log files for 21 days 
			}
		}
	
	# this part sets up the reverse proxy for the baseURL that is configured in the JellyFin console	
	redir /eggplantView /eggplantView/
	
	handle /eggplantView/* {
		reverse_proxy localhost:8096 
	}
	
 	# this part sends everything else to a 404 response
	handle {
		respond  "404 - Not Found" 404 { 
		     close 
		}
	}
	
}

FYI, this isn’t valid syntax:

respond  "404 - Not Found" 404 { close }

It should be

respond  "404 - Not Found" 404 {
	close
}
1 Like

thanks again! I updated my post.

This topic was automatically closed after 30 days. New replies are no longer allowed.