Subject: Re: DOS attacks
To: Miles Nordin <carton@Ivy.NET>
From: David Maxwell <david@fundy.ca>
List: netbsd-advocacy
Date: 02/12/2000 11:35:02
On Fri, Feb 11, 2000 at 09:23:28PM -0700, Miles Nordin wrote:
> Security (or, rather, useability) on the Internet is increasingly a
> communal affair. I think we should diversify our interpretation of
> ``security'' a bit for the purpose of advising otherwise selfish (how
> secure is MY sight from those Dastardly Hackers) NetBSD users on how to
> become good polite neighbors in the Internet community.
It has always been a community affair, it just happens that the nature
of the community has changed. Wide availability of net access has brought
online many networks without proper admins, as well as millions of newbies
and thousands of 'script kiddies'.
I agree with your point of a 'good neighbour' focus - the trouble is that
there are conflicting goals. Something other than sendmail would be
better for security, but there's inertia in change. Upgrading sendmail
earlier could allow NetBSD machines to be a different type of unfriendly
neighbour - the kind crackers break into and host attacks from.
> Do NetBSD routers forward directed broadcasts? Is this behaviour optional
> and defaulted to ``off'' as required by rfc 2644? Note that the recent
> attacks may not have been of this sort.
NetBSD complies. Check your sysctl:
net.inet.ip.directed-broadcast = 0
> Anyone have thoughts on running ipf out-of-the-box? My thoughts are that
> the configuration of an actual router is manual enough as to make any
> ``automatic'' ipf rules useless. But this is debateable, as rc.conf makes
> a pretty fair effort of being multi-interface-router--friendly. Does
> anyone using NetBSD for actual routing care to comment on
> ipf-out-of-the-box for the purpose of rfc2267 ``ingress filtering?''
The information needed for the setup is available in the form of routing
tables - you have to have a route to every network in a non-default
direction. It would be possible to write a utility which would select your
external network interface (based on where the default route goes), and
create an outgoing filter list limiting traffic to source IPs that you
have routes to on other interfaces.
It's problematic though, since many configs will break, or be imperfect
due to private IPs (192.168 etc), VPNs, misconfigured routes. And I'm not
sure what the 'right' handling of multiple default routes would be.
--
David Maxwell, david@vex.net|david@maxwell.net -->
If you don't spend energy getting what you want,
You'll have to spend it dealing with what you get.
- Unknown