I've noticed the same behavior as well. My first awareness of it came
during an otherwise typical day when, for some now forgotten but presumably
legitimate reason, I decided to ping the broadcast address of the local
subnet. To be quite honest, I think I was mostly just playing around at
the time, but the presumed degredation in network response quickly followed.
This being a class B network with well over a thousand machines, I quickly
checked my arp table to verify the cause and found more MAC addresses than
I was willing to page through, and certainly far more than I had otherwise
recently communicated with.
> So imagine this scenario: some disgruntled hax0r forges his
> source address to be your web server (or shell server, or irc server,
> or whatever) and sends some broadcast pings to a well populated remote
> network. His/her ping will be amplified by the number of hosts on the
> remote network.
Yes, the potential here for someone with a *little* time/motivation is
pretty severe. As for myself, I just classified it as a toy not to be
played with during business hours and relegated a small amount of further
experimentation to after hours when everyone else still hanging around was
busily try ing to p lay Doom. ;0
> Everyone needs to be doing the following:
>
> 1) Keep measured traffic stats, and look at them, using
> something like MRTG.
>
> 2) Filter all broadcast traffic from coming into your network.
> I believe that it's QUITE rare to have an application that
> is both *routed* and uses the broadcast address. This is
> made harder when you VLSM, but I belive the majority of
> networks are provisioned on an 8 bit boundary, so you can
> filter 90% of the traffic by filtering to the .255 address.
>
> 3) Re-iterating what people have said before, filter outbound
> traffic to allow only *your* host traffic from getting out.
> This makes you a responsible Internet citizen, and makes it
> harder for people to launch attacks like this one.
Anyone doing serious multicasting might want to take some preventive measures
with ICMP ECHO_REQUEST packets to the multicast address as well. I don't
have anything to test it on now, but as I recall, the same behavior, on an
obviously much smaller scale, is present here as well and could likely slip
through router rules if not looked at.
Best Regards,
Kyle Amon
_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
Kyle Amon | email: amonk@labyrinth.cftnet.com
Unix Systems Administrator | url: http://labyrinth.cftnet.com/kyle
Security Specialist | phone: (203) 486-3290
IBM Global Services | pager: 1-800-759-8888 PIN 1616512
_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
1024/173D96C9 1997/03/06 Kyle Amon <amonk@labyrinth.cftnet.com>
PGP Key fingerprint = 90 4F 0B D4 2D 37 E7 61 1A 31 7B F2 72 04 66 1A