DoS Attacks

DoS Attacks, Detection, and Mitigation
Josiah Konrad (100847435)
Vladamir Menshikov (100840927)
Reilly Moore (100945421)
Xiao Zhu (100757147)
December 8, 2015
1 Introduction
1.1 Context
Many online services use a “Client-Server” model. In this model a service is provided
through a dedicated server where the individual users (the clients) connect to the server over
the internet at will (Fig 1-1).
One common method for bringing down servers is a Denial of Service Attack (DoS) known
as SYN Flooding (Where SYN is a Synchronization request). SYN Flooding is a relatively safe and
efficient way to bring down a server by overloading its resources through a spam of SYN requests
with a Spoofed Internet Protocol (IP) Address where the return address in the packet is forged to
point the server to a different location. The attack exploits a vulnerability in Transmission Control
Protocol (TCP) connections by interrupting the “Three-way Handshake” between a client and a
server that opens a connection. When interrupted, a server will continue to wait for an
acknowledgement (ACK) tying up resources while it waits. The attack floods the server with SYN

requests as the server continues to allocate resources to these connections that will never
complete until the server has used all of its resources and starts refusing the connections of
legitimate users.
Another common DoS attack is the DNS amplification attack. DNS amplification attacks are
still very common on the internet and can be very powerful against an unprepared server. They
work by requesting records from a Domain Name System (DNS) server with your victim’s IP
address as the source address in the IP header. Certain domains contain very large records, so
when the DNS server sends the response, it may be many times larger than the original request.
This achieves an amplification effect, as the victim will receive far larger amounts of data than
the attacker has originally sent. This attack is effective when you are able to flood the victim with
more information than their bandwidth allows.
1.2 Problem Statement
Servers are occasionally brought down by these DoS attacks without warning or record.
Often leaving server owners in the dark about what exactly happened and what they can do
about it in the future. Our goal was to create a set of DoS attack clients that will attack a server
of our creation that can detect an attack, record the event in its logs and possibly even defend
against it.
1.3 Result
One of our attack clients can launch a SYN Flood attack on a TCP server, overloading its
resources causing future connections to fail. Our Server can successfully detect when it is being
attacked by a SYN Flood Attack. It will record the event in the server’s logs and the server will
mitigate the attack based on the algorithm described in section 3. Our second attack client
launches a DNS amplification attack flooding a server with DNS requests effectively multiplying
the attack volume of the client for use against a server. Our server however, can only defend
against SYN flooding, not DNS amplification. The reasons for this are described in section 4.

1.4 Outline
The rest of the report is structured as follows. Section 2 presents the relevant background
information for a TCP connection, a SYN Flood Attack and a DNS Amplification Attack. Section 3
details the qualitative results of our objective relating to the attack clients and the mitigation
efforts of the server. Section 4 details the quantitative results with numerical breakdowns of the
effectiveness of our attack clients and defence server. Finally, section 5 is the conclusion of the
report followed by the references used.
2 Background Information
Recently, DoS and DDoS attacks are becoming more and more common every day (Fig 1-0).
Since they conform to the same specifications as the designed ‘legal’ way to communicate with
a system, the victim cannot avoid or defend against them directly. Because of this, the DoS attack
becomes an effective method for denying a web service (DoS). Often, if an attacker cannot
breach a server’s security they will instead launch a DoS attack to disable the service.
DoS and DDoS attacks can cause serious damage to the victim’s server, not only in hours of
downtime but also in data and subscriber loss. Occasionally an attack can even cause physical
damage to a server. The cost associated with defending against future attacks and recovering
from previous attacks can often be prohibitively high.
Fig 2-0: A news report of a recent DoS attack [1]

In light of this reality, it is important to pre-emptively mitigate these attacks to minimize the
potential damage.
IP Spoofing is required for both types of attacks. IP Spoofing is the forgery of the source IP
in a packet. It involves manually editing the header of the packet to change the source IP to a
random value effectively concealing the identity of the spoofer. The attacker can then send
potentially thousands of packets that appear to be from thousands of different users. This
concealment allows the attacker to continuously operate without detection.
SYN Flooding is a DoS attack that exploits the “Three-way Handshake” in a TCP connection
through IP Spoofing. A typical client server TCP connection starts when a client makes a SYN
request to a server, the server sends a SYN-ACK to the client and finally the client sends a final
ACK to complete the connection (Fig 2-1) [2][3].
The SYN Flood Attack interrupts this handshake by changing the return IP in the sent
packet to a different address (IP Spoofing). This causes the server to sent the SYN-ACK to the
spoofed address instead of the attacker’s and the spoofed address will never send back an ACK
because it knows it never sent a SYN request (Fig 2-2) [4].

