|
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)
On Wed, Feb 09, 2000 at 11:17:34AM +0000, John Payne wrote: > > On Wed, Feb 09, 2000 at 12:02:42PM +0100, [email protected] 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 that. > 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 netscan.org 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 borders. * 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 second. -- Richard A. Steenbergen <[email protected]> http://users.quadrunner.com/humble 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
|