SYSTEM FOR PROTECTION AGAINST DDOS ATTACKS

Abstract

A method is presented that enables a server to make use of client or third party resources. The client request data contains data about the network location of the client. The server may store this location data of each client. Before or after execution of the request, the server determines if the server is in or close to an overload situation. If the server is not in an overload situation, no further changes are needed. If the server is in or close to an overload situation, the server selects a new location in the network from the database with all client locations. The server allocates a new instance of the server function at a resource provider on (or close to) this new location. The server may select one or more clients from the database. The selected clients are transparently redirected to the offloaded server function. Subsequent requests from clients are handled by the offloaded server function. The offloaded server function employs the same functionality and thus may decide to offload a server function to another network location.

Claims

1. A method for handling server overload, comprising: providing a part or all of the functionality of a server application by a server function; said server function comprising one or more offloadable server functions that provide a part or all of the functionality of the server application, and which may be loaded on other resources; providing resource providers able to provide resources for hosting said offloadable server functions; detecting a server load by a load detection function constructed to determine if the server function is in or close to an overload situation; and redirect detected client requests to the offloaded server function on a selected resource in response to a load detection function detecting an overload situation.

2. The method according to claim 1, wherein the server further comprises a resource provider lookup function to select a resource from said resource providers.

3. The method according to claim 1, wherein the selection is provided by a client request advertisement indicating a selectable resource.

4. The method according to claim 1 wherein the offloaded server function is executable on a resource provider and wherein the offloaded server function in turn comprises offloadable server functions that provide a part or all of the functionality of the server application, and which may be loaded on other resources in another network location.

5. The method according to claim 1, further comprising; retrieving addresses of communication devices that are close to attack sources at the upstream; transmitting the offloaded server function to a resource provider in a defense position at the upstream.

6. The method according to claim 5, wherein the resource provider lookup function comprises an attack source determining function able to extract the address of a communication device to be chosen as an upstream defense position from the candidates of upstream communication device close to the attack sources retrieved by the resource provider lookup function.

7. The method according to claim 1, wherein the resource providers comprise at least one of physical and virtual resources.

8. The method according to claim 1, wherein the physical resources comprise at least one of CPU load, and communication bandwidth.

9. The method according to claim 1, wherein the non-physical resources comprise at least one of a number of database reads per time unit, a number of database writes per time unit, a number of requests per time unit, and a number of simultaneous sessions.

10. The method according to claim 1, the information processing system comprising system control means, interface means and client application means, the method comprising next steps when the system is overloaded or threatens to be overloaded: it is detected whether the system control means, the interface means or the relevant client application means are or are threatened to be overloaded; it is detected whether the requested access will load the system control means, the interface means or the relevant client application means; if the requested access is not deemed to contribute to the overload of the relevant system means, the requested access is judged to be admissible and/or if the requested access is deemed to load the relevant system means, the requested access is judged to be not-admissible.

11. The method according to claim 1, several clients requesting for access to the information processing system and service level indicators being assigned to those clients, the method comprising that if the kind of requested access is deemed to contribute to the system overload, the requested access of clients having a relative high service level indicator is given preference or priority over clients having a relative low service level indicator.

12. The method according to claim 1, the requested access, deemed to contribute to the system overload, is judged to be admissible for clients having a relative high service level indicator and/or not-admissible for clients having a relative low service level indicator.

13. A system for handling an access request to an information processing system, comprising processing means and memory means, whereby the apparatus is communicatively connected to the information processing system, whereby the apparatus is further connected to a network for transmitting the access request, characterised by that the apparatus is adapted to perform the steps of claim 1.

14. A non-transitory computer-readable medium having a computer program embodied thereon for handling an access request to an information processing system, the computer program including instructions that cause a processor to perform the method of claim 1.

Description

FIGURES

[0021] FIG. 1 shows a schematic arrangement of client-server interaction according to an embodiment of the invention.

[0022] FIG. 2 shows a detailed embodiment of the client server interaction using a redirect to third party resources;

