Paul B. Henson wrote: > On 11/19/2020 10:02 AM, Howard Chu wrote: > >>> 1. Config directives for specifying IP address(es) and network(s) expected >>> and trusted to send proxy protocol header. >> >> Sounds like unnecessary work. Just use an ACL. > > I don't think an ldap level ACL would work for what he means? I think he > wants to control what source IP addresses are allowed to connect to the > proxy protocol port and arbitrarily say what the client IP address is > which is passed down to the underlying ldap access control to be > processed by ACLs. If you are using IP address based access control, you > wouldn't want arbitrary clients to be able to connect and send a proxy > header claiming to be somebody else. > > However, given that the proxy protocol and regular access will be on > different ports, this seems better handled at the network firewall level.
It sounded to me like he is not passing the client address transparently, which means that the actual peer address is still known, and would be governed by the current peer-based ACL mechanisms already, while introducing a new term to represent the proxied client address. Anyway yes, controlling this at the firewall level would be better too. >>> 3. Log the proxied peername separately, similar how session >>> tracking control is logged. >> >> Again, kind of defeats the purpose of transparently relaying the >> client's address. > > I'm not completely sure what he meant by this, but I was planning on > modifying the initial connection log to indicate it was proxied, including > both the address > of the proxy and the proxied address. > > so for a normal connection something like: > > Nov 15 19:21:18 themis slapd[22846]: conn=482386 fd=89 ACCEPT from > IP=134.71.247.3:54401 (IP=0.0.0.0:389) > > and for a proxied connection something like: > > Nov 15 19:21:18 themis slapd[22846]: conn=482386 fd=89 ACCEPT from > IP=134.71.247.3:54401 proxyIP=10.128.1.0:34323 (IP=0.0.0.0:389) This would require that you actually read and process the proxy header immediately after the accept call. It strikes me that this is the wrong thing to do, if you also want to support TLS. I.e., that means the proxy header travels in the clear before you do a TLS handshake, which is probably not what one would want if they're using TLS. I suppose you would need to check what the proxy server actually supports, if it actually supports connecting to the target server using TLS. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
