North American Network Operators Group

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

Re: Info on the DoS attacks.

  • From: Richard Steenbergen
  • Date: Thu Feb 10 15:57:10 2000

On Wed, Feb 09, 2000 at 10:15:46PM -0800, Sean Donelan wrote:
> 
> On Wed, 09 February 2000, Joe Shaw wrote:
> > I'd be worried if they didn't have theories or know about the known DDoS
> > attacks, but not if they didn't have specifics.  Tier1 NSP's seem to be
> > very tight lipped about these sorts of things when they are the 
> > victim.  I'm sure there are GC employees on this list, but none have come
> > forward to give any details.  Could be a gag order, which wouldn't shock
> > me at all.  Hopefully we'll know something eventually, but for now we're
> > all mushrooms when it comes to official information.
> 
> I guess the techies reduced to reading the New York Times for technical
> details.
> 
> Today's NYT has a description from GlobalCenter's PR person.  The Yahoo
> attack was a large number of ICMP EchoReplies(PINGs) coming via GlobalCenter's
> 50 peering connections (about half of GlobalCenter's total peering connections).
> Which may explain the "50" number I've been hearing.  The original ICMP EchoRequests listed Yahoo as the source address and were directed to other
> networks which replied to Yahoo.  GlobalCenter installed rate-limits, but
> didn't know if they are effective in preventing attacks.
> 
> Yahoo's spokesperson confirmed GlobalCenter's account.
> 
> (free NYT registration required)
> http://www.nytimes.com/library/tech/00/02/biztech/articles/10attack.html
> 
> Note: other people have sent me private mail saying it was actually a
> different method, but this appears to be the official statement out of
> GlobalCenter and Yahoo.

Also http://www.nytimes.com/library/tech/00/02/biztech/articles/10web.html

I believe it was a combination of smurfs in the 800-1200Mbps range and
SYN/ACK floods. Honestly I believe the big .COMs have done a fairly good
job of protecting their systems from SYN floods, within reasonable limits
of technology (its a CPU problem, someone puts 1000 p2 400s against your
e10k, you either buy more and bigger hardware or you find intelligent
ways to use less cpu to ditch the bad packets).

I believe the smurf problem is being overlooked to some degree. If your
network has sufficient capacity the filters are almost trivial, even in
the range of multi-Gbps attacks. I suspect many people were caught
offguard and were not prepared to react quickly, even if they HAD the
ingress capacity (and for those networks with large ingress capacity but
not enough headroom on the backbone or customer attach point identifying a
supprise attack and getting critical borders protected could quite likely
be a bitch). Now obviously not everyone is going to have the capacity for
such, nor should they without a good reason. Thats one of the reasons the
people who can afford it and need burst capacity and reliable service get
connectivity from companies like AboveNet, Exodus, and GlobalCenter with
centralized points of huge capacity and the backbone and infastructure to
support it.

As for the syn floods... I think I have some intelligent ways to go about
filtering them down at the router level without disrupting normal traffic,
if I could get some cooperation from Cisco. I'm leery about releasing the
information publicly (or at least on a public mailing list which will be
archived and distributed for quite some time) because its something that
the attackers "can" change, but given the clue level we've seen so far I
don't think they have a prayer unless we walk right up and hand it to them
on a silver platter. Would someone in a position of clue from Cisco please
contact me privately about this, I've asked before but don't think anyone
has ever even looked at it, so I'm taking this request public.

-- 
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