Merit Network
Can't find what you're looking for? Search the Mail Archives.
  About Merit   Services   Network   Resources & Support   Network Research   News   Events   Home

Discussion Communities: Merit Network Email List Archives

North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: Yahoo offline because of attack (was: Yahoo network outage)

  • From: Richard Steenbergen
  • Date: Wed Feb 09 09:38:22 2000

On Wed, Feb 09, 2000 at 11:17:34AM +0000, John Payne wrote:
> On Wed, Feb 09, 2000 at 12:02:42PM +0100, wrote:
> > May I suggest that we all get off our collective butts and do
> > something about these items?  Even by going so far as to proactively
> > probe our customer networks and/or extracting info from the list
> > available from the above site?
> ... and actively use the logs to contact peers when they're used as amplifiers
> against you, rather than just filtering?

Actually I had some ideas for a fairly interesting method to fight smurf
attacks directly while being attacked without causing further disruption
on anyone's network (just need time to finish writing it), and of course
more granular information about the attackers (complete list of broadcasts
unsed in an attack, the ability to track multiple attacks simultaniously
for use in a span port environment, information for amount of bandwidth
seen from each broadcast sorted by worst-attacker, etc) would be a part of

> Does anyone have a CIDR to broadcast address script handy?
> (the network address is part of the CIDR format :-)

Yes, I used to do a fairly large smurf amplifier scanning and emailing
operation back in the day (infact a lot of the stuff was
directly based off of it). Code was never (and will never) be distributed
because of potential for abuse, but my scanner was quite fast (the only
way to improve speeds would be to throw much more cpu/boxes at it or do
some kernel land work). Almost all of this proactive work has stopped
since smurf ceased to be such a "huge" problem in itself.

But, depending on the size and design of your network, at least one or
more of the following should be considered:
#1 filter your damn customers so they can't spoof out (I really can't
   stress this enough, particularly if you are an educational institution
   with a large dorm resnet! DO IT!), "ip verify unicast reverse-path"
#2 rate-limit ICMP echo/echo-replys at ingress and egress points
#3 filter/rate-limit ICMP 8/0 to the most obvious natural mask broadcast
   addresses (.0 and .255) both ingress and egress

And one of the more interesting ones... With the high packet/sec syn/ack
floods, the kids have realized that attacking the upstream routers is
often far more effective then a well protected downstream. All it takes is
pegging the CPU (against Cisco's this isnt very hard, even GRPs fall over
at extremely low (realtively speaking) rates against closed ports or under
high volumes of UDP attacks) until BGP falls over and suddenly victim A is
off the air (*). Consider numbering your core loopbacks and link /30s out
of a single block which can then be filtered/rate-limited at network

* As an interesting side note, the "best" and "worst" devices in this
  area... The Foundry gear, in particular the BigIron series (mgmt3 card
  is nice), has the highest survivability rate for a layer 3 device
  dealing with not only attacks through it but against the box itself,
  that I have yet seen. The worst seems to be the Cabletron SSR series,
  which does switching based on src ip/port dst ip/port combinations, and
  can only program new flows into the ASIC at a rate of about 3000 per

Richard A. Steenbergen <>
PGP Key ID: 0x60AB0AD1  (E5 35 10 1D DE 7D 8C A7  09 1C 80 8B AF B9 77 BB)
MFN / AboveNet Communications Inc - ISX Network Engineer, Vienna VA

Discussion Communities

About Merit | Services | Network | Resources & Support | Network Research
News | Events | Contact | Site Map | Merit Network Home

Merit Network, Inc.