From owner-freebsd-current Mon Aug 16 22:35:34 1999 Delivered-To: freebsd-current@freebsd.org Received: from rucus.ru.ac.za (rucus.ru.ac.za [146.231.29.2]) by hub.freebsd.org (Postfix) with SMTP id 0A28514C15 for ; Mon, 16 Aug 1999 22:35:22 -0700 (PDT) (envelope-from geoff@rucus.ru.ac.za) Received: (qmail 68406 invoked by uid 268); 17 Aug 1999 05:36:36 -0000 Message-ID: <19990817053636.68405.qmail@rucus.ru.ac.za> Subject: Re: Dropping connections without RST In-Reply-To: <199908170356.UAA10363@gndrsh.dnsmgr.net> from "Rodney W. Grimes" at "Aug 16, 1999 08:56:54 pm" To: current@freebsd.org Date: Tue, 17 Aug 1999 07:36:36 +0200 (SAST) Reply-To: "Geoff Rehmet" From: "Geoff Rehmet" X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Rodney W. Grimes writes : > > > > Now what would a box with so much security concern such that > it needed this knob be doing running an ftp session.... though > your point is valid and acceptable for low security boxes. And > I can see the real benifit that having this knob for those boxes > would be, since it would mean not having to spend the care and > attention to create a proper firewall rule set. > > The idea is okay in the general since, this is an easy knob to > add, it would increase the security of some boxes, and not require > great configuration pains of writting ipfw rules. .... > > IMHO, this know would give some folks a false since of security, > but not so much that I would argue about keeping it out. I never intended this idea as a replacement for ipfw, but rather as a simple setup, which can be done to make a SMALL improvement in security, and just make the lives of inquisitive or nasty people a little harder. Maybe I will eventually decide I want ipfw on some of the boxes concerned, but that is trickier on machines like public ftp servers. Also, the machines concerned already sit behind a packet filtering firewall setup, which is being slated for a $100000 upgrade over the next year anyhow, so this is not for machines that act as any primary line of defense. I'm also making the assumption that the machines concerned are being looked after by competent admins. (A lot to assume sometimes.) It seems, though, that there are no serious objections to this kind of feature. I was thinking of calling it net.inet.tcp.blackhole, and net.inet.udp.blackhole rather than "drop_in_vain". Any advances on that. I never quite cottoned onto the "in vain" bit - it seems a bit obscure, personally, I prefer the idea of the machine behaving like a black hole - refused connections no longer "reflect" off it. :-) Geoff. -- Geoff Rehmet, The Internet Solution geoffr@is.co.za; geoff@rucus.ru.ac.za; csgr@freebsd.org tel: +27-83-292-5800 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message