Countering DDoS and XDoS Attacks against Web Services Xinfeng Ye Department of Computer Science, Auckland University, New Zealand
[email protected] Abstract Cyber-criminals use distributed denial-of-service attacks (DDoS) and XML denial-of-service attacks (XDoS) to extort money from online service providers. This kind of attacks is normally targeted at a particular service provider to exhaust the network and system resources of the provider. This paper proposes a scheme for building a defense system against DDoS and XDoS attacks. The system is built on Web Services. It can be constructed and reconfigured easily by an attack victim.
1. Introduction In a DDoS attack, attackers use a large number of machines to launch the attack to make the resources of the attack victims unavailable to the legitimate users. To avoid detection, more and more attackers launch their attacks by mimicking legitimate Web access behavior of a large number of clients, e.g. running a large number of queries against the victim’s site, downloading large image files from the victim’s server. This type of attacks is called CyberSlam [8]. Web Services are becoming the fundamental building blocks of distributed systems. As web services are built on the SOAP protocol that represents data in XML format, XDoS is another technique used by the attackers to launch attacks against service providers. An XDoS attack intends to exhaust the system resources of the server hosting a web service when the server processes SOAP messages. An XDoS attack mainly uses three strategies, i.e. oversized payload, external entity references, and, entity expansion [5, 6]. The size of a SOAP message affects the amount of time needed to process the message. In oversized payloads attack, an attacker sends an excessively large payload to deplete the victim's system resources. A SOAP message can contain references to external entities (e.g. an XML file residing on a different server). These references are substituted with the actual contents when the SOAP message is processed. An
attacker can send a SOAP message containing a large amount of references to external entities to force the service provider to (a) open a large number of TCP connections to download the actual contents of the entities and (b) use a large amount of CPU cycles to process the downloaded contents. In entity expansion attacks, an attacker defines a deeply nested structure to represent the value of an entity. This could force the server to use an exponential amount of memory to hold the value of the entity when the server expands the entity according to the definition of the entity [5]. This paper extends our earlier work [16]. It proposes a scheme for countering DDoS and XDoS attacks. The scheme is based-on the service oriented architecture (SOA) approach. §2 presents the proposed DDoS and XDoS defense system. The performance evaluations of the system are given in §3. §4 discusses some features of the system. Related work is described in §5. Conclusions are given in §6.
2. The Scheme 2.1. Threat Model and Assumptions A web services provider is called an operations provider. It is assumed that a service provider with the expertise to handle security issues provides a service that forwards the requests from the clients to the operations providers that subscribe to the service. The site hosting the service is called the ServiceHub. Since the ServiceHub’s provider has the security expertise, the provider is able to use various techniques to trace and confine attacks against the ServiceHub. An attacker may control an arbitrary number of machines. However, an attacker cannot infer how the SerivceHub forwards an incoming service request. It is possible that an attacker has compromised a client's machine. Thus, an attacker can impersonate a client to launch attacks. To counter XDoS attacks, each operations provider has given a set of constraints on service requests. To handle the attacks using oversized payloads and entity
expansion, the operations provider specifies the maximum length of each field in the SOAP message for each applicable field. To cope with attacks using external entities references, the service provider specifies the maximum number of external references that can be included in a message. Request message authentication and validation are used to counter DDoS and XDoS attacks. Message authentication verifies the identity of the sender of a message. Message validation ensures that the service requests conform to the constraints given by the operations providers. It is assumed that a group of operations providers have established trust with each other. They host the authentication and validation services that can be used by each other to collectively defend against DDoS and XDoS attacks. It is assumed that the clients interact with the system using the asynchronous callback pattern [3]. That is, a client sends a service request with a return address to the web service. The web service returns the result to the address specified by the client.
2.2. An Overview of the Scheme DDoS and XDoS attacks intend to exhaust the victim’s system resources and network bandwidth. The system resources can be exhausted by processing the requests sent in by the attacker. The attacker can exhaust the victim's network bandwidth by directing a large volume of traffic toward the victim’s site. The scheme in this paper avoids the network bandwidth of the Web Services providers being exhausted by hiding the locations of the Web Services providers from the public. To avoid the system resources being exhausted by the attackers, the system carries out request message authentication and validation before the requests are processed by the Web Services providers. The scheme has two modes, i.e. the normal mode and the under-attack mode. An operations provider decides which mode the system works in. When an operations provider does not detect any attack activity, the system works in the normal mode. Otherwise, the system works in the under-attack mode. To minimise the delay in responding to users’ requests, a service request is only authenticated and validated when the system works in the under-attack mode. An operations provider subscribes to the service of a ServiceHub. The WSDL file describing the operations (i.e. services) provided by the operations provider binds the operations to the ServiceHub. Thus, the public perceive the operations as being hosted by the ServiceHub. As a result, all service requests are sent to the ServiceHub. Since an operations provider’s address is unknown to the attackers, the attackers
cannot send service requests directly to the operations provider. Thus, the attackers cannot easily exhaust the network bandwidth of the operations provider. When working in the normal mode, clients' service requests do not need to be authenticated and validated. Figure 1(a) shows how the system works in the normal mode. Service requests are first sent to the ServiceHub (step 1). The ServiceHub forwards the requests to the operations provider (step 2). The operations provider sends the results back to the client through the ServiceHub (step 3 and 4). 2. forward request
1. request ServiceHub
client 4. forward result
operations provider
3. result
(a) Normal Mode operations provider client
ServiceHub
verifier ... verifier
(b) Under-attack Mode Figure 1 A System against DDoS and XDoS Attack
In the under-attack mode, the service requests need to be authenticated and validated before being processed. The operations provider only processes a service request if the request can be successfully authenticated and validated. Therefore, the service provider does not waste system resources to process the attackers’ requests. However, the authentication and validation mechanism also uses system resources. An attacker can still deplete the victim’s system resources by sending in a large amount of requests that force the victim to authenticate and validate. To counter this kind of attack, an operations provider, say op, subscribes the services provided by other service providers to delegate the authentication and validation task to the other service providers. The providers of the authentication and validation service are called verifiers. Since the authentication and validation is carried out by the verifiers, the attacker will not be able to exhaust op’s system resources. Figure 1(b) shows how the system works in the under-attack mode. The operations provider and the verifiers provide their services through the ServiceHub. They send and receive messages through the ServiceHub. Only the ServiceHub knows their IP addresses. Thus, they cannot exchange messages directly. In the under-attack mode, the operations provider informs the ServiceHub of the authentication and validation services that it subscribes to. The ServiceHub forwards the service requests to the
corresponding verifiers. During the authentication process, the verifiers might need to exchange authentication information with the clients. The ServiceHub is responsible for forwarding the messages exchanged between the clients and the verifiers. If a service request is authenticated and validated successfully, the verifier sends the service request to the operations provider through the ServiceHub. After processing the request, the operations provider sends the result back to the client through the ServiceHub.
2.3. The ServiceHub The ServiceHub might host many operations of different service providers. The services provided by the verifiers are also regarded as operations provided by service providers. The ServiceHub maps the received service requests to their corresponding services providers. For each operations provider, the ServiceHub keeps a verifiers table. The table records the authentication and validation services subscribed by the corresponding operations provider. When an operations provider, say op, changes to the underattack mode, it informs the ServiceHub and sends a list of the verifiers. The operations provider assigns an ID to each of its verifiers and makes the ServiceHub aware of the IDs. The ID of a verifier is a number. It cannot be used to infer the IP address of the verifier. When a service request arrives, the ServiceHub finds the corresponding operations provider. If the operations provider is working in the normal mode, the ServiceHub forwards the request to the operations provider. Otherwise, the ServiceHub finds a verifier and forwards the request to the verifier. The ServiceHub provides some web methods to allow the verifiers to pass information to it. When processing a service request, the verifier can use the getToken method to ask the ServiceHub to pass authentication information to the client. The verifiers use the ServiceHub's forward method to pass the service requests that have passed the authentication and validation check to the ServiceHub. In turn, the ServiceHub forwards the requests to the corresponding operations providers. The verifiers use the report method to report the messages that fail the authentication and validation check.
2.4. Authentication and Validation The authentication mechanism relies on the PKI [7] and the symmetric key encryption algorithm [13]. At the service negotiation stage, a client and an operations provider agreed on a shared key, KEYclient-provider, to encrypt the authentication information. A client can
only encrypt the information that can be correctly decrypted by the verifiers if the client has the appropriate shared key. Thus, the possession of the shared key is the proof of the identity of the client. When changing to the under-attack mode, the operations provider informs the verifiers of their IDs and the keys KEYclient-provider (if any) used by the clients to encrypt the authentication information. For clients who have not completed the service negotiation with the operations provider, they have not agreed on KEYclient-provider with the operations provider. In this case, the PKI mechanism is used for handling the authentication information. In order to use the PKI, the client must have an X.509 certificate for distributing the client's public key. The client will encrypt the authentication information using the client's private key. The verifier uses the client's public key to decrypt the encrypted information. The encrypted information can only be correctly decrypted if it was encrypted using the client's private key (i.e. PRIVATEclient). Since the client's private key is only known to the client, the possession of the key is the proof of the identity of the client. client
hub
verifier
provider
service(para) verify(msg) opt [msg.token = null]
getToken(cstr)
cstr
service(para) verify(msg)
opt [msg.token != null && valid(msg)] forward(msg) service(para)
response(result) result
opt [!valid(msg)] report(msg)
Figure 2 Request Authentication and Validation
Figure 2 is the sequence diagram showing the interactions amongst the client, the ServiceHub, the verifiers and the operations provider in under-attack
mode. A client uses web method service to make service request. When a request is authenticated, if no authentication information is attached to the request (denoted as “msg.token = null”), a challenge string (denoted as cstr) is sent from the verifier to the client through the ServiceHub. The challenge string consists of the id of the verifier (ID), a sequence number (S_Num), and, the creation time of the string (C_Time). Each verifier has an challenge-string table to record the challenge strings sent out by the verifier. In this paper, S^T means the concatenation of S and T. digest is the one-way hash function SHA1 [12] for calculating the digest of a string. {M}Key means message M is encrypted using key Key. When a client receives a challenge string, the client generates a digital signature SIGclient using the information in the challenge string. If the client has agreed key KEYclient-provider with the operations provider, the following formula is used to generate SIGclient. SIGclient = {digest( ID ^ S _ Num^ C _ Time)}KEY
When a request with an authentication token is received by a verifier, the verifier checks to see whether SIGclient in the authentication token is encrypted using the PKI mechanism. The presence of SOAP header "certificate" in the request message indicates that SIGclient is encrypted using the client's private key. In this case, the verifier retrieves the client's public key, PUBLICclient, from the X.509 certificate in the "certificate" header element and use PUBLICclient to decrypt SIGclient. Otherwise, the verifier uses KEYclient-provider to decrypt SIGclient. According to the S_Num of the authentication token, the verifier retrieves the challenge string that corresponds to the token 1 from the challenge-string table and checks whether the following condition holds.
Otherwise, SIGclient is generated using the private key of the client as below: SIGclient = {digest( ID ^ S _ Num ^ C _ Time)}PRIVATE
Since ID, S_Num, and, C_Time are sent in clear text in the challenge string, the attacker can easily compute the digest of their concatenation. However, if the attacker has not compromise the client's machine, the attacker does not know KEYclient-provider and PUBLICclient. Hence, the attacker cannot generate SIGclient correctly. As a result, an attacker's message will fail the above check. An attacker might intercept a service request with a valid authentication token and replay the intercepted message from multiple attacking sites. To counter this kind of attack, after an authentication token is used to authenticate a service request successfully, the verifier removes the corresponding challenge string from the challenge-string table. For a service request, if the verifier cannot find a challenge string that corresponds to the request's authentication token, the verifier drops the request. Thus, an authentication token can only be used to authenticate a message once. Since the attacker can only intercept the client’s message after the client sends out the message, a replayed message should arrive after the original message sent by the legitimate client. Hence, the replayed messages will be dropped by the verifier. Since an attacker might compromise a client's machine, the attacker can use the compromised client's KEYclient-provider or PUBLICclient to generate valid authentication tokens. As a result, an attacker's message cannot be filtered out by the authentication mechanism. Hence, an attacker can launch XDoS
1 1 = DIG ) ∨ ({ SIG client }−PUBLIC = DIG ) ({ SIG client }−KEY where 1 {M }−KEY means message M is decrypted using key KEY DIG = digest( ID cstr ^ S _ Num cstr ^ C _ Time cstr ) X cstr is an item in the challenge string client − provider
client
client − provider
client
The S_Num of the challenge string and SIGclient form an authentication token. As the challenge string causes the creation of the token, the sender of the challenge string is called the originator of the authentication token. The sequence number (S_Num) from the challenge string is also called the sequence number of the token. After generating the authentication token, the client re-sends the original service request with the authentication token attached. The token is stored in a header element of the SOAP message that encapsulates the service request. If the PKI mechanism is used to generate SIGclient, the client also includes the client's X.509 certificate as a "certificate" header element in the SOAP message. The client's service request should be authenticated by the originator of the authentication token. In order to ensure that the ServiceHub forwards a request with an authentication token to the originator of the token, a SOAP message header “verifier” is used. The value of the header indicates the ID of the verifier. The verifier sets the header when it sends the challenge string to the client. The client should include this header when it re-sends the service request to the ServiceHub. When the ServiceHub receives a request from a client, if the request has the “verifier” header, the ServiceHub forwards the request to the corresponding verifier. Otherwise, the ServiceHub forwards the request to a verifier selected from the operations provider’s verifiers table.
1
A token generated from a challenge string should have the same S_Num as the challenge string.
3. Evaluation Experiments were carried out to evaluate the performance of the system. The experiments were carried out on a group of PCs connected by a 100Mbps Ethernet. Each PC is a Dell Precision 390 with a 2.13GHz Intel Core 2 CPU and 2GB memory. All the programs are implemented using Java. Axis2 and Tomcat are used to host the web services. The experiments assume that the client, the ServiceHub, the operations provider, and, the verifiers are connected through a WAN. The one-way transmission delay over the WAN between a client and the other entities in the system is set to 100ms. It is assumed that the service providers subscribe to the service of their local ServiceHub. As the ServiceHub, the verifiers and the operations provider are close to each other, the transmission delay amongst them is set to 15ms. To simulate the transmission delay, a program sleeps for 100ms or 15ms before it sends out a message.
the message can be varied. In this experiment, the size of the messages varies from about 150KB to 1500KB. Figure 3 shows the results of the experiments. From the figure, it can be seen that authentication based on the PKI scheme takes more time than the approach using the symmetric key. The time for carrying out authentication increases slightly as the size of the SOAP messages increases. This is because it takes more time to calculate the digest of a larger message and to decrypt a larger message. However, the increase in time is almost negligible, as the sizes of the messages do not differ from each other dramatically. From Figure 3, it can be seen that the time for checking the message contents (denoted as Content Checking) increases as the sizes of messages increase. This is because a larger message contains more XML tags. Thus, it takes more time to parse the message. It can be seen that, when a message is small, the time for checking the message contents is shorter than authenticating a message. Thus, depending on the size of a message, the verifier can decide whether to authenticate the message or validate the message contents first in order to minimize the cost in filtering out attack messages. 14000 Response Time (ms)
attacks by impersonating a compromised client. To counter this threat, message validation is used to identify possible XDoS attacks. The verifier checks the size of the fields in each SOAP message encapsulating the service request as well as the number of external references in each message to ensure that they do not exceed the limits specified by the operations provider. The verifier also downloads the files referenced by the external references to ensure that the limits on field size and external references are not exceeded.
10000 8000 6000 4000 2000
100 Time (ms)
12000
0
80
0
60
50
100
150
200
250
300
Processing Time (ms)
40
With Defense
No Defense
Figure 4 The Effectiveness of the Proposed Scheme
20 0 150 300 450 600 750 900 1050 1200 1350 1500
SOAP Message Size (KB) Content Checking Symmetric Key Authentication
PKI Authentication
Figure 3 The Cost of Authentication and Validation The first experiment measures the time that it takes to authenticate/validate a SOAP message (i.e. a service request). The SOAP messages used in the experiments do not contain any external references. The parameter being passed to the service provider is in XML format. The value given to each XML tag is about 3.3KB in size. An XML tag can have up to four levels of nesting. By varying the number of tags in a message, the size of
The second experiment measures the effectiveness of the system in countering attacks. In this experiment, the system consists of one ServiceHub, one operations provider, and, two verifiers. It is assumed that, (a) the attacker sends requests to the operations provider at the rate of 1000 requests per second, (b) the size of each SOAP message is 1500KB, and, (c) the attacker's requests are well formed (i.e. the data in the requests conform to the constraints given by the operations provider). The response time of the operations provider when the defense system is used (denoted as withdefense) and the response time of the system when the defense system is not used2 (denoted as no-defense) are 2
That is, the legitimate users and the attacker send requests directly to the operations provider.
Overhead (%)
compared. Figure 4 shows the results of the experiments. In the figure, processing time is the time that it takes for an operations provider to process a service request. From the figure, it can be seen that the response time of the no-defense system increases sharply as the processing time increases. This is because the operations provider processes each of the received requests (including the ones sent in by the attacker). Thus, as the processing time increases, the response time also increases. It also can be seen that, as the processing time increases, the response time of the with-defense system only increases gradually from 741ms when the processing time is 30ms to 965ms when the processing time is 250ms. It can be seen that the increase is mainly due to the increase in processing time. This is because the attack messages cannot reach the service provider. As a result, the response time is only affected by the processing time. From Figure 4, it can be seen that, compared to an un-protected system (i.e. the no-defense system), a system using the defense scheme proposed in this paper can significantly reduce the response time when the system is under attack. 60 50 40 30 20 10 0 0
100
200
300
400
Processing Time (ms) 150 KB
1500 KB
Figure 5 The Overheads of in Normal Mode The last experiment measures the overhead of using the ServiceHub to forward service requests when the operations provider is working in the normal mode. The overhead is defined as (t forward − t direct ) / t direct where
t direct is the service response time when the client’s request is sent directly from the client to the operations provider (i.e. the ServiceHub is not used), and, t forward is the service response time when the client’s request is forwarded to the operations provider by the ServiceHub. The processing time is the time that it takes for an operations provider to process a service request. Two sets of tests were carried out. The size of each request in one test is about 150KB while the size of the requests in the other test is 1500KB. Figure 5 shows the results of the experiments. It can be seen that, as the processing time increases, the overhead of the system decreases. This is because, as the processing time increases, the forwarding cost for per
unit of computation decreases. It can be seen that the overheads for processing a larger message are higher than processing a smaller message. This is because, for a larger message, it takes more time for the ServiceHub to extract the message from the system and to construct the SOAP message to be forwarded to the operations provider.
4. Discussions If an attacker has compromised a client's machine, the attacker can impersonate the client to send a large amount of well-formed service requests to the operations provider. The authentication and the validation mechanism will not be able to filter out this kind of messages. To counter this threat, during the service negotiation phase, a client and an operations provider need to agree on a rate r at which the client sends its service requests to the operations provider. If the operations provider observes that the client's request rate is significantly higher than r, the operations provider can suspend the processing of the client's request until a new request rate can be agreed. When a verifier calls the ServiceHub's forward method to forward a service request to the operations provider, the verifier sets a header element in the SOAP message encapsulating the call to indicate that the call is from the verifier. Although the IP addresses of the verifiers are unknown to the public, an attacker might correctly guesses the IP address of a verifier. As a result, the attacker can pretend to be the verifier and calls the forward method to ask the ServiceHub to forward service requests to the operations provider. To counter this problem, for each verifier, the ServiceHub records the number of service requests (denoted as α) that it has forwarded to the verifier for authentication and validation and the number of responses (denoted as β) that it has obtained from the verifier. β is updated when methods getToken, forward and report are called by the verifier. Due to the processing and transmission delays, α should be slightly greater than β. Thus, if the ServiceHub notices that a verifier's β becomes far greater than the verifier's α, it probably means an attacker is impersonating a verifier. In this case, the ServiceHub will stop forwarding the messages received from the verifier to the operations provider and remove the verifier from the operations provider's verifiers table.
5. Related Work Our earlier work [16] only considers the use of the authentication mechanism. As an attacker might have compromised a legitimate client’s machine, the
attacker can impersonate a legitimate client to defeat the authentication mechanism when launching an XDoS attack. This paper extends the work in [16]. Apart from using the authentication mechanism, it also incorporates mechanisms for dealing with XDoS attacks. Thus, the scheme in this paper is more robust than the scheme in [16]. Andersen et al. [2] and Keromytis et al. [9] use a secure overlay to filter and route the messages to a destination. Since the schemes in [2] and [9] need cooperation from the ISP operators to modify the DNS entries when an attack occurs, their overlay network cannot be reconfigured easily at run time. In contrast, the scheme in this paper can dynamically decrease or increase the number of verifiers in the system by asking the ServiceHub to add or remove verifiers from the operations provider’s verifiers table. Thus, the system in this paper is more flexible and easy to use. Padmanabhuni et al. [11] proposed a framework for detecting and preventing XDoS attacks. Since their scheme handles the validation at one site, unlike our scheme, [11] is not suitable for countering the CyberSlam type attacks. Some schemes [8, 10, 15] require human attention when authenticating the users. For example, [8] provides an operating system kernel extension to protect Web servers against DDoS attacks. It uses a reverse Turing test [14] to authenticate users. Web Services are normally accessed through programs. The reverse Turing test cannot be carried out by the programs easily. Thus, the scheme proposed in [14] cannot be directly applied to Web Services. There are schemes using computational puzzles that require the client to carry out heavy computation before accessing the services [1, 4]. The computation would slow down the attacker. However, this kind of scheme is not effective against DDoS attacks. This is because the attacker can utilise a large number of machines. Thus, it is unlikely that the attacker will be short of computing power.
6. Conclusion This paper proposes a scheme for forming a defense system against DDoS and XDoS attacks using the SOA approach. A web service provider can construct such a system by subscribing the services provided by other providers. With this system, a service provider does not need to have security expertise or rely on the ISP operators to counter medium-scale CyberSlam type attacks. Since the system is constructed from web services, it can be formed and reconfigured easily. The empirical data shows that, when the system is under attack, the
response time to the legitimate users is much shorter than the response time of a system that is not protected by the scheme proposed in this paper. Thus, the proposed system is effective in countering DDoS and XDoS attacks.
References [1] M. Abadi, M. Burrows, M. Manasse, and T. Wobber. Moderately hard, memory-bound functions. ACM Trans. on Internet Technology, Vol. 5, Issue 2, 2005, pp. 299 - 327 [2] D. Andersen. Mayday: Distributed Filtering for Internet services. Proc. of the 4th USENIX Symposium on Internet Technologies and Systems (USITS), 2003 [3] M. Brambilla, S. Ceri, M. Passamani, A. Riccio: Managing Asynchronous Web Services Interactions, Proc. of the IEEE Intl Conf on Web Services, 2004 [4] C. Dwork, A. Goldberg, and M. Naor. On memory-bound functions for fighting spam. In Advances in Cryptology CRYPTO 2003. LNCS 2729, pp.426-444 [5] R. Jaamour, XML security: Preventing XML bombs, http://searchsoftwarequality.techtarget.com/expert/Knowledg ebaseAnswer/0,289625,sid92_gci1168442,00.html [6] B. Hartman, Securing your Enterprise Web Services in a Suspicious world, SOA Web Services Journal, March 2004, Available at http://webservices.sys-con.com/read/43958.htm [7] R. Housley, W. Polk, W. Ford, and D. Solo, Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile, IETF RFC3280 [8] S. Kandula, D. Katabi M. Jacob and A. Berger, Botz4Sale: Surviving Organized DDoS Attacks That Mimic Flash Crowds, Proceedings of the 2nd Symposium on Networked Systems Design and Implementation, 2005 [9] A. D. Keromytis, V. Misra, and D. Rubenstein. SOS: An architecture for mitigating DDoS attacks. Journal on Selected Areas in Communications, 21(1):176–188, 2004 [10] W. Morein and A. Stavrou and D. Cook and A. Keromytis and V. Misra and D. Rubenstein, Using Graphic Turing Tests to Counter Automated DDoS Attacks Against Web Servers, Proc. of the 10th ACM Intl. Conf. on Computer and Comm. Security (CCS), pp. 8-19, 2003 [11] S. Padmanabhuni, V. Singh, K. M. S. Kumar, and A. Chatterjee, Preventing Service Oriented Denial of Service (PreSODoS): A Proposed Approach, Proc. of the IEEE Intl. Conference on Web Services (ICWS'06), pp577 – 584, 2006 [12] RFC 3174, US Secure Hash Algorithm 1 (SHA-1), http://tools.ietf.org/html/rfc3174 [13] B. Schneier, Applied Cryptography,Second Edition, John Wiley & Sons, 1996 [14] L. von Ahn, M. Blum, and J. Langford. Telling humans and computers apart automatically. CACM, 47(2), Feb. 2004. [15] M. Srivatsa, A. K. Iyengar, J. Yin and L. Ling. A Middleware System for Protecting Against Application Level Denial of Service Attacks, Proc. of 7th International Middleware Conference, 2006 [16] X. Ye, S. Singh. A SOA Approach to Counter DDoS Attacks, Proc. of the IEEE Intl. Conference on Web Services (ICWS'07), pp. 567-574, 2007
