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@xxxxxxxxxx> wrote: > > 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 > this approach. > > 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 >> http://tools.ietf.org/html/draft-wahl-ldap-session and only insert that >> _control_ into the first LDAP operation. >> There is already a 389 ticket for the server side functionality >> (https://fedorahosted.org/389/ticket/47873). >> 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 > isolate issues. > > 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 ..... > >> >> Regards, >> J. >> -- >> 389-users mailing list >> 389-users@xxxxxxxxxxxxxxxxxxxxxxx >> http://lists.fedoraproject.org/admin/lists/389-users@xxxxxxxxxxxxxxxxxxxxxxx > > -- > Sincerely, > > William Brown > Software Engineer > Red Hat, Brisbane > > -- > 389-users mailing list > 389-users@xxxxxxxxxxxxxxxxxxxxxxx > http://lists.fedoraproject.org/admin/lists/389-users@xxxxxxxxxxxxxxxxxxxxxxx -- 389-users mailing list 389-users@xxxxxxxxxxxxxxxxxxxxxxx http://lists.fedoraproject.org/admin/lists/389-users@xxxxxxxxxxxxxxxxxxxxxxx
