Hi David,
I have now implemented the following (but not yet committed,
since i was side-tracked by some tcl9 issues and i am running out of
time.
From my understanding, this should address your problems now,
and when “proxy 2” is removed.
An easy extension of this would be to let the site-admin configure
an alternative header field (like x-real-ip), which could bypass
the search through the list of candidate addresses.
all the best
-gn
=========================================================
Traditionally, NaviServer has implemented x-forwarded-for handling in
the simplest way, by treating the first value in the x-forwarded-for
header as the client (see also [1] for a brief description). This
works well for the most part in many production environments.
There are two potential problems with this:
a) If the client is connecting from a private network through
potentially multiple proxy servers, the private address
(e.g. 192.168.1.100) may end up as the peer (and also e.g. in the
access.log), which is not useful for any kind of analysis.
b) If the client itself sends a (faked) "X-Forwarded-For" header, it
can privide whatever it wants as header value.
One measure is for a reverse proxy to only accept X-Forwarded-For
headers from trusted sources, or to always treat its peer as a client
(providing the peer address in the header field).
This can lead to some loss of information if there are multiple proxy
servers in the chain, and sometimes, it is not possible for an
application to influence the proxy server configuration.
The new version now has two modes, the first being an extension of the
classic mode, and the second being better for untrusted header
content.
The default mode processes the address list from left to right,
skipping private addresses. If the received "x-forwarded-for header
contains, for example, "192.168.1.100 1.1.1.1 2.2.2.2", then "1.1.1.1"
will be used as the client IP address.
Alternatively, when the NaviServer site admin configures trusted
reverse proxy servers in the configuration file (either by IP address
or in CDIR notation)
ReverseProxyTrustedServers {192.168.0.0/16 137.208.89.213}
then the "x-forwarded-for" header will only be accepted from trusted
servers (otherwise the header will be ignored). In addition, the
address list is processed from right to left, skipping known trusted
reverse proxies. This reduces the problem of spoofed addresses. In the
address list "142.251.208.110 1.1.1.1 192.168.2.10", the trusted
reverse proxy "192.168.2.10" is skipped and "1.1.1.1" is used (instead
of the spoofed Google IP).
Note: Only when NaviServer receives multiple entries in the
"x-forwarded-for" header is there a difference between these two
modes.
[1] https://en.wikipedia.org/wiki/X-Forwarded-For
_______________________________________________
naviserver-devel mailing list
naviserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/naviserver-devel
