DDoS MidSubmission

DDoS Attacks, Simulation and Detection Projects Technion Faculty of Electrical Engineering - Computer Networks Lab
DDoS Projects Midterm Report
Members of The Teams: Team 1 (cn1w03): Tzach Schechner, 037696226 Yaniv Stern, 038664454 Instructor: Yoram Yihyie
1
Team 2 (cn2w03): Moshe Benyamini, 027437086 Ori Modai, 033389487
1 Table of Content
DDoS Projects.................................................................................................................................1 Midterm Report...............................................................................................................................1 1 Table of Content...........................................................................................................................2 Background..................................................................................................................................8 2 General Definitions.......................................................................................................................9 3 Project objectives..........................................................................................................................9 4 Project content..............................................................................................................................9 4.1 Attack......................................................................................................................................9 4.2 Detection...............................................................................................................................10 4.3 Work Environment...............................................................................................................10 5 DDoS background....................................................................................................................11 5.1 What is DoS & DDoS?.........................................................................................................11 5.2 Brief History & Trends:........................................................................................................11 5.3 The Asymmetric Threat........................................................................................................13 6 Attacks classification..................................................................................................................14 6.1 Bandwidth/Throughput Attacks............................................................................................14 6.2 Protocol Attacks....................................................................................................................21 6.3 Software Vulnerability Attacks............................................................................................23 7 Attack Tools................................................................................................................................26 7.1 General Description..............................................................................................................26 7.2 Command Distribution Methods..........................................................................................26
7.3 Frequently Used Attack Tools..............................................................................................27 8 Test Cases...................................................................................................................................30 8.1 The attack on grc.com site May 2001 ...............................................................................30 8.2 DoS Attack on a Check Point Firewall.................................................................................33 Attack.........................................................................................................................................35 9 Attack Platform Requirements Review......................................................................................36 9.1 General..................................................................................................................................36 9.2 Details...................................................................................................................................36 9.3 Simulation Environment ......................................................................................................38 10 TFN2K Structure overview......................................................................................................40 10.1 General................................................................................................................................40 10.2 The client ("the master").....................................................................................................40 10.3 The agent ("the daemon")...................................................................................................41 11 Features added to TFN2K.........................................................................................................43 11.1 New commands...................................................................................................................43 11.2 Logging system...................................................................................................................44 11.3 Synchronization tool...........................................................................................................45 11.4 Corrections to original TFN2K...........................................................................................48 12 References.................................................................................................................................49 12.1 Attack Methods...................................................................................................................49 (1) Managing the Threat of Denial-of-Service Attacks, CERT Coordination Center
http://www.cert.org/archive/pdf/Managing_DoS.pdf ....................................................................49 (2) CERT Advisory CA-1997-28 IP Denial-of-Service Attacks
http://www.cert.org/advisories/CA-1997-28.html .........................................................................49
(3) DRDoS - Distributed Reflection Denial of Service http://grc.com/dos/drdos.htm .................49 (4) Denial of Service Attack Threat Analyzed http://www.uksecurityonline.com/threat/dos.php ........................................................................................................................................................49 (5) Microsoft Knowledge Base Article - Q172983 - Explanation of the Three-Way Handshake via TCP/IP http://support.microsoft.com/default.aspx?scid=KB;EN-US;Q172983&LN=EN-US ..................49 (6) The Strange Tale of the Denial Of Service Attacks Against GRC.COM
http://grc.com/dos/grcdos.htm .......................................................................................................49 (7) Razor The Naptha DoS vulnerabilities
http://razor.bindview.com/publish/advisories/adv_NAPTHA.html ..............................................49 (8) CERT Advisory CA-2000-21 Denial-of-Service Vulnerabilities in TCP/IP Stacks
http://www.cert.org/advisories/CA-2000-21.html .........................................................................49 (9) CERT Advisory CA-1998-01 Smurf IP Denial-of-Service Attacks
http://www.cert.org/advisories/CA-1998-01.html .........................................................................49 (10) Denial of Service Attacks using Nameservers http://www.cert.org/incident_notes/IN-200004.html ...........................................................................................................................................50 (11) CERT Advisory CA-1996-21 TCP SYN Flooding and IP Spoofing Attacks
http://www.cert.org/advisories/CA-1996-21.html..........................................................................50 (12) CERT Advisory CA-1997-28 IP Denial-of-Service Attacks
http://www.cert.org/advisories/CA-1997-28.html..........................................................................50 (13) CERT advisory CA-1998-13: Vulnerability in Certain TCP/IP Implementations
http://www.cert.org/advisories/CA -1998-13.html ........................................................................50 (14) Sans Institute How can attacker use ICMP for reconnaissance?
http://www.sans.org/newlook/resources/IDFAQ/ICMP_misuse.htm............................................50 (15) CERT Advisory CA-1996-26 Denial-of-Service Attack via ping
http://www.cert.org/advisories/CA-1996-26.html..........................................................................50
(16)
Security Info Online, CI-98.03: Cisco PIX and CBAC Fragmentation Attack
http://online.securityfocus.com/advisories/1428............................................................................50 (17) CERT Advisory CA-1996-01 UDP Port Denial-of-Service Attack
http://www.cert.org/advisories/CA-1996-01.html .........................................................................50 12.2 Background and History.....................................................................................................50 (18) Slides of history from early 90' (tools and trends).
http://www.uniforum.chi.il.us/slides/ddos/sld001.htm...................................................................50 (19) CERT Coordination Center, Denial of Service Attacks
http://www.cert.org/tech_tIPs/denial_of_service.html...................................................................50 (20) Computer Crime, Ronald B. Standler http://www.rbs2.com/ccrime.htm#anchor111666 Yahoo, Amazon attack....................................................................................................................51 (21) Weather-com story
http://www.techweb.com/wire/story/TWB20010524S0010 ........................................................51 (22) Valve Launches Largest DDoS In History By Kevin Weiser
http://www.themushroom.com/humor/valvedos.html....................................................................51 (23) Distributed Reflection Denial of Service, Steve Gibson,
http://grc.com/files/drdos.pdf..........................................................................................................51 (24) DDoS: Chronology, Mazu Networks
http://www.mazunetworks.com/ddos_library/chronology.html ....................................................51 (25) SANS Institute, Consensus Roadmap for Defeating Distributed Denial of Service Attacks http://www.sans.org/ddos_roadmap.htm#1....................................................................................51 12.3 Attack Tools........................................................................................................................51 (26) CERT Incident Note IN-99-07 Distributed Denial of Service Tools
http://www.cert.org/incident_notes/IN-99-07.html .......................................................................51 (27) CERT Advisory CA-1996-01 UDP Port Denial-of-Service Attack
http://www.cert.org/advisories/CA-1996-01.html..........................................................................51
(28)
The DoS Project's "Trinoo" distributed denial of service attack tool, David Dittrich of Washington
University
http://staff.washington.edu/dittrich/misc/trinoo.analysis.txt .........................................................51 (29) National Infrastructure Protection Center - TRINOO/Tribal Flood Net/tfn2k
http://www.nIPc.gov/warnings/alerts/1999/trinoo.htm .................................................................52 (30) SANS Institute - Distributed Denial of Service Attack Tools: trinoo and wintrinoo
http://www.sans.org/newlook/resources/IDFAQ/trinoo.htm .........................................................52 (31) Advanced Networking Management Lab (ANML), Distributed Denial of Service
Attacks(DDoS) Resources - http://www.anml.iu.edu/ddos/tools.html ..........................................52 (32) ISS Security Alert, December 7, 1999, Denial of Service Attack using the trin00 and Tribe Flood Network programs http://bvlive01.iss.net/issEn/delivery/xforce/alertdetail.jsp? id=advise40 ....................................................................................................................................52 (33) The "Stacheldraht" distributed denial of service attack tool, David Dittrich, University of Washington - http://staff.washington.edu/dittrich/misc/stacheldraht.analysis.txt .........................52 (34) SANS Institute - "Trinity" Distributed Denil of Service Attack Tool, Michael Marchesseau http://rr.sans.org/malicious/trinity.php ..........................................................................................52 (35) CERT Incident Note IN-2000-08. "Chat Clients and Network Security." CERT. 21 June 2000 - http://www.cert.org/incident_notes/IN-2000-08.html ........................................................52 (36) X-Force. "Internet Security Systems Security Alert." Internet Security Systems. 05
September 2000 - http://xforce.iss.net/alerts/advise59.php ...........................................................52 (37) Axent releases a full TFN2K Analysis -
http://www.securiteam.com/securitynews/5YP0G000FS.html .....................................................52 (38) Analyzing Distributed Denial Of Service Tools: The Shaft Case; Sven Dietrich NASA Goddard Space Flight Center, Neil Long Oxford University, David Dittrich University of Washington - http://home.adelphi.edu/~spock/lisa2000-shaft.pdf ................................................53 (39) SANS Institute - An Analysis of the "Shaft" Distributed Denial of Service Tool -
http://www.sans.org/y2k/shaft.htm ................................................................................................53
12.4 Test Cases..........................................................................................................................53 (40) Denial of Service attacks against GRC.COM, Steve Gibson
http://grc.com/dos/grcdos.htm........................................................................................................53 (41) SANS Institute, DoS Attack on a Check Point Firewall
http://rr.sans.org/casestudies/dos_attack.php..................................................................................53
Background
2 General Definitions
The following definitions and terms will be used throughout this document: DoS Attack: Refers to all Denial of Service related attacks including DoS, DDoS and DRDoS attacks (unless specified otherwise). Victim: the target network, host or hosts of a DoS Attack. Attacker: the initiator of the attack. Intermediary: innocent hosts or networks exploited for the attack.
3 Project objectives
Study the different aspects of DoS & DDoS attacks. Simulate several attacks against a host on the lab network. Study different detection methods. Analyze the reaction of chosen detection methods to the simulated attacks.
4 Project content
4.1 Attack
1. Summarize the main kinds of attacks known today. 2. Identify the main parameters and modes of exploitation used in the various attacks (based on analyzed test cases). 3. Overview the various attack tools available on the internet, and the ability to utilize them in this project. 4. Define the requirements and design of the attack tools necessary for this project.
5. Based on 3 & 4, construct a platform to initiate several modes of attack. Each pair will focus on different kinds of attack methods. 6. Study the possibility to simulate background traffic.
4.2 Detection
1. Summarize the main parameters of detection used. 2. Overview detection tools available on the internet, and the ability to modify them for this project 3. Decide on a detection strategy. 4. Based on 2 & 3, define the requirements and design such a platform and construct it. 5. Test the detection performance of different parameters to several attack modes. Each pair will examine the effectiveness of different detection methods. 6. Analyze the results of the test performed in section 5 and conclude the effectiveness of the detection methods.
4.3 Work Environment

