1. 1
The University of Texas at Austin
MIS 373: IT Audit & Security
DDOS: The Superweapon of the Internet
R. Blake Martin, Connie Cheng, Jason Picciano, Michele Jafri, Allison Kahn
Sponsor: Nick Angelou, CTO of Sectify
Professor: Dr. Hüseyin Tanriverdi, PhD
TA: Amrita Chopra
11/22/2015

2. 2
I. EXECUTIVE SUMMARY
This project examines a possible alternative solution to mitigate Distributed Denial of
Service (DDoS) attacks, specifically Combo SYN Flood Attacks or UDP Flood Attacks, for
individuals or small to medium sized businesses. The proposed DDoS solution addresses the
most common type of DDoS attack called the Combo SYN Flood Attack. These attacks
account for half the network DDoS events and 75% of large scale network DDoS attacks
(Imperva, 2015). In this attack, the user floods the server with connection requests and
binds the resources until no new connections can be made, causing a denial of service. This
remains a perpetrator’s main weapon due to the quick consumption of resources on the
target or intermediate communication equipment (Imperva, 2015). UDP Flood Attacks are
also common. The intention is to overwhelm the bandwidth pipe going to the host with
garbage packets, not necessarily to exhaust the server’s resourcesby keeping connections
open like SYN attacks.
DDoS attacks target online services with the intention of bringing them offline with the
use of excessive traffic from multiple sources. Organizations that are victims of DDoS attacks
can suffer from major financial consequences along with the possibility of data theft.
According to a 2014 Incapsula survey of 270 North American locations, DDoS attacks
average a cost of $40,000 an hour and almost half the attacks last 6-24 hours. The average
cost of a DDoS attack is approximately $500,000 with some resulting in more significant
costs (Matthews, 2014).
Attackers can have more malicious motivations and use DDoS attacks as a means to
distract a company’s IT team while hiding their true intentions such as installing malware or
stealing data. Therefore, DDoS attacks also present significant security implications in

3. 3
addition to the financial concerns. 45% of Incapsula’s respondents acknowledged that their
organization had been hit at some point. Almost all (91%) of those respondents suffered an
attack in 2013 and 70% were targeted at least twice (Matthews, 2014).
This paper explores a unique solution that addresses a growing need for DDoS
solutions. Bandwidth is expensive and if crowd-sourcing is a more cost effective way to
harness bandwidth it could change the way that DDoS mitigation is handled. We took this
idea and researched the fundamentals necessary to understand the front and back end
architecture that would be required for this proposed solution to operate.
Unfortunately, we concluded that with the current technologies available, this product
is not possible because it presents security, performance, or unreliability issues. We
approached three different methods, performing DPI on the client to sort through encrypted
traffic, directing all traffic through a trusted proxy before sending packet to the client for a
DPI, or not using a DPI method at all and just applying a header/metadata inspection. The
main problem with the first method is placing too much trust and responsibility with the
client when there is no way to prevent them from acting maliciously when dealing with SSL
encrypted sites. Additionally, due to the slow nature of the public DNS propagation along
with unreliable client uptime and dynamic IPs, this opens protected hosts up to suffering
from extended periods of downtime. Until this fundamental underpinning of the internet is
changed or updated, we have to recognize that public DNS propagation is a slow process. If
we were to react to the security threat on SSL encrypted sites and change our method to
header/metadata inspection only, the issue with performance latency due to DNS
propagation still exists. Only inspecting the header of packets is not reliable because headers

4. 4
can easily be spoofed by botnets. These are some of the fundamental realities of why this
crowd-sourced DDoS mitigation concept is not currently possible.
The target audience can still be protected with many other DDoS solutions that
currently exist and operate on a more central model. With their own servers and static IPs,
companies that provide DDoS mitigation like CloudFlare, are able to offer reliable uptime
and slow DNS propagation is much less likely to be an issue, except during the initial
implementation process. These solutions often add an extra layer of protection by offering
SSL certificates to sites that are not SSL encrypted. It is important that companies allocate
some resources to mitigating DDoS attacks as the problem is growing.
II. PROBLEM STATEMENT
DDoS attacks are a persistent threat to businesses that rely on reliable network and
internet connectivity in order to conduct business. A flood DDoS is an attack in which a
network of several infected internet-connected devices (botnet) is used to render the
services of a host on the internet inoperable for an extended period of time. DDoS attacks are
complicated for companies to mitigate in-house for multiple reasons. The growing
sophistication of techniques mean that companies need to consistently update their DDoS
response tactics to adapt to changes in attacks. The attack source is generally thousands of
unique IP addresses, each one belonging to an infected zombie computer within a botnet,
flooding the host with traffic until it overwhelms the site and takes it offline. The growing
ability of DDoS attacks to behave similarly to ordinary web traffic makes it more difficult to
detect legitimate and illegitimate tactics with traditional defenses (Arbor Networks, Inc.,
2013). According to data from Info Security Magazine, a growing trend has been organized
cybercriminals renting out their botnets cheaply to individuals. This transaction is known as

