Preventing Bandwidth Theft with Apache

Even if you expressly ask them not to, some webmasters will try to directly link to your images from their pages. By stealing your images in this way they’re using up your site’s bandwidth without notifying their visitors of your site, which means you get no credit and a bigger bandwidth bill at the end of the month. Erk! Luckily, a simple configuration change provides the necessary fix.

The Swindle

So how exactly is this dastardly deed carried out? It’s a simple ruse: the offending webmaster sees an image they like the look of on your site. Smiling craftily, they murmur “I’ll have that,” and proceed to write an img tag like this:

<img src=”http://www.yoursite.com/media/image.gif” alt=”I eat bandwidth for breakfast”>

Your image will then appear on their site as if it was one of their own. This practice is known as “hotlinking” or “leeching” an image. It’s rude, and often infringes on the copyright of the image.

You’ll often see people hotlinking images to use as their » avatar or signature image on messageboards. It is a poor strategy to link to images stored on a separate server than the one your webpages are on, as it slows the loading of the page, not to mention leaving you wide open to embarrassing retribution of the » “switcheroo” variety.

A webmaster could also offer a link to an image on your site, like this:

<a href=”http://www.yoursite.com/media/image.gif”>Download this image</a>

This is pretty much the same deal, though at least this time people will see that they’re getting the image from a different server than the one that referred them to it. However, this is poor form, and it would be much better for the webmaster in question to either take a local copy of the image (save it on their own server and link to that image, provided there’s no copyright infringement), or link to a page on your site that has the image on it.

What we want to do is to stop images from loading on remote sites by redirecting all requests for them to another location.

Locking the Door

As with most configuration changes in this section, this technique requires that your site is hosted on a computer running the Apache web server. The vast majority of servers do run Apache, since it’s free and excellent, although those of you on IIS or whatever could consider this » PHP solution.

So, how are we going to work this? Well, whenever an image is requested from a server, the page that referred to this image is sent as part of the request. This is the page that linked to the image or the page that contained the img call to it. We can look at this referrer, and if it doesn’t match a list of sites that you allow to link to your images, you can block the image from being sent.

Let’s Do This Thing

Open your .htaccess (or create a new one), and add these lines:

RewriteEngine On
RewriteCond %{HTTP_REFERER} !^http://(www\.)?yoursite\.com [NC]
RewriteCond %{HTTP_REFERER} !^$
RewriteCond %{HTTP_REFERER} ^http://.*$
RewriteRule \.(jpe?g|gif|bmp|png)$ /media/nohotlinks.png [L]

We’re using URL rewriting to redirect any unwanted image requests. If you’ve done any redirecting before this should seem straightforward enough. Let me step through this, line by line:

Before we do any redirect, we set down some conditions — those are the two RewriteConds. The first checks if the variable HTTP_REFERER does not start with either http://yoursite.com or http://www.yoursite.com (the question mark meaning “zero or one occurrences of the preceding parentheses,” and the exclamation mark negating the match). The [NC] flag simply makes the match case-insensitive.
The second condition checks if no referrer was sent, which may occur if a visitor typed the image’s address into the location bar. We don’t want to block those requests.
The third condition checks if the referrer header does actually contain another website’s URL. This is to guard against doing the wrong thing in the case of users with special software on their computers that replace all referrer headers they send with text like “Blocked by personal firewall.” Again, we don’t want to block those requests.
If all of these conditions are true, we know that the image is being requested from a remote site, and can go ahead with the redirect. “HTTP_REFERER” (with one ‘r’) is not a mistake; some joker on the HTTP team just couldn’t spell, and this has survived as a geeky joke ever since.
The RewriteRule itself is a simple one. It simply looks at the file extension of the file being served. If the file has any of the extensions listed, it is rewritten to our ‘nohotlinks’ image.
sourcetip: Don’t try to redirect blocked image requests to a HTML page instead of this ‘nohotlinks’ image. It won’t work, because the browser is expecting a file with the MIME type of an image, and so will only accept another image.

The image you redirect to should obviously be small or you’re defeating the purpose. What you put in the image is up to you — people have had past success with retina-searing animations or the aforementioned » humourous replacement strategy.

If you would like instead to simply block the images completely and not redirect to another image, you can send back a “403 Forbidden” error message by replacing the RewriteRule above with this:

RewriteRule \.(jpe?g|gif|bmp|png)$ – [F]

Nobody’s Perfect…