[0023] FIG. 3 shows a schematic flow of actions depending on a detected server overload condition;

[0024] FIG. 4 shows an upstream redirection of offloaded server functions;

[0025] FIG. 5 shows a detailed embodiment of client server interaction using a redirect to local resources

DETAILED DESCRIPTION

[0026] A method is presented that enables a server to make use of client or third party resources. The client request data contains data about the network location of the client. The server may store this location data of each client. Before or after execution of the request, the server determines if the server is in or close to an overload situation. If the server is not in an overload situation, no further changes are needed. If the server is in or close to an overload situation, the server selects a new location in the network from the database with all client locations. The server allocates a new instance of the server function at a resource provider on (or close to) this location. The server may select one or more clients from the database. The selected clients are transparently redirected to the offloaded server function. Subsequent requests from clients are handled by the offloaded server function. The offloaded server function employs the same functionality and thus may decide to offload a server function to another network location.

[0027] To execute the method a system provides the described functionality may be composed of the following functional components. [0028] Server Function (SF) provides (a part of) the functionality of a server application. A server application may consist of one or more distinct server functions. [0029] Offloaded server function (OSF) provides (a part of) the functionality of the server, which may be loaded on other resources. [0030] Resource Provider (resource provider) is a third party or client device which is able to provide resources for hosting an offloaded server function. [0031] Overload Detection Function (overload detection function) use information from client requests and current resource consumption of the server function to determine if the server function is in or close to an overload situation. Unless otherwise defined, all terms (including technical and scientific terms) used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this invention belongs as read in the context of the description and drawings. It will be further understood that terms, such as those defined in commonly used dictionaries, should be interpreted as having a meaning that is consistent with their meaning in the context of the relevant art and will not be interpreted in an idealized or overly formal sense unless expressly so defined herein. In some instances, detailed descriptions of well-known devices and methods may be omitted so as not to obscure the description of the present systems and methods. The term and/or includes any and all combinations of one or more of the associated listed items. It will be further understood that the terms comprises and/or comprising specify the presence of stated features but do not preclude the presence or addition of one or more other features. All publications, patent applications, patents, and other references mentioned herein are incorporated by reference in their entirety. In case of conflict, the present specification, including definitions, will control.

[0032] Throughout the application, any function for carrying out the disclosed methods, in particular, as further clarified below: a server function; an offloaded/offloadable server function; load detection function; resource provider lookup function; and attack source determining function is implemented in hardware and/or software and as structurally identifiable by the function it perform in the system; i.e. the function is physically implemented in hardware and/or software or information structures transmitted through the network. The function may be implemented in hardware or software, to provide dedicated processing circuitry that processes input data read from system resources. A server function may e.g. be provided by a connected physical network device, but may also be formed as a virtual device, functioning in a network, and which may be implemented on a hardware resource that can be reached via network communication. These functions may be executed by one or more processors configured to perform operational acts in accordance with the present systems and methods, such as to provide control signals to the various other module components. The processor may be a dedicated processor for performing in accordance with the present system or may be a general-purpose processor wherein only one of many functions operates for performing in accordance with the present system. The processor may operate utilizing a program portion, multiple program segments, or may be a hardware device utilizing a dedicated or multi-purpose integrated circuit. Any type of processor may be used such as dedicated or shared one. The processor may include micro-controllers, central processing units (CPUs), digital signal processor s (DSPs), ASICs, or any other processor(s) or controller(s) such as digital optical devices, or analog electrical circuits that perform the same functions, and employ electronic techniques and architecture. The controller or processor may further comprise a memory that may be part of or operationally coupled to the controller. The memory may be any suitable type of memory where data is stored. Any medium known or developed that can store and/or transmit information suitable for use with the present systems and methods may be used as a memory. The memory may also store user preferences and/or application data accessible by the controller for configuring it to perform operational acts in accordance with the present systems and methods.