5. 5
“DDoS-For-Hire” with the service known as “Booter”. Booter services enable anyone with a
payment method to conduct large-scale DDoS attacks with minimal technical knowledge.
The targets of these attacks are generally internet-connected servers of companies and
websites (i.e. Apache web servers) that either generate revenue from web traffic or
otherwise rely on their systems being online to function (Seals, 2015). The difficulty for
businesses to mitigate these attacks on their own is quickly rising due to highly sophisticated
attack mechanisms, the cost-benefit of bandwidth needed to mitigation attacks (the cost of
adding bandwidth is not linearly proportional to risk), Advanced Persistent Threats (APTs),
Internet-of-Things (IoT) concerns, and the popularity of Booters.
The looming threat of DDoS attacks has created an opportune environment for DDoS
mitigation strategies. Current DDoS mitigation technologies employ the same strategies that
a corporate entity would use in-house, simply with better methodology and on a larger scale.
These companies use their own networks and datacenters or partner datacenters to act as
middle men receiving web traffic, attempting to scrub out malicious traffic, and then
redirecting the traffic to its requested destination. The difficulty of mitigating DDoS faces a
high chance of being exacerbated in the near future as bandwidth provided by ISPs increases
and the persistent threat of IoT devices rises. Current SaaS DDoS mitigation companies will
potentially face difficulty providing their services if they cannot keep up with the new
volumes and growing attack potential of DDoS tools and botnets.
Our objective is to examine the feasibility of a DDoS mitigation application powered
by crowd-sourced bandwidth. We developed various approaches to address how the crowd-
sourced solution would operate. Upon discovering that certain methods may cause security

6. 6
or performance issues, we examined alternate processes that could address issues brought
up in earlier methods.
The application will allow clients to sign up to participate, allocate a chosen amount
of their bandwidth to be used in mitigating DDoS attacks, and receive monetary
compensation for the amount of bandwidth used. By integrating a dynamic real-time DNS
service, web traffic will be dispersed to application users, and then will be rerouted back to
the destination. This theoretically creates a cost effective solution to gather unused
bandwidth from multiple clients that will continue to grow as more clients join the network
and provide more bandwidth, making the solution scalable. With a sufficient amount of
bandwidth available (our breakeven point), the application could potentially mitigate DDoS
attacks for small to medium businesses and possibly even large corporations if more clients
join. This is an innovative idea that could significantly impact and revolutionize the way that
DDoS is mitigated in the industry. With the growing trends of crowd-sourced companies, and
the powerful crowd-sourcing abilities behind DDoS attacks, could crowd-sourcing be a
formidable solution to defend against these attacks? As DDoS attacks rapidly become more
common, more damaging, and easier to conduct, an evolved and robust DDoS mitigation
application that leverages current SaaS services and crowd-sourcing can transcend the
traditional functionality of current DDoS solutions.
III. CONTEXT
Nick Angelou, Co-Founder and CTO of the information security consulting company
Sectify and “white-hat hacker”, is the architect behind the idea of crowd-sourced DDoS
mitigation. As a self-starter with a technical background, Mr. Angelou has an appetite for
innovative and creative ideas. With the rising popularity in crowd-sourced projects, Mr.