The project will be developed in C/C++ and Java on Linux workstations. The simulation environment will include several workstations interconnected by several routers. A NetAlly server will be used for network diagnostics.
10
5 DDoS background
5.1 What is DoS & DDoS?
A "denial-of-service" (DoS) attack is characterized by an explicit attempt by attackers to deny legitimate users the availability of a service. DoS attacks come in a variety of forms, such as "flooding" a network, disrupting connections between two machines, etc. Generally, the attacks are based on at least one of the following elements: consumption of scarce, limited, or nonrenewable resources and destruction or alteration of configuration information. Such attacks can essentially disable a computer or a network, and effectively an entire organization or company, thus, resulting in disability to provide services, economic damage and loss of data. (19) DDoS is "Distributed-Denial-of-Service" meaning, many "zombie" computers ganging up on one computer (or more), usually directed by one "master", which is controlled by the attacker.
5.2 Brief History & Trends:

DoS attacks started around the early '90s. At the first stage they were quite "primitive", involving only one attacker exploiting maximum bandwidth from the victim, denying others the ability to be served. This was done mainly by using simple methods of ping floods, SYN floods and UDP floods (see details and explanations below). Later, attacks became more sophisticated, by imitating the victim, sending certain messages "on his behalf" and getting other computers to flood the victim with their replies (Smurf attack, IP spoofing etc.). 12.2 These attacks had to be "manually" synchronized by a lot of attackers in order to cause an effective damage. The shift to automating this synchronization, coordination and generating a parallel massive attack became public in 1997, with the release of the first publicly available DDoS attacks tool, Trinoo. It was based on UDP flood attack and master-slave communications (forcing "innocent" computers participate in the attack by planting in them remote-control programs). In the following years, few more tools were published TFN (tribe flood network), TFN2K, and Stacheldraht ("Barbed wire" in German). 12.2 (19)
11
Nevertheless, only from the end of 1999 there are documented reports of such attacks, and the subject came to public awareness only after a massive attack on public sites on February 2000. During a period of three days the sites of Yahoo.com, amazon.com, buy.com, cnn.com & eBay.com where under attack (for example Yahoo was pinged at the rate of one gigabyte/second). It turned out that about fifty computers at Stanford University, and also computers at the University of California at Santa Barbara, were amongst the zombie computers sending pings in these DoS attacks. (20) In the following months other major attacks were held against other widely used sites (commercial & governmental): 1. A study during a period of three weeks in February 2001 showed that there were about 4000 DoS attacks each week. Most DoS attacks are neither publicized in the news media nor prosecuted in courts. (19) 2. May 2001 - hackers overloaded Weather.com routers and those of its Web hosting company with bogus traffic. To counter the attack, weather.com moved to another dedicated router and installed filtering software to protect switches and servers, as well as intrusion detection software to record all ongoing activity. It took the company 7 hours to bring the site back up. (21) 3. May 2001 and January 2002 - two major attacks on grc.com website. These attacks were unique due to the extensive analyze that was done on them by Steve Gibson, one of the owners of the site. He published two detailed articles, describing the evolution of the attacks, the way his team analyzed them and how they got over them (see more details in the chapter that deals with the "case studies"). (22) 4. April 2002 Thousands of computers across the world flooded every major gaming news website with hundreds of requests for a file vaguely named 11081109.exe. The surprise attack brought down most of the major news sites, including Shacknews, Bluesnews, Gamespy, and myriad others. Even non-gaming sites were affected, as major routing points were clogged or shut down from the heavy traffic. (22)
12
5. Some of these attacks were even motivated by political reasons and good examples can be found in the Middle East, were Israeli supporters launched a DDoS attack on the Hezbollah site in September 2000, and on the other hand Palestinian supporters succeeded in "crashing" the official site of the Israeli ministry of foreign affairs for a couple of days, and clogged traffic in some of the main ISPs.
5.3 The Asymmetric Threat

DoS attacks can be executed with limited resources against a large, sophisticated site. For example, an attacker with an old PC and a slow modem may be able to disable much faster and more sophisticated machines or networks. Currently a huge amount of exploitable systems exist with weak security connected to the Internet. The attacks even transcend geography and national boundaries hardening the possibility to deter attackers in legislative initiatives. (25) Moreover, the attack technology is developing in an open-source environment and is evolving rapidly. On the other hand, much of the software written today for different applications is done by inexperienced programmers, and is aimed to "speed" the market, or to enable sophisticated features but not necessarily safety. Many of the "system administrators" are also not well trained. (25) Some good examples may be seen in the fact that an intense FBI investigation after the attacks on yahoo.com, cnn.com (and others see above) on February 2000 led to the arrest of a 15 (!) year old from Canada. The attack on grc.com server (May 2001 see above) was launched by a 13 year old. All of these emphasize the challenges in dealing with DoS attacks, and explain why they are sometimes described as an "asymmetric threat". (19) (22) (25)
13
6 Attacks classification
DoS attacks exploit the asymmetric nature of certain types of network traffic. One attack method seeks to cause the target to use more resources processing traffic than the attacker does sending the traffic. Another method is to control multiple attackers. Therefore DoS attacks can be classified into three categories Bandwidth/Throughput attacks, Protocol attacks and Software Vulnerability Attacks.
6.1 Bandwidth/Throughput Attacks

