Posted by apotek on April 23, 2013 at 10:35pm
The 7.22 security update for D7 includes some interesting and challenging modifications to the standard drupal distributions .htaccess file.
-<FilesMatch "\.(engine|inc|info|install|make|module|profile|test|po|sh|.*sql|theme|tpl(\.php)?|xtmpl)$|^(\..*|Entries.*|Repository|Root|Tag|Template)$">
+<FilesMatch "\.(engine|inc|info|install|make|module|profile|test|po|sh|.*sql|theme|tpl(\.php)?|xtmpl)(|~|\.sw[op]|\.bak|\.orig|\.save)?$|^(\..*|Entries.*|Repository|Root|Tag|Template)$|^#.*#$|\.php(~|\.sw[op]|\.bak|\.orig\.save)$">
This can be replicated in an nginx config with this:
location ~* \.(engine|inc|info|install|make|module|profile|test|po|sh|.*sql|theme|tpl(\.php)?|xtmpl)(|~|\.sw[op]|\.bak|\.orig|\.save)?$|^(\..*|Entries.*|Repository|Root|Tag|Template)$|^#.*#$|\.php(~|\.sw[op]|\.bak|\.orig\.save)$ {
deny all;
}
However, there are some other interesting changes that I either don't have the knowledge to implement or are simply not doable in nginx at the moment.
lines 62-64
+ RewriteRule ^ - [E=protossl]
+ RewriteCond %{HTTPS} on
+ RewriteRule ^ - [E=protossl:s]
line 88-90 (commented out, but should be available in an nginx config):
+ # RewriteCond %{HTTP_HOST} .
# RewriteCond %{HTTP_HOST} !^www\. [NC]
- # RewriteRule ^ http://www.%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
+ # RewriteRule ^ http%{ENV:protossl}://www.%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
Line 96:
- # RewriteRule ^ http://%1%{REQUEST_URI} [L,R=301]
+ # RewriteRule ^ http%{ENV:protossl}://%1%{REQUEST_URI} [L,R=301]
Any thoughts on how to make these changes to the security model (whether enabled or not) available to nginx users?
Comments
.htaccess changes
The second change http://drupal.org/node/1733476 has to do with https getting redirected to http.
.htaccess changes: how to implement in nginx config
Thank you for the reply. Yes, I get that they're trying to restrict to same protocol. My question, though, and reason for posting in the nginx group, was how we could make available these configuration changes to users of drupal who are running nginx, ie, how do we translate this apache syntax to nginx configuration syntax.
thanks again.
Here's the
Here's the patch:
http://drupal.org/files/1733476_htaccess_protocol_sensitive.patch
It has to do with redirecting to or from a www subdomain while maintaining the scheme.
In nginx you would do something like:
server {
listen 80;
listen 443 ssl;
server_name example.com;
##server_name www.example.com;
ssl_certificate /etc/ssl/mycerts/example.com.crt;
ssl_certificate_key /etc/ssl/private/example.com.key;
return 301 $scheme://www.example.com$request_uri;
##return 301 $scheme://example.com$request_uri;
}
thank you
That was much easier than I thought it would be. No need to define an environment variable 's' depending on whether the protocol is ssl or not, and then paste it into the redirect later, like in apache. So for nginx the $scheme variable is already available in this context, and we can, it looks like, easily enforce our preferred url quite easily.
Thanks for the input.
Do we maintain a D6 and D7 apache-equivalent nginx.conf file somewhere for this group?
thanks again.
Apache equivalence where art thou?
There's no such thing. Nginx is completely different. The issue you linked to just doesn't exist in a well configured Nginx. Also there's no
.htaccessin Nginx (which is a very bad idea anyway).apache equivalence
"just doesn't exist in a well configured Nginx"
Exactly. The question I am asking is how to help keep nginx-based drupal installs up-to-date with changes in the drupal security module. Of course there's no need for an .htaccess file etc etc. I am talking about a "best-practice" document that is maintained by this or some other group that would help admins that are running drupal on nginx actually do what you are assuming from the get go: run a 'well-configured' nginx server.
What is "well-configured" if you are either not an nginx genius, nor always certain of how the .htaccess/apache logic is interacting with drupal?
We're not all as well-informed as you assume us to be. I certainly need to look at others ngnix configuration files from time to time in order to get better ideas, smarter set ups, and to help tighten up security. I certainly could not have set up my drupal sites without any kind of guidance from others who had learned the tough lessons before.
I am glad to be in a world without those awful .htaccess files and it's performance-killing aspects, but I am suggesting in this thread that some kind of coöperative document be established that could help people make sure their sites are secure and well configured.
When I wrote "apache equivalence" I mean only "configuration equivalence."
I for one don't always know when my nginx is considered well-configured, without guidance from others. I'm glad you always do.
There's no configuration equivalence
and it's a bad idea to bring all the baggage from Apache to Nginx. Completely different concepts. Some ideas like hierarchical configuration directives, memory pools, filter chains are stolen from Apache. But the configuration is completely different.
I think no one here claims to have ESP about Nginx configuration nirvana. We all learn by trial and error, i.e., by tinkering.
As per references use the configs suggested at the top of the group for a start. They're used in production in many sites. If something is not clear ask here. Someone will help you as you can see that this is a quite helpful group. No one here is of RTFM variety.
We learn by looking at other configs and by intervening in forums like this one and
the Nginx ML.
Perhaps what you're asking
Perhaps what you're asking for is some way that we can track necessary configuration changes for Drupal core the same way we can simply by upgrading core and getting a new .htaccess (or web.config) along with it. In which case, there really isn't a way, save for just keeping your perusio's config directory updated. If you're familiar with the basics of Git, you may find it useful to check out the project as a Git repository and periodically synch up from the Githup master repo. That might sound like a pain, but that sort of thing comes with the territory when you go against the grain and use anything that isn't Apache, I'm afraid.
The Boise Drupal Guy!
.htaccess
Why .htaccess in Nginx is a very bad idea, anyway?
A few points
It splits the configuration in several places instead of being in a single place. Thus making updating it and maintaining it more difficult.
It introduces a performance penalty since the configuration is reparsed for
every request. On Nginx the configuration is reparsed only when you explicitly do a reload.
Things like the fast 404 problem don't exist since we're able to intercept the requests for static files at the vhost level instead of relying on hacks on
settings.phplike is currently done for Drupal 7.It potentially introduces security problems since instead of the config being on directory accessible only by root, it's on a directory belonging to an unpriveleged user, thus can be exploited more easiliy.
.htaccessis a vestige of the days of shared hosting. It was created to solve theproblem of giving a user some control over the configuration of a site. It doesn't make any sense anymore in a world of VPSes and cloud hosting IMHO.
If fantastic documentation
If fantastic documentation for nginx in Drupal exists, then I haven't seen it. But that's common in Drupal on the average and many other community projects.
Perusio maintains the most comprehensive configuration that I know of and the link to it on Github is at the top of the group page. The inline documentation is much better than most of the configs you'll find.
He uses a similar snippet: https://github.com/perusio/drupal-with-nginx/blob/D7/sites-available/exa... at line 4 and 101 though he breaks out the ssl and non-ssl blocks.
You complain that good
You complain that good documentation for Nginx and Drupal doesn't exist, but then you turn around and praise the documentation with perusio's config. What gives?
Aside from the inline documentation in the config files themselves, there's also a lot to be gleaned from reading the README. It's a bit disorganized and tl;dr, but it's useful and it most certainly exists.
The Boise Drupal Guy!
I stand by my careful chosen
I stand by my carefully chosen words.
Then you should be quite
Then you should be quite comfortable with elaborating on them.
The Boise Drupal Guy!