There are some isolated cases when this won’t work. Some tools that allow people to surf “anonymously” will not send proper referrer headers, meaning that images will become broken on your own site for these visitors. Some proxies and firewalls will have the same effect. However, this won’t affect the vast majority of your visitors, and those who use referrer-hiding services are likely well aware of the side-effects.

Password protecting a folder using Apache

In general, all websites are freely viewable by anybody who wants to see them. Requiring a username and password to access various sensitive areas of your site allows you to restrict access to only a chosen few people who know the secret codes. In this tutorial I’ll present a method to secure a directory of documents by using a special Apache server configuration file.

Password protection through JavaScript

Before we get into this section, I present a minor caveat: using JavaScript to secure your website is an absolutely rubbish way to keep unwanted visitors out. If I encounter a site that tries to block access using JavaScript, it is a simple matter of temporarily disabling JavaScript in my browser to circumvent the dialog box. With no JavaScript, the link to the protected area of the site will work like any other normal link, and I will be able to roam free through the heretofore unseen depths of the site.

On top of this rather large chink in the armour, those pages will also be automatically indexed by search engines, leaving the private information accessible simply by searching for it.

So, given that any halfway competent infiltrator will easily be able to access a site secured only through JavaScript, I am not going to describe the method to do it, as there are significantly more secure ways to protect a section of your site that are much safer to use.

Using a .htaccess file

This special “.htaccess file”, which you may have encountered before if you’ve set up your own 404 error, is a configuration file for the Apache web server. It is just a text file with a special name that contains rules that your server will apply before it sends any files to a viewer of your site. These rules can change the URL of a page, create custom error messages, or in this case require a valid username and password to gain access to a certain area of the site.

These configuration files work on a directory basis, so if your site is at www.example.com and you place the .htaccess file in the root directory (where your index.html homepage is), the entire site will be off-limits and all visitors will need a password to view anything. This is generally not what you want, and so you will create a .htaccess file within a certain directory.

When you set up authorisation for a certain directory, that directory, all of its files, and any directories within it are all protected by this one file. You can have multiple different .htaccess file in multiple directories in your site if necessary.

To create the file, open your text editor and save a blank file as “.htaccess” in the directory you want to protect, noting that the filename starts with a dot. Windows users may find that they are told they can’t start a filename with a dot. If you get this error, use your FTP program to create the .htaccess file on your server and edit it there instead.

Setting up Authorisation

Now that we have our all-important .htaccess file, we’ll need to add the authorisation rules to it. Add these lines to your file:

AuthName “Section name”
AuthType Basic
AuthUserFile /.htpasswd
Require valid-user

Change the “Section name” to whatever the secure section of your website is called. This value will be placed in the dialog box when a user is asked for their details, so try to make it descriptive so that they know what they’re being asked for. The dialog looks like this in Firefox:

Firefox .htaccess authentication dialog box

If you save that file now and try to access this part of your website, you should be presented with a dialog box in your browser asking you for your username and password. Of course, there is no right answer yet because we haven’t set up any users. If you press Cancel in the dialog you will be given the standard “401 Authorization Required” error response code. This is what everyone will see if they log in incorrectly.

The .htpasswd file

To add valid users to our authentication scheme, we use a second file called a .htpasswd file. This file will hold a list of usernames and passwords. Because it contains potentially sensitive information, you should store it in a place that’s impossible to access from the web. This means putting it somewhere else on the server outside of your “web” or “www” directory where your website files are stored. Your hosting company will be able to help you place this file securely so that no ne’er-do-wells can access it.

Once you have secured this file, change the line in .htaccess that points to it. It’ll then look something like this:

AuthUserFile /usr/home/ross/.htpasswd

Finally, we just need to start adding valid users to this file. For added security, the passwords of your users aren’t stored in plain text in the .htpasswd file — they’re encrypted so that they can’t be read by a user snooping around the server. To add a user called “rustyleroo” with the password “flummox45”, we would add this line to the file:

rustyleroo:E2JbzVpOLlE6Y

As you can see, the password has been obfuscated into a strange form of gobbledegook. I derived this value (technically called a “hash”) by running the original password through an encryption program. There are lots of these available online (this one for example). You can add new users by adding new lines to this file, all in the form username:encryptedpassword.

Accessing the protected section

Now when you reload a file behind the authorisation wall, you enter a username and password into the dialog box. The server will encrypt this password again, and compare it to the encrypted version stored in the file to see if they match. If they do, you will be allowed to view the rest of the protected files as normal.

