From owner-freebsd-current Mon Aug 16 23:49:48 1999 Delivered-To: freebsd-current@freebsd.org Received: from gndrsh.dnsmgr.net (GndRsh.dnsmgr.net [198.145.92.4]) by hub.freebsd.org (Postfix) with ESMTP id EE5F3155B5 for ; Mon, 16 Aug 1999 23:49:43 -0700 (PDT) (envelope-from freebsd@gndrsh.dnsmgr.net) Received: (from freebsd@localhost) by gndrsh.dnsmgr.net (8.9.3/8.9.3) id XAA12148; Mon, 16 Aug 1999 23:48:46 -0700 (PDT) (envelope-from freebsd) From: "Rodney W. Grimes" Message-Id: <199908170648.XAA12148@gndrsh.dnsmgr.net> Subject: Re: Dropping connections without RST In-Reply-To: <19990817053636.68405.qmail@rucus.ru.ac.za> from Geoff Rehmet at "Aug 17, 1999 07:36:36 am" To: geoffr@is.co.za (Geoff Rehmet) Date: Mon, 16 Aug 1999 23:48:46 -0700 (PDT) Cc: current@FreeBSD.ORG 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 This is an ACK. I like those names, the idea is okay given that the documentation for it reflects what has been discussed here in this thread so folks can understand this is a very simple security measure. And it works just like a blackhole route does... if no more specfic route exists we send the packet to a bit bucket, now someone want to make the routing code under ``port routes'' :-) :-)... > > 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. :-) Perhaps one more word in the mib name to reflect that it applies to sockets without listners is all I can think of, but not sure what to add to the name to make this clear. mib's tend to be breif anyway. -- Rod Grimes - KD7CAX - (RWG25) rgrimes@gndrsh.dnsmgr.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message