Denial of Service (DoS)

1
Denial of Service (DoS)

• By
• Prateek Arora

2
Few types of DoS attacks

• SYN Flooding Attack The SYN flood attack sends
  TCP connections requests faster than a machine
  can process them. The attacker creates a random
  source address for each packet. The SYN flag set
  in each packet is a request to open a new
  connection to the server from the spoofed IP
  address. The victim responds to spoofed IP
  address, then waits for confirmation that never
  arrives (waits about 3 minutes). Victim's
  connection table fills up waiting for replies and
  after table fills up, all new connections are
  ignored.
• Since the legitimate users are ignored as well,
  and cannot access the server. Once attacker stops
  flooding server, it usually goes back to normal
  state. Newer operating systems manage resources
  better, making it more difficult to overflow
  tables, but still are vulnerable. SYN flood can
  be used as part of other attacks, such as
  disabling one side of a connection in TCP
  hijacking, or by preventing authentication or
  logging between servers.

3
Few types of DoS attacks (contd.)

• Ping of death An oversized ICMP datagram can
  crash IP devices that were made before 1996.
• It is a denial of service attack caused by an
  attacker deliberately sending an IP packet larger
  than the 65,536 bytes allowed by the IP protocol.
  One of the features of TCP/IP is fragmentation
  it allows a single IP packet to be broken down
  into smaller segments.
• In 1996, attackers began to take advantage of
  that feature when they found that a packet broken
  down into fragments could add up to more than the
  allowed 65,536 bytes. Many operating systems
  didn't know what to do when they received an
  oversized packet, so they froze, crashed, or
  rebooted.

4
Few types of DoS attacks (contd.)

• Smurf In such an attack, a perpetrator sends a
  large amount of ICMP echo (ping) traffic to IP
  broadcast addresses, all of it having a spoofed
  source address of the intended victim. If the
  routing device delivering traffic to those
  broadcast addresses performs the IP broadcast to
  layer 2 broadcast function, most hosts on that IP
  network will take the ICMP echo request and reply
  to it with an echo reply each, multiplying the
  traffic by the number of hosts responding. On a
  multi-access broadcast network, potentially
  hundreds of machines might reply to each packet.
• Several years ago, most IP networks could lend
  themselves thus to smurf attacks -- in the lingo,
  they were "smurfable". Today, thanks largely to
  the ease with which administrators can make a
  network immune to this abuse, very few networks
  remain smurfable.

5
Few types of DoS attacks (contd.)

• Teardrop A normal packet is sent. A second
  packet is sent which has a fragmentation offset
  claiming to be inside the first fragment. This
  second fragment is too small to even extend
  outside the first fragment. This may cause an
  unexpected error condition to occur on the victim
  host which can cause a buffer overflow and
  possible system crash on many operating systems.

6
Frequency Scope

• How prevalent are denial-of-service attacks in
  the Internet today?
• Researchers at the Cooperative Association for
  Internet Data Analysis (CAIDA) address this
  question in their paper, Inferring Internet
  Denial-of-Service Activity.
• Using a technique called backscatter analysis,
  the researchers monitored unsolicited traffic to
  unpopulated address space. Their theory is that
  DoS traffic that uses random spoofed source
  addresses will generate some response traffic to
  the entire Internet address space, including
  unpopulated space.

7
Frequency Scope (contd.)

• Their results in February 2001 were that using
  backscatter analysis, they observed 12,805
  attacks on over 5,000 distinct Internet hosts
  belonging to more than 2,000 distinct
  organizations during a three-week period.
• In addition, CAIDA reports that 90 of attacks
  last for one hour or less 90 are TCP based
  attacks, and around 40 reach rates of 500
  Packets Per Second (PPS) or greater.
• Analyzed attacks peaked at around 500,000 PPS.
  Other anecdotal sources report larger attacks
  consuming 35 megabits per second (Mbps) for
  periods of around 72 hours, with high-volume
  attacks reaching 800 Mbps.

8
Damage Costs

• There may be hidden costs associated with
  denial-of-service attacks. For example, the
  direct target of a DoS attack may not be the only
  victim. An attack against one site may affect
  network resources that serve multiple sites.
• Or resources we share with other parties
  (upstream bandwidth) may be consumed by an attack
  on someone elseanother customer of our Internet
  service provider is attacked, so our upstream
  connections and routers are not as available to
  handle our legitimate traffic. Thus, even when we
  are not the target of an attack, we might
  experience increased network latency and packet
  loss, or possibly a complete outage.

