From owner-freebsd-security Tue Jun 13 12:26:53 2000 Delivered-To: freebsd-security@freebsd.org Received: from ouch.Oof.NET (ouch.Oof.NET [207.99.30.50]) by hub.freebsd.org (Postfix) with ESMTP id 7C8E437C0AF for ; Tue, 13 Jun 2000 12:26:47 -0700 (PDT) (envelope-from freebsd-contact@research.poc.net) Received: from localhost (ash@localhost) by ouch.Oof.NET (POCmail) with ESMTP id PAA76489; Tue, 13 Jun 2000 15:26:45 -0400 (EDT) Date: Tue, 13 Jun 2000 15:26:45 -0400 (EDT) From: To: freebsd-security@freebsd.org Subject: rc.network firewall init Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I've noticed that FreeBSD 4.0's /etc/rc.network brings up network interfaces before initializing firewall behavior. In the case of IPFIREWALL, when not compiled into the kernel, this causes a short window of 'exposure' during startup. In the time between network connectivity being established, and the IPFIREWALL KLD being loaded, all interfaces are up and unfiltered. (An almost identical problem exists even when IPFIREWALL *is* compiled into the kernel, but the kernel option IPFIREWALL_DEFAULT_TO_ACCEPT is specified.) One successful TCP handshake during this window can establish a connection that survives the firewall loading, due to IPFIREWALL's non-statefulness and the (resultant) commonality of "allow tcp from any to any established". --Anatole Shaw To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message