From owner-svn-src-head@FreeBSD.ORG Fri May 22 16:18:51 2009 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 17A79106564A; Fri, 22 May 2009 16:18:51 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id 5909D8FC13; Fri, 22 May 2009 16:18:50 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAMttFkqDaFvL/2dsb2JhbADTaYJDgUgFhxA X-IronPort-AV: E=Sophos;i="4.41,234,1241409600"; d="scan'208";a="36304263" Received: from nile.cs.uoguelph.ca ([131.104.91.203]) by esa-jnhn-pri.mail.uoguelph.ca with ESMTP; 22 May 2009 12:18:48 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by nile.cs.uoguelph.ca (Postfix) with ESMTP id F05FD8D411A; Fri, 22 May 2009 12:18:47 -0400 (EDT) X-Virus-Scanned: amavisd-new at nile.cs.uoguelph.ca Received: from nile.cs.uoguelph.ca ([127.0.0.1]) by localhost (nile.cs.uoguelph.ca [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qMYa21caYUh4; Fri, 22 May 2009 12:18:47 -0400 (EDT) Received: from muncher.cs.uoguelph.ca (muncher.cs.uoguelph.ca [131.104.91.102]) by nile.cs.uoguelph.ca (Postfix) with ESMTP id E304F8D410F; Fri, 22 May 2009 12:18:46 -0400 (EDT) Received: from localhost (rmacklem@localhost) by muncher.cs.uoguelph.ca (8.11.7p3+Sun/8.11.6) with ESMTP id n4MGJW017991; Fri, 22 May 2009 12:19:32 -0400 (EDT) X-Authentication-Warning: muncher.cs.uoguelph.ca: rmacklem owned process doing -bs Date: Fri, 22 May 2009 12:19:32 -0400 (EDT) From: Rick Macklem X-X-Sender: rmacklem@muncher.cs.uoguelph.ca To: John Baldwin In-Reply-To: <200905221118.48669.jhb@freebsd.org> Message-ID: References: <200905201858.n4KIw7Fc040619@svn.freebsd.org> <86r5yhzaso.fsf@ds4.des.no> <200905221118.48669.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: svn-src-head@freebsd.org, =?utf-8?B?RGFnLUVybGluZyBTbcO4cmdyYXY=?= , svn-src-all@freebsd.org, src-committers@freebsd.org, Rick Macklem Subject: Re: svn commit: r192463 - head/sys/fs/nfsserver X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2009 16:18:51 -0000 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