Re: Detection of PROXY protocol version and Citrix CIP
Apologies as this is *way* overdue as I didn't get the initial reply for whatever reason. Thanks, Willy, for that initial response. We ended getting this implemented and things worked properly. By the way you can currently do this using "expect-proxy layer4" and "expect-netscaler-cip layer4" in tcp-request rules. If you already know your clients addresses (which I'm sure you do), instead of leaving the entry hardcoded you could put such rules instead. Ah, right. So, in our setup this was just with Netscalers in the path, then on to the client, not having haproxy in the path. The dynamic detection of PROXY protocol vs. Netscaler CIP was on the backend server application side, not in haproxy config. So the question here was purely around whether this would be breaking the intention of the PROXY protocol *spec*, rather than looking for implementation/configuration information on haproxy being in path. Now I'm having a question : shouldn't we simply move the netscaler CIP parser to the proxy protocol parser and use a single option ? (ie accept- proxy would validate both of them, and possibly future ones if needed). It's important to decide before we release 1.7 :-) That's somewhat out of my wheelhouse in terms of haproxy implementation specifics. It looks from the docs for 1.8 that this is still split, so ¯\_(ツ)_/¯ -- Hugo Slabbert | email, xmpp/jabber: h...@slabnet.com pgp key: B178313E | also on Signal
Re: Detection of PROXY protocol version and Citrix CIP
Hi Hugo, I'm CCing Bertrand who implemented the netscaler CIP protocol. On Mon, Oct 17, 2016 at 01:36:40PM -0700, Hugo Slabbert wrote: > The PROXY protocol spec specifically indicates that a receiver should not > try to guess whether or not a PROXY protocol header is present[1]: > > > 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. > > I have an (unfortunate) scenario where traffic to the same backend may be > arriving through either an HAProxy *or* a Citrix NetScaler where source IP > information needs to be passed to the backend, at least during a DNS swing > from one to the other while records TTL out. > > The spec as I read it intends to protect against a malicious actor sending > traffic with a PROXY protocol header set with an arbitrary client IP. In > other words, the "MUST NOT" directive is there to ensure that backends that > are not *explicitly* configured to receive PROXY protocol traffic can't be > tricked into treating traffic from a random host as PROXY protocol traffic. > > Is that correct? Yes that's correct. > Is it against the spirit or letter of the spec, though, to test not for the > absence or presence of the PROXY protocol header itself but rather (a) > whether the PROXY protocol version is 1 or 2 and (b) if another client > source IP preservation/representation protocol, like the Citrix Client IP > option, is in use? Or does that still expose a possible exploit vector? > Protections could still be provided to the backend servers in either case > such that PROXY protocol traffic or Citrix Client IP traffic would only be > permitted from known/trusted proxies. No it's not against the spirit, I think it's even a good idea, just one that we probably never thought about. As you understood, what matters is the person configuring haproxy knows what front components can be trusted or not. Once the connection comes from a trusted IP, I think you don't care about the protocol, it could be accepted. > I haven't been able to brainstorm a weakness/exploit in that type of setup, > as it would basically amount to (pseudo-code): > > if header.type == "proxyv1": > # do PROXY protocol v1 stuff > elif header.type == "proxyv2": > # do PROXY protocol v2 stuff > elif header.type == "cip": > # do Citrix Client IP stuff > else: > # no good; drop it like it's hot > > ...with the network configured to permit only trusted proxies to talk > directly to the backends. By the way you can currently do this using "expect-proxy layer4" and "expect-netscaler-cip layer4" in tcp-request rules. If you already know your clients addresses (which I'm sure you do), instead of leaving the entry hardcoded you could put such rules instead. Now I'm having a question : shouldn't we simply move the netscaler CIP parser to the proxy protocol parser and use a single option ? (ie accept- proxy would validate both of them, and possibly future ones if needed). It's important to decide before we release 1.7 :-) Thanks, Willy
Detection of PROXY protocol version and Citrix CIP
The PROXY protocol spec specifically indicates that a receiver should not try to guess whether or not a PROXY protocol header is present[1]: 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. I have an (unfortunate) scenario where traffic to the same backend may be arriving through either an HAProxy *or* a Citrix NetScaler where source IP information needs to be passed to the backend, at least during a DNS swing from one to the other while records TTL out. The spec as I read it intends to protect against a malicious actor sending traffic with a PROXY protocol header set with an arbitrary client IP. In other words, the "MUST NOT" directive is there to ensure that backends that are not *explicitly* configured to receive PROXY protocol traffic can't be tricked into treating traffic from a random host as PROXY protocol traffic. Is that correct? Is it against the spirit or letter of the spec, though, to test not for the absence or presence of the PROXY protocol header itself but rather (a) whether the PROXY protocol version is 1 or 2 and (b) if another client source IP preservation/representation protocol, like the Citrix Client IP option, is in use? Or does that still expose a possible exploit vector? Protections could still be provided to the backend servers in either case such that PROXY protocol traffic or Citrix Client IP traffic would only be permitted from known/trusted proxies. I haven't been able to brainstorm a weakness/exploit in that type of setup, as it would basically amount to (pseudo-code): if header.type == "proxyv1": # do PROXY protocol v1 stuff elif header.type == "proxyv2": # do PROXY protocol v2 stuff elif header.type == "cip": # do Citrix Client IP stuff else: # no good; drop it like it's hot ...with the network configured to permit only trusted proxies to talk directly to the backends. Unless I'm missing something? -- Hugo Slabbert | email, xmpp/jabber: h...@slabnet.com pgp key: B178313E | also on Signal [1] http://www.haproxy.org/download/1.5/doc/proxy-protocol.txt signature.asc Description: Digital signature