Bandwidth attacks are intended to overflow and consume resources available to the victim. These resources include network bandwidth between the victim and the internet or equipment throughput (including computer related resources such as memory and CPU). Such high volume attacks can consume all available bandwidth between an ISP and the victim's site. The bandwidth clogs up, and legitimate users find it virtually impossible to receive any kind of service from the site rendering it useless (and the attack in some scenarios may even cause the victim's server to crash). An attacker can consume bandwidth by transmitting any traffic at all on the victim's network connection. Attack traffic can be classified in two separate groups. The first includes connectionless protocol traffic such as IP raw packets, UDP and ICMP which targets primarily the victim's bandwidth capacity. The second group includes all connection oriented protocols (mainly TCP related) which in addition to consuming bandwidth, aims to exploit additional vulnerabilities of network equipment used by the victim (including switches, routers, firewalls etc.). The first group of attacks exploits the throughput limits of servers or network equipment by focusing on high packet rates sending large numbers of small packets which require large processing resources on the victim's side.
14
High-packet-rate attacks typically overwhelm network equipment before the traffic reaches the limit of available bandwidth. For instance routers and firewalls upon reaching their input limits start dumping excess packets due to queue overflow and processing latencies. Servers under great processing stress may even collapse resulting with a general system freeze. In practice, denial of service is often accomplished by high packet rates, not by sheer traffic volume. (1)
6.1.1 Ping Flood Attack (ICMP Echo)

ICMP (Internet Control Message Protocol) is a message control and error-reporting protocol between host servers in the Internet. ICMP is encapsulated by IP datagrams. ICMP includes two commonly used packets: ICMP echo request which conveys an ICMP query (for instance: is the host designated by IP address 1.1.1.1 reachable) and ICMP echo response which is used for providing information (such as the latency from the host that sent an ICMP echo request). Ping Flood is an attempt by an attacker on a high bandwidth connection to saturate a network with ICMP Echo Request packets in order to slow or stop legitimate traffic going through the network.
ICMP echo replies ?
Spoofed ICMP echo requests
Victim host Attack Daemons
ICMP Floods
15
6.1.2 SYN Flood Attack (DoS attack)

The idea behind this attack is to exploit the TCP-Three Way Handshake. Individual TCP packets contain "flag bits" which specify the contents and purpose of each packet. Packets can be marked as either a SYN packet (synchronize) meaning that it is initiating a connection from the sender to the recipient, an ACK packet (acknowledge) that acknowledges the receipt of information from the sender or A FIN packet (finish) terminating the connection from the sender to the recipient. In addition each packet includes source and destination port numbers, IP address of the machine which originated the packet (the Source IP) and the address of the machine to which the Internet's routers will forward the packet (the Destination IP). (3) Since understanding the handshake is necessary for this mode of attack and more advanced types, we will start with presenting a detailed explanation of how the handshake works. 6.1.2.1 TCP-Three Way Handshake The connection initiating SYN packet is usually sent from the client's port, numbered between 1024 and 65535, to the server's port, numbered between 1 and 1023. The port on the Client side is assigned by the operating system. When a connection-requesting SYN packet is received at an "open" TCP service port, the server's operating system replies with a connection-accepting "SYN/ACK" packet. Although TCP connections are bi-directional (full duplex), each direction of the connection is set up and managed independently. For this reason, a TCP server replies to the client's connectionrequesting SYN packet by ACKnowledging the client's packet and sending its own SYN to initiate a connection in the returning direction. These two messages are combined into a single "SYN/ACK" response packet. The SYN/ACK packet is sent to the SYN's sender by exchanging the source and destination IPs from the SYN packet and placing them into the answering SYN/ACK packet. This sets the SYN/ACK packet's destination to the source IP of the SYN, which is exactly what we want. (3) (5) The client's reception of the server's SYN/ACK packet confirms the server's willingness to accept the client's connection. If the server had been unable or unwilling to accept the client's TCP
16
connection, it would have replied with a RST/ACK (Reset Acknowledgement) packet, or an ICMP Port Unreachable packet, to inform the client that its connection request had been denied. The client acknowledges the receipt of the SYN portion of the server's answering SYN/ACK by sending an ACK packet back to the server. At this point, from the client's perspective, a new twoway TCP connection has been established between the client and server, and data may now freely flow in either direction between the two TCP endpoints. The server's reception of the client's ACK packet confirms to the server that its SYN/ACK packet was able to return to the client across the Internet's packet routing system. At this point, the server considers that a new two-way TCP connection has been established between the client and server and data may now flow freely in either direction between the two TCP endpoints. The server's receipt of a client's SYN packet causes the server to prepare for a connection. It typically allocates memory buffers for sending and receiving the connection's data, and it records the various details of the client's connection including the client's remote IP and connection port number. In this way, the server will be prepared to accept the client's final connection-opening ACK packet. Also, if the client's ACK packet should fail to arrive, the server will be able to resend its SYN/ACK packet, presuming that it might have been lost or dropped by an intermediate Internet router. (3) (4) (5) 6.1.2.2 Exploiting the TCP-Three Way Handshake Every time a handshake is initiated, memory and other significant server "connection resources" are allocated as a consequence of the receipt of a single Internet "SYN" packet. Obviously, there is a limit to the number of "half open" connections a TCP server could handle, and therefore with simple means this limit may be exceeded. The method used by SYN Flood Attacks is creating SYN packets with deliberately fraudulent (spoofed) IP return addresses. By flooding the victim with a flood of SYN packets that seem to be indifferent from valid requests, the victims server will allocate all the resources mentioned above and reply with an ACK/SYN packet to the Source IP. Since this IP was spoofed, at most cases the ACK/SYN packet will be discarded. Since the server does not know that the original SYN packet was fraudulent, it will wait and resend the ACK/SYN packet several more times until giving up. (3) (4)
17
All of this connection management consumes valuable and limited resources in the server. Meanwhile, the attacking TCP client continues firing additional fraudulent SYN packets at the server, forcing it to accumulate a continuously growing pool of incomplete connections. At some point, the server will be unable to accommodate any more "half-open" connections and even valid connections will fail, since the server's ability to accept any connections will have been maliciously consumed. At this point any legitimate sessions find it extremely difficult to be established with the victims server. (3) (5) It is important to mention that this method of attack is mainly a throughput attack depleting the systems resources. In addition, large quantities of SYN packets can also act as a Bandwidth consumption attack, causing even further damage to the quality of service given to legitimate users. This method has evolved into more complex modes of attack (see DRDoS in 6.1.4) that require new and unique detection & protection methods (3)
Normal TCP Handshake
TCP Handshake During SYN Attack
TCP 3-way handshake and SYN attack. (Taken from (23))
18
6.1.3 DDoS attack (Distributed SYN Flood)

This attack is a natural development from the SYN Flood mentioned above. The idea behind this attack is focusing Internet connection bandwidth of many machines upon one or a few machines. This way it is possible to use a large array of smaller (or weaker) widely distributed computers to create the big flood effect. Usually, the assailant installs his remote attack program on weakly protected computers (Universities, home users constantly connected etc.) using Trojan horses and intrusion methods, and then orchestrates the attack from all the different computers at once. This creates a brute force flood of malicious "nonsense" Internet traffic to swamp and consume the target server's or its network connection bandwidth. This malicious packet flood competes with, and overwhelms, the network's valid traffic so that "good packets" have a low likelihood of surviving the flood. The network's servers become cut off from the rest of the Internet, and their service is denied. (6)(3)
6.1.4 Distributed Reflected Denial of Service (DRDoS) attack

