Recipe 42Securing Your Content

Problem

When we put files on our web server, they’re available for anyone to see. But we don’t want the entire world to have access to any important documents we’re storing. When we want a select group of people to be able to access the files, we need a way to lock certain files or folders and create basic authentication.

Ingredients

  • Development server with Apache

  • Apache2-Utils

Solution

Apache allows us to create configuration files that specify which directories and files shouldn’t be served without authentication. We’ll take a look at how we build these configuration files to secure our server.

Using Basic HTTP Authentication

When Apache is serving up files, it’s always looking for the .htaccess file. This special file tells Apache the configuration for a specific folder on your server. With the .htaccess file, we can enable password protection of files, block users based on certain criteria, set redirects and error documents, and much more.

Let’s start by creating a file to ask for authentication. If you haven’t already, be sure to read through Recipe 39, Setting Up a Virtual Machine, so that you have a development server to test with. After we log into our development server, let’s also make sure that Apache is running and that we have the most up-to-date apache2-utils package:

 
$ ​sudo service apache2 restart
 
$ ​sudo apt-get update
 
$ ​sudo apt-get install apache2-utils

We’ll also want to make sure that our website is configured correctly. Open the default site configuration /etc/apache2/sites-available/000-default.conf and make sure the following code exists. The key piece we need here is the AllowOverride All so that our .htaccess can be used by the web server for this site.

 
<Directory /var/www/html/>
 
Options FollowSymLinks
 
AllowOverride All
 
</Directory>

Now that Apache is running, we can start to build the authentication. For basic HTTP authentication, we need to create a file to hold the usernames and passwords that are allowed to log in. We can use the htpasswd command to generate a username with an encrypted password. Let’s create the username and password now, and let’s keep the file in our home directory:

 
$ ​htpasswd -c ~/.htpasswd webdev
 
New password:
 
Re-type new password:
 
Adding password for user webdev

When we call htpasswd, we pass a location for the file and our username. We use the -c flag to create a new file if one doesn’t exist. When we press Return, we’re prompted to enter the password we want to encrypt. If we want, we can use the cat command to check what’s in that file so far, and we’ll see something similar to the following:

 
$ ​cat .htpasswd
 
webdev:$​apr1$9rQfRhOd$ZJJpVrhFVlWvYrn3vVrtI0

Now that our user is created, we can start locking down directories. Let’s navigate to the document root and create an .htpasswd file:

 
$ ​cd /var/www/html
 
$ ​touch .htaccess

Let’s open up our new file with our text editor and add some directives to lock down the root directory:

 
AuthUserFile /home/webdev/.htpasswd
 
AuthType Basic
 
AuthName 'Our secure section'
 
Require valid-user

Because we created this file in the top level of the document root, we’ve locked down every document on our server. Let’s use our browser and navigate to http://192.168.1.100/. You should see an authentication modal dialog like the one in the following figure:

images/securingcontent/httpbasic_dialog.png

Thanks to Apache’s HTTP authentication, we have an easy method for securing the content on our servers.

Where Should I Keep My .htpasswd Files on a Live Server?

With most shared hosts, you’re limited to working only in your home directory. This means that the document root for Apache is set up to point most often to something like /home/webdev/mywebsite.com/public_html. Since you’ll often be hosting multiple websites, it’s nice to have each website in its own folder. For security reasons, you should place each site’s .htpasswd file in that site’s folder. For example, to generate the file for http://mywebsite.com, we’d run something like this:

 
$ ​htpasswd -c ~/mywebsite.com/.htpasswd webdev

This allows us to keep the users for different websites separate from one another.

Denying Off-Site Image Requests

We’re paying a pretty penny for our hosting plan, so bandwidth and server load are always a concern. Also, we don’t want anyone to be able to use our images without the correct rights and permissions. Thankfully, we can write a rule in .htaccess that will block off-site linking of images.

First, we need to enable Apache’s mod_rewrite, since we’ll want to use it to deliver a broken image to the request:

 
$ ​sudo a2enmod rewrite

To learn more about mod_rewrite, refer to Recipe 43, Rewriting URLs to Preserve Links.

We’ll add a rule that rewrites the URLs for incoming requests to instead deliver an image that doesn’t exist. Let’s open up our .htaccess file and add these lines:

 
RewriteEngine on
 
RewriteCond %{HTTP_REFERER} !^http://(www.)?mywebsite.com/.*$ [NC]
 
RewriteRule .(jpg|png|gif)$ - [F]

The first line tells Apache to use mod_rewrite. Next, we add a condition that applies our rewrite rule only if the referring website is different from our own URL. Last, we create a rewrite rule to look for any requests that end in an image extension. We use the [F] flag to tell Apache that these URLs are forbidden.

With that, any image request to our server returns a broken image in place of the image that was being used.

Further Exploration

When it comes to locking down a server, we can use many methods to keep information and content hidden. Aside from password protection and rewrite rules, we can also block users by IP address or even by the website they are coming from. With Apache’s configuration files, we can secure our content in many ways. To see more advanced applications of the rewrite engine, read through Recipe 43, Rewriting URLs to Preserve Links. Also, you can refer to Apache’s own .htaccess tutorial.[138]

Also See

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
52.15.160.43