Re: Adopting mod_remoteip to modules/metadata/ ?
Colm MacCárthaigh wrote: I don't think permitting hostname/number is a good idea, because a hostname can map to multiple IPs, and it gets confusing, it's non-standard :-) Right now the code just does a single lookup, and uses that - so where there are multiple A/ records we'll have random behaviour. Very true. I'm now walking that lookup and have coded to prohibit namedhost/scope syntax. I'm not sure that I think hard-coding RFC1918 addresses is a good idea. RFC3330 is more authoratitive for a start, and there's no correspending code for IPv6 (e.g. the documentation prefixes, link-local scope, site-local scope, and so on). Reviewing the 3330 list - these are mostly either 'normal' or 'returning to normal' deviations from 1918. All we really seek to dodge are well defined shared IP spaces, so I simplified this a bit. From http://www.iana.org/assignments/ipv6-address-space there appears to be one and only one sensical assignment, the Global Unicast per note [3]. Either way, I think it's inaccurate to assume that there is anything special about RFC1918 space, the user should be forced to configure those ranges. Many networks have differing levels of trust and overlapping usages for that space, and many others use globally-unique IPs in private contexts. Exactly. This is why we partition trusted (internet peer) from internal (1918 intranet peer). The typical trusted host might give us one of their private addresses, we cannot use that because it isn't partnered with our own private address space. If an internal, intranet peer presents us with such a remote host, we simply accept it. Let's say you grant some special security to 10. for your intranet. We never want trusted but external peers polluting that space, nor would we want to consider 10.0.1.15 at one peer to be identical to 10.0.1.15 at yet another peer. Looks cool though. We might need to add some docs warning peolpe that the address might no longer match the address family of the actual socket. That's already true ;-) But you are right, we should note that. AIUI, all IPv4-over-v6 addresses decode into v4 form already for remote_host lookups. Bill
Re: Adopting mod_remoteip to modules/metadata/ ?
On Wed, Apr 1, 2009 at 12:45 AM, William A. Rowe, Jr. wr...@rowe-clan.netwrote: I have essentially finished mod_remoteip at this point and am looking to find out the interest level of adopting this as a core module into trunk (modules/metadata/ appears to be the most appropriate target)? +1 :-) RemoteIPTrustedProxy 192.168.0. localhost/8 I don't think permitting hostname/number is a good idea, because a hostname can map to multiple IPs, and it gets confusing, it's non-standard :-) Right now the code just does a single lookup, and uses that - so where there are multiple A/ records we'll have random behaviour. I'm not sure that I think hard-coding RFC1918 addresses is a good idea. RFC3330 is more authoratitive for a start, and there's no correspending code for IPv6 (e.g. the documentation prefixes, link-local scope, site-local scope, and so on). Either way, I think it's inaccurate to assume that there is anything special about RFC1918 space, the user should be forced to configure those ranges. Many networks have differing levels of trust and overlapping usages for that space, and many others use globally-unique IPs in private contexts. Looks cool though. We might need to add some docs warning peolpe that the address might no longer match the address family of the actual socket. -- Colm
Re: Adopting mod_remoteip to modules/metadata/ ?
Graham Leggett wrote: William A. Rowe, Jr. wrote: I have essentially finished mod_remoteip at this point and am looking to find out the interest level of adopting this as a core module into trunk (modules/metadata/ appears to be the most appropriate target)? +1. That's two of us; I'm still looking for at least one more opinion. I had to code up a similar feature recently in something that needed to know the end user's IP address, this will be very useful for apps behind load balancers and reverse proxies. I've heard similar from others, which is why this seems appropriate for the core distribution, even if it's not enabled by 'most'.
Re: Adopting mod_remoteip to modules/metadata/ ?
William A. Rowe, Jr. wrote: I have essentially finished mod_remoteip at this point and am looking to find out the interest level of adopting this as a core module into trunk (modules/metadata/ appears to be the most appropriate target)? +1. I had to code up a similar feature recently in something that needed to know the end user's IP address, this will be very useful for apps behind load balancers and reverse proxies. If I get enough +1's this week I'll move the module and whip up some docs, but in the meantime, here's the experimental config I was working with; RemoteIpHeader X-IP RemoteIpProxiesHeader X-Via-IP RemoteIPTrustedProxy 192.168.0. localhost/8 RemoteIPInternalProxy 192.168.1 RemoteIPInternalProxyList conf/internal.lst RemoteIPTrustedProxyList conf/trusted-xff.lst Header echo X-Via-IP Header echo X-IP (the trusted-xff.lst is from the wikimedia XFF project). (Having not yet had a chance to look at the code) How is the possibility of multiple IPs in the same header handled, eg: X-Fowarded-For: 10.2.3.4, 10.11.12.13 Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
Re: Adopting mod_remoteip to modules/metadata/ ?
Graham Leggett wrote: (Having not yet had a chance to look at the code) How is the possibility of multiple IPs in the same header handled, eg: X-Fowarded-For: 10.2.3.4, 10.11.12.13 I think you'll find your question is answered in the README I referenced. It's handled fine. The interesting point is that, presuming that the nearest remote_host and 10.11.12.13 both have 'Internal' trust, meaning they are know to our network, while 67.151.55.1 and 178.21.1.10 are given TrustedProxy status, we would still refuse to acknowledge another networks private subnet. Therefore; X-Fowarded-For: 10.2.3.4, 67.151.55.1 178.21.1.10, 10.11.12.13 results in a remote_host 67.151.55.1, and the header value is updated to reflect that this host still makes an X-Forwarded-For assertion, e.g. X-Fowarded-For: 10.2.3.4 Will we someday introduce a feature to treat this as a decorated remote host name of something like 67.151.55.1_10.2.3.4 - I'd suggest we could but that feature could break any number of thirdparty modules attempting to resolve this address.
Adopting mod_remoteip to modules/metadata/ ?
I have essentially finished mod_remoteip at this point and am looking to find out the interest level of adopting this as a core module into trunk (modules/metadata/ appears to be the most appropriate target)? mod_remoteip can deal with 2 situations effortlessly, one is the absolute initialization of an X-IP style header by the load balancer, where the load balancer is ignored as the remote host. The second is using X-Forwarded-For headers to process the client of the recognized proxies as the actual remote host. Currently there is no way to use two different headers, although that might change in the future if there was sufficient interest. See http://svn.apache.org/repos/asf/httpd/sandbox/mod_remoteip/README which needs to be translated into documentation, and of course the source; http://svn.apache.org/repos/asf/httpd/sandbox/mod_remoteip/mod_remoteip.c If I get enough +1's this week I'll move the module and whip up some docs, but in the meantime, here's the experimental config I was working with; RemoteIpHeader X-IP RemoteIpProxiesHeader X-Via-IP RemoteIPTrustedProxy 192.168.0. localhost/8 RemoteIPInternalProxy 192.168.1 RemoteIPInternalProxyList conf/internal.lst RemoteIPTrustedProxyList conf/trusted-xff.lst Header echo X-Via-IP Header echo X-IP (the trusted-xff.lst is from the wikimedia XFF project).
