Using nss-pam-ldapd in a large environment, Part 2: Denial of Service due to open connections

[Thomas Orgis <thomas.orgis [at] uni-hamburg.de>]

Hi,

I got another issue that makes nslcd troublesome for a large-scale
setup. I discovered that nslcd opens <n> connections to the LDAP server
and then keeps them open forever. This is not a good idea in an
environment with thousands of clients talking to a central set of LDAP
servers.

The default number of 5 connections is another big "Why?". I really ask
myself, and the world at large, why you need 5 channels to the LDAP
server for NSS/PAM needs. What kind of setup is this designed for? Are
modern desktops querying the user database 100 times in a second?

Well, the main point is that the connections are not closed. Combine
that with a setup of 400 machines, each running its own nslcd, and you
quickly get blamed for attempting a DoS on the university network.

My rescue is the design decision to have a separated daemon to begin
with: That daemon doesn't need to run on each client!

That on an intermediate server,

socat TCP4-LISTEN:123,bind=a.b.c.d,reuseaddr,fork,su=nobody \
      UNIX-CLIENT:/var/run/nslcd/socket

, and that on the client

socat  UNIX-LISTEN:/var/run/nslcd/socket \
       TCP4:a.b.c.d:123

nicely forwards the requests to the centralized nslcd which pumps them
through a reasonable set of connections. I'll have to play with the
thread count to see what's necessary. But I don't expect that much
actual load. And even if there is, can still configure sssd. Also note
that a lack of encryption is not that much of an issue in the
controlled network and also since we do not authenticate against LDAP,
no passwords are going over the wire.

Do you see an issue with my approach?

And on the upstream front: Would it be considered to add a switch to
make nslcd drop the connections when there are no requests to serve? In
an environment with thousands or even tens of thousands of client
machines, you simply cannot allow them all to keep constant connections
open. The folks running the servers were quite surprised at that
behaviour and that leads me to conclude that the old nss_ldap did not
do that.


Alrighty then,

Thomas

-- 
Dr. Thomas Orgis
Universität Hamburg
RRZ / Zentrale Dienste / HPC
Schlüterstr. 70
20146 Hamburg
Tel.: 040/42838 8826
Fax: 040/428 38 6270

Attachment: smime.p7s
Description: S/MIME cryptographic signature

-- 
To unsubscribe send an email to
nss-pam-ldapd-users-unsubscribe@lists.arthurdejong.org or see
http://lists.arthurdejong.org/nss-pam-ldapd-users/