DDoS MidSubmission

7/27/2019 DDoS MidSubmission

1/53

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): Team 2 (cn2w03):

Tzach Schechner, 037696226 Moshe Benyamini, 027437086

Yaniv Stern, 038664454 Ori Modai, 033389487

Instructor: Yoram Yihyie

1


2/53



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

2


3/53



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


4/53



(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


(9) CERT Advisory CA-1998-01 Smurf IP Denial-of-Service Attacks


(10) Denial of Service Attacks using Nameservers http://www.cert.org/incident_notes/IN-2000-

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


(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


4


5/53



(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


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


5


6/53



(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 .................................................................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 TribeFlood 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 NASAGoddard 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

6


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

7


8/53



Background

8


9/53



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.

9


10/53



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


11/53



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

renewable 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


12/53



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. Astudy 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
http://www.caida.org/outreach/papers/2001/BackScatter/usenixsecurity01.pdfhttp://www.caida.org/outreach/papers/2001/BackScatter/usenixsecurity01.pdfhttp://www.caida.org/outreach/papers/2001/BackScatter/usenixsecurity01.pdf


13/53



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


14/53



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

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


15/53



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 hostservers in the Internet. ICMP is encapsulated by IPdatagrams. 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.

Attack Daemons

Spoofed ICMP echo requests

Victim host

ICMP echo replies

?

ICMP Floods

15
http://searchwebservices.techtarget.com/sDefinition/0,,sid26_gci212254,00.htmlhttp://searchwebservices.techtarget.com/sDefinition/0,,sid26_gci212254,00.htmlhttp://searchnetworking.techtarget.com/sDefinition/0,,sid7_gci214031,00.htmlhttp://searchnetworking.techtarget.com/sDefinition/0,,sid7_gci214031,00.htmlhttp://searchnetworking.techtarget.com/sDefinition/0,,sid7_gci211897,00.htmlhttp://searchwebservices.techtarget.com/sDefinition/0,,sid26_gci212254,00.htmlhttp://searchnetworking.techtarget.com/sDefinition/0,,sid7_gci214031,00.htmlhttp://searchnetworking.techtarget.com/sDefinition/0,,sid7_gci211897,00.html


16/53



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

requesting 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


17/53



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

way 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


18/53



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


19/53



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

requesting 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


20/53



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


21/53



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


22/53



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


23/53



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 = 8bits of data).In some TCP stack implementation encountering packets of greater size may causethe victim's host to crash.

23


24/53



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

packet" (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


25/53



hold due to resources starvation. The same effect is achieved by sending many unmatched non-

initial IP fragments. (16)

25


26/53



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 ofattack). 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 DistributionIn this architecture the master uses some sort of broadcast mechanism to connect and distribute

attack commands.

26


27/53



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


28/53



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

deployment 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


29/53



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


30/53



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 4 th 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.

ICMP debris from large-packet ping commands.

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


31/53



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


32/53



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


33/53



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


34/53



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


35/53



Attack

35


36/53



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


37/53



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


38/53



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


39/53



Simulation Topology

Simulated background traffic

Simulated Attack Traffic

Victim Host

39


40/53



10 TFN2K Structure overview

10.1General

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 daemonprocess 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.2The 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


41/53



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.3The 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


42/53



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


43/53



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.1New 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 -z

where the packet size will be generated randomly between the values and ( + ) 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


44/53



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

0

20000

40000

60000

80000

100000

120000

1234567891011121314151617

Steps

microsec

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

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


45/53



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.3Synchronization 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


46/53



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.

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 isinserted into 'time_out'. The data includes the time (secs from the year 1970), millisecs, timezone etc.

void get_time_diff(char *sync_srv_IP, char *sync_srv_port, int *p_diff_millitm, long

*p_diff_time);

46

Sync Server

Main Thread

Accept

Thread

Handle

Thread

Creates and

Close

Creates

Sync Client Library

Time- msec

resolution


47/53



The function checks the difference between the local time and the server time. Theresolution is msecs and it is updated in p_diff_time.

47


48/53



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 thetime difference calculated in the 'get_time_diff' function.

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


49/53



12 References

12.1Attack Methods

(1) Managing the Threat of Denial-of-Service Attacks, CERT Coordination Center

http://www.cert.org/archive/pdf/Managing_DoS.pdf

(2) CERTAdvisory CA-1997-28 IP Denial-of-Service Attacks

http://www.cert.org/advisories/CA-1997-28.html

(3) DRDoS - Distributed Reflection Denial of Service http://grc.com/dos/drdos.htm

(4) Denial of Service Attack Threat Analyzedhttp://www.uksecurityonline.com/threat/dos.php

(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

(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) CERTAdvisory CA-2000-21 Denial-of-Service Vulnerabilities in TCP/IP Stacks


(9) CERTAdvisory CA-1998-01 Smurf IP Denial-of-Service Attacks


49
http://www.cert.org/archive/pdf/Managing_DoS.pdfhttp://www.cert.org/advisories/CA-1997-28.htmlhttp://grc.com/dos/drdos.htmhttp://www.uksecurityonline.com/threat/dos.phphttp://support.microsoft.com/default.aspx?scid=KB;EN-US;Q172983&LN=EN-UShttp://grc.com/dos/grcdos.htmhttp://razor.bindview.com/publish/advisories/adv_NAPTHA.htmlhttp://www.cert.org/advisories/CA-2000-21.htmlhttp://www.cert.org/advisories/CA-1998-01.htmlhttp://www.cert.org/archive/pdf/Managing_DoS.pdfhttp://www.cert.org/advisories/CA-1997-28.htmlhttp://grc.com/dos/drdos.htmhttp://www.uksecurityonline.com/threat/dos.phphttp://support.microsoft.com/default.aspx?scid=KB;EN-US;Q172983&LN=EN-UShttp://grc.com/dos/grcdos.htmhttp://razor.bindview.com/publish/advisories/adv_NAPTHA.htmlhttp://www.cert.org/advisories/CA-2000-21.htmlhttp://www.cert.org/advisories/CA-1998-01.html


50/53


Technion Faculty of Electrical Engineering - Compute

DDoS MidSubmission

Documents