Re: Netscape proxy in firewall flooding slapd

[Jeff Clowser <jclowser@aerotek.com>]

I ran into this and have done some pretty extensive
research here to trace through the problem, and
it's actually worse than you may think...

This affects pretty much all Netscape servers:
web, proxy, news, etc.

The servers cache user authentication, but not
group auth.  If you set your proxy server (or
web server, etc) to authenticate against LDAP
for user auth only - i.e. anyone in the LDAP
database - the server caches that users auth,
and stores it for some period of time (forget
what the default is - something like 1 hr).

However, if you auth against a group (as you
are doing), it does not cache the group auth at
all.  Every page, graphic, etc that is authed
causes roughly the following process (all from
memory, so there may be some minor errors):

1.  Look up the group record
2.  Look up the user record and auth it (forget
    off hand, but this one step may be cached)
3.  See if the user's dn is in uniquemember (used
    to also look at member, but they dropped
    support of that - whole 'nother problem)
4.  If the users dn is not in uniquemember, it
    looks up every dn in uniquemember to see if
    any of those are groups (in older servers,
    say up to 3.0).  In newer servers (3.5 or so),
    if the user is not in uniquemember, it searches
    for any other records that contain the users
    dn in uniquemember, and see if these other
    records are in the uniquemember of the auth
    group.  If it still doesn't find it, it looks
    for all records containing these other groups
    to see if any of those are in the original auth
    group until it runs out of return values.  This
    is needed to support group within a group
    hierarchies, and is why Netscape recommends
    against nested groups. (something like this-
    like I said this is from memory, but it does
    do a lot of recursive, exhaustive searching
    if you are not part of the initial group)

The end result is that when authing against a group
in a netscape server:
1. Little or nothing is cached.  If 100 users try to
   access 100 files, and each access generates at
   least 3 or 4 hits to LDAP to look up the user,
   group, etc, you get 30000-40000 hits to LDAP.  If
   you just use user auth (which caches but allows
   everyone in you ldap server access) you get about
   300-400 hits.
2. People trying to access your server that are
   not on the auth group will really slam the LDAP
   server to try to let them in.  In
   your case, with 40,000 people of which 750 have
   access, if you have any significant number of
   groups that may be recursively searched, and a
   significant number of these 40,000 people try to
   access your proxy, it can kill your LDAP server.

My advise is - don't use group auth on Netscape servers
except in very low volume transactions.  We had a
high volume app here on a Netscape web server that
was group authed and it killed the ldap server farm
we had.  Removing group auth and just allowing any
user in the database in reduced the load on our LDAP
servers by something like 80-90% and VERY significantly
improved performance of the app.  This was acceptable
in our case (the group they were authing contained
90% of the company, and there was no need to keep
out the other 10%), but not yours.

One solution we came up with here, which I have
not yet tried but sounds reasonable it this:

Have an attribute in a users record - lets call it
"serveraccess".  You'll need to extend your schema
for this most likely.  Within the serveraccess
attribute, store a unique value for each server
you want to limit to a group of people - for proxy,
lets say this value is "proxy", so for valid proxy
users, they have serveraccess: proxy in their record.
Define an account for the proxy server to bind to.
Create an ACL that allows that proxy account to
only see records that contain "proxy" in the
serveraccess attribute.  Set the proxy server to
auth "all users" in the database.  Since it can
only see those users with the proxy attribute,
"all users" are the 750 you want to have access.
You have to protect the serveraccess attribute
so users can't write to it and give themselves
access (another ACL).  Doing it this way, proxy
will cache the user's auth, so if the user accesses
100 url's (graphics, html, etc) in an hour, you get
one hit to LDAP instead of 100.  If you need this
list for other purposes (say as a mail list to
notify proxy users of changes), have a script
that runs once a day, hour, whatever turnaround
you need to rebuild your dist list based on
records containing mail and serveraccess=proxy,
for instance.

Another way to do this is to have a dedicated LDAP
replica for the proxy server only - at least this
way the proxy server won't impact your other services
that use LDAP.

Oh, one other thing - his applies to the latest 3.x
versions of Netscape servers - older versions didn't
do auth under any circumstance.

One last thing - while I'm beating up on Netscape
for not caching, I'd guess many of the open source
proxies w/LDAP auth mechanisms like Apache, Squid, etc
probably don't do any auth caching. I could be (hopefully
am) wrong, but just want to be fair - the Netscape
products are very good, they just have some very
significant annoyances here and there :-)

Oh - it's probably _possible_ to have netscape
proxy only auth .html files, and allow everything
else through, but it is not reasonable.  This would
allow all 40,000 users to download graphics and stuff,
or access cgi's and things where the URL doesn't
end in .html, so creates way too many security/access
holes.

Sorry for rambling on so long :)

Gerhard Duile wrote:

> Hi,
>
> we are using OpenLDAP 1.2.2, among other things to authentificate users to cross the firewall (with Netscape proxy) to get internet html web pages.  Of our 40.000 users, about 750 are allowed access internet (www) over a firewall. Authentication of these 750 is by access to LDAP server, groupofuniquenames=internet_pilots.
>
> Everything workes fine, but there is one problem: As our CERT (and proxy operators) tell me, their proxy fires one authentification ldap-search not only for every http page any user wishes to see outside our intranet, but also for EVERY image, sound file or whatever this html page itself wishes to load. That means, for one html page our directory server has to answer up to 25 or more authentification jobs, which seems to be quite too much for him. CERT guys tell me Netscape says that there was no way telling Netscape proxy only to authentificate against the html page itself.
>
> Now, here´s my question: does anybody know if they are right? Is there really no way to configure Netscape Proxy Server to only authentificate for html pages, not images (gif, jpg), sound or movie, or java applets, or, or, or, or...?
>
> I´m using OpenLDAP 1.2.2 directory server on SuSE Linux, Pentium II 266 MHz.
>
> Greatful for any hint.
>
> Gerhard Duile
> gerhard.duile@gmx.de

--
 Jeff Clowser
 mailto:jclowser@aerotek.com       Hanover MD  21076 USA
 Phone: (410)-579-4328             7312 Parkway Drive