I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.

Download Presentation

PowerPoint Slideshow about 'Denial of Service (DoS)' - Gabriel

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

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.

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.

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.

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.

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.

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.

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 else—another 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.

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.

The previous illustration demonstrates that we have a wide variety of options. When deciding on our company’s 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 doesn’t 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.

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.

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 SCO’s 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.

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.

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.

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.

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.