9
Damage Costs (contd.)

• We may have additional costs because of the need
  to size notification resources (such as logs,
  mail spools, and paging services) to absorb
  attack-related events. Logging systems need to
  cope with significant deviations in the amount of
  data logged during attacks.
• Ideally, logging systems should use an
  out-of-band channel so that logging traffic does
  not add to the volume of DoS traffic that may be
  passed to the internal network. Centralized
  logging systems, considered a best security
  practice, may be stressed by receiving log data
  from multiple locations. Mail queues may fill up
  during a prolonged outage.

10
Damage Costs (contd.)

• Network traffic generated by the attack can
  result in incremental bandwidth costswhen we pay
  per byte, we also pay for the increased traffic
  caused by the attack.
• In addition, our upstream Internet provider might
  or might not be amenable to waiving penalty
  charges caused by flood traffic. Its good to
  know this ahead of time.
• Other issues that create hidden costs are
  insurance or legal fees or possible third-party
  liability resulting from our involvement in an
  attack.

11
Security Spending Estimates

• Part of any organizations security posture is a
  function of its spending decisions.
• Lets assume that an organization has an
  operational IT infrastructure, including Internet
  services and connectivity, and that the
  organization has 1,000,000 to defend against
  DoS attacks.
• Following are just three examples of how the
  organization might choose to expend those funds.

12
Examples

• Example 1
• Provide excess capacity to absorb some attacks,
  hire experienced staff, and provide defensive
  network equipment.
• 200,000 Extra bandwidth and router throughput
• 500,000 Experienced, highly skilled staff
• 300,000 Firewall, load-balancing,
  traffic-shaping technology
• Example 2
• Distribute web services to avoid single point of
  attack cover costs of attack with insurance.
• 700,000 Content distribution (Akamai, Digital
  Island, etc.)
• 300,000 Insurance premiums

13
Examples (contd.)

• Example 3
• Retain a managed security service to handle
  attacks, provide some in- house staff and
  defenses, contract with ISP to respond quickly to
  attacks.
• 200,000 Firewall, load-balancing,
  traffic-shaping technology
• 300,000 Managed security services
• 300,000 Four-hour response service from ISP
• 200,000 Staff

14
Security Spending Estimates (contd.)

• The previous illustration demonstrates that we
  have a wide variety of options. When deciding on
  our companys response to DoS attacks, consider
  these questions What are the chances of an
  attack hitting our company? What are the chances
  of an attack being of a certain type and/or
  magnitude? What level of risk is acceptable? How
  important is the Internet to our business? How
  long can we function without some or all Internet
  services? Which services to hire?
• In addition, business continuity plans should
  address loss of both critical and non-critical
  systems, though this doesnt change the services
  that should be prioritized as critical. Finally,
  because each attack has its own idiosyncrasies,
  we may need to extensively customize technical
  remedies, remaining aware that technical
  countermeasures are not 100 percent effective.

15
How to handle DoS

• Protecting Among the aspects of protecting our
  systems and our business, are looking at network
  design, discussing our agreement with your ISP,
  putting detection mechanisms and a response plan
  in place, and perhaps taking out an insurance
  policy. Proper preparation is essential for
  effective detection and reaction. Unfortunately,
  some sites begin their cycle with detection and
  reaction, triggering preparation steps after a
  lessons learned experience.
• Detecting Our ability to detect attacks
  directly affects our ability to react
  appropriately and to limit damages. Among the
  approaches we can take are instituting procedures
  for analyzing logs and using automated intrusion
  detection systems.
• Reacting Reaction steps, hopefully put in place
  as part of preparing for an attack, include
  following our response plan, implementing
  specific steps based on the type of attack,
  calling our ISP, enabling backup links, moving
  content, and more. Technical steps include
  traffic limiting, blocking, and filtering.

16
Real world targets and metrics

• MyDoom On Monday, January 26, 2004 a new and
  very aggressive E-mail worm began infecting
  thousands of machines both home users and
  corporate users alike. MyDoom arrived as an
  e-mail attachment from a randomized sender with
  various subject titles, and quickly spread across
  the Internet. By Tuesday morning it was estimated
  that 1 out of every 12 e-mails contained the
  virus.
