North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

RE: netscan.org update

  • From: Roeland M.J. Meyer
  • Date: Tue Sep 26 12:37:07 2000

> From: Daniel Senie [mailto:[email protected]]
> Sent: Tuesday, September 26, 2000 8:45 AM

> "Henry R. Linneweh" wrote:
> > John;

> > "The SMURF problem is years old.  People who don't look for 
> this on their
> > own networks and prevent it before it starts are AS MUCH if 
> not MORE a
> > part of the problem as the script kiddies".
> 
> Implementing RFC 2827 (ingress filtering) and RFC 2644 (disabling
> directed broadcast) is more than just a nice idea. These are 
> both BCPs,
> since they both represent methods for limiting damage to the Internet.

I've been following this thread since the first time it came around. In
the last round, the point was made that 0 and 255 weren't the ONLY
b'cast addrs in a /24. In fact they aren't, over here (MHSC.NET). Our
/24 is so sub-netted. In fact, one can have up to 64 b'cast addrs in a
/24. 

I know that all of you are aware of this. Granted, each subsequently
smaller subnet also limits the maximum number of hosts that will respond
to the smurf trigger. The point is that, the web-site ONLY tests 0 and
255 and y'all are discussing filtering on ONLY those values. This is
inadequate for what you are trying to do. A /25 can still yield 127 host
respnses and a /26 will yield 63 host responses, and so on...
Discovering these b'cast addrs isn't difficult either and I'm sure that
the script-kiddees already have a means to do so. Had I the time, I
could write the code, the algorithm is trivial.

The last time this came around I suggested a means that would work. It
involves making entries in your in-addr.arpa file that lables each base
and b'cast addr. As an example, I have done this to my own file and have
been maintaining it for years. Once put in place, it is simple to
maintain. Generally, subnet assignments don't change that much (scale =
years). The upstream should filter any and all packets going to those
addrs, at the gateway. This can be made a part of the contract, with
downstreams that manage their own IP and DNS space (like MHSC does).
I've actually considered a script that reads the ARPA file and generates
ipchains commenads to automagically put the proper filters in place.
Again, it isn't that hard. 

The specific file I am talking about is "175.108.199.inaddr.arpa", dig
at your local BIND for the auth server NS1.MHSC.NET. Base addrs are
labeld "base" and b'cast are labeled "bcast" (duh).

There are various means to implement this, I can think of 1-2 others
without really trying. The point is that, if you're going to do this, do
it right. Defense is a lot less socially antagonistic than offensively
BGP black-holing antire IP-blocks (which can get you seriously sued) and
creating more outages than we already have to suffer through.