7. 7
Angelou was inspired to develop the idea explored in this paper, creating a crowd-sourced
solution to address the growing DDoS problem. DDoS mitigation solutions exist but adequate
protection plans can be expensive, especially for small to medium sized companies with
limited budgets. In Incapsula’s 2014 survey, only 43% of the companies surveyed used a
“purpose-built” DDoS solution. Over half the respondents admit they rely on traditional
firewalls or web application firewalls which are vulnerable on their own (Matthews, 2014).
Mr. Angelou saw a need for more companies to protect their services from DDoS attacks and
thought of an inventive way to make DDoS protection more cost effective. Many consumers
or companies have extra bandwidth that they don’t use, if that bandwidth could be
potentially harnessed from various sources, it could create a cost-effective crowd-sourced
platform to fight DDoS attacks.
The target audience of our paper is anyone that will benefit from learning about how to
protect themselves from DDOS attacks. This includes anyone who has a stake in a vulnerable
corporation, IT professionals, executives such as CISOs and CTOs, and individuals whose
personal home networks are at risk of suffering from a DDoS attack and rely on internet
connectivity for generating income. Examples of the latter category include popular content
creators, live video streamers, and blog owners who have been victims of DDOS attacks.
Individuals who work from home and would potentially be targeted by extortion-based
attacks due to their wealth, such as successful day traders, are also at risk of DDOS attacks as
well and are part of our target audience. On the user side, anyone who can provide a pre-
selected amount of bandwidth by running the proposed application (independent of
operating system) on their laptops, desktops, or mobile devices is part of our target
audience. They will profit from providing bandwidth they are not using. This potentially

8. 8
includes anyone in any country where we could legally operate and who owns a device with
internet connectivity. Initially we will target potential users in North America since our
preliminary research is based on the feasibility in the United States, especially regarding
compliance and auditing our service would be subject to. As far as clients of our service are
concerned, any business entity or individual who makes substantial income from online
revenue would be a part of our target audience. We are primarily targeting ourselves toward
the market of small to medium businesses since they have less budget constraints, can spend
money more freely, and network downtime can be especially costly. Large companies mostly
already have some sort of DDOS protection, whether in house or provided by a third party
content delivery network (CDN), and will likely be reluctant to change if their current
methods are effective enough to meet standards and needs. An expensive enterprise package
offered by a CDN might be affordable for a large company, but our concept could provide
comparable services for cheaper to small-medium sized companies due to eliminating much
of the overhead needed through crowd-sourcing.
IV. DECISION PARAMETERS AND CONSTRAINTS
There are multiple forms of DDoS attacks but this proposed crowd-sourced solution
focuses on defending against flood attacks. Although other attacks would fall outside the
scope of this solution, this solution does address the most common form of DDoS in great
depth. While this idea would not offer a comprehensive solution for all DDoS mitigation, the
proof of concept would first need to be able to mitigate the largest type of DDoS attack in
order to be a viable resolution.
The feasibility we explored was infrastructure of the application and how it would
communicate within the network and between the host and browser. Developing an

9. 9
algorithm to determine whether or not traffic is legitimate was outside the scope of this
research. There are many resources that exist that have successfully been used to detect
legitimate traffic and continue to adapt as DDoS attacks evolve. It is important to ensure the
foundations of this idea are plausible first.
With a growing number of sites with SSL encryption and the growing DDoS attacks
targeting SSL sites, it is important for the application to address a significant portion of the
web that use SSL encryption. When evidence was found that this concept would create more
security issues with SSL encrypted sites, we had to readjust our parameters to focus on the
feasibility to protect sites that are not encrypted with SSL or to drop the idea of DPI for
traffic profiling entirely. This led us to discover issues that this model would cause with
backend processes due to dynamic DNS and DNS propagation speeds.
V. CONCEPTUAL FOUNDATIONS
To guide our study of the proposed DDoS mitigation application, we adopted the COBIT
framework of conceptual thought. Mitigating DDoS attacks require a company to have strong
controls in place. In regards to COBIT 5, Robert Stroud, a member of ISACA”s strategic
Advisory Council said, "'COBIT 5 for Information Security' provides guidance for IT
practitioners on implementing effective security practices regardless of the environment
(on-premise, public or private cloud), and reinforces the alignment between business values
and effective security practices" (Ko, 2012). Due to this framework’s focus on enterprise
risk tolerance and acceptance and emphasis on the appropriate management of security, the
implications of DDoS are an issue that this framework addresses. DDoS is an example of
computer misuse and security risks, especially to cloud technologies and COBIT 5 is relevant
to these issues because it addresses the risks for corporations that operate in the cloud (Ko,

10. 10
2012). Linda Hui, managing director of F5 Networks stated in regards to COBIT 5, “…to
defend DDoS attacks, the security framework has to be flexible and expandable in order to
add new logic to defend such new attacks” (Ko, 2012).
Looking at risk-decreasing factors by Service Model in regards to Infrastructure as a
Serviced (IaaS), S1.A addresses scalability and elasticity of an infrastructure. Cloud
technologies make it easy for companies to scale capacity and elasticity aids in better cost
optimization by eliminating over-provisioning and under-provisioning IT resources. Using
IaaS is advantageous for companies to offset issues like DDoS to these services that provide
filtering traffic services and offload a lot of unnecessary bandwidth from the protected host
(ISACA). Using such a service would mitigate the risk of unavailability.
However we also have to consider the risks of offshoring key infrastructure addressed in
S1.J which can make the protected host more vulnerable to attacks because they must trust
that the service they are using will implement best practices in security and will not
compromise their data (ISACA). One of the potential issues we discovered in a model that we
explored gave clients the certificate to allow them to act as the host and perform malicious
activities. This would increase risk for the protected host.
Understanding the framework, we were able to recognize that we needed to analyze
potential risks our proposed application could create (S1.J) even though it is intended to
mitigate risks for companies like mentioned(S1.A). We also recognized the importance of
understanding the technical foundations that the application would be built on in order to
recognize potential risks that the concept would cause. This crowd-sourced technology could
shine new light on this growing trend and how it could create IT risks for companies. Many

