Date: Wed, 23 Sep 1998 17:34:20 +0800 From: Peter Wemm <peter@netplex.com.au> To: Studded <Studded@dal.net> Cc: Drew Baxter <netmonger@genesis.ispace.com>, rotel@indigo.ie, FreeBSD Hackers <hackers@FreeBSD.ORG> Subject: Re: Packet/traffic shapper ? Message-ID: <199809230934.RAA14233@spinner.netplex.com.au> In-Reply-To: Your message of "Wed, 23 Sep 1998 00:37:29 MST." <3608A539.B9BD103E@dal.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Studded wrote: > Drew Baxter wrote: > > > > At 12:49 AM 9/23/98 +0000, Niall Smart wrote: > > > > > >Personally I don't think IPFW_DEFAULT_TO_ACCEPT is a bad idea, once you > > >are sure you have the accept rules necessary to ensure your connectivity > > >to the host you can pop in a deny all rule. This will probably be slower > > >than defaulting to deny though. > > --- > > Hm, isn't default_to_accept still affected by ipfw flush? > > No it's not, that's one of the reasons the option was added. The other reason it's an option is because it's a tradeoff situation. An inclusive filter (ie: only explicitly allow defined packets) is compromised if an accident happens or somebody can make the box fall over and somehow not reload it's filters properly. With an exclusive strategy (eg: ISP, who is in the business of carrying data rather than dropping it), it's beneficial to have it open by default so that specific things can be filtered when and as needed without the risk of accidents closing everything down. Generally, accidently leaving the barn door open and everything running away generally is far worse than having to drive to fix the damn thing. "Generally" is the key. One policy doesn't always fit everybody perfectly, but having it this way seems the lesser of the evils. > Doug Cheers, -Peter -- Peter Wemm <peter@netplex.com.au> Netplex Consulting "No coffee, No workee!" :-) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199809230934.RAA14233>