You can send the username and password to people in this format:

http://username:password@www.example.com/directory/

Clicking a link like that will log you in as the user at the start of the URL. Of course, you need to make sure that only the intended person gets their hands on this information.

Finally, to remove any password restrictions on your files, just delete the .htaccess file. For the final cherry on the cake, you can follow the steps in the 404 error tutorial, but instead set up a custom 401 error, so that users who log in incorrectly get a nicely-formatted error message.

Australian Web Hosting at its finest

You’ve successfully registered a new AUSWEB web hosting account.

logo

Founded in 2002, AUSWEB connects thousands of Australian businesses to the internet, with our services ranging from shared web hosting to virtual private servers, dedicated servers and Enterprise Cloud Solutions.
With all our servers and network based in a Sydney TIER3 Data Center (Equinix/Alexandria), AUSWEB provides a reliable local alternative to your online business needs.

Whether you are just getting started with your first website or are an IT Professional, you’ll appreciate the speed and features we offer with our range of plans with the ability to manage all aspects of your web hosting from the popular and user friendly cPanel Hosting Control Panel.

Our web hosting solutions are targeted to the Australian online market and our Australian servers provide the fastest connection speeds possible, whilst our 99.9% uptime guarantee provides peace of mind.

Why host in Australia?

australia-amag-tags-225x300With an increase of developers and small business looking at offshore alternatives to house their websites, we felt compelled to be frank about the reasons why you should choose an Australian host.

The 4 main pointers are:

  1. Latency
  2. SEO
  3. Support
  4. Economy

1. Latency

What is latency?

As defined by the Freedictionary.com:

latency – the time that elapses between a stimulus and the response to it

The speed of downloading or uploading data is dictated by a sequence of handovers of data between various networks starting at your device.

Your device, via your ISP connects to the server, demands the data from the remote server and receives the data, which is then relayed back to you by a route from the server’s ISP back to you via your ISP in the same manner as the initial connection.

In other words, it is one big daisy chain, which wraps around the Earth. That photo you upload to a social network does trips around the world faster than Superman, before you can ask “What exactly did I do last weekend?”.

Often you may wonder why downloading information from your local ISP is so fast (often reaching the ISP’s advertised speed…it is possible!) whilst downloads of half the size from an overseas FTP site might sluggishly drag along for hours? This is because the physical connection to your local server is shorter – just like the way it is with your phone landline!

If your small and static website is hosted overseas, latency is minimal as the volume of information relayed to and from you and the server is quite small, even though noticeable.

However, imagine hosting a large-scale CRM solution, or perhaps an elaborate Java application, which uses high quantities of bandwidth to run. The amount of data sent to and from the server increases, creating a time lag/delay which may often be problematic enough to cause packet loss or timeouts for users accessing it.

In a mission critical scenario, this is something which no business can afford to experience.

2. SEO

Your address is in Australia, your phone number is in Australia. You advertise in Australia to Australian customers. You’ve launched your shiny new site and put on your cork hat…but wait! Google knows your site is in America and naively assumes that yankees are going to want to purchase your novelty BBQ aprons with the boxing kangaroo.

Having your site hosted either in Australian or overseas is going to be detrimental to your carefully planned and fine-tuned SEO.

3. Support

We all know that calling technical support is everybody’s least favourite thing to do during the day!

Should anything go wrong, you would want to get help from somebody who does business when you do business and speaks the way in which you do. No more staying up until 4am to get a remote reboot, or password reset. Voila.

Timezones and proximity to the data center are crucial when things go pearshaped and the last thing one needs is extended periods of downtime because the datacenter is remote to the callcenter. Or yet worse, when the datacenter staff are in another timezone and sound asleep as you are ringing tech support to report peak-hour downtime in Australia!

Ausweb offers support with the confidence of a 24/7, 365 days a year monitoring of servers located in a Sydney city Datacenter, managed and supported from a Sydney city office, entirely by Sydney city staff.

4. Economy

Encouragement of healthy competition is crucial in our home soil and for competition to thrive, Australian web hosts must thrive too. We support you as an Australian business – we are one ourselves!

That and we eat our own brand of “dogfood”. The speed at which you have been able to access this very page is a testimony to the speed our clients appreciate daily as after all, this is just another website powered by Ausweb’s server cluster.

Get started today with some helpful links below: