HI!
I'm currently trying to upgrade an OpenLDAP package for a openSUSE distribution.
The original package links slapd with libwrap which made sense in former times on systems without local host firewall mechanisms. If libwrap does not have a major performance impact I'd keep it that way just for sake of backward compability.
But AFAICT if slapd is linked with libwrap the TCP wrapper is always asked whether a connection is allowed or not. One cannot disable it by slapd configuration.
So the question is: How big is the performance impact?
Ciao, Michael.
Michael Ströder wrote:
HI!
I'm currently trying to upgrade an OpenLDAP package for a openSUSE distribution.
The original package links slapd with libwrap which made sense in former times on systems without local host firewall mechanisms. If libwrap does not have a major performance impact I'd keep it that way just for sake of backward compability.
But AFAICT if slapd is linked with libwrap the TCP wrapper is always asked whether a connection is allowed or not. One cannot disable it by slapd configuration.
So the question is: How big is the performance impact?
How much does it matter? libwrap has to fopen two files (/etc/hosts.allow and hosts.deny) and read their rules, every time a connection is received. That's pretty significant overhead, but if you're not receiving thousands of connections per second, it probably doesn't matter.
Ciao, Michael.
Howard Chu wrote:
Michael Ströder wrote:
I'm currently trying to upgrade an OpenLDAP package for a openSUSE distribution.
The original package links slapd with libwrap which made sense in former times on systems without local host firewall mechanisms. If libwrap does not have a major performance impact I'd keep it that way just for sake of backward compability.
But AFAICT if slapd is linked with libwrap the TCP wrapper is always asked whether a connection is allowed or not. One cannot disable it by slapd configuration.
So the question is: How big is the performance impact?
How much does it matter?
That's what I'm trying to find out. ;-)
libwrap has to fopen two files (/etc/hosts.allow and hosts.deny) and read their rules, every time a connection is received. That's pretty significant overhead, but if you're not receiving thousands of connections per second, it probably doesn't matter.
Hmm, I will drop it since the same functionality can be easily achieved on this platform by using local kernel firewall.
BTW: I'm using this package also on rasperry pi. So calling fopen() twice seems significant to me.
Ciao, Michael.
On 09.12.2014 16:25, Michael Ströder wrote:
Hmm, I will drop it since the same functionality can be easily achieved on this platform by using local kernel firewall.
Sounds like a good idea.
I dropped it after one misbehaving firefox addressbook lookup plugin I tried managed to open up enough connections in the same second to our ldap server to fill the logs with:
Oct 31 11:11:33 ldapsrv slapd[6603]: warning: cannot open /etc/hosts.allow: Too many open files Oct 31 11:11:33 ldapsrv slapd[6603]: warning: cannot open /etc/hosts.deny: Too many open files Oct 31 11:11:33 ldapsrv slapd[6603]: warning: cannot open /etc/hosts.allow: Too many open files Oct 31 11:11:33 ldapsrv slapd[6603]: warning: cannot open /etc/hosts.deny: Too many open files ...etc...etc...
...and preventing most of the genuine lookups and logins.
You can of course up the ulimit (default was 1024) and in slapd config limit connections to prevent clients from being able to do this, but if you don't need tcp wrappers anyway, ....
On Tue, 9 Dec 2014, Terje Trane wrote:
Oct 31 11:11:33 ldapsrv slapd[6603]: warning: cannot open /etc/hosts.deny: Too many open files ...etc...etc...
...and preventing most of the genuine lookups and logins.
You can of course up the ulimit (default was 1024) and in slapd config limit connections to prevent clients from being able to do this, but if you don't need tcp wrappers anyway, ....
While I don't disagree with this in principle, I want to write for the archives. IMO people searching for "slapd /etc/hosts.deny: Too many open files" really shouldn't get "go recompile --disable" as a result:
A ulimit that low, nowadays, is really just to rapidly stop typos and other foolishly runaway processes. For a process such as a server running on (even-not-so-)modern hardware, when you're expecting large amounts of connections -- and keeping in mind that each connection takes a file descriptor -- that limit should be significantly higher.
Basically, blaming the final straw isn't the right move. Given the choice between repackaging a piece of software with fewer features, or reconfiguring an unrealistic default to an appropriate value for your environment, I'd think the config file is the way to go...regardless of libwrap or any other part of the stack.
Aaron Richton wrote:
On Tue, 9 Dec 2014, Terje Trane wrote:
Oct 31 11:11:33 ldapsrv slapd[6603]: warning: cannot open /etc/hosts.deny: Too many open files ...etc...etc...
...and preventing most of the genuine lookups and logins.
You can of course up the ulimit (default was 1024) and in slapd config limit connections to prevent clients from being able to do this, but if you don't need tcp wrappers anyway, ....
While I don't disagree with this in principle, I want to write for the archives. IMO people searching for "slapd /etc/hosts.deny: Too many open files" really shouldn't get "go recompile --disable" as a result:
A ulimit that low, nowadays, is really just to rapidly stop typos and other foolishly runaway processes. For a process such as a server running on (even-not-so-)modern hardware, when you're expecting large amounts of connections -- and keeping in mind that each connection takes a file descriptor -- that limit should be significantly higher.
Basically, blaming the final straw isn't the right move. Given the choice between repackaging a piece of software with fewer features, or reconfiguring an unrealistic default to an appropriate value for your environment, I'd think the config file is the way to go...regardless of libwrap or any other part of the stack.
But it makes a huge difference if you have two or three file handles per connection or just one.
And on Linux and some other platforms normally nobody uses TCP wrapper anymore. You can achieve the same and do better with iptables or whatever local FW is available.
As usual: Your mileage may vary.
Ciao, Michael.
* Michael Ströder:
Hmm, I will drop it since the same functionality can be easily achieved on this platform by using local kernel firewall.
The DNS-based access rules are not available as part of the kernel firewall. For some odd reasons, a lot of people think this tcpwrappers feature is insecure, but it seems a rather convenient way to get *additional* security in cases where you have proper reverse lookup (with matching forward lookup) and fragmented address space that does not lend itself easily to writing access rules.
But as I said, this goes against accepted wisdom, so these additional filters probably don't make it through security audits, and carrying along this support at the tool level does not make much sense anymore:
https://lists.fedoraproject.org/pipermail/devel/2014-March/196913.html
Florian Weimer wrote:
- Michael Ströder:
Hmm, I will drop it since the same functionality can be easily achieved on this platform by using local kernel firewall.
The DNS-based access rules are not available as part of the kernel firewall.
Good point.
For some odd reasons, a lot of people think this tcpwrappers feature is insecure,
Me too. ;-)
but it seems a rather convenient way to get *additional* security in cases where you have proper reverse lookup (with matching forward lookup) and fragmented address space that does not lend itself easily to writing access rules.
But it adds two additional DNS lookups to the game.
But as I said, this goes against accepted wisdom, so these additional filters probably don't make it through security audits, and carrying along this support at the tool level does not make much sense anymore:
https://lists.fedoraproject.org/pipermail/devel/2014-March/196913.html
Thanks for the link to this interesting discussion.
Ciao, Michael.
Michael Ströder wrote:
Florian Weimer wrote:
- Michael Ströder:
Hmm, I will drop it since the same functionality can be easily achieved on this platform by using local kernel firewall.
The DNS-based access rules are not available as part of the kernel firewall.
Good point.
For some odd reasons, a lot of people think this tcpwrappers feature is insecure,
Me too. ;-)
but it seems a rather convenient way to get *additional* security in cases where you have proper reverse lookup (with matching forward lookup) and fragmented address space that does not lend itself easily to writing access rules.
But it adds two additional DNS lookups to the game.
I also use dnsmasq everywhere these days. Wouldn't dream of using a non-cached DNS resolver.
(And btw, dnsmasq supports DNSSEC.)
Florian Weimer wrote:
- Michael Ströder:
Hmm, I will drop it since the same functionality can be easily achieved on this platform by using local kernel firewall.
The DNS-based access rules are not available as part of the kernel firewall. For some odd reasons, a lot of people think this tcpwrappers feature is insecure, but it seems a rather convenient way to get *additional* security in cases where you have proper reverse lookup (with matching forward lookup) and fragmented address space that does not lend itself easily to writing access rules.
But as I said, this goes against accepted wisdom, so these additional filters probably don't make it through security audits, and carrying along this support at the tool level does not make much sense anymore:
https://lists.fedoraproject.org/pipermail/devel/2014-March/196913.html
Interesting discussion. There seems to be an inherent belief that old code is bad code. *Bad* code is bad code, and *good* code is good regardless of its age. The fact that TCP wrappers has been basically unmaintained since 2003 only indicates that it has not needed any new features since then. (And as I was one of the original authors in 1992, I know very well that it contains code that has never needed fixing...)
Your point about layered security is well taken though. As for DNS-based access rules, I've always considered them a liability; the cost of doing a reverse DNS lookup was something I'd never use in my own sites.
Michael Ströder michael@stroeder.com schrieb am 09.12.2014 um 15:19 in
Nachricht 548704F9.7030504@stroeder.com:
HI!
I'm currently trying to upgrade an OpenLDAP package for a openSUSE distribution.
Very good!
The original package links slapd with libwrap which made sense in former times on systems without local host firewall mechanisms.
Maybe even with firewall _mechanism_, some people may prefer using tcp wraapper instead. Still many products and consultants claim that firewalls have to be disabled 8-(
If libwrap does not have a major performance impact I'd keep it that way just for sake of backward compability.
But AFAICT if slapd is linked with libwrap the TCP wrapper is always asked whether a connection is allowed or not. One cannot disable it by slapd configuration.
So the question is: How big is the performance impact?
As you are building anyway, why not do a simple performance test as part of your package testing?
Regards, Ulrich
Ciao, Michael.
openldap-technical@openldap.org
-
Aaron Richton -
Florian Weimer -
Howard Chu -
Michael Ströder -
Terje Trane -
Ulrich Windl