> On 22.04.2024, at 11:01, David Osborne <da...@qcode.co.uk> wrote:
>
> In reverseproxymode, when there is a list of IPs in X-Forwarded-For header,
> it's always the leftmost IP which is chosen by NaviServer for accesslogs (and
> ns_conn peeraddr):
>
> X-Forwarded-For 1.1.1.1,2.2.2.2
> ns_conn peeraddr -source forwarded = 1.1.1.1
>
> Is there any mechanism by which we can resolve to the rightmost IP for the
> access logs instead?
In case, there is only one forwarded-for entry received by NaviServer,
everything is fine in all situations. In case x-forwarded-for has multiple
values and gets its content from trusted and well-configured proxies, the
leftmost value is the original value of the client
X-Forwarded-For: client, proxy1, proxy2
The rightmost value is from is the last proxy.
From a security point of view, if there is no trust in the proxies, it is
certainly easy for an attacker to inject a wrong IP-address of the client to
the forwarded-for header. Therefore, various reverse proxy server have
mechanisms to define trusted upstream proxies, from which these values are
accepted. So, probably the right approach is to accept in nginx configuration
only incoming x-forwarded-for headers from trusted sources (or drop all, if
there are no trusted upstream servers). nginx-rule for replacing incoming
x-forwarded-for headers with the remote address:
proxy_set_header X-Forwarded-For $remote_addr;
Note that it is possible that a request can contain multiple x-forwarded-for
headers, which should be logically concatenated. NaviServer just takes the
first one (corresponding the leftmost value) and shows therefore a consistent
behaviour.
However, the implementation in NaviServer is certainly not perfect. When
handling of multiple proxy servers is required (larger network of proxies) and
e.g. a client and a proxy are from a private network (having non-routable
addresses), and these requests are routed over proxies in public networks, the
internal addresses would not be informative for most purposes (geo-location,
etc.) and should not be used. Instead, the first routable, valid address from
the left should be taken.
As another improvement, NaviServer should support the standardised “Forwarded”
header, but its content can't be trusted as well. So, i am not sure, this would
help.
Why are you looking into the issue? Would the filtering of private addresses
help you?
-gn
_______________________________________________
naviserver-devel mailing list
naviserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/naviserver-devel
