From owner-freebsd-stable  Tue Nov 19  6: 7: 9 2002
Delivered-To: freebsd-stable@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP id 11FDE37B401
	for <freebsd-stable@FreeBSD.org>; Tue, 19 Nov 2002 06:07:08 -0800 (PST)
Received: from gs166.sp.cs.cmu.edu (GS166.SP.CS.CMU.EDU [128.2.205.169])
	by mx1.FreeBSD.org (Postfix) with SMTP id 9617A43E42
	for <freebsd-stable@FreeBSD.org>; Tue, 19 Nov 2002 06:07:07 -0800 (PST)
	(envelope-from dpelleg@gs166.sp.cs.cmu.edu)
To: freebsd-stable@FreeBSD.org
Subject: RFC: alternative firewall rule framework
From: Dan Pelleg <daniel+bsd@pelleg.org>
Date: 19 Nov 2002 09:06:36 -0500
Message-ID: <u2s65ut4psj.fsf@gs166.sp.cs.cmu.edu>
Lines: 36
User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.1 (Cuyahoga Valley)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-freebsd-stable@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-stable.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-stable>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-stable>
X-Loop: FreeBSD.ORG


I'd like to propose a framework alternative to rc.firewall. The monolithic
rc.firewall makes it hard to maintain and to use in any way other than
loading it all at once. I can think of at least two axes along which one
would like to modularize:

1. Define independent policies to perform various firewall tasks (eg, allow
access to our web server, or: let NAT machines initiate connections).

2. Separate the lists of actual hosts and networks from the policy.

If you want, (1) separates "what" from "how", and (2) separates "how" from
"whom".

With this kind of framework in place, it becomes easy to load, unload, or
refresh any part of the ruleset. For example: you've just added a machine
to the battery of webservers and need to update the firewall. You'd rather
not lose your state table or lock yourself out while doing it. The only
part you want to touch is the one with the http rules in it.

I have a prototype for such a system (below). The implementation is nothing
but a bunch of shell scripts that wrap ipfw(8) calls. But they do step
towards providing modularization. As-is it's mostly a drop-in replacement
for rc.firewall. But it also contains some examples that show it is easily
extensible to more complex situations.

Also included is a setup for a small NAT-ed network, which seems to be a
high hurdle for many, (at least if you judge by the number of questions
posted to the mailing lists).

It's at http://web.cs.cmu.edu/~dpelleg/download/fwtasks.tgz
comments will be appreciated. I already know the implementation is ugly :)

-- 

  Dan Pelleg

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-stable" in the body of the message