11. 11
risks for this specific use case are explored in this paper and could be referred to as potential
risk cases in COBIT.
VI. TECHNICAL FOUNDATIONS
Secure Socket Layer (SSL) is essential for web applications with sensitive information
to securely communicate with a client’s browser. It is important to understand this
encryption protocol because current DDoS mitigation techniques often require access to SSL
encryption in order to filter through the traffic. When a browser attempts to connect to a
website that is secured with SSL, it will request that the web server identify itself. The
website host will send an SSL certificate signed by a root certifying authority. The browser
(or client) checks that SSL certificate has been signed by a trusted root certifying authority
and if so it sends a sends a message to the server. An “SSL handshake” occurs which validates
the identity of the remote host and opens an encrypted tunnel. Now all communication sent
between the client and the host is encrypted. The host uses the private key of the SSL
certificate to decrypt the client’s traffic.
Domain Name Service (DNS) Propagation is essential to the network routing
architecture of the proposed application and affects performance of the application. There
are thousands of DNS servers located around the world that store domain names and an
associated IP address. This allows users to type in an address such as “foo.com” into the
browser and your browser will know to take you to the IP address associated with that
domain name. When there is a change in host provider or the domain name for an IP address
changes, a DNS change is made and every DNS server in the world needs to update their
record for the domain name and associated IP address. Unfortunately, propagating through
the entire network of public DNS servers usually take from several hours to 5 days and in

12. 12
some cases even 7 to 10 days. During this time, traffic can go to either location (old or new
IP) depending on which DNS server the user is accessing. This means users will see differing
servers during propagation. This process can take even longer depending on when the user
has last accessed the site. The user’s local DNS server can cache the IP address of a domain
and send the user directly to the cached IP address instead of accessing the public DNS
server again. The time the information is cache is limited and once the cached record
expires, the user’s browser will access the public DNS server again to obtain the IP address
for the domain.
VII. METHODOLOGY
First, we maximized guidance from our sponsor, meeting for 1 to 1.5 hours on a weekly
basis. We spent multiple meetings discussing the architecture of the solution that our
sponsor proposed before doing independent research on the technical foundations that this
infrastructure would depend on. We also spent time learning about these technical
foundations from an experienced industry professional with extensive experience in IT
security.
To be able to understand the frameworks of this proposed application and draw
conclusions regarding its feasibility, we needed to understand the basics of the various
protocols the application would interact with. First, the front-end deals with communication
between the browser and the protected host. Because a significant number of sites are
secured with SSL, it was essential for us to understand the fundamentals of how SSL worked
in order to comprehend how the application would sit in the middle to facilitate the
communication and filter out illegitimate traffic.

13. 13
To address the backend processes required for this application, we researched
extensively on DNS propagations and how IPs are utilized in typical DDoS mitigation
strategies. We decided to produce a prototype of the backend to develop a better
understanding of the network routing architecture design for a crowd-sourced DDoS
mitigation platform. To accomplish this we developed a process to intercept incoming traffic
and pass it along to clients.
Our plan was to extensively research the fundamental aspects how the application
would operate with protected hosts, clients, and browsers/end users. If the crowd-sourced
DDoS mitigation application proved to be feasible we would move on to building a more
comprehensive prototype to demonstrate the functionality of such an application. Part of the
motivation behind developing an initial prototype of the potential application’s backend
during research was to actively apply our theoretical knowledge. Unfortunately, when we
discovered that there were many security and performance issues facing the various models
we explored, we had to readjust the direction of our project. We analyzed our findings to
understand the implications of the security threats that the application would face. In
response to this, we conducted more research regarding current viable DDoS mitigation
solutions that exist in order to recommend DDoS protection solutions that would help
increase security for our target audience.
VIII. FINDINGS AND IMPLICATIONS
There are three ways that we approached the front-end aspect of this project however
both methods presented many problems. The first method distributes the bandwidth needed
across multiple clients but presents various security issues. The second method we
developed in response to that finding is more secure but ultimately does not address the

