Tải bản đầy đủ (.docx) (20 trang)

A Resilient Peer-to-Peer System for Denial of Service Protection

Bạn đang xem bản rút gọn của tài liệu. Xem và tải ngay bản đầy đủ của tài liệu tại đây (816.46 KB, 20 trang )

1
University of Engineering and Technology
STUDENT SCIENTIFIC RESEARCH CONTEST
YAER 2012
Name of project: A Resilient Peer-to-Peer System for Denial of Service Protection
Student’s name: Lê Ngọc Anh Male
Class: K53CA Faculty: Computer Science
Instructor:
Dr. Nguyễn Đại Thọ

Hà Nội, 3/2012
2
Summary
Since the Internet appears and becomes popular, Denial of service (DoS) attacks continues to
threaten the reliability of networking systems. All most previous approaches for protecting
networks from DoS attacks are reactive in that they wait for an attack to be launched before
taking appropriate measures to protect the network. Nowadays, with the development of
information, programs, there are more sophisticated methods that attacker using to attack
victim. Moreover, with limited infrastructure of ISP (Internet Service Provider) .So there is a
requirement that we need a system which can easily add into network without changes in
infrastructure. And WebSOS is solution for that requirement. WebSOS has architecture
constructed using a combination of secure overlay tunneling, routing via consistent hashing,
and filtering. It contains an overlay with many nodes which receive requests from user and
check those requests belong to user or zombie by a captcha test. Then only valid will be
forward to server. System WebSOS reduces the probability of successful attacks, however it
will be dangerous when nodes being attacked and become malicious nodes. So this scientific
research will mention about improvements that be able to detect those node and change query
from user to server through overlay.
3
Contents
List figure


Figure 1: three-way handshake 6
Figure 2: Basic SOS architecture. 12
Figure 3: Chord routing 13
Figure 4: sample captcha test 14
Figure 5: Sos Proxylet Applet 14
Figure 6: Sos Proxylet Applet 15
Figure 7: Access successful via WebSOS 18
4
1. Problem statement
Nowadays, with the Internet explosion bring to human many benefits. It make human in all
over the word can communicate together easily, work more effectively. Besides that, the
Internet is also an object of many attacks and one type of attack that many current attackers
using is Dos (Denial of service) attack. Moreover, with the development of information,
programs, there are more sophisticated methods that attacker using to attack victim and it
hard to detect and defense again attack with limited infrastructure especially in small and
medium system. So that WebSOS has been developed to address this problem. WebSOS in
an overlay network that will check all requests sent to server, and only valid requests that
pass captcha test are able to go to server. WebSOS is a good system for distinguish request
from real user and zombie. However, WebSOS assume that all nodes in system are safe and
work right. Therefore this report will mention about improvement that be able to detect,
remove malicious nodes to guarantee query from real user can go to server.
2. An Overview of research problem
2.1 Definition of Dos attack [1]
A denial-of-service attack is different in goal, form, and effect than most of the attacks that
are launched at networks and computers. Most attackers involved in cybercrime seek to break
into a system, extract its secrets, or fool it into providing a service that they should not be
allowed to use. Attackers commonly try to steal credit card numbers or proprietary
information, gain control of machines to install their software or save their data, deface Web
pages, or alter important content on victim machines. Frequently, compromised machines are
valued by attackers as resources that can be turned to whatever purpose they currently deem

