| <?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</a></seealso> |
| <seealso><a href="avoid.html">When not to use mod_rewrite</a></seealso> |
| |
| <section id="blocked-inline-images"> |
| |
| <title>Forbidding Image "Hotlinking"</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 "hotlinking", 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> |
| |
| <!-- TODO: Add discussion here of why we have !^$ in there. --> |
| |
| <highlight language="config"> |
| RewriteCond "%{HTTP_REFERER}" "!^$" |
| RewriteCond "%{HTTP_REFERER}" "!www.example.com" [NC] |
| RewriteRule "\.(gif|jpg|png)$" "-" [F,NC] |
| </highlight> |
| |
| <p>In this second example, instead of failing the request, we display |
| an alternate image instead.</p> |
| |
| <highlight language="config"> |
| RewriteCond "%{HTTP_REFERER}" "!^$" |
| RewriteCond "%{HTTP_REFERER}" "!www.example.com" [NC] |
| RewriteRule "\.(gif|jpg|png)$" "/images/go-away.png" [R,NC] |
| </highlight> |
| |
| <p>In the third example, we redirect the request to an image on some |
| other site.</p> |
| |
| <highlight language="config"> |
| RewriteCond "%{HTTP_REFERER}" "!^$" |
| RewriteCond "%{HTTP_REFERER}" "!www.example.com" [NC] |
| RewriteRule "\.(gif|jpg|png)$" "http://other.example.com/image.gif" [R,NC] |
| </highlight> |
| |
| <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> |
| |
| <highlight language="config"> |
| SetEnvIf Referer "example\.com" localreferer |
| <FilesMatch "\.(jpg|png|gif)$"> |
| Require env localreferer |
| </FilesMatch> |
| </highlight> |
| </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 wish 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> |
| |
| <highlight language="config"> |
| RewriteCond "%{HTTP_USER_AGENT}" "^NameOfBadRobot" |
| RewriteCond "%{REMOTE_ADDR}" "=123\.45\.67\.[8-9]" |
| RewriteRule "^/secret/files/" "-" [F] |
| </highlight> |
| </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> |
| <highlight language="config"> |
| SetEnvIfNoCase User-Agent "^NameOfBadRobot" goaway |
| <Location "/secret/files"> |
| <RequireAll> |
| Require all granted |
| Require not env goaway |
| </RequireAll> |
| </Location> |
| </highlight> |
| <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> |
| <highlight language="config"> |
| RewriteEngine on |
| RewriteMap hosts-deny "txt:/path/to/hosts.deny" |
| RewriteCond "${hosts-deny:%{REMOTE_ADDR}|NOT-FOUND}" "!=NOT-FOUND" [OR] |
| RewriteCond "${hosts-deny:%{REMOTE_HOST}|NOT-FOUND}" "!=NOT-FOUND" |
| RewriteRule "^" "-" [F] |
| </highlight> |
| |
| <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> |
| |
| <highlight language="config"> |
| RewriteMap deflector "txt:/path/to/deflector.map" |
| |
| RewriteCond "%{HTTP_REFERER}" !="" |
| RewriteCond "${deflector:%{HTTP_REFERER}}" "=-" |
| RewriteRule "^" "%{HTTP_REFERER}" [R,L] |
| |
| RewriteCond "%{HTTP_REFERER}" !="" |
| RewriteCond "${deflector:%{HTTP_REFERER}|NOT-FOUND}" "!=NOT-FOUND" |
| RewriteRule "^" "${deflector:%{HTTP_REFERER}}" [R,L] |
| </highlight> |
| |
| <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> |
| |
| <highlight language="config"> |
| ## |
| ## deflector.map |
| ## |
| |
| http://badguys.example.com/bad/index.html - |
| http://badguys.example.com/bad/index2.html - |
| http://badguys.example.com/bad/index3.html http://somewhere.example.com/ |
| </highlight> |
| |
| </dd> |
| </dl> |
| |
| </section> |
| |
| </manualpage> |