14. 14
bandwidth issue. In fact, we discovered that it would need more bandwidth than if the
service was performed without the crowd-sourced client. The third method does not
implement the DPI protocol. Instead the client attempts to determine whether or not to
forward the encrypted packet simply based on header and metadata information without
knowing the contents of the packet. However, due to the nature of the DNS propagation, we
learned that this method could significantly impact the performance of the trusted host.
Method One: Clients sit in the middle and decrypt traffic, perform Deep Packet Inspection (DPI),
re-encrypt the traffic, and send the traffic to the protected host.
As we mentioned in the introduction, current mitigation technologies sit in the middle
between the browser and the host to route traffic accordingly. To perform this task massive
and expensive bandwidth allocations are required. With the bandwidth being the scarce
resource, our first method looked into our team’s idea of offloading the bandwidth
allocations by using extra bandwidth available from participating clients (individual clients
with PCs or companies with extra bandwidth), thus decreasing the costs. These clients would
be incentivized through monetary compensation to participate depending on the amount of
bandwidth they contribute to alleviate these attacks.
In order to distribute bandwidth to the client, the client would sit in the middle
between the browser and the protected host. When the browser attempts to connect with
the SSL secured website, it will first be routed to the client. The client is perceived as the
domain. The protected host provides the client with the root certificate so that it can sign as
the protected host and be able to perform DPI, determining whether or not the traffic is
legitimate. If the traffic is determined to be illegitimate, it drops the connection or leaves the
connection open and the attacker will never receive a response. If the traffic is legitimate the

15. 15
client will re-encrypt the traffic and send it to the protected host. This model is based off of
Cloudflare’s DDoS mitigation tactics, but replaces bandwidth coming from the company’s
servers with crowd-sourced bandwidth.
Method One Implications
This solution presents several problems. If the client has access to the root certificate to
decrypt and perform DPI, they have the ability to impersonate the website. The client can
take legitimate traffic, reroute the end user on the browser to a website that looks like the
protected host’s site on the client’s server, record any login or sensitive information that the
end user may enter and reroute that traffic to the protected host inputting the login
information entered. Doing so, the client is able to steal sensitive information without the
end user’s or protected host’s knowledge. This solution gives clients the ability to perform a
malicious man-in-the-middle attack. A basic tenant of software design is to never trust the
client but to trust the server. This model places too much trust in the client and creates many
vulnerabilities for the end user of the browser and the protected host.
Another issue this method will face is proof of bandwidth. Clients will be paid based on
the amount of bandwidth that they use to mitigate DDoS. However, without a central server
measuring the amount of bandwidth that is being passed through, as the mitigation process
is done through the clients, there is no way to ensure that the client is telling the truth when
reporting the amount of bandwidth that they used. This is another dilemma that is faced
because the client cannot be trusted.
Method Two: Reroute the traffic to a trusted proxy that will hold the root certificate and
decrypt and encrypt the information before sending traffic to the protected host. The client
would only be responsible to perform the DPI.

16. 16
In this model, we address the security threat that the first method will present. A
trusted proxy would be placed in the center that will handle the decryption of the packet.
The trusted proxy would then send the decrypted packet to the client to perform a DPI. The
client sends the trusted proxy information regarding whether or not the traffic is legitimate.
The trusted proxy will drop the connection if illegitimate and if the traffic is legitimate, the
trusted proxy will re-encrypt the information before sending it to the protected host.
Method Two Implications
This method is certainly more secure than the first one. You do not trust the client
with the root certificate so it is not plausible that they could impersonate the protected host.
Only the trusted proxy handles the root certificate, decryption, and re-encryption. However,
in order for the trusted proxy to accept incoming traffic and pass legitimate traffic to the
protected host, the trusted proxy will need the amount of bandwidth that is being passed
along. It will then require extra bandwidth for the proxy to pass the decrypted packet to the
client to perform a DPI and for the client to send a response. The bandwidth needed for this
proposal would exceed the bandwidth needed for a centralized service like Cloudflare, thus
defeating the purpose of trying to minimize costs by allocating bandwidth. It would be more
cost effective to drop the client and run all protocols through the trusted proxy like
Cloudflare does.
Method Three: Clients determine whether or not encrypted packets are legitimate traffic by
looking at the header and metadata instead of decrypting the packet.
This method uses the same network model as method one, but does not give clients
access to sensitive information contained within packets. It uses a CONNECT tunnel to proxy
the traffic without decrypting it. Clients attempt to determine whether or not the traffic is

