My code on the load balancer inserts the XFF message before any client data gets passed.
So forging can be handled by ignoring any subsequent XFF messages, only the first one is
the one from the load balancer.
However, this doesn’t allow for cascading load balancers. HTML’s X-Forwarded-For header
handles this by having each load balancer just append to the string. I’m not sure how
important this capability is.
On May 18, 2016, at 7:48 PM, William Brown <wibrown(a)redhat.com>
On Wed, 2016-05-18 at 23:04 +0200, Jochen Schneider wrote:
> Hi Rich, hi Robert,
> On 18/05/16 15:48, Rich Megginson wrote:
>> On 05/18/2016 07:35 AM, Robert Viduya wrote:
>>> I have no issues with that.
>> Can you open a 389 ticket? https://fedorahosted.org/389/newticket
>>> I’m a little concerned about the ldap message id, however.
>> Me too. Developers, LDAP SMEs, please feel free to chime in.
> this is quite an interesting approach and it will probably work in the
> vast majority of cases.
I think it sounds a bit fragile, and really relies on the log aggregation techniques of
the implementor. I'm not sure I like
As well, how is this locked down to prevent a fradulent client sending a fake control
first, then their real operation? It would
certainly cause confusion in the logs ....
> But instead of adding a separate LDAP _operation_ to the stream (where
> we cannot easily ensure uniqueness of the message id) we could implement
> the "LDAP Session Tracking Control" from
and only insert that
> _control_ into the first LDAP operation.
> There is already a 389 ticket for the server side functionality
> On the F5 there is ASN1::element which makes construction of the control
> and adding it to the LDAP operation quite feasible.
The issue with this is that this control can be forged. We would need to essentially add
another layer of "auth" which states
that we allow the control from only certain source ips, ie the load balancer that is
allowed to add this control. And even IP
layer checks can be forged unless you turn on things like reverse path checking and such
on the host.
Both solutions really have shortcomings and complexity, but I think I would prefer to
implement the draft version of session-03
over the "loosely coupled" approach that Robert developed. We could at least
lock it down to a check on the plugin only allowed
some set of IP's to use the control, and put a check in dsktune for rpf. Then the
load balancer can inject the control to the
operation as needed.
Saying this, there is no faster way to ruin your network than to allow a load balancer to
tamper with your traffic. I've seen
horrible, horrible things happen because of bigip, netscalers, ace, and others, tampered
with the internals of DNS, LDAP, HTTP
... At the point you allow a load balancer to actively look at your traffic you are
opening yourself to many subtle, hard to
I really can't recommend that you use one arm mode for LDAP, and highly recomend that
you use routed mode, with TLS/SSL
termination on the LDAP servers themself.
But that's a discussion for another thread I think .....
> 389-users mailing list
Red Hat, Brisbane
389-users mailing list