Just another Sys Admin blog… wait really ?

Apache has a very convenient feature: loading setting files from a webapp directories on the fly. These .htaccess files allow you to tweak the server’s behavior without access to the standard setting files. That a killer feature in a shared hosting environment but beside this particular case, you shouldn’t use it. Why ? Because there are serious drawback !

Performance hit

When AllowOverride all is used Apache will look for .htaccess files in every directory on the path of each served files. That pretty bad but it gets even worse: for each request the content of every .htaccess is read again. As you can imagine that a serious performance hit.

Security concern

Not all parameters can be overridden into .htaccess files, but there is already a lot you can do with a little imagination. For example an attacker could use an application vulnerability to modify a .htaccess in order to add a new file handler, so that .jpeg files are now processed by PHP.

By doing this he can now bypass most webapp upload ‘protection’ mechanism. You can sure the next .jpeg upload will not be a picture of a busty girl but something way more nasty, like a C99 shell.

Maintainability concern

Sometimes a customer will complain that a particular rewrite rule or a specific php setting doesn’t behave like expected. That weird, because you are sure you made ​​the appropriate changes. Surprise surprise, the behavior is altered into a .htaccess file, hidden somewhere in a 5-depth directory structure.

Integrate htaccess content into standard setting files

Many applications come with their own .htaccess. This file generally contain all the required rewrites rules to ensure their proper functioning. It can be very annoying to adapt its content into a standard apache setting file, because the syntax isn’t completely the same.

Fortunately there is a small tip that will save you a lot of trouble and time: you can just copy the rewrites rules into your main Directory block and then add a RewriteBase / line into it.

This error append when trying to upload a file bigger than 1Mbits on a platform using Nginx as an HTTP server or reverse-proxy/SSL off-loader. That because Nginx, by default, limit client query size.

You can change the upper value using the client_max_body_size directive into Nginx setting file:

# vi /etc/nginx/nginx.conf
client_max_body_size <new_value>;

Note: if you want to disable this behavior, set the value to 0.

As varnish doesn’t have any persistent storage you shoul avoid restart it, beside modifications on health checks, backend definitions or changes on the vcl_hash routine.

To reload varnish configuration you could use the distribution init script, or you can do it by hand:

# varnishadm -S /etc/varnish/secret  -T 127.0.0.1:6082
vcl.load conf_two /etc/varnish/prod.vcl
vcl.use conf_two
quit

Note that you can use these commands to load multiple setting files and switch between them on the fly.

Put in place a basic HTTP authentication on a website with a Varnish can be a little tricky.

If you add the authentication on the backend without any changes into the varnish configuration, as soon as an authenticated client browse the website, filtered contents will be accessible to other users.

To avoid this behavior you can add the following block into your vcl_recv :

if (req.http.Authorization) {
   return (pass);
}

but that mean bypassing all cache for the filtered-content. If you want to protect the whole website this setting make Varnish completely useless. Fortunately, it is possible to implement the HTTP authentication on the Varnish side.

Encode user and password

As varnish is a reverse-proxy and not an HTTP server, there is nothing surprising in the fact that there is no support for password file. To bypass this limitation, we will add the login and password directly inside Varnish’s configuration, encoded into a base64 string, generated like this:

# echo -n "$LOGIN:$PW" | base64

VCL modifications

Into the vcl_recv add this block:

if (! req.http.Authorization ~ "Basic XXXXXXXXXXXX"){
   error 401 "Restricted" ;
}

where XXXXXXXXXXXX is your base64 encoded string.

Then add into the vcl_error :

if (obj.status == 401) {
   set obj.http.Content-Type = "text/html; charset=utf-8";
   set obj.http.WWW-Authenticate = "Basic realm=Secured";
   synthetic {"
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/1999/REC-html401-19991224/loose.dtd">
<HTML>
<HEAD>
<TITLE>Forbidden</TITLE>
<META HTTP-EQUIV='Content-Type' CONTENT='text/html;'>
</HEAD>
<BODY><H1>401 Forbidden</H1></BODY>
</HTML>
  "};
  return (deliver);
}