<?xml version="1.0" encoding="UTF-8" ?>

<!DOCTYPE manualpage SYSTEM "/style/manualpage.dtd">

<?xml-stylesheet type="text/xsl" href="/style/manual.en.xsl"?>

<manualpage metafile="access.xml.meta">

<parentdocument href="./">Rewrite</parentdocument>

<title>Using mod_rewrite to control access</title>

<summary>

<p>This document supplements the <module>mod_rewrite</module>

<a href="/mod_rewrite.html">reference documentation</a>. It describes

how you can use <module>mod_rewrite</module> to control access to

various resources, and other related techniques.

This includes many examples of common uses of mod_rewrite,

including detailed descriptions of how each works.</p>

<note type="warning">Note that many of these examples won't work unchanged in your

particular server configuration, so it's important that you understand

them, rather than merely cutting and pasting the examples into your

configuration.</note>

</summary>

<seealso><a href="/mod/mod_rewrite.html">Module documentation</a></seealso>

<seealso><a href="intro.html">mod_rewrite introduction</a></seealso>

<section id="blocked-inline-images">

<title>Forbidding Image &quot;Hotlinking&quot;</title>

<dl>

<dt>Description:</dt>

<dd>

<p>The following technique forbids the practice of other sites

including your images inline in their pages. This practice is

often referred to as &quot;hotlinking&quot;, and results in

your bandwidth being used to serve content for someone else's

site.</p>

</dd>

<dt>Solution:</dt>

<dd>

<p>This technique relies on the value of the

<code>HTTP_REFERER</code> variable, which is optional. As

such, it's possible for some people to circumvent this

limitation. However, most users will experience the failed

request, which should, over time, result in the image being

removed from that other site.</p>

<p>There are several ways that you can handle this

situation.</p>

<p>In this first example, we simply deny the request, if it didn't

initiate from a page on our site. For the purpose of this example,

we assume that our site is <code>www.example.com</code>.</p>

<example><pre>

RewriteCond %{HTTP_REFERER} <strong>!^$</strong>

RewriteCond %{HTTP_REFERER} !www.example.com [NC]

RewriteRule <strong>\.(gif|jpg|png)$</strong> - [F,NC]

</pre></example>

<p>In this second example, instead of failing the request, we display

an alternate image instead.</p>

<example><pre>

RewriteCond %{HTTP_REFERER} <strong>!^$</strong>

RewriteCond %{HTTP_REFERER} !www.example.com [NC]

RewriteRule <strong>\.(gif|jpg|png)$</strong> /images/go-away.png [R,NC]

</pre></example>

<p>In the third example, we redirect the request to an image on some

third-party site.</p>

<example><pre>

RewriteCond %{HTTP_REFERER} <strong>!^$</strong>

RewriteCond %{HTTP_REFERER} !www.example.com [NC]

RewriteRule <strong>\.(gif|jpg|png)$</strong> http://other.site.com/image.gif [R,NC]

</pre></example>

<p>Of these techniques, the last two tend to be the most effective

in getting people to stop hotlinking your images, because they will

simply not see the image that they expected to see.</p>

</dd>

<dt>Discussion:</dt>

<dd>

<p>If all you wish to do is deny access to the resource, rather

than redirecting that request elsewhere, this can be

accomplished without the use of mod_rewrite:</p>

<example>

SetEnvIf Referer example\.com localreferer<br />

&lt;FilesMatch \.(jpg|png|gif)$&gt;<br />

Order deny,allow<br />

Deny from all<br />

Allow from env=localreferer<br />

&lt;/FilesMatch&gt;

</example>

</dd>

</dl>

</section>

<section id="blocking-of-robots">

<title>Blocking of Robots</title>

<dl>

<dt>Description:</dt>

<dd>

<p>

In this recipe, we discuss how to block persistent requests from

a particular robot, or user agent.</p>

<p>The standard for robot exclusion defines a file,

<code>/robots.txt</code> that specifies those portions of your

website where you which to exclude robots. However, some robots

do not honor these files.

</p>

<p>Note that there are methods of accomplishing this which do

not use mod_rewrite. Note also that any technique that relies on

the clients <code>USER_AGENT</code> string can be circumvented

very easily, since that string can be changed.</p>

</dd>

<dt>Solution:</dt>

<dd>

<p>We use a ruleset that specifies the directory to be

protected, and the client <code>USER_AGENT</code> that

identifies the malicious or persistent robot.</p>

<p>In this example, we are blocking a robot called

<code>NameOfBadRobot</code> from a location

<code>/secret/files</code>. You may also specify an IP address

range, if you are trying to block that user agent only from the

particular source.</p>

<example><pre>

RewriteCond %{HTTP_USER_AGENT} ^<strong>NameOfBadRobot</strong>

RewriteCond %{REMOTE_ADDR} =<strong>123\.45\.67\.[8-9]</strong>

RewriteRule ^<strong>/secret/files/</strong> - [<strong>F</strong>]

</pre></example>

</dd>

<dt>Discussion:</dt>

<dd>

<p>

Rather than using mod_rewrite for this, you can accomplish the

same end using alternate means, as illustrated here:

</p>

<example>

SetEnvIfNoCase User-Agent ^NameOfBadRobot goaway<br />

&lt;Location /secret/files&gt;<br />

Order allow,deny<br />

Allow from all<br />

Deny from env=goaway<br />

&lt;/Location&gt;

</example>

<p>

As noted above, this technique is trivial to circumvent, by simply

modifying the <code>USER_AGENT</code> request header. If you

are experiencing a sustained attack, you should consider blocking

it at a higher level, such as at your firewall.

</p>

</dd>

</dl>

</section>

</manualpage>