[0033] The invention is described more fully hereinafter with reference to the accompanying drawings, in which embodiments of the invention are shown. This invention may, however, be embodied in many different forms and should not be construed as limited to the embodiments set forth herein. Rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the invention to those skilled in the art. The description of the exemplary embodiments is intended to be read in connection with the accompanying drawings, which are to be considered part of the entire written description. In the drawings, the size and relative sizes of systems, components, layers, and regions may be exaggerated for clarity. Embodiments are described with reference to schematic illustrations of possibly idealized and/or intermediate structures of the invention.

[0034] FIG. 1 illustrates in more detail a system that provides a method for handling server overload. The client application sends a request to the server application with operational parameters of the request (1). The operational parameters may contain (a reference to) location information (e.g. a network address, IP address, credentials, session key). The server may store location information of the client in a datastore (e.g. in a database) (2). Overload detection of the server function can be done by several methods e.g. using a resource load threshold (CPU limit) or a model based approach based on the average service time of fulfilling the request e.g. of a broker type disclosed in Meulenhoff et al., Intelligent overload control for composite web services, Service-Oriented Computing, 2009. If the likeliness of an overload situation is low, the request is handled by the server function (1). Another example of an overload detection function is given in EP 1612674 incorporated by reference herein that receives the operational parameters of the request (3), and that can read current resource consumption of the server, to result in a calculated likeliness of the server function becoming in an overload situation.

[0035] In case of the overload detection function estimates a high overload likeliness (3), the server function redirects detected client requests to the offloaded server function (1 and 7) on a selected resource provider in response to the load detection function detecting an overload situation. This can be done, for instance, by defining a location from the datastore (2) for a new server location. Among other methods, defining a new server location could be done by clustering (e.g. with k-means where k, the number of clusters is set to two), or by a graph based approach, where the graph is split and assigned to a new server. The server can make use of a resource provider lookup function to get the location and contact details of a resource provider (4), and allocates an offloaded server function at a resource provider on this location (5 and 6). A subset of clients which are assigned to the offloaded server function are redirected by the server function (e.g. by HTTP redirect or DNS reconfiguration). In this case the client function makes use of the offloaded server function (7). The offloaded server function may communicate with another server function (8) executed on the same physical device or elsewhere in a physical network.

[0036] FIG. 2 shows user or client terminal 1 and server 2 connected via e.g. the internet. Terminal 1 may send, via the internet, an access request (15a, 15b) to server 2 in a redirection function. The client request sent to the server application (2) may contain and advertisement with information about one or more resource providers 3 (e.g. a cloud resource provider, Azure, Amazon, provided by an ISP) as illustrated in FIG. 2. The advertisement may also be sent at another moment via another path to the server; or in the alternative, the advertisement may be sent by resource providers themselves via a designated protocol. The advertisement may contain a list of data (e.g. a URL, operational parameters, settings, credentials, tokens, cryptographic keys) about local and third party resource providers. If an offloaded server function is available and an offloaded server function decision function decides to make use of the offloaded server function (16) a redirection function redirects the request from the client application to the offloaded server function (23). The location of the redirection and the offloaded server function decision function can vary: at the client device, server application or on a device (e.g. proxy server, router, deep packet inspection device) on the path between client and server. A redirection function can operate at various levels and could be implemented by network address translation, network traffic routing (routing table configuration), nameservice lookup (e.g. DNS lookup), application specific proxy (e.g. web proxy server). If no redirection function is provisioned, the request arrives at the server (15b). The server uses a offloaded server function decision function (17) and a resource provider selection function (18) to decide if it is more optimal to place an offloaded server function and which resource to use (which resource provider to choose) to host the offloaded server function. Input for the offloaded server function decision function and the resource provider selection function are: expected resource consumption of the offloaded server function, resource provider information (URL, access credentials, current status, interface protocol) provided by the client, resource usage data provided by third party resource providers. The resource provider selection function, e.g. implemented in a client store as illustrated in FIG. 1 may query known resource providers (19) for up to date resource usage data (e.g. computing load, memory consumption, network latency). After selection of the optimal location, the resource provider is requested by the Server 2 to create an offloaded server function (20) (for instance via a HTTP webservice call). An offloaded server function is created (21) by the resource provider on the third party 3. The resource provider also provisions a redirection function from the client application to the offloaded server function (22). The location of the redirection function can vary: at the client device (e.g. a web proxy, routing, DNS configuration or plugin of a web browser), at the location of the server (e.g. a HTTP redirect, plugin of the web server), or somewhere on the path between client and server (e.g. application protocol proxy, routing, DNS). When the redirection function, offloaded server function, and client device are located in a computer network under control of the same organization, the redirection function may also be implemented in the form of reconfiguration of the same computer network (e.g. configuration of routers, proxy servers, DNS configuration in an ISP network or configuration of a home router in a home network where a offloaded server function is installed on a local device like a settop box) so that the request from the client can be directly routed to the offloaded server function. Finally, the request from the client is redirected to the offloaded server function and processed there (23).

