docs/manual/rewrite/access.xml

<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE manualpage SYSTEM "../style/manualpage.dtd">
<?xml-stylesheet type="text/xsl" href="../style/manual.en.xsl"?>
<!-- $LastChangedRevision$ -->

<!--
 Licensed to the Apache Software Foundation (ASF) under one or more
 contributor license agreements.  See the NOTICE file distributed with
 this work for additional information regarding copyright ownership.
 The ASF licenses this file to You under the Apache License, Version 2.0
 (the "License"); you may not use this file except in compliance with
 the License.  You may obtain a copy of the License at

     http://www.apache.org/licenses/LICENSE-2.0

 Unless required by applicable law or agreed to in writing, software
 distributed under the License is distributed on an "AS IS" BASIS,
 WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
 See the License for the specific language governing permissions and
 limitations under the License.
-->

<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/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>
<seealso><a href="remapping.html">Redirection and remapping</a></seealso>
<!-- <seealso><a href="access.html">Controlling access</a></seealso> -->
<seealso><a href="vhosts.html">Virtual hosts</a></seealso>
<seealso><a href="proxy.html">Proxying</a></seealso>
<seealso><a href="rewritemap.html">Using RewriteMap</a></seealso>
<seealso><a href="advanced.html">Advanced techniques and tricks</a></seealso>
<seealso><a href="avoid.html">When not to use mod_rewrite</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>
RewriteCond %{HTTP_REFERER} <strong>!^$</strong><br />
RewriteCond %{HTTP_REFERER} !www.example.com [NC]<br />
RewriteRule <strong>\.(gif|jpg|png)$</strong>    -   [F,NC]
</example>

    <p>In this second example, instead of failing the request, we display
    an alternate image instead.</p>

<example>
RewriteCond %{HTTP_REFERER} <strong>!^$</strong><br />
RewriteCond %{HTTP_REFERER} !www.example.com [NC]<br />
RewriteRule <strong>\.(gif|jpg|png)$</strong>    /images/go-away.png   [R,NC]
</example>

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

<example>
RewriteCond %{HTTP_REFERER} <strong>!^$</strong><br />
RewriteCond %{HTTP_REFERER} !www.example.com [NC]<br />
RewriteRule <strong>\.(gif|jpg|png)$</strong> http://other.example.com/image.gif   [R,NC]
</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>
RewriteCond %{HTTP_USER_AGENT}   ^<strong>NameOfBadRobot</strong><br />
RewriteCond %{REMOTE_ADDR}       =<strong>123\.45\.67\.[8-9]</strong><br />
RewriteRule ^<strong>/secret/files/</strong>   -   [<strong>F</strong>]
</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>

<section id="host-deny">

  <title>Denying Hosts in a Blacklist</title>

  <dl>
    <dt>Description:</dt>

    <dd>
      <p>We wish to maintain a blacklist of hosts, rather like
      <code>hosts.deny</code>, and have those hosts blocked from
      accessing our server.</p>
    </dd>

    <dt>Solution:</dt>

    <dd>
<example>
RewriteEngine on<br />
RewriteMap    hosts-deny  txt:/path/to/hosts.deny<br />
RewriteCond   ${hosts-deny:%{REMOTE_ADDR}|NOT-FOUND} !=NOT-FOUND [OR]<br />
RewriteCond   ${hosts-deny:%{REMOTE_HOST}|NOT-FOUND} !=NOT-FOUND<br />
RewriteRule   ^  -  [F]
</example>

<example>
##<br />
##  hosts.deny<br />
##<br />
##  ATTENTION! This is a map, not a list, even when we treat it as such.<br />
##             mod_rewrite parses it for key/value pairs, so at least a<br />
##             dummy value "-" must be present for each entry.<br />
##<br />
<br />
193.102.180.41 -<br />
bsdti1.sdm.de  -<br />
192.76.162.40  -<br />
</example>
    </dd>

    <dt>Discussion:</dt>
    <dd>
    <p>
    The second RewriteCond assumes that you have HostNameLookups turned
    on, so that client IP addresses will be resolved. If that's not the
    case, you should drop the second RewriteCond, and drop the
    <code>[OR]</code> flag from the first RewriteCond.
    </p>
    </dd>
  </dl>

</section>

<section id="referer-deflector">

  <title>Referer-based Deflector</title>

  <dl>
    <dt>Description:</dt>

    <dd>
      <p>Redirect requests based on the Referer from which the request
      came, with different targets per Referer.</p>
    </dd>

    <dt>Solution:</dt>

    <dd>
  <p>The following ruleset uses a map file to associate each Referer
  with a redirection target.</p>

<example>
RewriteMap  deflector txt:/path/to/deflector.map<br />
<br />
RewriteCond %{HTTP_REFERER} !=""<br />
RewriteCond ${deflector:%{HTTP_REFERER}} =-<br />
RewriteRule ^ %{HTTP_REFERER} [R,L]<br />
<br />
RewriteCond %{HTTP_REFERER} !=""<br />
RewriteCond ${deflector:%{HTTP_REFERER}|NOT-FOUND} !=NOT-FOUND<br />
RewriteRule ^.* ${deflector:%{HTTP_REFERER}} [R,L]
</example>

      <p>The map file lists redirection targets for each referer, or, if
      we just wish to redirect back to where they came from, a "-" is
      placed in the map:</p>

<example>
##<br />
##  deflector.map<br />
##<br />
<br />
http://badguys.example.com/bad/index.html    -<br />
http://badguys.example.com/bad/index2.html   -<br />
http://badguys.example.com/bad/index3.html   http://somewhere.example.com/
</example>

    </dd>
  </dl>

</section>

</manualpage>