8 ms·
I believe Caddy brought a much needed paradigm shift in web server space, it is an incredible piece of technology. I have moved all my servers from NGINX to Ca
by BilalBudhani 3y ago
I believe Caddy brought a much needed paradigm shift in web server space, it is an incredible piece of technology.
I have moved all my servers from NGINX to Caddy for the pass few years and I couldn't be happier.
Also, I would like to give a shoutout to the team behind Caddy. They have been nothing but great about constantly shipping updates and being incredibly helpful in their community forum.
- rekoil 3y agoCaddy is amazing, but on production machines remember to disable the unauthenticated and enabled by default JSON-based admin API bound to localhost:2019, as it can be a serious security risk in certain deployments. Put the following in your Caddyfile at the lowest scope to disable it: { admin off }
- executesorder66 3y agoAlternatively don't serve your site over HTTP at all. Just redirect to HTTPS. Edit, I just checked the Caddyfile for one of my sites. There is no config for redirecting HTTP to HTTPS is does it automatically. So this is entirely unnecessary.
- rekoil 3y agoNo what I'm talking about here is the unauthenticated JSON-based configuration API that hosts itself on port 2019 on localhost of the machine that runs Caddy. This is unrelated to sites hosted using HTTP. I was clumsily using the term "HTTP" to refer to the fact that this configuration mechanism is based on HTTP-communication.
- executesorder66 3y agoSo if I understand this correctly, anyone can bring down a site with a Caddy server by just running : curl -X POST "https://example.com:2019/stop https://example.com:2019/stop" ? [0] Seems counter to their objective of having secure defaults. [0] https://caddyserver.com/docs/api#post-stop https://caddyserver.com/docs/api#post-stop
- jorams 3y agoNo, it is only bound to localhost.
- gkbrk 3y agoNo, by default it listens on localhost. So only processes running on the same machine can connect to that port.
- executesorder66 3y agoOkay that makes sense. So why would you bother disabling this thing? I'd imagine if someone already has local access to the server, it's already too late.
- mcint 3y agoMost people would expect that `sudo` and `curl localhost:2019` are very different permissions, that is, curl with post payload `-d '{"admin":{"remote":{"listen":"0.0.0.0:2019"}}}'`, and you'd only have to convince an existing process to make the request.
- rekoil 3y agoSSRF in an application is a serious issue to have on its own, that's true, but in combination with a Caddy admin endpoint it can be used to give an attacker full access to your local network. You could have a blind SSRF vulnerability in an application and while that's not great, it is difficult for an attacker to exploit successfully. If the attacker knows or guesses you're hosting Caddy on the same machine, they know you most likely have an admin interface on localhost:2019 that they can use to make further local network requests and also makes it possible for them to access the results of their local network requests they were making through the blind SSRF vulnerability hypothesised above. Basically, if you're not using it (and you shouldn't be using such functionality on a production machine), then you don't need it and should disable it, see: https://owasp.org/Top10/A05_2021-Security_Misconfiguration/ https://owasp.org/Top10/A05_2021-Security_Misconfiguration/
- nurettin 3y agoWorks on localhost. It is not a big deal.
- rekoil 3y agoIf you're hosting your applications on localhost it can be a security risk. A blind SSRF vulnerability (with payload control) in your application could be used to gain full control over the reverse proxy resulting in the attacker gaining full unfettered access to your network. If you're not using it (and you shouldn't be using such functionality on a production machine), then you don't need it and should disable it, see: https://owasp.org/Top10/A05_2021-Security_Misconfiguration/ https://owasp.org/Top10/A05_2021-Security_Misconfiguration/
- rocqua 3y agoIf your server reaches out to user-provided URLs, it can be a big deal. Especially with DNS rebinding, remote users can bind domains to 127.0.0.1. Which avoids cors like protections.
- mholt 3y agoWe mitigate both DNS rebinding and cross-origin in the admin endpoint by verifying Host and Origin headers -- by default.
- deleted 3y ago[deleted]
- mrd3v0 3y agoThis is how trivial bugs turn into full-fledged threats. Increasing attack surfaces without any justification is bad cyber security.
- Gud 3y agoIt is absolutely a big deal. Any server software should be secure by default, period.
- sergiosgc 3y agoAt least, have it respond only to authenticated requests. Caddy supports client certificate authentication: https://caddyserver.com/docs/json/admin/remote/access_control/public_keys/ https://caddyserver.com/docs/json/admin/remote/access_contro...
- Freaky 3y agoCaddy also supports Unix sockets, which should be rather more difficult to smuggle requests to, and can be protected by file permissions: admin listen unix//var/run/caddy/admin.sock
- rekoil 3y agoThis (if they definitely must leave the functionality enabled by default) is what should be the default honestly. I still can't fathom why that isn't the case!
- oarmstrong 3y agoI would imagine so the default behaviour could be identical across platforms.
- robertlagrant 3y agoI imagine it's for Windows users. But yes, it could very sensibly be the default in Unix.
- Freaky 3y agoI'll see about getting it made the default for the FreeBSD port at least.
- francislavoie 3y agoCaddy maintainer here: we're looking to move to unix socket by default for Linux distributions. See https://github.com/caddyserver/caddy/issues/5317 https://github.com/caddyserver/caddy/issues/5317, the plan is to set this env var in the default service config but I'm trying to be careful about backwards compatibility so I haven't pushed the change for our deb package yet. Will likely do it soon.
- asimops 3y agoPSA: systemctl reload caddy will call this api. If you disable it, then reloading the server will no longer work.
- mozey 3y agoThis default behaviour makes sense. If you're going to be using it for hosting in production, then read the documentation, and it's trivial to disable. If I recall, AWS has a similar default for some services. That is, access to the subnet (VPC) gives you full access to the attached service, no password required.
- jarym 3y agoDo you recall which AWS services are like this? Thinking I better check a few things!
- jbverschoor 3y agoAnd mongo, and many others packages with insane defaults. What if rm would by default just delete everything, as it assumes that makes sense? Stupid comparison, I know, also a stupid default.
- bravetraveler 3y agoDisagree, to a degree. It's fine to offer this for extended use cases (ie: restarting from a second, trusted, host) It would be more appropriate to handle signals, particularly SIGHUP. That's how most services have been handling reloads. It's fine to offer an admin API, especially if I want a peer to be able to affect the local instance, but this shouldn't be the position init is placed in. Put simply, the init process is what we depend on if everything else fails.
- jbverschoor 3y agoJust another weird and stupid default waiting to be exploited.
- mmcnl 3y agoWhile you are right, remember there are usually additional layers of security (and if not, there should be). On the network level, you would only allow ports 80/443 to reach the machine. And if you use a containerized deployment, you would only expose 80/443 as well.
- btgeekboy 3y agoIf your application can be used to make outbound requests to the internet (and so many apps can be), you can easily make a GET against localhost. There are ways to lock that down, but they aren’t automatic.
- tetris11 3y agoTheir filebrowser (originally part of caddy, since split out)[1] is a pretty nice tool for serving web-based browser of your NAS files. I'm also a huge fan of Caddy's "handle" and "handle_path" directives for their simplicity. One thing I will say against it though is that it does seem to run a little hotter than Nginx on my Pi4. Just random spikes here and there, whereas Nginx barely used to blip. 1: https://filebrowser.org/installation/ https://filebrowser.org/installation/
- mmcnl 3y agoI've been using this for years but never knew it was a spin-off from Caddy. I really like it!
- mholt 3y agoYeah! Henrique Dias did great work with it. He should be very proud of his project.
- francislavoie 3y agoTechnically it was shipped as a plugin for Caddy back then, it wasn't actually part of Caddy proper. Now they ship it standalone and recommend to reverse proxy to it. IMO it would be nice to still have the ability to include it as a Caddy plugin, but alas.