important.
In DDoS attacks, breaking into a large number of computers and gaining malicious control of
them is just the first step. The attacker then moves on to the DoS attack itself, which has a
different goal—to prevent victim machines or networks from offering service to their
legitimate users. No data is stolen, nothing is altered on the victim machines, and no
unauthorized access occurs. The victim simply stops offering service to normal clients
because it is preoccupied with handling the attack traffic. While no unauthorized access to
the victim of the DDoS flood occurs, a large number of other hosts have previously been
compromised and controlled by the attacker, who uses them as attack weapons. In most
cases, this is unauthorized access, by the legal definition of that term.
5
2.2 Attack methods
In almost attack, to make a successful attack, attackers have to build a Botnet(2) system, in
another way is recruitment of the Agent Network. Depending on the type of denial of service
planned, the attacker needs to find a large number of vulnerable machines to use for
attacking. This can be done in a completely automated manner, semi-automatically, or
manually. In the cases of two popular DDoS tools, trinoo and Shaft, only the installation
process was automated, and discovery, compromise of vulnerable machines were done
manually. Nowadays, attackers use scripts that automate the entire process, or scanning to
identify already compromised machines to take over (e.g., Slammer-, MyDoom-, or Bagle-
infected hosts). It has been speculated that some worms may be used explicitly to create a
fertile harvesting ground for building bot networks that are later used for various malicious
purposes, including DDoS attacks.
Some methods of causing a denial of service that attacker prefer to use:
2.2.1 Attacking a Protocol:
An ideal example of protocol attacks is a TCP SYN flood attack. A TCP session starts with
negotiation of session parameters between a client and a server. The client sends a TCP SYN
packet to the server, requesting some service. In the SYN packet header, the client provides
his initial sequence number (x), a uniqueper-connection number that will be used to keep
count of data sent to the server. When SYN packet receipt, the server allocates a transmission

control block (TCB), storing information about the client, then replies with a SYN-ACK,
informing the client that its service request will be granted, acknowledging the client's
sequence number and sending information about the server's initial sequence number (y). The
client, upon receipt of the SYN-ACK packet, allocates a transmission control block. The
client then replies with an ACK to the server, which completes the opening of the
connection. This process message exchange is called a three-way handshake and is descript
in this figure
6
Figure 1: three-way handshake
The idea is server's resources allocation for client when receive SYN packet. When the server
allocates his a transmission control block and replies with a SYN-ACK and the connection is
half-open. The server's allocated resources will not be using until the client sends an ACK
packet then closes the connection or until a timeout expires and the server will closes the
connection and releasing the buffer space. So the attacker generates a multitude of half-open
connections by using IP source spoofing. These requests quickly exhaust the server's
transmission control block memory, and the server cannot accept any more incoming
connection requests. The transmission control block records spaces they were using will be
exhausted by the attack, other legitimate connections cannot go to. In rare cases, the server
machine crashes, exhausts its memory, or is otherwise rendered inoperative. In order to keep
buffer space occupied, the attacker needs to generate a steady stream of SYN packet toward
the victim. This is an attack is particularly dangerous, when the server receives a large
number of SYN packets and legally cannot easily distinguish the packets from legitimate
customers with packages from attack traffic. To successfully implement a SYN flood attack,
an attacker needs to locate open ports on the victim's machine. Then, just send a small packet
traffic, range 10 SYN / minutes can slowly squeeze the victim's resources. A SYN attack is
less common overflows SYN packets with random port. In particular, the attacker creates a
large volume of TCP SYN packets targeting the victim's random port, and aims to
overwhelm the victim's network resources, rather than filling the buffer memory of the
victims. Attacks on protocols can be difficult to resist by means of repair, creating a patch.
7

By creating patches required to change the protocol, while the fact that the internet protocol
change is almost impossible. In some cases, the current protocol used wisely they can solve
the problem. As the use of TCP SYN cookies can solve the SYN packet that overflows just
change the server to handle the connection.
2.2.2 Attacking Middleware
Attacks can be made on algorithms, for example hash functions normally perform its
operations in linear time for each subsequent entry. By using values that force worst-case
conditions to exist such as all values hashing into the same bucket, the attacker cause
application to perform their functions in exponential time for each subsequent entry .So the
attacker can freely send data that is processed using the vulnerable hash function, it can cause
the CPU of the server to exceed capacity and degrade what would normally done in a second
but now it takes several minutes to complete. So that it does not take a very large number of
requests to overwhelm some applications
2.2.3 Attacking an Application
The attacker send a large number of packets to reach the limit of service requests that
application can handle. For example, Web servers take a certain amount of time to serve
normal Web page requests, and thus there will exist some finite number of maximum
requests per second that server can process. We assume that the Web server can process
10,000 requests per second, so at most 10,000 customers' requests can be processed
concurrently. And the normal load a Web server sees daily is 1000 requests per second.
But what if an attacker controls 20,000 hosts, and can force each one of them to make one
request every 2 seconds to the Web server? That is an average of 10,000 requests per second,
and added to the normal traffic so the results is more than 100% of the server's capacity.
Therefore a large portion of the legitimate requests will not be accepted through because the
server is saturated.
2.2.4 Attacking a Resource
Resource can be target of attack, such as CPU cycles, in this attack, attacker force the CPU of
system work more than needed. Or with resource is router switching capacity, this type of
attack could be disastrous if the network is not well thought. For example, In January 2001
an attack against the router that direct traffic to Microsoft Web site was perform. When news