17. 17
from a real user or a botnet by examining the metadata and packet header information. This
also addresses the bandwidth issue that method two did not address while keeping sensitive
information safe, something that method one was unable to do.
To understand how we came to the conclusion that the idea of crowd-sourced DDoS
protection would cause performance issues, it is important to explain the architecture of
network routing on the backend of this proposed application. This backend architecture
would apply to first method that we investigated as well. So the performance problems
associated with the backend would affect both the third and first methods in addition to the
security issues found in the first proposal.
In order for the client to receive the traffic the domain needs to be associated with the
IP address offering the protection service in the public DNS servers. Like Cloudflare, when
the protected host is set up with the service, the client IP addresses performing the DPI are
recorded and stored in a central server. The central server would assign various IPs to the
domain of each protected host and publish these entries to public DNS. After the newly
assigned IP addresses propagate through the public DNS servers, traffic would then be
directed first to the client before the client redirects legitimate traffic to the protected host.
Method Three Implications (DNS Propagation issues applicable to Method One)
The downside of this method is that with such a simple filtering mechanism, false
positives are likely as well as false negatives leading to poor user experience when their
connection/session gets dropped or poor protected host experience when they receive
illegitimate traffic that could have been filtered if DPI or other more advanced methods had
been employed. Additionally, this method still does not address the DNS propagation issues.

18. 18
As mentioned under technical foundations, it takes a significant amount of time to
propagate a new assigned IP address through the entire public DNS server network. This is
not a significant concern if it’s a one-time propagation during implementation for a new
protected host. However, if participating clients’ IP addresses were connected to the domain,
that leaves protected hosts vulnerable to significant downtime. Static IPs and reliable uptime
are needed in order for DDoS mitigation strategies to work. Unfortunately, we return to the
rule that clients cannot be trusted. There is no way to enforce static IPs and reliable uptime
when the strategy is dependent on the client to provide these factors. Most consumer level
internet connections are dynamic and not static. Additionally, clients can shut off their PC,
rendering their IP addresses unavailable. If all clients assigned to a protected host were
suddenly offline, new clients and IP addresses would need to be assigned to the domain of
the protected host. As we know from DNS propagation, this process is slow and can take
from several hours to several days. This would mean that the domain would be unavailable
to users searching for the site until DNS propagation is complete. During the DNS
propagation, some users may be able to access the new assigned IPs depending on the public
DNS server they are connected to (as the information is updated for each DNS server at
different times), but not all users would know about the new IP.
IX. PERFORMANCE METRICS
Rather than defining performance metrics for this specific proposed solution which we
concluded was infeasible, the proposed metrics could be used by companies or individuals to
evaluate the effectiveness of any DDoS mitigation service.
First it is important to take a look at load time and requests before and after
implementing a DDoS mitigation solution. If the solution is effective and illegitimate traffic

19. 19
has been filtered out, it should decrease load time and the host should experience fewer
requests. Protected hosts should also take a look at the amount of bandwidth used after
using a solution. The expected reduction in traffic should show a decrease in the use of
bandwidth. Additionally, bandwidth usage should decrease because the bandwidth to filter
through traffic is offloaded to a third-party solution.
X. LIMITATIONS AND FUTURE WORK
The architecture and operational functionality of the crowd-sourced DDoS mitigation
idea explored only addresses flood type DDoS attacks. Although this is the most common
form of DDoS attacks, it does not provide protection from other DDoS attacks such as a DNS
amplification attack. Therefore, this solution is limited to tackling only one form of DDoS
attack which does not offer the protected host complete protection from DDoS attacks.
Proof of bandwidth is one of the many issues that plague the first method of this
application because the client cannot be trusted. How can we prove that the client is using as
much bandwidth as they claim when all the work is routed through the client? This flaw
allows clients to exploit the business model by claiming to process more bandwidth that they
are in order to receive additional monetary compensation. Currently there is no technology
that exists that solves the proof of bandwidth problem for decentralized networks. However,
there has been research done that tries to solve this problem. A study from Yale University
and the US Naval Research Laboratory proposed an alternate cryptocurrency using the
bitcoin protocol but with a proof of bandwidth concept instead of proof of work (Ghosh,
Richardson, Ford, & Jansen, 2015). While the ideal is still just a proof of concept, one of the
authors of the paper claim that researchers are now, “developing a prototype, and/or a
network simulation to run experiments” (Quentson, 2014). If this proposed “proof of