This redirection has the consequence of wasting server resources waiting for the spoofed IP
to respond. The attacker will send the server many seemingly legitimate SYN requests that are
indistinguishable from actual users [5]. The server is then flooded with SYN requests causing it to
allocate resources to each new connection. Eventually the attacker will have flooded the server
with so many connection requests that will never complete the server will run out of resources
to allocate to new connections either crashing the server or simply refusing connection to any
new clients effectively denying them the service [6].
DNS Amplification works by requesting records from a Domain Name System (DNS) server
with your victim’s IP address as the source address [9]. When the DNS server sends a response,
it is often many times larger than the original request [10]. This achieves the desired amplification
effect, as the victim will receive far larger amounts of data than the attacker has originally sent
(Fig 2-3) [11].

3 Result
We have developed an attack client that is designed to launch a SYN Flood Attack on a
TCP server. The client is capable of overloading a server with TCP SYN requests that have a
spoofed IP protecting the client’s identity. The spoofed IP is randomized with every packet
making it difficult for a server to detect and block the attack client. Ideally a SYN flood attack
would use multiple instances of the attack client, however a single client can often flood a
server with enough spoofed requests to effectively disable it.
The server protects against SYN flood attacks through design. It does this by keeping a
large master list of active SYN requests in a fixed size array with a counter denoting the position
(effective size) in the array. Every SYN request has its IP logged in the array as the server waits
for an ACK. When an ACK is received the server records that client on a separate list of
legitimate clients (Fig 3-1). The first array of SYN requests has a maximum arbitrary size of
1000. Every time the position counter of the array reaches the maximum size (1000) the server
resets the counters value to 0, effectively flushing the buffer of SYN requests. This
implementation works because it has a fixed amount of resources allocated to active SYN
requests and every time the resources are expended it flushes the buffer and starts from 0.
This system can still drop legitimate users attempting to connect if they fail to connect before
the buffer is flushed but a sufficiently large buffer makes this scenario relatively unlikely. The

end result of this system is that the server can now handle a large amount of spoofed SYN
requests by discarding incomplete SYN requests when the buffer is full.
The server can withstand an average sized attack indefinitely where a similarly sized
server without any defence could be brought down in seconds. The rate of detection is
essentially perfect, however at large attack volumes legitimate clients attempting to establish
a new connection may be dropped.
The implementation of our SYN Flooding mitigation makes all but the largest of SYN Flood
Attacks a non-issue. This implementation is likely unsuited for commercial use as its design still
leaves it very susceptible to other types of DoS attacks. Since many DoS attacks are multi-
factored the usefulness of this implementation is likely minimal. One of the most common
methods for defending against SYN Flood attacks is “SYN Cookies” where the only major
weakness is that it discards all TCP options. Our implementation fixes this issue by completing
a standard TCP connection but this comes at a cost of occasionally dropping users that are
Fig 3-1: The SYN Flood Mitigation Algorithm

attempting to connect while the server is under attack. The likelihood of being dropped is
directly proportional to the volume of the attack. This is described in detail in section 4.
Our second client is designed to launch a DNS amplification attack, however there is no
server software counterpart for this attack. The client has a very straightforward interface for
basic use: it is simply run from a command line argument taking only your victim’s IP address
and port (and optionally a DNS server to use). From here it simply runs in an infinite loop
sending packets until receiving the interrupt signal.
For more advanced use, which DNS servers are queried as well as which records are
requested may be easily changed, however this requires recompilation. This implementation
is also straightforward from a programming point of view, with respect to modifications to the
frequency of attacks, as well as distributing across multiple DNS servers. The DNS attack code
was separated into its own portable file.
In order to implement the attack, we constructed a datagram and sent it over a raw
socket. The datagram is constructed first with the headers (IP, UDP, DNS) and then with the
DNS query body. As to not illicit suspicion, most of the header fields and query fields are set to
the typical values for making a DNS requests. The only significant differences are in the IP
header and the DNS query. The source address in the IP header is spoofed to be the target’s
address,
header->saddr = inet_addr(sender_ip);
and the DNS query type is set to 255, the value to request ‘ANY’ from the DNS server, which
returns all record types.
q->qtype = htons(0x00ff);
Lastly we calculate the UDP and IP header checksums since we are using raw sockets and
the kernel’s networking stack will leave it as is. If the checksum fields are invalid, the attacker’s
local router will most likely discard the packet entirely. After all of this the attack is amplified
many times allowing a single connection to bring down a larger server.