• The worm had a real target in mind - www.sco.com.
  It was engineered to launch a denial-of-service
  (DOS) attack against SCO starting on February 1.
  The attack began early Sunday morning as infected
  computers sent messages to SCOs website
  completely overloading its web servers.
  Fortunately, due to an error in coding, only
  about one in four infected machines engaged in
  the DOS attack against SCO.
• However, that was enough. In a prepared
  statement, SCO confirmed the attack stating that
  requests sent to www.sco.com from MyDoom-infected
  computers were responsible for making its website
  "completely unavailable" on Sunday, February 1.
  Facing continual attacks for at least until
  February 12, SCO moved its Web site. Over
  250,000 in bounties were posted by SCO and
  Microsoft for information leading to the
  identification of the virus author.

17
Real world targets and metrics (contd.)

• The virus now has the distinction of being the
  fastest spreading attack on record, edging out
  SoBig.F which hit the Internet with a vengeance
  in August of 2003. Estimates on the number of
  machines infected vary, but it is anticipated the
  number will be well over 1 million on the final
  tally. At its peak on Thursday, January 29, the
  number of systems being infected reached 12,000
  per hour.
• Because the code is designed to stop its DoS
  attack against SCO on Feb 12, many individuals
  and companies are under the impression that the
  virus will pose no further threat at that point.
  Security experts warn that this is not the case.
  The virus will still be resident until cleansed
  and will continue to monitor activity on the
  infected machine. Additionally infected machines
  can serve as a zombie army that could allow
  hackers to execute additional DoS attacks and
  cause other serious problems in the future.
• Damage and total cost estimates from MyDoom are
  still in progress, but CEI now estimates the
  total may exceed 4 billion, making it one of
  the most costly cyber attacks on record.
  Additionally, 2004 is threatening to be one of
  the worst years ever in terms of virus damages
  and costs. The fact that SoBig.F and MyDoom were
  launched only months apart and are now ranked as
  the two fastest spreading viruses of all time.

18
Real world targets and metrics (contd.)

• Ramen Worm In January 2001 a series of DoS
  attacks overwhelmed the multicast infrastructure
  with an unusually large number of SA messages. An
  Internet worm, called the Ramen Worm, triggered
  these attacks with the simple attack mechanism.
• Interestingly, attacks caused by the Ramen Worm
  were purely accidental. They were not targeted at
  multicast and, in fact, did not intend to cause a
  DoS attacks at all. The Ramen Worm was, actually,
  intending to just port-scan a random set of IP
  addresses by sending ICMP messages. It triggered
  the flood of bogus SA messages because part of
  the address range it scanned belonged to the
  Class D multicast address range. The activity of
  the Ramen Worm exposed just how fragile the
  multicast infrastructure is.

19
Real world targets and metrics (contd.)

• To gauge the impact of Ramen Worm attacks on the
  global infrastructure with the help of data
  collected from multiple routers using our global
  monitoring infrastructure, few metrics were
  collected about it.
• Analyzing these metrics we are able to
  substantiate the claims that Multicast Source
  Discovery Protocol (MSDP) DoS attacks can rapidly
  span the entire infrastructure and have serious
  negative repercussions.

20
Real world targets and metrics (contd.)

• The above figure plots the number of Source
  Active (SA) messages seen in the MSDP
  infrastructure in a one month period starting on
  January 12, 2001. These results are based on the
  aggregate view of MSDP tables collected from
  multiple routers at 15-minute intervals. These
  results show that there were 40 distinct attacks
  during the data collection period. The number of
  bogus SAs generated because of these attacks
  ranged from 10000 to close to 45000. Further
  investigation reveals that each of these attacks
  was launched from a different domain.

21
References

• http//www.google.co.in
• http//www.itoc.usma.edu/workshop/2005/Papers/Foll
  ow20ups/Making20Garbage20Collection20Dependabl
  e.pdf
• http//www.cert.org/archive/pdf/Managing_DoS.pdf
• http//en.wikipedia.org/wiki/Smurf_attack
• http//searchsecurity.techtarget.com/sDefinition/0
  ,,sid14_gci822096,00.html
• http//www.computereconomics.com/article.cfm?id93
  2
• www.caida.org/tools/measurement/Mantra/mantra-publ
  ications/INFOCOM-03b.ps.gz
• http//www.iss.net/security_center/advice/Exploits
  /TCP/SYN_flood/default.htm