North American Network Operators Group|
Date Prev | Date Next |
Date Index |
Thread Index |
Author Index |
Re: Smurf Prevention
- From: Richard Thomas
- Date: Sun Jul 12 19:57:48 1998
From: Dalvenjah FoxFire <firstname.lastname@example.org>
To: Richard Thomas <email@example.com>
Cc: firstname.lastname@example.org <email@example.com>
Date: Sunday, July 12, 1998 6:24 PM
Subject: Re: Smurf Prevention
>On Mon, Jul 13, 1998 at 04:48:41AM -0400, Richard Thomas put this into my
>> Perhaps we might have some success preventing smurfs from the most common
>> sources, hacked machines on university dorm networks, by getting the
>> university backbones to filter spoofs. Things like SUnet, FUnet,
>> etc, account for a large portion of universities used to smurf from, and
>> might be easier then trying to get each school to filter individually. I
>> found the following two addresses for nysernet and funet but was unable
>> read or translate the Swedish on www.sunet.se.
>That's one solution. What might be a better solution would be if the Big
>networks (MCI, Sprint, UUnet, etc.) were to take the list of smurf
>from something like the SAR, *verify* that they're still smurf amplifiers,
>and then refuse to route traffic from those networks.
>Not only would it cut the smurfs down cold, but it would also get the folks
>responsible for those networks to fix things.
>Then again, if the big-bandwidth folks cared about such things, perhaps
>would have done so already.
Unfortunately the big guys have no incentive to deal with it on a
large-scale basis. The amount of traffic involved is insignificant to them,
they're making money off the bandwidth used, and of course the "filtering
smurfs takes too much cpu time on our routers" answer (they don't seem to
realize that as soon as the kids loose the instant gratification of seeing a
ping timeout they will get bored and stop). You know several global
broadcast scans have been conducted, I've submitted them all to the Smurf
Archive Registry, and we now seem stuck at around 14,000. That leads one to
believe maybe this is all there ARE (of the .0 and .255 variety anyhow).
10,000 of those are < 10 dupes, and only 500 or so are > 30 dupes. Also
remember that SAR doesn't scan to remove dead ones by itself (something I am
currently working to create in my bcast databases), so a good many of those
are probably fixed by now.
HOW HARD CAN IT BE to take care of 500 broadcasts? Very hard, since the only
bcasts still left are those with broken contact information and upstreams
who haven't been informed or who don't give a damn. Maybe if we all picked
10 of the worst offenders every day, picked up the phone, and started
informing people who have missed the boat...