4 Evaluation
Our implementation of a SYN Flood attack was used for all tests relating to the
evaluation of the effectiveness of our server’s defence.
Our SYN Flood attack client was able to consistently bring down our basic undefended
test server in approximately ~1 second. As the basic server had no defence its resources were
filled to the point that the server would crash. It is worth noting however that an average
commercial server has options to deal with a sudden spike in network traffic allowing it to
withstand a SYN Flood attack much longer before eventually running out of resources.
Our defence client was designed to withstand a SYN Flood attack indefinitely as it does
not bind any resources to a connection until it has been verified and it is able to do so with
varying effectiveness depending on the volume of the attack. There is a theoretical maximum
limit of SYN requests our server may take per second where the server cannot process the
requests as fast as it receives them but we were not able to reach this limit with our
implementation.
Our detection rate for if the server is under attack was 100% in all tests when the attack
was sustained for more than 100s (Fig 4-0). In volumes of 1000 requests per second or more
the server detected the attack nearly instantaneously. The detection rate for this
implementation is somewhat irrelevant however because unlike other defences that must be
activated upon detection our defence is through design and cannot be activated or deactivated.
Therefore, the detection rate in the server’s log is just for the benefit of the server owner.
0
50
100
150
10 100 1000 10000
Detection Speed (s) vs. Attack
Volume (requests/s)
Requests per Second
Fig 4-0: Detection speed (s) of a SYN
Flood Attack with respect to the
volume of an attack.
Seconds

The biggest weakness of our defence algorithm is false positives (Fig 4-1). If the server is
not under attack only 1 in 1000 legitimate requests will be flushed from the buffer (effectively a
false positive). Note that these rates for dropped clients only pertain to clients attempting to
connect. Once a client has successfully established a connection it should never be dropped.
When the server is under attack with a mild volume (10-100 requests per second) the rates are
about the same at only 1 in 1000 false positives. The rate of legitimate user attempted
connections being dumped only increases when the attack volume is higher than 1000 per
second. At this point it is estimated that roughly 10% of all legitimate requests would be
dropped depending greatly on the connection speed between the users and the server. Our
tests were base on an approximate time to connect of about ~200ms. Finally, at 10,000 and a
theoretical 100,000 requests per second the server would be flushing the buffer faster than the
legitimate clients could connect and we estimate roughly 50% and 98% respectively would be
dumped as false positives. This again however only effects users attempting to establish a
connection. Users already connected should remain unaffected. At very high volumes
upgrading the server’s hardware would be the best solution to mitigate an attack.
Fig 4-1: Rate of false positives for mitigation of a SYN Flood attack.
*Theoretical
0%
10%
20%
30%
40%
50%
60%
70%
80%
90%
100%
10 100 1000 10000 100000*
Rate of False Positives for SYN Flood Defence
Requests Per Second

The DNS amplification attack was successful in terms of function, but not entirely in
terms of result. When run, it is capable of sending out 20,000+ packets per second, although
that rate is largely dependant on the CPU. These packets were verified to be valid DNS request
by capturing them with Wireshark.
As an example of our amplification effect, we used the ‘dig’ tool available in the
‘dnsutils’ package from the official Arch Linux repositories (this may be available by default on
other distributions, or from the respective distributions repositories). This tool makes a DNS
query for the domain and query or your choice. The tool was used to measure request and
response sizes, since the requests made are the same as our attack client.
For example, we ran dig ANY tf2pug.me, and caught the packets in Wireshark to view
the size on wire. For this domain, the requests were 80 bytes, and the response was 436 bytes.
Achieving a small amplification of 5.45 times.
At this point, things get more complicated. DNS servers have a wide range of policies in
terms of their response. The first major complication occurs when requesting very large
responses. For example, requesting ‘ANY’ from “ietf.org” will give you a TCP response because
DNS servers will only send UDP responses up to 512 bytes, or 4096 bytes if you indicate you can
handle it in your request. The response for ietf.org is 4935 bytes, and as such is useless to us
(since the victim has not initiated the TCP connection). In the case of having a domain which
gives a response just under 4096 bytes, we would achieve an amplification of just over 50
times. Below is an example of achieved amplification off of common domains (Fig 4-2).
0
100
200
300
400
500
600
700
800
google.com amazon.com wikipedia.org ebay.com
Request/Response Sizes for DNS Records
Request Response
5.89x
8.12x
3.36x
9.01x
Bytes
Fig 4-2: Typical amplification
from common domain records

The next complication caused by DNS server behaviour is in the case of receiving mass
requests from the same IP address. The majority of DNS servers (and almost all commonly used
servers) implement rate limits of some sort to prevent their servers from being used in a DNS
amplification attack. There are servers with no restrictions, however they are not always easily
findable and are typically from countries such as China, Afghanistan, or other similar countries
with less strict technological regulation.
Most large networks operators also have methods in place to prevent an attack from being
launched on their network. This can be very easily achieved by simply filtering out all packets
with invalid IP headers attempting to leave the network. We have determined through testing
that Carleton University likely has this, or something similar in place that prevents us from
launching an attack from the computer labs. We were however able to successfully launch
attacks from our respective home networks.
5 Conclusion
The DNS Amplification attack client can successfully amplify the client’s attack volumes
allowing it to launch a DoS attack even if the server has a larger bandwidth than the client, taking
into account the pitfalls described above. The SYN Flood attack client can successfully flood a
server with TCP SYN requests using a spoofed IP allowing it bring down servers that use TCP and
do not have adequate DoS protection. The server can successfully detect, log and mitigate a SYN
Flood attack, allowing legitimate users to continue to connect to the server and use its services.
Contributions of Team Members
Josiah Konrad: Developed and evaluated the SYN Flood Mitigation Algorithm, contributed to
the Anti-SYN Flood Server. Final editor for the report.
Vladamir Menshikov: Worked primarily on the Anti-SYN Flood Server, contributed to the SYN
Flood Attack Client and SYN Flood Mitigation Algorithm.
Reilly Moore: Developed and evaluated the DNS Attack Client, contributed to the Anti-SYN
Flood Server.
Xiao Zhu: Developed the SYN Flood Attack Client and implemented IP Spoofing for both
clients, contributed to Anti-SYN Flood Server.

References
[1] Newsweek, “Report: Canadian Government Websites inaccessible Following Denial-of-Service
Attack” http://www.newsweek.com/canadian-government-websites-inaccessible-following-denial-
service-attack-344002. Accessed: November 27, 2015
[2] Rhys Haden, “TCP” http://www.rhyshaden.com/tcp.htm. Accessed: November 21, 2015
[3] OmniSecu.com, “TCP Three-way Handshake” http://www.omnisecu.com/tcpip/tcp-three-way-
handshake.php. Accessed: November 21, 2015
[4] JUNIPER NETWORKS, “Understanding SYN Flood Attacks”
http://www.juniper.net/documentation/en_US/junos12.1/topics/concept/denial-of-service-network-
syn-flood-attack-understanding.html. Accessed: November 23, 2015
[5] Wesley M. Eddy, “Defenses Against TCP SYN Flooding Attacks”
http://www.cisco.com/web/about/ac123/ac147/archived_issues/ipj_9-4/syn_flooding_attacks.html.
Accessed: November 25, 2015
[6] Thanglalson Gangte, “SYN Flood Attacks-How to protect?-article” https://hakin9.org/syn-flood-
attacks-how-to-protect-article/. Accessed: November 23, 2015
[7] Mariusz Burdach, “Hardening the TCP/IP stack to SYN attacks”
http://www.symantec.com/connect/articles/hardening-tcpip-stack-syn-attacks. Accessed: November
23, 2015
[8] Rik Farrow, “TCP SYN Flooding Attacks and Remedies”
http://www.networkcomputing.com/unixworld/security/004/004.txt.html. Accessed: November 23,
2015
[9] Maxim Blagov, “DDoS Attack Glossary” https://www.incapsula.com/ddos/attack-glossary/dns-
amplification.html. Accessed: November 17, 2015
[10] DAVID CORNELL, “DNS AMPLIFICATION ATTACKS” https://labs.opendns.com/2014/03/17/dns-
amplification-attacks/. Accessed: November 17, 2015
[11] Matthew Prince, “Deep Inside a DNS Amplification DDoS Attack” https://blog.cloudflare.com/deep-
inside-a-dns-amplification-ddos-attack/. Accessed: November 21, 2015
Note: References [7] and [8] were general research sources and not referenced directly in this report.

DoS Attacks

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (10)

Ähnlich wie DoS Attacks

Ähnlich wie DoS Attacks (20)

DoS Attacks