From owner-freebsd-security Wed Oct 16 13: 3: 6 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 EB8E737B401 for ; Wed, 16 Oct 2002 13:03:03 -0700 (PDT) Received: from fubar.adept.org (fubar.adept.org [63.147.172.249]) by mx1.FreeBSD.org (Postfix) with ESMTP id AD8DD43EA3 for ; Wed, 16 Oct 2002 13:03:03 -0700 (PDT) (envelope-from mike@adept.org) Received: by fubar.adept.org (Postfix, from userid 1001) id 3D93C15247; Wed, 16 Oct 2002 13:02:53 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by fubar.adept.org (Postfix) with ESMTP id 3B5B315226 for ; Wed, 16 Oct 2002 13:02:53 -0700 (PDT) Date: Wed, 16 Oct 2002 13:02:53 -0700 (PDT) From: Mike Hoskins To: freebsd-security@freebsd.org Subject: CERT VU#539363 Message-ID: <20021016124439.T4295-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 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