Date: Wed, 16 Oct 2002 17:43:15 -0700 From: David Schultz <dschultz@uclink.Berkeley.EDU> To: Mike Hoskins <mike@adept.org> Cc: freebsd-security@FreeBSD.ORG Subject: Re: CERT VU#539363 Message-ID: <20021017004315.GA8951@HAL9000.homeunix.com> In-Reply-To: <20021016124439.T4295-100000@fubar.adept.org> References: <20021016124439.T4295-100000@fubar.adept.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Thus spake Mike Hoskins <mike@adept.org>: > I'm sure everyone saw this on Bugtraq, firewalls, firewall-wizards, etc... > But I noticed Apple was quick to resond with a 'we're not vulnerable' > regarding OS X and wondered if we could draw similar conclusions. 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. I suspect that OS X is not vulnerable for the same reason, namely, it doesn't ship with a firewall that understands FTP in the first place. > "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. (Consider what happens when you're sent an excessive number of incomplete fragmented IP packets.) 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. > "Use separate timeout values for initial sessions" > > net.inet.ip.fw.dyn_syn_lifetime ? Yes. > "Use dynamically adjustable session timers (Aggressive Aging)" [...] > Or maybe a lot of rules are created for a set of hosts causing the state > table to grow to within some threshold of net.inet.ip.fw.dyn_max, causing > the lifetime of all rules to be shortened and hopefully create more room > for additional rules. 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. > "Allow connection tracking to be disabled" > > I.e. Turn off statefulness? I suppose that could give one time to find a > real solution, but it may require a lot of work. :) If you turn off statefulness, you lose some expressiveness, and you may consequently allow or restrict more than you intended to. You couldn't permit outgoing-only requests via most UDP protocols, for instance; without state, you wouldn't know whether an incoming response was solicited by a local machine. For TCP this is less of a problem. If you assume that your internal hosts properly drop non-SYN packets corresponding to nonexistent connections, all you have to do is filter SYNs as appropriate and check for spoofing. Of course with an application layer firewall filtering a stateful protocol like FTP, you clearly need to maintain state, and that's in addition to IP fragment reassembly. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20021017004315.GA8951>