Date: Wed, 16 Oct 2002 13:02:53 -0700 (PDT) From: Mike Hoskins <mike@adept.org> To: freebsd-security@freebsd.org Subject: CERT VU#539363 Message-ID: <20021016124439.T4295-100000@fubar.adept.org>
next in thread | raw e-mail | index | archive | help
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. From their "Solution" section: "Use firewall features that detect and block flood traffic" I assume they mean things like the PIX can do... Monitor for excessive SYNs from foreign hosts and throttle connections (or deny them entirely after a threshold). However, if the attacker used randomly forged source addresses to an open port on the firewall, I don't see how these features would really help. "Use dynamically resizeable state tables" Couldn't this hurt more at some point? Assuming the attacker has time and is able to forge IPs... A state table has to either become full (reach net.inet.ip.fw.dyn_max) or use all available resources at some point, right? Hard to say which is better. "Use separate timeout values for initial sessions" net.inet.ip.fw.dyn_syn_lifetime ? "Use dynamically adjustable session timers (Aggressive Aging)" Do they mean the net.inet.ip.fw.dyn_* timers? If so, what sort of algorithm would do this "dynamic" adjustment, and based upon what criterea? A couple possible cases... A large number of rules are created for a given host... So the timeout values for rules associated with that host are cut short until the total rules from that host return below some threshold. 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. "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. :) 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?20021016124439.T4295-100000>