Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 22 May 2009 12:19:32 -0400 (EDT)
From:      Rick Macklem <rmacklem@uoguelph.ca>
To:        John Baldwin <jhb@freebsd.org>
Cc:        svn-src-head@freebsd.org, =?utf-8?B?RGFnLUVybGluZyBTbcO4cmdyYXY=?= <des@des.no>, svn-src-all@freebsd.org, src-committers@freebsd.org, Rick Macklem <rmacklem@freebsd.org>
Subject:   Re: svn commit: r192463 - head/sys/fs/nfsserver
Message-ID:  <Pine.GSO.4.63.0905221157580.14855@muncher.cs.uoguelph.ca>
In-Reply-To: <200905221118.48669.jhb@freebsd.org>
References:  <200905201858.n4KIw7Fc040619@svn.freebsd.org> <86r5yhzaso.fsf@ds4.des.no> <Pine.GSO.4.63.0905221024420.105@muncher.cs.uoguelph.ca> <200905221118.48669.jhb@freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help


On Fri, 22 May 2009, John Baldwin wrote:

>
> What about a malicious denial-of-service attack where a malicious client
> initiates an endless stream of connection attempts to force a panic?  I think
> that is where the concern lies.  I'm sure a malicious client could do it
> intentionally in less than 136 years, perhaps on the order of seconds and/or
> minutes? :)
>
Ok, I'll buy into this and change it back to a "printf()" and let it 
continue.

Btw, if a malicious client gets to do repeated SetClientIDs against
the server (which is what you are referring to, above), then other
ugly things will occur. There are high water marks set for concurrent
allocations of clientids (there is a malloc'd structure for each one
of them), but if that is set too high, the server will get wedged,
big time. As for what happens inside the krpc when a malicious client
does repeated TCP connection attempts, I have no idea, but suspect it
ain't gonna be pretty. Doug?

Your only defenses within the server are:
1 - requiring all clients to have use KerberosV. (If you do this, the
   malicious client will probably still slow the machine to a crawl, but
   shouldn't exhaust resources, at least not in the nfs code.)
2 - blocking IP#s at the nfs server. (Pretty much the same result as 1,
   but maybe less overhead for the case of a malicious client using bogus
   GSSAPI authenticators.)

I think blocking IP#s at some external firewall is going to be the only
way to survive such an attack, but I suppose it's nice if the server
doesn't reboot during the attack and just gets really really slow.

NFSv4.1 has a rather complex front end to sessions called SSV, in an
attempt to protect against such attacks, but it seems to me that it
will require so much overhead to implement that it may not work out
well anyhow. But until someone implements sessions, who knows.
(Although there are some sessions implementations out there, I don't
think anyone tested SSV at the last connectathon, but I wasn't there,
so this is just a hunch.)

I'll change it back to a printf(), because that won't do any
harm, rick



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.63.0905221157580.14855>