On 03/16/2017 10:34 AM, Sander Hoentjen wrote:
>
> On 03/11/2017 07:57 PM, Daniel Ruggeri wrote:
>> Thanks, all, for the patience as I finally got back to this.
>>
>> On 2/24/2017 11:05 AM, Sander Hoentjen wrote:
>>> On 02/20/2017 07:48 PM, William A Rowe Jr wrote:
>>>> On Sat, Feb 18, 2017 at 4:25 PM, Daniel Ruggeri <drugg...@apache.org>
>>>> wrote:
>>>>> On 2017-02-15 09:07 (-0600), William A Rowe Jr <wr...@rowe-clan.net>
>>>>> wrote:
>>>>>> On Wed, Feb 15, 2017 at 9:02 AM, Sander Hoentjen <san...@hoentjen.eu>
>>>>>> wrote:
>>>>>>> mod_remote ip has:
>>>>>>> /* mod_proxy creates outgoing connections - we don't want those */
>>>>>>> if (!remoteip_is_server_port(c->local_addr->port)) {
>>>>>>> return DECLINED;
>>>>>>> }
>>>>>>> I am guessing something similar is needed for h2 connections?
>>>>>> I suspect that the mod_remoteip logic is wrong, that it should be
>>>>>> guarding
>>>>>> against any subordinate connections and examining only explicitly
>>>>>> configured
>>>>>> ports / origin IPs. the PROXY protocol is not part of the HTTP protocol
>>>>>> and
>>>>>> incompatible with it, so the trust list logic isn't directly compatible
>>>>>> (this is
>>>>>> clearly explained in the PROXY pseudo-RFC.)
>>>>>>
>>>>> Hi, Bill. That is what the module is doing. The original authors wrote it
>>>>> to have a list of virtual hosts it is explicitly enabled for and
>>>>> explicitly disabled for. I added a third list for optional vhosts. In the
>>>>> pre_connection hook, it checks to see if the connection's local_addr
>>>>> (which should normally be the server's IP) is explicitly configured to
>>>>> enable PROXY handling. It then checks to see if the local port is a
>>>>> server port.
>>>>>
>>>>> Looking at the logs shared, 192.168.122.249:84 is the server IP:Port
>>>>> combo and is also the local IP:Port from mod_h2. If h2 sets the master of
>>>>> this connection, then we could skip the whole ordeal with this patch:
>>>>>
>>>>> Index: modules/metadata/mod_remoteip.c
>>>>> ===================================================================
>>>>> --- modules/metadata/mod_remoteip.c (revision 1781701)
>>>>> +++ modules/metadata/mod_remoteip.c (working copy)
>>>>> @@ -862,6 +862,10 @@
>>>>> remoteip_conn_config_t *conn_conf;
>>>>> int optional;
>>>>>
>>>>> + if (c->master != NULL) {
>>>>> + return DECLINED;
>>>>> + }
>>>>> +
>>>>> conf = ap_get_module_config(ap_server_conf->module_config,
>>>>> &remoteip_module);
>>>>>
>>>>> .. but I don't know if that potentially means we are looking at the wrong
>>>>> connection.
>>> First I'll say that with the "Optional" mode it worked, just not with On
>>> I just tried this patch and as far as I have tested this seems to work
>>> fine in On mode, as well as in Optional. I do see some other issue, but
>>> that is probably in my own code, I'll try to track that down later.
>> This is good news and about what I was expecting to happen. I will add
>> this to the commit I've got coming that incorporates a lot of Ruediger's
>> feedback.
>>
>>>> That should be close, but need to ensure c->master is initialized for
>>>> http as well
>>>> where there is no master/subordinate.
>>> I am not sure what this means, how should I test this?
>> Hi, Bill - also hoping for a bit more input. Since PROXY protocol is not
>> tied to any particular layer 7 protocol, I don't think we'd have to
>> verify it is initialized for HTTP - just that there is no master at all.
>> At least, that's my understanding so I appreciate any corrections.
> Here are my changes by the way:
> https://github.com/AntagonistHQ/httpd/commit/2d208793b4494e73289477c231c79be9e0030a2b
>> Sure, to clarify, the Optional use case came from a member on one of our
>> cousin projects (Tomcat) Chris Schultz as well as my own use cases. It
>> is useful for internally accessing the site from behind the
>> loadbalancer. When there is a publicly addressed upstream loadbalancer
>> (Amazon ELB or just HAProxy itself) talking to RFC1918 addressed or
>> non-routeable backend httpd servers, it becomes impossible to enable
>> internal communication on the RFC1918 space to the backend instances.
>> If the goal is to monitor or probe the site and (httpd proxy) backends
>> internally for health, this *can* be done by duplicating the virtual
>> hosts. Depending on the complexity of the virtual hosts, what resources
>> those virtual hosts have (proxies and whatnot) and their general size,
>> this could result in a fairly unmanageable httpd configuration having a
>> vhost that requires PROXY header and a second one on a different port or
>> IP that does not.
>> It gets even more complicated when you are aiming to do management
>> tasks. If you have balancers configured at the vhost as intended, you
>> can only manage those balancers from the vhost they live in. Further,
>> you may want to view server statistics, check info about the ldap cache,
>> etc but permit access to those things only from a trusted network in
>> addition to the user credentials protecting it.
>> So for those examples, aside from creating an internal HAProxy to
>> provide the header, it's not really possible to access the site
>> internally when "On". With "Optional" it's possible to keep the same
>> number of vhosts and enable the various management handlers and restrict
>> them to the RFC1918 space (plus any other authnz mechanisms). The other
>> obvious option would be to enable those handlers to the public Internet,
>> but that's bad juju :-)
>>
> Well maybe what I am doing is wrong, but I just add a port to my vhosts,
> so I have:
> <VirtualHost $some_ip:80 $some_ip:83 >
> and then I also have:
> <VirtualHost *:83>
> RemoteIPProxyProtocol On
> </VirtualHost>
>
> This way I can reach the same vhost with and without proxy protocol.
>
>From the protocol specification
http://www.haproxy.org/download/1.8/doc/proxy-protocol.txt:
'''The receiver MUST be configured to only receive the protocol described in
this
specification and MUST not try to guess whether the protocol header is present
or not. This means that the protocol explicitly prevents port sharing between
public and private access. Otherwise it would open a major security breach by
allowing untrusted parties to spoof their connection addresses. The receiver
SHOULD ensure proper access filtering so that only trusted proxies are allowed
to use this protocol.'''
So I don't think Optional is allowed, if you treat the specification as
authoritative.
A vhost reachable by multiple ip's and/or ports would be a better way to
solve it then.
Thinking more about this: Right now the patch proposes
RemoteIPProxyProtocol inside a vhost config, but wouldn't it be better
(since it is connection-specific) to have something like a
ProxyProtocolListen directive? Where you say instead of:
------
<VirtualHost 127.0.0.1:9001>
RemoteIPProxyProtocol On
</VirtualHost>
------
Something like:
------
ProxyProtocolListen 127.0.0.1:9001
or
ProxyProtocolEnable 127.0.0.1:9001
------
IMHO this is much cleaner than within a vhost (because that has
side-effects on other vhosts as well)
Regards,
Sander Hoentjen
