"Fossies" - the Fresh Open Source Software Archive
As a special service "Fossies" has tried to format the requested text file into HTML format (style: standard
) with prefixed line numbers.
Alternatively you can here view
the uninterpreted source code file.
2 mod_extract_forwarded is designed to transparently modify a connection so
3 that it looks like it came from the IP behind a proxy server rather than
4 the proxy itself. This affects all subsequent stages of request processing
5 including access control, logging, and CGIs. It relies on the
6 "X-Forwarded-For" header to do this. This header should be added by all
7 well-behaved proxies. If the proxy doesn't add it, we can't do anything
8 about it.
10 It's possible for a request to pass thru multiple proxies on its request
11 path in which case X-Forwarded-For should contain multiple IPs. You will
12 build a list of trusted proxies (see below) and the first IP in the header
13 which is not trusted will be used as the client IP.
15 Since we are altering the connection record to remove references to the
16 actual connecting IP, it might be useful to remember that IP somewhere. We
17 store it in the environment variable PROXY_ADDR immediately before
18 altering the connection record. So CGIs have access to PROXY_ADDR if they
19 need it. Other Apache modules can also get to PROXY_ADDR via the
20 request_rec's subprocess_env table.
22 Using this module has potentially serious implications for host-based
23 access control to your server. Since "X-Forwarded-For" is just a piece of
24 text in a request header spoofing it is trivial. To compensate for this
25 mod_extract_forwarded provides configuration directives to restrict the
26 proxy hosts for which X-Forwarded-For will be processed. Disallowing a
27 proxy host with these directives doesn't mean the proxy can't get pages
28 from your server, it just means the forwarded IP won't be used. It is
29 _strongly_ advised that you only process "X-Forwarded-For" from proxies
30 you trust.
32 If a request has passed through multiple proxies then the X-Forwarded-For
33 may contain several IPs like this:
35 X-Forwarded-For: client1, proxy1, proxy2
37 Additionally there is the IP of the requesting host itself which is not
38 included in the header. Let's say the requesting host is proxy3. First we
39 check that the connecting host is in the allow list. Then we traverse the
40 header from right to left and the first encountered IP which is not in the
41 allow list will be treated as the client IP. For example if proxy1,
42 proxy2, and proxy3 are in the allow list then in the above header client1
43 would be shown as the connecting IP. But in the below header:
45 X-Forwarded-For: client1, untrusted1, proxy1, proxy2
47 untrusted1 would be shown as the connecting IP even though untrusted1 is
48 proxying for client1. (Because untrusted1 might be lying.)
50 There is also a directive for allow or disallowing the proxies to cache
51 the returned content. You may find yourself in a situation where there may
52 be some hosts behind a caching proxy which are allowed access to a URI but
53 other hosts behind the same proxy which are not allowed. If the proxy
54 caches the content when it responds to an allowed client, it might not
55 re-check with your server before giving the cached content to another
56 client. If you find yourself in this situation use
57 AllowForwarderCaching (described below) to deactivate caching for
58 locations with protected content.
60 The configuration directives are as follows:
62 AllowForwarderCaching: On or Off - will we allow any caches along the
63 request path to cache this response?
65 AddAcceptForwarder: add this IP or hostname to the list of hosts from
66 which we will honor the "X-Forwarded-For" header.
68 RemoveAcceptForwarder: remove this IP or hostname from the list of hosts
69 built with AddAcceptForwarder.
71 If no directives are found the default is to ignore X-Forwarded-For from
72 all proxies and to allow caching. In other words if you load the module
73 but don't configure it, it doesn't do anything.
75 Like many other directives you may specify these at "top level" outside
76 any container directives, then you may specify overriding directives
77 inside containers. You may also use them inside .htaccess files if
78 AllowOverride Options is in effect. The effect of the directives is
79 cumulative. Example:
81 AddAcceptForwarder 10.0.0.1
82 AddAcceptForwarder 10.0.0.2
83 AllowForwarderCaching On
85 <Location /foobar>
86 RemoveAcceptForwarder 10.0.0.2
87 AllowForwarderCaching Off
90 So now inside /foobar 10.0.0.1 is still accepted but 10.0.0.2 is not, but
91 10.0.0.1 is not allowed to cache responses. (Perhaps /foobar contains some
92 sensitive content.)
94 AddAcceptForwarder and RemoveAcceptForwarder also take an "all" keyword
95 which does exactly that - "AddAcceptForwarder all" will accept
96 X-Forwarded-For from all proxies and "RemoveAcceptForwarder all" will
97 totally blank the accept list. The "all" keyword makes possible something
98 like this:
100 AddAcceptForwarder all
101 RemoveAcceptFowarder 10.0.0.3
103 <Location /foobaz>
104 RemoveAcceptForwarder all
105 AddAcceptFowarder 10.0.0.4
108 At top level we accept from all proxies _except_ 10.0.0.3. Inside /foobaz
109 we totally blank the accept list and then accept from _only_ 10.0.0.4.
111 The ordering in which the directives appear in a container is not fixed,
112 but the order of their processing is explicit:
114 (1) RemoveAcceptForwarder all
115 (2) AddAcceptForwarder all
116 (3) any other RemoveAcceptForwarders
117 (4) any other AddAcceptForwarders
119 Those rules might seem restrictive at first but in practice you won't even
120 have to know them. They are based on the premise that you won't try to
121 remove your own AddAcceptForwarders inside the same container. If you do
122 (why?!) you won't get what your expect. But on the whole the rules will
123 behave very naturally.
126  I wasn't able to get squid 2.2 to do this (i.e. give cached content to
127 a disallowed client) but I also haven't tried any other proxies. The
128 possibility is always there. Once the content is cached, you've lost
129 control of it.
131  The reasoning here is that since we're not honoring any
132 X-Forwarded-Fors we can't be spoofed, so caching is safe. As soon as you
133 put in your first AddAcceptForwarder you should think about caching.
137 $Id: README,v 1.5 2003/03/18 21:27:31 ahosey Exp $