20. 20
bandwidth” solution proves to be feasible, future work done on the DDoS mitigation project
should apply this technology.
Due to the security threats the only real solution to approaching this problem while
saving bandwidth is to never let the client hold the certificate. This means clients need to
inspect traffic based on the header information of the packet but header information can still
be spoofed. Even if headers weren’t spoofed there would be issues with latency due to DNS
propagation and unreliable clients and dynamic IPs. If the clients were somehow able to
provide reliable uptime and static IPs, this solution would still not be scalable in the future.
In January 2014, the pool of the top million websites with SSL encryption increased by 48%
compared to the previous year (Netcraft, 2014). An additional half a million more SSL
certificates were in use as compared to the previous year in January 2013 (Netcraft, 2014).
As of November 2015, at least 64.4% of the top 10 million websites use an SSL certificate
authority (Q-Success Consulting, 2015). Future work regarding this project needs to address
sites with SSL encryption. If there is no way to implement this model without compromising
the protected host’s security, there needs to be fundamental changes to the infrastructure of
the concept such as using a centralized solution without crowd-sourcing bandwidth like
current DDoS strategies.
XI. RECOMMENDATIONS
Due to the infeasibility of the proposed application, it is important to give the target
audience recommendations on how they can still protect themselves with DDoS attacks
using other applications.
Although the majority of sites in the top 10 million sites use SSL, a startling 35.6% of
those sites still do not use SSL encryption (Q-Success Consulting, 2015). While this is not

21. 21
directly related to DDoS attacks, this discovery in our research is important enough to
address to help the target audience improve basic web security. The reason that SSL is
important is because it prevents a third party from being able to eavesdrop on an encrypted
connection. Only intended parties can read and understand the information being
communicated. SSL is required to meet various compliances such as PCI. Even Google has
gotten involved with encouraging companies to adopt SSL by giving an SEO boost to sites
that implement a SSL 2048-bit key certificate (Schwartz, 2014).
Although this solution isn’t feasible based on the constraints that crowd-sourcing puts
on the model, there are many companies that offer technologies to combat DDoS with a
centralized model. Companies such as Cloudflare or Incapsula have dedicated servers
around the world with static IPs and reliable uptime that can provide protection against
DDoS attacks. Their centralized model only creates DNS latency during the implementation
of the technology and because they have static IPs, they are generally able to provide
consistent service without downtime due to constantly shifting IP addresses and slow public
DNS propagation.
There is no need to trust an outside “client” for centralized companies because they
provide the services. Trusted companies that offer services like these are “good” man-in-the-
middle agents. They filter through traffic with their own servers and discard illegitimate
traffic to prevent protected hosts from being flooded and taken down. What’s important for
these companies is to ensure that they are using best security practices to ensure that their
service is not compromised. Although they don’t have to trust a client to handle the
certificates, they still have to handle certificates themselves. If that access were to be
compromised, perpetrators could gain access to the certificates and impersonate protected

22. 22
hosts for malicious activity. When deciding what service to use, it’s important to go with a
service with a proven track record and trusted reputation. Cloudflare is one of the biggest
DDoS mitigation providers and takes up 77.83% market share of Alexa’s listing of top 1
million websites as of November 21, 2015 (Datanyze, 2015).
For smaller to medium businesses or even individuals that cannot afford to pay
enterprise prices, many solutions do offer smaller plans at more cost-effective prices.
Cloudflare offers both free and “pro” services with pro services being priced at $20 a month.
Both of these plans offer basic DDoS protection as well as SSL encryption.
XII. CONCLUSIONS
Until a few years ago, DDoS was mainly used as a form for perpetrators to gain
attention in the form of fame or notoriety or simple because they did not agree with the
motivations of a company or political figure. As DDoS attacks become more prevalent, they
are being used as a competitive tool or for bad actors to create a distraction while executing
their true, more malicious intentions elsewhere. DDoS attacks that used to mainly focus on
large enterprises are now affecting medium and even smaller businesses. Traditional
firewalls and intrusion detection systems that many companies employ are not enough to
defend against DDoS attacks.
We explored the possibility of creating a cost-effective solution to protect small to
medium businesses that could scale to protect larger enterprises as well. Because the need
for exorbitant amounts of bandwidth is expensive, the idea revolved around gathering
unused bandwidth from participating clients (incentivized with a small monetary
compensation depending on bandwidth used) to filter through the traffic. By creating an

