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>