From owner-freebsd-stable Sun Feb 25 02:18:59 1996 Return-Path: owner-stable Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id CAA23861 for stable-outgoing; Sun, 25 Feb 1996 02:18:59 -0800 (PST) Received: from asstdc.scgt.oz.au (root@asstdc.scgt.oz.au [202.14.234.65]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id CAA23850 for ; Sun, 25 Feb 1996 02:18:54 -0800 (PST) Received: (from imb@localhost) by asstdc.scgt.oz.au (8.6.12/BSD4.4) id VAA08266 for stable@freebsd.org; Sun, 25 Feb 1996 21:18:44 +1100 From: michael butler Message-Id: <199602251018.VAA08266@asstdc.scgt.oz.au> Subject: -stable hangs at boot To: stable@freebsd.org Date: Sun, 25 Feb 1996 21:18:40 +1100 (EST) X-Mailer: ELM [version 2.4 PL24beta] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-stable@freebsd.org Precedence: bulk Having backed out the troublesome /usr/lib/libc/db/hash/hash.c change, I still have the problem of a recently built -stable kernel stopping during start-up immediately after "ifconfig ed0 .." but before "ifconfig lo0 .." If I wait long enough, it seems that it will eventually continue but cannot transmit packets at all on the ed0 interface. This is a single-homed host with a WD8013EPC configured to be at port 0x280, irq 5 and iomem of 0xd8000. If I boot my previous -stable, it comes up normally although having done a "make world" things like ps don't do as they should :-( michael From owner-freebsd-stable Sun Feb 25 20:05:29 1996 Return-Path: owner-stable Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id UAA17681 for stable-outgoing; Sun, 25 Feb 1996 20:05:29 -0800 (PST) Received: from asstdc.scgt.oz.au (root@asstdc.scgt.oz.au [202.14.234.65]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id UAA17675 for ; Sun, 25 Feb 1996 20:05:22 -0800 (PST) Received: (from imb@localhost) by asstdc.scgt.oz.au (8.6.12/BSD4.4) id PAA00794 for stable@freebsd.org; Mon, 26 Feb 1996 15:05:19 +1100 From: michael butler Message-Id: <199602260405.PAA00794@asstdc.scgt.oz.au> Subject: Opti 82C895 cache coherency ? To: stable@freebsd.org Date: Mon, 26 Feb 1996 15:05:18 +1100 (EST) X-Mailer: ELM [version 2.4 PL24beta] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-stable@freebsd.org Precedence: bulk I wonder if anyone can vouch for an Opti 82C895 motherboard with an AMD 486DX4/100 in respect of cache coherency. Specifically, in combination with an Adaptec 2842 (VLB) controller. Just trying to track down a "quirk" with a (sort of working) -stable .. I don't know if it's -stable or the motherboard :-( michael From owner-freebsd-stable Mon Feb 26 03:15:52 1996 Return-Path: owner-stable Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id DAA12590 for stable-outgoing; Mon, 26 Feb 1996 03:15:52 -0800 (PST) Received: from hawk.gnome.co.uk (gnome.intecc.co.uk [194.72.95.90]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id DAA12585 for ; Mon, 26 Feb 1996 03:15:46 -0800 (PST) Received: (from jacs@localhost) by hawk.gnome.co.uk (8.6.12/8.6.12) id LAA28842; Mon, 26 Feb 1996 11:13:14 GMT Date: Mon, 26 Feb 1996 11:13:14 GMT From: Chris Stenton Subject: make world fail To: stable@freebsd.org Message-Id: Sender: owner-stable@freebsd.org Precedence: bulk I have just had a make world fail on todays sup cd /usr/src/lib/libutil && make beforeinstall install -C -o bin -g bin -m 444 /usr1/FreeBSD-stable/src/lib/libutil/libutil.h /usr/include install: illegal option -- C usage: install [-cs] [-f flags] [-g group] [-m mode] [-o owner] file1 file2; or file1 ... fileN directory *** Error code 1 From owner-freebsd-stable Mon Feb 26 04:29:22 1996 Return-Path: owner-stable Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id EAA15985 for stable-outgoing; Mon, 26 Feb 1996 04:29:22 -0800 (PST) Received: from asstdc.scgt.oz.au (root@asstdc.scgt.oz.au [202.14.234.65]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id EAA15963 Mon, 26 Feb 1996 04:29:02 -0800 (PST) Received: (from imb@localhost) by asstdc.scgt.oz.au (8.6.12/BSD4.4) id XAA07877; Mon, 26 Feb 1996 23:28:57 +1100 From: michael butler Message-Id: <199602261228.XAA07877@asstdc.scgt.oz.au> Subject: -stable hangs at boot (fwd) To: stable@freebsd.org Date: Mon, 26 Feb 1996 23:28:56 +1100 (EST) Cc: current@freebsd.org X-Mailer: ELM [version 2.4 PL24beta] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-stable@freebsd.org Precedence: bulk I wrote: > Having backed out the troublesome /usr/lib/libc/db/hash/hash.c change, I > still have the problem of a recently built -stable kernel stopping during > start-up immediately after "ifconfig ed0 .." but before "ifconfig lo0 .." > If I wait long enough, it seems that it will eventually continue but cannot > transmit packets at all on the ed0 interface. This is as a direct consequence of compiling IPFW into the kernel .. it can't receive packets from its own ethernet interface ! If you ^C your way to a shell prompt, there's a single rule that's in the firewall list saying "deny all from any to any". Courtesy of the same recent brain-damage in ipfw(8), you can't delete this rule either ("setsockopt failed"). I suspect the very same problem in -current. The only workaround I can think of is to add "ipfw addf accept .." statements _prior_ to the running of ifconfig in netstart .. theory as yet untested .. michael From owner-freebsd-stable Mon Feb 26 05:26:37 1996 Return-Path: owner-stable Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id FAA18151 for stable-outgoing; Mon, 26 Feb 1996 05:26:37 -0800 (PST) Received: from tfs.com (tfs.com [140.145.250.1]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id FAA18129 Mon, 26 Feb 1996 05:26:32 -0800 (PST) Received: from critter.tfs.com by tfs.com (smail3.1.28.1) with SMTP id m0tr2wc-0003wSC; Mon, 26 Feb 96 05:26 PST Received: from localhost.tfs.com (localhost.tfs.com [127.0.0.1]) by critter.tfs.com (8.6.12/8.6.12) with SMTP id OAA11366; Mon, 26 Feb 1996 14:26:25 +0100 X-Authentication-Warning: critter.tfs.com: Host localhost.tfs.com didn't use HELO protocol To: michael butler cc: stable@freebsd.org, current@freebsd.org Subject: Re: -stable hangs at boot (fwd) In-reply-to: Your message of "Mon, 26 Feb 1996 23:28:56 +1100." <199602261228.XAA07877@asstdc.scgt.oz.au> Date: Mon, 26 Feb 1996 14:26:23 +0100 Message-ID: <11364.825341183@critter.tfs.com> From: Poul-Henning Kamp Sender: owner-stable@freebsd.org Precedence: bulk > If you ^C your way to a shell prompt, there's a single rule that's in the > firewall list saying "deny all from any to any". Courtesy of the same recent > brain-damage in ipfw(8), you can't delete this rule either ("setsockopt > failed"). If you call this "brain-damage" then you quite clearly don't need IPFW. > I suspect the very same problem in -current. > > The only workaround I can think of is to add "ipfw addf accept .." > statements _prior_ to the running of ifconfig in netstart .. theory as yet > untested .. This is all correct, designed that way, and it is the way it should work, according to all material I have on the subject. If you have IPFW in your kernel, you don't want it to pass any packets you haven't approved in your filters. QED: Setup your filters before anything gets passed. Wrt to the rule #65535 "deny all from any to any", then you are correct, you cannot delete it. It represents the default policy of "anything not specifically allowed, is banned. If you want to have another policy, they you must define rules that implement that policy, "65000 allow all from any to any" sounds like the policy for your needs. If you want to dispute this design, then please find at least one textbook or capacity in the area who agree with you first, that will save a lot of my time. -- Poul-Henning Kamp | phk@FreeBSD.ORG FreeBSD Core-team. http://www.freebsd.org/~phk | phk@login.dknet.dk Private mailbox. whois: [PHK] | phk@ref.tfs.com TRW Financial Systems, Inc. Future will arrive by its own means, progress not so. From owner-freebsd-stable Mon Feb 26 05:41:42 1996 Return-Path: owner-stable Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id FAA19004 for stable-outgoing; Mon, 26 Feb 1996 05:41:42 -0800 (PST) Received: from asstdc.scgt.oz.au (root@asstdc.scgt.oz.au [202.14.234.65]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id FAA18978 Mon, 26 Feb 1996 05:41:31 -0800 (PST) Received: (from imb@localhost) by asstdc.scgt.oz.au (8.6.12/BSD4.4) id AAA09032; Tue, 27 Feb 1996 00:41:16 +1100 From: michael butler Message-Id: <199602261341.AAA09032@asstdc.scgt.oz.au> Subject: Re: -stable hangs at boot (fwd) To: phk@critter.tfs.com (Poul-Henning Kamp) Date: Tue, 27 Feb 1996 00:41:15 +1100 (EST) Cc: stable@freebsd.org, current@freebsd.org In-Reply-To: <11364.825341183@critter.tfs.com> from "Poul-Henning Kamp" at Feb 26, 96 02:26:23 pm X-Mailer: ELM [version 2.4 PL24beta] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-stable@freebsd.org Precedence: bulk Poul-Henning Kamp writes: > > If you ^C your way to a shell prompt, there's a single rule that's in > > the firewall list saying "deny all from any to any". Courtesy of the > > same recent brain-damage in ipfw(8), you can't delete this rule either > > ("setsockopt failed"). > If you call this "brain-damage" then you quite clearly don't need IPFW. I call it "brain-damage" to render a machine unbootable because it can't "see" it's _own_ interfaces. AFAIK, firewalls by default prevent packets passing _through_ them but are themselves permitted to talk to anything they have a route to (the previous behaviour with a default policy of "deny"). A direct connection (interface in the same box) constitutes having a "route to". Further, there are no hints whatsoever in the current rc, sysconfig, netstart, et al to indicate that this (current condition) is the problem. Even if this (IMHO unusual) behaviour was documented it wouldn't be so much of a problem, michael From owner-freebsd-stable Mon Feb 26 05:47:01 1996 Return-Path: owner-stable Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id FAA19310 for stable-outgoing; Mon, 26 Feb 1996 05:47:01 -0800 (PST) Received: from tfs.com (tfs.com [140.145.250.1]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id FAA19293 Mon, 26 Feb 1996 05:46:57 -0800 (PST) Received: from critter.tfs.com by tfs.com (smail3.1.28.1) with SMTP id m0tr3GR-0003wgC; Mon, 26 Feb 96 05:46 PST Received: from localhost.tfs.com (localhost.tfs.com [127.0.0.1]) by critter.tfs.com (8.6.12/8.6.12) with SMTP id OAA11447; Mon, 26 Feb 1996 14:46:56 +0100 X-Authentication-Warning: critter.tfs.com: Host localhost.tfs.com didn't use HELO protocol To: michael butler cc: stable@freebsd.org, current@freebsd.org Subject: Re: -stable hangs at boot (fwd) In-reply-to: Your message of "Tue, 27 Feb 1996 00:41:15 +1100." <199602261341.AAA09032@asstdc.scgt.oz.au> Date: Mon, 26 Feb 1996 14:46:55 +0100 Message-ID: <11445.825342415@critter.tfs.com> From: Poul-Henning Kamp Sender: owner-stable@freebsd.org Precedence: bulk > Poul-Henning Kamp writes: > > > > If you ^C your way to a shell prompt, there's a single rule that's in > > > the firewall list saying "deny all from any to any". Courtesy of the > > > same recent brain-damage in ipfw(8), you can't delete this rule either > > > ("setsockopt failed"). > > > If you call this "brain-damage" then you quite clearly don't need IPFW. > > I call it "brain-damage" to render a machine unbootable because it can't > "see" it's _own_ interfaces. AFAIK, firewalls by default prevent packets > passing _through_ them but are themselves permitted to talk to anything they > have a route to (the previous behaviour with a default policy of "deny"). A > direct connection (interface in the same box) constitutes having a "route to" Well, this happens to be your view. I know machines where IPFW are being used to restrict what users on the machine can do, this is only possible if you filter >ALL< traffic, to and from the machine. The IPFW is not a policy, it's a tool to implement policies. As such it needs to be able to implement the widest possible range of policies. > Further, there are no hints whatsoever in the current rc, sysconfig, > netstart, et al to indicate that this (current condition) is the problem. > Even if this (IMHO unusual) behaviour was documented it wouldn't be so much > of a problem, No, this is still on it's way. You should be on -committers if you run -stable or -current. If you were, you would have seen it. -- Poul-Henning Kamp | phk@FreeBSD.ORG FreeBSD Core-team. http://www.freebsd.org/~phk | phk@login.dknet.dk Private mailbox. whois: [PHK] | phk@ref.tfs.com TRW Financial Systems, Inc. Future will arrive by its own means, progress not so. From owner-freebsd-stable Mon Feb 26 06:06:13 1996 Return-Path: owner-stable Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id GAA20388 for stable-outgoing; Mon, 26 Feb 1996 06:06:13 -0800 (PST) Received: from asstdc.scgt.oz.au (root@asstdc.scgt.oz.au [202.14.234.65]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id GAA20368 Mon, 26 Feb 1996 06:06:08 -0800 (PST) Received: (from imb@localhost) by asstdc.scgt.oz.au (8.6.12/BSD4.4) id BAA09438; Tue, 27 Feb 1996 01:05:50 +1100 From: michael butler Message-Id: <199602261405.BAA09438@asstdc.scgt.oz.au> Subject: Re: -stable hangs at boot (fwd) To: phk@critter.tfs.com (Poul-Henning Kamp) Date: Tue, 27 Feb 1996 01:05:48 +1100 (EST) Cc: stable@freebsd.org, current@freebsd.org In-Reply-To: <11445.825342415@critter.tfs.com> from "Poul-Henning Kamp" at Feb 26, 96 02:46:55 pm X-Mailer: ELM [version 2.4 PL24beta] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-stable@freebsd.org Precedence: bulk Poul-Henning Kamp writes: > Well, this happens to be your view. I know machines where IPFW are being > used to restrict what users on the machine can do, this is only possible > if you filter >ALL< traffic, to and from the machine. OK .. but, personally, I wouldn't call or attempt to use those boxes as firewalls .. any "sensitive" firewall/filtering router I have control over has two valid accounts which have any access at all, mine and one other, with limited privilege, for daily monitoring. No users == much reduced risk. If security is _that_ important, investing in a dedicated box to do the job is cheap at triple the price :-) > The IPFW is not a policy, it's a tool to implement policies. As such it > needs to be able to implement the widest possible range of policies. I can see where you're coming from .. but this behaviour caught me out because it is unusual and I'm sure it'll catch many others :-(. > You should be on -committers if you run -stable or -current. If you were, > you would have seen it. If I could get half-way through the stuff I'm obliged to read now .. michael From owner-freebsd-stable Mon Feb 26 06:22:15 1996 Return-Path: owner-stable Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id GAA21117 for stable-outgoing; Mon, 26 Feb 1996 06:22:15 -0800 (PST) Received: from tfs.com (tfs.com [140.145.250.1]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id GAA21096 Mon, 26 Feb 1996 06:22:11 -0800 (PST) Received: from critter.tfs.com by tfs.com (smail3.1.28.1) with SMTP id m0tr3oX-0003wSC; Mon, 26 Feb 96 06:22 PST Received: from localhost.tfs.com (localhost.tfs.com [127.0.0.1]) by critter.tfs.com (8.6.12/8.6.12) with SMTP id PAA11521; Mon, 26 Feb 1996 15:22:10 +0100 X-Authentication-Warning: critter.tfs.com: Host localhost.tfs.com didn't use HELO protocol To: michael butler cc: stable@freebsd.org, current@freebsd.org Subject: Re: -stable hangs at boot (fwd) In-reply-to: Your message of "Tue, 27 Feb 1996 01:05:48 +1100." <199602261405.BAA09438@asstdc.scgt.oz.au> Date: Mon, 26 Feb 1996 15:22:08 +0100 Message-ID: <11519.825344528@critter.tfs.com> From: Poul-Henning Kamp Sender: owner-stable@freebsd.org Precedence: bulk > Poul-Henning Kamp writes: > > > Well, this happens to be your view. I know machines where IPFW are being > > used to restrict what users on the machine can do, this is only possible > > if you filter >ALL< traffic, to and from the machine. > > OK .. but, personally, I wouldn't call or attempt to use those boxes as > firewalls .. any "sensitive" firewall/filtering router I have control over > has two valid accounts which have any access at all, mine and one other, > with limited privilege, for daily monitoring. No users == much reduced risk. I agree, I'd do that too. However, that is all a question of what your policy is. The IPFW, should not affect your policy, but merely be able to implement it. > If security is _that_ important, investing in a dedicated box to do the job > is cheap at triple the price :-) depends, sometimes other things are of some importance too :-) > > The IPFW is not a policy, it's a tool to implement policies. As such it > > needs to be able to implement the widest possible range of policies. > > I can see where you're coming from .. but this behaviour caught me out > because it is unusual and I'm sure it'll catch many others :-(. I'm sure about that too, that is really too bad :-( However, the reason why I'm in this business right now was that a (by now documented) criminal person gained access through a FreeBSD firewall, even though the filters claimed that it wasn't possible. This was not something I could have sitting on my shoulders as a security supplier. I decided to fix it once and for all, so that the policy would be entirely in the hands of the sysadmin, rather than some of it being done in a very obscure piece of code. Security will always require people to know what they do, unfortunately. > > You should be on -committers if you run -stable or -current. If you were, > > you would have seen it. > > If I could get half-way through the stuff I'm obliged to read now .. Talk to me about it... Ohh, and don't forget to read >all< of Terrys emails :-) Now, how about you check out the ipfw.8 from -current and send me your comments, and possibly a couple of good commented rule-sets for the doc, then I'll make sure the kernel-code does what we want it to and what we think ? -- Poul-Henning Kamp | phk@FreeBSD.ORG FreeBSD Core-team. http://www.freebsd.org/~phk | phk@login.dknet.dk Private mailbox. whois: [PHK] | phk@ref.tfs.com TRW Financial Systems, Inc. Future will arrive by its own means, progress not so. From owner-freebsd-stable Mon Feb 26 06:44:41 1996 Return-Path: owner-stable Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id GAA22157 for stable-outgoing; Mon, 26 Feb 1996 06:44:41 -0800 (PST) Received: from brasil.moneng.mei.com (brasil.moneng.mei.com [151.186.109.160]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id GAA22136 Mon, 26 Feb 1996 06:44:34 -0800 (PST) Received: (from jgreco@localhost) by brasil.moneng.mei.com (8.7.Beta.1/8.7.Beta.1) id IAA15422; Mon, 26 Feb 1996 08:43:14 -0600 From: Joe Greco Message-Id: <199602261443.IAA15422@brasil.moneng.mei.com> Subject: Re: -stable hangs at boot (fwd) To: imb@scgt.oz.au (michael butler) Date: Mon, 26 Feb 1996 08:43:14 -0600 (CST) Cc: phk@critter.tfs.com, stable@freebsd.org, current@freebsd.org In-Reply-To: <199602261341.AAA09032@asstdc.scgt.oz.au> from "michael butler" at Feb 27, 96 00:41:15 am X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-stable@freebsd.org Precedence: bulk > Poul-Henning Kamp writes: > > > > If you ^C your way to a shell prompt, there's a single rule that's in > > > the firewall list saying "deny all from any to any". Courtesy of the > > > same recent brain-damage in ipfw(8), you can't delete this rule either > > > ("setsockopt failed"). > > > If you call this "brain-damage" then you quite clearly don't need IPFW. > > I call it "brain-damage" to render a machine unbootable because it can't > "see" it's _own_ interfaces. AFAIK, firewalls by default prevent packets > passing _through_ them but are themselves permitted to talk to anything they > have a route to (the previous behaviour with a default policy of "deny"). A > direct connection (interface in the same box) constitutes having a "route to". Sorry, I quite vehemently disagree. In order to preserve any pretense of being a firewall, the firewall itself MUST be able to be protected by the same policies that protect the networks it is protecting. My firewalls generally drop *everything* bound for themselves (i.e. you CANNOT telnet, ftp, NFS, finger, ping, etc from EITHER side of the firewall, the policy is that external packets may not cause the firewall to execute programs, modify data, etc - only route packets). This policy guarantees the invulnerability of the firewall - and generally the nets that I firewall have similar rules. You cannot have a firewall that firewalls routed packets but not packets to itself. The chance exists for someone to cause something to happen on the firewall (be it a telnet session, whatever), and once your firewall is compromised, the firewall is useless. The firewall MUST be effectively protected itself. My 2.0.5R/2.1.0R firewalls start out with the assumption that the world is not firewalled and I build firewalls from that point, restricting vast ranges. It would probably be "easier" for the reverse to happen, at least for me. Either way - I don't care because I know the desired end result. > Further, there are no hints whatsoever in the current rc, sysconfig, > netstart, et al to indicate that this (current condition) is the problem. > Even if this (IMHO unusual) behaviour was documented it wouldn't be so much > of a problem, Sure, absolutely agree with that! :-) ... Joe ------------------------------------------------------------------------------- Joe Greco - Systems Administrator jgreco@ns.sol.net Solaria Public Access UNIX - Milwaukee, WI 414/546-7968 From owner-freebsd-stable Mon Feb 26 06:44:53 1996 Return-Path: owner-stable Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id GAA22184 for stable-outgoing; Mon, 26 Feb 1996 06:44:53 -0800 (PST) Received: from lear35.cytex.com (mbartley@lear35.cytex.com [38.252.97.5]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id GAA22177 for ; Mon, 26 Feb 1996 06:44:51 -0800 (PST) Received: (from mbartley@localhost) by lear35.cytex.com (8.7.3/8.6.9) id GAA05615 for stable@freebsd.org; Mon, 26 Feb 1996 06:44:29 -0800 From: Matt Bartley Message-Id: <199602261444.GAA05615@lear35.cytex.com> Subject: Re: make world fail To: stable@freebsd.org Date: Mon, 26 Feb 1996 06:44:28 -0800 (PST) In-Reply-To: from "Chris Stenton" at Feb 26, 96 11:13:14 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-stable@freebsd.org Precedence: bulk > I have just had a make world fail on todays sup > > cd /usr/src/lib/libutil && make beforeinstall > install -C -o bin -g bin -m 444 /usr1/FreeBSD-stable/src/lib/libutil/libutil.h /usr/include > install: illegal option -- C > usage: install [-cs] [-f flags] [-g group] [-m mode] [-o owner] file1 file2; > or file1 ... fileN directory > *** Error code 1 This happens in /usr/src/lib/libutil/ and /usr/src/gnu/lib/libgmp/. Edit the Makefiles in those two directories and replace the -C with -c in the line beginning with ${INSTALL}. Unfortunately, this has to be done after each sup, because the Makefiles will be changed back after a sup. From owner-freebsd-stable Mon Feb 26 06:55:59 1996 Return-Path: owner-stable Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id GAA22606 for stable-outgoing; Mon, 26 Feb 1996 06:55:59 -0800 (PST) Received: from brasil.moneng.mei.com (brasil.moneng.mei.com [151.186.109.160]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id GAA22588 Mon, 26 Feb 1996 06:55:55 -0800 (PST) Received: (from jgreco@localhost) by brasil.moneng.mei.com (8.7.Beta.1/8.7.Beta.1) id IAA15449; Mon, 26 Feb 1996 08:54:41 -0600 From: Joe Greco Message-Id: <199602261454.IAA15449@brasil.moneng.mei.com> Subject: Re: -stable hangs at boot (fwd) To: phk@critter.tfs.com (Poul-Henning Kamp) Date: Mon, 26 Feb 1996 08:54:40 -0600 (CST) Cc: imb@scgt.oz.au, stable@freebsd.org, current@freebsd.org In-Reply-To: <11519.825344528@critter.tfs.com> from "Poul-Henning Kamp" at Feb 26, 96 03:22:08 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-stable@freebsd.org Precedence: bulk > > Poul-Henning Kamp writes: > > > > > Well, this happens to be your view. I know machines where IPFW are being > > > used to restrict what users on the machine can do, this is only possible > > > if you filter >ALL< traffic, to and from the machine. > > > > OK .. but, personally, I wouldn't call or attempt to use those boxes as > > firewalls .. any "sensitive" firewall/filtering router I have control over > > has two valid accounts which have any access at all, mine and one other, > > with limited privilege, for daily monitoring. No users == much reduced risk. > > I agree, I'd do that too. However, that is all a question of what your > policy is. The IPFW, should not affect your policy, but merely be able to > implement it. Agree. Sometimes you use IPFW for "related but not really" policy things. The uses are quite varied. My firewalls all have a "root" account and require console access, my routers have a single wheel user. But beyond that, I use it in several "insecure" places: The PPP/term servers I build will drop packets that claim a source address that is not assigned to the term server. (think: prevent IP spoofing). They also drop routing packets and a few other things that "shouldn't or don't need to happen". My public access UNIX system, Solaria, is not allowed to access the Internet directly because it doesn't generate the revenue that's paying for the T1. I use IPFW's accounting abilities in numerous places. Etc. None of these are "secure" or absolutely required, even, but the functionality of IPFW makes life so much easier. > However, the reason why I'm in this business right now was that a (by now > documented) criminal person gained access through a FreeBSD firewall, even > though the filters claimed that it wasn't possible. This was not something > I could have sitting on my shoulders as a security supplier. :-( ... Joe ------------------------------------------------------------------------------- Joe Greco - Systems Administrator jgreco@ns.sol.net Solaria Public Access UNIX - Milwaukee, WI 414/546-7968 From owner-freebsd-stable Mon Feb 26 07:25:44 1996 Return-Path: owner-stable Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id HAA24600 for stable-outgoing; Mon, 26 Feb 1996 07:25:44 -0800 (PST) Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id HAA24594 for ; Mon, 26 Feb 1996 07:25:40 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.7.4/8.6.9) with SMTP id HAA05448; Mon, 26 Feb 1996 07:25:13 -0800 (PST) To: Matt Bartley cc: stable@freebsd.org Subject: Re: make world fail In-reply-to: Your message of "Mon, 26 Feb 1996 06:44:28 PST." <199602261444.GAA05615@lear35.cytex.com> Date: Mon, 26 Feb 1996 07:25:13 -0800 Message-ID: <5446.825348313@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-stable@freebsd.org Precedence: bulk > This happens in /usr/src/lib/libutil/ and /usr/src/gnu/lib/libgmp/. > > Edit the Makefiles in those two directories and replace the -C with -c > in the line beginning with ${INSTALL}. Unfortunately, this has to be > done after each sup, because the Makefiles will be changed back after > a sup. Yikes! That really shouldn't be necessary, and we clearly have an undeclared bootstrapping dependency here. I think this was actually fixed in -current, so perhaps it just needs to be brought over. I'll look into it shortly. Jordan From owner-freebsd-stable Mon Feb 26 07:31:44 1996 Return-Path: owner-stable Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id HAA25112 for stable-outgoing; Mon, 26 Feb 1996 07:31:44 -0800 (PST) Received: from robin.mcnc.org.mcnc.org (robin.mcnc.org [128.109.130.29]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id HAA25107 for ; Mon, 26 Feb 1996 07:31:40 -0800 (PST) Received: by robin.mcnc.org.mcnc.org (8.6.9/MCNC/8-10-92) id KAA11962; Mon, 26 Feb 1996 10:31:33 -0500 for Date: Mon, 26 Feb 1996 10:31:33 -0500 From: "Frank E. Terhaar-Yonkers" Message-Id: <199602261531.KAA11962@robin.mcnc.org.mcnc.org> To: stable@FreeBSD.ORG Subject: Re: -stable hangs at boot (fwd) X-Face: ,fjtWiMPydUaSQl%8[eTg`u:^BXt&T)Sny(6w\*U"5D9H[Z$kG%Q/z;Z=NwrPiXf-aMF3R) Rsand$,]26-8>5@HD(A3A79gN|0%NHsdek4mT8E,>j+\w!~d2#nH;~NV!5a0"`5$Cj8d\or(Jy/JQ_ |uc;C[filmZ(~#lre*l:|O%d/PJFy`.5w8)sMZ-)QI3TaV"j'k Sender: owner-stable@FreeBSD.ORG Precedence: bulk Having IPACCT defined also breaks -stable. And no, I don't know WHY I had this defined, but it turns on some of the ip_fw code in ip_input.c resulting in a link error trying to find ip_fw_init. - Frank >To: michael butler >cc: stable@FreeBSD.ORG, current@FreeBSD.ORG >Subject: Re: -stable hangs at boot (fwd) >Date: Mon, 26 Feb 1996 14:26:23 +0100 >From: Poul-Henning Kamp > >> If you ^C your way to a shell prompt, there's a single rule that's in the >> firewall list saying "deny all from any to any". Courtesy of the same recent >> brain-damage in ipfw(8), you can't delete this rule either ("setsockopt >> failed"). > >If you call this "brain-damage" then you quite clearly don't need IPFW. > >> I suspect the very same problem in -current. >> >> The only workaround I can think of is to add "ipfw addf accept .." >> statements _prior_ to the running of ifconfig in netstart .. theory as yet >> untested .. > >This is all correct, designed that way, and it is the way it should work, >according to all material I have on the subject. > >If you have IPFW in your kernel, you don't want it to pass any packets >you haven't approved in your filters. > >QED: Setup your filters before anything gets passed. > >Wrt to the rule #65535 "deny all from any to any", then you are correct, >you cannot delete it. It represents the default policy of "anything not >specifically allowed, is banned. > >If you want to have another policy, they you must define rules that >implement that policy, "65000 allow all from any to any" sounds like the >policy for your needs. > >If you want to dispute this design, then please find at least one textbook >or capacity in the area who agree with you first, that will save a lot of >my time. > >-- >Poul-Henning Kamp | phk@FreeBSD.ORG FreeBSD Core-team. >http://www.freebsd.org/~phk | phk@login.dknet.dk Private mailbox. >whois: [PHK] | phk@ref.tfs.com TRW Financial Systems, Inc. >Future will arrive by its own means, progress not so. > \\\\////\\\\////\\\\\////\\\\\////\\\\////\\\\////\\\\////\\\\////\\\\////\\\\ Frank Terhaar-Yonkers, Manager High Performance Computing and Communications Research MCNC PO Box 12889 3021 Cornwallis Road Research Triangle Park, North Carolina 27709-2889 fty@mcnc.org voice (919)248-1417 FAX (919)248-1455 http://www.mcnc.org/hpcc.html From owner-freebsd-stable Mon Feb 26 07:38:19 1996 Return-Path: owner-stable Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id HAA25648 for stable-outgoing; Mon, 26 Feb 1996 07:38:19 -0800 (PST) Received: from rocky.sri.MT.net (rocky.sri.MT.net [204.182.243.10]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id HAA25640 Mon, 26 Feb 1996 07:38:15 -0800 (PST) Received: (from nate@localhost) by rocky.sri.MT.net (8.6.12/8.6.12) id IAA29287; Mon, 26 Feb 1996 08:40:53 -0700 Date: Mon, 26 Feb 1996 08:40:53 -0700 From: Nate Williams Message-Id: <199602261540.IAA29287@rocky.sri.MT.net> To: Poul-Henning Kamp Cc: michael butler , stable@freebsd.org, current@freebsd.org Subject: Re: -stable hangs at boot (fwd) In-Reply-To: <11364.825341183@critter.tfs.com> References: <199602261228.XAA07877@asstdc.scgt.oz.au> <11364.825341183@critter.tfs.com> Sender: owner-stable@freebsd.org Precedence: bulk Poul-Henning Kamp writes: > > If you ^C your way to a shell prompt, there's a single rule that's in the > > firewall list saying "deny all from any to any". Courtesy of the same recent > > brain-damage in ipfw(8), you can't delete this rule either ("setsockopt > > failed"). > > If you call this "brain-damage" then you quite clearly don't need IPFW. I understand that it's there to stop a race condition where folks can 'get into' the system before the FW rules are brought in. However, ... > > I suspect the very same problem in -current. > > > > The only workaround I can think of is to add "ipfw addf accept .." > > statements _prior_ to the running of ifconfig in netstart .. theory as yet > > untested .. > > This is all correct, designed that way, and it is the way it should work, > according to all material I have on the subject. > > If you have IPFW in your kernel, you don't want it to pass any packets > you haven't approved in your filters. > > QED: Setup your filters before anything gets passed. I can't do this on my box at all. It's a PPP connection, and *all* of the filtering is done on my PPP interface, which can vary depending on incoming calls. So, by having a default 'global' firewall entry I have a couple problems. 1) There is no established way to have it be on a per-process. This is *bad* news for me since my PPP box is also my DNS/router. I can't wait for my PPP connection to come up before I add entries, and I want all of my local machines to have access to *everything* on my router box. 2) There is no established method for adding IPFW entries in FreeBSD. If we are going to make this the default method, I think we need some hooks in /etc/netstart added to make this work. 3) The code -stable is un-documented and incomplete w/regard to -current. The documentation in -stable hasn't been updated yet. Here is the last entry for the ipfw.8 man-page. revision 1.7.4.5 date: 1996/02/23 15:28:38; author: phk; state: Exp; lines: +2 -0 Make ipfw handle the new kernel stuff. Put notice in man-page that it doesn't match reality right now. - But there have been commits since this time to the man-page, so I'm assuming that documentation has been written to document the new functionality. > Wrt to the rule #65535 "deny all from any to any", then you are correct, > you cannot delete it. It represents the default policy of "anything not > specifically allowed, is banned. While I understand why (see above), I still don't think this should be the 'global' default behavior. It should be applied on a specific interface since every gateway must have 2 interfaces, and only one will need the 'block everything' rule. Yes, I understand that I can add a 'open up everything' rule on my ethernet, but it'll also be necessary for all of my incoming PPP/SLIP connections. Also, how does this affect the PPP/SLIP startup code? Can a connection be established with the new IPFW code in place? > If you want to dispute this design, then please find at least one textbook > or capacity in the area who agree with you first, that will save a lot of > my time. I will dispute the design in that the current implementation *increases* the liklihood of errors due to lack of documentation and flexibility. The former may be the cause of the latter, but it's still a great cause of concern. Nate From owner-freebsd-stable Mon Feb 26 07:44:20 1996 Return-Path: owner-stable Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id HAA26257 for stable-outgoing; Mon, 26 Feb 1996 07:44:20 -0800 (PST) Received: from tuminfo2.informatik.tu-muenchen.de (root@tuminfo2.informatik.tu-muenchen.de [131.159.0.81]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id HAA26021 for ; Mon, 26 Feb 1996 07:41:55 -0800 (PST) Received: from sunsystem5.informatik.tu-muenchen.de ([131.159.0.125]) by tuminfo2.informatik.tu-muenchen.de with ESMTP id <26521-2>; Mon, 26 Feb 1996 16:35:38 +0100 Received: by sunsystem5.informatik.tu-muenchen.de id <15879>; Mon, 26 Feb 1996 16:35:19 +0100 To: freebsd-stable@freebsd.org Path: not-for-mail From: gruner@informatik.tu-muenchen.de (Armin Gruner) Newsgroups: muc.lists.freebsd.stable Subject: Re: make world fail Date: 26 Feb 1996 15:35:09 GMT Organization: Technische Universitaet Muenchen, Germany Lines: 22 Message-ID: <4gsjvd$dv5@sunsystem5.informatik.tu-muenchen.de> References: NNTP-Posting-Host: hprbg5.informatik.tu-muenchen.de X-Newsreader: TIN [UNIX 1.3 950824BETA PL0] Sender: owner-stable@freebsd.org Precedence: bulk Chris Stenton (jacs@gnome.co.uk) wrote: : : : I have just had a make world fail on todays sup : : cd /usr/src/lib/libutil && make beforeinstall : install -C -o bin -g bin -m 444 /usr1/FreeBSD-stable/src/lib/libutil/libutil.h /usr/include : install: illegal option -- C : usage: install [-cs] [-f flags] [-g group] [-m mode] [-o owner] file1 file2; : or file1 ... fileN directory : *** Error code 1 : Install src/usr.bin/xinstall first (or set your PATH that it will override the old /usr/bin/install) Gruss, Armin ____ Armin Gruner, Technische Universitaet, Muenchen \ / http://www.leo.org/~gruner/ \/ Nur wer sich aendert, bleibt sich treu - Wolf Biermann From owner-freebsd-stable Mon Feb 26 07:48:46 1996 Return-Path: owner-stable Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id HAA26582 for stable-outgoing; Mon, 26 Feb 1996 07:48:46 -0800 (PST) Received: from rocky.sri.MT.net (rocky.sri.MT.net [204.182.243.10]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id HAA26570 Mon, 26 Feb 1996 07:48:38 -0800 (PST) Received: (from nate@localhost) by rocky.sri.MT.net (8.6.12/8.6.12) id IAA29317; Mon, 26 Feb 1996 08:51:22 -0700 Date: Mon, 26 Feb 1996 08:51:22 -0700 From: Nate Williams Message-Id: <199602261551.IAA29317@rocky.sri.MT.net> To: Poul-Henning Kamp Cc: michael butler , stable@freebsd.org, current@freebsd.org Subject: Re: -stable hangs at boot (fwd) In-Reply-To: <11445.825342415@critter.tfs.com> References: <199602261341.AAA09032@asstdc.scgt.oz.au> <11445.825342415@critter.tfs.com> Sender: owner-stable@freebsd.org Precedence: bulk > > I call it "brain-damage" to render a machine unbootable because it > > can't "see" it's _own_ interfaces. AFAIK, firewalls by default > > prevent packets passing _through_ them but are themselves permitted > > to talk to anything they have a route to (the previous behaviour > > with a default policy of "deny"). A direct connection (interface in > > the same box) constitutes having a "route to" > > Well, this happens to be your view. I know machines where IPFW are being > used to restrict what users on the machine can do, this is only possible > if you filter >ALL< traffic, to and from the machine. This is a policy decision which is *now* the default policy for *everyone*. > The IPFW is not a policy, it's a tool to implement policies. As such it > needs to be able to implement the widest possible range of policies. It is capable of filtering all traffic into and out of a machine before w/out the the default rule. After thinking about the ramifications of this, I'm beginning to swap more towards the side of keep it more useful and document the heck out of it. Anyone who is using firewall software better be intimately knowledgable about what they are doing. If we document (there's the icky word again) the known problems with the current system w/out the obnoxious default policy (notably the race condition), then we are better off than by making the system unusable by a # of folks. > > Further, there are no hints whatsoever in the current rc, sysconfig, > > netstart, et al to indicate that this (current condition) is the problem. > > Even if this (IMHO unusual) behaviour was documented it wouldn't be so much > > of a problem, > > No, this is still on it's way. > > You should be on -committers if you run -stable or -current. If you were, > you would have seen it. I am on both, but the code in -stable is different from the code in -current, so the documentation is not up to snuff. Here's commit information for just ip_fw.c: ---------------------------- revision 1.31 date: 1996/02/24 00:17:32; author: phk; state: Exp; lines: +49 -45 The new firewall functionality: Filter on the direction (in/out). Filter on fragment/not fragment. ---------------------------- revision 1.30 date: 1996/02/23 20:11:37; author: phk; state: Exp; lines: +6 -1 I overlooked this one. ---------------------------- revision 1.29 date: 1996/02/23 15:47:49; author: phk; state: Exp; lines: +290 -719 Big sweep over the IPFIREWALL and IPACCT code. Close the ip-fragment hole. Waste less memory. Rewrite to contemporary more readable style. Kill separate IPACCT facility, use "accept" rules in IPFIREWALL. Filter incoming >and< outgoing packets. Replace "policy" by sticky "deny all" rule. Rules have numbers used for ordering and deletion. Remove "rerorder" code entirely. Count packet & bytecount matches for rules. Code in -current & -stable is now the same. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ And there have been apparently a significant commit to -current which hasn't been done to -stable at which point the documentation to -current was updated. ---------------------------- revision 1.14.4.5 date: 1996/02/23 20:10:52; author: phk; state: Exp; lines: +6 -1 Overloooked this one. ---------------------------- revision 1.14.4.4 date: 1996/02/23 15:26:03; author: phk; state: Exp; lines: +381 -694 Big sweep over the IPFIREWALL and IPACCT code. Close the ip-fragment hole. Waste less memory. Rewrite to contemporary more readable style. Kill separate IPACCT facility, use "accept" rules in IPFIREWALL. Filter incoming >and< outgoing packets. Replace "policy" by sticky "deny all" rule. Rules have numbers used for ordering and deletion. Remove "rerorder" code entirely. Count packet & bytecount matches for rules. ---------------------------- According to the -stable commit to ipfw(8) (see previous email) the documentation is invalid. Short of perusing the code (which IMHO shouldn't be necessary for -stable bits) there is no valid documentation for the code in -stable. This is unacceptable, since we are telling folks that -stable contains code that should be run in production systems. Nate From owner-freebsd-stable Mon Feb 26 08:14:17 1996 Return-Path: owner-stable Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id IAA27818 for stable-outgoing; Mon, 26 Feb 1996 08:14:17 -0800 (PST) Received: from asstdc.scgt.oz.au (root@asstdc.scgt.oz.au [202.14.234.65]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id IAA27783 Mon, 26 Feb 1996 08:14:06 -0800 (PST) Received: (from imb@localhost) by asstdc.scgt.oz.au (8.6.12/BSD4.4) id DAA14868; Tue, 27 Feb 1996 03:13:54 +1100 From: michael butler Message-Id: <199602261613.DAA14868@asstdc.scgt.oz.au> Subject: Re: -stable hangs at boot (fwd) To: phk@critter.tfs.com (Poul-Henning Kamp) Date: Tue, 27 Feb 1996 03:13:52 +1100 (EST) Cc: stable@freebsd.org, current@freebsd.org In-Reply-To: <11445.825342415@critter.tfs.com> from "Poul-Henning Kamp" at Feb 26, 96 02:46:55 pm X-Mailer: ELM [version 2.4 PL24beta] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-stable@freebsd.org Precedence: bulk Poul-Henning Kamp writes: > Well, this happens to be your view. I know machines where IPFW are being > used to restrict what users on the machine can do, this is only possible > if you filter >ALL< traffic, to and from the machine. I haven't checked this but .. what happens to a packet which matches a "reject" rule when it's not actually destined for the machine doing the filtering .. does it still generate an ICMP "host unreachable" ? This can happen, for example, with multiple subnets on one wire .. If so .. we have our incarnation of the M$ "sniper bug" that plagued WFW and WinNT boxes and which arbitrarilt shot down packets which were not theirs to kill :-( michael From owner-freebsd-stable Mon Feb 26 08:45:03 1996 Return-Path: owner-stable Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id IAA00160 for stable-outgoing; Mon, 26 Feb 1996 08:45:03 -0800 (PST) Received: from asstdc.scgt.oz.au (root@asstdc.scgt.oz.au [202.14.234.65]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id IAA00148 for ; Mon, 26 Feb 1996 08:44:58 -0800 (PST) Received: (from imb@localhost) by asstdc.scgt.oz.au (8.6.12/BSD4.4) id DAA16013; Tue, 27 Feb 1996 03:44:49 +1100 From: michael butler Message-Id: <199602261644.DAA16013@asstdc.scgt.oz.au> Subject: Re: make world fail To: mbartley@lear35.cytex.com (Matt Bartley) Date: Tue, 27 Feb 1996 03:44:46 +1100 (EST) Cc: stable@freebsd.org In-Reply-To: <199602261444.GAA05615@lear35.cytex.com> from "Matt Bartley" at Feb 26, 96 06:44:28 am X-Mailer: ELM [version 2.4 PL24beta] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-stable@freebsd.org Precedence: bulk Matt Bartley writes: > > install: illegal option -- C > Edit the Makefiles in those two directories and replace the -C with -c > in the line beginning with ${INSTALL}. Unfortunately, this has to be > done after each sup, because the Makefiles will be changed back after > a sup. Better solution .. go to /usr/src/usr.bin/xinstall .. make depend all install .. then go back to make world, michael From owner-freebsd-stable Mon Feb 26 09:15:39 1996 Return-Path: owner-stable Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id JAA01899 for stable-outgoing; Mon, 26 Feb 1996 09:15:39 -0800 (PST) Received: from haven.uniserve.com (haven.uniserve.com [198.53.215.121]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id JAA01875 Mon, 26 Feb 1996 09:15:32 -0800 (PST) Received: by haven.uniserve.com id <30786-28103>; Mon, 26 Feb 1996 09:18:08 -0800 Date: Mon, 26 Feb 1996 09:17:59 -0800 (PST) From: Tom Samplonius To: michael butler cc: Poul-Henning Kamp , stable@freebsd.org, current@freebsd.org Subject: Re: -stable hangs at boot (fwd) In-Reply-To: <199602261613.DAA14868@asstdc.scgt.oz.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-stable@freebsd.org Precedence: bulk On Tue, 27 Feb 1996, michael butler wrote: > Poul-Henning Kamp writes: > > > Well, this happens to be your view. I know machines where IPFW are being > > used to restrict what users on the machine can do, this is only possible > > if you filter >ALL< traffic, to and from the machine. > > I haven't checked this but .. what happens to a packet which matches a > "reject" rule when it's not actually destined for the machine doing the > filtering .. does it still generate an ICMP "host unreachable" ? The system shouldn't be getting packets not destined for it, unless the interface is in promiscous mode, which it not normally. Tom From owner-freebsd-stable Mon Feb 26 09:22:29 1996 Return-Path: owner-stable Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id JAA02315 for stable-outgoing; Mon, 26 Feb 1996 09:22:29 -0800 (PST) Received: from tfs.com (tfs.com [140.145.250.1]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id JAA02294 Mon, 26 Feb 1996 09:22:26 -0800 (PST) Received: from critter.tfs.com by tfs.com (smail3.1.28.1) with SMTP id m0tr6bZ-0003wmC; Mon, 26 Feb 96 09:20 PST Received: from localhost.tfs.com (localhost.tfs.com [127.0.0.1]) by critter.tfs.com (8.6.12/8.6.12) with SMTP id QAA11761; Mon, 26 Feb 1996 16:43:42 +0100 X-Authentication-Warning: critter.tfs.com: Host localhost.tfs.com didn't use HELO protocol To: Joe Greco cc: imb@scgt.oz.au, stable@freebsd.org, current@freebsd.org Subject: Re: -stable hangs at boot (fwd) In-reply-to: Your message of "Mon, 26 Feb 1996 08:54:40 CST." <199602261454.IAA15449@brasil.moneng.mei.com> Date: Mon, 26 Feb 1996 16:43:38 +0100 Message-ID: <11758.825349418@critter.tfs.com> From: Poul-Henning Kamp Sender: owner-stable@freebsd.org Precedence: bulk > I use IPFW's accounting abilities in numerous places. I would like to hear more about this: 1. is the present packet & byte count per rule enough ? 2. are you going to miss "bidir" much ? 3. do we need a precise, atomic "read & reset" operation ? 4. anything else ? -- Poul-Henning Kamp | phk@FreeBSD.ORG FreeBSD Core-team. http://www.freebsd.org/~phk | phk@login.dknet.dk Private mailbox. whois: [PHK] | phk@ref.tfs.com TRW Financial Systems, Inc. Future will arrive by its own means, progress not so. From owner-freebsd-stable Mon Feb 26 09:50:32 1996 Return-Path: owner-stable Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id JAA03888 for stable-outgoing; Mon, 26 Feb 1996 09:50:32 -0800 (PST) Received: from tfs.com (tfs.com [140.145.250.1]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id JAA03867 Mon, 26 Feb 1996 09:50:28 -0800 (PST) Received: from critter.tfs.com by tfs.com (smail3.1.28.1) with SMTP id m0tr744-0003wyC; Mon, 26 Feb 96 09:50 PST Received: from localhost.tfs.com (localhost.tfs.com [127.0.0.1]) by critter.tfs.com (8.6.12/8.6.12) with SMTP id SAA11933; Mon, 26 Feb 1996 18:50:20 +0100 X-Authentication-Warning: critter.tfs.com: Host localhost.tfs.com didn't use HELO protocol To: stable@freebsd.org, current@freebsd.org Subject: IPFW (was: Re: -stable hangs at boot) Date: Mon, 26 Feb 1996 18:50:16 +0100 Message-ID: <11931.825357016@critter.tfs.com> From: Poul-Henning Kamp Sender: owner-stable@freebsd.org Precedence: bulk I have tried to collapse three threads here, sorry for the cross-posting PHK: > If you have IPFW in your kernel, you don't want it to pass any packets PHK: > you haven't approved in your filters. PHK: > PHK: > QED: Setup your filters before anything gets passed. Nate: I can't do this on my box at all. It's a PPP connection, and *all* of Nate: the filtering is done on my PPP interface, which can vary depending on Nate: incoming calls. So, by having a default 'global' firewall entry I have Nate: a couple problems. Nate: 1) There is no established way to have it be on a per-process. This is Nate: *bad* news for me since my PPP box is also my DNS/router. I can't wait Nate: for my PPP connection to come up before I add entries, and I want all of Nate: my local machines to have access to *everything* on my router box. Yes you can. Add this to the top of /etc/netstart: ipfw add 65000 pass all from any to any. This changes your default policy to "pass everything". Then later you can add the restrictions you want to. Nate: 2) There is no established method for adding IPFW entries in FreeBSD. Nate: If we are going to make this the default method, I think we need some Nate: hooks in /etc/netstart added to make this work. This is next on my list of things. Nate: 3) The code -stable is un-documented and incomplete w/regard to Nate: -current. The documentation in -stable hasn't been updated yet. Here Nate: is the last entry for the ipfw.8 man-page. Reality has overtaken you again. A couple of hours ago I committed a almost complete synopsis and description to the man page. PHK: Wrt to the rule #65535 "deny all from any to any", then you are correct, PHK: you cannot delete it. It represents the default policy of "anything not PHK: specifically allowed, is banned. Nate: While I understand why (see above), I still don't think this should be Nate: the 'global' default behavior. I has to be the default, otherwise you leave a bunch of holes open in an "secure" installation. Nate: I will dispute the design in that the current implementation *increases* Nate: the liklihood of errors due to lack of documentation and flexibility. Nate: The former may be the cause of the latter, but it's still a great cause Nate: of concern. This I agree to, and I'm working as fast as I can to address it. I felt it was very important though, to give people a tool to shut what seems to be a published hole in the FreeBSD (ipfw) security. Comming up next :-) PHK: If you have IPFW in your kernel, you don't want it to pass any packets PHK: you haven't approved in your filters. Wollman: Um, not necessarily. I have a situation here where there is /one/ Wollman: network (out of three) that I need to isolate, and everything else Wollman: should operate normally. And You can do that now, you couldn't before. You may not care about the short time machines take to reboot, other people do. You can get what you want now, and now: so can some other people. PHK If you want to dispute this design, then please find at least one textbook PHK or capacity in the area who agree with you first, that will save a lot of PHK my time. Wollman: Appeal to irrelevant authority. Try again. Show me one sane authority on IP security that would defend "pass all" as the boot time default... IMB: I haven't checked this but .. what happens to a packet which matches a IMB: "reject" rule when it's not actually destined for the machine doing the IMB: filtering .. does it still generate an ICMP "host unreachable" ? IMB: This can happen, for example, with multiple subnets on one wire .. IMB: If so .. we have our incarnation of the M$ "sniper bug" that plagued WFW IMB: and WinNT boxes and which arbitrarilt shot down packets which were not IMB: theirs to kill :-( You decide if you want ICMP to be sent or the packet to silently be discarded. I am seriously considering to make the filtering better than it is now. To be effective, we need to be able to apply multiple chains of rules, something along the line of: "In" (per i/f), "Out" (per i/f), "routed", "to me" and "from me". I will probably post a strawman in tonight some time, then please take time to think over the issues and tell me your thoughts... Until then, rest assured that I'm not trying to make anybodys life misserable intentionally, I'm have merely tried to close a security hole, and at the same time improved your chances of doing so too... Poul-Henning From owner-freebsd-stable Mon Feb 26 10:14:06 1996 Return-Path: owner-stable Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id KAA05283 for stable-outgoing; Mon, 26 Feb 1996 10:14:06 -0800 (PST) Received: from brasil.moneng.mei.com (brasil.moneng.mei.com [151.186.109.160]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id KAA05259 Mon, 26 Feb 1996 10:14:00 -0800 (PST) Received: (from jgreco@localhost) by brasil.moneng.mei.com (8.7.Beta.1/8.7.Beta.1) id MAA15629; Mon, 26 Feb 1996 12:12:15 -0600 From: Joe Greco Message-Id: <199602261812.MAA15629@brasil.moneng.mei.com> Subject: Re: -stable hangs at boot (fwd) To: phk@critter.tfs.com (Poul-Henning Kamp) Date: Mon, 26 Feb 1996 12:12:14 -0600 (CST) Cc: jgreco@brasil.moneng.mei.com, imb@scgt.oz.au, stable@freebsd.org, current@freebsd.org In-Reply-To: <11758.825349418@critter.tfs.com> from "Poul-Henning Kamp" at Feb 26, 96 04:43:38 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-stable@freebsd.org Precedence: bulk > > I use IPFW's accounting abilities in numerous places. > > I would like to hear more about this: ****** Note: I am not running it under -stable or -current, the following comments are relative to 2.0.5R/2.1.0R and what little I am aware of as far as the changes you have made. Since you have asked, I have gone into detail about what _I_ would like to see. > 1. is the present packet & byte count per rule enough ? Adequate for what I am doing. I am worried, however, about the potential for byte count rollover, I don't know if it's a 32-bit or 64-bit quantity. I would like to be able to leave a "cumulative" counter running... > 2. are you going to miss "bidir" much ? !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! Owwwww. See below. I use it a lot :-( > 3. do we need a precise, atomic "read & reset" operation ? I am sampling hourly and my belief is that it takes less than a second to do, and a 1/3600 error is acceptable to me. However, for those folks who might be making more practical measurements (i.e. measuring NNTP traffic to various sites every 5 seconds), a read and reset operation would be great. I believe that the current implementation allows you to sample and clear (non-atomically) individual entries, but if I am wrong, I would also like to see that, preferably atomically. And as mentioned above I would like to leave a few cumulative counters running, sampling but NOT clearing them occasionally. So the answer is "Yes but not for me right now". > 4. anything else ? Okay, here's a problem I've been wanting to solve. I have a rule: ipfw adda bidirectional all from 0/0 to 0/0 via 204.95.219.1 that I use to give me a really rough guess about my T1 loading. The problem is, I handle multiple CIDR blocks. If I had a single CIDR block, I could do # Outbound traffic ipfw adda all from CIDR/20 to 0/0 via 204.95.219.1 # Inbound traffic ipfw adda all from 0/0 to CIDR/20 via 204.95.219.1 I can add multiple rules to deal with it but that seems echhy. There are also some firewalling things I can relate to this same problem. But I *know* the interface I want to watch! What I would LIKE to see: # Outbound traffic ipfw adda all from 0/0 to 0/0 sentvia 204.95.219.1 # Inbound traffic ipfw adda all from 0/0 to 0/0 rcvdvia 204.95.219.1 In other words, I would like the ability to specify the direction the packet was travelling on the "via" interface... it would pretty much kill the main use for "bidir" that I have, and give me a much more accurate idea of what's going on. How about IPFW issues? I know you didn't ask but as long as you're in the code, maybe some of these issues are of interest to you too. Is it possible to fill in the byte/packets dropped by a particular filter? (the fields in ipfw -s -a -n l are always 0) Last time I checked (2.0.5R), the "reject" keyword didn't produce a ICMP HOST_UNREACHABLE. Last time I checked (2.0.5R), the "log" (also l before reject/deny) panicked the box. I can't match specific icmp messages - i.e. I allow ping in both directions or I break ping in both directions. That bites. The "syn" protocol (to firewall TCP connections being opened in a direction) didn't seem to work. Maybe it was just me. Obviously I know you can't possibly address all of the above, but these are all issues that I believe lower the value of IPFW. Solving some/all of these problems would go a long way towards making IPFW look much more like a professional firewalling product and not just something hacked together. (not to mention increase the utility greatly!) Thanks for your efforts, ... Joe ------------------------------------------------------------------------------- Joe Greco - Systems Administrator jgreco@ns.sol.net Solaria Public Access UNIX - Milwaukee, WI 414/546-7968 From owner-freebsd-stable Mon Feb 26 10:39:34 1996 Return-Path: owner-stable Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id KAA07023 for stable-outgoing; Mon, 26 Feb 1996 10:39:34 -0800 (PST) Received: from brasil.moneng.mei.com (brasil.moneng.mei.com [151.186.109.160]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id KAA06997 Mon, 26 Feb 1996 10:39:28 -0800 (PST) Received: (from jgreco@localhost) by brasil.moneng.mei.com (8.7.Beta.1/8.7.Beta.1) id MAA15680; Mon, 26 Feb 1996 12:37:51 -0600 From: Joe Greco Message-Id: <199602261837.MAA15680@brasil.moneng.mei.com> Subject: Re: -stable hangs at boot (fwd) To: tom@uniserve.com (Tom Samplonius) Date: Mon, 26 Feb 1996 12:37:51 -0600 (CST) Cc: imb@scgt.oz.au, phk@critter.tfs.com, stable@FreeBSD.ORG, current@FreeBSD.ORG In-Reply-To: from "Tom Samplonius" at Feb 26, 96 09:17:59 am X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-stable@FreeBSD.ORG Precedence: bulk > On Tue, 27 Feb 1996, michael butler wrote: > > > Poul-Henning Kamp writes: > > > > > Well, this happens to be your view. I know machines where IPFW are being > > > used to restrict what users on the machine can do, this is only possible > > > if you filter >ALL< traffic, to and from the machine. > > > > I haven't checked this but .. what happens to a packet which matches a > > "reject" rule when it's not actually destined for the machine doing the > > filtering .. does it still generate an ICMP "host unreachable" ? > > The system shouldn't be getting packets not destined for it, unless the > interface is in promiscous mode, which it not normally. Think about: "route add -net 123.45.67.0 -netmask 0xffffff00 some.firewall.router.org 1" Not all packet delivery(/routing) is passively sitting on your butt on an Ethernet waiting for an ARP request. Sometimes you have things pushed at you by other routers :-) In my opinion it would be most useful to catch things and return ICMP HOST_UNREACHABLE messages at the firewall. Your average Cisco/etc router can do it. The only thing you might need to be careful about would be broadcasts/multicasts. ... Joe ------------------------------------------------------------------------------- Joe Greco - Systems Administrator jgreco@ns.sol.net Solaria Public Access UNIX - Milwaukee, WI 414/546-7968 From owner-freebsd-stable Mon Feb 26 11:05:10 1996 Return-Path: owner-stable Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id LAA08504 for stable-outgoing; Mon, 26 Feb 1996 11:05:10 -0800 (PST) Received: from brasil.moneng.mei.com (brasil.moneng.mei.com [151.186.109.160]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id LAA08484 Mon, 26 Feb 1996 11:05:05 -0800 (PST) Received: (from jgreco@localhost) by brasil.moneng.mei.com (8.7.Beta.1/8.7.Beta.1) id NAA15710; Mon, 26 Feb 1996 13:03:06 -0600 From: Joe Greco Message-Id: <199602261903.NAA15710@brasil.moneng.mei.com> Subject: Re: -stable hangs at boot (fwd) To: nate@sri.MT.net (Nate Williams) Date: Mon, 26 Feb 1996 13:03:06 -0600 (CST) Cc: phk@critter.tfs.com, imb@scgt.oz.au, stable@freebsd.org, current@freebsd.org In-Reply-To: <199602261540.IAA29287@rocky.sri.MT.net> from "Nate Williams" at Feb 26, 96 08:40:53 am X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-stable@freebsd.org Precedence: bulk > Poul-Henning Kamp writes: > > > If you ^C your way to a shell prompt, there's a single rule that's in the > > > firewall list saying "deny all from any to any". Courtesy of the same recent > > > brain-damage in ipfw(8), you can't delete this rule either ("setsockopt > > > failed"). > > > > If you call this "brain-damage" then you quite clearly don't need IPFW. > > I understand that it's there to stop a race condition where folks can > 'get into' the system before the FW rules are brought in. However, ... THIS can be generally solved by installing the rules before configuring the interfaces (at least that's how I do it). The disadvantage is that if you re-install the rules, you probably flush the old ones first, and you leave a small opening. That is not terrible but the ideal solution would address it. Argument FOR keeping this "default" rule, IMHO. > > QED: Setup your filters before anything gets passed. > > I can't do this on my box at all. It's a PPP connection, and *all* of > the filtering is done on my PPP interface, which can vary depending on > incoming calls. So, by having a default 'global' firewall entry I have > a couple problems. That's true. > 1) There is no established way to have it be on a per-process. This is > *bad* news for me since my PPP box is also my DNS/router. I can't wait > for my PPP connection to come up before I add entries, and I want all of > my local machines to have access to *everything* on my router box. But your local machines are well known: ipfw addf pass all from nates.net/24 to nates.router You can run a script when your PPP link {goes up, comes down} that installs further firewall entries to deal with your Internet connection, including correct dynamic addresses, etc. I'm not clear on what the problem that you perceive is. > 2) There is no established method for adding IPFW entries in FreeBSD. > If we are going to make this the default method, I think we need some > hooks in /etc/netstart added to make this work. Absolutely!!!!!!!!!!! And BEFORE the interfaces are configured AND before forwarding is enabled. I simply stuck in "sh /etc/fw", where /etc/fw is a script that flushes rules and then installs the new ones. We should probably ship one that cancels out the effect of the "default" rule, but has several other examples in it. Yes, you heard that right. In my opinion having the default drop rule is a good idea. It closes some small windows of opportunity. But it will confuse the hell out of people. By default we should "undo" the problem in the config file, document it, and give examples of configurations that offer low risk / no risk firewall profiles, which users can then uncomment and activate. > 3) The code -stable is un-documented and incomplete w/regard to > -current. The documentation in -stable hasn't been updated yet. Here > is the last entry for the ipfw.8 man-page. > > revision 1.7.4.5 > date: 1996/02/23 15:28:38; author: phk; state: Exp; lines: +2 -0 > Make ipfw handle the new kernel stuff. Put notice in man-page that it > doesn't match reality right now. > - > But there have been commits since this time to the man-page, so I'm > assuming that documentation has been written to document the new > functionality. True. > > Wrt to the rule #65535 "deny all from any to any", then you are correct, > > you cannot delete it. It represents the default policy of "anything not > > specifically allowed, is banned. > > While I understand why (see above), I still don't think this should be > the 'global' default behavior. It should be applied on a specific > interface since every gateway must have 2 interfaces, and only one will > need the 'block everything' rule. Yes, but which one? The current setup doesn't worry about it, it assumes you will open up the interface you want opened. And paranoids like me do actually firewall both interfaces :-) > Yes, I understand that I can add a > 'open up everything' rule on my ethernet, but it'll also be necessary > for all of my incoming PPP/SLIP connections. Also, how does this affect > the PPP/SLIP startup code? Can a connection be established with the new > IPFW code in place? Sure. I already run the firewall rule config script before starting any interfaces. That works. (I don't see how it would interfere with a connection being established anyways, we are firewalling at the protocol level, not the byte level). > > If you want to dispute this design, then please find at least one textbook > > or capacity in the area who agree with you first, that will save a lot of > > my time. > > I will dispute the design in that the current implementation *increases* > the liklihood of errors due to lack of documentation and flexibility. > The former may be the cause of the latter, but it's still a great cause > of concern. % cat /etc/ipfw.conf #! /bin/sh - # # Default IPFW Rule Configuration File # # The kernel has a built in rule that drops all packets. The intention is # to close any window of opportunity for potential attackers. The following # rule overrides this until a local firewall policy is implemented. # ipfw addf pass all from 0/0 to 0/0 # # To define a local firewall policy, comment out the above line and insert # new rules below that define the types of traffic you wish to permit on # your network. Please note that you will need to understand the ipfw # syntax, see man ipfw(1). Also note that by commenting out the command # above, ONLY packets allowed by your declared policy will be allowed to # pass! # # Samples: # --- Allow incoming SMTP. # ipfw addf pass tcp from 0/0 to my.net.number.0/bits 25 # --- Allow outbound SMTP. # ipfw addf pass tcp from my.net.number.0/bits to 0/0 25 # --- Allow outbound telnet. # ipfw addf pass tcp from my.net.number.0/bits to 0/0 23 # --- Allow ICMP messages (ping and friends). # ipfw addf pass icmp from 0/0 to 0/0 % Note I wrote that from memory. Somebody sanity check it, commit it, and stick if [ -f /etc/ipfw.conf -a -x /sbin/ipfw ]; then sh /etc/ipfw.conf fi into /etc/rcwhereever and we can be done with this argument :-) Or we can hash this to a bloody pulp and not make any forward progress. ... Joe ------------------------------------------------------------------------------- Joe Greco - Systems Administrator jgreco@ns.sol.net Solaria Public Access UNIX - Milwaukee, WI 414/546-7968 From owner-freebsd-stable Mon Feb 26 12:25:32 1996 Return-Path: owner-stable Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id MAA13217 for stable-outgoing; Mon, 26 Feb 1996 12:25:32 -0800 (PST) Received: from tfs.com (tfs.com [140.145.250.1]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id MAA13212 Mon, 26 Feb 1996 12:25:29 -0800 (PST) Received: from critter.tfs.com by tfs.com (smail3.1.28.1) with SMTP id m0tr9U0-0003wyC; Mon, 26 Feb 96 12:25 PST Apparently-To: , Received: from localhost.tfs.com (localhost.tfs.com [127.0.0.1]) by critter.tfs.com (8.6.12/8.6.12) with SMTP id VAA12244; Mon, 26 Feb 1996 21:25:17 +0100 X-Authentication-Warning: critter.tfs.com: Host localhost.tfs.com didn't use HELO protocol Date: Mon, 26 Feb 1996 21:25:15 +0100 Message-ID: <12238.825366315@critter.tfs.com> From: Poul-Henning Kamp Subject: IP filtering strawman, comments please. MIME-Version: 1.0 Content-Type: multipart/digest; boundary="----- =_aaaaaaaaaa" Sender: owner-stable@freebsd.org Precedence: bulk ------- =_aaaaaaaaaa To: hackers@freebsd.org Subject: IP filtering strawman, comments please. Date: Mon, 26 Feb 1996 21:25:15 +0100 Message-ID: <12238.825366315@critter.tfs.com> From: Poul-Henning Kamp Sorry for the wide cross-posting, followups to "hackers" only please ! IP filtering in FreeBSD, a strawman proposal. Poul-Henning Kamp 26 feb 1996 Ver: 1.1 This is a strawman intended to foster discussion about the future support for IP packet filtering in the FreeBSD kernel. Fig 1 shows a simplified schematic of the paths of IP packets in the FreeBSD kernel, and various potential spots for applying filters. =========================================================================== if0 --->(0i)--->+ | if1 --->(1i)--->+ | applications if2 --->(2i)--->+ ^ | | | v +--->(A)---> protocol stack --->(B)--->+ | | +--->(Ci)---> route through ---->(Co)--->+ | +--->(0o)---> if0 | +--->(1o)---> if1 | +--->(2o)---> if2 == Fig 1 ================================================================== The present support (as of 960226) provides the following support: There is one chain of rules, and it is applied at (A), (B), (Ci) and (Co). The following information is available, in addition to the packet itself: At (A) and (Ci), receiving interface. At (B) and (Co), destination interface. Now, this is clearly not optimal from particular many points, therefore I suggest the following model instead: There will be multiple chains of rules as follows: For each interface, two chains of rules. One filters incoming packets, the other outgoing packets. In Fig 1 these are the pairs (0i/0o), (1i/1o) &c. No information is available apart from the packet itself. There will be a filter-chain at (A) to filter what packets we let into the local protocol stack. In addition to the packet, information about the arrival interface is available. There will be a filter-chain at (B) to filter what packets we let out of the local protocol stack. In addition to the packet, information about the destination interface is available. There will be two filter-chains at (Ci) and (Co) to filter what packets we route through this machine. At (Ci) the arrival interface is known and at (Co) the destination interface is known in addition to the packet itself. Rules are numbered with 16 bit integers, and can appear on any number of filter-chains, such that a conceptual matrix is formed, as illustrated in Fig 2: =========================================================================== Rule# criteria 0i 1i 2i A Ci Co B 0o 1o 2o --------------------------------------------------------------------------- 00010 Deny all loose source route X X X X 00020 Deny all strict source route X X X X 00030 Deny all traffic via if0 X X 00040 Deny all tcp setup packets X X 65535 Allow all traffic X X X X X X X X X X == Fig 2 ================================================================== At each filtering point, the rules are applied in numeric order, until one of them matches the packet, the action from that rule is then taken. Just as important as where a rule can be applied, is what the rule can express, I suggest this functionality, this is more or less what we have now as well: Source-ip matches target+netmask Destination-ip matches target+netmask Protocol matches (any, udp, icmp, tcp, other). Packet has (not) ip-option(s) (loose source route, strict source route, timestamp, record route, other). Interface matches name Interface matches IP. For UDP & TCP: source-port matches target(-range) destination-port matches target(-range) For TCP: packet has (not) TCP flags (syn, rst, psh, urg, ack). Packet is (not) a non-initial fragment. Packet is (not) a broadcast. Packet is (not) a multicast. And finally, what should be done when the rule matches: "drop" the packet is discarded. "refuse" as drop, but an ICMP packet is sent if applicable. "pass" the packet is OK and continues it's merry way. "count" the counters for this rule is updated, but the rule doesn't match the packet, and the next rule is tried. "divert" the packet is sent to a (specific) instance of the tun# interface, where a user-mode process can have fun with it. Some modifiers to this exist: "printf" register the match with printf. "syslog" register the match with syslog. "verbose" be very detailed. "hexdump" be very very detailed. The changes to the code to support this scheme are rather simple: Add reference counts to each rule. Add two rule-chain headers to the if structure. Add the logic to specify what chains a rule applies to. Make sure ip_output knows if the packet was locally generated or routed. Comments ? Poul-Henning ------- =_aaaaaaaaaa-- From owner-freebsd-stable Mon Feb 26 12:25:53 1996 Return-Path: owner-stable Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id MAA13266 for stable-outgoing; Mon, 26 Feb 1996 12:25:53 -0800 (PST) Received: from rocky.sri.MT.net (rocky.sri.MT.net [204.182.243.10]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id MAA13259 Mon, 26 Feb 1996 12:25:48 -0800 (PST) Received: (from nate@localhost) by rocky.sri.MT.net (8.6.12/8.6.12) id MAA00360; Mon, 26 Feb 1996 12:26:22 -0700 Date: Mon, 26 Feb 1996 12:26:22 -0700 From: Nate Williams Message-Id: <199602261926.MAA00360@rocky.sri.MT.net> To: Poul-Henning Kamp Cc: stable@freebsd.org, current@freebsd.org Subject: Re: IPFW (was: Re: -stable hangs at boot) In-Reply-To: <11931.825357016@critter.tfs.com> References: <11931.825357016@critter.tfs.com> Sender: owner-stable@freebsd.org Precedence: bulk > I have tried to collapse three threads here, sorry for the cross-posting No problem, I like it this way and appreciate the extra work you've done. > PHK: > If you have IPFW in your kernel, you don't want it to pass any packets > PHK: > you haven't approved in your filters. > PHK: > > PHK: > QED: Setup your filters before anything gets passed. > > Nate: I can't do this on my box at all. It's a PPP connection, and *all* of > Nate: the filtering is done on my PPP interface, which can vary depending on > Nate: incoming calls. So, by having a default 'global' firewall entry I have > Nate: a couple problems. > > Nate: 1) There is no established way to have it be on a per-process. This is > Nate: *bad* news for me since my PPP box is also my DNS/router. I can't wait > Nate: for my PPP connection to come up before I add entries, and I want all of > Nate: my local machines to have access to *everything* on my router box. > > Yes you can. Add this to the top of /etc/netstart: > > ipfw add 65000 pass all from any to any. OK so far, but it needs to be in doable from a sysconfig or netstart hook (which you talk about later). > This changes your default policy to "pass everything". > Then later you can add the restrictions you want to. So far so good. :) > Nate: 2) There is no established method for adding IPFW entries in FreeBSD. > Nate: If we are going to make this the default method, I think we need some > Nate: hooks in /etc/netstart added to make this work. > This is next on my list of things. I'll be glad to see it go in. > Nate: 3) The code -stable is un-documented and incomplete w/regard to > Nate: -current. The documentation in -stable hasn't been updated yet. Here > Nate: is the last entry for the ipfw.8 man-page. > > Reality has overtaken you again. A couple of hours ago I committed a almost > complete synopsis and description to the man page. Glad to hear it, but it happened after I sup'd the CVS tree. It also appears that you need to add the patch you just made to -current into -stable as well. Don't you just hate having to keep two trees in sync sometimes? (Though the advantages outweigh the disadvantages). > PHK: Wrt to the rule #65535 "deny all from any to any", then you are correct, > PHK: you cannot delete it. It represents the default policy of "anything not > PHK: specifically allowed, is banned. > > Nate: While I understand why (see above), I still don't think this should be > Nate: the 'global' default behavior. > > I has to be the default, otherwise you leave a bunch of holes open in an > "secure" installation. Unless you require them to add a line similar to what you are requiring me to do in /etc/sysconfig. I think it should be sysconfig know to 'lock-down' the system, rather than have it be the default. It's just as easy to add a line to /etc/netstart to 'tighten up' the system as it is to 'loosen-up'. The latter will cause us much more support grief than the former. > Nate: I will dispute the design in that the current implementation *increases* > Nate: the liklihood of errors due to lack of documentation and flexibility. > Nate: The former may be the cause of the latter, but it's still a great cause > Nate: of concern. > > This I agree to, and I'm working as fast as I can to address it. I felt > it was very important though, to give people a tool to shut what seems > to be a published hole in the FreeBSD (ipfw) security. Comming up next :-) Waiting expectantly. (And I won't even bug you about reviewing the PC-CARD patches either. *grin*) > PHK: If you have IPFW in your kernel, you don't want it to pass any packets > PHK: you haven't approved in your filters. > > Wollman: Um, not necessarily. I have a situation here where there is /one/ > Wollman: network (out of three) that I need to isolate, and everything else > Wollman: should operate normally. > > And You can do that now, you couldn't before. Sure you could. I'm doing that now w/out the changes you've made. > You may not care about > the short time machines take to reboot, other people do. You can get > what you want now, and now: so can some other people. You could do it before, and can do it now if we add a line to /etc/netstart which is off by default which shuts down the entire machine. > PHK If you want to dispute this design, then please find at least one textbook > PHK or capacity in the area who agree with you first, that will save a lot of > PHK my time. > > Wollman: Appeal to irrelevant authority. Try again. > > Show me one sane authority on IP security that would defend "pass all" > as the boot time default... > I am seriously considering to make the filtering better than it is now. > > To be effective, we need to be able to apply multiple chains of rules, > something along the line of: "In" (per i/f), "Out" (per i/f), "routed", > "to me" and "from me". Doesn't the current code already do that? Obviously since it wasn't filtering outgoing packets before it didn't, but I'm not sure I could see the need for filtering differently for incoming vs. outgoing (except in the case of syn. packets). That reminds me. I haven't looked yet, but does the new code also filter out routing information? The old code didn't (and other firewall code I have used does). > Until then, rest assured that I'm not trying to make anybodys life misserable > intentionally, I'm have merely tried to close a security hole, and at the > same time improved your chances of doing so too... If you would have had the 'entire' solution in place at the same time as you made the changes I suspect most of this wouldn't be happening. Providing a solution I can't use simply makes it more difficult for me since I must do extra work to 'back out' the changes since I can't use them. I'm not tracking -current on my router box since that would be silly, but I can't even use the fixes you've put into fix holes w/out documentation. Nate From owner-freebsd-stable Mon Feb 26 12:27:33 1996 Return-Path: owner-stable Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id MAA13446 for stable-outgoing; Mon, 26 Feb 1996 12:27:33 -0800 (PST) Received: from rocky.sri.MT.net (rocky.sri.MT.net [204.182.243.10]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id MAA13425 Mon, 26 Feb 1996 12:27:24 -0800 (PST) Received: (from nate@localhost) by rocky.sri.MT.net (8.6.12/8.6.12) id MAA00322; Mon, 26 Feb 1996 12:20:04 -0700 Date: Mon, 26 Feb 1996 12:20:04 -0700 From: Nate Williams Message-Id: <199602261920.MAA00322@rocky.sri.MT.net> To: Joe Greco Cc: nate@sri.MT.net (Nate Williams), phk@critter.tfs.com, stable@freebsd.org, current@freebsd.org Subject: Re: -stable hangs at boot (fwd) In-Reply-To: <199602261903.NAA15710@brasil.moneng.mei.com> References: <199602261540.IAA29287@rocky.sri.MT.net> <199602261903.NAA15710@brasil.moneng.mei.com> Sender: owner-stable@freebsd.org Precedence: bulk Joe Greco writes: > > Poul-Henning Kamp writes: > > > > If you ^C your way to a shell prompt, there's a single rule that's in the > > > > firewall list saying "deny all from any to any". Courtesy of the same recent > > > > brain-damage in ipfw(8), you can't delete this rule either ("setsockopt > > > > failed"). > > > > > > If you call this "brain-damage" then you quite clearly don't need IPFW. > > > > I understand that it's there to stop a race condition where folks can > > 'get into' the system before the FW rules are brought in. However, ... > > THIS can be generally solved by installing the rules before configuring the > interfaces (at least that's how I do it). I can't do this on my box, since I don't know which interface is going to be used for my outgoing PPP connections until after the interface is completely up. That's the disadvantage of keeping the system running all the time no matter what the network affair is. The current system won't allow me to do this now. Now, I can explicitly force the old behavior by adding a rule to open up the world, but I haven't gained anything. The reason I think it should be open is because of support. Making the system unable to talk to *anything* at bootup is going to cause more support headaches than it's worth. If we add a line to /etc/sysconfig similar to: # Set this to yes if you want to avoid *any* possibiity of un-authorized # packets from getting into your system. # Note: # By setting this to YES, *NO* network data will be allowed into your # system, which may cause mis-configured firewalls to take a *very* # long # time to boot if they rely on external networking services. SECURE_IPFW=NO > The disadvantage is that if you re-install the rules, you probably > flush the old ones first, and you leave a small opening. That is not > terrible but the ideal solution would address it. Argument FOR > keeping this "default" rule, IMHO. I disagree for support reasons. See above. > > > QED: Setup your filters before anything gets passed. > > > > I can't do this on my box at all. It's a PPP connection, and *all* of > > the filtering is done on my PPP interface, which can vary depending on > > incoming calls. So, by having a default 'global' firewall entry I have > > a couple problems. > > That's true. > > > 1) There is no established way to have it be on a per-process. This is > > *bad* news for me since my PPP box is also my DNS/router. I can't wait > > for my PPP connection to come up before I add entries, and I want all of > > my local machines to have access to *everything* on my router box. > > But your local machines are well known: > > ipfw addf pass all from nates.net/24 to nates.router > > You can run a script when your PPP link {goes up, comes down} that installs > further firewall entries to deal with your Internet connection, including > correct dynamic addresses, etc. Which I do. However, how do I filter out packets from machines that *appear* to be mine from external now that I've setup the above default rule? > I'm not clear on what the problem that you perceive is. The old behavior was more flexible and made for less confusion. :) > In my opinion having the default drop rule is a good idea. It closes some > small windows of opportunity. But it will confuse the hell out of > people. Yep. I think we should make it really easy to add a default 'close' rule, but leave the stock behavior, because of the confusion. Make the user explicitly firewall everything rather than forcing him to open up things. This is the behavior all other firewalls take, so why should we be different? > > > Wrt to the rule #65535 "deny all from any to any", then you are correct, > > > you cannot delete it. It represents the default policy of "anything not > > > specifically allowed, is banned. > > > > While I understand why (see above), I still don't think this should be > > the 'global' default behavior. It should be applied on a specific > > interface since every gateway must have 2 interfaces, and only one will > > need the 'block everything' rule. > > Yes, but which one? The current setup doesn't worry about it, it assumes > you will open up the interface you want opened. And paranoids like me do > actually firewall both interfaces :-) There have been two people on the list that disagree with the 'policy' decision, and two that agree. I think we should go with the behavior other firewall vendors use and let the user choose his own default policy, which you and Poul are free to do. > > Yes, I understand that I can add a > > 'open up everything' rule on my ethernet, but it'll also be necessary > > for all of my incoming PPP/SLIP connections. Also, how does this affect > > the PPP/SLIP startup code? Can a connection be established with the new > > IPFW code in place? > > Sure. I already run the firewall rule config script before starting any > interfaces. That works. (I don't see how it would interfere with a > connection being established anyways, we are firewalling at the protocol > level, not the byte level). I wasn't sure if some of the 'startup' code required some IP traffic late in the game. Nate From owner-freebsd-stable Mon Feb 26 12:45:57 1996 Return-Path: owner-stable Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id MAA14716 for stable-outgoing; Mon, 26 Feb 1996 12:45:57 -0800 (PST) Received: from tfs.com (tfs.com [140.145.250.1]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id MAA14697 Mon, 26 Feb 1996 12:45:53 -0800 (PST) Received: from critter.tfs.com by tfs.com (smail3.1.28.1) with SMTP id m0tr9mM-0003x0C; Mon, 26 Feb 96 12:44 PST Received: from localhost.tfs.com (localhost.tfs.com [127.0.0.1]) by critter.tfs.com (8.6.12/8.6.12) with SMTP id VAA12321; Mon, 26 Feb 1996 21:44:16 +0100 X-Authentication-Warning: critter.tfs.com: Host localhost.tfs.com didn't use HELO protocol To: Joe Greco cc: imb@scgt.oz.au, stable@freebsd.org, current@freebsd.org Subject: Re: -stable hangs at boot (fwd) In-reply-to: Your message of "Mon, 26 Feb 1996 12:12:14 CST." <199602261812.MAA15629@brasil.moneng.mei.com> Date: Mon, 26 Feb 1996 21:44:14 +0100 Message-ID: <12319.825367454@critter.tfs.com> From: Poul-Henning Kamp Sender: owner-stable@freebsd.org Precedence: bulk > > 1. is the present packet & byte count per rule enough ? > > Adequate for what I am doing. I am worried, however, about the potential > for byte count rollover, I don't know if it's a 32-bit or 64-bit quantity. > I would like to be able to leave a "cumulative" counter running... yes, I would really love to make them 64 instead of 32, but right now the structure is 64bytes, and I'd hate to increase it to 128 :-( > > 2. are you going to miss "bidir" much ? > > !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! > > Owwwww. See below. I use it a lot :-( I thought so, it's just that we need a lot of special code to do it, and I think it is kind of messy anyway... > > 3. do we need a precise, atomic "read & reset" operation ? > > I am sampling hourly and my belief is that it takes less than a second to > do, and a 1/3600 error is acceptable to me. However, for those folks who > might be making more practical measurements (i.e. measuring NNTP traffic to > various sites every 5 seconds), a read and reset operation would be great. Ok, not bad to do. > So the answer is "Yes but not for me right now". OK, will think. > > 4. anything else ? > > Okay, here's a problem I've been wanting to solve. I have a rule: > > ipfw adda bidirectional all from 0/0 to 0/0 via 204.95.219.1 > > that I use to give me a really rough guess about my T1 loading. > > The problem is, I handle multiple CIDR blocks. If I had a single CIDR > block, I could do CIDR ? Uhm, Canned Indian Doughnut Rolls ? no, hmm, I guess, Contiguous Internet something ? > *know* the interface I want to watch! What I would LIKE to see: > > # Outbound traffic > ipfw adda all from 0/0 to 0/0 sentvia 204.95.219.1 > > # Inbound traffic > ipfw adda all from 0/0 to 0/0 rcvdvia 204.95.219.1 Check out the strawman I just emailed, and actually you can do that in the present code: ipfw add count from any to any in via 204.95.219.1 ipfw add count from any to any out via 204.95.219.1 :-) > In other words, I would like the ability to specify the direction the packet > was travelling on the "via" interface... it would pretty much kill the main > use for "bidir" that I have, and give me a much more accurate idea of what's > going on. got it :-) > How about IPFW issues? I know you didn't ask but as long as you're in the > code, maybe some of these issues are of interest to you too. > > Is it possible to fill in the byte/packets dropped by a particular filter? > (the fields in ipfw -s -a -n l are always 0) It is :-) I can see that I'm about two days ahead of you still :-) > Last time I checked (2.0.5R), the "reject" keyword didn't produce a > ICMP HOST_UNREACHABLE. It only does in some cases, I'll have to check it out a bit. It's a mine- field, so I'm very careful. > Last time I checked (2.0.5R), the "log" (also l before reject/deny) panicked > the box. doesn't now. > I can't match specific icmp messages - i.e. I allow ping in both directions > or I break ping in both directions. That bites. Hmmm, noted. > The "syn" protocol (to firewall TCP connections being opened in a direction) > didn't seem to work. Maybe it was just me. It does now, better than ever I think. Sounds like you should take a peek on the ipfw.8 manpage of -stable or -current, you may just like it :-) > Obviously I know you can't possibly address all of the above, but these are try me :-) > all issues that I believe lower the value of IPFW. Solving some/all of > these problems would go a long way towards making IPFW look much more like a > professional firewalling product and not just something hacked together. > (not to mention increase the utility greatly!) I'm looking forward to your comments on the strawman I sent out! -- Poul-Henning Kamp | phk@FreeBSD.ORG FreeBSD Core-team. http://www.freebsd.org/~phk | phk@login.dknet.dk Private mailbox. whois: [PHK] | phk@ref.tfs.com TRW Financial Systems, Inc. Future will arrive by its own means, progress not so. From owner-freebsd-stable Mon Feb 26 12:57:50 1996 Return-Path: owner-stable Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id MAA15471 for stable-outgoing; Mon, 26 Feb 1996 12:57:50 -0800 (PST) Received: from brasil.moneng.mei.com (brasil.moneng.mei.com [151.186.109.160]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id MAA15432 Mon, 26 Feb 1996 12:56:48 -0800 (PST) Received: (from jgreco@localhost) by brasil.moneng.mei.com (8.7.Beta.1/8.7.Beta.1) id OAA15921; Mon, 26 Feb 1996 14:55:26 -0600 From: Joe Greco Message-Id: <199602262055.OAA15921@brasil.moneng.mei.com> Subject: Re: -stable hangs at boot (fwd) To: nate@sri.MT.net (Nate Williams) Date: Mon, 26 Feb 1996 14:55:26 -0600 (CST) Cc: jgreco@brasil.moneng.mei.com, nate@sri.MT.net, phk@critter.tfs.com, stable@freebsd.org, current@freebsd.org In-Reply-To: <199602261920.MAA00322@rocky.sri.MT.net> from "Nate Williams" at Feb 26, 96 12:20:04 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-stable@freebsd.org Precedence: bulk > I can't do this on my box, since I don't know which interface is going > to be used for my outgoing PPP connections until after the interface is > completely up. That's the disadvantage of keeping the system running > all the time no matter what the network affair is. The current system > won't allow me to do this now. Why not? Stick a few rules with a variable in a script that is called when the interface is started. This can be driven from sysconfig, OR manually by startslip/ppp/etc. I do this all the time for routing purposes. > Now, I can explicitly force the old behavior by adding a rule to open up > the world, but I haven't gained anything. YOU haven't, but you haven't lost anything either. On the other hand, it's fixed a loophole in ipfw, and OTHERS have gained something. > The reason I think it should be open is because of support. Making the > system unable to talk to *anything* at bootup is going to cause more > support headaches than it's worth. If we add a line to /etc/sysconfig > similar to: Why not just put in the sample ipfw.conf I gave at the end of the last message... > # Set this to yes if you want to avoid *any* possibiity of un-authorized > # packets from getting into your system. > # Note: > # By setting this to YES, *NO* network data will be allowed into your > # system, which may cause mis-configured firewalls to take a *very* > # long # time to boot if they rely on external networking services. > SECURE_IPFW=NO > > > The disadvantage is that if you re-install the rules, you probably > > flush the old ones first, and you leave a small opening. That is not > > terrible but the ideal solution would address it. Argument FOR > > keeping this "default" rule, IMHO. > > I disagree for support reasons. See above. And that is plain and simple bull. The problem is circumventable at that level. Just use our heads and stick in a wide-open ipfw.conf. I *agree* we can't ship something out the door that is network-dumb!!!! But if we can do a simple wide-open configuration and SOLVE your support problem AND not punch a needless hole in IPFW, LET'S DO IT. > > But your local machines are well known: > > > > ipfw addf pass all from nates.net/24 to nates.router > > > > You can run a script when your PPP link {goes up, comes down} that installs > > further firewall entries to deal with your Internet connection, including > > correct dynamic addresses, etc. > > Which I do. However, how do I filter out packets from machines that > *appear* to be mine from external now that I've setup the above default > rule? % cat /etc/ppp/ip-up ipfw addf deny all from nates.net/24 to nates.net/25 via ${nates.dynamic.ppp.address} would work for me. > > I'm not clear on what the problem that you perceive is. > > The old behavior was more flexible and made for less confusion. :) Less confusion, maybe. More confusion when it didn't work as expected. More flexible? We'll see where this is all taken in the end. I suspect the new stuff will be most flexible. Either way I think it needs to be documented. > > In my opinion having the default drop rule is a good idea. It closes some > > small windows of opportunity. But it will confuse the hell out of > > people. > > Yep. I think we should make it really easy to add a default 'close' > rule, but leave the stock behavior, because of the confusion. Make the > user explicitly firewall everything rather than forcing him to open up > things. This is the behavior all other firewalls take, so why should we > be different? I wasn't aware that that's how other firewalls work. Really, it would be GREAT to be able to edit my "ipfw.conf" file and rerun it, not having to worry about even small holes opening when "ipfw f" runs. This is all about making IPFW act like a REAL firewall. Real firewalls DON'T open holes. We have no reason to argue with this change. The sample ipfw.conf I gave in my last message addresses your concerns, provides a system that performs as you expect, yet does not have any of the holes that the rest of us are worried about. If we can agree that this is a MOST optimal solution, let's put this to bed. Thanks, ... Joe ------------------------------------------------------------------------------- Joe Greco - Systems Administrator jgreco@ns.sol.net Solaria Public Access UNIX - Milwaukee, WI 414/546-7968 From owner-freebsd-stable Mon Feb 26 13:11:36 1996 Return-Path: owner-stable Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id NAA16531 for stable-outgoing; Mon, 26 Feb 1996 13:11:36 -0800 (PST) Received: from rocky.sri.MT.net (rocky.sri.MT.net [204.182.243.10]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id NAA16526 Mon, 26 Feb 1996 13:11:31 -0800 (PST) Received: (from nate@localhost) by rocky.sri.MT.net (8.6.12/8.6.12) id OAA00842; Mon, 26 Feb 1996 14:12:45 -0700 Date: Mon, 26 Feb 1996 14:12:45 -0700 From: Nate Williams Message-Id: <199602262112.OAA00842@rocky.sri.MT.net> To: Joe Greco Cc: nate@sri.MT.net (Nate Williams), phk@critter.tfs.com, stable@freebsd.org, current@freebsd.org Subject: Re: -stable hangs at boot (fwd) In-Reply-To: <199602262055.OAA15921@brasil.moneng.mei.com> References: <199602261920.MAA00322@rocky.sri.MT.net> <199602262055.OAA15921@brasil.moneng.mei.com> Sender: owner-stable@freebsd.org Precedence: bulk Joe Greco writes: > > I can't do this on my box, since I don't know which interface is going > > to be used for my outgoing PPP connections until after the interface is > > completely up. That's the disadvantage of keeping the system running > > all the time no matter what the network affair is. The current system > > won't allow me to do this now. > > Why not? Stick a few rules with a variable in a script that is called when > the interface is started. When I start, I don't know that it will succeed? When my link goes down, it usually means my ISP is having problem and will continue to have problems for a couple hours. During that time, a home user will dial in to the system. This user may take the ppp0 slot since the outside connection isn't used. > This can be driven from sysconfig, OR manually by > startslip/ppp/etc. I do this all the time for routing purposes. I won't know until the PPP link is successful which interface to use. Now, the first thing that happens (/etc/ppp/ip-up) is that the ipfw entries are added, but there is still that window of opportunity (which is acceptable to me) between the time the link goes up but before ip-up is run where packets can get into my machine. I consider this acceptable for me. > > Now, I can explicitly force the old behavior by adding a rule to open up > > the world, but I haven't gained anything. > > YOU haven't, but you haven't lost anything either. On the other hand, it's > fixed a loophole in ipfw, and OTHERS have gained something. See my comment. Since we have the ability to close the loophole, my concern is to minimize support headaches now. Make the default behavior less likely to bit the casual user, and make them shoot themselves in the foot by enabling it so they don't ask me questions. :) > > The reason I think it should be open is because of support. Making the > > system unable to talk to *anything* at bootup is going to cause more > > support headaches than it's worth. If we add a line to /etc/sysconfig > > similar to: > > Why not just put in the sample ipfw.conf I gave at the end of the last > message... Support. If we're going to disable it by default, then why have it enabled in the first place? > > # Set this to yes if you want to avoid *any* possibiity of un-authorized > > # packets from getting into your system. > > # Note: > > # By setting this to YES, *NO* network data will be allowed into your > > # system, which may cause mis-configured firewalls to take a *very* > > # long # time to boot if they rely on external networking services. > > SECURE_IPFW=NO > > > > > The disadvantage is that if you re-install the rules, you probably > > > flush the old ones first, and you leave a small opening. That is not > > > terrible but the ideal solution would address it. Argument FOR > > > keeping this "default" rule, IMHO. > > > > I disagree for support reasons. See above. > > And that is plain and simple bull. The problem is circumventable at that > level. Just use our heads and stick in a wide-open ipfw.conf. What's the point of having it then if it's open by default? > I *agree* we > can't ship something out the door that is network-dumb!!!! But if we can do > a simple wide-open configuration and SOLVE your support problem AND not > punch a needless hole in IPFW, LET'S DO IT. It's not punching any hole in the code. *ALL* of the firewall products I've used (not extensive by any means) are open by default and require the user to explicitly close them. If a user mis-configures the firewall it's their problem in all of the other products, why is it now FreeBSD's problem to make the users 'smarter'? > > > But your local machines are well known: > > > > > > ipfw addf pass all from nates.net/24 to nates.router > > > > > > You can run a script when your PPP link {goes up, comes down} that installs > > > further firewall entries to deal with your Internet connection, including > > > correct dynamic addresses, etc. > > > > Which I do. However, how do I filter out packets from machines that > > *appear* to be mine from external now that I've setup the above default > > rule? > > % cat /etc/ppp/ip-up > ipfw addf deny all from nates.net/24 to nates.net/25 via ${nates.dynamic.ppp.address} Ok, now all of my PPP machine are no longer able to speak to my local net, which have valid IP address in nates.net. :( Now I have to go re-write all of my rules and scripts and I've gained *NOTHING* because I have to explicitly disable the default rule anyway. You're making it *ALOT* more work for me than it needs to be. It *doesn't have to be* this hard. > > The old behavior was more flexible and made for less confusion. :) > > Less confusion, maybe. More confusion when it didn't work as > expected. I consider the 'didn't work as expected' to be bugs that are now fixed. I have problems with changing the default behavior, not with fixing bugs. > > Yep. I think we should make it really easy to add a default 'close' > > rule, but leave the stock behavior, because of the confusion. Make the > > user explicitly firewall everything rather than forcing him to open up > > things. This is the behavior all other firewalls take, so why should we > > be different? > > I wasn't aware that that's how other firewalls work. > > Really, it would be GREAT to be able to edit my "ipfw.conf" file and rerun > it, not having to worry about even small holes opening when "ipfw f" > runs. I like the way MorningStar's product works in this regard. It shuts down the link, when new entries are added, and depending on how extensive they are (I don't know what measure they use) it shuts down the link completely and re-connects. It reads a file which contains the IPFW entries, so if you modify the file you send the firewall program a HUP signal to re-read it. Unfortunately, this won't work in our case since we are using kernel code, but the general idea is sound. I'm not sure how this could be done in FreBSD though. Nate From owner-freebsd-stable Mon Feb 26 13:19:40 1996 Return-Path: owner-stable Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id NAA17284 for stable-outgoing; Mon, 26 Feb 1996 13:19:40 -0800 (PST) Received: from brasil.moneng.mei.com (brasil.moneng.mei.com [151.186.109.160]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id NAA17260 Mon, 26 Feb 1996 13:19:26 -0800 (PST) Received: (from jgreco@localhost) by brasil.moneng.mei.com (8.7.Beta.1/8.7.Beta.1) id PAA15987; Mon, 26 Feb 1996 15:17:53 -0600 From: Joe Greco Message-Id: <199602262117.PAA15987@brasil.moneng.mei.com> Subject: Re: -stable hangs at boot (fwd) To: phk@critter.tfs.com (Poul-Henning Kamp) Date: Mon, 26 Feb 1996 15:17:53 -0600 (CST) Cc: imb@scgt.oz.au, stable@freebsd.org, current@freebsd.org In-Reply-To: <12319.825367454@critter.tfs.com> from "Poul-Henning Kamp" at Feb 26, 96 09:44:14 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-stable@freebsd.org Precedence: bulk > > for byte count rollover, I don't know if it's a 32-bit or 64-bit quantity. > > I would like to be able to leave a "cumulative" counter running... > yes, I would really love to make them 64 instead of 32, but right now > the structure is 64bytes, and I'd hate to increase it to 128 :-( Ummm. :-/ Some of us wouldn't mind :-) (but some would, I know). > > > 2. are you going to miss "bidir" much ? > > > > !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! > > > > Owwwww. See below. I use it a lot :-( > > I thought so, it's just that we need a lot of special code to do it, > and I think it is kind of messy anyway... It is. But on the other hand, tracking two separate filters isn't always optimum. > > The problem is, I handle multiple CIDR blocks. If I had a single CIDR > > block, I could do > CIDR ? Uhm, Canned Indian Doughnut Rolls ? no, hmm, I guess, > Contiguous Internet something ? Classless Inter-Domain Routing. Basically classed routing is obsolete, has been for a while. You get assigned BLOCKS of address space and rather than having to route 8 class-C addresses separately, you route an entire group of addresses with a single routing table entry. For example, I "own" 206.55.64.0/20, which is composed of the sixteen "Class C" networks 206.55.64.0-206.55.79.255. However I also route some other blocks, too. This makes it a real pain to do conceptually simple filters like "How much traffic is going over my T1?" See http://www.rain.net/faq/cidr.faq.html. > Check out the strawman I just emailed, and actually you can do that in > the present code: > > ipfw add count from any to any in via 204.95.219.1 > ipfw add count from any to any out via 204.95.219.1 > > :-) !!!!! :-) I am very thrilled! > > Is it possible to fill in the byte/packets dropped by a particular filter? > > (the fields in ipfw -s -a -n l are always 0) > It is :-) I can see that I'm about two days ahead of you still :-) I'm impressed :-) > > Last time I checked (2.0.5R), the "reject" keyword didn't produce a > > ICMP HOST_UNREACHABLE. > It only does in some cases, I'll have to check it out a bit. It's a mine- > field, so I'm very careful. Yes, I can imagine :-) I just want my firewalls to do something mildly more social - like return a HOST_UNREACHABLE :-) It's not necessary, but it is cooler. > Sounds like you should take a peek on the ipfw.8 manpage of -stable or > -current, you may just like it :-) Q: Are there any differences that would prevent me from taking it and dropping it into a 2.0.5R or 2.1.0R based box (preferably with as little effort as humanly possible)?? > > Obviously I know you can't possibly address all of the above, but these are > try me :-) Please forgive me for underestimating you :-) ... Joe ------------------------------------------------------------------------------- Joe Greco - Systems Administrator jgreco@ns.sol.net Solaria Public Access UNIX - Milwaukee, WI 414/546-7968 From owner-freebsd-stable Mon Feb 26 13:58:36 1996 Return-Path: owner-stable Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id NAA20803 for stable-outgoing; Mon, 26 Feb 1996 13:58:36 -0800 (PST) Received: from brasil.moneng.mei.com (brasil.moneng.mei.com [151.186.109.160]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id NAA20755 Mon, 26 Feb 1996 13:57:58 -0800 (PST) Received: (from jgreco@localhost) by brasil.moneng.mei.com (8.7.Beta.1/8.7.Beta.1) id PAA16062; Mon, 26 Feb 1996 15:53:56 -0600 From: Joe Greco Message-Id: <199602262153.PAA16062@brasil.moneng.mei.com> Subject: Re: -stable hangs at boot (fwd) To: nate@sri.MT.net (Nate Williams) Date: Mon, 26 Feb 1996 15:53:55 -0600 (CST) Cc: jgreco@brasil.moneng.mei.com, nate@sri.MT.net, phk@critter.tfs.com, stable@freebsd.org, current@freebsd.org In-Reply-To: <199602262112.OAA00842@rocky.sri.MT.net> from "Nate Williams" at Feb 26, 96 02:12:45 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-stable@freebsd.org Precedence: bulk > Joe Greco writes: > > > I can't do this on my box, since I don't know which interface is going > > > to be used for my outgoing PPP connections until after the interface is > > > completely up. That's the disadvantage of keeping the system running > > > all the time no matter what the network affair is. The current system > > > won't allow me to do this now. > > > > Why not? Stick a few rules with a variable in a script that is called when > > the interface is started. > > When I start, I don't know that it will succeed? When my link goes > down, it usually means my ISP is having problem and will continue to > have problems for a couple hours. During that time, a home user will > dial in to the system. This user may take the ppp0 slot since the > outside connection isn't used. So.... I must be missing something. You don't (or shouldn't) CARE if someone takes the ppp0 slot. You have the flexibility to do it by address, and you have BOTH the address AND the interface in /etc/ppp/ip-up, as I recall. > > This can be driven from sysconfig, OR manually by > > startslip/ppp/etc. I do this all the time for routing purposes. > > I won't know until the PPP link is successful which interface to use. > Now, the first thing that happens (/etc/ppp/ip-up) is that the ipfw > entries are added, but there is still that window of opportunity (which > is acceptable to me) between the time the link goes up but before ip-up > is run where packets can get into my machine. I consider this > acceptable for me. And if it's not, you should still be able to write some rules that solve your problem. I guess I'm not seeing why you think this is such a problem. > > > Now, I can explicitly force the old behavior by adding a rule to open up > > > the world, but I haven't gained anything. > > > > YOU haven't, but you haven't lost anything either. On the other hand, it's > > fixed a loophole in ipfw, and OTHERS have gained something. > > See my comment. Since we have the ability to close the loophole, my > concern is to minimize support headaches now. Make the default behavior > less likely to bit the casual user, and make them shoot themselves in > the foot by enabling it so they don't ask me questions. :) I think we agree, but you are "solving" the problem by breaking the tool. > > > The reason I think it should be open is because of support. Making the > > > system unable to talk to *anything* at bootup is going to cause more > > > support headaches than it's worth. If we add a line to /etc/sysconfig > > > similar to: > > > > Why not just put in the sample ipfw.conf I gave at the end of the last > > message... > > Support. If we're going to disable it by default, then why have it > enabled in the first place? Because!!!! It DOESN'T break the tool to do so. You simply "change your mind" and allow everything to be routed. You introduce a HOLE in the wall if you do it the other way around! > > > # Set this to yes if you want to avoid *any* possibiity of un-authorized > > > # packets from getting into your system. > > > # Note: > > > # By setting this to YES, *NO* network data will be allowed into your > > > # system, which may cause mis-configured firewalls to take a *very* > > > # long # time to boot if they rely on external networking services. > > > SECURE_IPFW=NO > > > > > > > The disadvantage is that if you re-install the rules, you probably > > > > flush the old ones first, and you leave a small opening. That is not > > > > terrible but the ideal solution would address it. Argument FOR > > > > keeping this "default" rule, IMHO. > > > > > > I disagree for support reasons. See above. > > > > And that is plain and simple bull. The problem is circumventable at that > > level. Just use our heads and stick in a wide-open ipfw.conf. > > What's the point of having it then if it's open by default? Because you're bitching about support issues and how confused people will be. If we provide a default that is wide open, and samples that are not, people have the flexibility to choose what they want to do. This is what you have been arguing FOR!!! Doing it in this manner allows us to ship a perfect brick wall IPFW that doesn't suffer from "minor instances of forgetfulness" while rules are being reloaded, but also doesn't break all the networking services and cause users to scratch their heads. > > I *agree* we > > can't ship something out the door that is network-dumb!!!! But if we can do > > a simple wide-open configuration and SOLVE your support problem AND not > > punch a needless hole in IPFW, LET'S DO IT. > > It's not punching any hole in the code. *ALL* of the firewall products > I've used (not extensive by any means) are open by default and require > the user to explicitly close them. If a user mis-configures the > firewall it's their problem in all of the other products, why is it now > FreeBSD's problem to make the users 'smarter'? I've never seen a firewall product that is open by default. That is an oxymoron. But what's the objection to a simple reversal of logic? IF what you say is true, why can't we build a BETTER firewall than the next guy by reversing the logic, dealing with the immediate "learning curve" problem that network administrators may have by putting in a default rule that makes it "magically work"? Then, when they understand the deal, they can stick in whatever rules they want. AND those of us who want real firewalling don't have to contend with a hole in the wall. > > > > But your local machines are well known: > > > > > > > > ipfw addf pass all from nates.net/24 to nates.router > > > > > > > > You can run a script when your PPP link {goes up, comes down} that installs > > > > further firewall entries to deal with your Internet connection, including > > > > correct dynamic addresses, etc. > > > > > Which I do. However, how do I filter out packets from machines that > > > *appear* to be mine from external now that I've setup the above default > > > rule? > > > > % cat /etc/ppp/ip-up > > ipfw addf deny all from nates.net/24 to nates.net/25 via ${nates.dynamic.ppp.address} > > Ok, now all of my PPP machine are no longer able to speak to my local > net, which have valid IP address in nates.net. :( Maybe I don't get what you're trying to accomplish. > Now I have to go re-write all of my rules and scripts and I've gained > *NOTHING* because I have to explicitly disable the default rule anyway. > You're making it *ALOT* more work for me than it needs to be. It > *doesn't have to be* this hard. No, you can go to CVS and extract ipfw1.0 and install it and keep your head in the sand. That seems silly. IPFW needs some changes in order to be taken seriously. With some changes comes some pain. That is unfortunate. I agree. > > > The old behavior was more flexible and made for less confusion. :) > > > > Less confusion, maybe. More confusion when it didn't work as > > expected. > > I consider the 'didn't work as expected' to be bugs that are now fixed. > I have problems with changing the default behavior, not with fixing > bugs. So let me stick my "default reversing" line in your ipfw.conf, and you are once again happy. The rest of us are happy because we have a SOLID firewall. Life is good. > > > Yep. I think we should make it really easy to add a default 'close' > > > rule, but leave the stock behavior, because of the confusion. Make the > > > user explicitly firewall everything rather than forcing him to open up > > > things. This is the behavior all other firewalls take, so why should we > > > be different? > > > > I wasn't aware that that's how other firewalls work. > > > > Really, it would be GREAT to be able to edit my "ipfw.conf" file and rerun > > it, not having to worry about even small holes opening when "ipfw f" > > runs. > > I like the way MorningStar's product works in this regard. It shuts > down the link, when new entries are added, and depending on how > extensive they are (I don't know what measure they use) it shuts down > the link completely and re-connects. It reads a file which contains the > IPFW entries, so if you modify the file you send the firewall program a > HUP signal to re-read it. Unfortunately, this won't work in our case > since we are using kernel code, but the general idea is sound. I'm not > sure how this could be done in FreBSD though. ... Joe ------------------------------------------------------------------------------- Joe Greco - Systems Administrator jgreco@ns.sol.net Solaria Public Access UNIX - Milwaukee, WI 414/546-7968 From owner-freebsd-stable Mon Feb 26 14:02:51 1996 Return-Path: owner-stable Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id OAA21095 for stable-outgoing; Mon, 26 Feb 1996 14:02:51 -0800 (PST) Received: from rocky.sri.MT.net (rocky.sri.MT.net [204.182.243.10]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id OAA21089 Mon, 26 Feb 1996 14:02:38 -0800 (PST) Received: (from nate@localhost) by rocky.sri.MT.net (8.6.12/8.6.12) id PAA01109; Mon, 26 Feb 1996 15:04:06 -0700 Date: Mon, 26 Feb 1996 15:04:06 -0700 From: Nate Williams Message-Id: <199602262204.PAA01109@rocky.sri.MT.net> To: Joe Greco Cc: nate@sri.MT.net (Nate Williams), phk@critter.tfs.com, stable@freebsd.org, current@freebsd.org Subject: Re: -stable hangs at boot (fwd) In-Reply-To: <199602262153.PAA16062@brasil.moneng.mei.com> References: <199602262112.OAA00842@rocky.sri.MT.net> <199602262153.PAA16062@brasil.moneng.mei.com> Sender: owner-stable@freebsd.org Precedence: bulk > > > > I can't do this on my box, since I don't know which interface is going > > > > to be used for my outgoing PPP connections until after the interface is > > > > completely up. That's the disadvantage of keeping the system running > > > > all the time no matter what the network affair is. The current system > > > > won't allow me to do this now. > > > > > > Why not? Stick a few rules with a variable in a script that is called when > > > the interface is started. > > > > When I start, I don't know that it will succeed? When my link goes > > down, it usually means my ISP is having problem and will continue to > > have problems for a couple hours. During that time, a home user will > > dial in to the system. This user may take the ppp0 slot since the > > outside connection isn't used. > > So.... I must be missing something. You don't (or shouldn't) CARE if > someone takes the ppp0 slot. You have the flexibility to do it by address, > and you have BOTH the address AND the interface in /etc/ppp/ip-up, as I > recall. I admitted this below. But, it's *much* harder than it needs to be for now gain now. > And if it's not, you should still be able to write some rules that solve > your problem. I guess I'm not seeing why you think this is such a problem. It's more work. But, in retrospect I could have solved the problem with the time I spent answering email. :) > > See my comment. Since we have the ability to close the loophole, my > > concern is to minimize support headaches now. Make the default behavior > > less likely to bit the casual user, and make them shoot themselves in > > the foot by enabling it so they don't ask me questions. :) > > I think we agree, but you are "solving" the problem by breaking the tool. We aren't breaking anything. The tool simply blocks packets based on what you want it to do. If you want it to block *all* packets, then tell it to. I don't want it to do anything unless I tell it to. That's the purpose of the tool. > > It's not punching any hole in the code. *ALL* of the firewall products > > I've used (not extensive by any means) are open by default and require > > the user to explicitly close them. If a user mis-configures the > > firewall it's their problem in all of the other products, why is it now > > FreeBSD's problem to make the users 'smarter'? > > I've never seen a firewall product that is open by default. That is an > oxymoron. A firewall is *always* open by default. You determine what it is to firewall against. All of them haven't told me how to make policy, or force me to 'revert' behavior. Firewalls don't make policy, they enforce policy. Nate From owner-freebsd-stable Mon Feb 26 14:41:06 1996 Return-Path: owner-stable Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id OAA23584 for stable-outgoing; Mon, 26 Feb 1996 14:41:06 -0800 (PST) Received: from who.cdrom.com (who.cdrom.com [192.216.222.3]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id OAA23579 Mon, 26 Feb 1996 14:41:04 -0800 (PST) Received: from GndRsh.aac.dev.com (GndRsh.aac.dev.com [198.145.92.241]) by who.cdrom.com (8.6.12/8.6.11) with ESMTP id OAA02654 ; Mon, 26 Feb 1996 14:41:01 -0800 Received: (from rgrimes@localhost) by GndRsh.aac.dev.com (8.6.12/8.6.12) id OAA14871; Mon, 26 Feb 1996 14:38:22 -0800 From: "Rodney W. Grimes" Message-Id: <199602262238.OAA14871@GndRsh.aac.dev.com> Subject: Re: IPFW (was: Re: -stable hangs at boot) To: nate@sri.MT.net (Nate Williams) Date: Mon, 26 Feb 1996 14:38:22 -0800 (PST) Cc: phk@critter.tfs.com, stable@FreeBSD.ORG, current@FreeBSD.ORG In-Reply-To: <199602261926.MAA00360@rocky.sri.MT.net> from "Nate Williams" at Feb 26, 96 12:26:22 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-stable@FreeBSD.ORG Precedence: bulk ... > > Nate: 3) The code -stable is un-documented and incomplete w/regard to > > Nate: -current. The documentation in -stable hasn't been updated yet. Here > > Nate: is the last entry for the ipfw.8 man-page. > > > > Reality has overtaken you again. A couple of hours ago I committed a almost > > complete synopsis and description to the man page. > > Glad to hear it, but it happened after I sup'd the CVS tree. It also > appears that you need to add the patch you just made to -current into > -stable as well. Don't you just hate having to keep two trees in sync > sometimes? (Though the advantages outweigh the disadvantages). That is why I raised the little protest the other day, this should have all been done in -current, stabalized, tested, hashed out, etc, then and ONLY then should have it been brought over to -stable. As it stands now I have ``Frozen'' my stable sources until this work is done, which means I can not take advantage of several other nice fixes that just recently went in to -stable :-( :-(. Work should really be done in one branch only until it is _complete_. -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation Company Reliable computers for FreeBSD From owner-freebsd-stable Mon Feb 26 15:57:38 1996 Return-Path: owner-stable Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id PAA28410 for stable-outgoing; Mon, 26 Feb 1996 15:57:38 -0800 (PST) Received: from GndRsh.aac.dev.com (GndRsh.aac.dev.com [198.145.92.241]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id PAA28385 Mon, 26 Feb 1996 15:57:27 -0800 (PST) Received: (from rgrimes@localhost) by GndRsh.aac.dev.com (8.6.12/8.6.12) id PAA15114; Mon, 26 Feb 1996 15:55:33 -0800 From: "Rodney W. Grimes" Message-Id: <199602262355.PAA15114@GndRsh.aac.dev.com> Subject: Re: -stable hangs at boot (fwd) To: nate@sri.MT.net (Nate Williams) Date: Mon, 26 Feb 1996 15:55:33 -0800 (PST) Cc: jgreco@brasil.moneng.mei.com, nate@sri.MT.net, phk@critter.tfs.com, stable@freebsd.org, current@freebsd.org In-Reply-To: <199602262204.PAA01109@rocky.sri.MT.net> from "Nate Williams" at Feb 26, 96 03:04:06 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-stable@freebsd.org Precedence: bulk .... > > > It's not punching any hole in the code. *ALL* of the firewall products > > > I've used (not extensive by any means) are open by default and require > > > the user to explicitly close them. If a user mis-configures the > > > firewall it's their problem in all of the other products, why is it now > > > FreeBSD's problem to make the users 'smarter'? > > > > I've never seen a firewall product that is open by default. That is an > > oxymoron. > > A firewall is *always* open by default. You determine what it is to > firewall against. All of them haven't told me how to make policy, or > force me to 'revert' behavior. Firewalls don't make policy, they > enforce policy. It is not a firewall if it is always open, it is just a plain old router :-) And per the RFC's FreeBSD can not, and does not, ship with even IP forwarding turned on. -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation Company Reliable computers for FreeBSD From owner-freebsd-stable Mon Feb 26 15:58:01 1996 Return-Path: owner-stable Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id PAA28462 for stable-outgoing; Mon, 26 Feb 1996 15:58:01 -0800 (PST) Received: from rocky.sri.MT.net (rocky.sri.MT.net [204.182.243.10]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id PAA28453 Mon, 26 Feb 1996 15:57:58 -0800 (PST) Received: (from nate@localhost) by rocky.sri.MT.net (8.6.12/8.6.12) id RAA01738; Mon, 26 Feb 1996 17:00:33 -0700 Date: Mon, 26 Feb 1996 17:00:33 -0700 From: Nate Williams Message-Id: <199602270000.RAA01738@rocky.sri.MT.net> To: "Rodney W. Grimes" Cc: nate@sri.MT.net (Nate Williams), stable@freebsd.org, current@freebsd.org Subject: Re: -stable hangs at boot (fwd) In-Reply-To: <199602262355.PAA15114@GndRsh.aac.dev.com> References: <199602262204.PAA01109@rocky.sri.MT.net> <199602262355.PAA15114@GndRsh.aac.dev.com> Sender: owner-stable@freebsd.org Precedence: bulk Rodney W. Grimes writes: > > > > It's not punching any hole in the code. *ALL* of the firewall products > > > > I've used (not extensive by any means) are open by default and require > > > > the user to explicitly close them. If a user mis-configures the > > > > firewall it's their problem in all of the other products, why is it now > > > > FreeBSD's problem to make the users 'smarter'? > > > > > > I've never seen a firewall product that is open by default. That is an > > > oxymoron. > > > > A firewall is *always* open by default. You determine what it is to > > firewall against. All of them haven't told me how to make policy, or > > force me to 'revert' behavior. Firewalls don't make policy, they > > enforce policy. > > It is not a firewall if it is always open, it is just a plain old router :-) It's not a configured firewall if it's wide open. ;) Let me re-phrase. All of the firewall products I've used are configured 'wide-open' by default. Now, if you leave it that way you don't have much of a firewall, but that's a configuration problem. Nate From owner-freebsd-stable Mon Feb 26 18:15:26 1996 Return-Path: owner-stable Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id SAA09549 for stable-outgoing; Mon, 26 Feb 1996 18:15:26 -0800 (PST) Received: from brasil.moneng.mei.com (brasil.moneng.mei.com [151.186.109.160]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id SAA09522 Mon, 26 Feb 1996 18:15:20 -0800 (PST) Received: (from jgreco@localhost) by brasil.moneng.mei.com (8.7.Beta.1/8.7.Beta.1) id UAA16377; Mon, 26 Feb 1996 20:14:31 -0600 From: Joe Greco Message-Id: <199602270214.UAA16377@brasil.moneng.mei.com> Subject: Re: -stable hangs at boot (fwd) To: nate@sri.MT.net (Nate Williams) Date: Mon, 26 Feb 1996 20:14:31 -0600 (CST) Cc: jgreco@brasil.moneng.mei.com, nate@sri.MT.net, phk@critter.tfs.com, stable@freebsd.org, current@freebsd.org In-Reply-To: <199602262204.PAA01109@rocky.sri.MT.net> from "Nate Williams" at Feb 26, 96 03:04:06 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-stable@freebsd.org Precedence: bulk > It's more work. But, in retrospect I could have solved the problem with > the time I spent answering email. :) Isn't that always the case though :-) > > I think we agree, but you are "solving" the problem by breaking the tool. > > We aren't breaking anything. The tool simply blocks packets based on > what you want it to do. If you want it to block *all* packets, then > tell it to. I don't want it to do anything unless I tell it to. That's > the purpose of the tool. I want the tool to enforce my policies. As a firewall, I interpret the purpose of the tool as being a policy enforcement tool. One of them is that I want to prevent ANY "bad packets" from entering my networks. That policy cannot be enforced by an IPFW implementation that periodically chooses to allow all packets through just because somebody flushed all the rules while reloading them. That policy CAN be enforced by an IPFW implementation that periodically chooses to allow NO packets through. Since the basic purpose of IPFW is to provide a tool to enforce policies, I submit that an implementation that knowingly and by design allows policies to be violated is inherently flawed and dangerous, even if the policy violations are only momentary at best. This is the way you would have the implementation work. The way I would like it implemented, this would not be a problem. > > I've never seen a firewall product that is open by default. That is an > > oxymoron. > > A firewall is *always* open by default. You determine what it is to > firewall against. All of them haven't told me how to make policy, or > force me to 'revert' behavior. Firewalls don't make policy, they > enforce policy. I disagree with that analysis of a firewall, but that is semantics, and irrelevant to this discussion. You can build your house from the ground up and wind up with your dream house. You can start with a prefab house and remodel it and wind up with your dream house. I think we agree that either method yields the desired "dream house". However, my point is that when you start from the ground up, you have to worry about the rain getting in the unfinished house and ruining the structure... you just don't have those sorts of problems when you're just remodeling. :-) THAT is what _I_ am trying to argue! Good night, ... Joe ------------------------------------------------------------------------------- Joe Greco - Systems Administrator jgreco@ns.sol.net Solaria Public Access UNIX - Milwaukee, WI 414/546-7968 From owner-freebsd-stable Mon Feb 26 20:02:15 1996 Return-Path: owner-stable Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id UAA19217 for stable-outgoing; Mon, 26 Feb 1996 20:02:15 -0800 (PST) Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id UAA19185 Mon, 26 Feb 1996 20:02:06 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.7.4/8.6.9) with SMTP id UAA10130; Mon, 26 Feb 1996 20:00:06 -0800 (PST) To: Joe Greco cc: nate@sri.MT.net (Nate Williams), phk@critter.tfs.com, stable@freebsd.org, current@freebsd.org Followup-To: security@freebsd.org Subject: Re: -stable hangs at boot (fwd) In-reply-to: Your message of "Mon, 26 Feb 1996 15:53:55 CST." <199602262153.PAA16062@brasil.moneng.mei.com> Date: Mon, 26 Feb 1996 20:00:05 -0800 Message-ID: <10128.825393605@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-stable@freebsd.org Precedence: bulk ARGH! Stop, please!! Uh. Most kindly, guys, can you perhaps take this topic to freebsd-security, where it truly and honestly belongs? This may be heretical, but I personally don't CARE about firewalls! There are enough people in the world who do care about them that I don't have to, and I rather like it that way. This thread has virtually taken over both -stable and -current, and I think that 24 messages in this thread is reasonable grounds to call for a closed discussion or, at the minimum, revectoring it to the proper place already! What kind of firewall can I install which will redirect discussions about firewalls from -current to -security, now that's something I'd like to know! :-) Jordan From owner-freebsd-stable Tue Feb 27 05:02:08 1996 Return-Path: owner-stable Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id FAA16895 for stable-outgoing; Tue, 27 Feb 1996 05:02:08 -0800 (PST) Received: from tfs.com (tfs.com [140.145.250.1]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id FAA16875 Tue, 27 Feb 1996 05:02:04 -0800 (PST) Received: from critter.tfs.com by tfs.com (smail3.1.28.1) with SMTP id m0trP1J-0003wXC; Tue, 27 Feb 96 05:00 PST Received: from localhost.tfs.com (localhost.tfs.com [127.0.0.1]) by critter.tfs.com (8.6.12/8.6.12) with SMTP id OAA13804; Tue, 27 Feb 1996 14:00:40 +0100 X-Authentication-Warning: critter.tfs.com: Host localhost.tfs.com didn't use HELO protocol To: "Rodney W. Grimes" cc: nate@sri.MT.net (Nate Williams), jgreco@brasil.moneng.mei.com, stable@freebsd.org, current@freebsd.org Subject: Re: -stable hangs at boot (fwd) In-reply-to: Your message of "Mon, 26 Feb 1996 15:55:33 PST." <199602262355.PAA15114@GndRsh.aac.dev.com> Date: Tue, 27 Feb 1996 14:00:40 +0100 Message-ID: <13802.825426040@critter.tfs.com> From: Poul-Henning Kamp Sender: owner-stable@freebsd.org Precedence: bulk > > > > It's not punching any hole in the code. *ALL* of the firewall products > > > > I've used (not extensive by any means) are open by default and require > > > > the user to explicitly close them. If a user mis-configures the > > > > firewall it's their problem in all of the other products, why is it now > > > > FreeBSD's problem to make the users 'smarter'? > > > > > > I've never seen a firewall product that is open by default. That is an > > > oxymoron. > > > > A firewall is *always* open by default. You determine what it is to > > firewall against. All of them haven't told me how to make policy, or > > force me to 'revert' behavior. Firewalls don't make policy, they > > enforce policy. > > It is not a firewall if it is always open, it is just a plain old router :-) > And per the RFC's FreeBSD can not, and does not, ship with even IP forwarding > turned on. Amen. By doing it so the default is "deny all", we solve a couple of nasty corner cases: 1. You can "ipfw flush" and then add your rules, without leaving the door open in the meantime. 2. If you get your rules wrong you wont by accident leave some crap through. 3. It is clearly visible for the user what will happen if nothing is explicitly defined before. 4. Statistics are gathered on this policy rule, just like for the rest of the rules, so you can see if they do what you want. -- Poul-Henning Kamp | phk@FreeBSD.ORG FreeBSD Core-team. http://www.freebsd.org/~phk | phk@login.dknet.dk Private mailbox. whois: [PHK] | phk@ref.tfs.com TRW Financial Systems, Inc. Future will arrive by its own means, progress not so. From owner-freebsd-stable Tue Feb 27 10:39:15 1996 Return-Path: owner-stable Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id KAA11161 for stable-outgoing; Tue, 27 Feb 1996 10:39:15 -0800 (PST) Received: (from jmb@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id KAA11155 for freebsd-stable; Tue, 27 Feb 1996 10:39:14 -0800 (PST) From: "Jonathan M. Bresler" Message-Id: <199602271839.KAA11155@freefall.freebsd.org> Subject: ipfw comments To: freebsd-stable Date: Tue, 27 Feb 1996 10:39:14 -0800 (PST) X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-stable@FreeBSD.ORG Precedence: bulk i want to able to filter on both incoming and outgoing interfaces. if0 is accounting if1 is engineering if2 is marketing no traffic from marketing to engineering allow traffic from engineering to marketing allow traffic from marketing to accounting allow traffic from accounting to marketing allow traffic from accounting to engineering allow traffic from engineering to marketing this can be done using ip addresses (or ranges) but specifying interfaces is easier, and i wont let me forget any (sub)nets it does not seems to be possible to filter on both interfaces from the strawman. this may be a real bear to implement in the kernel only after the route is chosen can the rule be applied. the packet has to carry around information regarding which interface it arrived on. (ugh.) warning the following may be just "persnickitiness" on my part. actions: it is implied that all actions are mutually exclusive. "count" could be combined with any of the other actions. should state mall actions are mutually exclusive. count action: strawman says "counters are updated, but the rule doesnt match the packet, and the next rule is tried." man page says "update counters for all packets that match rule. The search continues with the next rule." this confuses me. i guess that "but the rule doesnt match" means that "count" is never the last rule applied. "rules are applied in numerical order until one of them matches the packet" implying that once a match occurs ipfw applies the actions specified in that rule and stops processing that packet. we dont want "count" to be a terminal rule, so it must not match, ever. this exception is needed because "count" cant be combined with any other action. should ipfw be changed to allow "count" to combine with any other action? we would then need a "continue" action to let us count all packets of a general type, some of which we will later drop, others we will accept. on the external interface: i want to count all inbound nnrp (but continue processing rules) i want to accept and count inbound nnrp from allowed news readers i want to drop, cound and log all other nnrp packets should should "count" be a modifier like "syslog"? not an action like "accept". -- Jonathan M. Bresler FreeBSD Postmaster jmb@FreeBSD.ORG FreeBSD--4.4BSD Unix for PC clones, source included. http://www.freebsd.org/ From owner-freebsd-stable Wed Feb 28 11:06:23 1996 Return-Path: owner-stable Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id LAA02800 for stable-outgoing; Wed, 28 Feb 1996 11:06:23 -0800 (PST) Received: from alpha.xerox.com (alpha.Xerox.COM [13.1.64.93]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id LAA02793 Wed, 28 Feb 1996 11:06:21 -0800 (PST) Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <16022(2)>; Wed, 28 Feb 1996 11:05:39 PST Received: from localhost ([127.0.0.1]) by crevenia.parc.xerox.com with SMTP id <177480>; Wed, 28 Feb 1996 11:05:30 -0800 X-Mailer: exmh version 1.6.4 10/10/95 To: Nate Williams cc: Poul-Henning Kamp , stable@freebsd.org, current@freebsd.org Subject: Re: IPFW (was: Re: -stable hangs at boot) In-reply-to: Your message of "Mon, 26 Feb 1996 11:26:22 PST." <199602261926.MAA00360@rocky.sri.MT.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 28 Feb 1996 11:05:24 PST From: Bill Fenner Message-Id: <96Feb28.110530pst.177480@crevenia.parc.xerox.com> Sender: owner-stable@freebsd.org Precedence: bulk In message <199602261926.MAA00360@rocky.sri.MT.net> Nate wrote: >I'm not sure I could >see the need for filtering differently for incoming vs. outgoing (except >in the case of syn. packets). You can prevent many IP spoofing attacks by disallowing packets with IP source addresses that match your internal network addresses from coming in your external connection (e.g. Xerox does access-list N deny 13.0.0.0 0.255.255.255 any on its incoming interface on the Cisco) >That reminds me. I haven't looked yet, but does the new code also >filter out routing information? The old code didn't (and other firewall >code I have used does). Sorry, this doesn't make much sense to me -- shouldn't "filtering routing information" just be another firewall rule? Seems like policy to me. Bill From owner-freebsd-stable Wed Feb 28 11:08:05 1996 Return-Path: owner-stable Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id LAA02981 for stable-outgoing; Wed, 28 Feb 1996 11:08:05 -0800 (PST) Received: from rocky.sri.MT.net (rocky.sri.MT.net [204.182.243.10]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id LAA02881 Wed, 28 Feb 1996 11:07:57 -0800 (PST) Received: (from nate@localhost) by rocky.sri.MT.net (8.6.12/8.6.12) id MAA08395; Wed, 28 Feb 1996 12:10:42 -0700 Date: Wed, 28 Feb 1996 12:10:42 -0700 From: Nate Williams Message-Id: <199602281910.MAA08395@rocky.sri.MT.net> To: Bill Fenner Cc: Nate Williams , Poul-Henning Kamp , stable@freebsd.org, current@freebsd.org Subject: Re: IPFW (was: Re: -stable hangs at boot) In-Reply-To: <96Feb28.110530pst.177480@crevenia.parc.xerox.com> References: <199602261926.MAA00360@rocky.sri.MT.net> <96Feb28.110530pst.177480@crevenia.parc.xerox.com> Sender: owner-stable@freebsd.org Precedence: bulk > >That reminds me. I haven't looked yet, but does the new code also > >filter out routing information? The old code didn't (and other firewall > >code I have used does). > > Sorry, this doesn't make much sense to me -- shouldn't "filtering routing > information" just be another firewall rule? Seems like policy to me. The routing code didn't go through the firewall code in the previous implementation, so there was no way for it to filter out routing information. Nate From owner-freebsd-stable Wed Feb 28 11:11:25 1996 Return-Path: owner-stable Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id LAA03267 for stable-outgoing; Wed, 28 Feb 1996 11:11:25 -0800 (PST) Received: from rocky.sri.MT.net (rocky.sri.MT.net [204.182.243.10]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id LAA03235 Wed, 28 Feb 1996 11:10:48 -0800 (PST) Received: (from nate@localhost) by rocky.sri.MT.net (8.6.12/8.6.12) id MAA08403; Wed, 28 Feb 1996 12:13:34 -0700 Date: Wed, 28 Feb 1996 12:13:34 -0700 From: Nate Williams Message-Id: <199602281913.MAA08403@rocky.sri.MT.net> To: Nate Williams Cc: Bill Fenner , stable@freebsd.org, current@freebsd.org Subject: Re: IPFW (was: Re: -stable hangs at boot) In-Reply-To: <199602281910.MAA08395@rocky.sri.MT.net> References: <199602261926.MAA00360@rocky.sri.MT.net> <96Feb28.110530pst.177480@crevenia.parc.xerox.com> <199602281910.MAA08395@rocky.sri.MT.net> Sender: owner-stable@freebsd.org Precedence: bulk Nate Williams writes: > > >That reminds me. I haven't looked yet, but does the new code also > > >filter out routing information? The old code didn't (and other firewall > > >code I have used does). > > > > Sorry, this doesn't make much sense to me -- shouldn't "filtering routing > > information" just be another firewall rule? Seems like policy to me. > > The routing code didn't go through the firewall code in the previous > implementation, so there was no way for it to filter out routing > information. Man, I think I'm going to crawl into a hole today. I can't communicate at all effectively. What that should have said is: Routing packets didn't pass through the firewall code previously, so there was no way to filter it out. Sorry, Nate From owner-freebsd-stable Wed Feb 28 11:15:30 1996 Return-Path: owner-stable Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id LAA03621 for stable-outgoing; Wed, 28 Feb 1996 11:15:30 -0800 (PST) Received: from alpha.xerox.com (alpha.Xerox.COM [13.1.64.93]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id LAA03616 Wed, 28 Feb 1996 11:15:27 -0800 (PST) Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <16153(2)>; Wed, 28 Feb 1996 11:14:39 PST Received: from localhost ([127.0.0.1]) by crevenia.parc.xerox.com with SMTP id <177480>; Wed, 28 Feb 1996 11:14:37 -0800 X-Mailer: exmh version 1.6.4 10/10/95 To: Joe Greco cc: phk@critter.tfs.com (Poul-Henning Kamp), stable@freebsd.org, current@freebsd.org Subject: Re: -stable hangs at boot (fwd) In-reply-to: Your message of "Mon, 26 Feb 1996 13:17:53 PST." <199602262117.PAA15987@brasil.moneng.mei.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 28 Feb 1996 11:14:21 PST From: Bill Fenner Message-Id: <96Feb28.111437pst.177480@crevenia.parc.xerox.com> Sender: owner-stable@freebsd.org Precedence: bulk In message <199602262117.PAA15987@brasil.moneng.mei.com>you write: >Yes, I can imagine :-) I just want my firewalls to do something mildly >more social - like return a HOST_UNREACHABLE How about "Communication Administratively Prohibited" (code 13, see RFC1812 section 5.3.9) Bill From owner-freebsd-stable Wed Feb 28 11:40:57 1996 Return-Path: owner-stable Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id LAA05941 for stable-outgoing; Wed, 28 Feb 1996 11:40:57 -0800 (PST) Received: from brasil.moneng.mei.com (brasil.moneng.mei.com [151.186.109.160]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id LAA05910 Wed, 28 Feb 1996 11:40:50 -0800 (PST) Received: (from jgreco@localhost) by brasil.moneng.mei.com (8.7.Beta.1/8.7.Beta.1) id NAA03192; Wed, 28 Feb 1996 13:39:56 -0600 From: Joe Greco Message-Id: <199602281939.NAA03192@brasil.moneng.mei.com> Subject: Re: -stable hangs at boot (fwd) To: fenner@parc.xerox.com (Bill Fenner) Date: Wed, 28 Feb 1996 13:39:55 -0600 (CST) Cc: jgreco@brasil.moneng.mei.com, phk@critter.tfs.com, stable@freebsd.org, current@freebsd.org In-Reply-To: <96Feb28.111437pst.177480@crevenia.parc.xerox.com> from "Bill Fenner" at Feb 28, 96 11:14:21 am X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-stable@freebsd.org Precedence: bulk > In message <199602262117.PAA15987@brasil.moneng.mei.com>you write: > >Yes, I can imagine :-) I just want my firewalls to do something mildly > >more social - like return a HOST_UNREACHABLE > > How about "Communication Administratively Prohibited" (code 13, see RFC1812 > section 5.3.9) > > Bill The hell if I care :-) My only concern would be making sure the right thing happened. ... JG From owner-freebsd-stable Wed Feb 28 14:07:52 1996 Return-Path: owner-stable Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id OAA18946 for stable-outgoing; Wed, 28 Feb 1996 14:07:52 -0800 (PST) Received: from brasil.moneng.mei.com (brasil.moneng.mei.com [151.186.109.160]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id OAA18909 Wed, 28 Feb 1996 14:07:41 -0800 (PST) Received: (from jgreco@localhost) by brasil.moneng.mei.com (8.7.Beta.1/8.7.Beta.1) id QAA03415; Wed, 28 Feb 1996 16:05:27 -0600 From: Joe Greco Message-Id: <199602282205.QAA03415@brasil.moneng.mei.com> Subject: Re: IPFW (was: Re: -stable hangs at boot) To: fenner@parc.xerox.com (Bill Fenner) Date: Wed, 28 Feb 1996 16:05:26 -0600 (CST) Cc: nate@sri.MT.net, phk@critter.tfs.com, stable@freebsd.org, current@freebsd.org In-Reply-To: <96Feb28.110530pst.177480@crevenia.parc.xerox.com> from "Bill Fenner" at Feb 28, 96 11:05:24 am X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-stable@freebsd.org Precedence: bulk > In message <199602261926.MAA00360@rocky.sri.MT.net> Nate wrote: > >I'm not sure I could > >see the need for filtering differently for incoming vs. outgoing (except > >in the case of syn. packets). > > You can prevent many IP spoofing attacks by disallowing packets with IP source > addresses that match your internal network addresses from coming in your > external connection (e.g. Xerox does > > access-list N deny 13.0.0.0 0.255.255.255 any > > on its incoming interface on the Cisco) Technically, one might want to place it's much-less-often-considered brother in the firewall too... the one that prevents OUTgoing packets that do NOT have a 13.0.0.0 address... (no I don't do this either but I should). ... JG From owner-freebsd-stable Thu Feb 29 00:55:00 1996 Return-Path: owner-stable Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id AAA23134 for stable-outgoing; Thu, 29 Feb 1996 00:55:00 -0800 (PST) Received: from tfs.com (tfs.com [140.145.250.1]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id AAA23127 Thu, 29 Feb 1996 00:54:57 -0800 (PST) Received: from critter.tfs.com by tfs.com (smail3.1.28.1) with SMTP id m0ts47H-0003vmC; Thu, 29 Feb 96 00:53 PST Received: from localhost.tfs.com (localhost.tfs.com [127.0.0.1]) by critter.tfs.com (8.6.12/8.6.12) with SMTP id JAA02614; Thu, 29 Feb 1996 09:53:35 +0100 X-Authentication-Warning: critter.tfs.com: Host localhost.tfs.com didn't use HELO protocol To: Joe Greco cc: fenner@parc.xerox.com (Bill Fenner), nate@sri.MT.net, stable@FreeBSD.ORG, current@FreeBSD.ORG Subject: Re: IPFW (was: Re: -stable hangs at boot) In-reply-to: Your message of "Wed, 28 Feb 1996 16:05:26 CST." <199602282205.QAA03415@brasil.moneng.mei.com> Date: Thu, 29 Feb 1996 09:53:35 +0100 Message-ID: <2612.825584015@critter.tfs.com> From: Poul-Henning Kamp Sender: owner-stable@FreeBSD.ORG Precedence: bulk > > In message <199602261926.MAA00360@rocky.sri.MT.net> Nate wrote: > > >I'm not sure I could > > >see the need for filtering differently for incoming vs. outgoing (except > > >in the case of syn. packets). > > > > You can prevent many IP spoofing attacks by disallowing packets with IP sou rce > > addresses that match your internal network addresses from coming in your > > external connection (e.g. Xerox does > > > > access-list N deny 13.0.0.0 0.255.255.255 any > > > > on its incoming interface on the Cisco) > > Technically, one might want to place it's much-less-often-considered brother > in the firewall too... the one that prevents OUTgoing packets that do NOT > have a 13.0.0.0 address... > > (no I don't do this either but I should). And if you're on a lousy ISP, also a filter to block all of the "private" networks, 192.168.x.x and so on, (RFC 1596 ?) -- Poul-Henning Kamp | phk@FreeBSD.ORG FreeBSD Core-team. http://www.freebsd.org/~phk | phk@login.dknet.dk Private mailbox. whois: [PHK] | phk@ref.tfs.com TRW Financial Systems, Inc. Future will arrive by its own means, progress not so. From owner-freebsd-stable Thu Feb 29 09:09:15 1996 Return-Path: owner-stable Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id JAA23169 for stable-outgoing; Thu, 29 Feb 1996 09:09:15 -0800 (PST) Received: from precipice.shockwave.com (precipice.shockwave.com [171.69.108.33]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id JAA23145 Thu, 29 Feb 1996 09:09:08 -0800 (PST) Received: from localhost.shockwave.com (localhost.shockwave.com [127.0.0.1]) by precipice.shockwave.com (8.7.4/8.7.3) with SMTP id JAA05845; Thu, 29 Feb 1996 09:07:06 -0800 (PST) Message-Id: <199602291707.JAA05845@precipice.shockwave.com> To: Poul-Henning Kamp cc: Joe Greco , fenner@parc.xerox.com (Bill Fenner), nate@sri.MT.net, stable@FreeBSD.ORG, current@FreeBSD.ORG Subject: Re: IPFW (was: Re: -stable hangs at boot) In-reply-to: Your message of "Thu, 29 Feb 1996 09:53:35 +0100." <2612.825584015@critter.tfs.com> Date: Thu, 29 Feb 1996 09:07:06 -0800 From: Paul Traina Sender: owner-stable@FreeBSD.ORG Precedence: bulk On sites that I run, my filter rules -start- with: deny any deny any deny 127.0.0.0 0.255.255.255 any deny 0.0.0.0 0.255.255.255 any deny <1597 nets> any The idea is that you want to block off all source addresses that you should never expect to see. 127 is a favorite of mine, because a lot of people have localhost in their hosts.equiv files. Paul From owner-freebsd-stable Thu Feb 29 09:32:58 1996 Return-Path: owner-stable Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id JAA24686 for stable-outgoing; Thu, 29 Feb 1996 09:32:58 -0800 (PST) Received: from brasil.moneng.mei.com (brasil.moneng.mei.com [151.186.109.160]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id JAA24669 Thu, 29 Feb 1996 09:32:41 -0800 (PST) Received: (from jgreco@localhost) by brasil.moneng.mei.com (8.7.Beta.1/8.7.Beta.1) id LAA04770; Thu, 29 Feb 1996 11:31:53 -0600 From: Joe Greco Message-Id: <199602291731.LAA04770@brasil.moneng.mei.com> Subject: Re: IPFW (was: Re: -stable hangs at boot) To: phk@critter.tfs.com (Poul-Henning Kamp) Date: Thu, 29 Feb 1996 11:31:52 -0600 (CST) Cc: stable@freebsd.org, current@freebsd.org In-Reply-To: <2612.825584015@critter.tfs.com> from "Poul-Henning Kamp" at Feb 29, 96 09:53:35 am X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-stable@freebsd.org Precedence: bulk > > Technically, one might want to place it's much-less-often-considered brother > > in the firewall too... the one that prevents OUTgoing packets that do NOT > > have a 13.0.0.0 address... > > > > (no I don't do this either but I should). > > And if you're on a lousy ISP, also a filter to block all of the "private" > networks, 192.168.x.x and so on, (RFC 1596 ?) RFC1597: 10.0.0.0 - 10.255.255.255 172.16.0.0 - 172.31.255.255 192.168.0.0 - 192.168.255.255 That's a real good point, actually. Also 127.*, I would think... (actually, some non-lousy ISP's assign space out of this address range as it serves as a very "gross" firewall. And even if you don't, your customers might use it as described in 1597 and have a misconfigured router that doesn't prevent outbound packets. This implies you want to stop traffic in BOTH directions). Gosh, this gets complex quickly :-) ... Joe ------------------------------------------------------------------------------- Joe Greco - Systems Administrator jgreco@ns.sol.net Solaria Public Access UNIX - Milwaukee, WI 414/546-7968 From owner-freebsd-stable Thu Feb 29 09:55:18 1996 Return-Path: owner-stable Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id JAA25662 for stable-outgoing; Thu, 29 Feb 1996 09:55:18 -0800 (PST) Received: from ix13.ix.netcom.com (ix13.ix.netcom.com [199.182.120.13]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id JAA25657 for ; Thu, 29 Feb 1996 09:55:16 -0800 (PST) Received: from by ix13.ix.netcom.com (8.6.12/SMI-4.1/Netcom) id JAA23185; Thu, 29 Feb 1996 09:54:40 -0800 Date: Thu, 29 Feb 1996 09:54:40 -0800 Message-Id: <199602291754.JAA23185@ix13.ix.netcom.com> From: wlchen@ix.netcom.com (Wen-lung Chen ) Subject: Virtual Host?? To: stable@FreeBSD.ORG Sender: owner-stable@FreeBSD.ORG Precedence: bulk Hi, I am new in this FreeBSD society. I would appreciate if anybody here can help me solve this problem. I am trying to setup Virtual Host with FreeBSD, can anybody tell me how to do that? Thanks a lot. Lon From owner-freebsd-stable Thu Feb 29 12:17:46 1996 Return-Path: owner-stable Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id MAA04344 for stable-outgoing; Thu, 29 Feb 1996 12:17:46 -0800 (PST) Received: from brasil.moneng.mei.com (brasil.moneng.mei.com [151.186.109.160]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id MAA04305 Thu, 29 Feb 1996 12:17:35 -0800 (PST) Received: (from jgreco@localhost) by brasil.moneng.mei.com (8.7.Beta.1/8.7.Beta.1) id OAA06433; Thu, 29 Feb 1996 14:16:15 -0600 From: Joe Greco Message-Id: <199602292016.OAA06433@brasil.moneng.mei.com> Subject: Re: IPFW (was: Re: -stable hangs at boot) To: phk@critter.tfs.com (Poul-Henning Kamp) Date: Thu, 29 Feb 1996 14:16:15 -0600 (CST) Cc: jgreco@brasil.moneng.mei.com, fenner@parc.xerox.com, nate@sri.MT.net, stable@freebsd.org, current@freebsd.org In-Reply-To: <2612.825584015@critter.tfs.com> from "Poul-Henning Kamp" at Feb 29, 96 09:53:35 am X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-stable@freebsd.org Precedence: bulk > > Technically, one might want to place it's much-less-often-considered brother > > in the firewall too... the one that prevents OUTgoing packets that do NOT > > have a 13.0.0.0 address... > > > > (no I don't do this either but I should). > > And if you're on a lousy ISP, also a filter to block all of the "private" > networks, 192.168.x.x and so on, (RFC 1596 ?) Okay, firewall debaters. Here's what I've done on gateway.inr.sol.net. 204.95.219.1 is the local address of my T1 interface. 206.55.64.17 is the address of the router on my backbone Ethernet. Commentary in curly braces. #! /bin/sh - PATH=/sbin; export PATH ipfw f echo "Installing Firewall" # # ----- IP Bad Address Prevention Section ----- # { Packets from these addresses should never be coming in } # Block RFC1597 "Private Internets" (inbound) ipfw addf deny all from 10.0.0.0/8 to 0/0 via 204.95.219.1 ipfw addf deny all from 172.16.0.0/16 to 0/0 via 204.95.219.1 ipfw addf deny all from 192.168.0.0/16 to 0/0 via 204.95.219.1 # Block other "Shouldn't Exist" Internets (inbound) ipfw addf deny all from 127.0.0.0/8 to 0/0 via 204.95.219.1 ipfw addf deny all from 0.0.0.0/8 to 0/0 via 204.95.219.1 # { Likewise, we should never allow packets with these addresses } # { as source or destination to go out onto the Big Net } # Block RFC1597 "Private Internets" as Source Address (outbound) ipfw addf deny all from 10.0.0.0/8 to 0/0 via 206.55.64.17 ipfw addf deny all from 172.16.0.0/16 to 0/0 via 206.55.64.17 ipfw addf deny all from 192.168.0.0/16 to 0/0 via 206.55.64.17 # Block RFC1597 "Private Internets" as Destination Address (outbound) ipfw addf deny all from 0/0 to 10.0.0.0/8 via 206.55.64.17 ipfw addf deny all from 0/0 to 172.16.0.0/16 via 206.55.64.17 ipfw addf deny all from 0/0 to 192.168.0.0/16 via 206.55.64.17 # Block other "Shouldn't Exist" Internets as Source Address (outbound) ipfw addf deny all from 0/0 to 127.0.0.0/8 via 206.55.64.17 ipfw addf deny all from 0/0 to 0.0.0.0/8 via 206.55.64.17 # Block other "Shouldn't Exist" Internets as Destination Address (outbound) ipfw addf deny all from 127.0.0.0/8 to 0/0 via 206.55.64.17 ipfw addf deny all from 0.0.0.0/8 to 0/0 via 206.55.64.17 # # ----- IP Spoofing Prevention Section ----- # { Prevent packets that claim to have source addresses on our networks } # { from entering from outside our networks } # Block SOLNET-BLK-1 (inbound) ipfw addf deny all from 206.55.64.0/20 to 0/0 via 204.95.219.1 # Block INCNET-172 (inbound) ipfw addf deny all from 204.95.172.0/24 to 0/0 via 204.95.219.1 # Block INCNET-219 (inbound) ipfw addf deny all from 204.95.219.0/24 to 0/0 via 204.95.219.1 # { Now do something funny. Block *every* outbound source address and } # { then re-allow JUST those that could potentially be generated on our } # { networks. Yes this means that the above checks for "Private } # { Internets" as Source Address checks are not strictly necessary. } # # Disallow all Source Addresses (outbound) ipfw addf deny all from 0/0 to 0/0 via 206.55.64.17 # Allow SOLNET-BLK-1 (outbound) ipfw addf accept all from 206.55.64.0/20 to 0/0 via 206.55.64.17 # Allow INCNET-172 (outbound) ipfw addf accept all from 204.95.172.0/24 to 0/0 via 206.55.64.17 # Allow INCNET-219 (outbound) ipfw addf accept all from 204.95.219.0/24 to 0/0 via 206.55.64.17 What have I forgotten, if anything? :-) ... Joe ------------------------------------------------------------------------------- Joe Greco - Systems Administrator jgreco@ns.sol.net Solaria Public Access UNIX - Milwaukee, WI 414/546-7968 From owner-freebsd-stable Thu Feb 29 12:40:24 1996 Return-Path: owner-stable Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id MAA05874 for stable-outgoing; Thu, 29 Feb 1996 12:40:24 -0800 (PST) Received: from precipice.shockwave.com (precipice.shockwave.com [171.69.108.33]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id MAA05853 Thu, 29 Feb 1996 12:40:13 -0800 (PST) Received: from localhost.shockwave.com (localhost.shockwave.com [127.0.0.1]) by precipice.shockwave.com (8.7.4/8.7.3) with SMTP id MAA00408; Thu, 29 Feb 1996 12:38:13 -0800 (PST) Message-Id: <199602292038.MAA00408@precipice.shockwave.com> X-Mailer: exmh version 1.6.5 12/11/95 To: Joe Greco cc: phk@critter.tfs.com (Poul-Henning Kamp), stable@freebsd.org, current@freebsd.org Subject: Re: IPFW (was: Re: -stable hangs at boot) In-reply-to: Your message of "Thu, 29 Feb 1996 11:31:52 CST." <199602291731.LAA04770@brasil.moneng.mei.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 29 Feb 1996 12:38:13 -0800 From: Paul Traina Sender: owner-stable@freebsd.org Precedence: bulk Obligatory comment: 1597 space should *NEVER* be considered "more secure." The only difference between 1597 space and non-1597 space is that 1597 space is not guaranteed to be unique across the internet. I can still get my packets through to (and often received from) a 1597 based machine. From owner-freebsd-stable Thu Feb 29 12:51:27 1996 Return-Path: owner-stable Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id MAA06992 for stable-outgoing; Thu, 29 Feb 1996 12:51:27 -0800 (PST) Received: from brasil.moneng.mei.com (brasil.moneng.mei.com [151.186.109.160]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id MAA06967 Thu, 29 Feb 1996 12:51:22 -0800 (PST) Received: (from jgreco@localhost) by brasil.moneng.mei.com (8.7.Beta.1/8.7.Beta.1) id OAA06496; Thu, 29 Feb 1996 14:50:08 -0600 From: Joe Greco Message-Id: <199602292050.OAA06496@brasil.moneng.mei.com> Subject: Re: IPFW (was: Re: -stable hangs at boot) To: pst@shockwave.com (Paul Traina) Date: Thu, 29 Feb 1996 14:50:07 -0600 (CST) Cc: jgreco@brasil.moneng.mei.com, phk@critter.tfs.com, stable@freebsd.org, current@freebsd.org In-Reply-To: <199602292038.MAA00408@precipice.shockwave.com> from "Paul Traina" at Feb 29, 96 12:38:13 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-stable@freebsd.org Precedence: bulk > Obligatory comment: > > 1597 space should *NEVER* be considered "more secure." > > The only difference between 1597 space and non-1597 space is that 1597 space > is not guaranteed to be unique across the internet. > > I can still get my packets through to (and often received from) a 1597 based > machine. Of course that is true. However, it IS inherently more difficult for you to get a packet routed to a 1597 network that is local, here, because there aren't any routes to help you, and in my opinion that does count as being "more secure". I am BY NO MEANS advocating the use of 1597 networks instead of firewalls and other traditional security tools. Paranoia and politics simply suggests that a 1597 network is yet another tool that helps keep trouble away. ... Joe ------------------------------------------------------------------------------- Joe Greco - Systems Administrator jgreco@ns.sol.net Solaria Public Access UNIX - Milwaukee, WI 414/546-7968 From owner-freebsd-stable Thu Feb 29 15:07:12 1996 Return-Path: owner-stable Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id PAA17106 for stable-outgoing; Thu, 29 Feb 1996 15:07:12 -0800 (PST) Received: from nervosa.com (root@[192.187.228.86]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id PAA17087 for ; Thu, 29 Feb 1996 15:07:06 -0800 (PST) Received: from nervosa.com (coredump@onyx.nervosa.com [10.0.0.1]) by nervosa.com (8.7.4/nervosa.com.2) with SMTP id PAA26650; Thu, 29 Feb 1996 15:07:02 -0800 (PST) Date: Thu, 29 Feb 1996 15:07:01 -0800 (PST) From: invalid opcode To: Wen-lung Chen cc: stable@FreeBSD.ORG Subject: Re: Virtual Host?? In-Reply-To: <199602291754.JAA23185@ix13.ix.netcom.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-stable@FreeBSD.ORG Precedence: bulk On Thu, 29 Feb 1996, Wen-lung Chen wrote: > I am trying to setup Virtual Host with FreeBSD, can anybody tell me how > to do that? Thanks a lot. man ifconfig, look at the alias option. == Chris Layne ============================================================= == coredump@nervosa.com ================ http://www.nervosa.com/~coredump == From owner-freebsd-stable Thu Feb 29 23:40:36 1996 Return-Path: owner-stable Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id XAA22906 for stable-outgoing; Thu, 29 Feb 1996 23:40:36 -0800 (PST) Received: from mailhub.aros.net (mailhub.aros.net [205.164.111.17]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id XAA22901 for ; Thu, 29 Feb 1996 23:40:34 -0800 (PST) Received: from terra.aros.net (terra.aros.net [205.164.111.10]) by mailhub.aros.net (8.6.12/Unknown) with ESMTP id AAA19878 for ; Fri, 1 Mar 1996 00:42:43 -0700 Received: (from angio@localhost) by terra.aros.net (8.6.12/8.6.12) id AAA20383 for freebsd-stable@freebsd.org; Fri, 1 Mar 1996 00:40:32 -0700 From: Dave Andersen Message-Id: <199603010740.AAA20383@terra.aros.net> Subject: 'no more processes' To: freebsd-stable@freebsd.org Date: Fri, 1 Mar 1996 00:40:31 -0700 (MST) X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-stable@freebsd.org Precedence: bulk I did a recent 'make most', and I'm getting some neat error messages. When I spawn a new shell (I use tcsh), it tries to execute a program in my .login, and gives me a 'no more processes' error. I'm well below the 40 process limit, and maxusers is set to 45 or so.. Have I goofed something up somewhere, or did I just miss an announcement on this list? The last make world I did was two ctm updates ago.. *shrugs* (Oh - stupid question, also. How to do a 'make' that'll make & install only that which has been updated?) -Dave -- angio@aros.net Complete virtual hosting and business-oriented system administration Internet services. (WWW, FTP, email) http://www.aros.net/ http://www.aros.net/about/virtual/ "There are only two industries that refer to thier customers as 'users'." From owner-freebsd-stable Fri Mar 1 00:36:42 1996 Return-Path: owner-stable Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id AAA25491 for stable-outgoing; Fri, 1 Mar 1996 00:36:42 -0800 (PST) Received: from mailhub.aros.net (mailhub.aros.net [205.164.111.17]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id AAA25486 for ; Fri, 1 Mar 1996 00:36:39 -0800 (PST) Received: from terra.aros.net (terra.aros.net [205.164.111.10]) by mailhub.aros.net (8.6.12/Unknown) with ESMTP id BAA20031 for ; Fri, 1 Mar 1996 01:38:43 -0700 Received: (from angio@localhost) by terra.aros.net (8.6.12/8.6.12) id BAA23200 for freebsd-stable@freebsd.org; Fri, 1 Mar 1996 01:36:31 -0700 From: Dave Andersen Message-Id: <199603010836.BAA23200@terra.aros.net> Subject: 'no more processes' To: freebsd-stable@freebsd.org Date: Fri, 1 Mar 1996 01:36:30 -0700 (MST) X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-stable@freebsd.org Precedence: bulk Disregard the last mail. The message was caused by me having a command in my .cshrc (yes, it does belong in my .login. long story. :-) that wasn't executable on this particular machine. The file on the "broken" machine was an empty file that was marked executable. It's also interesting to note that if I invoke this script, it reports back the last reported error message it gave me before I invoked it. I would presume that it goes in to some kind of loop when it encounters the not-quite-usable file, because the only time csh exits with ERR_NOPROC is, well, when it actually can't fork. Is this a well-known error that I just stumbled on? And if so, someone feel like explaining it? It's a bit odd. I can't reproduce it on -release, but I don't have another -stable system around on which to test it (and my -current machine is .. ahh, in a bad state. :-) -Dave Andersen -- angio@aros.net Complete virtual hosting and business-oriented system administration Internet services. (WWW, FTP, email) http://www.aros.net/ http://www.aros.net/about/virtual/ "There are only two industries that refer to thier customers as 'users'." From owner-freebsd-stable Fri Mar 1 05:36:53 1996 Return-Path: owner-stable Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id FAA11187 for stable-outgoing; Fri, 1 Mar 1996 05:36:53 -0800 (PST) Received: from ibp.ibp.fr (ibp.ibp.fr [132.227.60.30]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id FAA11179 Fri, 1 Mar 1996 05:36:30 -0800 (PST) Received: from blaise.ibp.fr (blaise.ibp.fr [132.227.60.1]) by ibp.ibp.fr (8.6.12/jtpda-5.0) with ESMTP id OAA14542 ; Fri, 1 Mar 1996 14:35:43 +0100 Received: from (uucp@localhost) by blaise.ibp.fr (8.6.12/jtpda-5.0) with UUCP id OAA21683 ; Fri, 1 Mar 1996 14:35:42 +0100 Received: (from roberto@localhost) by keltia.freenix.fr (8.7.3/keltia-uucp-2.7) id NAA11058; Fri, 1 Mar 1996 13:14:36 +0100 (MET) From: Ollivier Robert Message-Id: <199603011214.NAA11058@keltia.freenix.fr> Subject: Re: IPFW (was: Re: -stable hangs at boot) To: phk@critter.tfs.com (Poul-Henning Kamp) Date: Fri, 1 Mar 1996 13:14:36 +0100 (MET) Cc: jgreco@brasil.moneng.mei.com, fenner@parc.xerox.com, nate@sri.MT.net, stable@freebsd.org, current@freebsd.org In-Reply-To: <2612.825584015@critter.tfs.com> from Poul-Henning Kamp at "Feb 29, 96 09:53:35 am" X-Operating-System: FreeBSD 2.2-CURRENT ctm#1688 X-Mailer: ELM [version 2.4ME+ PL10 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-stable@freebsd.org Precedence: bulk It seems that Poul-Henning Kamp said: > And if you're on a lousy ISP, also a filter to block all of the "private" > networks, 192.168.x.x and so on, (RFC 1596 ?) It is RFC-1918 now. It supersedes both 1597 and 1620. -- Ollivier ROBERT -=- The daemon is FREE! -=- roberto@keltia.frmug.fr.net FreeBSD keltia.freenix.fr 2.2-CURRENT #1: Tue Feb 20 01:16:51 MET 1996 From owner-freebsd-stable Fri Mar 1 07:38:52 1996 Return-Path: owner-stable Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id HAA20842 for stable-outgoing; Fri, 1 Mar 1996 07:38:52 -0800 (PST) Received: from rocky.sri.MT.net (rocky.sri.MT.net [204.182.243.10]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id HAA20837 for ; Fri, 1 Mar 1996 07:38:48 -0800 (PST) Received: (from nate@localhost) by rocky.sri.MT.net (8.6.12/8.6.12) id IAA14808; Fri, 1 Mar 1996 08:40:41 -0700 Date: Fri, 1 Mar 1996 08:40:41 -0700 From: Nate Williams Message-Id: <199603011540.IAA14808@rocky.sri.MT.net> To: Dave Andersen Cc: freebsd-stable@freebsd.org Subject: Re: 'no more processes' In-Reply-To: <199603010740.AAA20383@terra.aros.net> References: <199603010740.AAA20383@terra.aros.net> Sender: owner-stable@freebsd.org Precedence: bulk > I did a recent 'make most', and I'm getting some neat error messages. > When I spawn a new shell (I use tcsh), it tries to execute a program in > my .login, and gives me a 'no more processes' error. I'm well below the > 40 process limit, and maxusers is set to 45 or so.. Try doing an 'unlimit' and trying again. You still might be running into the upper limit for some strange reason. > (Oh - stupid question, also. How to do a 'make' that'll make & > install only that which has been updated?) Do a make depend now, and next time it will only compile those files which have changed (theoretically anyway). Most of the time that works, as long as the dependencies are file related. ;) Nate From owner-freebsd-stable Fri Mar 1 12:25:12 1996 Return-Path: owner-stable Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id MAA06704 for stable-outgoing; Fri, 1 Mar 1996 12:25:12 -0800 (PST) Received: from lackowa.pap.waw.pl (lackowa.pap.waw.pl [194.92.35.33]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id MAA06699 for ; Fri, 1 Mar 1996 12:25:07 -0800 (PST) Received: from cergowa.waw.pl (cergowa [194.92.35.52]) by lackowa.pap.waw.pl (8.6.9/8.6.9) with ESMTP id VAA14246 for ; Fri, 1 Mar 1996 21:20:22 +0100 Received: by cergowa.waw.pl (SMI-8.6/SMI-SVR4) id VAA16628; Fri, 1 Mar 1996 21:21:02 +0100 From: jarekb@pap.waw.pl (Jaroslaw Bazydlo) Message-Id: <199603012021.VAA16628@cergowa.waw.pl> Subject: Ghhhhh weirdness after supping -stable, am I wrong ? To: freebsd-stable@freebsd.org Date: Fri, 1 Mar 1996 21:21:01 +0100 (MET) X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-stable@freebsd.org Precedence: bulk Hey, Smth very strange is going on with my freebsd boxes after supping -stable today. The situation overview: I've got two FreeBSD boxes: one is a router and other just a host. --[green]-[...other_hosts...]--->[gerlach-router]---- Rest of the lan Everything worked fine. Green exported a /usr for others. Gerlach on the other hand exported /usr/src. I configured them and it worked more than fine. A couple weeks ago I decided to sup -stable (form 2.1.0-RELEASE) first time: green:~ {15} uname -a FreeBSD green.pap.waw.pl 2.1-STABLE FreeBSD 2.1-STABLE #0: Mon Feb 5 12:12:39 1996 jarekb@gerlach.pap.waw.pl:/usr/src/sys/compile/KERNEL i386 And the same on gerlach. After that still everything worked excellent. Even I managed to run NIS server and client. Today I did another supping of -stable on gerlach but something is strange. New kernel got crazy, my router stopped any TCP/IP activity. What I did then was to come back to the prevous kernel. It helped but still it just can't handle nfs exporting. The sample session on green. I am trying to mount /usr/src from gerlach: # mount gerlach:/usr/src /usr/src [Now it's oK mount report good mounting] # cd /usr/src [It is just hanging ... no msg, no cursor] There is no error message on gerlach:/var/log/messages and on the green I could see something like this: NFS server does not respond ! What is off course true. This what I snoop from network interface: 19:34:05.158732 green.pap.waw.pl > gerlach-ed2.pap.waw.pl: icmp: green.pap.waw.pl udp port 1052 unreachable 19:34:06.195344 green.pap.waw.pl.1 > gerlach.pap.waw.pl.nfs: 120 getattr 19:34:06.196092 gerlach-ed2.pap.waw.pl.nfs > green.pap.waw.pl.1: reply ok 96 19:34:06.196916 green.pap.waw.pl > gerlach-ed2.pap.waw.pl: icmp: green.pap.waw.pl udp port 1052 unreachable 19:34:08.236118 green.pap.waw.pl.1 > gerlach.pap.waw.pl.nfs: 120 getattr 19:34:08.236867 gerlach-ed2.pap.waw.pl.nfs > green.pap.waw.pl.1: reply ok 96 19:34:08.237676 green.pap.waw.pl > gerlach-ed2.pap.waw.pl: icmp: green.pap.waw.pl udp port 1052 unreachable 19:34:12.277658 green.pap.waw.pl.1 > gerlach.pap.waw.pl.nfs: 120 getattr 19:34:12.278482 gerlach-ed2.pap.waw.pl.nfs > green.pap.waw.pl.1: reply ok 96 19:34:12.279291 green.pap.waw.pl > gerlach-ed2.pap.waw.pl: icmp: green.pap.waw.pl udp port 1052 unreachable 19:34:20.320797 green.pap.waw.pl.1 > gerlach.pap.waw.pl.nfs: 120 getattr 19:34:20.321621 gerlach-ed2.pap.waw.pl.nfs > green.pap.waw.pl.1: reply ok 96 19:34:20.322520 green.pap.waw.pl > gerlach-ed2.pap.waw.pl: icmp: green.pap.waw.pl udp port 1052 unreachable ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^why this happens ? 9:34:29.701358 What couse such strange behaving ... it worked very well for days. I'm trying to play with this problem but need your comments or something ;-(. I tried to mount other fs from outside the router and everything was fine so the problem is gerlach. And kernel is demaged (I used the same config file which worked). Tell me if you need more informations. J. -- _ ____ ____ | | __ _| _ \ __ _/ ___| POLISH PRESS AGENCY - Warsaw _ | |/ _` | |_) / _` \___ \ email: ............... jarekb@pap.waw.pl | |_| | Jaroslaw Bazydlo __) | irc: McJARAS ...... on: #Polska #Gandalf \___/ \__,_|_| \_\__,_|____/. home-page: http://www.pap.waw.pl/~jarekb From owner-freebsd-stable Sat Mar 2 19:26:28 1996 Return-Path: owner-stable Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id TAA06115 for stable-outgoing; Sat, 2 Mar 1996 19:26:28 -0800 (PST) Received: from freebsd.netcom.com (freebsd.netcom.com [198.211.79.3]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id TAA06108 for ; Sat, 2 Mar 1996 19:26:24 -0800 (PST) Received: by freebsd.netcom.com (8.6.12/SMI-4.1) id VAA28268; Sat, 2 Mar 1996 21:30:17 -0600 From: bugs@freebsd.netcom.com (Mark Hittinger) Message-Id: <199603030330.VAA28268@freebsd.netcom.com> Subject: termcap probs after make world? To: stable@freebsd.org Date: Sat, 2 Mar 1996 21:30:16 -0600 (CST) X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: owner-stable@freebsd.org Precedence: bulk Anybody having problems with termcap stuff - vanilla tsets and initscr's after a 2.1-stable make world? Later Mark Hittinger Netcom/Dallas bugs@freebsd.netcom.com From owner-freebsd-stable Sat Mar 2 20:05:41 1996 Return-Path: owner-stable Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id UAA08538 for stable-outgoing; Sat, 2 Mar 1996 20:05:41 -0800 (PST) Received: from freebsd.netcom.com (freebsd.netcom.com [198.211.79.3]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id UAA08533 for ; Sat, 2 Mar 1996 20:05:35 -0800 (PST) Received: by freebsd.netcom.com (8.6.12/SMI-4.1) id WAA28346; Sat, 2 Mar 1996 22:09:34 -0600 From: bugs@freebsd.netcom.com (Mark Hittinger) Message-Id: <199603030409.WAA28346@freebsd.netcom.com> Subject: re: termcap probs after make world? To: stable@freebsd.org Date: Sat, 2 Mar 1996 22:09:33 -0600 (CST) X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: owner-stable@freebsd.org Precedence: bulk I made the problem go away by deleting /usr/share/misc/termcap.db :-) Looks like hash.c is messed up in -stable also. Later Mark Hittinger Netcom/Dallas bugs@freebsd.netcom.com