> 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) [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