of this attack were known it was discover that all Domain Name Server (DNS) were on the
same segment of the network. When the router was under the DoS attack, no Web sites of
Microsoft were accessible anymore.
2.2.5 Pure Flooding
Flooding attacks are also known as bandwidth consumption attacks. This type of attack is
just sending the maximum possible of packets to the victim with purpose to use all the
8
possible bandwidth of the target. It is hard for the target to handle this kind of attack alone so
in many case servers need help of the Internet Service Provider (ISP). A filter of the packets
be done directly by the ISP, if the packets of the attack have an easy signature to discover as
large UDP packets to unused ports or IP packets have protocol value of 255. The filtering
might be easy and quick to set-up. If attacking packets are well crafted, and looks like
legitimate traffic, it is hard to filter it.
2.2.6 IP Spoofing [3]
In normal IP communications, the header field contains the source IP address and the
destination address set by the default network socket operations. IP spoofing is a malicious
program creates its own packets and does not set the true source IP address in the header of
packet and send them out over the network.
There are some ways to make a IP spoofing attack
• Random IP address fully: malicious program will create file with header contain IP at
random from the entire IPv4 space, from 0.0.0.0 to 255.255.255.255. This type can
create invalid IP such as 192.168.0.0 (this for private network) or multicast addresses,
broadcast addresses. But almost IP value created is valid.
• Subnet spoofing: for example with the 192.168.1.0/24 network, a machine in this
network can easily spoof a neighbor (such as 192.168.1.34 or 192.168.1.45) with IP
in 192.168.1.0/24 range
• Spoofing the victim's addresses: in this attack scenario the host forges the source
address in service request packets (for example, a SYN packet for a TCP connection)
to flood service replies to the victim. If there is no filtering of packets as they will
leave the source network.

In fact, IP address spoofing is not necessary for a successful DDoS attack, because an
attacker could exhaust resources and capabilities of the victim with a large number of packets
that do not relate to the source address. However, some attackers use IP Spoofing for a few
reasons, as to hide the address of the agent, thereby concealing the address of the attacker's
handler and better, or used for attack DDoS regions reflected a form of today's most powerful
attack spoofing the IP address of the victim to require some major server sends the query to
the server legitimate victims, resulting in the victim attacked the server in the world, and can
not succumb. IP Spoofing attacker also help overcome the defense mechanism of a number
of servers as they save the address of regular customers and used it as a trustworthy list of
priority access in case of attack
2.3 Previous Dos defense
2.3.1 Pushback
Pushback, proposed by Mahajan, [4], the idea, taken from practice, is that network operators
try to push back offending traffic toward the source, either crudely by unplugging a network
9
cable in the router and monitoring whether the bad traffic stops, or by observing network
traffic on monitoring equipment. Limit the rate of packets sent out from the victim
(pushback), then reduce pressure on the victim, allowing it to exchange traffic and exists in a
time effective to stop the attack source or removed. This assumes that the offending traffic is
not evenly distributed across all possible ingress points.
There are two techniques used here: The local Aggregate Congestion Control (ACC) and
pushback. Congestion control of local-level synthesis detect congestion at the router and set a
signal to attack (or more appropriately in each context), a congestion signal, which can be
translated into a router filters. The signal defines a set of high bandwidth, a subset of network
traffic, and congestion control integrated local limits determine the appropriate rate for that
set. Then pushback rate limit is sent immediately to the adjacent upstream traffic, which
contribute the bulk of the traffic aggregate. This mechanism works best against DDoS attacks
to flood and flash, as they share common characteristics, and try to handle the phenomenon
from the perspective of congestion control. The set limits are too high rate of traffic can
make valid also limited, losses, and to set limits so low that an attacker can overcome the

