US20120174196A1 - Active validation for ddos and ssl ddos attacks - Google Patents

Abstract

Methods and systems for detecting and responding to Denial of Service (“DoS”) attacks comprise: detecting a DoS attack or potential DoS attack against a first server system comprising one or more servers; receiving, at a second server system comprising one or more servers, network traffic directed to the first server system; subjecting requesting clients to one or more challenge mechanisms, the challenge mechanisms including one or more of challenging requesting clients to follow through HTTP redirect responses, challenging requesting clients to request Secure Sockets Layer (SSL) session resumption, or challenging requesting clients to store and transmit HTTP cookies; identifying one or more non-suspect clients, the one or more suspect clients corresponding to requesting clients that successfully complete the one or more challenge mechanisms; identifying one or more suspect clients, the one or more suspect clients corresponding to requesting clients that do not successfully complete the one or more challenge mechanisms; and forwarding, by the second server system, traffic corresponding to the one or more non-suspect clients to the first server system. Once a client has been validated, clients may communicate directly with application servers in a secure manner by transparently passing through one or more intermediary proxy servers.

Description

TECHNICAL FIELD
• The present disclosure relates generally to methods and systems for detecting and responding to Denial of Service and other cyber attacks against servers and web servers.
BACKGROUND
• A server is a computer or other electronic device that is configured to provide services or resources to other requesting devices. The server typically provides one or more communication links for receiving communications from other networked devices, known as “clients,” and executes one or more processes whose function it is to continually monitor those communication links for incoming messages from clients. In order to service a client request, the server typically must expend system resources, such as memory, processor cycles, or bandwidth. Although the server may elect not to service some clients or client requests, the server must nonetheless devote at least some system resources to receive a client communication and determine whether or not to service it.
• In some communications protocols, such as the Transmission Control Protocol (TCP) and the hypertext transfer protocol (HTTP), servers are configured by default to accept and service requests from any client provided the client conforms to the protocol. For example, public-facing web servers are typically configured by default to attempt to service any HTTP request received from any client—for example an HTTP request for a web page—without discriminating between clients or client requests.
• Although this characteristic of many communications protocols provides many benefits in terms of readily available network services, it may also leave servers vulnerable to cyber attacks. For example, in a denial-of-service (“DoS”) attack, a client may attempt to overwhelm a server by sending a large number of requests to the server in rapid succession. Because web servers are configured by default to accept requests from all clients, and because the HTTP protocol provides little information about the requesting client that would enable the server to determine the nature of the client's intentions in making the request, the attacked web server may be slow or unable to respond to other, legitimate requests due to the burdens imposed on the server when servicing the flood of requests from the single malicious client.
• DoS attacks, however, are often easy to detect and overcome, because, in many cases, all malicious requests from a single attacking client will originate from the same Internet Protocol (“IP”) address. Therefore, it may be easy to detect that a server is under attack by simply observing a large increase in traffic over normal loads and that a large percentage of that traffic is associated with a single IP address. The server may then overcome the attack by ignoring all requests from the identified IP address.
• Because of the ease with which DoS attacks may be detected and overcome, one variation on the DoS attack is the distributed denial-of-service (“DDoS”) attack. In a DDoS attack, rather than having a single client make all of the nuisance requests to the server, the attacker utilizes a network of different clients to simultaneously issue requests to the server. Such a network of requesting clients may be at the attacker's disposal by virtue of an in-place “botnet” in which hundreds or thousands of normal users' computers are infected by malware that is programmed to respond to commands issued by a central machine or authority known as a “bot master.” Bot masters may make use of such a collection of “zombie” machines in order to implement a DDoS attack on a server or enterprise.
• In a DDoS attack, because the flood of requests may be spread over a large number of disparate clients, each with a different IP address, it may be difficult to detect which requests originate from legitimate clients and which requests originate from malicious clients, such as compromised “zombie” machines in a botnet. Thus, a server may not be able to determine which requests it should ignore and which requests it should service, because all requests may appear substantially identical over the larger pool of IP addresses.
• One technique for discriminating between legitimate requests and malicious requests is to use a client “challenge” mechanism in which each requesting client is challenged to first perform an operation specified by the server before the server will commit further resources to servicing the client's request. Frequently, clients that participate in a DDoS attack are programmed to issue requests to the server in a “dumb” fashion—i.e., to perform only the operations necessary to cause the server to allocate resources and bandwidth while minimizing the number of operations that must be performed by the client. For example, when making an HTTP request to a server, a client typically must (1) construct and transmit the HTTP request and (2) receive and process the HTTP response from the server. Since the goal of a DDoS attack may be to burden the attacked server as much as possible while minimizing the burden on the attacking clients, the clients may be programmed to simply ignore any HTTP responses transmitted by the attacked server and thus to not devote any resources or processor cycles to processing the responses. Therefore, by requiring clients to perform preliminary tasks to demonstrate that they are normal clients and not merely “dumb” attack scripts, servers may be able to separate legitimate clients from malicious clients.
• Conventional client challenge mechanisms, however, suffer from a number of drawbacks. Most importantly, they require the server to expend resources challenging clients and determining which clients have successfully completed the challenge. Even though the client challenge mechanism may permit the server to thereafter ignore any requests or communications from clients who did not complete the challenge, if a DDoS attack is perpetrated by a large enough number of clients in a botnet, it may not matter whether any one particular client ever attempts to make a second request after failing to complete the challenge. The task alone of challenging each requesting client may be sufficient to overwhelm the server. This drawback may be fatal for mitigating against another variation on the DDoS attack known as an SSL DDoS attack.
• There is therefore a need for methods and systems for overcoming these and other problems presented by the prior art.
SUMMARY OF THE INVENTION
• The present invention comprises methods and systems for mitigating against DoS and DDoS attacks, including SSL DoS and DDoS attacks. In one aspect of the invention, one or more proxy servers monitor one or more application servers configured to receive and service requests from clients. If the proxy servers detect that the application servers are under a DoS and DDoS attack, the proxy servers initiate a process to reroute traffic intended for the application servers to the proxy servers. The proxy servers analyze the rerouted traffic to identify which clients are malicious, for example using one or more client-challenge mechanisms. The proxy servers forward only legitimate traffic to the application servers and either discard or rate-limit all other traffic.
• In other aspects of the invention, clients may be challenged to demonstrate their legitimacy by honoring HTTP redirects, performing SSL resumption operations, storing and transmitting HTTP cookies, etc. In yet another aspect of the invention, clients are subjected to multiple challenges in an incremental fashion until a sufficient amount of malicious traffic has been identified.
• In another aspect of the invention, once a client has been validated, that client is enabled to communicate directly with the application servers. If the validated client is also communicating using a secure connection, the proxy servers also cease to perform decryption operations on communications from that client in order to allow the client and the application servers to securely communicate through the proxy servers without the proxy servers having access to unencrypted communications. Once the DoS or DDoS attack has subsided, traffic intended for the application servers is rerouted back to the application servers.
• Additional objects and advantages of the invention will be set forth in part in the description that follows, and in part will be obvious from the description, or may be learned by practice of the invention. The objects and advantages of the invention will be realized and attained by means of the elements and combinations particularly pointed out in the appended claims. It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the invention, as claimed.
BRIEF DESCRIPTION OF THE DRAWINGS
• The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate various embodiments of the invention and together with the description, serve to explain the principles of the invention. In the drawings:
• FIG. 1 is a diagram illustrating exemplary communications between application servers and clients, consistent with certain disclosed embodiments;
• FIG. 2 is a diagram illustrating an exemplary method of diverting traffic intended for application servers to a mitigation site in the event of a DoS attack, consistent with certain disclosed embodiments;
• FIG. 3 is a flow diagram illustrating an exemplary method of validating clients using HTTP redirects, consistent with certain disclosed embodiments;
• FIG. 4 is a flow diagram illustrating an exemplary method of validating clients using SSL session resumption, consistent with certain disclosed embodiments; and
• FIG. 5 is a flow diagram illustrating an exemplary method of validating clients using HTTP cookies, consistent with certain disclosed embodiments.
DETAILED DESCRIPTION
• The following detailed description refers to the accompanying drawings. Wherever possible, the same reference numbers are used in the drawings and the following description to refer to the same or similar parts. While several exemplary embodiments and features of the invention are described herein, modifications, adaptations, and other implementations are possible, without departing from the spirit and scope of the invention. Accordingly, the following detailed description does not limit the invention. Instead, the proper scope of the invention is defined by the appended claims.
• FIG. 1 is a diagram illustrating communications between one or more exemplary application servers and one or more clients consistent with certain disclosed embodiments. As shown inFIG. 1, one ormore application servers135 provide services to one or more clients orend users110.Application servers135 may comprise commercial web servers that service HTTP requests fromclients110 for web pages hosted by theapplication servers135.Clients110 communicate withapplication servers135 through the Internet120 and using normal Internet communications protocols, such as HTTP, TCP, and IP. Althoughapplication servers135 may operate one or more applications or provide one or more public-facing network services,application servers135 comprise any servers capable of being subjected to a cyber attack, such as a DoS attack, and need not operate any particular application or host any particular services.
• In the embodiment ofFIG. 1,clients110 communicate directly withapplication servers135 viaInternet120. For example, HTTP requests fromclients110 may be encapsulated in TCP segments, IP datagrams, and Ethernet frames and transmitted toservers135. In some embodiments, the only third parties that participate as intermediaries in the communication are Internet Service Providers (ISPs) or other entities that provide routers and link layer switches that do not analyze or review the contents of the Ethernet frames beyond the link layer and the network layer, but instead analyze only those parts of the packet necessary to route communications fromclients110 toapplication servers135.
• Application servers135, or routers providing Internet connectivity toapplication servers135, may be monitored by one ormore monitoring servers145.Monitoring servers145 may monitorapplication servers135 for the purpose of determining whetherapplication servers135 are receiving network communications or are functioning in a normal or expected manner or whetherapplication servers135 are functioning in a non-normal manner that may indicate the presence of a DoS attack. A “DoS attack” may refer to a traditional DoS attack, in which all malicious requests or communications originate from a single device, a DDoS attack, in which multiple, separate devices may participate in the attack, or other types of cyber attacks.
• In one embodiment, a third-partymitigation service provider140 may operatemonitoring servers145, which monitorapplication servers135, pursuant to a commercial mitigation service provided tocustomer130, which may own or operateapplication servers135. AlthoughFIG. 1 depictsmonitoring servers145 as communicating withapplication servers135 using a direct communications link or a communications link separate fromInternet120, those skilled in the art will appreciate that monitoringservers145 may also communicate withapplication servers135 via an indirect network connection, such as a network connection throughInternet120.Monitoring servers145 may be within the network path betweenclients110 andapplication servers135 or may be outside of the path.
• FIG. 2 is a diagram illustrating an exemplary method of diverting traffic intended for one or more application servers to a mitigation site for filtering the traffic in the event of a DoS attack, consistent with certain disclosed embodiments. As shown inFIG. 2, althoughlegitimate clients210 are making normal requests toapplication servers135,additional clients220 that are part of a botnet are also making requests toapplication servers135. InFIG. 2,traffic220afrommalicious clients220 is depicted as a thick arrow, whereastraffic210afromlegitimate clients210 is depicted as a thin arrow, to illustrate thattraffic220amay be significantly heavier thantraffic210a. Once a DoS attack onapplication servers130 is detected, alltraffic120btoapplication servers135 may be diverted toproxy servers245, such that clients may no longer be able to establish adirect connection120awithapplication servers135 viaInternet120. In some embodiments,proxy servers245 may be operated by the same third-partymitigation service provider140 that operatesmonitoring servers145. Moreover, in certain embodiments the same physical servers may perform the roles of both monitoringservers145 andproxy servers245.Proxy servers245 may also be within the network path betweenclients110 andapplication servers135 or may be outside of the path.
• Traffic120bmay be redirected toproxy servers245 using a number of different techniques. For example, using features provided by the Border Gateway Protocol (“BGP”), an inter-Autonomous System routing protocol used by ISPs,proxy servers245 may advertise their availability to route communications to the IP addresses associated withapplication servers135 or may advertise that they themselves terminate such IP addresses, in a process known as a “BGP swing.” As the result of a BGP swing, communications intended forapplication servers135, such as communications fromclients210 and220, may terminate atproxy servers245 such thatproxy servers245 may communicate withclients210 and220 on behalf ofapplication servers135, typically without detection.
• Alternatively, eitherapplication servers135 orproxy servers245 may initiate a request to one or more Domain Name Service (“DNS”) servers to reassign domain names hosted byapplication servers135 to IP addresses assigned toproxy servers245. This process of DNS record alteration may additionally be facilitated or expedited ifapplication servers135 and/orproxy servers245, or the entities associated therewith, operate authoritative DNS servers or have other primary or authoritative roles in the DNS system. Those skilled in the art will appreciate that other techniques may be used to redirect traffic intended forapplication servers135 toproxy servers245. Those skilled in the art will also appreciate that the techniques described in this application may also be applied in the context of an “always-on” DDoS mitigation service in which proxy servers, such asproxy servers245, may always be in the communication path between clients and the application servers. In that case, there may be no need to redirect the traffic to the proxy servers when an attack is detected.
• Oncetraffic120bhas been diverted toproxy servers245,proxy servers245 may filter the traffic by categorizing the traffic into communications from legitimate clients and communications from malicious clients, such as DoS participants. Alllegitimate traffic245amay be forwarded toapplication servers135, whileother traffic245bmay be discarded (item250). Alternatively, to avoid denying service to a legitimate client incorrectly identified as malicious, some or alltraffic245bcould be forwarded toapplication servers135 or otherwise serviced, for example at a much lower priority thantraffic245a, a process known as “rate-limiting” (operations not depicted inFIG. 2.).
• In one embodiment,proxy servers245 may be owned or operated by a third party that provides proxy services as part of a broader DoS mitigation service. One advantage of employing a separately-owned or operated mitigation server system may be the third party service provider's ability to bear computational and connection burdens that a customer's server system could not. For example,customer130 may be a small company that does not have the resources to operate separate proxy servers to perform mitigation services. Or, even ifcustomer130 also operated separate proxy servers, such proxy servers might not be able to bear the burden of a full DDoS attack by separately analyzing each requesting client to determine legitimacy. This aspect of invention may be contrasted with conventional systems that focus on equipping servers that are being attacked or other servers operated by the attacked entity to filter legitimate requests from malicious requests. These systems fail when filtering operations themselves are sufficient to overwhelm the owner of the attacked servers or associated proxy servers.
• For example, some DoS-mitigation techniques attempt to filter traffic as early as possible in the communications process, before the attacked servers devote any significant resources, such as during the preliminary TCP handshake. This technique is particularly ineffective, since very little information may be gleaned during the TCP handshake to enable a server to separately identify legitimate versus malicious clients. Another technique is to send the client a client-side script, such as a piece of JavaScript code, in response to the client's first HTTP request. The client-side script may require the client to demonstrate its legitimacy by solving a cryptographic puzzle in the code. However, any techniques that focus on challenging the client at the HTTP application layer would be ineffective for mitigating against SSL DDoS attacks.
• In an SSL DDoS attack, prior to making any application layer requests or communications to servers, malicious clients first request a secure channel of communication with the server using the Secure Socket Layer (“SSL”) protocol. In an SSL connection, a client and server may communicate securely by encrypting data transmitted back and forth using a symmetric private key protocol, such as the Data Encryption Standard (“DES”) or Advanced Encryption Standard (“AES”). In order for the client and server to encrypt communicate using symmetric private keys, however, they must first securely exchange private keys using an asymmetric encryption protocol that employs public-private key pairs, such as the Rivest-Shamir-Adleman (“RSA”) or Diffie-Hellman protocols. In particular, both the client and the server must transmit their respective public keys to each other and must compute a “Pre-Master Secret” (“PMS”) using each other's public keys, which will be used to generate the symmetric private keys to encrypt subsequent communications between the client and the server, a process known as an “SSL handshake.” Thereafter, the client and the server may communicate using an application layer protocol, e.g., “HTTPS,” that is encrypted using the SSL session.
• The process of encrypting or decrypting data using an asymmetric public or private key (e.g., generating the PMS) is an expensive operation that requires a host system to perform exponentiation over large numbers. As a result, in order to preserve resources, many servers are configured to limit the number of concurrent SSL sessions that they will allocate to clients. In an SSL DDoS attack, an attacker may be able to tax a server's resources using far fewer attacking clients by having each participating client request an SSL session (or multiple SSL sessions) from the server. Each SSL session request causes the server to perform the expensive exponentiation operations and to allocate separate memory for each requested SSL session. Moreover, if the server is configured to allocate only a limited number of SSL sessions, the DDoS malicious clients may consume all available secured sockets, thus causing the server to deny SSL connections to legitimate users. The DDoS clients may tax the server's resources by simply requesting new SSL sessions, even if they never make any subsequent requests to the server using the SSL sessions. In fact, precisely to avoid requiring the client to also perform expensive exponentiation operations, clients that participate in an SSL DDoS attack may not even complete the SSL handshake from their end, another example of how attack scripts may be “dumb.” Although the failure to complete the SSL handshaking operations may allow the server to avoid allocating an SSL socket to such clients, the server may be sufficiently burdened by simply having to perform the exponentiation operations in the partial, failed handshakes that the SSL DDoS attack may nevertheless be successful.
• A third-party mitigation service consistent with embodiments of the present invention may be effective for overcoming these and other limitations of conventional DoS mitigation processes. For example, a third-party mitigation service provider with a sufficiently robust technical infrastructure may be able to fully analyze and evaluate all requesting traffic during a DoS attack, even if such operations require the service provider to bear the full brunt of the DoS attack. In the area of SSL DDoS attacks, in particular, a third-party mitigation service provider may have the resources to open a separate SSL socket and every requesting client in order to challenge the SSL clients using HTTP and other challenge mechanisms. Examples of such challenge mechanisms will be further described with respect toFIGS. 3-5.
• FIG. 3 is a flow diagram illustrating an exemplary method of validating clients by requiring clients to follow through with HTTP redirects, consistent with certain disclosed embodiments. In the method ofFIG. 3, in response to a detected DoS attack, direct communication betweenapplication servers330, owned or operated bycustomer130, andclients310 has been disabled. Client traffic has been diverted to one or moreproxy servers320, e.g., owned or operated by third-party service provider140, for the purpose of identifying whichclients310 are legitimate and whichclients310 are malicious. In particular,FIG. 3 depicts a method for challenging clients that, prior to making any application-layer requests, have requested a secure channel of communications through, e.g., SSL.
• Instep310a,client310 requests an SSL session fromproxy server320 by sending a standard SSL “ClientHello” message. In SSL, the “ClientHello” message contains the SSL version and a list of cryptographic algorithms that the client can support, as well as the client's maximum key length. Although not depicted, prior to this request,client310 andproxy server320 may have exchanged other messages in order to establish a TCP connection.
• In response to the “ClientHello” message,proxy server320 sends a “ServerHello” message toclient310 to indicate which of the client-listed cryptographic algorithms it has selected, as well as the key lengths to be used in the subsequent conversation (step320a). Theproxy server320 also assigns an SSL session ID to uniquely identify theclient310 during subsequent requests fromclient310 and stores that session ID in memory.
• Before the SSL session is established,client310 andproxy server320 may exchange a number of additional messages. For example,proxy server320 may provideclient310 with a copy of its public key and a certificate, e.g., from a Certificate Authority (“CA”), attesting to the authenticity of the public key.Client310 may then generate a symmetric key, encrypt the symmetric key using the public key provided byproxy server320, and transmit the encrypted symmetric key toproxy server320 for use during subsequent communications. Theproxy server320 in turn decrypts the symmetric key using its private key. This decryption operation in particular may causeproxy server320 to perform exponentiation and therefore to expend non-trivial resources. In the event that mutual authentication is requested,client310 also provides a copy of its public key and CA-issued certificate, which are verified byproxy server320, also requiring an exponentiation operation. These and other operations comprise a process known as an SSL “handshake”315a.
• Forproxy server320 to communicate withclient310 using SSL in a manner that allowsproxy server320 to impersonateapplication server330,proxy server320 providesclient310 with a copy of one ofcustomer130's public keys and the certificate issued tocustomer130 vouching for the authenticity of that public key. Otherwise,client310 may reject any other public key thatproxy server320 may provide as not belonging tocustomer130, the party with whomclient310 is attempting to communicate. However,proxy server320 will not be able to decrypt communications fromclient310 that have been encrypted usingcustomer130's public key unlessproxy server320 also has access tocustomer130's private key. Thus, in one aspect of the disclosed invention,proxy server320 is entrusted withcustomer130's private key in order to communicate oncustomer130's behalf with clients that request secure connections.
• After the SSL handshake has been completed (step315a) and the necessary keys exchanged betweenclient310 andproxy server320,client310 will typically make an HTTP request or HTTPS request toproxy server320 using the secure connection (step310b). Ifclient310 is merely a participant in an SSL DDoS attack,client310 may either never complete theSSL handshaking process315aor may never actually request any resources fromproxy server320 over the established secure connection. As previously explained, the SSL handshaking process itself (or even just the first few steps of the SSL handshaking process) may be a sufficient burden on servers that a malicious client would not need to subsequently request any resources from the attacked server after establishing the secure connection. In fact, a malicious client may simply follow the successful creation of an SSL session by requesting additional, separate SSL sessions from the attacked server.
• However, ifclient310 fails to take action after the successful creation of an SSL session, this failure only makes it easier forproxy server320 to filter out malicious traffic. In particular, sinceclient310 never requests any actual resources fromproxy server320 beyond an SSL session,proxy server320 does not need to furtherchallenge client310 to validate, and any cleaned traffic that is forwarded fromproxy server320 toapplication server330 will exclude further traffic fromclient310 by definition. Moreover, even ifclient310 attempts to cause harm by subsequently requesting additional SSL sessions that it doesn't intend to actually use fromproxy server320,client310 will not be able to validate itself in order to proceed toapplication server330, and computational burdens caused byclient310's repeated SSL session requests will be borne byproxy server320, thus protectingapplication server330.
• In one embodiment, simply filtering outclients310 that fail either to perform the full SSL handshaking process or to request subsequent resources following the SSL handshaking process may sufficiently segregate malicious traffic thatproxy server320 may forward all remaining traffic toapplication server330 without performing any further client-challenge or validation operations. Alternatively, if the remaining traffic is still outside the bounds of whatapplication server330 would expect to receive under in the absence of a DoS attack, thenproxy server320 may furthersubject clients310 that request resources following the SSL handshaking process to one or more client-challenge mechanisms.
• Ifclient310 attempts to request a resource fromproxy server320 following the SSL handshaking process, thenproxy server320 may challengeclient310 to validate, since legitimate and malicious clients alike might make application-layer requests after successfully establishing an SSL session. Thus,FIG. 3 depicts the operations of an exemplary client-challenge mechanism thatproxy server320 may employ—in particular,challenging client310 to follow through with one or more HTTP redirects.
• In one embodiment,client310 makes an HTTP request toproxy server320 for aURL resource311b(step310b). However, rather than providing the resource associated withURL311bto client310 (whichproxy server320 may not even have, since its primary role may be only to perform validation and filtering services),proxy server320 may send an HTTP redirect message to client310 (step320b), for example using a “301” or “302” HTTP response status code. TheHTTP redirect message320bmay instructclient310 to make an HTTP request toURL321b, whichproxy server320 has generated by hashing the client's IP address with, e.g., a secret string of characters known only toproxy server320.Proxy server320 may also set a time limit forclient310 to execute the redirect (operations not depicted). Ifclient310 successfully validates by honoring the redirect, as further described below, the time limit may nevertheless be important for preventing the same client or another client with the same IP address from achieving validation at a later time by requesting thesame URL321bin the form of a “replay attack.”
• Since many standard clients are configured to follow through with HTTP redirects as a matter of course,proxy server320 may assume thatclient310 is malicious—e.g., a “dumb” attack script—ifclient310 does not make an HTTP request toproxy server320 forURL321bwithin the established time limit. Accordingly,proxy server320 may blacklistclient310's IP address so that all subsequent requests or communications fromclient310 are either ignored or rate-limited.
• Alternatively,proxy server320 may simply whitelist the IP addresses of any clients that successfully follow the redirect. Ifclient310 honors the redirect, then, instep310c,client310 will make an HTTP request toproxy server320 for the resource associated with hashedURL321b. Whenproxy server320 receives theHTTP request310c,proxy server320 may hash the IP address of the client that made the request (client310) together with the secret string of characters. If the resulting string matches theURL321brequested instep310c, thenproxy server320 will know thatclient310 has honored a challenge redirect provided byproxy server320, sinceclient310 would not have been able to guess theappropriate URL321bto request instep310c(not having access to the secret string of characters). Accordingly,proxy server320 may whitelistclient310's IP address (step320c) and/or SSL session ID on the assumption thatclient310 is a legitimate client and not a “dumb” attack script, and all future requests fromclient310 will be forwarded toapplication server330. Those skilled in the art will appreciate other ways in which the client that madeHTTP request310ccould be linked to the client that madeHTTP request310b, such as creating a simple lookup table onproxy server320mapping client310's IP address or SSL session ID to arandom URL321b.
• At this point, althoughclient310 may have been whitelisted, it has still not yet received the original resource that it requested instep310b. Therefore, instep320d,proxy server320 once again redirectsclient310, this time to theoriginal URL311brequested byclient310 instep310b. In addition, in order to facilitate secure communication betweenclient310 andapplication server330,proxy server320 may also close the SSL connection (e.g., by sending an SSL “close_notify” message) and the TCP connection with client310 (step320e). By closing the SSL connection,client310 may be forced to establish a new SSL connection by sending a new “ClientHello” message to proxy server320 (step310d). Whenproxy server320 receives the “ClientHello” message, it will recognize the IP address in the message as a whitelisted IP address (step3200 and forward the message to application server330 (step320g).
• Sinceapplication server330 will not recognizeclient310 at this point,application server330 will likely requireclient310 to perform a new, full SSL handshake in which new keys may be exchanged and used for secure communication betweenapplication server330 and client310 (operations not depicted). Thereafter, all communications betweenapplication server330 andclient310 may pass throughproxy server320 without the need for further validation (step330a).
• The technique of whitelisting clients that successfully honor redirects may be preferable to blacklisting clients that fail to honor redirects in light of complications with clients that operate from behind a Network Address Translation (“NAT”) service. In a NAT network, multiple clients may be assigned internal IP addresses (typically using a 10.0.0.0/8 address space) that are valid only within the NAT sub-network. All network layer communications from devices within the NAT sub-network to devices outside of the NAT sub-network are sent to a NAT-enabled router, which maps internal IP addresses of the devices to one or more external IP addresses and port numbers and forwards those communications to external devices using the external IP addresses and port numbers. Thus, multiple clients behind a NAT may (and often do) share a single IP address.
• Thus, ifclient310 fails to honor a redirect andproxy server320 responds by blacklistingclient310's IP address, thenproxy server320 may risk erroneously blacklisting other, legitimate clients ifclient310 is operating from behind a NAT, since other, legitimate clients may share that same IP address. Likewise, ifproxy server320 simply whitelists the IP address of clients that successfully honors a redirect, thenproxy server320 risks a situation in which malicious clients may be able to communicate withapplication server330 simply because they share an IP address with a legitimate client that may have previously validated that IP address. In one embodiment, the problem of validating clients behind a NAT may be handled by whitelisting or blacklisting client IP addresses in combination with client port numbers or SSL session IDs.
• In another embodiment, the HTTP redirect client-challenge mechanism may reduce the amount of traffic directed atapplication server330 to a sufficient threshold, even if some malicious clients may still be able to accessapplication server330. And, if the HTTP redirect client-challenge mechanism does not reduce the traffic to a sufficient threshold,proxy server320 may apply one or more additional client-challenge mechanisms, such as the mechanisms described with respect toFIGS. 4 and 5, in an incremental fashion until a workable threshold is achieved.
• Although the foregoing discussion of the HTTP redirect client-challenge mechanism ofFIG. 3 has been described in the context of an SSL or HTTPS connection, those skilled in the art will appreciate that the solution may mitigate against HTTP traffic as well. For example, for HTTP traffic,proxy server320 may requireHTTP client310 to requestredirect URL321band, after receiving such a request, whitelist the client IP address and redirect the client to request to the originally requested URL forapplication server330.
• FIG. 4 is a flow diagram illustrating an exemplary method of validating clients using SSL resumption, consistent with certain disclosed embodiments. In some embodiments, if the HTTP redirect client-challenge mechanism ofFIG. 3 does not reduce the amount of whitelisted traffic to a sufficient threshold, SSL clients may be subjected to an additional challenge to perform SSL resumption.
• SSL resumption is essentially an abbreviated SSL handshaking process in which clients and servers may open a new SSL connection by resuming a previous SSL session rather than creating a new SSL session. In particular, during a full SSL handshake, in which a new SSL session between a client and a server is created, prior to exchanging any symmetric keys, the client and the server must first establish a secure connection using public key encryption. Since public key encryption requires operationally expensive exponentiation operations, SSL resumption achieves efficiencies by allowing clients and servers to establish a new SSL connection that relies on symmetric keys that were securely exchanged (e.g., by public key encryption) during a previous SSL connection.
• Whereas an SSL “connection” may refer to a period during which a client and a server are actively communicating (or connected via a TCP connection) using a set of agreed upon symmetric keys, an SSL “session” may refer to any period of time (e.g., days) in which a client and a server have an agreed upon set of symmetric keys. An SSL session, therefore, may span multiple SSL connections, and a client request to establish a new SSL connection using a previously agreed upon set of symmetric keys is a request to “resume” a previous SSL session.
• Both the client and the server are able to uniquely identify an SSL session using an SSL session ID (or “SSL ID”). When establishing a new SSL session, the server generates an SSL session ID assigned to the client and transmits it to the client as part of the server's “ServerHello” message. InFIG. 4, these operations are depicted insteps410aand420a, in whichclient410 requests a new SSL session by transmitting a “ClientHello” message to proxy server420 (step410a), andproxy server420 responds with a “ServerHello” message that includes anSSL session ID421a(step420a). In someembodiments steps410aand420amay be the same assteps310aand320a. Ifclient410 is responsive to the “ServerHello” message ofstep420a,client410 andproxy server420 may complete the full SSL handshake process as instep315aofFIG. 3.
• Proxy server420 may respond to an HTTP request for aURL411b(step410b) with an HTTP redirect to a hashedURL421bin order to validate client410 (step420b). Ifclient410 follows through with the redirect by requesting hashedURL421b(step410c),proxy server420 may whitelist client410 (step420c). In some embodiments, rather than whitelistingclient410's IP address, which might obscure the existence of multiple distinct clients behind a NAT,proxy server420 may whitelist theSSL session ID421a, either alone or in combination withclient410's IP address.SSL session ID421amay be sufficient to identifyclient410, even if there are other clients that share the same IP address.
• Sinceclient410 has now been whitelisted,proxy server420 redirectsclient410 back to theoriginal URL411bthatclient410 requested instep410b(step420d). In addition,proxy server420 closes the SSL connection (e.g., by sending an SSL “close_notify” message) and its TCP connection with client410 (step420e). Notably, when closing the SSL connection,proxy server420 may take care not to close the SSL session. In this embodiment,client410 will not be able to immediately requestURL411bfromproxy server420, but insteadclient410 will need to first establish a new SSL connection, which will requireclient410 to initiate an SSL handshake by transmitting another “ClientHello” message (step410d).
• At this point, a legitimate client would be most likely to request resumption of the SSL session it had established withproxy server420 moments prior. Thus, ifclient410 is legitimate, it will likely includeSSL session ID421ain its “ClientHello” message instep410d. Onceproxy server420 receivesSSL session ID421afromclient410,proxy server420 may verify that it previously whitelisted the SSL session ID and/or SSL session ID/IP address combination (step4200 and therefore assume thatclient410 is legitimate.
• If, however,client410 does not request SSL session resumption by transmittingSSL session ID421ain its “ClientHello” message, thenclient410 may appear no different from any other client that requests a new SSL session instep410a, and will therefore be required to perform the same challenge steps it had previously performed (e.g., steps410b,420b,410c,402d, etc.), potentially in an infinite-loop fashion. As such,client410 may never reachapplication server430, effectively being blacklisted by virtue of being repeatedly challenged byproxy server420.
• Returning to the case whenclient410 does request SSL session resumption,proxy server420 may forwardclient410's SSL connection request, including theSSL session ID421ato application server430 (step420g). However, sinceapplication server430 may not have established any previous SSL session withclient410,application server430 may not recognizeSSL session ID421a. Accordingly,application server430 may requireclient410 to perform a new, full SSL handshake by generating a newSSL session ID431aand transmitting the new ID toclient410 as part ofapplication server430's “ServerHello” message (step430a). Because communications betweenapplication server430 andclient410 are still being routed throughproxy server420,proxy server420 may receiveapplication server430's “ServerHello” message (containing the newSSL session ID431a) and relay it to client410 (step420i). Thereafter,application server430 andclient410 may communicate in a secured manner usingproxy server420 as an intermediary (step430b)
• In addition to relayingapplication server430's “ServerHello” message,proxy server420 may also inspect the message packet to note the newSSL session ID431athatapplication server430 has assigned toclient410 and to whitelist that session ID (step420h).Proxy server420 may whitelist the newSSL session ID431aso that whenclient410 makes future requests toapplication server430 throughproxy server420 containing the newSSL session ID431a, rather than the previously whitelistedSSL session ID421a,proxy server420 may be able to recognizeclient410 as a whitelisted client andforward client410's communications toapplication server430. Otherwise,proxy server420 may not recognize the newSSL session ID431a, and may requireclient410 to validate again.
• In one aspect of the invention, afterapplication server430 andclient410 have successfully established an SSL session andproxy server420 has whitelisted the new session ID associated with that session,client410 andapplication server430 may then communicate securely throughproxy server420 without allowingproxy server420 to decrypt their communications (step430b). For example, the entity that owns or operatesproxy server420 may be a third-party service provider, e.g.,service provider140, that should not have access to encrypted communications betweenapplication server430 andclient410 beyond the process of initially validatingclient410.
• Sinceproxy server420 may already have a copy ofapplication server430's private key, secure communication betweenapplication server430 andclient410 may be achieved in a number of ways. In one embodiment,proxy server420 may ignore the contents of communications betweenapplication server430 andclient410 during the SSL handshaking process between the devices (other than to detect the SSL session ID needed to determine whetherclient410 had been whitelisted). Once the SSL handshaking process betweenapplication server430 andclient410 is complete,application server430 andclient410 may have agreed upon a set of symmetric keys for encrypting communications between them. By ignoring the contents of this handshaking process,proxy server420 would not know which symmetric keys are being used in the SSL session and therefore would not be able to decrypt communications betweenapplication server430 andclient410 despite having a copy ofapplication server430's private key.
• In another embodiment,application server430 may maintain a second private key that it does not share withproxy server420. Afterclient410 has been validated byproxy server420,application server430 could perform a full SSL handshake by sendingclient410 a copy of a second public key (corresponding toapplication server430's second private key), along with a valid certificate for the second public key, which could be used to securely exchange symmetric keys withclient410. Becauseproxy server420 does not have a copy ofapplication server430's second private key,proxy server420 will not be able to decrypt SSL handshaking communications fromapplication server430. This is especially the case ifapplication server430 imposes a mutual authentication requirement on the handshake (requiring the client to authenticate using its public key and certificate), which may preventproxy server420 from engaging in a “man-in-the-middle” attack.
• After subjecting clients to an SSL session resumption client-challenge mechanism,proxy server420 may assess whether resulting whitelisted traffic falls below a particular threshold. In some embodiments, if the SSL session resumption client-challenge mechanism does not reduce the traffic to a sufficient threshold,proxy server420 may apply additional client-challenge mechanisms, such as the mechanism described with respect toFIG. 5, in an incremental fashion until the threshold is achieved.
• FIG. 5 is a flow diagram illustrating an exemplary method of validating clients using HTTP cookies, consistent with certain disclosed embodiments. Whenclient510 requests a new SSL session by transmitting a “ClientHello” message to proxy server520 (step510a),proxy server520 responds with a “ServerHello” message that includes anSSL session ID521a. Provided thatclient510 is responsive to the “ServerHello” message ofstep520a,client510 andproxy server520 may complete the full SSL handshake process, e.g., in a manner similar to that described with respect to step315aofFIG. 3.
• Proxy server520 may respond to an HTTP request for aURL511b(step510b) with an HTTP redirect to a hashedURL521b(step520b). In the embodiment ofFIG. 5,proxy server520 may also include an HTTP cookie in its response (step520b). In one embodiment,proxy server520 redirectsclient510 to aURL521bwithin a randomly generatedpath522b.Proxy server520 may also include anHTTP cookie523bin the response containing a random value and a path attribute corresponding topath522b. The path attribute specifies thatclient510 is to returncookie523btoproxy server520, but only ifclient510 makes an HTTP request for a resource withinpath522b.Cookie523bmay also include other attributes, such as “domain,” “expires,” and “secure.”
• In order forclient510 to validate,client510 must not only honor the redirect by requestingURL521b, but must also includeHTTP cookie523bin the request by matching the path ofURL521bwith the path attribute ofHTTP cookie523b(step510c).Proxy server520 may assume that a “dumb” attack script may not include functionality for storing HTTP cookies or following particular cookie rules with respect to path attributes. Ifproxy server520 receives the HTTP request forURL521bfromclient510, along with theappropriate cookie523bcorresponding to thepath522bofURL521bandclient510's IP address, then proxy server may whitelistclient510 using its IP address and SSL session ID (step520c).
• Thereafter,proxy server520 may manage communication betweenclient510 andapplication server530 followingsteps520d,520e,510d,520f,520g,530a,520h,520i, and530b, as shown. In some embodiments, these steps may be analogous tosteps420d,420e,410d,420f,420g,430a,420h,420i, and430b. Those skilled in the art will appreciate that foregoing description is merely exemplary for testing the capabilities of a client with respect to its ability to properly store and transmit HTTP cookies for the purpose of validating the client. Those skilled in the art will appreciate that the foregoing technique may be modified or simplified to mitigate against HTTP-based attacks, and not merely HTTPS-based DDoS attacks. For example, for HTTP-based DDoS attacks,proxy server520 may similarly validate HTTP clients by transmitting HTTP cookies and evaluating the HTTP clients' ability to store and return the HTTP cookies. HTTP clients may be whitelisted using their IP addresses or IP addresses in combination with HTTP cookie values assigned to particular IP addresses byproxy server520.
• Under any of the previously described client-challenge mechanisms, once the client has been validated, the application server and the client may communicate through the proxy server (e.g., as insteps330a,430a, and530a) using a number of techniques. In one embodiment, usingFIG. 5 as an example, onceclient510 has been validated,proxy server520 may enableclient510 to communicate withapplication server530 by continuing to operate in the role of a proxy server. For example, communications fromclient510 toapplication server530 may terminate atproxy server520;proxy server520 may copy the communication; andproxy server520 may send a copy of the communication toapplication server530.Proxy server520 may operate similarly with respect to communications fromapplication server530 directed toclient510.
• In this example, communications fromproxy server520 toapplication server530 would indicateproxy server520's IP address in the “Source Address” field of the IP datagram. As such,application server530 may not be able to determine which clients are making requests to it, since arriving requests would appear to come fromproxy server520. To overcome this limitation,proxy server520 may allow communications fromclient510 to “transparently” pass throughproxy server520 by modifying IP datagrams transmitted byproxy server520 toapplication server530 to indicateclient510's IP address in the “Source Address” field of the datagram rather thanproxy server520's IP address.Proxy server520 could accomplish this modification using, for instance, the “Netfilter” or “IP sets” framework of the Linux kernel.
• Alternatively,proxy server520 could provideapplication server530 with information about requestingclient510 by including client information, such asclient510's IP address, in one or more HTTP headers transmitted toapplication server530. In yet another embodiment,proxy server520 could transition to operating in the mode of a traditional router or link-layer switch by simply forwarding any packets received fromclient510 toapplication server530 without demultiplexing higher layers of the Internet protocol stack. Under these approaches,application server530 could be apprised of which clients are requesting resources fromapplication server530 and could keep records to individually track malicious users or compile information that may be useful for marketing or other analysis.
• Returning toFIG. 2, onceproxy servers245 determine that the DoS attack has subsided or that traffic directed toapplication servers135 has returned to acceptable levels,proxy servers245, or other servers associated withservice provider140, may initiate a process of redirecting traffic back toapplication servers135. Thus, for example,proxy servers245 could advertise a BGP “swing” back toapplication servers135 in order to remove themselves from the routing path. Alternatively,proxy servers245 could request a reversal of any previous DNS record alteration to reassign one or more domain names hosted byapplication servers135 back to IP addresses associated withapplication servers135.
• Becauseproxy servers245 may have used ofcustomer130's private key to validate SSL traffic during the mitigation event,proxy servers245 could attempt to restore security toapplication servers135 by, for example, permanently deleting the private key (and any copies of the key) or sending a reminder tocustomer130 to revoke the certificate associated with its corresponding public key. Thereafter,proxy servers245 ormonitoring servers145 may return tomonitoring application servers135 to detect any subsequent DoS attacks and, if necessary, to undertake corrective action, such as the above-described mitigation operations.
• In some embodiments,proxy servers245 may validate SSL traffic directed atapplication servers135 without using or obtaining access tocustomer130's private key. For example, clients requesting HTTPS access toapplication servers135 may be required byproxy servers245 to using a challenge mechanism, such as the above-described HTTP redirect or HTTP cookie client-challenge mechanisms, that may be implemented over HTTP. Onceproxy servers245 validate a client over HTTP, the validated client is allowed to accessapplication servers135 using HTTPS (e.g., using HTTPS port443). Validated clients may be whitelisted using their IP addresses or IP addresses in combination with other information. To protect against potential misuse of port443 by the whitelisted clients,proxy servers245 may limit the number of connections to port443 that whitelisted clients may have open at any given time.
• The foregoing description of the invention, along with its associated embodiments, has been presented for purposes of illustration only. It is not exhaustive and does not limit the invention to the precise form disclosed. Those skilled in the art will appreciate from the foregoing description that modifications and variations are possible in light of the above teachings or may be acquired from practicing the invention. For example, although described in connection with a third-party mitigation service, the above-described client-challenge mechanisms could also be performed by the application servers themselves. The steps described need not be performed in the same sequence discussed or with the same degree of separation. Likewise various steps may be omitted, repeated, or combined, as necessary, to achieve the same or similar objectives. Accordingly, the invention is not limited to the above-described embodiments, but instead is defined by the appended claims in light of their full scope of equivalents.

Claims (90)

1. A computer-implemented method of mitigating against a denial of service (DoS) attack, comprising:

detecting a DoS attack or potential DoS attack against a first server system comprising one or more servers;

receiving, at a second server system comprising one or more servers, network traffic directed to the first server system;

subjecting requesting clients to one or more challenge mechanisms, the challenge mechanisms including one or more of challenging requesting clients to follow through HTTP redirect responses, challenging requesting clients to request Secure Sockets Layer (SSL) session resumption, or challenging requesting clients to store and transmit HTTP cookies;

identifying one or more non-suspect clients, the one or more suspect clients corresponding to requesting clients that successfully complete the one or more challenge mechanisms;

identifying one or more suspect clients, the one or more suspect clients corresponding to requesting clients that do not successfully complete the one or more challenge mechanisms; and

forwarding, by the second server system, traffic corresponding to the one or more non-suspect clients to the first server system.

2. The method ofclaim 1, further comprising:

redirecting network traffic directed to the first server system to the second server system in response to detecting the DoS attack or potential DoS attack against the first server system.

3. The method ofclaim 2, further comprising:

detecting a sufficient mitigation of the DoS attack or potential DoS attack; and

redirecting the network traffic directed to the first server system back to the first server system.

4. The method ofclaim 2, wherein redirecting network traffic directed to the first server system to the second server system further comprises:

transmitting one or more Border Gateway Protocol (BGP) messages to advertise that traffic directed to the first server system should be routed through the second server system.

5. The method ofclaim 2, wherein redirecting network traffic directed to the first server system to the second server system further comprises:

requesting a Domain Name Services (DNS) record alteration to reassign one or more domain names assigned to one or more Internet Protocol (IP) addresses associated with the first server system to one or more IP addresses associated with the second server system.

6. The method ofclaim 1, wherein the DoS attack comprises an SSL DoS attack.

7. The method ofclaim 6, wherein receiving, at the second server system, network traffic directed to the first server system comprises:

using, by the second server system, one or more encryption keys belonging to an owner of the first server system to decrypt secure network traffic directed to the first server system, wherein the first server system and the second server system are owned by different entities.

8. The method ofclaim 7, wherein the second server system uses one or more private asymmetric encryption keys belonging to the owner of the first server system.

9. The method ofclaim 1, wherein the first server system and the second server system are owned by different entities.

10. The method ofclaim 9, wherein an owner of the second server system provides the operations of identifying suspect and non-suspect clients and forwarding traffic from non-suspect clients as part of a commercial DoS attack mitigation service.

11. The method ofclaim 1, wherein subjecting requesting clients to one or more challenge mechanisms comprises:

receiving a first HTTP request from a client directed to the first server system;

sending, by the second server system, an HTTP redirect response to the client;

categorizing the client as non-suspect in response to a determination that the client has transmitted a second HTTP request according to the HTTP redirect response.

12. The method ofclaim 11, wherein the HTTP redirect response directs the client to make the second HTTP request to a URL particularly associated with the client by the second server system.

13. The method ofclaim 1, wherein subjecting requesting clients to one or more challenge mechanisms comprises:

challenging a client to request SSL session resumption; and

categorizing the client as non-suspect in response to a determination that the client has correctly requested SSL session resumption.

14. The method ofclaim 13, wherein challenging the client to request SSL session resumption comprises:

establishing, by the second server system, an SSL session and an SSL connection with the client, wherein the SSL session includes an SSL session ID particularly associated with the client;

closing the SSL connection with the client; and

categorizing the client as non-suspect in response to a determination that the client has subsequently requested a new SSL connection using the SSL session ID particularly associated with the client.

15. The method ofclaim 1, wherein subjecting requesting clients to one or more challenge mechanisms comprises:

categorizing a client as suspect or non-suspect based on the client's ability to properly store and transmit an HTTP cookie sent by the second server system.

16. The method ofclaim 15, further comprising:

transmitting an HTTP cookie to the client containing a value particularly associated with the client;

categorizing the client as non-suspect in response to a determination that the client has transmitted a cookie containing the value particularly associated with the client in a subsequent HTTP request.

17. The method ofclaim 1, wherein subjecting requesting clients to one or more challenge mechanisms comprises:

directing clients to complete multiple challenge mechanisms until a portion of network traffic originating from non-suspect clients reaches a threshold.

18. The method ofclaim 1, wherein identifying one or more non-suspect clients further comprises:

whitelisting clients that successfully complete one or more challenge mechanisms.

19. The method ofclaim 18, further comprising:

whitelisting clients that successfully complete one or more challenge mechanisms using at least the successful clients' IP addresses.

20. The method ofclaim 18, further comprising:

whitelisting clients that successfully complete one or more challenge mechanisms using at least SSL session IDs particularly associated with the successful clients.

21. The method ofclaim 18, further comprising:

whitelisting clients that successfully complete one or more challenge mechanisms using at least HTTP cookie values particularly associated with the successful clients.

22. The method ofclaim 1, wherein identifying one or more suspect clients further comprises:

blacklisting clients that fail to complete one or more challenge mechanisms.

23. The method ofclaim 1, wherein forwarding, by the second server system, traffic corresponding to the one or more non-suspect clients to the first server system further comprises:

discarding traffic corresponding to suspect clients.

24. The method ofclaim 1, wherein forwarding, by the second server system, traffic corresponding to the one or more non-suspect clients to the first server system further comprises:

rate-limiting traffic corresponding to suspect clients.

25. The method ofclaim 1, wherein forwarding, by the second server system, traffic corresponding to the one or more non-suspect clients to the first server system further comprises:

operating as an intermediary for communications between a client and the first server system once the client has been identified as non-suspect.

26. The method ofclaim 25, further comprising:

decrypting, by the second server system, secure communications from the client to determine whether the client is suspect or non-suspect; and

after determining that the client is non-suspect, operating as an intermediary for secure communications between the client and the first server system without decrypting the secure communications between the client and the first server system.

27. The method ofclaim 25, further comprising:

enabling communications from the client to the first server system to pass through the second server system in a manner that preserves the client's IP address.

28. The method ofclaim 27, further comprising:

including the client's IP address in an HTTP header in a communication from the second server system to the first server system forwarding a communication from the client directed to the first server system.

29. The method ofclaim 27, further comprising:

operating, by the second server system, as a router to allow communications from the client to the first server system to terminate at the first server system.

30. The method ofclaim 27, further comprising:

transmitting a first communication from the second server system to the first server system forwarding a previously received second communication from the client directed to the first server system; and

modifying the first communication from the second server system to the first server system to substitute the client's IP address for the second server system's IP address.

31. A computer-implemented method of mitigating against a Secure Sockets Layer (SSL) denial of service (DoS) attack, comprising:

detecting an SSL DoS attack or potential SSL DoS attack against a first server system comprising one or more servers;

receiving, at a second server system comprising one or more servers, network traffic directed to the first server system, wherein the first server system and the second server system are owned by different entities, and the second server system uses one or more encryption keys belonging to an owner of the first server system to decrypt secure network traffic directed to the first server system

subjecting requesting clients to one or more challenge mechanisms;

identifying one or more non-suspect clients, the one or more suspect clients corresponding to requesting clients that successfully complete the one or more challenge mechanisms;

identifying one or more suspect clients, the one or more suspect clients corresponding to requesting clients that do not successfully complete the one or more challenge mechanisms; and

forwarding, by the second server system, traffic corresponding to the one or more non-suspect clients to the first server system.

32. The method ofclaim 31, wherein the second server system uses one or more private asymmetric encryption keys belonging to the owner of the first server system.

33. The method ofclaim 31, wherein forwarding, by the second server system, traffic corresponding to the one or more non-suspect clients to the first server system further comprises:

operating as an intermediary for communications between a client and the first server system once the client has been identified as non-suspect.

34. The method ofclaim 33, further comprising:

decrypting, by the second server system, secure communications from the client to determine whether the client is suspect or non-suspect; and

after determining that the client is non-suspect, operating as an intermediary for secure communications between the client and the first server system without decrypting the secure communications between the client and the first server system.

35. The method ofclaim 34, further comprising:

using, by the second server system, a first encryption key to decrypt secure communications from the client to determine whether the client is suspect or non-suspect; and

after determining that the client is non-suspect, operating as an intermediary for secure communications between the client and the first server system that are encrypted using a second encryption key to which the second server system does not have access.

36. The method ofclaim 31, wherein identifying one or more non-suspect clients further comprises:

whitelisting clients that successfully complete one or more challenge mechanisms using at least SSL session IDs particularly associated with the successful clients.

37. A computer-implemented method of mitigating against a denial of service (DoS) attack, comprising:

receiving a first HTTP request from a client;

sending an HTTP redirect response to the client;

if the client transmits a second HTTP request according to the HTTP redirect response, categorizing the client as non-suspect; and

if the client does not transmit a second HTTP request according to the HTTP redirect response, categorizing the client as suspect.

38. The method ofclaim 37, wherein categorizing the client as non-suspect comprises servicing future requests from the client, and wherein categorizing the client as suspect comprises rate-limiting or declining to service future requests from the client.

39. The method ofclaim 37, wherein the HTTP redirect response directs the client to make the second HTTP request to a URL particularly associated with the client by the second server system.

40. A computer-implemented method of mitigating against a Secure Sockets Layer (SSL) denial of service (DoS) attack, comprising:

receiving a request for an SSL session from a client;

establishing an SSL session and a first SSL connection with the client, wherein the SSL session includes an SSL session ID particularly associated with the client;

closing the first SSL connection with the client;

receiving a subsequent request from the client to establish a second SSL connection;

categorizing the client as non-suspect if the client requests the second SSL connection using the SSL session ID particularly associated with the client; and

categorizing the client as suspect if the client requests the second SSL connection without using the SSL session ID particularly associated with the client.

41. The method ofclaim 40, further comprising:

determining that the client has requested the second SSL connection without using the SSL session ID particularly associated with the client; and

in response to the determining, declining to establish a new SSL session with the client.

42. The method ofclaim 41, further comprising:

declining to service subsequent requests from the client.

43. A computer-implemented method of mitigating against a denial of service (DoS) attack, comprising:

receiving a first HTTP request from a client;

sending an HTTP response to the client, wherein the HTTP response includes an HTTP cookie;

receiving a second HTTP request from the client;

if the second HTTP request includes the HTTP cookie, categorizing the client as non-suspect; and

if the second HTTP request does not include the HTTP cookie, categorizing the client as suspect.

44. The method ofclaim 43, wherein the HTTP cookie contains a value particularly associated with the client; and wherein the client is categorized as suspect or non-suspect depending on whether the HTTP cookie in the second HTTP request contains the value particularly associated with the client.

45. The method ofclaim 44, wherein the HTTP response comprises an HTTP redirect response that directs the client to make the second HTTP request to a URL particularly associated with either the client or the HTTP cookie value particularly associated with the client.

46. A system for mitigating against a denial of service (DoS) attack, comprising:

a processing system comprising one or more processors;

one or more communications ports for receiving communications from one or more networked devices and transmitting communications to one or more networked devices; and

a memory system comprising one or more computer-readable media, wherein the computer-readable media store instructions that, when executed by the processing system, cause the system to perform the operations of:

detecting a DoS attack or potential DoS attack against a first server system comprising one or more servers;

receiving, at a second server system comprising one or more servers, network traffic directed to the first server system;

subjecting requesting clients to one or more challenge mechanisms, the challenge mechanisms including one or more of challenging requesting clients to follow through HTTP redirect responses, challenging requesting clients to request Secure Sockets Layer (SSL) session resumption, or challenging requesting clients to store and transmit HTTP cookies;

identifying one or more non-suspect clients, the one or more suspect clients corresponding to requesting clients that successfully complete the one or more challenge mechanisms;

identifying one or more suspect clients, the one or more suspect clients corresponding to requesting clients that do not successfully complete the one or more challenge mechanisms; and

forwarding, by the second server system, traffic corresponding to the one or more non-suspect clients to the first server system.

47. The system ofclaim 46, the operations further comprising:

redirecting network traffic directed to the first server system to the second server system in response to detecting the DoS attack or potential DoS attack against the first server system.

48. The system ofclaim 47, the operations further comprising:

detecting a sufficient mitigation of the DoS attack or potential DoS attack; and

redirecting the network traffic directed to the first server system back to the first server system.

49. The system ofclaim 47, wherein redirecting network traffic directed to the first server system to the second server system further comprises:

transmitting one or more Border Gateway Protocol (BGP) messages to advertise that traffic directed to the first server system should be routed through the second server system.

50. The system ofclaim 47, wherein redirecting network traffic directed to the first server system to the second server system further comprises:

requesting a Domain Name Services (DNS) record alteration to reassign one or more domain names assigned to one or more Internet Protocol (IP) addresses associated with the first server system to one or more IP addresses associated with the second server system.

51. The system ofclaim 46, wherein the DoS attack comprises an SSL DoS attack.

52. The system ofclaim 51, wherein receiving, at the second server system, network traffic directed to the first server system comprises:

using, by the second server system, one or more encryption keys belonging to an owner of the first server system to decrypt secure network traffic directed to the first server system, wherein the first server system and the second server system are owned by different entities.

53. The system ofclaim 52, wherein the second server system uses one or more private asymmetric encryption keys belonging to the owner of the first server system.

54. The system ofclaim 46, wherein the first server system and the second server system are owned by different entities.

55. The system ofclaim 54, wherein an owner of the second server system provides the operations of identifying suspect and non-suspect clients and forwarding traffic from non-suspect clients as part of a commercial DoS attack mitigation service.

56. The system ofclaim 46, wherein subjecting requesting clients to one or more challenge mechanisms comprises:

receiving a first HTTP request from a client directed to the first server system;

sending, by the second server system, an HTTP redirect response to the client;

categorizing the client as non-suspect in response to a determination that the client has transmitted a second HTTP request according to the HTTP redirect response.

57. The system ofclaim 56, wherein the HTTP redirect response directs the client to make the second HTTP request to a URL particularly associated with the client by the second server system.

58. The system ofclaim 46, wherein subjecting requesting clients to one or more challenge mechanisms comprises:

challenging a client to request SSL session resumption; and

categorizing the client as non-suspect in response to a determination that the client has correctly requested SSL session resumption.

59. The system ofclaim 58, wherein challenging the client to request SSL session resumption comprises:

establishing, by the second server system, an SSL session and an SSL connection with the client, wherein the SSL session includes an SSL session ID particularly associated with the client;

closing the SSL connection with the client; and

categorizing the client as non-suspect in response to a determination that the client has subsequently requested a new SSL connection using the SSL session ID particularly associated with the client.

60. The system ofclaim 46, wherein subjecting requesting clients to one or more challenge mechanisms comprises:

categorizing a client as suspect or non-suspect based on the client's ability to properly store and transmit an HTTP cookie sent by the second server system.

61. The system ofclaim 60, the operations further comprising:

transmitting an HTTP cookie to the client containing a value particularly associated with the client;

categorizing the client as non-suspect in response to a determination that the client has transmitted a cookie containing the value particularly associated with the client in a subsequent HTTP request.

62. The system ofclaim 46, wherein subjecting requesting clients to one or more challenge mechanisms comprises:

directing clients to complete multiple challenge mechanisms until a portion of network traffic originating from non-suspect clients reaches a threshold.

63. The system ofclaim 46, wherein identifying one or more non-suspect clients further comprises:

whitelisting clients that successfully complete one or more challenge mechanisms.

64. The system ofclaim 63, the operations further comprising:

whitelisting clients that successfully complete one or more challenge mechanisms using at least the successful clients' IP addresses.

65. The system ofclaim 63, the operations further comprising:

whitelisting clients that successfully complete one or more challenge mechanisms using at least SSL session IDs particularly associated with the successful clients.

66. The system ofclaim 63, the operations further comprising:

whitelisting clients that successfully complete one or more challenge mechanisms using at least HTTP cookie values particularly associated with the successful clients.

67. The system ofclaim 46, wherein identifying one or more suspect clients further comprises:

blacklisting clients that fail to complete one or more challenge mechanisms.

68. The system ofclaim 46, wherein forwarding, by the second server system, traffic corresponding to the one or more non-suspect clients to the first server system further comprises:

discarding traffic corresponding to suspect clients.

69. The system ofclaim 46, wherein forwarding, by the second server system, traffic corresponding to the one or more non-suspect clients to the first server system further comprises:

rate-limiting traffic corresponding to suspect clients.

70. The system ofclaim 46, wherein forwarding, by the second server system, traffic corresponding to the one or more non-suspect clients to the first server system further comprises:

operating as an intermediary for communications between a client and the first server system once the client has been identified as non-suspect.

71. The system ofclaim 70, the operations further comprising:

decrypting, by the second server system, secure communications from the client to determine whether the client is suspect or non-suspect; and

after determining that the client is non-suspect, operating as an intermediary for secure communications between the client and the first server system without decrypting the secure communications between the client and the first server system.

72. The system ofclaim 70, the operations further comprising:

enabling communications from the client to the first server system to pass through the second server system in a manner that preserves the client's IP address.

73. The system ofclaim 72, the operations further comprising:

including the client's IP address in an HTTP header in a communication from the second server system to the first server system forwarding a communication from the client directed to the first server system.

74. The system ofclaim 72, the operations further comprising:

operating, by the second server system, as a router to allow communications from the client to the first server system to terminate at the first server system.

75. The system ofclaim 72, the operations further comprising:

transmitting a first communication from the second server system to the first server system forwarding a previously received second communication from the client directed to the first server system; and

modifying the first communication from the second server system to the first server system to substitute the client's IP address for the second server system's IP address.

76. A system for mitigating against a Secure Sockets Layer (SSL) denial of service (DoS) attack, comprising:

a processing system comprising one or more processors;

one or more communications ports for receiving communications from one or more networked devices and transmitting communications to one or more networked devices; and

a memory system comprising one or more computer-readable media, wherein the computer-readable media store instructions that, when executed by the processing system, cause the system to perform the operations of:

detecting an SSL DoS attack or potential SSL DoS attack against a first server system comprising one or more servers;

receiving, at a second server system comprising one or more servers, network traffic directed to the first server system, wherein the first server system and the second server system are owned by different entities, and the second server system uses one or more encryption keys belonging to an owner of the first server system to decrypt secure network traffic directed to the first server system

subjecting requesting clients to one or more challenge mechanisms;

identifying one or more non-suspect clients, the one or more suspect clients corresponding to requesting clients that successfully complete the one or more challenge mechanisms;

identifying one or more suspect clients, the one or more suspect clients corresponding to requesting clients that do not successfully complete the one or more challenge mechanisms; and

forwarding, by the second server system, traffic corresponding to the one or more non-suspect clients to the first server system.

77. The system ofclaim 76, wherein the second server system uses one or more private asymmetric encryption keys belonging to the owner of the first server system.

78. The system ofclaim 76, wherein forwarding, by the second server system, traffic corresponding to the one or more non-suspect clients to the first server system further comprises:

operating as an intermediary for communications between a client and the first server system once the client has been identified as non-suspect.

79. The system ofclaim 78, the operations further comprising:

decrypting, by the second server system, secure communications from the client to determine whether the client is suspect or non-suspect; and

after determining that the client is non-suspect, operating as an intermediary for secure communications between the client and the first server system without decrypting the secure communications between the client and the first server system.

80. The system ofclaim 79, the operations further comprising:

using, by the second server system, a first encryption key to decrypt secure communications from the client to determine whether the client is suspect or non-suspect; and

after determining that the client is non-suspect, operating as an intermediary for secure communications between the client and the first server system that are encrypted using a second encryption key to which the second server system does not have access.

81. The system ofclaim 76, wherein identifying one or more non-suspect clients further comprises:

whitelisting clients that successfully complete one or more challenge mechanisms using at least SSL session IDs particularly associated with the successful clients.

82. A system for mitigating against a denial of service (DoS) attack, comprising:

a processing system comprising one or more processors;

one or more communications ports for receiving communications from one or more networked devices and transmitting communications to one or more networked devices; and

a memory system comprising one or more computer-readable media, wherein the computer-readable media store instructions that, when executed by the processing system, cause the system to perform the operations of:

receiving a first HTTP request from a client;

sending an HTTP redirect response to the client;

if the client transmits a second HTTP request according to the HTTP redirect response, categorizing the client as non-suspect; and

if the client does not transmit a second HTTP request according to the HTTP redirect response, categorizing the client as suspect.

83. The system ofclaim 82, wherein categorizing the client as non-suspect comprises servicing future requests from the client, and wherein categorizing the client as suspect comprises rate-limiting or declining to service future requests from the client.

84. The system ofclaim 82, wherein the HTTP redirect response directs the client to make the second HTTP request to a URL particularly associated with the client by the second server system.

85. A system for mitigating against a Secure Sockets Layer (SSL) denial of service (DoS) attack, comprising:

a processing system comprising one or more processors;

one or more communications ports for receiving communications from one or more networked devices and transmitting communications to one or more networked devices; and

a memory system comprising one or more computer-readable media, wherein the computer-readable media store instructions that, when executed by the processing system, cause the system to perform the operations of:

receiving a request for an SSL session from a client;

establishing an SSL session and a first SSL connection with the client, wherein the SSL session includes an SSL session ID particularly associated with the client;

closing the first SSL connection with the client;

receiving a subsequent request from the client to establish a second SSL connection;

categorizing the client as non-suspect if the client requests the second SSL connection using the SSL session ID particularly associated with the client; and

categorizing the client as suspect if the client requests the second SSL connection without using the SSL session ID particularly associated with the client.

86. The system ofclaim 85, the operations further comprising:

determining that the client has requested the second SSL connection without using the SSL session ID particularly associated with the client; and

in response to the determining, declining to establish a new SSL session with the client.

87. The system ofclaim 86, the operations further comprising:

declining to service subsequent requests from the client.

88. A system for mitigating against a denial of service (DoS) attack, comprising:

a processing system comprising one or more processors;

one or more communications ports for receiving communications from one or more networked devices and transmitting communications to one or more networked devices; and

a memory system comprising one or more computer-readable media, wherein the computer-readable media store instructions that, when executed by the processing system, cause the system to perform the operations of:

receiving a first HTTP request from a client;

sending an HTTP response to the client, wherein the HTTP response includes an HTTP cookie;

receiving a second HTTP request from the client;

if the second HTTP request includes the HTTP cookie, categorizing the client as non-suspect; and

if the second HTTP request does not include the HTTP cookie, categorizing the client as suspect.

89. The system ofclaim 88, wherein the HTTP cookie contains a value particularly associated with the client; and wherein the client is categorized as suspect or non-suspect depending on whether the HTTP cookie in the second HTTP request contains the value particularly associated with the client.

90. The system ofclaim 89, wherein the HTTP response comprises an HTTP redirect response that directs the client to make the second HTTP request to a URL particularly associated with either the client or the HTTP cookie value particularly associated with the client.

Images