To enhance the previous methods a reflective method of attack was generated. Instead of sending directly TCP packets with spoofed Source IP addresses to the Victim, An attacker located somewhere else on the Internet, might SYN flood internet routers with TCP connectionrequesting SYN packets. Those SYN packets carry the fraudulent (spoofed) source IP belonging to the victim. Therefore, the routers believe that the SYN packets were coming from the victim, and they reply with SYN/ACK packets as the second phase of the standard TCP three-way connection handshake. This way, the victim sees an attack from a wide array of core infrastructure servers (instead of many small computers around the globe). (3) Some variations of this attack take advantage of BGP (Border Gate Protocol). This protocol is supported by intermediate routers. Routers use BGP to communicate with their immediate neighbors to exchange their "routing tables" in order to inform each other about which IP ranges the router can forward. The specific details of BGP are unimportant. The fact that virtually all of the Internet's extremely well-connected (high bandwidth) intermediate routers will accept TCP connections on their port 179 (BGP port) means a SYN packet arriving at port 179 of an Internet
19
router will elicit a responding SYN/ACK packet. This example indicates the type of network assets the assailant may use for his cause. (3)
Distributed Reflected Denial of Service (Taken from (3))
6.1.5 Naptha
Naptha is a name used to describe a set of network DoS vulnerabilities. Naptha attacks exploit weaknesses in the way some TCP stacks and applications handle large numbers of connections in states other than "SYN RECVD", including "ESTABLISHED" and "FIN WAIT-1". By creating a suitably large number of TCP connections and leaving them in certain states, individual applications or the operating system itself can be starved of resources to the point of failure. In the past, attacks that would exploit TCP connections in this manner have not been implemented because they would typically exhaust the resources of the attacker as well. The innovation provided by the Naptha attack is that it is possible to easily create a DoS attack on the target with little resource consumption on the part of the attacker. (7)(8)
20
The first part sends out a sequence of SYN packets from all possible ports of a forged IP address to the victim. This sounds like a SYN flood, but more happens. The second half runs on a LAN where the forged IP address would be, if it were a real host. The program first makes sure that the router has an entry for this phantom host in its ARP table. Next, it listens for a packet from the victim to the phantom host. The program responds with a packet with the appropriate flags and sequence numbers. Typically, it listens for SYN/ACK packets and replies with an ACK. It could also set the FIN flag and leave the connection waiting for a FIN-WAIT-1 packet. To keep connections alive longer, it can listen for 'regular' data packets or 'keep alive' packets and send ACK in reply. This 'phantom' nature makes it hard to track down and eliminate as it is almost impossible to discriminate between a bogus connection and valid one.(7)
6.1.6 UDP Flood Attacks

UDP protocol is a connectionless unreliable protocol which doesn't require session negotiation between client and server application. UDP provides easy to use interface for producing large quantity of packets. A common attack which exploits UDP simply floods the network with UDP packets destined to a victim's host. Due to the relative simplicity of this protocol an attacker can produce large bandwidth capacity with relatively small effort. (17)
6.2 Protocol Attacks

The basic flood attack can be further refined to take advantage of the inherent design of commonly used network protocols including TCP, UDP, ICMP and applications protocol such as BGP, DNS, HTTP and others. These attacks do not directly exploit weaknesses in these protocols but, instead, use their expected behavior to the attackers advantage, resulting in a bandwidth attack. (1)
6.2.1 Smurf Attack

The Internet Control Message Protocol (ICMP) is used to handle errors and exchange control messages. ICMP can be used to determine if a machine on the Internet is responding. To do this,
21
an ICMP echo request packet is sent to a host. If a host receives that packet, that host will return an ICMP echo reply packet. A common implementation of this process is the "ping" application. In this attack, spoofed IP packets containing ICMP Echo-Request with a source address equal to that of the attacked system and a broadcast destination address are sent to the intermediate network. Broadcast addresses are specially allocated addresses within all network subnets, used to broadcast messages to the whole network. All hosts within a given subnet receive packets sent to these broadcast addresses and in some cases (ICMP protocol for instance) respond to them. Sending a ICMP Echo Request to a broadcast address triggers all hosts included in the network to respond with an ICMP response packet, thus creating a large mass of packets which are routed to the victim's spoofed address. Networks may include up to hundreds of hosts, thus one attack echo request results in hundreds of flooding packets at the victim's site. (8)
6.2.2 DNS name server Attack

The most common method seen involves an intruder sending a large number of UDP-based DNS requests to a nameserver using a spoofed source IP address. Any nameserver response is sent back to the spoofed IP address as the destination. In this scenario, the spoofed IP address represents the victim of the denial of service attack. The nameserver is an intermediate party in the attack. The true source of the attack is difficult for an intermediate or a victim site to determine due to the use of spoofed source addresses. (10) Since nameserver responses can be significantly larger than DNS requests this is an opportunity for bandwidth amplification. The queries are usually crafted to request the same valid DNS resource record from multiple nameservers. The result is many nameservers receiving queries for resources records in zones for which the nameserver is not authoritative. The response of the nameserver depends on it's configuration.(10)
22
6.3 Software Vulnerability Attacks

Unlike previously mentioned attack strategies, this group of attacks attempts to send a crippling blow to the victim's Achilles heel. This is accomplished not by brute force of mass traffic, but with a well designed attack, usually considerably less traffic than flood attacks. Most of these attacks exploit inherited weaknesses in network software implementations. For example, IP fragmented packets reassembly can deal with an orderly set of fragmented packets as long as the offsets and size of the packet's payload are aligned. In cases where fragments are overlapping or missing, in some TCP/IP stack implementations this may cause a system failure (for details see below). (1)
6.3.1 Land Attack

