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
7/27/2019 DDoS MidSubmission
2/53
DDoS Attacks, Simulation and Detection Projects
Technion Faculty of Electrical Engineering - Computer Networks Lab
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
7/27/2019 DDoS MidSubmission
3/53
DDoS Attacks, Simulation and Detection Projects
Technion Faculty of Electrical Engineering - Computer Networks Lab
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
7/27/2019 DDoS MidSubmission
4/53
DDoS Attacks, Simulation and Detection Projects
Technion Faculty of Electrical Engineering - Computer Networks Lab
(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-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
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
4
7/27/2019 DDoS MidSubmission
5/53
DDoS Attacks, Simulation and Detection Projects
Technion Faculty of Electrical Engineering - Computer Networks Lab
(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
5
7/27/2019 DDoS MidSubmission
6/53
DDoS Attacks, Simulation and Detection Projects
Technion Faculty of Electrical Engineering - Computer Networks Lab
(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/27/2019 DDoS MidSubmission
7/53
DDoS Attacks, Simulation and Detection Projects
Technion Faculty of Electrical Engineering - Computer Networks Lab
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
7/27/2019 DDoS MidSubmission
8/53
DDoS Attacks, Simulation and Detection Projects
Technion Faculty of Electrical Engineering - Computer Networks Lab
Background
8
7/27/2019 DDoS MidSubmission
9/53
DDoS Attacks, Simulation and Detection Projects
Technion Faculty of Electrical Engineering - Computer Networks Lab
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
7/27/2019 DDoS MidSubmission
10/53
DDoS Attacks, Simulation and Detection Projects
Technion Faculty of Electrical Engineering - Computer Networks Lab
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
7/27/2019 DDoS MidSubmission
11/53
DDoS Attacks, Simulation and Detection Projects
Technion Faculty of Electrical Engineering - Computer Networks Lab
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
7/27/2019 DDoS MidSubmission
12/53
DDoS Attacks, Simulation and Detection Projects
Technion Faculty of Electrical Engineering - Computer Networks Lab
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.pdf7/27/2019 DDoS MidSubmission
13/53
DDoS Attacks, Simulation and Detection Projects
Technion Faculty of Electrical Engineering - Computer Networks Lab
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
7/27/2019 DDoS MidSubmission
14/53
DDoS Attacks, Simulation and Detection Projects
Technion Faculty of Electrical Engineering - Computer Networks Lab
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
7/27/2019 DDoS MidSubmission
15/53
DDoS Attacks, Simulation and Detection Projects
Technion Faculty of Electrical Engineering - Computer Networks Lab
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.html7/27/2019 DDoS MidSubmission
16/53
DDoS Attacks, Simulation and Detection Projects
Technion Faculty of Electrical Engineering - Computer Networks Lab
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
7/27/2019 DDoS MidSubmission
17/53
DDoS Attacks, Simulation and Detection Projects
Technion Faculty of Electrical Engineering - Computer Networks Lab
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
7/27/2019 DDoS MidSubmission
18/53
DDoS Attacks, Simulation and Detection Projects
Technion Faculty of Electrical Engineering - Computer Networks Lab
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
7/27/2019 DDoS MidSubmission
19/53
DDoS Attacks, Simulation and Detection Projects
Technion Faculty of Electrical Engineering - Computer Networks Lab
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
7/27/2019 DDoS MidSubmission
20/53
DDoS Attacks, Simulation and Detection Projects
Technion Faculty of Electrical Engineering - Computer Networks Lab
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
7/27/2019 DDoS MidSubmission
21/53
DDoS Attacks, Simulation and Detection Projects
Technion Faculty of Electrical Engineering - Computer Networks Lab
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
7/27/2019 DDoS MidSubmission
22/53
DDoS Attacks, Simulation and Detection Projects
Technion Faculty of Electrical Engineering - Computer Networks Lab
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
7/27/2019 DDoS MidSubmission
23/53
DDoS Attacks, Simulation and Detection Projects
Technion Faculty of Electrical Engineering - Computer Networks Lab
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
7/27/2019 DDoS MidSubmission
24/53
DDoS Attacks, Simulation and Detection Projects
Technion Faculty of Electrical Engineering - Computer Networks Lab
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
7/27/2019 DDoS MidSubmission
25/53
DDoS Attacks, Simulation and Detection Projects
Technion Faculty of Electrical Engineering - Computer Networks Lab
hold due to resources starvation. The same effect is achieved by sending many unmatched non-
initial IP fragments. (16)
25
7/27/2019 DDoS MidSubmission
26/53
DDoS Attacks, Simulation and Detection Projects
Technion Faculty of Electrical Engineering - Computer Networks Lab
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
7/27/2019 DDoS MidSubmission
27/53
DDoS Attacks, Simulation and Detection Projects
Technion Faculty of Electrical Engineering - Computer Networks Lab
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
7/27/2019 DDoS MidSubmission
28/53
DDoS Attacks, Simulation and Detection Projects
Technion Faculty of Electrical Engineering - Computer Networks Lab
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
7/27/2019 DDoS MidSubmission
29/53
DDoS Attacks, Simulation and Detection Projects
Technion Faculty of Electrical Engineering - Computer Networks Lab
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
7/27/2019 DDoS MidSubmission
30/53
DDoS Attacks, Simulation and Detection Projects
Technion Faculty of Electrical Engineering - Computer Networks Lab
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
7/27/2019 DDoS MidSubmission
31/53
DDoS Attacks, Simulation and Detection Projects
Technion Faculty of Electrical Engineering - Computer Networks Lab
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
7/27/2019 DDoS MidSubmission
32/53
DDoS Attacks, Simulation and Detection Projects
Technion Faculty of Electrical Engineering - Computer Networks Lab
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
7/27/2019 DDoS MidSubmission
33/53
DDoS Attacks, Simulation and Detection Projects
Technion Faculty of Electrical Engineering - Computer Networks Lab
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
7/27/2019 DDoS MidSubmission
34/53
DDoS Attacks, Simulation and Detection Projects
Technion Faculty of Electrical Engineering - Computer Networks Lab
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
7/27/2019 DDoS MidSubmission
35/53
DDoS Attacks, Simulation and Detection Projects
Technion Faculty of Electrical Engineering - Computer Networks Lab
Attack
35
7/27/2019 DDoS MidSubmission
36/53
DDoS Attacks, Simulation and Detection Projects
Technion Faculty of Electrical Engineering - Computer Networks Lab
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
7/27/2019 DDoS MidSubmission
37/53
DDoS Attacks, Simulation and Detection Projects
Technion Faculty of Electrical Engineering - Computer Networks Lab
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
7/27/2019 DDoS MidSubmission
38/53
DDoS Attacks, Simulation and Detection Projects
Technion Faculty of Electrical Engineering - Computer Networks Lab
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
7/27/2019 DDoS MidSubmission
39/53
DDoS Attacks, Simulation and Detection Projects
Technion Faculty of Electrical Engineering - Computer Networks Lab
Simulation Topology
Simulated background traffic
Simulated Attack Traffic
Victim Host
39
7/27/2019 DDoS MidSubmission
40/53
DDoS Attacks, Simulation and Detection Projects
Technion Faculty of Electrical Engineering - Computer Networks Lab
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
7/27/2019 DDoS MidSubmission
41/53
DDoS Attacks, Simulation and Detection Projects
Technion Faculty of Electrical Engineering - Computer Networks Lab
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
7/27/2019 DDoS MidSubmission
42/53
DDoS Attacks, Simulation and Detection Projects
Technion Faculty of Electrical Engineering - Computer Networks Lab
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
7/27/2019 DDoS MidSubmission
43/53
DDoS Attacks, Simulation and Detection Projects
Technion Faculty of Electrical Engineering - Computer Networks Lab
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
7/27/2019 DDoS MidSubmission
44/53
DDoS Attacks, Simulation and Detection Projects
Technion Faculty of Electrical Engineering - Computer Networks Lab
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
7/27/2019 DDoS MidSubmission
45/53
DDoS Attacks, Simulation and Detection Projects
Technion Faculty of Electrical Engineering - Computer Networks Lab
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
7/27/2019 DDoS MidSubmission
46/53
DDoS Attacks, Simulation and Detection Projects
Technion Faculty of Electrical Engineering - Computer Networks Lab
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
7/27/2019 DDoS MidSubmission
47/53
DDoS Attacks, Simulation and Detection Projects
Technion Faculty of Electrical Engineering - Computer Networks Lab
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
7/27/2019 DDoS MidSubmission
48/53
DDoS Attacks, Simulation and Detection Projects
Technion Faculty of Electrical Engineering - Computer Networks Lab
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
7/27/2019 DDoS MidSubmission
49/53
DDoS Attacks, Simulation and Detection Projects
Technion Faculty of Electrical Engineering - Computer Networks Lab
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
http://www.cert.org/advisories/CA-2000-21.html
(9) CERTAdvisory CA-1998-01 Smurf IP Denial-of-Service Attacks
http://www.cert.org/advisories/CA-1998-01.html
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.html7/27/2019 DDoS MidSubmission
50/53
DDoS Attacks, Simulation and Detection Projects
Technion Faculty of Electrical Engineering - Compute
Top Related