From owner-freebsd-isp@FreeBSD.ORG Fri Feb 20 18:57:19 2004 Return-Path: Delivered-To: freebsd-isp@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 530A116A4CE for ; Fri, 20 Feb 2004 18:57:19 -0800 (PST) Received: from exchange.wan.no (exchange.wan.no [80.86.128.88]) by mx1.FreeBSD.org (Postfix) with ESMTP id BB2D543D1D for ; Fri, 20 Feb 2004 18:57:18 -0800 (PST) (envelope-from sten.daniel.sorsdal@wan.no) Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Sat, 21 Feb 2004 03:57:13 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: firewalling policy Thread-Index: AcP2/kXT3zs20r9yRkKzWfPnn8jvqABJLAQg From: =?iso-8859-1?Q?Sten_Daniel_S=F8rsdal?= To: "VA" , Subject: RE: firewalling policy X-BeenThere: freebsd-isp@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Internet Services Providers List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Feb 2004 02:57:19 -0000 > What is the best point to firewall? Naturally default block=20 > strategy assumed. I know each interface need rules to achieve=20 > good security, but what about external interface (WAN link)? =20 > Is it safe just to firewall each internal interface, because=20 > otherwise I need "double rules" and it get's more complicated. >=20 > Any other hints to give or good optimized examples for pf in=20 > larger enviroment? I will surely make a public document once=20 > I get this up and running. > Thanks in advance and specially all you developers of this great OS! >=20 I pretty much always go for a setup in this order and i always group my rules by first incoming and then outgoing per interface; a) drop all attempts at spoofing b) no redundancy (duplicate rules) c) block/accept packets as early as possible (preferably on incoming) This method leaves few rules on outgoing segments and usually only for=20 the local rules for the firewall and makes efficient use of state = tables. With a large ruleset it becomes difficult to maintain anything with duplicate rules.=20 If this is about a firewalling/routing internet traffic (public ip = addresses) i would be extra careful about sources you can not trust when it comes = to=20 keeping state. a SYN attack or multiple instances of a virus like = blaster=20 can make the firewall slow or at worst unresponsive/crash.=20 Good luck with the firewall! _// Sten Daniel S=F8rsdal