Nginx serving whole drupal directory - security risk?

We encourage users to post events happening in the community to the community events group on https://www.drupal.org.
Big-Blue's picture

Hello,

I've got myself a budget VPS around a month ago and run a combination of nginx, MariaDB, PHP5-FPM and Drupal7 running. While following the Administration docs to optimize my Drupal installation, I found out that my nginx (at that time using the nginx-wiki config for Drupal) was serving all files in the drupal folder (except the specifically blocked directories and file types), which seemed like quite a huge security risk to me. After being concerned about this for a longer time (I don't have any content on the site yet, it's pretty much private) I joined the IRC today to ask what I should do. One of the helpful users there suggested me this configuration, which I'm using in a slightly modified version now, but it still serves - for example - '/profiles/standard/standard.profile'. The "dangerous" types like .inc or .sql are blocked now, but having those other directories in the open still concerns me.
Should I take any action against this? Like just blocked all directories other than /sites from being accessed from anyone else than localhost?

Thanks in advance, especially for enduring my inexperience. ^^"

Comments

It's a mess

perusio's picture

that config is a mess. Nobody here recommends it, in fact you cannot find any post here where someone recommends it. If you check the posts the idea is to allow for execution of specific PHP files, usually index.php and block all the rest. Check any other config except the one on the wiki which is insecure.

BTW that's referenced on the Nginx wiki: http://wiki.nginx.org/Pitfalls#Passing_Uncontrolled_Requests_to_PHP

At the top of the

brianmercer's picture

At the top of the http://groups.drupal.org/nginx page are a few configurations. I know Perusio's is kept up to date.

It isn't practical to limit things at the folder level because Drupal has .css and .js files all over /modules, /themes, /sites/all/modules, /sites/all/libraries, etc.

It's more practical to have a config that doesn't serve anything, and then explicitly allows certain specific files and file types, i.e. css/js anywhere; /index.php specifically; /robots.txt specifically; mp4, txt, zip, pdf only from sites/default/files, etc.

Such a restrictive config means you sometimes have to configure nginx for a specific module or feature, but it is manageable.

Well, wow, I didn't expect

Big-Blue's picture

Well, wow, I didn't expect the config to be so bad. I've taken the one from the wiki as it seemed like a good starting point, I thought if they put it on the wiki, it can't be so bad. It turns out, that was wrong, so thanks for the pointer.
A restrictive config sounds good, I'll try to take a lightweight example from the top of the group page. To my confusion, the wiki page I linked in the OP is also linked there.
I guess I'll go with yhager's first, and modify it to use sockets. It's still a budget VPS and I don't know how much it would impact the performance if I use a more complex config with more features.

EDIT: I've used yhager's config for now, and the file I used for testing, /profiles/standard/standard.profile, is still getting through :/

Note that we are talking

perusio's picture

about different things it seems. We're (Brian and I) talking about constraining execution of PHP scripts. Not blocking the files from the user.

In your case try adding:

location ^~ /profiles {
    internal;
}

see if it suits your needs,

Also this line

perusio's picture

which replicates the .htaccess file matching for blocking access does the trick:

    ## Replicate the Apache <FilesMatch> directive of Drupal standard
    ## .htaccess. Disable access to any code files. Return a 404 to curtail
    ## information disclosure. Hide also the text files.
    location ~* ^(?:.+.(?:htaccess|make|txt|engine|inc|info|install|module|profile|po|sh|.sql|test|theme|tpl(?:.php)?|xtmpl)|code-style.pl|/Entries.|/Repository|/Root|/Tag|/Template)$ {
        return 404;
    }

I wonder if we can somehow

greggles's picture

I wonder if we can somehow get this into Drupal core for D8?

Sure

perusio's picture

I've meaning to get it started myself. Also as a follow up to http://groups.drupal.org/node/232023#comment-761258.

I believe also that it should be backported to D7 and D6.

Nginx

Group organizers

Group notifications

This group offers an RSS feed. Or subscribe to these personalized, sitewide feeds: