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.

Seco

nd

s

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

Byt

es

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.