23. 23
application that is more affordable, we could encourage more companies to adopt more
advanced DDoS protection strategies.
We discovered that the fundamental aspect of crowd-sourcing the bandwidth would
require the client to have too much authority that they could used to react maliciously. If we
addressed this issue and only feed traffic through a trusted proxy first, this requires the
trusted proxy to have sufficient bandwidth to route all the traffic, negating the goal of trying
to save bandwidth. If we try to respond to both issues by allowing clients to only the header
which does not require a certificate, slow DNS propagation and unreliable clients would still
create performance issues that could take down a protected host for several hours or several
days and we risk letting in illegitimate traffic or dropping legitimate traffic.
We also made the discovery that while most of the top ten million sites use SSL
encryption, over one third still did not. SSL allows hosts to encrypt sensitive information and
provides authentication. Not only is this more secure and required by many compliances
such as PCI, but sites protected by SSL are more trusted by users.
Despite our conclusion that the project is currently infeasible at the time with current
technology, our target audience of various sized corporations, professionals, or even
individuals can still find protection from these attacks from existing solutions. These existing
solutions offer various plans targeted for larger enterprises or more cost-effective plans for
smaller business or individuals. Many of these plans also include SSL encryption capabilities
for sites that do not use this protocol.
Although crowd-sourcing has been wildly successful for other applications like crowd
funding, we believe that our research indicates the DDoS mitigation market will currently
not be able to join that trend.

24. 24
XIII. REFERENCES
Arbor Networks, Inc. (2013). What is a DDoS Attack? (Google Ideas) Retrieved September 1,
2015, from Digital Attack Map: http://www.digitalattackmap.com/understanding-ddos/
Datanyze. (2015, November 21). CloudFlare market share in the Alexa top 1M. Retrieved
November 21, 2015, from Datanyze: http://www.datanyze.com/market-
share/accelerators/cloudflare-market-share
Ghosh, M., Richardson, M., Ford, B., & Jansen, R. (2015). A TorPath to TorCoin: Proof-of-
Bandwidth Altcoins for Compensating Relays. Retrieved November 1, 2015, from
http://www.robgjansen.com/publications/torpath-hotpets2014.pdf
Imperva. (2015). The Top Ten DDoS Attack Trends. Retrieved October 5, 2015, from
Imperva:
https://www.imperva.com/docs/DS_Incapsula_The_Top_10_DDoS_Attack_Trends_ebook.pdf
ISACA. Vendor Management COBIT 5. ISACA.
Ko, C. (2012, July 9). New COBIT 5 framework to guard against cloud threats. Retrieved
October 20, 2015, from ISACA: http://cw.com.hk/feature/new-cobit-5-framework-guard-
against-cloud-threats
Matthews, T. (2014). Incapsula Survey : What DDoS Attacks Really Cost Businesses.
Retrieved September 5, 2015, from Incapsula:
http://lp.incapsula.com/rs/incapsulainc/images/eBook%20-
%20DDoS%20Impact%20Survey.pdf
Netcraft. (2014, February). January 2014 Web Server Survey. Retrieved November 12, 2015,
from Netcraft: http://news.netcraft.com/archives/2014/01/03/january-2014-web-server-
survey.html
Q-Success Consulting. (2015, November 11). Usage of SSL certificate authorities for websites.
Retrieved November 13, 2015, from Web Technology Surveys:
http://w3techs.com/technologies/overview/ssl_certificate/all
Quentson, A. (2014, June 6). TorCoin: Making Anonymity Pay. Retrieved November 1, 2015,
from Crypto Coins News: https://www.cryptocoinsnews.com/torcoin-making-anonymity-
pay/
Schwartz, B. (2014, August 7). Google Starts Giving A Ranking Boost To Secure HTTPS/SSL
Sites. Retrieved October 15, 2015, from Search Engine Land:
http://searchengineland.com/google-starts-giving-ranking-boost-secure-httpsssl-sites-
199446
Seals, T. (2015). DDoS-for-Hire Costs Just $38 per Hour. Retrieved September 1, 2015, from
Info Security Magazine: http://www.infosecurity-magazine.com/news/ddosforhire-costs-
just-38-per-hour/