smurf amp nets, the registry (SAR)

Tue Jun 16 17:16:14 UTC 1998

The biggest I've ever found is 12.79.237.0, depending on the host you ping
it from you can get between 900-1200 dupes, all from 12.79.237.1 which
reverses to 1.new-york-60rs.ny.dial-access.att.net. I've mailed at&t about
this several times and have gotten no response.

On another note, I wrote a broadcast scanner about a month ago that scans
many ips in parallel so its quite fast. I took a swat at a fairly good sized
chunk of the internet in about 24 hours and spent the next week mailing
everyone with more then 10 dupes. The breakdown of replies was something
like this (out of 900 received):

40% thanking me for pointing out a router or broadcast they missed
30% from an uplink informing me they have done the filtering for a customer
10% auto-replies
9% from people who tried to tell me they were secured (they weren't) =)
3% complaints from MCI 'cause the mail was going to the wrong department
3% hate mail from people convinced I was flooding their network
3% from people telling me they no longer maintained those networks
1% people telling me that I just found a 200 dupe network on an isdn line.
1% misc. stuff

of the messages from people telling me they had patched themselves, 15% were
not or missed a broadcast (like filtering .255 and missing .0). However
after pointing this out I believe almost all were patched properly.

About 1 week later I manually tested some of the biggest broadcasts and
amazingly enough almost ALL were patched. Unfortunately despite this success
it seems my uplink received some rather nasty calls from people complaining
about the scanning, so I was unable to continue scanning from that location.

The slowest part of the process is the rwhois'ing of each /24, not to
mention the 10 min timeout after 100 or so rwhois lookups. I made a slight
effort to spread the load out among vhosts and to do parallel lookups but
wasn't able to get it functional.

The least responsive networks seem to be military based. I easily had 1000
networks on army.mil navy.mil or af.mil (large numbers of dupes btw) with
dud contact information.

If anyone has a system they can donate for scanning or would like to work on
a better anti-smurf project, let me know.

-----Original Message-----
From: Oystein Homelien <oystein at homelien.no>
To: D'Arcy J.M. Cain <darcy at druid.net>
Cc: Michael Dillon <michael at memra.com>; nanog at merit.edu <nanog at merit.edu>
Date: Monday, June 15, 1998 10:15 PM
Subject: Re: smurf amp nets, the registry (SAR)

>On Mon, 15 Jun 1998, D'Arcy J.M. Cain wrote:
>
>> > http://www.powertech.no/smurf/
>>
>> It's great that you are doing this but I'm wondering how you determine
>> the number of responses.  In particular I see that 194.157.40.0/24 gives
>> 840 dups.  That one seems to be fixed but another one, 192.127.30.0/24,
>> is still broken but your probe shows 412 dups.  Seems to me that it can't
>> be more than 254.  My own test of that network showed a response of 151.
>> Just wondering.
>
>What we do is basically this:
>
> ping -c4 network_address
> ping -c4 broadcast_address
>
>Then we log the _highest number of returned packets_ from any of the 3*2
>pings we now have stored replies for.  The number of _dups_ we record is
>this count, minus one.
>
>Some times the number of dups we see vary wildly depending on when we
>probe, or where you are probing from.  I tend to attribute this to load on
>the amplifier network (perhaps someone is using them in an attack at this
>time), or packet-shredding international links that can't take the burst.
>
>(That is, if you and I were probing a european amplifier network, I might
>see slightly more dups than you since I am in Europe).
>
>Oh, and by the way!  No more than 254 replies, you say.  That's because
>you see it registered in the registry as a /24.  I need to point out that
>there's nothing we do at this point to verify that the prefix lengths
>of the networks entered into the SAR are actually correct.
>
>So something listed as a /24 could be anything - you'll have to look at
>the actual network number to judge for yourself what it might be.  We try
>to keep the prefix lengths longer so as not to block too much by accident
>(the probe defaults to /24).
>
>In some cases we see that the number of dups returned far exceed the
>theoretical max of the probed network.  In some cases this happens because
>the prefix length is wrong, but in other cases i am at a loss - the hosts
>in the probed network actually seems to return more than one response per
>request.  I have no idea why.  We saw this with the 193.55.112.0/24
>network, for instance (which has now been fixed).
>
>Oystein Homelien                  |  oystein at powertech.no
>PowerTech Information Systems AS  |  http://www.powertech.no/
>Nedre Slottsgate 5, N-0157 OSLO   |  tel: +47-23-010-010, fax:
+47-2220-0333
>