common security. Over all, pushback seems to require the deployment model approach to the
router. Current approach can not push through a rate limited router without understanding
pushback method. Pushback routers also require states to maintain traffic flow, there is an
increasing burden on the network infrastructure of the method.
2.3.2 SIFF: An End-Host Capability Mechanism to Mitigate DDoS Flooding Attacks
Yaar [5] proposed to mitigate DDoS flooding attacks using a mechanism in the ability of the
end host can distribute Internet traffic is split into two classes: privileged and unprivileged.
Last Host Capabilities exchange can be used in transportation privileges. The router will then
verify these capabilities stateless. These Capabilities are delivered in a dynamic mechanism,
so your wrong behavior (air attack) may be able to be withdrawn Capabilities. In contrast to
other approaches, this plan does not require a cover mechanism, but it does require a
modification of the client and server, as well as both routers again. The client uses a
handshake protocol to exchange capacity, and then the privilege of traffic will be expedited
by the network, as opposed to non-privileged communication that will not receive
preferential first. There are regulations in place to prevent the attacker sends traffic overflow
with the privileges of an unauthorized person, for example, by a person trying to create
Capabilities (done by marking in each packet). Capabilities If a client starts to flood, then the
flow of information access privileges can be revoked for that client.The authors of this
mechanism proposed two roads: one is the mechanism for next-generation Internet combine
these techniques and is a mechanism for the current protocol in IPv4 network. It is unclear
that the roads will prove effective or not.In summary, this technique also accept several
assumptions, including assuming the client and server software updates in TCP / IP to
incorporate the necessary modifications for the new Capabilities. The advantage is no need
for inter-ISP-or co-operation between ISPs. However, it also assumes that fraud is limited,
and the handling and maintenance of status is required at each router. The new network
protocol requirements in the space marked IP packet header, the client and collaboration
server, every router to mark packets, and routes between the machines on the network
10
remains stable. The assumption is quite limited, compared to what can happen in a real
network.

2.3.3 Pi
Pi, proposed by Yaar [6], is a target system to protect victims, based on packet marking
techniques mentioned measures traceback, path identifiers inserted into the unused entries in
IP packet header. The main idea is the path identifier or fingerprint authentication is inserted
by the router along the network. The target or victim will then reject the packet identifier
matches the path the packet has been clearly identified as part of the attack. In Pi marking
scheme Basically, each router participating in certain mark bit IP identification field of IP
packets. The location of the symbols in this field is determined by the value of the TTL (time
to live) of the packet. The symbol is part of the hash of the IP address of the router. Because
the TTL value is reduced at each router, a road junction of the packet when it was built closer
to the victim. One can decide to stop marking in a certain distance leg of the victim network
to increase capacity to the destination of the packet in this scheme. Pi filters can occur once
the mark has been installed in the infrastructure. This scheme assumes that victims know
how to identify a large number of attack traffic, for example, by choosing a large portion of
traffic to take a similar mark. Then the filter throws away all traffic with certain brands.
Inadvertently, some legitimate traffic sharing the brand with the attack (as it also shared the
path to the victims due to the variation and adaptive nature of the network) will also be
reduced, loss.
2.3.4 D-WARD
D-WARD, proposed by Mirkovic and colleagues [7] on May 8-2003, was developed at
UCLA under DARPA funding of the program Fault tolerant Network (FTN). Network-based
system aimed at detecting the source of attacks prior to or when they leave the networks of
DDoS agents. It is an inline system, transparent to the user on the network, through the
collection of statistics from the two-way traffic at the network edge router sources and
compare them with the traffic model network construction based on protocol and application
traffic, reflecting the normal (legal), suspected, or offensive behavior based on this three-tier
model (attack, suspected, normal), D-WARD limit the rate at router at all traffic going out of
a given destination, traffic prioritization legitimate connection, slightly slowing down
suspicious traffic, and slow connections tons of which it feels. Dynamic rate limit and change
over time, based on the observation of the signal to attack and the restrictive policies on

