what you don't know can hurt you
Home Files News &[SERVICES_TAB]About Contact Add New

yahoo.txt

yahoo.txt
Posted Feb 17, 2000

Technical details of the attack on Yahoo! last week. Includes information on what kind of packets were sent, how they were affected, and how they fixed it.

tags | denial of service
SHA-256 | 6ef68ee3bb6800bd3f2021946e09a1eb30e71b8d0e1ee3b57e7c296d180467e2

yahoo.txt

Change Mirror Download
hi there,

what follows is some detail into some of the problems we've seen here
at yahoo over the past several days.

sorry for not getting this information out there sooner -- we needed to be
sure we are well protected first...

we've had at least 4 separate attacks to our globalcenter hosted
network over the past week. we have fewer details on the earlier
ones, but they all seem to have similarities. they all seem to at
least have a large distributed smurf component to them. we haven't
been able to verify anything more than icmp smurf attacks, but as
stated, early attacks had little or no data to base this on.

from what we've heard from other sites, many of the other attacks have
been similar to what we've seen, while some have been completely
different. e.g. we've heard of a syn-attack that was either single
sourced or at most had a few sources. one would assume there has been
a fair amount of copycat activity.

the only attack that had a significant impact on us was the highly
publicized one that began monday morning at about 10:30am PST. at
that time we didn't realize that we had been attacked earlier (on a
smaller scale) and therefore an outside attack wasn't at the top of
our list of troubleshooting. definitely a surprise attack.

the initial flood of packets, which we later realized was in excess of
1G bits/sec, took down one of our routers. after the router recovered
we lost all routing to our upstream isp. having had recent problems
with some of our network gear we were sidetracked for the first hour+
trying to eliminate other possible issues.

we finally had all traffic to us turned off upstream. this allowed us
to get basic routing back up and then realize that we were under a DoS
attack. it was somewhat difficult to tell what was going on, but at
the very least we noticed lots of icmp traffic. it took us and our
isp sometime to stabilize things: basically temporary filtering all
icmp - we were then able to glue things back together.

getting things back up then caused major disruption as pent up real
traffic began to overwhelm the system. things finally stabilized and
at the time it wasn't clear whether the reason for recovery was due to
the fact that the attack had ceased. our isp managed to log only a
few packets during this time. our isp did record that a significant
percentage of their peering circuits were taking part in this attack.
i.e. it was widely distributed.

subsequent attacks have had little to no effect. of course we were
better prepared and knew what to expect. but most importantly because
of measures our isp took to limit such attacks.

currently our isp is using CAR to rate limit icmp at various points
within their network. important things to note is that doing CAR or
filtering on echo request / echo reply is probably not enough.

these icmp types can probably also replace echo packets during an
attack:

router advertisement information request
router solicitation information reply

timestamp request address mask request
timestamp reply address mask reply

while an attacker(s) won't be able to generate these packets with a
large payload (my guess, i don't have time to verify specific icmp
protocol details), these packets can come in at the same high rate as
echo packets would.

these rate limiters did their job nicely on subsequent attacks. the
most recent one resulted in a manageable 150M bits/sec coming through
to the yahoo site. our isp was able to log quite a few of these
packets during this bout. we noticed at this time that most of the
icmp packets were destined to www.yahoo.com servers as well as our
nameservers. i.e. "well-known" servers were the focus of the attack.

now about 'no ip directed-broadcast' business. it won't help with
DDoS. the whole point of DDoS is to get by that countermeasure. if
you have for example 2,000+ hosts and you want to make sure you can't
be an amp site, you put 'no ip directed-broadcast' .. well .. if i can
break into one of those 2,000+ hosts, i just ping from within that
network.

in fact, on one of the traces we got, this is exactly what it looks
like. the destination ip was 255.255.255.255 and the source was us.

the attack was against our routers (spoofed src ip was that of our
router interface). it seem that attacker(s) knew about our topology
and planned this large scale attack in advance. in talking to
different other companies it seem they also were hit "where it hurts"
the most"

it seems that this is definitely a DDoS attack, with attacker(s) been
smart and above your average script kiddie. attacker(s) probably know
both unix and networking (cisco, etc) pretty well and learn about site
topology to find weak spots.

we have a few emails sent to us from people who's sites been used as a
amplifier. our isp probably has better/more logs then we do.

if you would like more information or have question about anything
above, please feel free to drop me email: jkb@yahoo-inc.com


-- yan


btw, here is a last minute note from our isp on measures taken:

Currently, we've throttling all forms of ICMP at our borders, so other
ICMP messages types wouldn't be all that effective either. (We plan to
modify to permit ttl-exceeded so traceroute still works under an attack).

During the large attack, upstream sources were restricted to a single
gigabit ethernet denying ICMP and throtting syn-- we recovered routing at
this time, and applied the same filters to all 4 Gigabit interfaces.

Making the attack a bit harder to diagnose was the loss of OSPF
adjacencies-- when routing would get hosed, the attack would be sunk at
the hold-down routes on the route reflectors. Once the router(s) had time
to recover, the attack would resume.


Login or Register to add favorites

File Archive:

April 2024

  • Su
  • Mo
  • Tu
  • We
  • Th
  • Fr
  • Sa
  • 1
    Apr 1st
    10 Files
  • 2
    Apr 2nd
    26 Files
  • 3
    Apr 3rd
    40 Files
  • 4
    Apr 4th
    6 Files
  • 5
    Apr 5th
    26 Files
  • 6
    Apr 6th
    0 Files
  • 7
    Apr 7th
    0 Files
  • 8
    Apr 8th
    22 Files
  • 9
    Apr 9th
    14 Files
  • 10
    Apr 10th
    10 Files
  • 11
    Apr 11th
    13 Files
  • 12
    Apr 12th
    14 Files
  • 13
    Apr 13th
    0 Files
  • 14
    Apr 14th
    0 Files
  • 15
    Apr 15th
    30 Files
  • 16
    Apr 16th
    10 Files
  • 17
    Apr 17th
    22 Files
  • 18
    Apr 18th
    45 Files
  • 19
    Apr 19th
    8 Files
  • 20
    Apr 20th
    0 Files
  • 21
    Apr 21st
    0 Files
  • 22
    Apr 22nd
    11 Files
  • 23
    Apr 23rd
    68 Files
  • 24
    Apr 24th
    23 Files
  • 25
    Apr 25th
    0 Files
  • 26
    Apr 26th
    0 Files
  • 27
    Apr 27th
    0 Files
  • 28
    Apr 28th
    0 Files
  • 29
    Apr 29th
    0 Files
  • 30
    Apr 30th
    0 Files

Top Authors In Last 30 Days

File Tags

Systems

packet storm

© 2022 Packet Storm. All rights reserved.

Services
Security Services
Hosting By
Rokasec
close