2013 27th International Conference on Advanced Information Networking and Applications Workshops
A DDoS Mitigation System with Multi-Stage Detection and Text-Based Turing
Testing in Cloud Computing
Vincent Shi-Ming Huang
Robert Huang
Ming Chiang
Cloud Computing Center for Mobile Application
CCMA
CCMA
Indistrial Technology Research Institute
ITRI
ITRI
Hsinchu, Taiwan
Hsinchu, Taiwan
Hsinchu, Taiwan
Email: [email protected]
Email: [email protected] Email: [email protected]
from the victim server. This will become a big problem when
people are relying on cloud services for their tasks, business,
and even life. Zombie network, BotNet, [1], [2] is usually
being used to conduct DDoS attacks. Many researches are
proposed to detect and trace the zombie network [3], [4], [5].
We are concerned that before we detect a zombie network
and trace out the attack source to stop and clean zombie
virus, the cloud services are still unavailable and this may
take for a long time. Hence, a DDoS mitigation system is
necessary to defense DDoS attacks at once.
A distributed denial of service defense system is aimed
at detecting and mitigating the possible attacks from the
Internet. To reduce the possible damage due to such attacks
in the cloud, the DDoS mitigation system is responsible to
filter out the attackers’ packets and block the suspected packets by a challenge-response procedure where the challengeresponse procedure can mitigate the traffic and decide if the
packets is from human or machine (program). The zombie
hosts send huge HTTP requests to a victim web site can be
detected by a Turing test [6], [7] which have been developed
in the Artificial Intelligence community. Turing test is used
to test a machine’s ability to exhibit intelligent behavior
where it can determine the incoming request is initiated by
a human or a program on a zombie host. CAPTCHA [8],
[9] is a well-known technology which is used in many web
sites to challenge the users and determine if the users are
programs. However, most of the CAPTCHA system is based
on image challenge [10], [11] that it needs a quite amount
of bandwidth to transmit the CAPTCHA image to the users.
In a DDoS mitigation system, we need a mechanism to
challenge the suspected users with less network bandwidth
consumption. Thus, the attackers would not attack the DDoS
mitigation system directly by exhausting its bandwidth. Due
to this concern, the reflection ratio between the size of
incoming packet and out-going challenge packet must be
as low as possible.
In addition, the performance side effect of the implementation must be as less as possible [12] such that the
DDoS mitigation system would not become the bottleneck
and cause the whole cloud service system to be unavailable.
Abstract—An important trend in the computer science is
towards Cloud Computing and we can see that many cloud
services are proposed and developed in the Internet. An
important cloud service like the IaaS as AWS EC2 can help
many companies to build data centers with high performance
computing resources and reduce the cost of maintaining the
computing hardware. A data center which provides internet
service may suffer from many security risks including Distributed Denial of Service (DDOS) attack. We believe that most
of the cloud services, like Gmail, Dropbox, Google Document,
and etc., are based on HTTP connection. Hence, we aim at
HTTP-based connection and propose a low reflection ratio
mitigation system against the DDoS attacks. Our system is
in the front of an IaaS that all of the virtual data centers
in the IaaS are our protection targets. Our system consists
of Source Checking, Counting, Attack Detection, Turing Test,
and Question Generation modules. We provide a multi-stage
detection to more precisely detect the possible attackers and
a text-based turing test with question generation module to
challenge the suspected requesters who are detected by the
detection module. We implemented the proposed system and
evaluated the performance to show that our system works
efficiently to mitigate the DDoS traffic from the Internet.
Keywords-DDoS; Multi-Stage Detection; Turing Testing;
CAPTCHA; Cloud Computing; Text-based Question
I. I NTRODUCTION
Cloud services provide a very convenient and efficient
way for people to deal with their tasks ubiquitously in the
Internet. We can use just a browser with Internet to do many
works by using cloud services. Most of the cloud services,
like Gmail, Dropbox, Google Document, Facebook, etc., are
all based on HTTP connections such that a user can access
these services with a browser via a cell phone, tablet, or
laptop which can be carried everywhere. We are relying on
the cloud computing insensibly when we store and process
most of our data in the cloud. However, more dependence
on our works to the cloud service, more reliability the cloud
services must be concerned.
Many denial of service (DoS) and distributed denial of
service (DDoS) attacks use flooding attacks to exhaust a
server’s computing capability or network bandwidth such
that the legal users could not access the services provided
978-0-7695-4952-1/13 $26.00 © 2013 IEEE
DOI 10.1109/WAINA.2013.94
655
When doing source checking, DDoS attack detection, and
Turing test, the computation performance must be efficient.
Furthermore, once the system has no alternative but to be
busy, the DDoS mitigation system must have a mechanism
to reduce the workload of the server. In our multi-stage
detection sub-system when a server becomes busy or the
network is under flooding, it will try to block all new
requests into Turing test in order not to increase the network
or computation usage of the server.
In our proposed DDoS mitigation system, it consists of
a Source Checking and Counting module, a Turing Test
module, a Attack Detection module, and a Question Generation module. The Source Checking module decides how the
incoming packets are forwarded according to its status that
it belongs to white list, black list, source block/destination
block list, and unknown sources. The Turing Test module
challenges the suspected requesters, waits for their answers,
and decides if the suspected requesters are humans or
programs. All of the challenging questions are generated
by the Question Generation module where the questions
are text-based natural language question with small size,
about 200 bytes. The Attack Detection module is running a
multi-stage algorithm to find out the suspected sources with
efficiency consideration that it does more precise detection
when the system has spare time and stops all new requests
when the system is extreme busy.
To improve the DDoS mitigation performance and reduce
the network latency, the Source Checking and Counting
module and the Turing Test module are implemented in the
Linux kernel of the network gateway. The Attack Detection
module is more complex so that we implement it in the
user space. We reduce the dependency and create APIs
for communicating between each module. Thus, the cloud
managers can control all modules by their own-demand via
accessing our APIs. They can add more logics or policies
for detection which are specific in their cloud environments.
This will be more flexible when the DDoS mitigation system
is deployed to various IaaS platform, like AWS EC2 or any
other private clouds.
II. R ELATED W ORKS
In the literary of CAPTCHAs, most schemes were aimed
at the Turing test that embeds characters in an image.
However, [10] illustrated that computer vision techniques,
by optical character recognition, have over 90% accuracy to
recognize the character in an image. To improve the strength
of a character image against to a program, [14] tries to
add more noise and distortion, but this will be harder for
a human to recognize the characters too. Thus, adding too
much noise and distortion will make the characters image
to be unusable [14]. Furthermore, [15], [16], [17] proposed
alternative image question CAPTCHAs which does not
have the above issue and [18] provided a combination of
character and image CAPTCHA which possesses both of the
above properties and users have to do simple mathematical
computation in order to answer the question.
Most of the proposed CAPTCHAs are used to avoid huge
registration to some web services or prevent brute-force
attack to guess a password in a login screen. [19] proposed
a new idea to use Turing test in a DDoS defense system.
They designed a system to protect web service where
the suspected requesters will be challenged by graphical
puzzles. The requesters need to recognize the characters
in the distorted image to answer the question. This is a
well-known method to test if the requesters are human or
machine (program). Besides, the Turing test system of [19]
is implemented in Linux kernel in order to improve the
performance.
For a DDoS defense system, the reflection-ratio of the
system in [19] which uses image-based challenge to test the
suspected requesters will be very high, i.e., the requester
send a request packet with size less than 100 bytes but
the Turing test system has to response a packet with about
3 Kbytes image size. The reflection-ratio is about 30. A
DDoS defense system with high reflection-ratio is with less
efficiency and might be exhausted its bandwidth. Thus, the
front-end DDoS defense system might become the target of
DDoS attack and cannot achieve its goal to protect the web
servers.
A. Our Contribution
III. T HE P ROPOSED DD O S S YSTEM
The system flow is depicted in Figure 1. The packet
coming from the Internet will first arrive our kernel Source
Checking and Counting module. The checked packet will be
redirected to Turing test module if it is a suspected packet.
The Turing Test module will challenge the requester by
responding a text-based question to her/him and she/he must
return a right answer to pass the challenge to continue her
connections. The Detection Module will cooperate with the
Source Checking module to detect if there is any possible
DDoS attack. The Source checking and Counting module
counts the arriving time and related information for attack
Detection. Furthermore, the question pool of the Turing Test
Our contribution is to build a DDoS mitigation system to
reduce the DDoS attacks to the services on the cloud. We
construct a multi-stage Attack Detection module to detect
the possible malicious sources with low computation cost.
A kernel-embedded Turing Test module is built to quickly
response a challenge to the requester. The challenge is a
text-based question composed by natural language in our
Question Generation module. It uses less bandwidth than an
image-base challenge. The collaboration of these modules
help us to reduce most DDoS attacks from the Internet. We
also implemented these modules in ITRI Cloud OS which
is an operation system for building a AWS-like IaaS [13].
656
module is updated periodically by the Question Generation
module.
Figure 1.
behavior of each VC where the collected information
are the average and maximum value of the connection
per second (cps), incoming packet per second (inpps),
and incoming bytes per second (inbps). The collected
data could be represented each VC’s network activity
ordinarily. It will be used to analyze every VC’s instant
traffic to detect the abnormal traffic and malicious
packets. The parameters in Stage 2 can be also determined from the collected information. This stage will
be performed continuously and all of the VCs’ data will
be updated except that the detection status is in Stage 2
and in Stage 3. This is because that when the detection
status is under Stage 2 or Stage 3, the system should be
busy and we would like to reduce the computation cost
at that moment. In our system, the manager changes
the detection status from Stage 0 to Stage 1 manually
when she/he thinks that she/he has collected sufficient
traffic data of VCs.
Stage 1: In this stage, the program in Stage 0 is still
running to collect the instant VC traffic data, say as
the tuple (cur cps, cur inpps, cur inbps). For each VC
traffic data, we check if the value of current traffic
data is large than the maximum value of previous
statistic one, i.e., cur cps > max cps, cur inpps >
max inpps, or cur inbps > max inbps. If a VC satisfies
the above condition, the detection status will be turned
into Stage 2 and the Counting module will be enabled
to count the incoming traffic of the particular VC. The
detection module periodically clean the counting data
and analyze the counting data period by period.
Stage 2: Before describing this stage, we have to define
four parameters that are listed as follows.
Packet Flow in the Proposed DDoS Mitigation System
A. Source Checking and Counting Module
This module is the coordination module in the whole
system. The packet coming from the Internet will first arrive
at the kernel Source Checking and Counting module. In our
system, a packet is in one of the four states which are black,
block, white or unknown state. This module checks if the
source address of the incoming packet is in white list, block
lists, or black list. The packet will be dropped immediately
if its source address is in black list or will be redirected to
the Turing Test module if its source/destination address is
included in the block lists. If the packet is neither in the
black nor block lists, it will be recorded by the Counting
module before forwarding through to the destination virtual
machine. The Counting module focuses on recording each
packet’s source address, destination address, and the arriving
times. Counting data is accumulated by this module and
will be reset by the Attack Detection module periodically.
Furthermore, the Counting module is disabled by default. It
will be enabled by the Attack Detection module when there
are some suspected traffic been detected.
– 𝑇 𝐻 and NUM Period: Both of the parameters
are threshold values. If an source IP continuously
sends packets to a VC more than NUM Period
periods and the number of its connection times in
each period is more than 𝑇 𝐻, we suspect that this
source IP is doing DDoS attack to this VC. In such
circumstance, the source IP will be added to the
source block list and it will be redirected to the
Turing test module. We predict that it will not send
packets to this VC and will not be detected by this
module again in the short run.
– Max TH: This is an extreme threshold value. If
the number of the connection times of an source
IP is larger than Max TH, this IP will be added to
the source block list immediately. This value can
be configured as the 90% of an Apache server’s
maximum performance or be number of times of
𝑇 𝐻.
– Node TH: This is a threshold value that if the
number of incoming source IPs exceeds Node TH,
the system randomly selects half of these IPs to the
B. DDoS Attack Detection Module
The goal of this module is trying to find the possible
malicious sources and add them into the block lists. Thus,
the malicious source addresses will be challenged by the
Turing Test module. There are four stages in the detection
algorithm which is described as follows.
Before describing the detection algorithm, we introduce
a concept of Virtual cluster (VC) which consists of one or
many virtual machines to provide a service, like web service,
and is with a public address which would be the destination
address of the incoming packets. Our detection algorithm
will focus on detecting attacks to VCs in an IaaS.
∙ Stage 0: In this stage, the detection module is in
a monitor mode. It collects and records the traffic
657
∙
source block list. This is in order to avoid huge
amount of connections come from the Internet in
a short time to exhaust the resource of a VC.
The above values can be configured by network managers according to their experience. But in our scheme,
the above value can be more precisely measured in
stage 0 and continuously updated according to the
practical network activity of each VC. The detection
status will be changed back to Stage 1 and the Counting
module will be disabled when there are no IPs been
added to the source block list for NUM Period periods.
Stage 3: In this stage, the traffic to/from a VC is
extreme high, say it consumes over 90-95% inbound or
outbound network bandwidth of the VC. Any analysis
at this time may cause the system to be more busy and
may not response in a reasonable time. Once we detect
one VC is under such flooding, we add its public IP to
the destination block list to block all new incoming
HTTP connections to it. The VC public IP will be
removed from the destination block list in a short
period, say 1 second. In the duration, the traffic will be
reduced because all new incoming HTTP requests will
be redirected to Turing Test module until they pass the
challenge. The VC public IP will be repeatedly added
and removed from the destination block list until its
traffic is down. If the traffic is keeping extreme high,
we can trigger a request to scale up the resource of
this VC where the IaaS must support the technology of
auto-scaling [20] to create more resource, more network
bandwidth or more virtual machines, to satisfy the
demand.
Figure 2.
The Text-Based Turing Test Flow
2) HTTP get request: After finishing TCP three way
handshake, the HTTP get request from the requester
will be redirected to this module. This module recognizes the HTTP get request by checking if its ACK
and PSH flags are set to 1. It then records the SEQ
number of the HTTP get request packet in order to
prepare the packet for responding.
3) Challenging question: At this step, this module simulates the web server to response an HTML document to the requester. It randomly selects a question
from the question pool to construct a new payload
by including MAC and IP of the requester, IP and
TCP headers, and the question which is a HTML
format text content with length less than 300 bytes.
The challenged question includes an unique UUID
which will be sent back in the requester’s answer.
Once sending a challenge to the requester, this module
records the following information: 1) UUID, 2) the
source address of the requester, 3) the destination
URL, 4) the correct answer of the challenged question
to the requester, 5) a parameter 𝑡𝑟 = 1, and 6) current
time 𝑡𝑐 . After sending the question to the requester,
this module also sends the FIN packet to close the
TCP connection.
4) HTTP post answer: The requester sends an answer back. Then, this module retrieves the requester’s
record by UUID in the answer and then checks if the
answer is correct. If the answer is not correct and
C. Text-Based Turing Testing Module
As mentioned in Section III-A, when a packet’s
source/destination address is in the source/destination block
list, it will be redirected to this module which is also
implemented in the Linux Kernel. The main task of this
module is to randomly select a question from the question
pool and send the text-based question to the requester. It then
checks the following answer from the requester is correct
or not. The requester will not be able to reach its original
destination until it responses the right answer corresponding
to the question it is challenged.
Figure 2 shows the flow to challenge a suspected requester. It is also described as follows.
1) Three way handshakes: Before sending HTTP request to a web server, the requester has to establish
TCP connection first [21] where it is implemented
by SYNC packet. Our Source Checking module will
not redirect the SYNC packets to this module instead
of forwarding them to the destination VC. There
are many SYNC flooding detection and defending
methods proposed [22], [23]. In this manuscript, we
don’t focus on this issue.
658
𝑡𝑟 ≤ 3, this module resends a challenging question
to the requester and computes 𝑡𝑟 = 𝑡𝑟 + 1. If the
answer is not correct and 𝑡𝑟 > 3, the requester’s source
address will be added into the black list. Besides, if
the requester does not send an answer back, it will be
always blocked and cannot reach the destination VM
until it sends a correct answer to pass the challenge.
Furthermore, 𝑡𝑐 is used for checking if the requester
responses her/his answer in a reasonable time. If
the requester responses her/his answer shorter than 3
seconds, we reasonably doubt she/he is a robot. Thus,
we resends a challenging question to the requester and
computer 𝑡𝑟 = 𝑡𝑟 + 1. If the requester continuously
response answers in a short time, it will be added to
black list soon. This can also avoid attackers to execute
a question mining to collect all of the questions in a
short time before the question pool is refreshed.
A more advanced policy is to add the source address
to the white list when she/he passed the challenging
more than a specific times.
5) HTTP redirection: Once the requester returns a correct answer, this module cleans all the record of the requester and responses an URL redirection [24] which
will direct the requester to the original destination. All
requesters will be redirected to a warning page when
they return wrong answers. For any real person who
cannot give right answer, she/he can request to remove
her/his IP from the black list on the warning page. For
example, she/he needs to input her/his e-mail address
on the warning page. Then a unique authorization link
will be sent to her/his email. Once she/he issue a
request via the link, the system will remove her/his
IP from the black IP.
are figured where we apply c-structure to construct our
questions. The following is a c-structure and Figure 3 shows
a sentence constructed by c-structure.
((S(NP(NNP))(VP(VBZ)(NP(DT)(NNS)))))
Figure 3.
A Sentence Constructed by LFG C-Structure
By applying LFG, we prepare a huge word pool for each
element in c-structure, i.e., we prepare a lot of names for
NNP, verbs for VBZ, and noun for NNS. Conceptually,
we randomly pick words from the prepared word pool
for each element to construct a sentence. However, the
syntax of the generated sentence is correct by using LFG
but the randomly selected verb may not be associated to
the randomly selected noun (NNS) and the semantics of
the constructed sentence will be strange. For example,
a randomly generated sentence might be ”Claire eats
thirty-four books.” Hence, we have to construct the relation
between each verb and noun and prepare many phrases to
make sure the meaning of a sentence is understandable.
Our text-based question consists of several sentences and
the following is an example.
D. Question Generation Module
Vicki buys forty-one eggs. Mac gets thirteen pens. Ducky
buys nineteen pens. What if the boy takes four items from
girls, how many items does the boy have?
The main task of this module is to randomly generate
text-based question for Turing Test module to challenge the
suspected requester. The most well-know Turing test method
which is used in many web sites to prevent robots from
doing brute-force attack is CAPTCHA [8]. Most of the web
sites use image-based challenge to check if the requester is
a human or a robot. Image-based challenge requires more
bandwidth for network transmission. For example, when we
input incorrect password to Gmail sign in the login screen
more than 5 times, it prompts a challenged image of which
size is about 3 Kbytes. The text-based question for Turing
test in this module is about 200 bytes that we need less
than 1/10 bandwidth compared with Gmail to challenge a
requester.
Lexical Functional Grammar (LFG) is a grammar framework [25] that we use it to generate natural language
sentences and construct our text-based question. In LFG
primary research [26], two primary structures, functional
structure (f-structure and constituents structure (c-structure),
The above question incurs a low reflection ratio since it
consumes fewer than 150 bytes, and is relatively difficult for
programs to answer correctly because it requires common
sense knowledge (gender and tense) that is usually difficult
to acquire. Besides, we also tried Siri [27] and many popular
artificial intelligence bots [28], [29] to test the strength of
our generated questions. We found that there are no AI bots
can answer our questions up to now.
In order to come up with an correct answer for each
generated question, we record many information during the
procedure of constructing sentences. For example, we have
to record male or female of the selected name (NNP), what
are the verb and none for each sentence, and what is the
number of DT. And finally, it decides what kind of question
will be generated with the answer.
659
IV. P ERFORMANCE E VALUATION
The performance cost of the DDoS attack mitigation
system is mainly affected by the overhead of checking
every incoming packet to determine if it is in the black
lists, white list, source/destination lists, the frequency of
invoking challenge-response interactions, and the overhead
of each challenge-response interaction. The Attack Detection
module can be executed in a standalone machine such that
it will not affect the performance of the traffic gateway. To
evaluate the impact of each of these factors, we set up a
test-bed consisting of the following components:
(1) A server that runs our DDoS attack mitigation, as
well as the web service under test, which does nothing but
returns a small static HTML file, in order to minimize the
communication overhead between them,
(2) A white input load generator that runs a stress testing
tool, ab, which is configured to run 100 concurrent threads
with 1000 requests per thread, where requests are targeted
at the web service installed on the above server,
(3) A gray input load generator node that constantly issues
requests to the web service under test, and
(4) A black or attack load generator node running a raw
socket program that generates a large number of HTTP
request packets with random source IP addresses.
These nodes are connected with a Gigabit Ethernet switch.
We first measure the relative cost of looking up the black
list. The blue bar in Figure 4 shows the throughput (number
of requests successfully serviced per second) of the test web
service under different black list size when only the white
input load generator node, which is not in the black list,
issues input requests. Because the black list is organized as
a hash table, even when the size of the black list is 100000,
the throughput degradation is around 4.4% as compared with
the configuration when the DDoS attack mitigation system
is turned off (No DDoS).
Next we use both the white and black input load generator
as the test input sources. The source IP addresses in the
input requests generated by the black input load generator
are always in the black list, and the rate (number of requests
per second) at which the black input load generator issues
requests is chosen to be the same as the black list size.
Although the requests from the black input load generator
are guaranteed to be dropped, they still could impact the
throughput of the test web service. However, the red bar in
Figure 4 shows that the DDoS attack mitigation system is
indeed capable of fending off the attack packets early on,
so that the throughput degradation under DDoS attacks is at
most 8.5% when the black list size reaches 100000.
In the next test, both the white and gray input load
generator are used. Input requests from the gray input
load generator trigger the Turing test, and therefore impose
additional performance overhead. Figure 5 shows that even
when the DDoS attack mitigation system needs to send out
Figure 4.
The Throughput under Different Black List Size
10000 challenge questions per second, the test web services
throughput degradation is only 7.3% when compared with
the ”No DDoS” case. Moreover, as soon as the gray input
load generator is placed in the black list and thus blocked,
the throughput degradation disappears (Blocked).
Figure 5.
The Throughput under Turing Test
To assess the performance impact of the challenge question size, we test two question sizes: 200-300 bytes and
1000 bytes. The results shown in Figure 6 suggest that
the text-based Turing test has promise as the performance
improvement from using 1000-byte challenge questions to
using 200-300 bytes challenge questions is between 4.8% to
5.9%. As a reference, the challenge question size of Google
Gmails login page is about 3 Kbytes.
From the above results, our DDoS attack mitigation
system does an effective job in protecting a web service
when the input requests are from known good users only,
from known good users and known bad users, and from
known good users and potential attackers. The proposed textbased Turing test prevents the Turing test itself becoming an
unknowing accomplice of a DDoS attack.
660
[2] J. B. Grizzard, V. Sharma, C. Nunnery, B. B. Kang, and
D. Dagon, “Peer-to-peer botnets: overview and case study,” in
Proceedings of the first conference on First Workshop on Hot
Topics in Understanding Botnets, ser. HotBots’07. Berkeley,
CA, USA: USENIX Association, 2007, pp. 1–1.
[3] P. Salvador, A. Nogueira, U. Franca, and R. Valadas, “Framework for zombie detection using neural networks,” in Internet
Monitoring and Protection, 2009. ICIMP ’09. Fourth International Conference on, may 2009, pp. 14 –20.
Figure 6.
[4] F. Giroire, J. Chandrashekar, N. Taft, E. Schooler, and D. Papagiannaki, “Exploiting temporal persistence to detect covert
botnet channels,” in Recent Advances in Intrusion Detection,
ser. Lecture Notes in Computer Science. Springer Berlin /
Heidelberg, 2009, vol. 5758, pp. 326–345.
The Throughput of Different Question Size
[5] W. Chun-dong, L. Ting, and W. Huai-bin, “Botnet detection
based on analysis of mail flow,” in Biomedical Engineering
and Informatics, 2009. BMEI ’09. 2nd International Conference on, oct. 2009, pp. 1 –4.
V. C ONCLUSION
In this manuscript, we proposed a DDoS mitigation
system which consists of Source Checking and Counting
module, Multi-Stage Attack Detection module, Text-Based
Turing Test module, and Question Generation module. We
also implemented our system in Linux kernel and user spaces
according to the performance and flexibility requirements.
Finally, we evaluated the performance to show that our
system is with low reflection ratio and high efficiency.
Our future works are to enhance the precision of the
Attack Detection module and the strength of the Question
Generation module. CPU utilization of a VC is also an
information to analyze the VC behavior to check if it is
under DDoS attack. Furthermore, integration with other
security appliances like Web Application Firewall (WAF)
[30] and iptables can also help us to manage the black list to
filter out the known malicious sources. NAT of a business is
also an issue that all of its employees use the same public IP
to access the service of a VC. A large amount of connections
from an IP to a VC might be treated as a suspected attacker
in our current detection method. For Question Generation
module, we would like to improve the complexity of a
sentence which is constructed by LFG. Increasing more
types of text-based questions is also a research topic. For
example, the ASCII art [31] uses the ASCII character sets
to represent an image, which could be a cat, a duck, or a
art-character. With various types of text-based questions in
the question pool could make our DDoS mitigation system
to be more secure against the DDoS attackers.
[6] A. Pinar Saygin, I. Cicekli, and V. Akman, “Turing test: 50
years later,” Minds and Machines, vol. 10, pp. 463–518, 2000.
[7] A. P. Saygin and I. Cicekli, “Pragmatics in human-computer
conversations,” Journal of Pragmatics, vol. 34, no. 3, pp. 227
– 258, 2002.
[8] L. V. Ahn, M. Blum, N. J. Hopper, and J. Langford, “Captcha:
using hard ai problems for security,” in Proceedings of the
22nd international conference on Theory and applications
of cryptographic techniques, ser. EUROCRYPT’03. Berlin,
Heidelberg: Springer-Verlag, 2003, pp. 294–311.
[9] J. Yan and A. S. El Ahmad, “A low-cost attack on a microsoft
captcha,” in Proceedings of the 15th ACM conference on
Computer and communications security, ser. CCS ’08. New
York, NY, USA: ACM, 2008, pp. 543–554.
[10] R. Datta, J. Li, and J. Z. Wang, “Imagination: a robust imagebased captcha generation system,” in Proceedings of the 13th
annual ACM international conference on Multimedia, ser.
MULTIMEDIA ’05. New York, NY, USA: ACM, 2005,
pp. 331–334.
[11] A. Gupta, A. Jain, A. Raj, and A. Jain, “Sequenced tagged
captcha: Generation and its analysis,” in Advance Computing
Conference, 2009. IACC 2009. IEEE International, march
2009, pp. 1286 –1291.
[12] R. Thomas, B. Mark, T. Johnson, and J. Croall, “Netbouncer:
client-legitimacy-based high-performance ddos filtering,” in
DARPA Information Survivability Conference and Exposition,
2003. Proceedings, vol. 1, april 2003, pp. 14 – 25 vol.1.
ACKNOWLEDGMENT
[13] “The World’s First ”All-in-One” Cloud Computing System,” http://www.itri.org.tw/eng/econtent/about/about09 02.
aspx?sid=5&PageID=1, 2011, [Online; accessed 05-Dec2011].
This research is supported by CCMA, Industry Technology Research Institute, Taiwan.
[14] J. Yan and A. S. El Ahmad, “Usability of captchas or
usability issues in captcha design,” in Proceedings of the 4th
symposium on Usable privacy and security, ser. SOUPS ’08.
New York, NY, USA: ACM, 2008, pp. 44–52.
R EFERENCES
[1] G. Goth, “Fast-moving zombies: Botnets stay a step ahead of
the fixes,” IEEE Internet Computing, vol. 11, pp. 7–9, 2007.
661
[30] L. Desmet, F. Piessens, W. Joosen, and P. Verbaeten, “Bridging the gap between web application firewalls and web
applications,” in Proceedings of the fourth ACM workshop
on Formal methods in security, ser. FMSE ’06. New York,
NY, USA: ACM, 2006, pp. 67–77.
[15] L. von Ahn, M. Blum, and J. Langford, “Telling humans
and computers apart automatically,” Commun. ACM, vol. 47,
no. 2, pp. 56–60, Feb. 2004.
[16] M. Chew and J. Tygar, “Image recognition captchas,” in
Information Security. Springer Berlin / Heidelberg, 2004,
vol. 3225, pp. 268–279.
[31] P. D. O’Grady and S. T. Rickard, “Automatic ascii art
conversion of binary images using non-negative constraints,”
in Signals and Systems Conference, 208. (ISSC 2008). IET
Irish, june 2008, pp. 186 –191.
[17] Y. Rui and Z. Liu, “Artifacial: Automated reverse turing test
using facial features,” Multimedia Systems, vol. 9, pp. 493–
502, 2004.
[18] M. Shirali-Shahreza and S. Shirali-Shahreza, “Question-based
captcha,” in Conference on Computational Intelligence and
Multimedia Applications, 2007. International Conference on,
vol. 4, dec. 2007, pp. 54 –58.
[19] S. Kandula, D. Katabi, M. Jacob, and A. Berger, “Botz4-sale: surviving organized ddos attacks that mimic flash
crowds,” in Proceedings of the 2nd conference on Symposium
on Networked Systems Design & Implementation - Volume 2,
ser. NSDI’05. Berkeley, CA, USA: USENIX Association,
2005, pp. 287–300.
[20] R. Buyya, R. Ranjan, and R. Calheiros, “Intercloud: Utilityoriented federation of cloud computing environments for
scaling of application services,” in Algorithms and Architectures for Parallel Processing, ser. Lecture Notes in Computer
Science, C.-H. Hsu, L. Yang, J. Park, and S.-S. Yeo, Eds.
Springer Berlin / Heidelberg, 2010, vol. 6081, pp. 13–31.
[21] J. Postel, “Transmission Control Protocol,” RFC 793, Sep.
1981. [Online]. Available: http://www.ietf.org/rfc/rfc793.txt
[22] W. Chen and D.-Y. Yeung, “Defending against tcp syn
flooding attacks under different types of ip spoofing,” in
Networking, International Conference on Systems and International Conference on Mobile Communications and Learning Technologies, 2006. ICN/ICONS/MCL 2006. International
Conference on, april 2006, p. 38.
[23] S. won Shin, K. young Kim, and J. soo Jang, “D-sat: detecting
syn flooding attack by two-stage statistical approach,” in
Applications and the Internet, 2005. Proceedings. The 2005
Symposium on, jan.-4 feb. 2005, pp. 430 – 436.
[24] “Javascript redirect.” [Online]. Available: http://www.tizag.
com/javascriptT/javascriptredirect.php
[25] A. Asudeh and I. Toivonen, Lexical-Functional Grammar.
Oxford University Press, Oxford, 2009.
[26] R. M. Kaplan and J. Bresnan, “Lexical-functional grammar:
A formal system for grammatical representation,” 1995.
[Online]. Available: http://citeseerx.ist.psu.edu/viewdoc/
summary?doi=10.1.1.70.3002
[27] “iPhone 4S - Ask Siri to help you get things done.” [Online].
Available: ihttp://www.apple.com/iphone/features/siri.html
[28] “Personality Forge.”
personalityforge.com/
[Online].
Available:
http://www.
[29] “Jeeney AI - Artificial Intelligence, Learning & Updates.”
[Online]. Available: http://jeeney.com/default.aspx?page=
home
662