traffic negatively. Less traffic will mitigate negative policy restrictions.
2.3.5 NetBouncer
NetBouncer, proposed by O'Brien [8], also emerged from DARPA FTN program. This is a
mechanism for user authentication when the Server stands above the target network. Ideally,
it is positioned at the nodes of the network and aims to allow only packets from clients or
users 'legal'. Some test for legitimacy is done on the client, for example, a ping (ICMP Echo)
was sent to experiment whether a customer is behind the package was received by the
11
destination server, and a Reverse Turing test, test to distinguish between humans and
machines. The reader may have seen as a test when registering an e-mail account on Yahoo
e-mail service: customers are asked to enter a phrase or word distortion, shown in a picture
background makes it so difficult to read, a test that is often only a man can do, not a machine
or automated program. And if the tests pass, indicating the user is "legal", they are required
to keep the target Server. If not, NetBouncer terminates the connection.
2.3.6 Proof of Work
Another way to approach the problem of DDoS is to consider the problem of declining
attacks to connect. Multiple connections initiated by an attacker to eliminate the number of
open connections that a server can maintain. One goal of prevention is to conserve these
resources in such attacks. As protection, the server started handing out the challenge test, no
different than NetBouncer, client connection requests. This happens at the TCP / IP, by the
system should focus on the protection of resources related to network connectivity. The
distribution server encodes a small puzzle for the customer connection requests, and waits for
a solution. If the customer solves the puzzles in a certain time window, the appropriate
resources are then allocated in the same network caching (part of the operating system handle
the network interfaces). Customers but does not solve the puzzle of their connections will be
ignored. This approach forces the attacker to spend more time and resources before achieving
a successful connection to a server or a target, and slow speed that he can deplete resources
the server from any computer. While this is low overhead (the server is to create and verify
the puzzle), the actual TCP / IP implementation on both ends (client and server) must be
modified for this method to working. This prevention cannot handle this problem as scattered

attacks in which an attacker to create squeeze enough to ask the server resource squeeze or
attack resources for creating a puzzle or objective acceptance bandwidth of the network to
the server.
2.4 WebSOS
2.4.1 Architecture of WebSOS
WebSOS is based on the Secure Overlay Services (SOS) [8] architecture. Ideal of this system
is building an overlay network that will filter request to check which request from user which
request from attacker. Architecture of overlay is descript in figure below
12
Figure 2: Basic SOS architecture. SOAP stands for Secure Overlay Access Point, and
represents an entry point to the SOS overlay. SOS nodes can serve any of the roles of SOAP,
Beacon, or Secret Servlet.
Follow this architecture, request of user will come from Source Point to go to overlay and the
fist node in the overlay receive request is SOAP (Secure Overlay Access Point). This node
has the task to distinguish legitimate traffics from (illegitimate) attack traffics by a request
authenticate (such as login or in WebSOS is a captcha test). If user is valid, request will be
forward into overlay. Over lay network is seemed a discrete firewall, base on chord routing
and using hash function. There are 4 type of node in system and each node have specific
task:
SOAP: Secure Overlay Access Point and check the authenticate of user
Overlay node: normal node in overlay forward message inside overlay
Beacon: is only node knows address of Servlet
Servelt: is special node and only messages come from this node can be accepted by target
server.
After be authenticated by SOAP, SOAP will identified the IP of the target in request packet,
then using Hash function in this IP to get a value. This value will locate the Beacon so that
SOAP can forward request to Beacon node. When receive request, Beacon will read address
of target then forward to Servlet of corresponding target. Servlet receive request from Beacon
them forward it to target server.
Servlet using Hash function to address of server to decide which node in overlay become

