nanog mailing list archives
RE: netscan.org update
From: "Roeland M.J. Meyer" <rmeyer () MHSC com>
Date: Tue, 26 Sep 2000 09:33:23 -0700
From: Daniel Senie [mailto:dts () senie com] Sent: Tuesday, September 26, 2000 8:45 AM
"Henry R. Linneweh" wrote:John;
"The SMURF problem is years old. People who don't look forthis on theirown networks and prevent it before it starts are AS MUCH ifnot MORE apart 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.
Current thread:
- RE: netscan.org update, (continued)
- RE: netscan.org update John Fraizer (Sep 25)
- Re: netscan.org update Bradley Dunn (Sep 25)
- Re: netscan.org update Charles Sprickman (Sep 25)
- Re: netscan.org update Roland Dobbins (Sep 25)
- CEF RPF check w/ACLs (was: Re: netscan.org update) Tony Tauber (Sep 25)
- Re: CEF RPF check w/ACLs (was: Re: netscan.org update) James A. T. Rice (Sep 28)
- Message not available
- Re: CEF RPF check w/ACLs (was: Re: netscan.org update) Patrick W. Gilmore (Sep 28)
- Re: CEF RPF check w/ACLs (was: Re: netscan.org update) James A. T. Rice (Sep 28)
- RE: netscan.org update John Fraizer (Sep 25)
- Re: netscan.org update Roland Dobbins (Sep 25)
- RE: netscan.org update John Fraizer (Sep 26)
- Re: netscan.org update Troy Davis (Sep 26)
- RE: netscan.org update John Fraizer (Sep 26)