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@homelien.no> To: D'Arcy J.M. Cain <darcy@druid.net> Cc: Michael Dillon <michael@memra.com>; nanog@merit.edu <nanog@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@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