Beacon, then send message to that node. So that node will become Beacon and know address
of Servlet with corresponding server.
13
In Server, it will setup a router to filter all packet sent to server and only packet sent from
Servelt that correspond to that server. Server chose node become Servlet and sent message to
that node.
2.4.2 Chord routing
About chord [9] routing which using to forward packet inside overlay. In Chord, each node is
assigned a numerical identifier (ID) via a hash function in the range [0; 2m] with some
predetermined value of m. All nodes in the overlay are ordered by these identifiers. The
ordering is cyclic, where the next node in the ordering is the next node along the circle in the
clockwise direction. Each overlay node maintains a table that stores the identities of m other
overlay nodes. The i th entry in the table is the node whose identifier x equals or, in relation
to all other nodes in the overlay, most immediately follows x + 2
i-1
. ( (mod 2
m
)), as shown in
Figure 3. When overlay node x receives a packet destined for ID y, it forwards the packet to
the overlay node in its table whose ID precedes y by the smallest amount. for example, if
node 7 receives a packet whose destination is the identifier 18, the packet will route from 7 to
16 to 17. When the packet reaches node 17, the next node in the overlay is 22, and hence
node 17 knows that 22 is responsible for identifier 18. The Chord algorithm routes packets
around the overlay “circle”, progressively getting closer to the desired overlay node. So just
O(m) overlay nodes are visited. Typically, the hash functions used to map nodes to identifiers
do not attempt to map two geographically close nodes to nearby identifiers. With all benefits,
the Chord service is a reasonable choice for overlay with many nodes.
Figure 3: Chord routing
And SOS uses the IP address of the target (i.e., web server) as the identifier to which the hash
function is applied.

14
2.4.3 Graphic Turing Tests
In order to prevent automated attacks from zombie machine, a CAPTCHA [10] visual test is
implemented at the entry point of the overlay to verify the presence of a human user.
CAPTCHA (Completely Automated Public Turing test to Tell Computers and Humans
Apart) is a program that generates and grade tests that most humans can pass, but automated
programs cannot. The particular CAPTCHA realization webSOS use is GIMPY, which
concatenates an arbitrary sequence of letters to form a word and renders a distorted image of
the word (such as example shown in Figure 4). GIMPY relies on the fact that humans can
read the words with the distorted image and pass the test while current automated tools
cannot. User is authenticated by entering as ASCII text the same sequence of letters as what
appears in the image. Updating the GIMPY interface to WebSOS can be performed without
modifying the other architectural components.
Figure 4: sample captcha test
15
2.4.4 Access and authentication mechanism
Figure 5: Access and authentication mechanism
First, users need to know SOAP and access to it. SOAP will be installing a web server to
perform the function test or CAPTCHA Graphic Turing Test-GTT, to confirm the visit made
by humans. CAPTCHA is a program that can generate tests that most humans can pass, while
the program is not automatic. In WebSOS, CAPTCHA is generated by the program
GIMPY.When the visitor has passed tests GTT, SOAP will provide the user with a short-
term X.509 authentication, encrypted access ip's to do authentication for access to web
services, to avoid the use for ip agent with another attack.Then, SOAP will require users to
run a proxy program applet (signed applets) to the user's browser to connect through a proxy
server applet that purpose, thereby creating the SOAP SSL connection. SOAP receives this
connection, and forwards network connections to the Beacon coverage appropriate, Beacon
will be forwarded to the Secret Servlet. From the Secret Servlet, the request is passed through
the filter to the target server. Found in the router's IP filtering Secret Servlet should accept
valid connection to the Server. This makes the user's connection becomes secure, and also

