smurf amplifier vs one workstation
Brian Pape
pape at gatekeeper.ph.ucla.edu
Mon Jun 22 16:27:05 UTC 1998
On Sun, 21 Jun 1998, Brett Frankenberger wrote:
> :: Joe Shaw writes ::
> >
> > > Next there is a rumor that 8000 users have been infected with a tweaked
> > > system.exe file that makes that user a smurf amplifier unwittingly. These
> > > are things to watch for. I wish there was an easier way to break bad news.
> >
> > I fell out of my chair at that statement. One user/host cannot be a smurf
> > amplifier; one network from a /30 and down can with different results.
>
> If I modify my kernel to generate 100 ECHO REPLYs for each ICMP ECHO I
> recieve, how is my PC signifigantly different than a /24 behind a
> router that doens't have "no ip directed-boradcast" (or it's
> equivalent) configured, with 100 devices on it that all respond to ICMP
> ECHOs addressed to the boracast address?
It's certainly different- a standard smurf gets n replies for each packet
received, if you have one hundred hosts, that's 100 replys for each echo
request. A single host sending out 100 replys is no different than a
pingflood, which can't flood more than a serial dialup line. The volume
of replys is 100 times greater for the 100 host network.
As for a "patched system.exe", if it exists, it could be problematic.
There is nothing preventing a workstation from receiving an ICMP echo
request and rebroadcasting it on the LAN with a spoofed source address.
Egress filters on the originator network would be ineffective because the
original packet would have a true source address in it. The destination
machine would accept the packet and spoof it onto its local network, which
would generate (n) replies, which would not be filtered on their way out
of the network to the remote address. The patched system would not log
incoming packets, so the only way to track it down would be to find the
local machine that is sending broadcasts to the local lan with spoofed
source addresses, and sniff for remote-originated packets destined for
that machine. The only upside is that you'd have the actual ip of the
originator.
Brian Pape
Computer Resource Services
University California Los Angeles
pape at mail.ph.ucla.edu
x59284
More information about the NANOG
mailing list