Caddy: Avoiding misconfigurations that could lead to breaches

[mholt]

As you know, one of the primary goals of Caddy is for it to be easy to configure. I strongly believe that easy configuration with sane defaults is crucial for good security. As Troy Hunt testified to US Congress today, misconfigurations and prioritizing convenience are primary causes of allowing data/security breaches.

I'm interested in looking into ways that Caddy can further help prevent accidentally making a site or service accessible to the public when it is not intended to be. It already does this to an extent by requiring a certificate by default, which requires public verification of a domain name. However, some services may use a public domain name or subdomain but are only meant to be exposed on internal interfaces.

Ways that Caddy could protect a site or service:

• Exposed only to a local or internal interface
• Basicauth
• TLS client auth

There are probably others; but the point is, how can we go about reducing the likelihood of a server misconfiguration such that content which is intended only to be private is not made public?

As an example of part of a solution to help you get an idea of what might be possible, imagine typing a directive called "public" in a site block that is intended to be public (even though Caddy thinks it should be private by default for safety).

Discussion questions:

• What are some signs in the Caddyfile, the way Caddy was run, or even HTTP requests that a site should be private?
• How can Caddy help prevent publicly exposing private sites to the Internet?

[magikstm]

I would consider:
1) Requiring a root directive (to avoid a misconfiguration that may expose unwanted files)
2) Validating that caddyfile isn't within root directive path (to avoid exposing sensitive info)
3) Validating that a basicauth file isn't within root directive path (to avoid exposing sensitive data)
4) Validating that errors directive files aren't within root directive path (to avoid exposing sensitive data)
5) Validating that log directive files aren't within root directive path (to avoid exposing sensitive data)
6) Validating that import directive path isn't within root directive path (to avoid exposing sensitive info)

[OmgImAlexis]

~Adding onto what @magikstm said. I'd also like to see certain known files/paths to be filtered.
For example not allowing files called passwd to be served without some kind of override in the plugin block of the Caddyfile, e.g. http.filemanager.~

[tobya]

Hiding files that begin with a . dot such as .env files by default which may contain information. This is already a feature request with a general hiding plugin.

[pgaskin]

@tobya An exception would need to be added for RFC 5785, which is the .well-known dir. Also locations which are proxied should be exempted as well, as most would already have their own security, and blocking dotfiles could break them.

[root360-AndreasUlm]

I'd add the following to the list:

1. prevent delivering directories of version control systems like tar-command with --exclude-vcs https://www.gnu.org/software/tar/manual/html_section/tar_48.html#IDX420
2. prevent delivering ignore files of version control systems, e.g. tar-command excludes .cvsignore, .gitignore, .bzrignore, and .hgignore
3. prevent delivering source code files that should be interpreted (e.g. *.php) unless a directory based option allows that
4. might be really hard but removing tracebacks from outputs by default would improve security a lot as mostly tracebacks contain sensitive information like passwords, session data and so on

[mholt]

Caddy 2 should have a vetter or linter for this.

[mholt]

Closing for now. These are all good ideas at least worth considering, but it probably isn't stuff we can safely assume by default without breaking legitimate configurations -- also, a lot has changed in v2, making some of the suggestions a bit obsolete / difficult to translate into v2 directly. Probably some third-party module or vet/lint tool would be the best way to take care of this.