In this attack, an attacker sends spoofed TCP SYN packets, with the same source and destination addresses as the victim's host address. In some TCP/IP stack implementations those kinds of packets may cause the victim's host to crash. In cases where the victim's host is a router, this attack may result in a routing loop consuming large quantities of bandwidth (unless filtered in advance). One of the variations of this attack targets a certain TCP service provided by the victim. In this case the attacker uses the same source and destination ports which used by the victim's service (for instance an attack on the victim's web server will probably use TCP port 80). This may consume the victim's host CPU resources. (11) (12) (13)
6.3.2 Ping of Death Attack

Ping of Death is an attempt by an attacker to crash, reboot or freeze a system by sending an illegal ICMP (over IP) packet to the host under attack. The TCP/IP specification allows for a maximum packet size of up to 65536 octets (1 octet = 8 bits of data). In some TCP stack implementation encountering packets of greater size may cause the victim's host to crash.
23
Most implementations of the ICMP protocol use packet header size of 8 octets but allow the user to specify larger packet header sizes. In the attack, the ICMP packet is sent in the form of a fragmented message which, when reassembled is larger than the maximum legal IP packet size. (14) (15)
6.3.3 Fragmentation Attack and Teardrop Attack

TCP/IP protocol allows IP packets to contain up to 65536 octets. Most line protocols (such as Cisco's HDLC, PPP, Ethernet etc.) which are used for encapsulating these packets limit data units length to up to 4470-5000 octets (also referred to MTU Maximum transfer unit). In order to send large IP packets over limited line protocols the IP stack divides them to smaller fragments. The reconstruction of these fragments is performed according to IP packet header fields such as fragment offset, packet ID and header flags. All the fragments of the same IP packet carry the same packet ID field and the flag "Fragmentedpacket" (one of the header's flags) on. The first fragment is sent with offset 0 and the flag "More-fragments" (one of the header's flags) is turned on. The next fragments are sent with the offset field containing the sum of all previously sent fragments lengths. The last fragment's "More-fragments" flag is unset (turned off). Some TCP/IP stack IP fragmentation re-assembly code improperly handles overlapping IP fragments. Teardrop (also known as bonk, boink, teardrop2) attack exploits this bug and sends a series of fragments with overlapping sections. This attack may cause some systems to crash or freeze. (1) (12) Other Fragmentation attacks exploit other illegal combinations of fragments configuration which prevents the target host from successfully reconstructing the packets. For instance, the attacker sends series of fragments without sending a closing fragment (containing the "More-Fragments" flag turned off) thus overloading the victim's host IP packets reconstruction queue with pending packets. In some systems the attack may result in a system
24
hold due to resources starvation. The same effect is achieved by sending many unmatched noninitial IP fragments. (16)
25
7 Attack Tools
7.1 General Description
During the last few years, in their increasing effort to raise havoc, the world wide community of hackers (also known as "crackers") started developing attack platforms for lunching global Internet scale coordinated DDoS attacks. Most of these tools were designed using client-server (master and slave) architecture. The attack network consists of large quantities of attack daemons, small software agents, capable of receiving command and generating different kind of packets (usually simulating some sort of attack). Those daemons are centrally controlled by a single or few master applications, servers capable of generating the required attack commands thus controlling the attack and the targets. (26) (27) The attacker can use the server application to order the attack.
7.2 Command Distribution Methods

7.2.1 Peer to Peer Distribution
In this architecture the master is aware (has knowledge) of all available daemons. Either through lists of infected intermediate hosts constructed and administrated by hackers which installed them or by "keep alive" messages sent by the daemons upon installation to a predefined location. When distributing an attack command the master connects all the required daemons by sending them command packets.
7.2.2 Broadcast or Multicast Distribution

In this architecture the master uses some sort of broadcast mechanism to connect and distribute attack commands.
26
Due to broadcast packets filtering done by edge and core routers the most popular method for broadcasting commands is using an application based protocol which provides multicast features, such as IRC protocol (used mainly for chat applications). In this case when the intermediate host connects to the Internet and becomes on line. The daemon connects to a predefined IRC channel. The attacker then can connect to the IRC channel using some sort of chat application and simply type the necessary commands. IRC protocol takes the commands and distributes it to all the connected daemons.
7.3 Frequently Used Attack Tools

7.3.1 Trinoo
This distributed attack tool is installed on intermediate host using a buffer overrun bug in the popular programs: "statd", "cmsd" and others. The daemon's code was compiled on Linux and Solaris operating systems. The daemons and masters are installed on root accounts privileges. The basic Trinoo daemon is capable of generating a UDP packets attack. The following packets parameters are controllable: destination address, packets sizes, attack duration. The attack is generated against random UDP ports on the victim's host. The contents of the packets are randomly generated from the intermediary host memory, thus packets sent from a certain daemon will have the same payload but different daemons generate different payloads. The daemon is cable of attacking multiple targets at once. (28)(29)(30)
7.3.2 TFN (Tribe Flood Network)

TFN installation procedure is similar to that of Trinoo and is based on buffer overrun bug. These tools use the same master-daemon architecture, and are capable of launching ICMP floods, UDP floods, SYN attacks, Smurf attacks and a raw TCP packet generator. The daemon's source code was compiled on Linux and Solaris operating systems. The daemons and masters are installed on root accounts privileges. Commands used by TFN are over ICMP protocol packets using fixed packet length (17 bytes). (31) (32)
27
7.3.3 Stacheldraht ("barbed wire")

Stacheldraht is a DDoS tool that started to appear in the late summer of 1999 and combines features of Trinoo and TFN. The possible attacks generated by the daemons of this tool are similar to those of TFN, namely, ICMP flood, SYN flood, UDP flood, and SMURF attacks. It does not provide an on demand root TCP port (that TFN provides). Stacheldraht also provides some advanced features, such as encrypted attacker-master communication (which makes detection and overtaking of daemon-master communication harder) and automated daemons updates which enables changes of the attack network with no redeployment of daemon or masters. Stacheldraht daemon is capable of producing ICMP, UDP and TCP-SYN packets of sizes up to 1024 bytes against multiple victim hosts. TCP-SYN packets are generated against random ports taken from selected range of port numbers. (33)
7.3.4 Trinity
Trinity is capable of launching several types of flooding attacks on a victim host, including UDP, fragmentation, SYN, RST, ACK, and other floods. Communication from the master to the daemon is accomplished via Internet Relay Chat (IRC) or AOL's ICQ. IRC attack daemon (including Trinity) will go online by connecting to a predefined IRC server and join a predefined IRC chat room. There it will await incoming commands. IRC chat relays are used in this matter to broadcast and distribute attack commands. The following attack parameters are controllable: packet size (possibly random), ports (possibly random). (34)(35) (36)
7.3.5 TFN2K
TFN2K is a complex variant of the original TFN with features designed specifically to make TFN2K traffic difficult to recognize and filter, remotely execute commands, hide the true source of the attack using IP address spoofing, and transport TFN2K traffic over multiple transport protocols including UDP, TCP, and ICMP.
28
TFN2K attacks include flooding (as in TFN) and those designed to crash or introduce instabilities in systems by sending malformed or invalid packets, such as those found in the Teardrop and Land attacks. Commands sent between masters and daemons are sent using UDP, ICMP and TCP (or all three in random). TFN2K generated traffic includes the following signatures: TCP and UDP header checksum contains errors. (37)
7.3.6 Shaft
A Shaft network looks conceptually similar to a Trinoo. It provides the ability to generate TCP, UDP and ICMP (or all three combined) floods. The attacker may control the following parameters: packet sizes, attack type, duration of the attack, list of targeted victims. Shaft daemons also provide statistics on the attack (mainly packets generation rates) which enables the master to refine the list of targets. (38)(39)
7.3.7 MStream
The MStream uses spoofed TCP packets with the ACK flag set to attack the target. Communication between masters and daemons is not encrypted and is performed through UDP packets, masters are controlled by TCP packets. MStream is in early stages of development, which means it can be used for generating a limited number of attacks. The following attack parameters are controllable: victims IP addresses, duration of the attack. (31)
29
8 Test Cases
8.1 The attack on grc.com site May 2001
(Based on a report by Steve Gibson) The grc.com site was under few attacks in May 2001. These attacks were documented and analyzed in details by Steve Gibson, Gibson Research Corporation (GRC). Below, there is a short description of the attacks and data that is relevant to our research. (1) The first attack began on the evening of May 4th and quite immediately caused grc.com to drop of the Internet. A quick check showed that both of the T1 trunk interfaces to the Internet were flooded at their maximum rate of 1.54 megabit per second by packets that were received, and the outbound traffic had fallen to nearly zero, presumably because valid inbound traffic was no longer able to reach our server. (GRC is connected to the Internet by a pair of T1 trunks that are connected to an ISP Cisco router. They provide a total of 3.08 megabits of bandwidth in each direction - 1.54 megabits each). Steve Gibson immediately started logging all the traffic coming into the server. Analyzing the data revealed that the attack came from 474 windows PC's (see note below) 1 via a long list of known ISPs and consisted of: Huge UDP packets aimed at the bogus port "666" of grc.com that were fragmented into a blizzard of millions of 1500-byte IP packets.
1
ICMP debris from large-packet ping commands.
It was clear to Gibson, That to the attacking machines were Windows PC's, since it didn't
consist of TCP SYN packets to port 80 as well (the use of "raw sockets" was possible only in UNIX based systems, until recently, when Windows XP was released). Such an attack would have "crippled" GRC totally, and the lack of use of that method indicated that the attack came from PC's.
30
It's important to note that the local router and firewall were able to analyze and discard the malicious traffic, but all the bandwidth of the connection to the Internet was consumed effectively dropping the site down. It took about 17 hours until grc.com site was back on the Internet and that only due to "brute force" filters that were configured in the ISP router - filtering out all UDP and ICMP traffic. This enabled grc.com to give service to "legitimate" clients, although it was still under heavy attack (now blocked in the server's router). The server was attacked again on May 13 th, in an identical way to the first attack (even from the same windows machines). Using the same filters, grc.com was "back" after 8 hours. A third attack took place on May 14th. While the ISP router was still blocking the "previous nonsense" to grc.com server, the "new" attack consisted of two stages: 1. Huge amount of packets targeted at the IP of GRC's firewall. So the malicious traffic was again crossing the T1's and knocked GRC off the Internet. This was fixed by changing the router's filter to block the firewall's IP address as well, and grc.com went back onto the Internet. 2. Two hours later the attack resumed, and in this stage packets were aimed at one of the two T1 interfaces of the Cisco router. This again knocked GRC off the Internet. This time it was decided to defend against the attack by completely shut down that T1. And indeed GRC.COM went back onto the Internet running on a single T1. The 4th attack happened the day after and lasted 6.5 hours, in which grc.com was off the Internet. This time GRC and the ISP couldn't filter out the malicious traffic (due to bugs, later discovered in Cisco routing software) and the attack ended only by it self. However, during the night the bugs in the router's software were found and fixed, so when the 5 th attack happened on the 16th GRC people were ready. They afterwards estimated that during that day 538,916,268 malicious packets were filtered by the ISP router (almost all of them - UDP maximum-size packets aimed to port 666). In the overall, on the following days, between May 16 th and the morning of the 21st the ISP router filtered out 2.4 billion malicious packets (again -"UDP/666")! But it was clear that grc.com couldn't keep working forever with the filters inserted to the router. They were unable to send and receive "ping", "trace route" and UDP fragments. A 13 years old
31
kid (that calls himself "Wicked") claimed responsibility on the attacks by an email sent to Gibson. Seeking for help in order to defend his site, Gibson called the FBI and different ISPs related to the computers that were involved in the attacks, but none of these were able\willing to help. He therefore, entered sites and chats "popular" in the "hackers' community" and succeeded in learning about the methods those "attackers" are spread (via IRC) and act. After "spying" for a while on hackers' "private" chats, he introduced himself to them in a certain stage, hinting that he's got full information about their actions in the previous days. He "persuaded" them to instruct "Wicked" to stop attacking his site- and "bought" himself quiet for few months. (40)
32
8.2 DoS Attack on a Check Point Firewall.

(Based on an article by David M. Wilson, published by SANS on Sep. 8th, 2000.) While this is not the classic case of a DoS attack studied in this project, as the victim is not an Internet site or server but a Firewall, it is still a relevant test case since it gives examples of some very characteristic properties.
8.2.1 Detection
At 23:43 around the beginning of year 2000 the Firewall stopped responding to ping packets sent to it by a monitoring system. The monitoring system, using a package called WhatsUp that polls various critical routers and servers of the system, immediately informed the supervising engineer, who found the Firewall server was experiencing malloc errors because the /tmp file system was 100% full. The Check Point Firewall is a system located on the entrance to the local network and is supposed to check every packet against a list of rules (the rule base) defining legal packets, and rejecting illegal ones. After describing the analysis done on the morning after, an explanation of the problem is given in detail.
8.2.2 Post mortem

On the morning after the attack, the firewall log files were examined, showing that up until 23:40 everything was just fine. Right after that there was what looked like a port scan of a particular IP on the local network, starting with port 1 all the way to port 8000 with all source IPs seeming to be random. An average of 25-60 packets per second went up to 500-1100 packets per second. All together 25,266 ports were scanned, 21,680 packets were accepted most of them TCP (a few ICMP) all from different IP sources, only 3500 packets were rejected by the rule base implemented by the firewall (mostly the ones directed at privileged ports) and after 6 minutes the firewall died.
33
8.2.3 What happened?

This was a classic case of exploiting a specific algorithm used by the server to clog up the memory resources of the victim. The way the Firewall is supposed to work is this: whenever a SYN packed is received, its run against the rule base to decide whether its OK. If it fails, a RST message is sent to the source host terminating the connection. If the SYN packet is accepted, it is entered to the connection table, a timeout is set to 60 seconds for the ACK, and all subsequent packets of the originating source are not processed by the rule base, but rather compared to the connection table. By this action, valuable time is saved on all the following packets that belong to the established connection. BUT here is the bug: if an ACK packet arrives with no corresponding entry in the connection table, it is run against the rule table just like a SYN and, if passes, its entered to the connection table with a slight difference. The timeout is now set to 3600 seconds (1 hour!), expecting this to be a normal connection that already passed the three-way handshake. Now all thats needed is a few hundred ACK packets from different IPs and very soon the memory allocated for the connection table is all gone! Solutions to this problem could be better rule bases, shorter timeouts for established connections, not to mention a patch that was published by Check Point.
34
Attack
35
9 Attack Platform Requirements Review

9.1 General
The attack platform is intended to provide a test bench for simulating attack and normal network traffic in the lab. Using the attack platform we will test the target's host vulnerability and durability and the effectiveness of the detection mechanism The attack platform consists of the following components: 1. Attack Generators: a set of software daemons that creates the required traffic streams for simulating several attack methods. 2. Attack Trigger: a general mechanism for issuing a centralized attack command to all the participating attack generators. 3. Synchronizer: a global mechanism which provides a clocking signal enabling synchronization between all system components. 4. Background Traffic Generation: simulating normal network traffic including TCP packets or HTTP requests. 5. Performance Bench marker: a simulated real world web client (some sort of simulated browser) which is able to grade the victim's performance.
9.2 Details
9.2.1 Attack Generator
The generator will be used to simulate different attack methods creating large attack bandwidth volumes. The attack network will consist of several generators controlled by a common attack trigger. The communication connection between the daemons and the attack trigger will be over some predefined protocol, such as: TCP or UDP.
36
The generator will provide the following traffic generation capabilities: 1. ICMP flooding: ICMP echo requests or replies (Ping or Smurf attacks). 2. UDP flooding: UDP packets of different lengths. 3. TCP packets: TCP SYN, SYN/ACK, ACK or RST packets. The generator will provide configurable parameters for controlling different attack traffic aspects, such as: Packet Sizes, Ports, Addresses and TCP Protocol header fields (for instance the SYN and ACK flags). IP spoofing will also be simulated. During attack simulation the generator will log detailed information about the packets generated. The attack log will include the following parameters: send timestamp, source addresses, ports, attack method, packet payload protocol type.
9.2.2 Attack Trigger

This component will be used simultaneously activating the attack generators. The attack trigger will issue the required commands to the generators and upon attack completion (or termination) the trigger will be used for gathering the attack logs and joining them together. The possibility to create a GUI for the trigger will be evaluated.
9.2.3 Synchronizer
In order to combine all the logs created by the system's generators a central clock synchronizer will be required. The synchronizer will work as a server, receiving requests and providing clock readings. All system components which require synchronization will issue requests for clock reading from the central clock unit. Timestamps logged will be calculated using the global time reading as a constant reference (delta).
37
9.2.4 Background Traffic Generation

In order to simulate a "real world" testing environment for the test bench, background traffic will have to be simulated thus creating a difference between attack related streams and normal users traffic. Background streams will have to include TCP, UDP and ICMP packets of different sizes with relative quantities simulating normal traffic distribution, thus creating some kind of background traffic routine.
9.2.5 Performance Bench Marker

In order to evaluate the efficiency of simulated attacks we will benchmark the victim's web server performance. The bench marker will simulate normal web browsers by sending standard HTTP requests and receiving HTTP responses. The following performance parameters will be evaluated: 1. Service latency: period of time sending the request until receiving the complete response. 2. Service throughput: opened session per minute, number of packets and bits received per minute. 3. Number of requests needed to receive the response. All performance measurements will be logged with a synchronized timestamp.
9.3 Simulation Environment

The simulation environment will consist of a few attack hosts (installed with Linux OS) connected via a router to the victim's host. One of these hosts will include the attack trigger and the synchronizer. The victim's host will be installed with Linux OS and standard Web Server. The bench marker will be installed separately from the victim's host, on a dedicated computer or on one of the attack hosts.
38
Simulation Topology
Simulated background traffic
Simulated Attack Traffic
Victim Host
39
10 TFN2K Structure overview

10.1 General
TFN2K is an attack tool developed by 'Mixter' which provides flooding capabilities as well as encrypted command transfer mechanism between the different system parts. TFN2K allows the user to exploit the resources of many other computers (referred to as 'agents') in order to coordinate an attack against one or more designated targets. The master can issue commands to all known agents or to choose individual ones. TFN2K is a two-component system: a command driven client on the master and a daemon process operating on an agent. The master instructs its agents to attack a list of designated targets. The agents respond by flooding the targets with a barrage of packets. Multiple agents, coordinated by the master, can work in tandem during this attack to disrupt access to the target. Master-to-agent communications are encrypted, and may be intermixed with any number of decoy packets. Both master-to-agent communications and the attacks themselves can be sent via randomized TCP, UDP, and ICMP packets. Additionally, the master can falsify its IP address (spoof), using Raw Socket capabilities.
10.2 The client ("the master")

The client is command driven, and can receive various inputs (in different commands) regarding the attack. The client immediately fills out each command, and has no memory of previous commands or the current status of the agents. Therefore in order to initiate an attack with specific parameters, there is a need for several messages to be issued from the client to each agent participating in the attack. Each message will include different parameters to be set, and the last message will initiate the attack. All the system parameters have initially set values, so there is no necessity to reset them before starting the attack, unless readjustment is requested. The connection between the master and the daemons is not a regular client-server connection. The daemons do not acknowledge receiving packets and the master must assume that his
40
command reached the daemon. In order to assure the safe arrival of the command, the master sends each command several times to each daemon. Following is a list of the main inputs the client accepts through the command line: 1. Set protocol for communication between master and agents (ICMP, UDP, TCP). 2. Number of decoy requests sent out with each real request. 3. Set spoof level. 4. List of targets to attack. 5. List of hosts with TFN2K agents. 6. Packet size. 7. Initiate UDP flood 8. Initiate TCP/SYN flood. 9. Initiate ICMP/Ping flood. 10. Initiate ICMP/Smurf flood. 11. Initiate Mix flood. 12. Halt all flooding. More parameters are open to change, but these are the main ones.
10.3 The agent ("the daemon")

This part of the program is installed on many computers. It constantly monitors incoming commands from the master and acts according to them. As mentioned before, to decrease the programs footprint, the daemon does not respond to received messages. In addition, the daemon attempts to disguise itself by altering the contents of argv[0], thereby changing the process name on some platforms. The falsified process names are defined at compile time and may vary from one installation to the next. This allows TFN2K to masquerade as a normal process on the agent. Consequently, the daemon (and its children) may not be readily visible by simple inspection of the process list.
41
When initiating an attack, the daemon spawns a child process (using the fork command) for each attack against a target. Each daemon has an upper range set for the max number of children. Packets originating from the daemon are spoofed. The spoof level is set according to the commands from the master.
42
11 Features added to TFN2K

To enable use of the TFN2K as an academic attack tool, we made several modifications which enable better analysis of the tools behavior and of the attack generated. The modifications are: 1. New (and modified) commands. 2. A logging system. 3. Synchronization tool. 4. Correcting built in mistakes that created unique (and illegal) packets.
11.1 New commands

One new command was added to the original code (set sleep time) and one command was adjusted (packet size).
11.1.1
Packet size
In the old version, the user could choose the size of the attacking packets. In order to allow more flexibility and real life simulation, we upgraded this command to allow setting an initial packet size and an additional range in which random size packets will be created. Thus, the new command format is: -c 2 -i <min pckt size in bytes> -z <size range in bytes> where the packet size will be generated randomly between the values <min pckt size in
bytes>
and
(<min pckt size in bytes> + <size range in bytes> )
using a random
function. Both values are initially set to '0'.
11.1.2
Sleep time
Real attacks tend to build up at the victims computer within a relatively short period. Since our simulation network is quite small and latency times are short we chose to enable the possibility of
43
artificially creating this slow build up (and not a one stage flood) at the target computer. Once the Daemons get the attack command, they do not immediately commence attack at full force but increase the packet release rate at an exponential rate until reaching full throttle.
Change in sleep time
120000 100000 microsec 80000 60000 40000 20000 0 17 16 15 14 13 12 11 10 9 Steps 8 7 6 5 4 3 2 1
The simple algorithm used takes a value given by the user (sleep time in micro sec's). After sending a packet the Daemon hibernates for a short time (according to this value), divides the value by 2 and then goes through the process again until reaching a stage when no sleep is initiated. The command format is: -c 2 -t <sleep time>
11.2 Logging system

The logging system was added in order to enable better analysis of attacks that have ended. The Modus operandi is that each daemon does continuous logging during the attack, and when the attack ends, the files from all the daemons are unified to enable statistics and in depth study of what had been sent to the victim. The daemons write the data to a file in binary mode in order to shorten as much as possible the writing time. After the attack ends, the daemon goes over the file, and revises it updating the time to the synchronized system time using the synchronization tool and changing the file to a comfortable excel (csv) format.
44
Each daemon saves the following data about every packet sent: 1. Exact time packet was sent ("Attack time") 2. Source IP and port 3. Destination IP and port 4. Packet size (including IP header) 5. TCP flags, sequence and ack. For more detailed information see the documentation in logger.h and logger.c files.
11.3 Synchronization tool

The synchronization tool (here on called "sync server") is a client server application which provides tools for retrieving central time reading in the resolution of msecs and calculating time difference between local time and server time. The sync server uses the time.h timing system library provided by Linux and TCP sockets for transporting the central time from the sync server to the client software. We use the function ftime() for reading the time including msec.
11.3.1
Sync Server
The sync server is a multi threaded application. It creates three kinds of threads: 1. Main Thread: this thread is created upon server startup. It provides a management prompt for passing commands to the server (such as: "quit"). This thread creates a single accept thread. 2. Accept Thread: this thread is created by the main thread and is used for listening to the server port. When a client connects to the server a new TCP socket is returned and is passed to a new handle thread which provides the necessary service to the client. When the handle thread was created the accept thread is ready to accept other client connections thus enabling several clients to receive service at the same time.
45
3. Handle Thread: a thread of this type is created for each client connection. This thread sends the content of a struct timeb, including seconds since 1.1.1970 (as defined by the UTC standard) and number of msec, received by a call to the function ftime() performed in server. When the data was successfully transmitted to the sync client the socket is closed and the thread returns.
Sync Server Main Thread Handle Thread Creates Close Accept Thread Creates and
Sync Client Library
Time- msec resolution
11.3.2
Sync Client
This is a library of utility functions which provides the required services for passing time information from the server to the calling client. The library provides the following functions:
void get_sync_time (char *sync_srv_IP, char *sync_srv_port, struct timeb *time_out); This function connects to the sync server at IP sync_srv_IP and recieves time data that is inserted into 'time_out'. The data includes the time (secs from the year 1970), millisecs, time zone etc. void get_time_diff(char *sync_srv_IP, char *sync_srv_port, int *p_diff_millitm, long *p_diff_time);
46
The function checks the difference between the local time and the server time. The resolution is msecs and it is updated in p_diff_time.
47
void convert_time(struct timeb time, int diff_millitm, long diff_time, char *out_time, char *str_time); The function changes local time to the syncronized system time, using the local time and the time difference calculated in the 'get_time_diff' function.
11.4 Corrections to original TFN2K

The open source TFN2K was created with built in mistakes in order to enable easy blocking of any malicious attacks instigated with this code. Most of the mistakes were inserted into specific fields in the IP header which are easily noticeable. Since in this project we are trying to gain better understanding of attack characteristics, we find it important that all the packet fields will be correct. Therefore, we made necessary modifications to correct these errors. In order not to enable malicious users to take advantage of these changes, we will not specify the modifications done.
48
12 References
12.1 Attack Methods
(1) Managing the Threat of Denial-of-Service Attacks, CERT Coordination Center
http://www.cert.org/archive/pdf/Managing_DoS.pdf (2) CERT Advisory CA-1997-28 IP Denial-of-Service Attacks
http://www.cert.org/advisories/CA-1997-28.html (3) (4) (5) DRDoS - Distributed Reflection Denial of Service http://grc.com/dos/drdos.htm Denial of Service Attack Threat Analyzed http://www.uksecurityonline.com/threat/dos.php Microsoft Knowledge Base Article - Q172983 - Explanation of the Three-Way Handshake via
TCP/IP http://support.microsoft.com/default.aspx?scid=KB;EN-US;Q172983&LN=EN-US (6) The Strange Tale of the Denial Of Service Attacks Against GRC.COM
http://grc.com/dos/grcdos.htm (7) Razor - The Naptha DoS vulnerabilities
http://razor.bindview.com/publish/advisories/adv_NAPTHA.html (8) CERT Advisory CA-2000-21 Denial-of-Service Vulnerabilities in TCP/IP Stacks
http://www.cert.org/advisories/CA-2000-21.html (9) CERT Advisory CA-1998-01 Smurf IP Denial-of-Service Attacks
http://www.cert.org/advisories/CA-1998-01.html
49
(10) Denial of Service Attacks using Nameservers http://www.cert.org/incident_notes/IN-200004.html (11) CERT Advisory CA-1996-21 TCP SYN Flooding and IP Spoofing Attacks http://www.cert.org/advisories/CA-1996-21.html (12) CERT Advisory CA-1997-28 IP Denial-of-Service Attacks http://www.cert.org/advisories/CA-1997-28.html (13) CERT advisory CA-1998-13: Vulnerability in Certain TCP/IP Implementations http://www.cert.org/advisories/CA -1998-13.html (14) Sans Institute - How can attacker use ICMP for reconnaissance? http://www.sans.org/newlook/resources/IDFAQ/ICMP_misuse.htm (15) CERT Advisory CA-1996-26 Denial-of-Service Attack via ping http://www.cert.org/advisories/CA-1996-26.html (16) Security Info Online, CI-98.03: Cisco PIX and CBAC Fragmentation Attack http://online.securityfocus.com/advisories/1428 (17) CERT Advisory CA-1996-01 UDP Port Denial-of-Service Attack http://www.cert.org/advisories/CA-1996-01.html
12.2 Background and History

(18) Slides of history from early 90' (tools and trends). http://www.uniforum.chi.il.us/slides/ddos/sld001.htm (19) CERT Coordination Center, Denial of Service Attacks http://www.cert.org/tech_tIPs/denial_of_service.html
50
(20) Computer Crime, Ronald B. Standler http://www.rbs2.com/ccrime.htm#anchor111666 Yahoo, Amazon attack. (21) Weather-com story http://www.techweb.com/wire/story/TWB20010524S0010 (22) Valve Launches Largest DDoS In History By Kevin Weiser http://www.themushroom.com/humor/valvedos.html (23) Distributed Reflection Denial of Service, Steve Gibson, http://grc.com/files/drdos.pdf (24) DDoS: Chronology, Mazu Networks http://www.mazunetworks.com/ddos_library/chronology.html (25) SANS Institute, Consensus Roadmap for Defeating Distributed Denial of Service Attacks http://www.sans.org/ddos_roadmap.htm#1
12.3 Attack Tools

(26) CERT Incident Note IN-99-07 - Distributed Denial of Service Tools http://www.cert.org/incident_notes/IN-99-07.html (27) CERT Advisory CA-1996-01 UDP Port Denial-of-Service Attack http://www.cert.org/advisories/CA-1996-01.html
12.3.1
Trinoo and TFN
(28) The DoS Project's "Trinoo" distributed denial of service attack tool, David Dittrich University of Washington http://staff.washington.edu/dittrich/misc/trinoo.analysis.txt
51
(29) National Infrastructure Protection Center - TRINOO/Tribal Flood Net/tfn2k http://www.nIPc.gov/warnings/alerts/1999/trinoo.htm (30) SANS Institute - Distributed Denial of Service Attack Tools: trinoo and wintrinoo http://www.sans.org/newlook/resources/IDFAQ/trinoo.htm (31) Advanced Networking Management Lab (ANML), Distributed Denial of Service Attacks(DDoS) Resources - http://www.anml.iu.edu/ddos/tools.html (32) ISS Security Alert, December 7, 1999, Denial of Service Attack using the trin00 and Tribe Flood Network programs - http://bvlive01.iss.net/issEn/delivery/xforce/alertdetail.jsp? id=advise40 (33) The "Stacheldraht" distributed denial of service attack tool, David Dittrich, University of Washington - http://staff.washington.edu/dittrich/misc/stacheldraht.analysis.txt
12.3.2
Trinity
(34) SANS Institute - "Trinity" Distributed Denil of Service Attack Tool, Michael Marchesseau http://rr.sans.org/malicious/trinity.php (35) CERT Incident Note IN-2000-08. "Chat Clients and Network Security." CERT. 21 June 2000 http://www.cert.org/incident_notes/IN-2000-08.html (36) X-Force. "Internet Security Systems Security Alert." Internet Security Systems. 05 September 2000 - http://xforce.iss.net/alerts/advise59.php
12.3.3
TFN2K
(37) Axent releases a full TFN2K Analysis http://www.securiteam.com/securitynews/5YP0G000FS.html
52
12.3.4
Shaft
(38) Analyzing Distributed Denial Of Service Tools: The Shaft Case; Sven Dietrich NASA Goddard Space Flight Center, Neil Long Oxford University, David Dittrich University of Washington - http://home.adelphi.edu/~spock/lisa2000-shaft.pdf (39) SANS Institute - An Analysis of the "Shaft" Distributed Denial of Service Tool http://www.sans.org/y2k/shaft.htm
12.4 Test Cases

(40) Denial of Service attacks against GRC.COM, Steve Gibson http://grc.com/dos/grcdos.htm (41) SANS Institute, DoS Attack on a Check Point Firewall http://rr.sans.org/casestudies/dos_attack.php
53

DDoS MidSubmission

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

DDoS MidSubmission

Uploaded by

Copyright:

Available Formats

DDoS Attacks, Simulation and Detection Projects Technion Faculty of Electrical Engineering - Computer Networks Lab

DDoS Projects Midterm Report

Team 2 (cn2w03): Moshe Benyamini, 027437086 Ori Modai, 033389487

http://www.cert.org/archive/pdf/Managing_DoS.pdf ....................................................................49 (2) CERT Advisory CA-1997-28 IP Denial-of-Service Attacks

http://grc.com/dos/grcdos.htm .......................................................................................................49 (7) Razor The Naptha DoS vulnerabilities

http://www.cert.org/advisories/CA-2000-21.html .........................................................................49 (9) CERT Advisory CA-1998-01 Smurf IP Denial-of-Service Attacks

http://www.cert.org/advisories/CA-1996-21.html..........................................................................50 (12) CERT Advisory CA-1997-28 IP Denial-of-Service Attacks

http://www.cert.org/advisories/CA-1997-28.html..........................................................................50 (13) CERT advisory CA-1998-13: Vulnerability in Certain TCP/IP Implementations

http://www.sans.org/newlook/resources/IDFAQ/ICMP_misuse.htm............................................50 (15) CERT Advisory CA-1996-26 Denial-of-Service Attack via ping

http://online.securityfocus.com/advisories/1428............................................................................50 (17) CERT Advisory CA-1996-01 UDP Port Denial-of-Service Attack

http://www.uniforum.chi.il.us/slides/ddos/sld001.htm...................................................................50 (19) CERT Coordination Center, Denial of Service Attacks

http://www.themushroom.com/humor/valvedos.html....................................................................51 (23) Distributed Reflection Denial of Service, Steve Gibson,

http://grc.com/files/drdos.pdf..........................................................................................................51 (24) DDoS: Chronology, Mazu Networks

http://grc.com/dos/grcdos.htm........................................................................................................53 (41) SANS Institute, DoS Attack on a Check Point Firewall

4.3 Work Environment

5.2 Brief History & Trends:

5.3 The Asymmetric Threat

6.1 Bandwidth/Throughput Attacks

6.1.1 Ping Flood Attack (ICMP Echo)

ICMP echo replies ?

Spoofed ICMP echo requests

Victim host Attack Daemons

6.1.2 SYN Flood Attack (DoS attack)

Normal TCP Handshake

TCP Handshake During SYN Attack

TCP 3-way handshake and SYN attack. (Taken from (23))

6.1.3 DDoS attack (Distributed SYN Flood)

6.1.4 Distributed Reflected Denial of Service (DRDoS) attack

Distributed Reflected Denial of Service (Taken from (3))

6.1.6 UDP Flood Attacks

6.2 Protocol Attacks

6.2.1 Smurf Attack

6.2.2 DNS name server Attack

6.3 Software Vulnerability Attacks

6.3.1 Land Attack

6.3.2 Ping of Death Attack

6.3.3 Fragmentation Attack and Teardrop Attack

7.2 Command Distribution Methods

7.2.2 Broadcast or Multicast Distribution

7.3 Frequently Used Attack Tools

7.3.2 TFN (Tribe Flood Network)

7.3.3 Stacheldraht ("barbed wire")

ICMP debris from large-packet ping commands.

8.2 DoS Attack on a Check Point Firewall.

8.2.2 Post mortem

8.2.3 What happened?

9 Attack Platform Requirements Review

9.2.2 Attack Trigger

9.2.4 Background Traffic Generation

9.2.5 Performance Bench Marker

9.3 Simulation Environment

Simulated Attack Traffic

10 TFN2K Structure overview

10.2 The client ("the master")

10.3 The agent ("the daemon")

11 Features added to TFN2K

11.1 New commands

(<min pckt size in bytes> + <size range in bytes> )

function. Both values are initially set to '0'.

11.2 Logging system

11.3 Synchronization tool

Sync Client Library

Time- msec resolution

11.4 Corrections to original TFN2K