Caddyfile configs for Wordpress

Hi, folks.
There is an example configuration on how to use Wordpress with Caddy V1, available here: examples/wordpress at master · caddyserver/examples · GitHub
Based on that tutorial, I was able to run Wordpress with Caddy V2. I’m using a “generic” Caddyfile config to run Wordpress:

mydomain.com {
root * /var/www/mydomain.com
encode gzip
php_fastcgi 127.0.0.1:9000
file_server
}

As I said before, it is running, but my Caddyfile config seems incomplete when compared to the Caddyfile V1 available in the Wordpress example (examples/wordpress/Caddyfile at master · caddyserver/examples · GitHub).

Are there any suggestions of config?

2 Likes

Welcome @lepore!

Is everything working, including the admin panel, clean “slugs” / post URLs, and pages? If so, you might be good to go, I guess?

Your config missing the rewrite on this condition: if {path} not_match ^\/wp-admin – but it just does a try_files, which php_fastcgi in v2 does for you anyway.

The only other thing missing is # Prevent malicious PHP uploads from running – but I do not understand what the threat model is there, unless people are allowed to upload executable scripts to your server (!! in which case, that’s the real problem here !!).

Hi, @matt !
Everything is working very well.
I was worry those rewrite conditions were truly necessary. It seems they’re not :slightly_smiling_face:

Thanks!

Wordpress allows arbitrary uploads because it’s a CMS… So I’d say it’s still worth blocking.

I think what you’d want is to return a static 404 response if the path is /uploads/*. I think all you’d need is something like:

respond /uploads/* 404

Worth giving it a shot at least!

P.S. @matt would it need close here? I’m not sure I understand when close is required

This is amusingly true, but in the sad-cry kind of way… most CMS’s have/had such bad security (at least defaults) that they are associated with “allowing uploads == RCE vuln” :sob: but it doesn’t have to be that way just because files can be uploaded. They just don’t care or something. Sigh.

Anyway yes, if that is in fact a real problem with modern WordPress, then you’ll want to block that somehow.

But how would benign uploads be accessed? I assume they are uploading things to also serve/access them.

Only if you want to terminate the TCP connection with the client. It can slow down future requests, so probably not in this case? We use it when redirecting HTTP->HTTPS because HTTPS is on a different port, so the connection to the HTTP port is no longer needed.

Okay I figure that should be added to the doc then :slightly_smiling_face:

Hmm, I guess we can also match on ending with .php

1 Like

100%. Specifically, the threat model is:

  1. Sign up to a WordPress site
  2. Upload a PHP file to the library
  3. Attempt to download the PHP file
  4. Laugh as instead of producing the PHP file as a download, the server renders it

I might propose a better solution would be:

respond /uploads/*.php 404

We don’t need to 404 every single upload - that would break uploaded pictures and the like attached to blog pages etc. Just 404 any uploaded PHP files specifically.

2 Likes

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.