[0037] Implementation of Redirection Functions an Offloaded Server Functionality with Java Webstart

[0038] Here we describe the process of the invention in case of an implementation for HTTP and Java Web Start. The client application is a web browser application. The offloaded server function could be implemented by spawning a new process (of native code), running a script in a script engine, starting a new virtual machine in a hypervisor. Here we use a Java Web Start application which is running at the client computer. A minimal example of the HTTP request sent by the client (step 7a, 15a) is shown below.

TABLE-US-00001 GET /webapplication HTTP/1.1 Host: www.server.com Resource-Provider:http://www.client.com/ResourceProvider

[0039] This is a request for server application /webapplication at server www.server.com. Information about local resources is provided through the HTTP header attribute Resource-Provider telling that a resource provider is available at http://www.client.com/ResourceProvider (e.g. at the address of the client). Two possible options for adding this HTTP header attribute to the request can be done by creating a browser plugin or proxy server on the path between client and server that insert to attribute to the request.

[0040] The redirection function can be implemented in various forms: a plugin added to the web browser (e.g. a firefox extension allows to modify request content), a HTTP proxy server installed on the client computer (e.g. with the apache HTTP server it is possible to rewrite requests and redirect incoming requests to other systems, add headers to the forwarded request).

[0041] The resource provider can be implemented in the same plugin of the webbrowser or HTTP proxy which implements the redirection function. The resource provider also runs a webservice so that it is accessible for the server. The request to the resource provider for creating a new offloaded server function (11,20) gives the resource provider the location of the Java Webstart program (a datafile to be downloaded from some location)

TABLE-US-00002 GET /ResourceProvider?operation=create&location=http://www.server .com/server.jnlp HTTP/1.1 Host: www.client.com

[0042] Both the operation (create an offloaded server function) and the location of the Java Web Start program are passed as arguments to the request to the resource provider. The resource provider parses the request arguments, downloads the Java Web Start program from the specified location, after which it is started. The resource provider changes the configuration of a redirection function (a plugin to the web browser or HTTP proxy on the client) to only redirect requests for the server functionality implemented by the offloaded server function to the new offloaded server function (e.g. a redirection rule based on the URL). After completion of this process the resource provider response to the server is to inform the server the location of the offloaded server function:

TABLE-US-00003 HTTP/1.1 200 OK Date: Wed, 22 Nov 2012 11:31:00 GMT Content-Type: text/html ofs=http://www.client.com/osf

[0043] Now the server can generate a redirection response to the original request of the client.

TABLE-US-00004 HTTP/1.1 301 Moved Permanently Location: http://www.client.com/osf

[0044] New requests of the client for the server are intercepted by the redirection function implemented by the web browser plugin or a proxy server and redirected to the local Java Web Start application. In this case, the Java Web Start application is a java program which implements a webserver.

[0045] offloaded server function hosted by a cloud provider