causes increased road route, caused a certain delay.
16
Figure 6: Sos Proxylet Applet
However, WebSOS has a matter that this system considers that all nodes in overlay is safe
and work right. Therefore, if one or some node in overlay have been attacked and become a
malicious node abet attacker to attack target. This scenario is very dangerous and can make
all system down.
3. Deal with problem
3.1 Improvement WebSOS
To improve WebSOS, in this report I will describe some scenario that some nodes have been
controlled by attacker and attack target via overlay. Base on that I will give measures
corresponding to each scenario. There are scenarios:
• Scenario 1:
Descried: one node in overlay is attacked and controlled by attacker. I assume that this node
is not SOAP. From this node, attacker will send query from machines that not be
authenticated with captcha test in SOAP to target and start flooding attack.
Measure: Using ideal checking value puzzles in OverDose [11] system, we setup a session
key between SOAP and server (with each time start up WebSOS, system will create new
session key). With small or experiment system, we can generate session key by hardcode.
But in huge system with number of nodes, session key will be created between
communications of server and SOAP by public key and private key that have been
authenticate. We indentified three value are session key (Ks), Address of SOAP (IPs) and
Address of client (IPc), then SOAP using Hash function in 3 value to get value X (X= H (Ks
17
|| IPs || IPc)). Then program adding this value X into all packets that sent from SOAP to
chord. In server, it will base on information that sent to get address of client and SOAP that
client connects to. After that server will use Hash function to three values Ks (had been
generate before) IPs and IPc (in received packet) to identify value X’, then comparing 2
value X and X’. If they are the same, which mean this client has pass captcha test, be
authenticated and packet is valid and accept. If not, that mean client is not authenticated and

this packet will be rejected.
With this measure, we can identify packet that sent from client connect to chord via a
malicious node and do not get through SOAP because only client connect to SOAP has right
value X.
• Scenario 2:
Descried: this attack is the same as scenario 1 but the danger is that node attacked is SOAP,
so that attacker can create valid X for client zombie connects to chord network and then
flooding attack server.
Measure:
This scenario is hard to detect but also frequency happed if attack occur because SOAP is the
first node that connect to client so that it also a target of attacker. To deal this problem we
need to build a traffic analysis and monitoring. So that measure is setting up a process in
server that controls flooding by identifying number of query that sending from client to target
via SOAP.
In target: we install a progress that can control flooding
Building an array 2 dimensional (name SOAParray) size nx3 (n is number of node SOAP)
// creat array and set default value (0)
For ( i=0, i<n ,i++)
SOAParray[0][i]=0
SOAParray[1][i]=0
SOAParray[2][i]=0
// create counter to determine position for SOAP in array
Count=0
//With each session key is created, increase counter and save address of that SOAP node
If (creat session key)
SOAParray[0][count]= IPs
Count ++;
// with each query from a client to server via SOAP, we increase counter query
TempCounterQuery = SOAParray[1][IPs]
SOAParray[1][IPs] = TempCounterQuery +1;

// after one hour (one session), reset all value
If (time session end)
For (i=0 , 1<n, i++)
SOAParray[1][i]=0
// after 5 minutes (time check), calculate average number of query
If (time check)
Average = Sum (SOAParray [1][]) / n
18
// Identify rate between each SOAP with average query
For (i=0; i<n, i++)
SOAParray [2][i]= SOAP[1][i]/Average
// check rate of query , if there is a node that have value more than safe vale, process will
warning
If ( SOAParray[2][i]) > safe && SOAParray[2][i]) < danger )
Give warning notification
If (SOAParray[2][i]) > = danger )
Give warning notification and deny all query via SOAP corresponding
If there are some valid query via this SOAP, after a period of time that it have not been
responded, this query will auto connect into new SOAP [12]
About safe value and dangerous value, these values can be change depended in each system
install WebSOS. However, I prefer to use 1.5 for safe value and 2 for dangerous value.
Experimental program is run in system with virtual machine in OS Ubuntu 10.04. Computer
with CPU core i5 2.4 GHz, Ram 4 Gb. WebSOS contains 3 modules:
Module CAPTCHA generates captcha test.
Module Secure Tunnel Proxylet written in Java language.
Communication Control Module and module Overlay Network (Chord) written in java, and
C languages, it is installed in all nodes.
3.2 Experiment
In the first scenario:
With original Websos, after control node, attacker begin flooding attack and resource attack

