From owner-freebsd-hackers Wed Sep 23 11:22:51 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA15735 for freebsd-hackers-outgoing; Wed, 23 Sep 1998 11:22:51 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from Loki.orland.u91.k12.me.us (Loki.orland.u91.k12.me.us [169.244.111.67]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA15693 for ; Wed, 23 Sep 1998 11:22:35 -0700 (PDT) (envelope-from netmonger@genesis.ispace.com) Received: from Celeris (56k-port4019.ime.net [209.90.195.29]) by Loki.orland.u91.k12.me.us (8.8.8/8.8.8) with SMTP id OAA12508; Wed, 23 Sep 1998 14:21:09 -0400 (EDT) (envelope-from netmonger@genesis.ispace.com) Message-Id: <199809231821.OAA12508@Loki.orland.u91.k12.me.us> X-Server-Comment: Sent via OCSNet/Orland, Admin is: Droobie@Onenetwork.orland.me.us X-Sender: netmonger@genesis.ispace.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1.0.52 (Beta) Date: Wed, 23 Sep 1998 14:20:35 -0400 To: Peter Wemm , Studded From: Drew Baxter Subject: Re: Packet/traffic shapper ? Cc: rotel@indigo.ie, FreeBSD Hackers In-Reply-To: <199809230934.RAA14233@spinner.netplex.com.au> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Sure I agree with that.. But we're a school.. There's only 2 types of classes we should have accessing the box... Me, and the school end. So our IPFW works with nothing active, then goes and allows my block, the schools block, and then everyone else is just 25, 80, or 113.. 113 being identd if I recall, 80 for web, and 25 for the mail transactions. I think 53 is thrown in there too to allow for the DNS services.. But maybe the Secondary DNS is the handler. At 05:34 PM 9/23/98 +0800, Peter Wemm wrote: >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 Netplex Consulting >"No coffee, No workee!" :-) > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message