[0046] The offloaded server function can also be hosted by a third party resource provider. Examples of such third parties are cloud providers like amazon EC2 or windows azure and Google App Engine (which provides a platform as a service or PaaS). In case of the Amazon EC2 service, the user also needs to advertise access credentials of the amazon service to the server. In case of Amazon these credentials are formed by the AWS Access Key, to be used to query the EC2 interface (see: http://docs.amazonwebservices.com). This provides access to the Amazon EC2 interface for the server and Resource provider selection function. Here the role of the resource provider is played by the Amazon EC2 service. The interfaces to this service (11,19,20) is provided by the EC2 webservice.

[0047] Implementation of the offloaded server function placement decision function and Resource provider selection function can be done by adding an extension to the webserver. Most webserver implementations (Internet Information Server, Apache HTTP server, Nginx) allow to add extensions that add additional processing functionality to an incoming request. A sample implementation of the offloaded server function decision function is shown below.

TABLE-US-00005 DecisionFunction( osf_array[ ], // array of offloaded server function's already running for the client requirements // resource requirements of the offloaded server function ) { // iterator over all available offloaded server function's foreach (osf in osf_array ) { // if the offloaded server function has enough free resources if ( osf.getAvailableResources > requirements ) { // return the reference to this offloaded server function return osf; } } // no offloaded server function was found with enough resources // or no offloaded server function was available at all. return NULL; }

[0048] Input for this function is an array of known offloaded server functions of this server and client and a data-structure describing the required resources of the offloaded server function. In an iteration over the list of offloaded server functions, the requirements are compared to the available resources on the offloaded server function. The first offloaded server function with enough resources is returned, an input for the redirection function. If no offloaded server function was found, NULL is returned which is the signal to create a new offloaded server function.

[0049] A sample implementation in psuedocode of the Resource provider selection function is shown below:

TABLE-US-00006 SelectionFunction( rp_array[ ], // array of resource providers requirements // resource requirements of an offloaded server function ) { // iterator over all available resource providers foreach (rp in rp_array ) { // get accurate data on available resources at each resource provider rp.updateAvailableResources( ); // if the resource provider has enough resources if ( rp.getAvailableResources > requirements ) { // return the reference to this resource provider return rp; } } // no resource provider was found with enough resources // or no resource provider was available at all. return NULL; }

[0050] Input for this function is an array of known resource providers and a data-structure describing the required resources for a offloaded server function. In an iteration over the list of resource providers, the requirements are compared to the available resource of the resource provider. In this example, each resource provider is queried to get the latest data on available resources. If a resource provider is returned by the function, this resource provider is used for creating a new offloaded server function. If nothing is returned (NULL), no resource provider is found, and the server must resort to a default path and generate the response itself or generate a server error (e.g. a HTTP 503 Service Unavailable status code) FIG. 3 shows a further illustration of overload handling in the network arrangement as disclosed in FIG. 1 or FIG. 2, in response to a DDos attack. First, a service request is sent by a client. The service request may contain location information on the client network location. In response, the server may update a database in the network location of clients making use of this server. Next, it is determined by the overload detection function whether execution of the request may result in an overload situation. If NO, the request is executed an data is transferred back in a conventional way. If YES, the server selects an new location in the network, based on the database and allocates a offloaded server function on selected resource, selected by a resource provider lookup function provided on the server to select a resource from said resource providers. Next, subsets of clients identified by the database are redirected to the offloaded server function provided on the selected resource provider.

[0051] In a way similar to U.S. Pat. No. 7,188,366 FIG. 4 illustrates an embodiment wherein it may be determined if installation of an offloaded server function is possible on an upstream device 400, i.e. a device that is virtually and or physically located upstream in a path between the client and the server. If the result of the determination is YES the upstream device 400 is challenged to determine whether it has resources to redirect detected client requests to an offloaded server function to be implemented on the device. If the installation is not possible (i.e. if the result of the determination is NO), the routine moves to a step wherein the server 2 retrieves adjacent devices that might become upstream routers by referring to an adjacent router database that may be provided in the upstream device. In the case of the router 400, the routers 401 and 402 are extracted as adjacent routers. In a subsequent step, the attack source retrieval module holding information on the DDoS attack is duplicated and sent to selected upstream devices that are identified as resource providers for executing the offloaded server function. Parts of the offloaded server function may be executed on the client application. Consequently, the method may include retrieving addresses of communication devices that are close to attack sources at the upstream and transmitting the offloaded server function to a resource provider in a defense position at the upstream. To this end the resource provider lookup function may comprise an attack source determining function section able to extract the address of a communication device to be chosen as an upstream defense position from the candidates of upstream communication device close to the attack sources retrieved by the resource provider lookup function.

[0052] FIG. 5 illustrates to that end a client device sending a request to the server application with operational parameters of the request (7a,7b). While the preceding has been illustrated with reference to other servers, or router devices available in the network, including third party resources, the mechanism is also applicable with resources advocated by clients themselves. The request may contain an advertisement of information (e.g. a URL, operational parameters, settings, credentials, tokens, cryptographic keys) of one or more Resource providers at the client device. This advertisement may also be sent to the server via another path or at another time. If an offloaded server function decision function makes the decision to use an offloaded server function (8) and a offloaded server function is available at the client, a redirection function redirects the request to the offloaded server function (14). Otherwise, the request arrives at the server application(7b). A possible implementation of the advertisement of one resource provider by the client (7b) is by embedding the advertisement in a HTTP request sent to the server application.

[0053] The server application may use the information in the advertisement and submit it to a offloaded server function decision function (9) and a Resource provider selection function (10) to decide whether to create a offloaded server function, and to select the most optimal location for the offloaded server function, and thus which resource provider to choose. Both functions (Resource provider selection function, offloaded server function decision function) compare the information sent in the advertisement by the client to the resource requirements of an offloaded server function (e.g. the Resource provider selection function can decide to create a offloaded server function when the resource provider has sufficient processing power available). If it is decided to create an offloaded server function, the server sends a create offloaded server function request to the selected resource provider (11). Amongst other possible solutions, the request (11) sent by the server to the resource provider may be embedded in a HTTP request. Information in the request would be the requested operation (create an offloaded server function), and operational parameters like (a reference to) an image for the offloaded server function.

[0054] The resource provider processes the create offloaded server function request and creates a new offloaded server function (12). The resource provider also provisions a redirection function (13). The redirection function is a means to redirect requests from the client to the offloaded server function. Provisioning of this function could be mean configuration of the client device (e.g. update local DNS information, configure a proxy service, change a routing table, firewall, change configuration of a web browser plugin, client application configuration) in order to redirect requests to the offloaded server function (14). After provisioning, the server may redirect the client request to the offloaded server function (e.g. with an HTTP redirect).

[0055] Finally, the above-discussion is intended to be merely illustrative of the present system and should not be construed as limiting the appended claims to any particular embodiment or group of embodiments. Thus, while the present system has been described in particular detail with reference to specific exemplary embodiments thereof, it should also be appreciated that numerous modifications and alternative embodiments may be devised by those having ordinary skill in the art without departing from the scope of the present systems and methods as set forth in the claims that follow. The specification and drawings are accordingly to be regarded in an illustrative manner and are not intended to limit the scope of the appended claims.

[0056] In interpreting the appended claims, it should be understood that the word comprising does not exclude the presence of other elements or acts than those listed in a given claim; the word a or an preceding an element does not exclude the presence of a plurality of such elements; any reference signs in the claims do not limit their scope; several means may be represented by the same or different item(s) or implemented structure or function; any of the disclosed devices or portions thereof may be combined together or separated into further portions unless specifically stated otherwise. The mere fact that certain measures are recited in mutually different claims does not indicate that a combination of these measures cannot be used to advantage and are deemed explicitly disclosed by the subject application.