From owner-freebsd-security Thu Oct 17 0:44:48 2002 Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9EB3537B401 for ; Thu, 17 Oct 2002 00:44:45 -0700 (PDT) Received: from fubar.adept.org (fubar.adept.org [63.147.172.249]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5357143E4A for ; Thu, 17 Oct 2002 00:44:45 -0700 (PDT) (envelope-from mike@adept.org) Received: by fubar.adept.org (Postfix, from userid 1001) id 66AE515247; Thu, 17 Oct 2002 00:44:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by fubar.adept.org (Postfix) with ESMTP id 645FC15226; Thu, 17 Oct 2002 00:44:28 -0700 (PDT) Date: Thu, 17 Oct 2002 00:44:28 -0700 (PDT) From: Mike Hoskins To: David Schultz Cc: freebsd-security@FreeBSD.ORG Subject: Re: CERT VU#539363 In-Reply-To: <20021017004315.GA8951@HAL9000.homeunix.com> Message-ID: <20021017003422.V5273-100000@fubar.adept.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Wed, 16 Oct 2002, David Schultz wrote: > Thus spake Mike Hoskins : > FreeBSD's ipfw isn't vulnerable because it doesn't do application > layer filtering. On the other hand, ipfilter is potentially > susceptible, probably depending on the FTP server you use. Are you thinking of VU#328867? Take a look at 539363 (which you indicate you haven't read below). 539353 certainly does affect ipfw, or any stateful firewall, from what I can see. It's not a question of whether a given implementation is or isn't vulnerable so much as a question of which implementations best deal with this type of (ab)use. > > "Use firewall features that detect and block flood traffic" > [...] > > "Use dynamically resizeable state tables" > [...] > Your criticisms here are well-founded; these suggestions do not > fix the resource exhausion problem. However, you have to realize > that a stateful firewall is inherently vulnerable to this kind of > attack. Note that the points above (in quotes) were from the CERT VU, I was just commenting on their reccomendations and attempting to draw FreeBSD-specific corollaries. > I haven't read the > list of suggestions you're referring to, but the suggestions > probably assume that the administrator requires a stateful > firewall, in which case the best you can possibly do is manage > that (theoretically unbounded) state intelligently. "[T]he best you can possibly do is manage that ..." I learned and accepted that about stateful firewalls long ago. My only real point was ensuring we handle things as gracefully as possible and possibly provide an official response to CERT. > I believe that's the idea. IPFW doesn't do this; it simply stops > creating new dynamic rules when the table is full. I think > there's lots of room for DOS resistance here; you could imagine > separate per-rule or per-source quotas on dynamic rules, for > example. I noticed a lot of big names haven't replied (Cisco). I'd like to know how the PIX' "adaptive security" algorithms handle this - a first clue will be seeing their response. > If you turn off statefulness, you lose some expressiveness, and > you may consequently allow or restrict more than you intended to. Indeed, I never intended to suggest configuring a "static" firewall as a valid option for most stateful installations. I believe that was an intended reccomendation from CERT, however, in their typically vague and overly broad manner. ;) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message