so valid user cannot access to target.
With WebSOS has improvement by adding value X by using Hash function has address
danger when a node (not SOAP) is attacked and controlled by attacker. Only packet form
client authenticated by captcha test via SOAP has right value X. And attacker cannot create
right value X for client connect to chord via malicious node because he do not know the
session key between SOAP and target, even he creates a random X, probability of that value
X valid is very low. So that flooding attack or resource attack to target via malicious node
(not SOAP) cannot be successful.
In the Second Scenario:
With original Websos, after control node, attacker begins flooding attack and resource attack.
Valid user cannot access to target because congestion or overload in target (result is the same
as first scenario).
With WebSOS has improvement, by adding a process control flooding in target, case a
SOAP be controlled and attack flooding or attack resource to target cannot be successful.
And malicious SOAP node will be detected so it will be removed from WebSOS.
19
Figure 7: Access successful via WebSOS
4. Conclusion
Two given measures have solved matter that a node controlled by attacker becomes
malicious node harm to system by flooding attack and resource attack. However, there are
still some problems in experiment that discovery.
In the first scenario malicious node still unknown so it can still attack flooding in chord in
some bad case (with small system) that will cause congestion in chord networking and in
Servlet connect to target. So it will take long time or disconnect (timeout) when valid user
access to server.
In the second scenario, we can detect malicious node (just SOAP) and remove it from
system. However process analysis and control traffic burden to server that decrease the
ability of server, especially in a huge system with the amount of query each minutes.
So future measure is applying distributed computing network [13] in system, that mean using
node to monitoring traffic in chord and give notification to target, by analysis information

send from node, target can detect malicious node and remove it from WebSOS.
5. Reference
[1] Jelena Mirkovic, Sven Dietrich, David Dittrich, Peter Reiher; Internet Denial of Service:
Attack and Defense Mechanisms.chm ; Prentice Hall PTR; 2004.
20
[2] Bots &; Botnet: An Overview from the SANS Institute Reading Room site
[3] Jelena Mirkovic, Sven Dietrich, David Dittrich, Peter Reiher; Internet Denial of Service:
Attack and Defense Mechanisms.chm ; Prentice Hall PTR; 2004.
[4] R. Mahajan, S. M. Bellovin, S. Floyd, J. Ioannidis, V. Paxson, and S. Shenker,
"Controlling High Bandwidth Aggregates in the Network," ACM SIGCOMM Computer
Communications Review, vol. 32, no. 3, July 2002, pp. 62–73.
[5] A. Yaar, A. Perrig, and D. Song, "SIFF: a stateless Internet flow filter to mitigate DDoS
flooding attacks," Proceedings of the IEEE Symposium on Security and Privacy, May 2004,
pp. 130–143.
[6] A. Yaar, A. Perrig, and D. Song, "Pi: A Path Identification Mechanism to Defend
Against DDoS Attacks," Proceedings of the IEEE Symposium on Security and Privacy, May
2003, pp. 93–107.
[7] J. Mirkovic, D-WARD: Source-End Defense Against Distributed Denial-of-Service
Attacks, PhD thesis, University of California Los Angeles, August 2003,
[8] A. D. Keromytis, V. Misra, and D. Rubenstein. SOS: Secure Overlay Services. In
Proceedings of ACM SIGCOMM, pages 61–72, August 2002.
[9] I. Stoica, R. Morris, D. Karger, F. Kaashoek, and H. Balakrishnan. Chord: A Scalable
Peer-To-Peer Lookup Service for Internet Application. In Proceedings of ACM SIGCOMM,
August 2001.
[10] L. von Ahn, M. Blum, N. J. Hopper, and J. Langford. CAPTCHA: Using Hard AI
Problems For Security. In Proceedings of EUROCRYPT’03, 2.
[11] Elaine Shi, Ion Stoica, David Andersen, Adrian Perrig, “OverDoSe: A Generic DDoS
Protection Service Using an Overlay Network”, CMU Technical Report CMU-CS-06-114,
2006.
[12]Graduated thesis of Phạm Xuân Bách “phong chống tấn công từ chối dịch vụ phân tán

vào các website”
[13] “Distributed Computing: Utilities, Grids & Clouds” in ITU-T Technology Watch Report
9 2009.

×