US20120174196A1 - Active validation for ddos and ssl ddos attacks - Google Patents
Active validation for ddos and ssl ddos attacks Download PDFInfo
- Publication number
- US20120174196A1 US20120174196A1 US12/982,520 US98252010A US2012174196A1 US 20120174196 A1 US20120174196 A1 US 20120174196A1 US 98252010 A US98252010 A US 98252010A US 2012174196 A1 US2012174196 A1 US 2012174196A1
- Authority
- US
- United States
- Prior art keywords
- client
- server system
- clients
- suspect
- http
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Abandoned
Links
- 238000010200 validation analysis Methods 0.000 title description 5
- 238000000034 method Methods 0.000 claims abstract description 96
- 230000007246 mechanism Effects 0.000 claims abstract description 62
- 230000004044 response Effects 0.000 claims abstract description 46
- 235000014510 cooky Nutrition 0.000 claims abstract description 40
- 238000004891 communication Methods 0.000 claims description 103
- 230000000116 mitigating effect Effects 0.000 claims description 33
- 238000012545 processing Methods 0.000 claims description 11
- 230000004075 alteration Effects 0.000 claims description 4
- 230000008569 process Effects 0.000 description 26
- 238000010586 diagram Methods 0.000 description 10
- 238000012544 monitoring process Methods 0.000 description 10
- 238000013515 script Methods 0.000 description 6
- 230000008901 benefit Effects 0.000 description 4
- 238000001914 filtration Methods 0.000 description 4
- 238000012986 modification Methods 0.000 description 3
- 230000004048 modification Effects 0.000 description 3
- 230000009471 action Effects 0.000 description 2
- 238000004422 calculation algorithm Methods 0.000 description 2
- 238000013478 data encryption standard Methods 0.000 description 2
- 230000006978 adaptation Effects 0.000 description 1
- 238000013459 approach Methods 0.000 description 1
- 230000005540 biological transmission Effects 0.000 description 1
- 230000001010 compromised effect Effects 0.000 description 1
- 238000001514 detection method Methods 0.000 description 1
- 230000006870 function Effects 0.000 description 1
- 238000013507 mapping Methods 0.000 description 1
- 238000012552 review Methods 0.000 description 1
- 238000000926 separation method Methods 0.000 description 1
- 238000012360 testing method Methods 0.000 description 1
- 238000012546 transfer Methods 0.000 description 1
- 230000007704 transition Effects 0.000 description 1
- 238000013519 translation Methods 0.000 description 1
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
- H04L63/1408—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic by monitoring network traffic
- H04L63/1416—Event detection, e.g. attack signature detection
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
- H04L63/1441—Countermeasures against malicious traffic
- H04L63/1458—Denial of Service
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
- H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
- H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
- H04L9/0819—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s)
- H04L9/0825—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) using asymmetric-key encryption or public key infrastructure [PKI], e.g. key signature or public key certificates
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L2463/00—Additional details relating to network architectures or network communication protocols for network security covered by H04L63/00
- H04L2463/141—Denial of service attacks against endpoints in a network
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L2463/00—Additional details relating to network architectures or network communication protocols for network security covered by H04L63/00
- H04L2463/144—Detection or countermeasures against botnets
Definitions
- 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.
- 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.
- clients networked devices
- the server 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.
- TCP Transmission Control Protocol
- HTTP hypertext transfer protocol
- 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.
- IP Internet Protocol
- DDoS distributed denial-of-service
- 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.
- 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.
- 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.
- a client 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.
- 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.
- the present invention comprises methods and systems for mitigating against DoS and DDoS attacks, including SSL DoS and DDoS attacks.
- 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.
- clients may be challenged to demonstrate their legitimacy by honoring HTTP redirects, performing SSL resumption operations, storing and transmitting HTTP cookies, etc.
- clients are subjected to multiple challenges in an incremental fashion until a sufficient amount of malicious traffic has been identified.
- a 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.
- 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.
- FIG. 5 is a flow diagram illustrating an exemplary method of validating clients using HTTP cookies, consistent with certain disclosed embodiments.
- FIG. 1 is a diagram illustrating communications between one or more exemplary application servers and one or more clients consistent with certain disclosed embodiments.
- one or more application servers 135 provide services to one or more clients or end users 110 .
- Application servers 135 may comprise commercial web servers that service HTTP requests from clients 110 for web pages hosted by the application servers 135 .
- Clients 110 communicate with application servers 135 through the Internet 120 and using normal Internet communications protocols, such as HTTP, TCP, and IP.
- application servers 135 may operate one or more applications or provide one or more public-facing network services
- application servers 135 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.
- clients 110 communicate directly with application servers 135 via Internet 120 .
- HTTP requests from clients 110 may be encapsulated in TCP segments, IP datagrams, and Ethernet frames and transmitted to servers 135 .
- 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 from clients 110 to application servers 135 .
- ISPs Internet Service Providers
- Application servers 135 may be monitored by one or more monitoring servers 145 .
- Monitoring servers 145 may monitor application servers 135 for the purpose of determining whether application servers 135 are receiving network communications or are functioning in a normal or expected manner or whether application servers 135 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.
- a third-party mitigation service provider 140 may operate monitoring servers 145 , which monitor application servers 135 , pursuant to a commercial mitigation service provided to customer 130 , which may own or operate application servers 135 .
- FIG. 1 depicts monitoring servers 145 as communicating with application servers 135 using a direct communications link or a communications link separate from Internet 120 , those skilled in the art will appreciate that monitoring servers 145 may also communicate with application servers 135 via an indirect network connection, such as a network connection through Internet 120 .
- Monitoring servers 145 may be within the network path between clients 110 and application servers 135 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.
- legitimate clients 210 are making normal requests to application servers 135
- additional clients 220 that are part of a botnet are also making requests to application servers 135 .
- traffic 220 a from malicious clients 220 is depicted as a thick arrow
- traffic 210 a from legitimate clients 210 is depicted as a thin arrow, to illustrate that traffic 220 a may be significantly heavier than traffic 210 a .
- proxy servers 245 may be operated by the same third-party mitigation service provider 140 that operates monitoring servers 145 . Moreover, in certain embodiments the same physical servers may perform the roles of both monitoring servers 145 and proxy servers 245 . Proxy servers 245 may also be within the network path between clients 110 and application servers 135 or may be outside of the path.
- Traffic 120 b may be redirected to proxy servers 245 using a number of different techniques.
- proxy servers 245 may advertise their availability to route communications to the IP addresses associated with application servers 135 or may advertise that they themselves terminate such IP addresses, in a process known as a “BGP swing.”
- BGP swing an inter-Autonomous System routing protocol used by ISPs
- communications intended for application servers 135 such as communications from clients 210 and 220
- proxy servers 245 may terminate at proxy servers 245 such that proxy servers 245 may communicate with clients 210 and 220 on behalf of application servers 135 , typically without detection.
- either application servers 135 or proxy servers 245 may initiate a request to one or more Domain Name Service (“DNS”) servers to reassign domain names hosted by application servers 135 to IP addresses assigned to proxy servers 245 .
- DNS Domain Name Service
- This process of DNS record alteration may additionally be facilitated or expedited if application servers 135 and/or proxy servers 245 , or the entities associated therewith, operate authoritative DNS servers or have other primary or authoritative roles in the DNS system.
- DNS Domain Name Service
- proxy servers such as proxy servers 245
- proxy servers 245 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.
- proxy servers 245 may filter the traffic by categorizing the traffic into communications from legitimate clients and communications from malicious clients, such as DoS participants. All legitimate traffic 245 a may be forwarded to application servers 135 , while other traffic 245 b may be discarded (item 250 ). Alternatively, to avoid denying service to a legitimate client incorrectly identified as malicious, some or all traffic 245 b could be forwarded to application servers 135 or otherwise serviced, for example at a much lower priority than traffic 245 a , a process known as “rate-limiting” (operations not depicted in FIG. 2 .).
- proxy servers 245 may be owned or operated by a third party that provides proxy services as part of a broader DoS mitigation service.
- 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.
- customer 130 may be a small company that does not have the resources to operate separate proxy servers to perform mitigation services.
- 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.
- 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.
- any techniques that focus on challenging the client at the HTTP application layer would be ineffective for mitigating against SSL DDoS attacks.
- SSL DDoS Secure Socket Layer
- 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”).
- DES Data Encryption Standard
- AES Advanced Encryption Standard
- DES Data Encryption Standard
- AES Advanced Encryption Standard
- client and server 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.
- RSA Rivest-Shamir-Adleman
- 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.
- PMS Pre-Master Secret
- the process of encrypting or decrypting data using an asymmetric public or private key is an expensive operation that requires a host system to perform exponentiation over large numbers.
- many servers are configured to limit the number of concurrent SSL sessions that they will allocate to clients.
- 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.
- 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.
- 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.
- 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.
- 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 to FIGS. 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.
- direct communication between application servers 330 , owned or operated by customer 130 , and clients 310 has been disabled.
- Client traffic has been diverted to one or more proxy servers 320 , e.g., owned or operated by third-party service provider 140 , for the purpose of identifying which clients 310 are legitimate and which clients 310 are malicious.
- 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.
- step 310 a client 310 requests an SSL session from proxy server 320 by sending a standard SSL “ClientHello” message.
- 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.
- client 310 and proxy server 320 may have exchanged other messages in order to establish a TCP connection.
- proxy server 320 In response to the “ClientHello” message, proxy server 320 sends a “ServerHello” message to client 310 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 (step 320 a ).
- the proxy server 320 also assigns an SSL session ID to uniquely identify the client 310 during subsequent requests from client 310 and stores that session ID in memory.
- proxy server 320 may exchange a number of additional messages. For example, proxy server 320 may provide client 310 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. Client 310 may then generate a symmetric key, encrypt the symmetric key using the public key provided by proxy server 320 , and transmit the encrypted symmetric key to proxy server 320 for use during subsequent communications. The proxy server 320 in turn decrypts the symmetric key using its private key. This decryption operation in particular may cause proxy server 320 to perform exponentiation and therefore to expend non-trivial resources.
- CA Certificate Authority
- client 310 In the event that mutual authentication is requested, client 310 also provides a copy of its public key and CA-issued certificate, which are verified by proxy server 320 , also requiring an exponentiation operation. These and other operations comprise a process known as an SSL “handshake” 315 a.
- proxy server 320 For proxy server 320 to communicate with client 310 using SSL in a manner that allows proxy server 320 to impersonate application server 330 , proxy server 320 provides client 310 with a copy of one of customer 130 's public keys and the certificate issued to customer 130 vouching for the authenticity of that public key. Otherwise, client 310 may reject any other public key that proxy server 320 may provide as not belonging to customer 130 , the party with whom client 310 is attempting to communicate. However, proxy server 320 will not be able to decrypt communications from client 310 that have been encrypted using customer 130 's public key unless proxy server 320 also has access to customer 130 's private key. Thus, in one aspect of the disclosed invention, proxy server 320 is entrusted with customer 130 's private key in order to communicate on customer 130 's behalf with clients that request secure connections.
- client 310 After the SSL handshake has been completed (step 315 a ) and the necessary keys exchanged between client 310 and proxy server 320 , client 310 will typically make an HTTP request or HTTPS request to proxy server 320 using the secure connection (step 310 b ). If client 310 is merely a participant in an SSL DDoS attack, client 310 may either never complete the SSL handshaking process 315 a or may never actually request any resources from proxy server 320 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.
- proxy server 320 does not need to further challenge client 310 to validate, and any cleaned traffic that is forwarded from proxy server 320 to application server 330 will exclude further traffic from client 310 by definition.
- proxy server 320 Even if client 310 attempts to cause harm by subsequently requesting additional SSL sessions that it doesn't intend to actually use from proxy server 320 , client 310 will not be able to validate itself in order to proceed to application server 330 , and computational burdens caused by client 310 's repeated SSL session requests will be borne by proxy server 320 , thus protecting application server 330 .
- simply filtering out clients 310 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 that proxy server 320 may forward all remaining traffic to application server 330 without performing any further client-challenge or validation operations.
- proxy server 320 may further subject clients 310 that request resources following the SSL handshaking process to one or more client-challenge mechanisms.
- proxy server 320 may challenge client 310 to validate, since legitimate and malicious clients alike might make application-layer requests after successfully establishing an SSL session.
- FIG. 3 depicts the operations of an exemplary client-challenge mechanism that proxy server 320 may employ—in particular, challenging client 310 to follow through with one or more HTTP redirects.
- client 310 makes an HTTP request to proxy server 320 for a URL resource 311 b (step 310 b ).
- proxy server 320 may send an HTTP redirect message to client 310 (step 320 b ), for example using a “ 301 ” or “ 302 ” HTTP response status code.
- the HTTP redirect message 320 b may instruct client 310 to make an HTTP request to URL 321 b , which proxy server 320 has generated by hashing the client's IP address with, e.g., a secret string of characters known only to proxy server 320 .
- Proxy server 320 may also set a time limit for client 310 to execute the redirect (operations not depicted). If client 310 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 the same URL 321 b in the form of a “replay attack.”
- proxy server 320 may assume that client 310 is malicious—e.g., a “dumb” attack script—if client 310 does not make an HTTP request to proxy server 320 for URL 321 b within the established time limit. Accordingly, proxy server 320 may blacklist client 310 's IP address so that all subsequent requests or communications from client 310 are either ignored or rate-limited.
- client 310 is malicious—e.g., a “dumb” attack script—if client 310 does not make an HTTP request to proxy server 320 for URL 321 b within the established time limit. Accordingly, proxy server 320 may blacklist client 310 's IP address so that all subsequent requests or communications from client 310 are either ignored or rate-limited.
- proxy server 320 may simply whitelist the IP addresses of any clients that successfully follow the redirect. If client 310 honors the redirect, then, in step 310 c , client 310 will make an HTTP request to proxy server 320 for the resource associated with hashed URL 321 b .
- proxy server 320 may hash the IP address of the client that made the request (client 310 ) together with the secret string of characters.
- proxy server 320 will know that client 310 has honored a challenge redirect provided by proxy server 320 , since client 310 would not have been able to guess the appropriate URL 321 b to request in step 310 c (not having access to the secret string of characters). Accordingly, proxy server 320 may whitelist client 310 's IP address (step 320 c ) and/or SSL session ID on the assumption that client 310 is a legitimate client and not a “dumb” attack script, and all future requests from client 310 will be forwarded to application server 330 .
- HTTP request 310 c could be linked to the client that made HTTP request 310 b , such as creating a simple lookup table on proxy server 320 mapping client 310 's IP address or SSL session ID to a random URL 321 b.
- proxy server 320 may also close the SSL connection (e.g., by sending an SSL “close_notify” message) and the TCP connection with client 310 (step 320 e ). By closing the SSL connection, client 310 may be forced to establish a new SSL connection by sending a new “ClientHello” message to proxy server 320 (step 310 d ).
- proxy server 320 receives the “ClientHello” message, it will recognize the IP address in the message as a whitelisted IP address (step 3200 and forward the message to application server 330 (step 320 g ).
- application server 330 Since application server 330 will not recognize client 310 at this point, application server 330 will likely require client 310 to perform a new, full SSL handshake in which new keys may be exchanged and used for secure communication between application server 330 and client 310 (operations not depicted). Thereafter, all communications between application server 330 and client 310 may pass through proxy server 320 without the need for further validation (step 330 a ).
- NAT Network Address Translation
- 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.
- NAT-enabled router 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.
- proxy server 320 may risk erroneously blacklisting other, legitimate clients if client 310 is operating from behind a NAT, since other, legitimate clients may share that same IP address.
- proxy server 320 simply whitelists the IP address of clients that successfully honors a redirect, then proxy server 320 risks a situation in which malicious clients may be able to communicate with application server 330 simply because they share an IP address with a legitimate client that may have previously validated that IP address.
- 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.
- the HTTP redirect client-challenge mechanism may reduce the amount of traffic directed at application server 330 to a sufficient threshold, even if some malicious clients may still be able to access application server 330 . And, if the HTTP redirect client-challenge mechanism does not reduce the traffic to a sufficient threshold, proxy server 320 may apply one or more additional client-challenge mechanisms, such as the mechanisms described with respect to FIGS. 4 and 5 , in an incremental fashion until a workable threshold is achieved.
- proxy server 320 may require HTTP client 310 to request redirect URL 321 b and, after receiving such a request, whitelist the client IP address and redirect the client to request to the originally requested URL for application server 330 .
- FIG. 4 is a flow diagram illustrating an exemplary method of validating clients using SSL resumption, consistent with certain disclosed embodiments.
- 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.
- 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.
- 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.
- 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”).
- SSL ID an SSL session ID assigned to the client and transmits it to the client as part of the server's “ServerHello” message.
- steps 410 a and 420 a depicted in steps 410 a and 420 a , in which client 410 requests a new SSL session by transmitting a “ClientHello” message to proxy server 420 (step 410 a ), and proxy server 420 responds with a “ServerHello” message that includes an SSL session ID 421 a (step 420 a ).
- steps 410 a and 420 a may be the same as steps 310 a and 320 a . If client 410 is responsive to the “ServerHello” message of step 420 a , client 410 and proxy server 420 may complete the full SSL handshake process as in step 315 a of FIG. 3 .
- Proxy server 420 may respond to an HTTP request for a URL 411 b (step 410 b ) with an HTTP redirect to a hashed URL 421 b in order to validate client 410 (step 420 b ). If client 410 follows through with the redirect by requesting hashed URL 421 b (step 410 c ), proxy server 420 may whitelist client 410 (step 420 c ). In some embodiments, rather than whitelisting client 410 's IP address, which might obscure the existence of multiple distinct clients behind a NAT, proxy server 420 may whitelist the SSL session ID 421 a , either alone or in combination with client 410 's IP address. SSL session ID 421 a may be sufficient to identify client 410 , even if there are other clients that share the same IP address.
- proxy server 420 redirects client 410 back to the original URL 411 b that client 410 requested in step 410 b (step 420 d ).
- proxy server 420 closes the SSL connection (e.g., by sending an SSL “close_notify” message) and its TCP connection with client 410 (step 420 e ).
- proxy server 420 may take care not to close the SSL session.
- client 410 will not be able to immediately request URL 411 b from proxy server 420 , but instead client 410 will need to first establish a new SSL connection, which will require client 410 to initiate an SSL handshake by transmitting another “ClientHello” message (step 410 d ).
- proxy server 420 may verify that it previously whitelisted the SSL session ID and/or SSL session ID/IP address combination (step 4200 and therefore assume that client 410 is legitimate.
- client 410 may appear no different from any other client that requests a new SSL session in step 410 a , and will therefore be required to perform the same challenge steps it had previously performed (e.g., steps 410 b , 420 b , 410 c , 402 d , etc.), potentially in an infinite-loop fashion. As such, client 410 may never reach application server 430 , effectively being blacklisted by virtue of being repeatedly challenged by proxy server 420 .
- proxy server 420 may forward client 410 's SSL connection request, including the SSL session ID 421 a to application server 430 (step 420 g ).
- application server 430 may not recognize SSL session ID 421 a . Accordingly, application server 430 may require client 410 to perform a new, full SSL handshake by generating a new SSL session ID 431 a and transmitting the new ID to client 410 as part of application server 430 's “ServerHello” message (step 430 a ).
- proxy server 420 may receive application server 430 's “ServerHello” message (containing the new SSL session ID 431 a ) and relay it to client 410 (step 420 i ). Thereafter, application server 430 and client 410 may communicate in a secured manner using proxy server 420 as an intermediary (step 430 b )
- proxy server 420 may also inspect the message packet to note the new SSL session ID 431 a that application server 430 has assigned to client 410 and to whitelist that session ID (step 420 h ). Proxy server 420 may whitelist the new SSL session ID 431 a so that when client 410 makes future requests to application server 430 through proxy server 420 containing the new SSL session ID 431 a , rather than the previously whitelisted SSL session ID 421 a , proxy server 420 may be able to recognize client 410 as a whitelisted client and forward client 410 's communications to application server 430 . Otherwise, proxy server 420 may not recognize the new SSL session ID 431 a , and may require client 410 to validate again.
- proxy server 420 may then communicate securely through proxy server 420 without allowing proxy server 420 to decrypt their communications (step 430 b ).
- the entity that owns or operates proxy server 420 may be a third-party service provider, e.g., service provider 140 , that should not have access to encrypted communications between application server 430 and client 410 beyond the process of initially validating client 410 .
- proxy server 420 may already have a copy of application server 430 's private key, secure communication between application server 430 and client 410 may be achieved in a number of ways.
- proxy server 420 may ignore the contents of communications between application server 430 and client 410 during the SSL handshaking process between the devices (other than to detect the SSL session ID needed to determine whether client 410 had been whitelisted).
- application server 430 and client 410 may have agreed upon a set of symmetric keys for encrypting communications between them.
- proxy server 420 By ignoring the contents of this handshaking process, proxy server 420 would not know which symmetric keys are being used in the SSL session and therefore would not be able to decrypt communications between application server 430 and client 410 despite having a copy of application server 430 's private key.
- application server 430 may maintain a second private key that it does not share with proxy server 420 .
- application server 430 could perform a full SSL handshake by sending client 410 a copy of a second public key (corresponding to application server 430 's second private key), along with a valid certificate for the second public key, which could be used to securely exchange symmetric keys with client 410 .
- proxy server 420 does not have a copy of application server 430 's second private key, proxy server 420 will not be able to decrypt SSL handshaking communications from application server 430 . This is especially the case if application server 430 imposes a mutual authentication requirement on the handshake (requiring the client to authenticate using its public key and certificate), which may prevent proxy server 420 from engaging in a “man-in-the-middle” attack.
- proxy server 420 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 server 420 may apply additional client-challenge mechanisms, such as the mechanism described with respect to FIG. 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.
- proxy server 520 When client 510 requests a new SSL session by transmitting a “ClientHello” message to proxy server 520 (step 510 a ), proxy server 520 responds with a “ServerHello” message that includes an SSL session ID 521 a .
- client 510 and proxy server 520 may complete the full SSL handshake process, e.g., in a manner similar to that described with respect to step 315 a of FIG. 3 .
- Proxy server 520 may respond to an HTTP request for a URL 511 b (step 510 b ) with an HTTP redirect to a hashed URL 521 b (step 520 b ).
- proxy server 520 may also include an HTTP cookie in its response (step 520 b ).
- proxy server 520 redirects client 510 to a URL 521 b within a randomly generated path 522 b .
- Proxy server 520 may also include an HTTP cookie 523 b in the response containing a random value and a path attribute corresponding to path 522 b .
- the path attribute specifies that client 510 is to return cookie 523 b to proxy server 520 , but only if client 510 makes an HTTP request for a resource within path 522 b .
- Cookie 523 b may also include other attributes, such as “domain,” “expires,” and “secure.”
- proxy server 520 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. If proxy server 520 receives the HTTP request for URL 521 b from client 510 , along with the appropriate cookie 523 b corresponding to the path 522 b of URL 521 b and client 510 's IP address, then proxy server may whitelist client 510 using its IP address and SSL session ID (step 520 c ).
- proxy server 520 may manage communication between client 510 and application server 530 following steps 520 d , 520 e , 510 d , 520 f , 520 g , 530 a , 520 h , 520 i , and 530 b , as shown. In some embodiments, these steps may be analogous to steps 420 d , 420 e , 410 d , 420 f , 420 g , 430 a , 420 h , 420 i , and 430 b .
- proxy server 520 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 by proxy server 520 .
- proxy server 520 may enable client 510 to communicate with application server 530 by continuing to operate in the role of a proxy server. For example, communications from client 510 to application server 530 may terminate at proxy server 520 ; proxy server 520 may copy the communication; and proxy server 520 may send a copy of the communication to application server 530 . Proxy server 520 may operate similarly with respect to communications from application server 530 directed to client 510 .
- proxy server 520 may allow communications from client 510 to “transparently” pass through proxy server 520 by modifying IP datagrams transmitted by proxy server 520 to application server 530 to indicate client 510 's IP address in the “Source Address” field of the datagram rather than proxy server 520 's IP address.
- Proxy server 520 could accomplish this modification using, for instance, the “Netfilter” or “IP sets” framework of the Linux kernel.
- proxy server 520 could provide application server 530 with information about requesting client 510 by including client information, such as client 510 's IP address, in one or more HTTP headers transmitted to application server 530 .
- proxy server 520 could transition to operating in the mode of a traditional router or link-layer switch by simply forwarding any packets received from client 510 to application server 530 without demultiplexing higher layers of the Internet protocol stack.
- application server 530 could be apprised of which clients are requesting resources from application server 530 and could keep records to individually track malicious users or compile information that may be useful for marketing or other analysis.
- proxy servers 245 may initiate a process of redirecting traffic back to application servers 135 .
- proxy servers 245 could advertise a BGP “swing” back to application servers 135 in order to remove themselves from the routing path.
- proxy servers 245 could request a reversal of any previous DNS record alteration to reassign one or more domain names hosted by application servers 135 back to IP addresses associated with application servers 135 .
- proxy servers 245 may have used of customer 130 's private key to validate SSL traffic during the mitigation event, proxy servers 245 could attempt to restore security to application servers 135 by, for example, permanently deleting the private key (and any copies of the key) or sending a reminder to customer 130 to revoke the certificate associated with its corresponding public key. Thereafter, proxy servers 245 or monitoring servers 145 may return to monitoring application servers 135 to detect any subsequent DoS attacks and, if necessary, to undertake corrective action, such as the above-described mitigation operations.
- proxy servers 245 may validate SSL traffic directed at application servers 135 without using or obtaining access to customer 130 's private key. For example, clients requesting HTTPS access to application servers 135 may be required by proxy servers 245 to using a challenge mechanism, such as the above-described HTTP redirect or HTTP cookie client-challenge mechanisms, that may be implemented over HTTP.
- proxy servers 245 validate a client over HTTP, the validated client is allowed to access application servers 135 using HTTPS (e.g., using HTTPS port 443 ).
- Validated clients may be whitelisted using their IP addresses or IP addresses in combination with other information. To protect against potential misuse of port 443 by the whitelisted clients, proxy servers 245 may limit the number of connections to port 443 that whitelisted clients may have open at any given time.
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
- 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.
- 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.
- 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.
- 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. - 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 servers 135 provide services to one or more clients orend users 110.Application servers 135 may comprise commercial web servers that service HTTP requests fromclients 110 for web pages hosted by theapplication servers 135.Clients 110 communicate withapplication servers 135 through the Internet 120 and using normal Internet communications protocols, such as HTTP, TCP, and IP. Althoughapplication servers 135 may operate one or more applications or provide one or more public-facing network services,application servers 135 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 of
FIG. 1 ,clients 110 communicate directly withapplication servers 135 viaInternet 120. For example, HTTP requests fromclients 110 may be encapsulated in TCP segments, IP datagrams, and Ethernet frames and transmitted toservers 135. 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 fromclients 110 toapplication servers 135. -
Application servers 135, or routers providing Internet connectivity toapplication servers 135, may be monitored by one ormore monitoring servers 145.Monitoring servers 145 may monitorapplication servers 135 for the purpose of determining whetherapplication servers 135 are receiving network communications or are functioning in a normal or expected manner or whetherapplication servers 135 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-party
mitigation service provider 140 may operatemonitoring servers 145, which monitorapplication servers 135, pursuant to a commercial mitigation service provided tocustomer 130, which may own or operateapplication servers 135. AlthoughFIG. 1 depictsmonitoring servers 145 as communicating withapplication servers 135 using a direct communications link or a communications link separate fromInternet 120, those skilled in the art will appreciate that monitoringservers 145 may also communicate withapplication servers 135 via an indirect network connection, such as a network connection throughInternet 120.Monitoring servers 145 may be within the network path betweenclients 110 andapplication servers 135 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 clients 210 are making normal requests toapplication servers 135,additional clients 220 that are part of a botnet are also making requests toapplication servers 135. InFIG. 2 ,traffic 220 a frommalicious clients 220 is depicted as a thick arrow, whereastraffic 210 a fromlegitimate clients 210 is depicted as a thin arrow, to illustrate thattraffic 220 a may be significantly heavier thantraffic 210 a. Once a DoS attack onapplication servers 130 is detected, alltraffic 120 b toapplication servers 135 may be diverted toproxy servers 245, such that clients may no longer be able to establish adirect connection 120 a withapplication servers 135 viaInternet 120. In some embodiments,proxy servers 245 may be operated by the same third-partymitigation service provider 140 that operatesmonitoring servers 145. Moreover, in certain embodiments the same physical servers may perform the roles of both monitoringservers 145 andproxy servers 245.Proxy servers 245 may also be within the network path betweenclients 110 andapplication servers 135 or may be outside of the path. -
Traffic 120 b may be redirected toproxy servers 245 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 servers 245 may advertise their availability to route communications to the IP addresses associated withapplication servers 135 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 servers 135, such as communications fromclients proxy servers 245 such thatproxy servers 245 may communicate withclients application servers 135, typically without detection. - Alternatively, either
application servers 135 orproxy servers 245 may initiate a request to one or more Domain Name Service (“DNS”) servers to reassign domain names hosted byapplication servers 135 to IP addresses assigned toproxy servers 245. This process of DNS record alteration may additionally be facilitated or expedited ifapplication servers 135 and/orproxy servers 245, 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 servers 135 toproxy servers 245. 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 servers 245, 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. - Once
traffic 120 b has been diverted toproxy servers 245,proxy servers 245 may filter the traffic by categorizing the traffic into communications from legitimate clients and communications from malicious clients, such as DoS participants. Alllegitimate traffic 245 a may be forwarded toapplication servers 135, whileother traffic 245 b may be discarded (item 250). Alternatively, to avoid denying service to a legitimate client incorrectly identified as malicious, some or alltraffic 245 b could be forwarded toapplication servers 135 or otherwise serviced, for example at a much lower priority thantraffic 245 a, a process known as “rate-limiting” (operations not depicted inFIG. 2 .). - In one embodiment,
proxy servers 245 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,customer 130 may be a small company that does not have the resources to operate separate proxy servers to perform mitigation services. Or, even ifcustomer 130 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 to
FIGS. 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 servers 330, owned or operated bycustomer 130, andclients 310 has been disabled. Client traffic has been diverted to one or moreproxy servers 320, e.g., owned or operated by third-party service provider 140, for the purpose of identifying whichclients 310 are legitimate and whichclients 310 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. - In
step 310 a,client 310 requests an SSL session fromproxy server 320 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,client 310 andproxy server 320 may have exchanged other messages in order to establish a TCP connection. - In response to the “ClientHello” message,
proxy server 320 sends a “ServerHello” message toclient 310 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 (step 320 a). Theproxy server 320 also assigns an SSL session ID to uniquely identify theclient 310 during subsequent requests fromclient 310 and stores that session ID in memory. - Before the SSL session is established,
client 310 andproxy server 320 may exchange a number of additional messages. For example,proxy server 320 may provideclient 310 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.Client 310 may then generate a symmetric key, encrypt the symmetric key using the public key provided byproxy server 320, and transmit the encrypted symmetric key toproxy server 320 for use during subsequent communications. Theproxy server 320 in turn decrypts the symmetric key using its private key. This decryption operation in particular may causeproxy server 320 to perform exponentiation and therefore to expend non-trivial resources. In the event that mutual authentication is requested,client 310 also provides a copy of its public key and CA-issued certificate, which are verified byproxy server 320, also requiring an exponentiation operation. These and other operations comprise a process known as an SSL “handshake” 315 a. - For
proxy server 320 to communicate withclient 310 using SSL in a manner that allowsproxy server 320 to impersonateapplication server 330,proxy server 320 providesclient 310 with a copy of one ofcustomer 130's public keys and the certificate issued tocustomer 130 vouching for the authenticity of that public key. Otherwise,client 310 may reject any other public key thatproxy server 320 may provide as not belonging tocustomer 130, the party with whomclient 310 is attempting to communicate. However,proxy server 320 will not be able to decrypt communications fromclient 310 that have been encrypted usingcustomer 130's public key unlessproxy server 320 also has access tocustomer 130's private key. Thus, in one aspect of the disclosed invention,proxy server 320 is entrusted withcustomer 130's private key in order to communicate oncustomer 130's behalf with clients that request secure connections. - After the SSL handshake has been completed (step 315 a) and the necessary keys exchanged between
client 310 andproxy server 320,client 310 will typically make an HTTP request or HTTPS request toproxy server 320 using the secure connection (step 310 b). Ifclient 310 is merely a participant in an SSL DDoS attack,client 310 may either never complete theSSL handshaking process 315 a or may never actually request any resources fromproxy server 320 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, if
client 310 fails to take action after the successful creation of an SSL session, this failure only makes it easier forproxy server 320 to filter out malicious traffic. In particular, sinceclient 310 never requests any actual resources fromproxy server 320 beyond an SSL session,proxy server 320 does not need to furtherchallenge client 310 to validate, and any cleaned traffic that is forwarded fromproxy server 320 toapplication server 330 will exclude further traffic fromclient 310 by definition. Moreover, even ifclient 310 attempts to cause harm by subsequently requesting additional SSL sessions that it doesn't intend to actually use fromproxy server 320,client 310 will not be able to validate itself in order to proceed toapplication server 330, and computational burdens caused byclient 310's repeated SSL session requests will be borne byproxy server 320, thus protectingapplication server 330. - In one embodiment, simply filtering out
clients 310 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 server 320 may forward all remaining traffic toapplication server 330 without performing any further client-challenge or validation operations. Alternatively, if the remaining traffic is still outside the bounds of whatapplication server 330 would expect to receive under in the absence of a DoS attack, thenproxy server 320 may furthersubject clients 310 that request resources following the SSL handshaking process to one or more client-challenge mechanisms. - If
client 310 attempts to request a resource fromproxy server 320 following the SSL handshaking process, thenproxy server 320 may challengeclient 310 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 server 320 may employ—in particular,challenging client 310 to follow through with one or more HTTP redirects. - In one embodiment,
client 310 makes an HTTP request toproxy server 320 for aURL resource 311 b (step 310 b). However, rather than providing the resource associated withURL 311 b to client 310 (whichproxy server 320 may not even have, since its primary role may be only to perform validation and filtering services),proxy server 320 may send an HTTP redirect message to client 310 (step 320 b), for example using a “301” or “302” HTTP response status code. TheHTTP redirect message 320 b may instructclient 310 to make an HTTP request toURL 321 b, whichproxy server 320 has generated by hashing the client's IP address with, e.g., a secret string of characters known only toproxy server 320.Proxy server 320 may also set a time limit forclient 310 to execute the redirect (operations not depicted). Ifclient 310 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 URL 321 b in the form of a “replay attack.” - Since many standard clients are configured to follow through with HTTP redirects as a matter of course,
proxy server 320 may assume thatclient 310 is malicious—e.g., a “dumb” attack script—ifclient 310 does not make an HTTP request toproxy server 320 forURL 321 b within the established time limit. Accordingly,proxy server 320 may blacklistclient 310's IP address so that all subsequent requests or communications fromclient 310 are either ignored or rate-limited. - Alternatively,
proxy server 320 may simply whitelist the IP addresses of any clients that successfully follow the redirect. Ifclient 310 honors the redirect, then, instep 310 c,client 310 will make an HTTP request toproxy server 320 for the resource associated with hashedURL 321 b. Whenproxy server 320 receives theHTTP request 310 c,proxy server 320 may hash the IP address of the client that made the request (client 310) together with the secret string of characters. If the resulting string matches theURL 321 b requested instep 310 c, thenproxy server 320 will know thatclient 310 has honored a challenge redirect provided byproxy server 320, sinceclient 310 would not have been able to guess theappropriate URL 321 b to request instep 310 c (not having access to the secret string of characters). Accordingly,proxy server 320 may whitelistclient 310's IP address (step 320 c) and/or SSL session ID on the assumption thatclient 310 is a legitimate client and not a “dumb” attack script, and all future requests fromclient 310 will be forwarded toapplication server 330. Those skilled in the art will appreciate other ways in which the client that madeHTTP request 310 c could be linked to the client that madeHTTP request 310 b, such as creating a simple lookup table onproxy server 320mapping client 310's IP address or SSL session ID to arandom URL 321 b. - At this point, although
client 310 may have been whitelisted, it has still not yet received the original resource that it requested instep 310 b. Therefore, instep 320 d,proxy server 320 once again redirectsclient 310, this time to theoriginal URL 311 b requested byclient 310 instep 310 b. In addition, in order to facilitate secure communication betweenclient 310 andapplication server 330,proxy server 320 may also close the SSL connection (e.g., by sending an SSL “close_notify” message) and the TCP connection with client 310 (step 320 e). By closing the SSL connection,client 310 may be forced to establish a new SSL connection by sending a new “ClientHello” message to proxy server 320 (step 310 d). Whenproxy server 320 receives the “ClientHello” message, it will recognize the IP address in the message as a whitelisted IP address (step 3200 and forward the message to application server 330 (step 320 g). - Since
application server 330 will not recognizeclient 310 at this point,application server 330 will likely requireclient 310 to perform a new, full SSL handshake in which new keys may be exchanged and used for secure communication betweenapplication server 330 and client 310 (operations not depicted). Thereafter, all communications betweenapplication server 330 andclient 310 may pass throughproxy server 320 without the need for further validation (step 330 a). - 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, if
client 310 fails to honor a redirect andproxy server 320 responds by blacklistingclient 310's IP address, thenproxy server 320 may risk erroneously blacklisting other, legitimate clients ifclient 310 is operating from behind a NAT, since other, legitimate clients may share that same IP address. Likewise, ifproxy server 320 simply whitelists the IP address of clients that successfully honors a redirect, thenproxy server 320 risks a situation in which malicious clients may be able to communicate withapplication server 330 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 at
application server 330 to a sufficient threshold, even if some malicious clients may still be able to accessapplication server 330. And, if the HTTP redirect client-challenge mechanism does not reduce the traffic to a sufficient threshold,proxy server 320 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 of
FIG. 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 server 320 may requireHTTP client 310 to requestredirect URL 321 b and, after receiving such a request, whitelist the client IP address and redirect the client to request to the originally requested URL forapplication server 330. -
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. In
FIG. 4 , these operations are depicted insteps client 410 requests a new SSL session by transmitting a “ClientHello” message to proxy server 420 (step 410 a), andproxy server 420 responds with a “ServerHello” message that includes anSSL session ID 421 a (step 420 a). In someembodiments steps steps client 410 is responsive to the “ServerHello” message ofstep 420 a,client 410 andproxy server 420 may complete the full SSL handshake process as instep 315 a ofFIG. 3 . -
Proxy server 420 may respond to an HTTP request for aURL 411 b (step 410 b) with an HTTP redirect to a hashedURL 421 b in order to validate client 410 (step 420 b). Ifclient 410 follows through with the redirect by requesting hashedURL 421 b (step 410 c),proxy server 420 may whitelist client 410 (step 420 c). In some embodiments, rather than whitelistingclient 410's IP address, which might obscure the existence of multiple distinct clients behind a NAT,proxy server 420 may whitelist theSSL session ID 421 a, either alone or in combination withclient 410's IP address.SSL session ID 421 a may be sufficient to identifyclient 410, even if there are other clients that share the same IP address. - Since
client 410 has now been whitelisted,proxy server 420 redirectsclient 410 back to theoriginal URL 411 b thatclient 410 requested instep 410 b (step 420 d). In addition,proxy server 420 closes the SSL connection (e.g., by sending an SSL “close_notify” message) and its TCP connection with client 410 (step 420 e). Notably, when closing the SSL connection,proxy server 420 may take care not to close the SSL session. In this embodiment,client 410 will not be able to immediately requestURL 411 b fromproxy server 420, but insteadclient 410 will need to first establish a new SSL connection, which will requireclient 410 to initiate an SSL handshake by transmitting another “ClientHello” message (step 410 d). - At this point, a legitimate client would be most likely to request resumption of the SSL session it had established with
proxy server 420 moments prior. Thus, ifclient 410 is legitimate, it will likely includeSSL session ID 421 a in its “ClientHello” message instep 410 d. Onceproxy server 420 receivesSSL session ID 421 a fromclient 410,proxy server 420 may verify that it previously whitelisted the SSL session ID and/or SSL session ID/IP address combination (step 4200 and therefore assume thatclient 410 is legitimate. - If, however,
client 410 does not request SSL session resumption by transmittingSSL session ID 421 a in its “ClientHello” message, thenclient 410 may appear no different from any other client that requests a new SSL session instep 410 a, and will therefore be required to perform the same challenge steps it had previously performed (e.g., steps 410 b, 420 b, 410 c, 402 d, etc.), potentially in an infinite-loop fashion. As such,client 410 may never reachapplication server 430, effectively being blacklisted by virtue of being repeatedly challenged byproxy server 420. - Returning to the case when
client 410 does request SSL session resumption,proxy server 420 may forwardclient 410's SSL connection request, including theSSL session ID 421 a to application server 430 (step 420 g). However, sinceapplication server 430 may not have established any previous SSL session withclient 410,application server 430 may not recognizeSSL session ID 421 a. Accordingly,application server 430 may requireclient 410 to perform a new, full SSL handshake by generating a newSSL session ID 431 a and transmitting the new ID toclient 410 as part ofapplication server 430's “ServerHello” message (step 430 a). Because communications betweenapplication server 430 andclient 410 are still being routed throughproxy server 420,proxy server 420 may receiveapplication server 430's “ServerHello” message (containing the newSSL session ID 431 a) and relay it to client 410 (step 420 i). Thereafter,application server 430 andclient 410 may communicate in a secured manner usingproxy server 420 as an intermediary (step 430 b) - In addition to relaying
application server 430's “ServerHello” message,proxy server 420 may also inspect the message packet to note the newSSL session ID 431 a thatapplication server 430 has assigned toclient 410 and to whitelist that session ID (step 420 h).Proxy server 420 may whitelist the newSSL session ID 431 a so that whenclient 410 makes future requests toapplication server 430 throughproxy server 420 containing the newSSL session ID 431 a, rather than the previously whitelistedSSL session ID 421 a,proxy server 420 may be able to recognizeclient 410 as a whitelisted client andforward client 410's communications toapplication server 430. Otherwise,proxy server 420 may not recognize the newSSL session ID 431 a, and may requireclient 410 to validate again. - In one aspect of the invention, after
application server 430 andclient 410 have successfully established an SSL session andproxy server 420 has whitelisted the new session ID associated with that session,client 410 andapplication server 430 may then communicate securely throughproxy server 420 without allowingproxy server 420 to decrypt their communications (step 430 b). For example, the entity that owns or operatesproxy server 420 may be a third-party service provider, e.g.,service provider 140, that should not have access to encrypted communications betweenapplication server 430 andclient 410 beyond the process of initially validatingclient 410. - Since
proxy server 420 may already have a copy ofapplication server 430's private key, secure communication betweenapplication server 430 andclient 410 may be achieved in a number of ways. In one embodiment,proxy server 420 may ignore the contents of communications betweenapplication server 430 andclient 410 during the SSL handshaking process between the devices (other than to detect the SSL session ID needed to determine whetherclient 410 had been whitelisted). Once the SSL handshaking process betweenapplication server 430 andclient 410 is complete,application server 430 andclient 410 may have agreed upon a set of symmetric keys for encrypting communications between them. By ignoring the contents of this handshaking process,proxy server 420 would not know which symmetric keys are being used in the SSL session and therefore would not be able to decrypt communications betweenapplication server 430 andclient 410 despite having a copy ofapplication server 430's private key. - In another embodiment,
application server 430 may maintain a second private key that it does not share withproxy server 420. Afterclient 410 has been validated byproxy server 420,application server 430 could perform a full SSL handshake by sendingclient 410 a copy of a second public key (corresponding toapplication server 430's second private key), along with a valid certificate for the second public key, which could be used to securely exchange symmetric keys withclient 410. Becauseproxy server 420 does not have a copy ofapplication server 430's second private key,proxy server 420 will not be able to decrypt SSL handshaking communications fromapplication server 430. This is especially the case ifapplication server 430 imposes a mutual authentication requirement on the handshake (requiring the client to authenticate using its public key and certificate), which may preventproxy server 420 from engaging in a “man-in-the-middle” attack. - After subjecting clients to an SSL session resumption client-challenge mechanism,
proxy server 420 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 server 420 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. Whenclient 510 requests a new SSL session by transmitting a “ClientHello” message to proxy server 520 (step 510 a),proxy server 520 responds with a “ServerHello” message that includes anSSL session ID 521 a. Provided thatclient 510 is responsive to the “ServerHello” message ofstep 520 a,client 510 andproxy server 520 may complete the full SSL handshake process, e.g., in a manner similar to that described with respect to step 315 a ofFIG. 3 . -
Proxy server 520 may respond to an HTTP request for aURL 511 b (step 510 b) with an HTTP redirect to a hashedURL 521 b (step 520 b). In the embodiment ofFIG. 5 ,proxy server 520 may also include an HTTP cookie in its response (step 520 b). In one embodiment,proxy server 520 redirectsclient 510 to aURL 521 b within a randomly generatedpath 522 b.Proxy server 520 may also include anHTTP cookie 523 b in the response containing a random value and a path attribute corresponding topath 522 b. The path attribute specifies thatclient 510 is to returncookie 523 b toproxy server 520, but only ifclient 510 makes an HTTP request for a resource withinpath 522 b.Cookie 523 b may also include other attributes, such as “domain,” “expires,” and “secure.” - In order for
client 510 to validate,client 510 must not only honor the redirect by requestingURL 521 b, but must also includeHTTP cookie 523 b in the request by matching the path ofURL 521 b with the path attribute ofHTTP cookie 523 b (step 510 c).Proxy server 520 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 server 520 receives the HTTP request forURL 521 b fromclient 510, along with theappropriate cookie 523 b corresponding to thepath 522 b ofURL 521 b andclient 510's IP address, then proxy server may whitelistclient 510 using its IP address and SSL session ID (step 520 c). - Thereafter,
proxy server 520 may manage communication betweenclient 510 andapplication server 530 followingsteps steps proxy server 520 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 server 520. - 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 in
steps FIG. 5 as an example, onceclient 510 has been validated,proxy server 520 may enableclient 510 to communicate withapplication server 530 by continuing to operate in the role of a proxy server. For example, communications fromclient 510 toapplication server 530 may terminate atproxy server 520;proxy server 520 may copy the communication; andproxy server 520 may send a copy of the communication toapplication server 530.Proxy server 520 may operate similarly with respect to communications fromapplication server 530 directed toclient 510. - In this example, communications from
proxy server 520 toapplication server 530 would indicateproxy server 520's IP address in the “Source Address” field of the IP datagram. As such,application server 530 may not be able to determine which clients are making requests to it, since arriving requests would appear to come fromproxy server 520. To overcome this limitation,proxy server 520 may allow communications fromclient 510 to “transparently” pass throughproxy server 520 by modifying IP datagrams transmitted byproxy server 520 toapplication server 530 to indicateclient 510's IP address in the “Source Address” field of the datagram rather thanproxy server 520's IP address.Proxy server 520 could accomplish this modification using, for instance, the “Netfilter” or “IP sets” framework of the Linux kernel. - Alternatively,
proxy server 520 could provideapplication server 530 with information about requestingclient 510 by including client information, such asclient 510's IP address, in one or more HTTP headers transmitted toapplication server 530. In yet another embodiment,proxy server 520 could transition to operating in the mode of a traditional router or link-layer switch by simply forwarding any packets received fromclient 510 toapplication server 530 without demultiplexing higher layers of the Internet protocol stack. Under these approaches,application server 530 could be apprised of which clients are requesting resources fromapplication server 530 and could keep records to individually track malicious users or compile information that may be useful for marketing or other analysis. - Returning to
FIG. 2 , onceproxy servers 245 determine that the DoS attack has subsided or that traffic directed toapplication servers 135 has returned to acceptable levels,proxy servers 245, or other servers associated withservice provider 140, may initiate a process of redirecting traffic back toapplication servers 135. Thus, for example,proxy servers 245 could advertise a BGP “swing” back toapplication servers 135 in order to remove themselves from the routing path. Alternatively,proxy servers 245 could request a reversal of any previous DNS record alteration to reassign one or more domain names hosted byapplication servers 135 back to IP addresses associated withapplication servers 135. - Because
proxy servers 245 may have used ofcustomer 130's private key to validate SSL traffic during the mitigation event,proxy servers 245 could attempt to restore security toapplication servers 135 by, for example, permanently deleting the private key (and any copies of the key) or sending a reminder tocustomer 130 to revoke the certificate associated with its corresponding public key. Thereafter,proxy servers 245 ormonitoring servers 145 may return tomonitoring application servers 135 to detect any subsequent DoS attacks and, if necessary, to undertake corrective action, such as the above-described mitigation operations. - In some embodiments,
proxy servers 245 may validate SSL traffic directed atapplication servers 135 without using or obtaining access tocustomer 130's private key. For example, clients requesting HTTPS access toapplication servers 135 may be required byproxy servers 245 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 servers 245 validate a client over HTTP, the validated client is allowed to accessapplication servers 135 using HTTPS (e.g., using HTTPS port 443). Validated clients may be whitelisted using their IP addresses or IP addresses in combination with other information. To protect against potential misuse of port 443 by the whitelisted clients,proxy servers 245 may limit the number of connections to port 443 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 of claim 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 of claim 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 of claim 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 of claim 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 of claim 1 , wherein the DoS attack comprises an SSL DoS attack.
7. The method of claim 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 of claim 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 of claim 1 , wherein the first server system and the second server system are owned by different entities.
10. The method of claim 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 of claim 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 of claim 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 of claim 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 of claim 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 of claim 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 of claim 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 of claim 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 of claim 1 , wherein identifying one or more non-suspect clients further comprises:
whitelisting clients that successfully complete one or more challenge mechanisms.
19. The method of claim 18 , further comprising:
whitelisting clients that successfully complete one or more challenge mechanisms using at least the successful clients' IP addresses.
20. The method of claim 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 of claim 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 of claim 1 , wherein identifying one or more suspect clients further comprises:
blacklisting clients that fail to complete one or more challenge mechanisms.
23. The method of claim 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 of claim 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 of claim 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 of claim 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 of claim 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 of claim 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 of claim 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 of claim 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 of claim 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 of claim 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 of claim 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 of claim 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 of claim 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 of claim 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 of claim 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 of claim 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 of claim 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 of claim 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 of claim 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 of claim 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 of claim 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 of claim 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 of claim 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 of claim 46 , wherein the DoS attack comprises an SSL DoS attack.
52. The system of claim 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 of claim 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 of claim 46 , wherein the first server system and the second server system are owned by different entities.
55. The system of claim 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 of claim 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 of claim 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 of claim 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 of claim 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 of claim 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 of claim 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 of claim 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 of claim 46 , wherein identifying one or more non-suspect clients further comprises:
whitelisting clients that successfully complete one or more challenge mechanisms.
64. The system of claim 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 of claim 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 of claim 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 of claim 46 , wherein identifying one or more suspect clients further comprises:
blacklisting clients that fail to complete one or more challenge mechanisms.
68. The system of claim 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 of claim 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 of claim 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 of claim 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 of claim 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 of claim 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 of claim 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 of claim 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 of claim 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 of claim 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 of claim 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 of claim 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 of claim 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 of claim 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 of claim 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 of claim 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 of claim 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 of claim 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 of claim 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.
Priority Applications (7)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US12/982,520 US20120174196A1 (en) | 2010-12-30 | 2010-12-30 | Active validation for ddos and ssl ddos attacks |
EP11808991.1A EP2659614A1 (en) | 2010-12-30 | 2011-12-12 | Active validation for ddos and ssl ddos attacks |
TW100145811A TW201233103A (en) | 2010-12-30 | 2011-12-12 | Active validation for DDoS and SSL DDoS attacks |
PCT/US2011/064328 WO2012096740A1 (en) | 2010-12-30 | 2011-12-12 | Active validation for ddos and ssl ddos attacks |
US14/095,712 US9473530B2 (en) | 2010-12-30 | 2013-12-03 | Client-side active validation for mitigating DDOS attacks |
US15/092,165 US10250618B2 (en) | 2010-12-30 | 2016-04-06 | Active validation for DDoS and SSL DDoS attacks |
US15/293,770 US9742799B2 (en) | 2010-12-30 | 2016-10-14 | Client-side active validation for mitigating DDOS attacks |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US12/982,520 US20120174196A1 (en) | 2010-12-30 | 2010-12-30 | Active validation for ddos and ssl ddos attacks |
Related Child Applications (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US14/095,712 Continuation-In-Part US9473530B2 (en) | 2010-12-30 | 2013-12-03 | Client-side active validation for mitigating DDOS attacks |
US15/092,165 Division US10250618B2 (en) | 2010-12-30 | 2016-04-06 | Active validation for DDoS and SSL DDoS attacks |
Publications (1)
Publication Number | Publication Date |
---|---|
US20120174196A1 true US20120174196A1 (en) | 2012-07-05 |
Family
ID=45496259
Family Applications (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US12/982,520 Abandoned US20120174196A1 (en) | 2010-12-30 | 2010-12-30 | Active validation for ddos and ssl ddos attacks |
US15/092,165 Active US10250618B2 (en) | 2010-12-30 | 2016-04-06 | Active validation for DDoS and SSL DDoS attacks |
Family Applications After (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US15/092,165 Active US10250618B2 (en) | 2010-12-30 | 2016-04-06 | Active validation for DDoS and SSL DDoS attacks |
Country Status (4)
Country | Link |
---|---|
US (2) | US20120174196A1 (en) |
EP (1) | EP2659614A1 (en) |
TW (1) | TW201233103A (en) |
WO (1) | WO2012096740A1 (en) |
Cited By (233)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20120233468A1 (en) * | 2011-03-10 | 2012-09-13 | Samsung Electronics Co., Ltd. | Authenticating method of communicating connection, gateway apparatus using authenticating method, and communication system using authenticating method |
US20120297197A1 (en) * | 2011-05-16 | 2012-11-22 | Norman Yale | Dynamic Domain Name Server Console for Disaster Recovery Server Management |
US20130007870A1 (en) * | 2011-06-28 | 2013-01-03 | The Go Daddy Group, Inc. | Systems for bi-directional network traffic malware detection and removal |
US20130007882A1 (en) * | 2011-06-28 | 2013-01-03 | The Go Daddy Group, Inc. | Methods of detecting and removing bidirectional network traffic malware |
US20130086211A1 (en) * | 2011-09-29 | 2013-04-04 | Oracle International Corporation | Mobile application, resource management advice |
US20130254879A1 (en) * | 2012-03-21 | 2013-09-26 | Radware, Ltd. | Method and system for detecting and mitigating attacks performed using cryptographic protocols |
US20140067996A1 (en) * | 2012-08-30 | 2014-03-06 | Yahoo! Inc. | Method and system for reducing network latency |
US20140068761A1 (en) * | 2012-09-06 | 2014-03-06 | Microsoft Corporation | Abuse identification of front-end based services |
US8677489B2 (en) * | 2012-01-24 | 2014-03-18 | L3 Communications Corporation | Methods and apparatus for managing network traffic |
US20140082204A1 (en) * | 2012-09-20 | 2014-03-20 | Cisco Technology, Inc. | Seamless Engagement and Disengagement of Transport Layer Security Proxy Services |
US20140108667A1 (en) * | 2012-10-15 | 2014-04-17 | Dell Products L.P. | Techniques for Generating Different Sessions for Multiple Tabs of a Single Browser Window |
US20140208194A1 (en) * | 2013-01-22 | 2014-07-24 | Michael O'Leary | Device and system for securely executing electronic documents |
US20140281510A1 (en) * | 2013-03-14 | 2014-09-18 | Shivakumar Buruganahalli | Decryption of data between a client and a server |
WO2014144555A1 (en) * | 2013-03-15 | 2014-09-18 | Robert Bosch Gmbh | System and method for mitigation of denial of service attacks in networked computing systems |
WO2014176461A1 (en) * | 2013-04-25 | 2014-10-30 | A10 Networks, Inc. | Systems and methods for network access control |
US20140373140A1 (en) * | 2013-06-18 | 2014-12-18 | Level 3 Communications, Llc | Data center redundancy in a network |
US20140373138A1 (en) * | 2011-06-27 | 2014-12-18 | Ahnlab, Inc. | Method and apparatus for preventing distributed denial of service attack |
US8990944B1 (en) * | 2013-02-23 | 2015-03-24 | Fireeye, Inc. | Systems and methods for automatically detecting backdoors |
US20150089566A1 (en) * | 2013-09-24 | 2015-03-26 | Radware, Ltd. | Escalation security method for use in software defined networks |
US8997219B2 (en) | 2008-11-03 | 2015-03-31 | Fireeye, Inc. | Systems and methods for detecting malicious PDF network content |
US9009823B1 (en) | 2013-02-23 | 2015-04-14 | Fireeye, Inc. | Framework for efficient security coverage of mobile software applications installed on mobile devices |
US20150113589A1 (en) * | 2013-10-01 | 2015-04-23 | Robert K. Lemaster | Authentication server enhancements |
US9141789B1 (en) | 2013-07-16 | 2015-09-22 | Go Daddy Operating Company, LLC | Mitigating denial of service attacks |
WO2015153849A1 (en) * | 2014-04-03 | 2015-10-08 | Automattic, Inc. | Systems and methods for protecting websites from botnet attacks |
US9176843B1 (en) | 2013-02-23 | 2015-11-03 | Fireeye, Inc. | Framework for efficient security coverage of mobile software applications |
US9178888B2 (en) | 2013-06-14 | 2015-11-03 | Go Daddy Operating Company, LLC | Method for domain control validation |
US20150339486A1 (en) * | 2014-05-21 | 2015-11-26 | Siddharth Shetye | Systems and methods for front-end and back-end data security protocols |
US20150372994A1 (en) * | 2014-06-23 | 2015-12-24 | Airwatch Llc | Cryptographic Proxy Service |
US9223972B1 (en) | 2014-03-31 | 2015-12-29 | Fireeye, Inc. | Dynamically remote tuning of a malware content detection system |
US20150381570A1 (en) * | 2013-08-14 | 2015-12-31 | Iboss, Inc. | Selectively performing man in the middle decryption |
US9262635B2 (en) | 2014-02-05 | 2016-02-16 | Fireeye, Inc. | Detection efficacy of virtual machine-based analysis with application specific events |
US9282109B1 (en) | 2004-04-01 | 2016-03-08 | Fireeye, Inc. | System and method for analyzing packets |
US9286331B2 (en) | 2010-05-06 | 2016-03-15 | Go Daddy Operating Company, LLC | Verifying and balancing server resources via stored usage data |
US9294501B2 (en) | 2013-09-30 | 2016-03-22 | Fireeye, Inc. | Fuzzy hash of behavioral results |
US9294503B2 (en) | 2013-08-26 | 2016-03-22 | A10 Networks, Inc. | Health monitor based distributed denial of service attack mitigation |
US9300686B2 (en) | 2013-06-28 | 2016-03-29 | Fireeye, Inc. | System and method for detecting malicious links in electronic messages |
US9306974B1 (en) | 2013-12-26 | 2016-04-05 | Fireeye, Inc. | System, apparatus and method for automatically verifying exploits within suspect objects and highlighting the display information associated with the verified exploits |
US9306960B1 (en) | 2004-04-01 | 2016-04-05 | Fireeye, Inc. | Systems and methods for unauthorized activity defense |
US9311479B1 (en) | 2013-03-14 | 2016-04-12 | Fireeye, Inc. | Correlation and consolidation of analytic data for holistic view of a malware attack |
US9355247B1 (en) | 2013-03-13 | 2016-05-31 | Fireeye, Inc. | File extraction from memory dump for malicious content analysis |
US9363280B1 (en) | 2014-08-22 | 2016-06-07 | Fireeye, Inc. | System and method of detecting delivery of malware using cross-customer data |
US9367681B1 (en) | 2013-02-23 | 2016-06-14 | Fireeye, Inc. | Framework for efficient security coverage of mobile software applications using symbolic execution to reach regions of interest within an application |
US9398028B1 (en) | 2014-06-26 | 2016-07-19 | Fireeye, Inc. | System, device and method for detecting a malicious attack based on communcations between remotely hosted virtual machines and malicious web servers |
JP5977860B1 (en) * | 2015-06-01 | 2016-08-24 | エヌ・ティ・ティ・コミュニケーションズ株式会社 | COMMUNICATION CONTROL METHOD, COMMUNICATION CONTROL DEVICE, AND PROGRAM |
US9430646B1 (en) | 2013-03-14 | 2016-08-30 | Fireeye, Inc. | Distributed systems and methods for automatically detecting unknown bots and botnets |
US9432389B1 (en) | 2014-03-31 | 2016-08-30 | Fireeye, Inc. | System, apparatus and method for detecting a malicious attack based on static analysis of a multi-flow object |
US9438623B1 (en) | 2014-06-06 | 2016-09-06 | Fireeye, Inc. | Computer exploit detection using heap spray pattern matching |
US9438613B1 (en) | 2015-03-30 | 2016-09-06 | Fireeye, Inc. | Dynamic content activation for automated analysis of embedded objects |
US9473530B2 (en) | 2010-12-30 | 2016-10-18 | Verisign, Inc. | Client-side active validation for mitigating DDOS attacks |
US9483644B1 (en) | 2015-03-31 | 2016-11-01 | Fireeye, Inc. | Methods for detecting file altering malware in VM based analysis |
US9495180B2 (en) | 2013-05-10 | 2016-11-15 | Fireeye, Inc. | Optimized resource allocation for virtual machines within a malware content detection system |
US9521138B2 (en) | 2013-06-14 | 2016-12-13 | Go Daddy Operating Company, LLC | System for domain control validation |
US9537886B1 (en) | 2014-10-23 | 2017-01-03 | A10 Networks, Inc. | Flagging security threats in web service requests |
US9584318B1 (en) * | 2014-12-30 | 2017-02-28 | A10 Networks, Inc. | Perfect forward secrecy distributed denial of service attack defense |
US9591015B1 (en) | 2014-03-28 | 2017-03-07 | Fireeye, Inc. | System and method for offloading packet processing and static analysis operations |
GB2541969A (en) * | 2016-05-27 | 2017-03-08 | F Secure Corp | Mitigating multiple advanced evasion technique attacks |
US9594912B1 (en) | 2014-06-06 | 2017-03-14 | Fireeye, Inc. | Return-oriented programming detection |
US9594904B1 (en) | 2015-04-23 | 2017-03-14 | Fireeye, Inc. | Detecting malware based on reflection |
EP3142327A1 (en) * | 2015-09-10 | 2017-03-15 | Openwave Mobility, Inc. | Intermediate network entity |
US9621575B1 (en) | 2014-12-29 | 2017-04-11 | A10 Networks, Inc. | Context aware threat protection |
US9628507B2 (en) | 2013-09-30 | 2017-04-18 | Fireeye, Inc. | Advanced persistent threat (APT) detection center |
US9628498B1 (en) | 2004-04-01 | 2017-04-18 | Fireeye, Inc. | System and method for bot detection |
US9626509B1 (en) | 2013-03-13 | 2017-04-18 | Fireeye, Inc. | Malicious content analysis with multi-version application support within single operating environment |
US9661018B1 (en) | 2004-04-01 | 2017-05-23 | Fireeye, Inc. | System and method for detecting anomalous behaviors using a virtual machine environment |
US9680801B1 (en) | 2016-05-03 | 2017-06-13 | Iboss, Inc. | Selectively altering references within encrypted pages using man in the middle |
US9690933B1 (en) | 2014-12-22 | 2017-06-27 | Fireeye, Inc. | Framework for classifying an object as malicious with machine learning for deploying updated predictive models |
US9690606B1 (en) | 2015-03-25 | 2017-06-27 | Fireeye, Inc. | Selective system call monitoring |
US9690936B1 (en) | 2013-09-30 | 2017-06-27 | Fireeye, Inc. | Multistage system and method for analyzing obfuscated content for malware |
US9722918B2 (en) | 2013-03-15 | 2017-08-01 | A10 Networks, Inc. | System and method for customizing the identification of application or content type |
US9736179B2 (en) | 2013-09-30 | 2017-08-15 | Fireeye, Inc. | System, apparatus and method for using malware analysis results to drive adaptive instrumentation of virtual machines to improve exploit detection |
US9747446B1 (en) | 2013-12-26 | 2017-08-29 | Fireeye, Inc. | System and method for run-time object classification |
US9756071B1 (en) | 2014-09-16 | 2017-09-05 | A10 Networks, Inc. | DNS denial of service attack protection |
US9773112B1 (en) | 2014-09-29 | 2017-09-26 | Fireeye, Inc. | Exploit detection of malware and malware families |
US9781081B1 (en) * | 2015-10-02 | 2017-10-03 | Amazon Technologies, Inc. | Leveraging transport-layer cryptographic material |
US9787581B2 (en) | 2015-09-21 | 2017-10-10 | A10 Networks, Inc. | Secure data flow open information analytics |
US20170331854A1 (en) * | 2016-05-11 | 2017-11-16 | Cisco Technology, Inc. | Short Term Certificate Management During Distributed Denial of ServiceAttacks |
US9825976B1 (en) | 2015-09-30 | 2017-11-21 | Fireeye, Inc. | Detection and classification of exploit kits |
US9825989B1 (en) | 2015-09-30 | 2017-11-21 | Fireeye, Inc. | Cyber attack early warning system |
US9824216B1 (en) | 2015-12-31 | 2017-11-21 | Fireeye, Inc. | Susceptible environment detection system |
US9838417B1 (en) | 2014-12-30 | 2017-12-05 | Fireeye, Inc. | Intelligent context aware user interaction for malware detection |
US9838416B1 (en) | 2004-06-14 | 2017-12-05 | Fireeye, Inc. | System and method of detecting malicious content |
US9848013B1 (en) * | 2015-02-05 | 2017-12-19 | A10 Networks, Inc. | Perfect forward secrecy distributed denial of service attack detection |
US20170366636A1 (en) * | 2015-02-13 | 2017-12-21 | Huawei Technologies Co., Ltd. | Redirection method, apparatus, and system |
US9854000B2 (en) * | 2014-11-06 | 2017-12-26 | Cisco Technology, Inc. | Method and apparatus for detecting malicious software using handshake information |
US9900343B1 (en) | 2015-01-05 | 2018-02-20 | A10 Networks, Inc. | Distributed denial of service cellular signaling |
US9906422B2 (en) | 2014-05-16 | 2018-02-27 | A10 Networks, Inc. | Distributed system to determine a server's health |
US9912555B2 (en) | 2013-03-15 | 2018-03-06 | A10 Networks, Inc. | System and method of updating modules for application or content identification |
US9910988B1 (en) | 2013-09-30 | 2018-03-06 | Fireeye, Inc. | Malware analysis in accordance with an analysis plan |
US9921978B1 (en) | 2013-11-08 | 2018-03-20 | Fireeye, Inc. | System and method for enhanced security of storage devices |
US9973531B1 (en) | 2014-06-06 | 2018-05-15 | Fireeye, Inc. | Shellcode detection |
US20180176189A1 (en) * | 2016-12-15 | 2018-06-21 | Ixia | In-Session Splitting Of Network Traffic Sessions For Server Traffic Monitoring |
US10027689B1 (en) | 2014-09-29 | 2018-07-17 | Fireeye, Inc. | Interactive infection visualization for improved exploit detection and signature generation for malware and malware families |
US10027690B2 (en) | 2004-04-01 | 2018-07-17 | Fireeye, Inc. | Electronic message analysis for malware detection |
US10033747B1 (en) | 2015-09-29 | 2018-07-24 | Fireeye, Inc. | System and method for detecting interpreter-based exploit attacks |
US10044582B2 (en) | 2012-01-28 | 2018-08-07 | A10 Networks, Inc. | Generating secure name records |
US10050998B1 (en) | 2015-12-30 | 2018-08-14 | Fireeye, Inc. | Malicious message analysis system |
US10063591B1 (en) | 2015-02-14 | 2018-08-28 | A10 Networks, Inc. | Implementing and optimizing secure socket layer intercept |
US10068091B1 (en) | 2004-04-01 | 2018-09-04 | Fireeye, Inc. | System and method for malware containment |
US10075455B2 (en) | 2014-12-26 | 2018-09-11 | Fireeye, Inc. | Zero-day rotating guest image profile |
US10084813B2 (en) | 2014-06-24 | 2018-09-25 | Fireeye, Inc. | Intrusion prevention and remedy system |
US10116634B2 (en) | 2016-06-28 | 2018-10-30 | A10 Networks, Inc. | Intercepting secure session upon receipt of untrusted certificate |
US10133863B2 (en) | 2013-06-24 | 2018-11-20 | Fireeye, Inc. | Zero-day discovery system |
US10133866B1 (en) | 2015-12-30 | 2018-11-20 | Fireeye, Inc. | System and method for triggering analysis of an object for malware in response to modification of that object |
US10148693B2 (en) | 2015-03-25 | 2018-12-04 | Fireeye, Inc. | Exploit detection system |
US10157280B2 (en) | 2009-09-23 | 2018-12-18 | F5 Networks, Inc. | System and method for identifying security breach attempts of a website |
US10158666B2 (en) | 2016-07-26 | 2018-12-18 | A10 Networks, Inc. | Mitigating TCP SYN DDoS attacks using TCP reset |
US10165000B1 (en) | 2004-04-01 | 2018-12-25 | Fireeye, Inc. | Systems and methods for malware attack prevention by intercepting flows of information |
DE102017210721A1 (en) * | 2017-06-26 | 2018-12-27 | Siemens Aktiengesellschaft | Method and communication system for the efficient establishment of a secure data connection between a client computer and a server computer |
US10169585B1 (en) | 2016-06-22 | 2019-01-01 | Fireeye, Inc. | System and methods for advanced malware detection through placement of transition events |
US10176321B2 (en) | 2015-09-22 | 2019-01-08 | Fireeye, Inc. | Leveraging behavior-based rules for malware family classification |
US20190020644A1 (en) * | 2016-03-14 | 2019-01-17 | Ricoh Company, Ltd. | Service providing system, service delivery system, service providing method, and non-transitory recording medium |
US10187377B2 (en) | 2017-02-08 | 2019-01-22 | A10 Networks, Inc. | Caching network generated security certificates |
US10210329B1 (en) | 2015-09-30 | 2019-02-19 | Fireeye, Inc. | Method to detect application execution hijacking using memory protection |
US10242185B1 (en) | 2014-03-21 | 2019-03-26 | Fireeye, Inc. | Dynamic guest image creation and rollback |
US20190097983A1 (en) * | 2013-03-07 | 2019-03-28 | Cloudflare, Inc. | Secure session capability using public-key cryptography without access to the private key |
US10250475B2 (en) | 2016-12-08 | 2019-04-02 | A10 Networks, Inc. | Measurement of application response delay time |
US10264079B2 (en) | 2016-05-18 | 2019-04-16 | Cisco Technology, Inc. | Fastpath web sessions with HTTP header modification by redirecting clients |
US10284574B1 (en) | 2004-04-01 | 2019-05-07 | Fireeye, Inc. | System and method for threat detection and identification |
US10284575B2 (en) | 2015-11-10 | 2019-05-07 | Fireeye, Inc. | Launcher for setting analysis environment variations for malware detection |
US10341365B1 (en) | 2015-12-30 | 2019-07-02 | Fireeye, Inc. | Methods and system for hiding transition events for malware detection |
US10341118B2 (en) | 2016-08-01 | 2019-07-02 | A10 Networks, Inc. | SSL gateway with integrated hardware security module |
US10382562B2 (en) | 2016-11-04 | 2019-08-13 | A10 Networks, Inc. | Verification of server certificates using hash codes |
US10397270B2 (en) | 2017-01-04 | 2019-08-27 | A10 Networks, Inc. | Dynamic session rate limiter |
US10417031B2 (en) | 2015-03-31 | 2019-09-17 | Fireeye, Inc. | Selective virtualization for security threat detection |
US10432649B1 (en) | 2014-03-20 | 2019-10-01 | Fireeye, Inc. | System and method for classifying an object based on an aggregated behavior results |
US10447728B1 (en) | 2015-12-10 | 2019-10-15 | Fireeye, Inc. | Technique for protecting guest processes using a layered virtualization architecture |
US10454950B1 (en) | 2015-06-30 | 2019-10-22 | Fireeye, Inc. | Centralized aggregation technique for detecting lateral movement of stealthy cyber-attacks |
US10454899B1 (en) * | 2015-03-16 | 2019-10-22 | Amazon Technologies, Inc. | Controlling firewall ports in virtualized environments through public key cryptography |
US10462173B1 (en) | 2016-06-30 | 2019-10-29 | Fireeye, Inc. | Malware detection verification and enhancement by coordinating endpoint and malware detection systems |
US10469594B2 (en) | 2015-12-08 | 2019-11-05 | A10 Networks, Inc. | Implementation of secure socket layer intercept |
US10476906B1 (en) | 2016-03-25 | 2019-11-12 | Fireeye, Inc. | System and method for managing formation and modification of a cluster within a malware detection system |
US10474813B1 (en) | 2015-03-31 | 2019-11-12 | Fireeye, Inc. | Code injection technique for remediation at an endpoint of a network |
US10491627B1 (en) | 2016-09-29 | 2019-11-26 | Fireeye, Inc. | Advanced malware detection using similarity analysis |
US10505984B2 (en) | 2015-12-08 | 2019-12-10 | A10 Networks, Inc. | Exchange of control information between secure socket layer gateways |
US10503904B1 (en) | 2017-06-29 | 2019-12-10 | Fireeye, Inc. | Ransomware detection and mitigation |
US10515214B1 (en) | 2013-09-30 | 2019-12-24 | Fireeye, Inc. | System and method for classifying malware within content created during analysis of a specimen |
US10523609B1 (en) | 2016-12-27 | 2019-12-31 | Fireeye, Inc. | Multi-vector malware detection and analysis |
US10528726B1 (en) | 2014-12-29 | 2020-01-07 | Fireeye, Inc. | Microvisor-based malware detection appliance architecture |
US10552610B1 (en) | 2016-12-22 | 2020-02-04 | Fireeye, Inc. | Adaptive virtual machine snapshot update framework for malware behavioral analysis |
US10554507B1 (en) | 2017-03-30 | 2020-02-04 | Fireeye, Inc. | Multi-level control for enhanced resource and object evaluation management of malware detection system |
US10565378B1 (en) | 2015-12-30 | 2020-02-18 | Fireeye, Inc. | Exploit of privilege detection framework |
US10572665B2 (en) | 2012-12-28 | 2020-02-25 | Fireeye, Inc. | System and method to create a number of breakpoints in a virtual machine via virtual machine trapping events |
US10581874B1 (en) | 2015-12-31 | 2020-03-03 | Fireeye, Inc. | Malware detection system with contextual analysis |
US10581879B1 (en) | 2016-12-22 | 2020-03-03 | Fireeye, Inc. | Enhanced malware detection for generated objects |
US10587647B1 (en) | 2016-11-22 | 2020-03-10 | Fireeye, Inc. | Technique for malware detection capability comparison of network security devices |
US10592678B1 (en) | 2016-09-09 | 2020-03-17 | Fireeye, Inc. | Secure communications between peers using a verified virtual trusted platform module |
US10601848B1 (en) | 2017-06-29 | 2020-03-24 | Fireeye, Inc. | Cyber-security system and method for weak indicator detection and correlation to generate strong indicators |
US10601863B1 (en) | 2016-03-25 | 2020-03-24 | Fireeye, Inc. | System and method for managing sensor enrollment |
US10601865B1 (en) | 2015-09-30 | 2020-03-24 | Fireeye, Inc. | Detection of credential spearphishing attacks using email analysis |
US10628228B1 (en) * | 2017-08-28 | 2020-04-21 | Amazon Technologies, Inc. | Tiered usage limits across compute resource partitions |
US10637880B1 (en) | 2013-05-13 | 2020-04-28 | Fireeye, Inc. | Classifying sets of malicious indicators for detecting command and control communications associated with malware |
US10642753B1 (en) | 2015-06-30 | 2020-05-05 | Fireeye, Inc. | System and method for protecting a software component running in virtual machine using a virtualization layer |
US10671726B1 (en) | 2014-09-22 | 2020-06-02 | Fireeye Inc. | System and method for malware analysis using thread-level event monitoring |
US10671721B1 (en) | 2016-03-25 | 2020-06-02 | Fireeye, Inc. | Timeout management services |
US10701091B1 (en) | 2013-03-15 | 2020-06-30 | Fireeye, Inc. | System and method for verifying a cyberthreat |
US10706149B1 (en) | 2015-09-30 | 2020-07-07 | Fireeye, Inc. | Detecting delayed activation malware using a primary controller and plural time controllers |
US10715542B1 (en) | 2015-08-14 | 2020-07-14 | Fireeye, Inc. | Mobile application risk analysis |
US10713358B2 (en) | 2013-03-15 | 2020-07-14 | Fireeye, Inc. | System and method to extract and utilize disassembly features to classify software intent |
US10726127B1 (en) | 2015-06-30 | 2020-07-28 | Fireeye, Inc. | System and method for protecting a software component running in a virtual machine through virtual interrupts by the virtualization layer |
US10728263B1 (en) | 2015-04-13 | 2020-07-28 | Fireeye, Inc. | Analytic-based security monitoring system and method |
US10742612B2 (en) | 2017-10-16 | 2020-08-11 | Cisco Technology, Inc. | Determine payload integrity for traffic flowing across proxies |
US10740456B1 (en) | 2014-01-16 | 2020-08-11 | Fireeye, Inc. | Threat-aware architecture |
US10747872B1 (en) | 2017-09-27 | 2020-08-18 | Fireeye, Inc. | System and method for preventing malware evasion |
US10785255B1 (en) | 2016-03-25 | 2020-09-22 | Fireeye, Inc. | Cluster configuration within a scalable malware detection system |
US10791119B1 (en) | 2017-03-14 | 2020-09-29 | F5 Networks, Inc. | Methods for temporal password injection and devices thereof |
US10791138B1 (en) | 2017-03-30 | 2020-09-29 | Fireeye, Inc. | Subscription-based malware detection |
US10798112B2 (en) | 2017-03-30 | 2020-10-06 | Fireeye, Inc. | Attribute-controlled malware detection |
US10795991B1 (en) | 2016-11-08 | 2020-10-06 | Fireeye, Inc. | Enterprise search |
US10805340B1 (en) | 2014-06-26 | 2020-10-13 | Fireeye, Inc. | Infection vector and malware tracking with an interactive user display |
US10805346B2 (en) | 2017-10-01 | 2020-10-13 | Fireeye, Inc. | Phishing attack detection |
US10812348B2 (en) | 2016-07-15 | 2020-10-20 | A10 Networks, Inc. | Automatic capture of network data for a detected anomaly |
US10817606B1 (en) | 2015-09-30 | 2020-10-27 | Fireeye, Inc. | Detecting delayed activation malware using a run-time monitoring agent and time-dilation logic |
US10826931B1 (en) | 2018-03-29 | 2020-11-03 | Fireeye, Inc. | System and method for predicting and mitigating cybersecurity system misconfigurations |
US20200358827A1 (en) * | 2013-07-23 | 2020-11-12 | Zscaler, Inc. | Cloud based security using DNS |
WO2020231688A1 (en) * | 2019-05-10 | 2020-11-19 | Akamai Technologies, Inc. | Using the state of a request routing mechanism to inform attack detection and mitigation |
US20200366689A1 (en) * | 2019-05-17 | 2020-11-19 | Charter Communications Operating, Llc | Botnet detection and mitigation |
US10846117B1 (en) | 2015-12-10 | 2020-11-24 | Fireeye, Inc. | Technique for establishing secure communication between host and guest processes of a virtualization architecture |
US10848521B1 (en) | 2013-03-13 | 2020-11-24 | Fireeye, Inc. | Malicious content analysis using simulated user interaction without user involvement |
US10855700B1 (en) | 2017-06-29 | 2020-12-01 | Fireeye, Inc. | Post-intrusion detection of cyber-attacks during lateral movement within networks |
US20200396217A1 (en) * | 2017-07-13 | 2020-12-17 | Microsoft Technology Licensing, Llc | Key Attestation Statement Generation Providing Device Anonymity |
CN112104744A (en) * | 2020-03-30 | 2020-12-18 | 厦门网宿有限公司 | Traffic proxy method, server and storage medium |
US10893068B1 (en) | 2017-06-30 | 2021-01-12 | Fireeye, Inc. | Ransomware file modification prevention technique |
US10893059B1 (en) | 2016-03-31 | 2021-01-12 | Fireeye, Inc. | Verification and enhancement using detection systems located at the network periphery and endpoint devices |
US10904286B1 (en) | 2017-03-24 | 2021-01-26 | Fireeye, Inc. | Detection of phishing attacks using similarity analysis |
US10903990B1 (en) | 2020-03-11 | 2021-01-26 | Cloudflare, Inc. | Establishing a cryptographic tunnel between a first tunnel endpoint and a second tunnel endpoint where a private key used during the tunnel establishment is remotely located from the second tunnel endpoint |
US10902119B1 (en) | 2017-03-30 | 2021-01-26 | Fireeye, Inc. | Data extraction system for malware analysis |
US10911483B1 (en) * | 2017-03-20 | 2021-02-02 | Amazon Technologies, Inc. | Early detection of dedicated denial of service attacks through metrics correlation |
US10929266B1 (en) | 2013-02-23 | 2021-02-23 | Fireeye, Inc. | Real-time visual playback with synchronous textual analysis log display and event/time indexing |
US10931465B2 (en) | 2011-07-28 | 2021-02-23 | Cloudflare, Inc. | Supporting secure sessions in a cloud-based proxy service |
US10931662B1 (en) | 2017-04-10 | 2021-02-23 | F5 Networks, Inc. | Methods for ephemeral authentication screening and devices thereof |
US10951652B1 (en) * | 2016-01-21 | 2021-03-16 | Amazon Technologies, Inc. | Communication session resumption |
US10956477B1 (en) | 2018-03-30 | 2021-03-23 | Fireeye, Inc. | System and method for detecting malicious scripts through natural language processing modeling |
US11005860B1 (en) | 2017-12-28 | 2021-05-11 | Fireeye, Inc. | Method and system for efficient cybersecurity analysis of endpoint events |
US11003773B1 (en) | 2018-03-30 | 2021-05-11 | Fireeye, Inc. | System and method for automatically generating malware detection rule recommendations |
US11044083B2 (en) | 2014-04-08 | 2021-06-22 | Cloudflare, Inc. | Secure session capability using public-key cryptography without access to the private key |
US11076010B2 (en) | 2016-03-29 | 2021-07-27 | Ricoh Company, Ltd. | Service providing system, service delivery system, service providing method, and non-transitory recording medium |
US11075930B1 (en) | 2018-06-27 | 2021-07-27 | Fireeye, Inc. | System and method for detecting repetitive cybersecurity attacks constituting an email campaign |
US20210266342A1 (en) * | 2017-01-27 | 2021-08-26 | Level 3 Communications, Llc | System and method for scrubbing dns in a telecommunications network to mitigate attacks |
US11108772B2 (en) | 2016-03-29 | 2021-08-31 | Ricoh Company, Ltd. | Service providing system, service delivery system, service providing method, and non-transitory recording medium |
US11108809B2 (en) | 2017-10-27 | 2021-08-31 | Fireeye, Inc. | System and method for analyzing binary code for malware classification using artificial neural network techniques |
US11113086B1 (en) | 2015-06-30 | 2021-09-07 | Fireeye, Inc. | Virtual system and method for securing external network connectivity |
US11128623B2 (en) | 2016-03-29 | 2021-09-21 | Ricoh Company, Ltd. | Service providing system, service delivery system, service providing method, and non-transitory recording medium |
US11153341B1 (en) | 2004-04-01 | 2021-10-19 | Fireeye, Inc. | System and method for detecting malicious network content using virtual environment components |
US11159562B2 (en) * | 2018-06-19 | 2021-10-26 | Wangsu Science & Technology Co., Ltd. | Method and system for defending an HTTP flood attack |
US11165586B1 (en) * | 2020-10-30 | 2021-11-02 | Capital One Services, Llc | Call center web-based authentication using a contactless card |
US11182473B1 (en) | 2018-09-13 | 2021-11-23 | Fireeye Security Holdings Us Llc | System and method for mitigating cyberattacks against processor operability by a guest process |
US11200080B1 (en) | 2015-12-11 | 2021-12-14 | Fireeye Security Holdings Us Llc | Late load technique for deploying a virtualization layer underneath a running operating system |
US20220006654A1 (en) * | 2020-07-02 | 2022-01-06 | EMC IP Holding Company LLC | Method to establish an application level ssl certificate hierarchy between master node and capacity nodes based on hardware level certificate hierarchy |
US11228491B1 (en) | 2018-06-28 | 2022-01-18 | Fireeye Security Holdings Us Llc | System and method for distributed cluster configuration monitoring and management |
US11240275B1 (en) | 2017-12-28 | 2022-02-01 | Fireeye Security Holdings Us Llc | Platform and method for performing cybersecurity analyses employing an intelligence hub with a modular architecture |
US11244056B1 (en) | 2014-07-01 | 2022-02-08 | Fireeye Security Holdings Us Llc | Verification of trusted threat-aware visualization layer |
US11258806B1 (en) | 2019-06-24 | 2022-02-22 | Mandiant, Inc. | System and method for automatically associating cybersecurity intelligence to cyberthreat actors |
US11271955B2 (en) | 2017-12-28 | 2022-03-08 | Fireeye Security Holdings Us Llc | Platform and method for retroactive reclassification employing a cybersecurity-based global data store |
US11314859B1 (en) | 2018-06-27 | 2022-04-26 | FireEye Security Holdings, Inc. | Cyber-security system and method for detecting escalation of privileges within an access token |
US11316900B1 (en) | 2018-06-29 | 2022-04-26 | FireEye Security Holdings Inc. | System and method for automatically prioritizing rules for cyber-threat detection and mitigation |
US11356423B2 (en) * | 2020-01-14 | 2022-06-07 | Cisco Technology, Inc. | Managing encrypted server-name-indication (ESNI) at proxy devices |
US11363044B2 (en) | 2019-06-26 | 2022-06-14 | Radware, Ltd. | Method and system for detecting and mitigating HTTPS flood attacks |
US11368475B1 (en) | 2018-12-21 | 2022-06-21 | Fireeye Security Holdings Us Llc | System and method for scanning remote services to locate stored objects with malware |
US11381578B1 (en) | 2009-09-30 | 2022-07-05 | Fireeye Security Holdings Us Llc | Network-based binary file extraction and analysis for malware detection |
US11392700B1 (en) | 2019-06-28 | 2022-07-19 | Fireeye Security Holdings Us Llc | System and method for supporting cross-platform data verification |
US11438178B2 (en) | 2014-04-08 | 2022-09-06 | Cloudflare, Inc. | Secure session capability using public-key cryptography without access to the private key |
CN115065537A (en) * | 2022-06-16 | 2022-09-16 | 公安部第三研究所 | Defense system and dynamic defense method for WEB application automation attack behavior |
US11496438B1 (en) | 2017-02-07 | 2022-11-08 | F5, Inc. | Methods for improved network security using asymmetric traffic delivery and devices thereof |
CN115333873A (en) * | 2022-10-17 | 2022-11-11 | 华中科技大学 | Attack URL detection method, device and system based on behavior pattern |
US11503052B2 (en) * | 2019-12-19 | 2022-11-15 | Radware, Ltd. | Baselining techniques for detecting anomalous HTTPS traffic behavior |
US11552986B1 (en) | 2015-12-31 | 2023-01-10 | Fireeye Security Holdings Us Llc | Cyber-security framework for application of virtual features |
US11556640B1 (en) | 2019-06-27 | 2023-01-17 | Mandiant, Inc. | Systems and methods for automated cybersecurity analysis of extracted binary string sets |
US11558401B1 (en) | 2018-03-30 | 2023-01-17 | Fireeye Security Holdings Us Llc | Multi-vector malware detection data sharing system for improved detection |
US11637862B1 (en) | 2019-09-30 | 2023-04-25 | Mandiant, Inc. | System and method for surfacing cyber-security threats with a self-learning recommendation engine |
US11658995B1 (en) | 2018-03-20 | 2023-05-23 | F5, Inc. | Methods for dynamically mitigating network attacks and devices thereof |
US11720660B2 (en) * | 2019-01-28 | 2023-08-08 | EMC IP Holding Company LLC | Temporary partial authentication value provisioning for offline authentication |
US11763004B1 (en) | 2018-09-27 | 2023-09-19 | Fireeye Security Holdings Us Llc | System and method for bootkit detection |
US11886585B1 (en) | 2019-09-27 | 2024-01-30 | Musarubra Us Llc | System and method for identifying and mitigating cyberattacks through malicious position-independent code execution |
Families Citing this family (18)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US10474820B2 (en) | 2014-06-17 | 2019-11-12 | Hewlett Packard Enterprise Development Lp | DNS based infection scores |
US9264370B1 (en) | 2015-02-10 | 2016-02-16 | Centripetal Networks, Inc. | Correlating packets in communications networks |
US9866576B2 (en) | 2015-04-17 | 2018-01-09 | Centripetal Networks, Inc. | Rule-based network-threat detection |
CN113316025A (en) | 2016-02-02 | 2021-08-27 | 弗劳恩霍夫应用研究促进协会 | Scene portion and region of interest processing in video streaming |
US10681078B2 (en) | 2016-06-10 | 2020-06-09 | Sophos Limited | Key throttling to mitigate unauthorized file access |
US10686827B2 (en) | 2016-04-14 | 2020-06-16 | Sophos Limited | Intermediate encryption for exposed content |
GB2565185B (en) * | 2016-02-12 | 2019-11-27 | Sophos Ltd | Encryption techniques |
US10628597B2 (en) | 2016-04-14 | 2020-04-21 | Sophos Limited | Just-in-time encryption |
US10650154B2 (en) | 2016-02-12 | 2020-05-12 | Sophos Limited | Process-level control of encrypted content |
US10791097B2 (en) | 2016-04-14 | 2020-09-29 | Sophos Limited | Portable encryption format |
US9984248B2 (en) | 2016-02-12 | 2018-05-29 | Sophos Limited | Behavioral-based control of access to encrypted content by a process |
GB2551983B (en) | 2016-06-30 | 2020-03-04 | Sophos Ltd | Perimeter encryption |
CN107666383B (en) * | 2016-07-29 | 2021-06-18 | 阿里巴巴集团控股有限公司 | Message processing method and device based on HTTPS (hypertext transfer protocol secure protocol) |
RU2676021C1 (en) | 2017-07-17 | 2018-12-25 | Акционерное общество "Лаборатория Касперского" | DDoS-ATTACKS DETECTION SYSTEM AND METHOD |
GB2563497B (en) * | 2018-05-18 | 2019-10-09 | Qip Solutions Ltd | Data filtering |
GB2574468B (en) * | 2018-06-08 | 2020-08-26 | F Secure Corp | Detecting a remote exploitation attack |
US11405418B2 (en) | 2020-06-16 | 2022-08-02 | Bank Of America Corporation | Automated distributed denial of service attack detection and prevention |
US11297152B1 (en) | 2021-09-30 | 2022-04-05 | metacluster lt, UAB | Regulation methods for proxy services |
Citations (14)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20030229809A1 (en) * | 1999-04-15 | 2003-12-11 | Asaf Wexler | Transparent proxy server |
US20040158766A1 (en) * | 2002-09-09 | 2004-08-12 | John Liccione | System and method for application monitoring and automatic disaster recovery for high-availability |
US20050235358A1 (en) * | 2004-04-15 | 2005-10-20 | International Business Machines Corporation | Server denial of service shield |
US20060107318A1 (en) * | 2004-09-14 | 2006-05-18 | International Business Machines Corporation | Detection of grid participation in a DDoS attack |
US20060112176A1 (en) * | 2000-07-19 | 2006-05-25 | Liu Zaide E | Domain name resolution using a distributed DNS network |
US20060206922A1 (en) * | 2005-03-08 | 2006-09-14 | Securedatainnovations Ag | Secure Remote Access To Non-Public Private Web Servers |
US20070022474A1 (en) * | 2005-07-21 | 2007-01-25 | Mistletoe Technologies, Inc. | Portable firewall |
US20070083670A1 (en) * | 2005-10-11 | 2007-04-12 | International Business Machines Corporation | Method and system for protecting an internet user from fraudulent ip addresses on a dns server |
US20070118894A1 (en) * | 2005-11-23 | 2007-05-24 | Nextone Communications, Inc. | Method for responding to denial of service attacks at the session layer or above |
US20080159299A1 (en) * | 2006-12-29 | 2008-07-03 | Tian Bu | Methods and systems for providing controlled access to the internet |
US20090144806A1 (en) * | 2007-12-03 | 2009-06-04 | Cisco Technology, Inc. | Handling of DDoS attacks from NAT or proxy devices |
US7620733B1 (en) * | 2005-03-30 | 2009-11-17 | Cisco Technology, Inc. | DNS anti-spoofing using UDP |
US20120008567A1 (en) * | 2003-09-12 | 2012-01-12 | Jochen Eisl | Reachability maintenance of a moving network based on temporary name identifiers |
US8346960B2 (en) * | 2005-02-15 | 2013-01-01 | At&T Intellectual Property Ii, L.P. | Systems, methods, and devices for defending a network |
Family Cites Families (27)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6789203B1 (en) | 2000-06-26 | 2004-09-07 | Sun Microsystems, Inc. | Method and apparatus for preventing a denial of service (DOS) attack by selectively throttling TCP/IP requests |
US7373510B2 (en) | 2000-09-12 | 2008-05-13 | International Business Machines Corporation | System and method for implementing a robot proof Web site |
US7707305B2 (en) * | 2000-10-17 | 2010-04-27 | Cisco Technology, Inc. | Methods and apparatus for protecting against overload conditions on nodes of a distributed network |
US7307999B1 (en) * | 2001-02-16 | 2007-12-11 | Bbn Technologies Corp. | Systems and methods that identify normal traffic during network attacks |
AU2002303501A1 (en) * | 2001-04-27 | 2002-11-11 | Wanwall, Inc. | Weighted fair queuing-based methods and apparatus for protecting against overload conditions on nodes of a distributed network |
US6851062B2 (en) * | 2001-09-27 | 2005-02-01 | International Business Machines Corporation | System and method for managing denial of service attacks |
US6944663B2 (en) | 2002-03-06 | 2005-09-13 | Sun Microsystems, Inc. | Method and apparatus for using client puzzles to protect against denial-of-service attacks |
AU2003247700A1 (en) | 2002-07-02 | 2004-01-23 | Netscaler, Inc | System, method and computer program product to avoid server overload by controlling http denial of service (dos) attacks |
US20040148520A1 (en) * | 2003-01-29 | 2004-07-29 | Rajesh Talpade | Mitigating denial of service attacks |
US7681235B2 (en) * | 2003-05-19 | 2010-03-16 | Radware Ltd. | Dynamic network protection |
US8171562B2 (en) | 2003-08-26 | 2012-05-01 | Oregon Health & Science University | System and methods for protecting against denial of service attacks |
CN102098305A (en) | 2004-01-26 | 2011-06-15 | 思科技术公司 | Upper-level protocol authentication |
US20050256968A1 (en) | 2004-05-12 | 2005-11-17 | Johnson Teddy C | Delaying browser requests |
US20060031680A1 (en) * | 2004-08-04 | 2006-02-09 | Yehuda Maiman | System and method for controlling access to a computerized entity |
US7661131B1 (en) * | 2005-02-03 | 2010-02-09 | Sun Microsystems, Inc. | Authentication of tunneled connections |
US8549646B2 (en) | 2005-10-20 | 2013-10-01 | The Trustees Of Columbia University In The City Of New York | Methods, media and systems for responding to a denial of service attack |
KR100828372B1 (en) | 2005-12-29 | 2008-05-08 | 삼성전자주식회사 | Method and apparatus for protecting servers from DOS attack |
AU2007215180B2 (en) | 2006-02-10 | 2011-03-17 | NortonLifeLock Inc. | System and method for network-based fraud and authentication services |
WO2007125402A2 (en) * | 2006-04-27 | 2007-11-08 | Axalto Sa | A method for protecting local servers from denial-of-service attacks |
US7721091B2 (en) | 2006-05-12 | 2010-05-18 | International Business Machines Corporation | Method for protecting against denial of service attacks using trust, quality of service, personalization, and hide port messages |
US20080034424A1 (en) | 2006-07-20 | 2008-02-07 | Kevin Overcash | System and method of preventing web applications threats |
US8028072B2 (en) | 2008-03-03 | 2011-09-27 | International Business Machines Corporation | Method, apparatus and computer program product implementing session-specific URLs and resources |
US9094435B2 (en) | 2009-12-23 | 2015-07-28 | Citrix Systems, Inc. | Systems and methods for prevention of JSON attacks |
US9634993B2 (en) | 2010-04-01 | 2017-04-25 | Cloudflare, Inc. | Internet-based proxy service to modify internet responses |
US9461996B2 (en) | 2010-05-07 | 2016-10-04 | Citrix Systems, Inc. | Systems and methods for providing a single click access to enterprise, SAAS and cloud hosted application |
US8850219B2 (en) | 2010-05-13 | 2014-09-30 | Salesforce.Com, Inc. | Secure communications |
US9686255B2 (en) | 2010-07-21 | 2017-06-20 | Citrix Systems, Inc. | Systems and methods for an extensible authentication framework |
-
2010
- 2010-12-30 US US12/982,520 patent/US20120174196A1/en not_active Abandoned
-
2011
- 2011-12-12 TW TW100145811A patent/TW201233103A/en unknown
- 2011-12-12 EP EP11808991.1A patent/EP2659614A1/en not_active Withdrawn
- 2011-12-12 WO PCT/US2011/064328 patent/WO2012096740A1/en active Application Filing
-
2016
- 2016-04-06 US US15/092,165 patent/US10250618B2/en active Active
Patent Citations (14)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20030229809A1 (en) * | 1999-04-15 | 2003-12-11 | Asaf Wexler | Transparent proxy server |
US20060112176A1 (en) * | 2000-07-19 | 2006-05-25 | Liu Zaide E | Domain name resolution using a distributed DNS network |
US20040158766A1 (en) * | 2002-09-09 | 2004-08-12 | John Liccione | System and method for application monitoring and automatic disaster recovery for high-availability |
US20120008567A1 (en) * | 2003-09-12 | 2012-01-12 | Jochen Eisl | Reachability maintenance of a moving network based on temporary name identifiers |
US20050235358A1 (en) * | 2004-04-15 | 2005-10-20 | International Business Machines Corporation | Server denial of service shield |
US20060107318A1 (en) * | 2004-09-14 | 2006-05-18 | International Business Machines Corporation | Detection of grid participation in a DDoS attack |
US8346960B2 (en) * | 2005-02-15 | 2013-01-01 | At&T Intellectual Property Ii, L.P. | Systems, methods, and devices for defending a network |
US20060206922A1 (en) * | 2005-03-08 | 2006-09-14 | Securedatainnovations Ag | Secure Remote Access To Non-Public Private Web Servers |
US7620733B1 (en) * | 2005-03-30 | 2009-11-17 | Cisco Technology, Inc. | DNS anti-spoofing using UDP |
US20070022474A1 (en) * | 2005-07-21 | 2007-01-25 | Mistletoe Technologies, Inc. | Portable firewall |
US20070083670A1 (en) * | 2005-10-11 | 2007-04-12 | International Business Machines Corporation | Method and system for protecting an internet user from fraudulent ip addresses on a dns server |
US20070118894A1 (en) * | 2005-11-23 | 2007-05-24 | Nextone Communications, Inc. | Method for responding to denial of service attacks at the session layer or above |
US20080159299A1 (en) * | 2006-12-29 | 2008-07-03 | Tian Bu | Methods and systems for providing controlled access to the internet |
US20090144806A1 (en) * | 2007-12-03 | 2009-06-04 | Cisco Technology, Inc. | Handling of DDoS attacks from NAT or proxy devices |
Cited By (384)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US10567405B1 (en) | 2004-04-01 | 2020-02-18 | Fireeye, Inc. | System for detecting a presence of malware from behavioral analysis |
US10027690B2 (en) | 2004-04-01 | 2018-07-17 | Fireeye, Inc. | Electronic message analysis for malware detection |
US10068091B1 (en) | 2004-04-01 | 2018-09-04 | Fireeye, Inc. | System and method for malware containment |
US10623434B1 (en) | 2004-04-01 | 2020-04-14 | Fireeye, Inc. | System and method for virtual analysis of network data |
US10165000B1 (en) | 2004-04-01 | 2018-12-25 | Fireeye, Inc. | Systems and methods for malware attack prevention by intercepting flows of information |
US9628498B1 (en) | 2004-04-01 | 2017-04-18 | Fireeye, Inc. | System and method for bot detection |
US9838411B1 (en) | 2004-04-01 | 2017-12-05 | Fireeye, Inc. | Subscriber based protection system |
US11082435B1 (en) | 2004-04-01 | 2021-08-03 | Fireeye, Inc. | System and method for threat detection and identification |
US10284574B1 (en) | 2004-04-01 | 2019-05-07 | Fireeye, Inc. | System and method for threat detection and identification |
US10587636B1 (en) | 2004-04-01 | 2020-03-10 | Fireeye, Inc. | System and method for bot detection |
US9591020B1 (en) | 2004-04-01 | 2017-03-07 | Fireeye, Inc. | System and method for signature generation |
US10511614B1 (en) | 2004-04-01 | 2019-12-17 | Fireeye, Inc. | Subscription based malware detection under management system control |
US9516057B2 (en) | 2004-04-01 | 2016-12-06 | Fireeye, Inc. | Systems and methods for computer worm defense |
US11153341B1 (en) | 2004-04-01 | 2021-10-19 | Fireeye, Inc. | System and method for detecting malicious network content using virtual environment components |
US9912684B1 (en) | 2004-04-01 | 2018-03-06 | Fireeye, Inc. | System and method for virtual analysis of network data |
US9282109B1 (en) | 2004-04-01 | 2016-03-08 | Fireeye, Inc. | System and method for analyzing packets |
US9661018B1 (en) | 2004-04-01 | 2017-05-23 | Fireeye, Inc. | System and method for detecting anomalous behaviors using a virtual machine environment |
US11637857B1 (en) | 2004-04-01 | 2023-04-25 | Fireeye Security Holdings Us Llc | System and method for detecting malicious traffic using a virtual machine configured with a select software environment |
US10757120B1 (en) | 2004-04-01 | 2020-08-25 | Fireeye, Inc. | Malicious network content detection |
US9306960B1 (en) | 2004-04-01 | 2016-04-05 | Fireeye, Inc. | Systems and methods for unauthorized activity defense |
US10097573B1 (en) | 2004-04-01 | 2018-10-09 | Fireeye, Inc. | Systems and methods for malware defense |
US9838416B1 (en) | 2004-06-14 | 2017-12-05 | Fireeye, Inc. | System and method of detecting malicious content |
US8997219B2 (en) | 2008-11-03 | 2015-03-31 | Fireeye, Inc. | Systems and methods for detecting malicious PDF network content |
US9118715B2 (en) | 2008-11-03 | 2015-08-25 | Fireeye, Inc. | Systems and methods for detecting malicious PDF network content |
US9438622B1 (en) | 2008-11-03 | 2016-09-06 | Fireeye, Inc. | Systems and methods for analyzing malicious PDF network content |
US9954890B1 (en) | 2008-11-03 | 2018-04-24 | Fireeye, Inc. | Systems and methods for analyzing PDF documents |
US10157280B2 (en) | 2009-09-23 | 2018-12-18 | F5 Networks, Inc. | System and method for identifying security breach attempts of a website |
US11381578B1 (en) | 2009-09-30 | 2022-07-05 | Fireeye Security Holdings Us Llc | Network-based binary file extraction and analysis for malware detection |
US9286331B2 (en) | 2010-05-06 | 2016-03-15 | Go Daddy Operating Company, LLC | Verifying and balancing server resources via stored usage data |
US9742799B2 (en) | 2010-12-30 | 2017-08-22 | Verisign, Inc. | Client-side active validation for mitigating DDOS attacks |
US9473530B2 (en) | 2010-12-30 | 2016-10-18 | Verisign, Inc. | Client-side active validation for mitigating DDOS attacks |
US9374350B2 (en) * | 2011-03-10 | 2016-06-21 | Samsung Electronics Co., Ltd. | Authenticating method of communicating connection, gateway apparatus using authenticating method, and communication system using authenticating method |
US20120233468A1 (en) * | 2011-03-10 | 2012-09-13 | Samsung Electronics Co., Ltd. | Authenticating method of communicating connection, gateway apparatus using authenticating method, and communication system using authenticating method |
US9060038B2 (en) * | 2011-05-16 | 2015-06-16 | At&T Intellectual Property I, L.P. | Dynamic domain name server console for disaster recovery server management |
US20120297197A1 (en) * | 2011-05-16 | 2012-11-22 | Norman Yale | Dynamic Domain Name Server Console for Disaster Recovery Server Management |
US20140373138A1 (en) * | 2011-06-27 | 2014-12-18 | Ahnlab, Inc. | Method and apparatus for preventing distributed denial of service attack |
US20130007882A1 (en) * | 2011-06-28 | 2013-01-03 | The Go Daddy Group, Inc. | Methods of detecting and removing bidirectional network traffic malware |
US20130007870A1 (en) * | 2011-06-28 | 2013-01-03 | The Go Daddy Group, Inc. | Systems for bi-directional network traffic malware detection and removal |
US10931465B2 (en) | 2011-07-28 | 2021-02-23 | Cloudflare, Inc. | Supporting secure sessions in a cloud-based proxy service |
US11546175B2 (en) | 2011-07-28 | 2023-01-03 | Cloudflare, Inc. | Detecting and isolating an attack directed at an IP address associated with a digital certificate bound with multiple domains |
US9600652B2 (en) | 2011-09-29 | 2017-03-21 | Oracle International Corporation | Mobile application, identity interface |
US20130086211A1 (en) * | 2011-09-29 | 2013-04-04 | Oracle International Corporation | Mobile application, resource management advice |
US9081951B2 (en) | 2011-09-29 | 2015-07-14 | Oracle International Corporation | Mobile application, identity interface |
US10325089B2 (en) * | 2011-09-29 | 2019-06-18 | Oracle International Corporation | Mobile application, resource management advice |
US9965614B2 (en) * | 2011-09-29 | 2018-05-08 | Oracle International Corporation | Mobile application, resource management advice |
US9495533B2 (en) | 2011-09-29 | 2016-11-15 | Oracle International Corporation | Mobile application, identity relationship management |
US10621329B2 (en) * | 2011-09-29 | 2020-04-14 | Oracle International Corporation | Mobile application, resource management advice |
US9088581B2 (en) | 2012-01-24 | 2015-07-21 | L-3 Communications Corporation | Methods and apparatus for authenticating an assertion of a source |
US8677489B2 (en) * | 2012-01-24 | 2014-03-18 | L3 Communications Corporation | Methods and apparatus for managing network traffic |
US10044582B2 (en) | 2012-01-28 | 2018-08-07 | A10 Networks, Inc. | Generating secure name records |
US8832831B2 (en) * | 2012-03-21 | 2014-09-09 | Radware, Ltd. | Method and system for detecting and mitigating attacks performed using cryptographic protocols |
US20140373143A1 (en) * | 2012-03-21 | 2014-12-18 | Radware, Ltd. | Method and system for detecting and mitigating attacks performed using cryptographic protocols |
US9674209B2 (en) | 2012-03-21 | 2017-06-06 | Radware Ltd. | Method and system for detecting and mitigating attacks performed using cryptographic protocols |
US20130254879A1 (en) * | 2012-03-21 | 2013-09-26 | Radware, Ltd. | Method and system for detecting and mitigating attacks performed using cryptographic protocols |
US9344448B2 (en) * | 2012-03-21 | 2016-05-17 | Radware, Ltd. | Method and system for detecting and mitigating attacks performed using cryptographic protocols |
US20140067996A1 (en) * | 2012-08-30 | 2014-03-06 | Yahoo! Inc. | Method and system for reducing network latency |
US9363240B2 (en) * | 2012-08-30 | 2016-06-07 | Excalibur Ip, Llc | Method and system for reducing network latency |
US20140068761A1 (en) * | 2012-09-06 | 2014-03-06 | Microsoft Corporation | Abuse identification of front-end based services |
US20140082204A1 (en) * | 2012-09-20 | 2014-03-20 | Cisco Technology, Inc. | Seamless Engagement and Disengagement of Transport Layer Security Proxy Services |
US9124628B2 (en) * | 2012-09-20 | 2015-09-01 | Cisco Technology, Inc. | Seamless engagement and disengagement of transport layer security proxy services |
US9218428B2 (en) * | 2012-10-15 | 2015-12-22 | Dell Products, L.P. | Techniques for generating different sessions for multiple tabs of a single browser window |
US20140108667A1 (en) * | 2012-10-15 | 2014-04-17 | Dell Products L.P. | Techniques for Generating Different Sessions for Multiple Tabs of a Single Browser Window |
US10572665B2 (en) | 2012-12-28 | 2020-02-25 | Fireeye, Inc. | System and method to create a number of breakpoints in a virtual machine via virtual machine trapping events |
US20140208194A1 (en) * | 2013-01-22 | 2014-07-24 | Michael O'Leary | Device and system for securely executing electronic documents |
US9367681B1 (en) | 2013-02-23 | 2016-06-14 | Fireeye, Inc. | Framework for efficient security coverage of mobile software applications using symbolic execution to reach regions of interest within an application |
US9176843B1 (en) | 2013-02-23 | 2015-11-03 | Fireeye, Inc. | Framework for efficient security coverage of mobile software applications |
US10929266B1 (en) | 2013-02-23 | 2021-02-23 | Fireeye, Inc. | Real-time visual playback with synchronous textual analysis log display and event/time indexing |
US9009823B1 (en) | 2013-02-23 | 2015-04-14 | Fireeye, Inc. | Framework for efficient security coverage of mobile software applications installed on mobile devices |
US10296437B2 (en) | 2013-02-23 | 2019-05-21 | Fireeye, Inc. | Framework for efficient security coverage of mobile software applications |
US9225740B1 (en) | 2013-02-23 | 2015-12-29 | Fireeye, Inc. | Framework for iterative analysis of mobile software applications |
US9792196B1 (en) | 2013-02-23 | 2017-10-17 | Fireeye, Inc. | Framework for efficient security coverage of mobile software applications |
US8990944B1 (en) * | 2013-02-23 | 2015-03-24 | Fireeye, Inc. | Systems and methods for automatically detecting backdoors |
US11546309B2 (en) | 2013-03-07 | 2023-01-03 | Cloudflare, Inc. | Secure session capability using public-key cryptography without access to the private key |
US20190097983A1 (en) * | 2013-03-07 | 2019-03-28 | Cloudflare, Inc. | Secure session capability using public-key cryptography without access to the private key |
US10785198B2 (en) * | 2013-03-07 | 2020-09-22 | Cloudflare, Inc. | Secure session capability using public-key cryptography without access to the private key |
US10025927B1 (en) | 2013-03-13 | 2018-07-17 | Fireeye, Inc. | Malicious content analysis with multi-version application support within single operating environment |
US10848521B1 (en) | 2013-03-13 | 2020-11-24 | Fireeye, Inc. | Malicious content analysis using simulated user interaction without user involvement |
US9626509B1 (en) | 2013-03-13 | 2017-04-18 | Fireeye, Inc. | Malicious content analysis with multi-version application support within single operating environment |
US10198574B1 (en) | 2013-03-13 | 2019-02-05 | Fireeye, Inc. | System and method for analysis of a memory dump associated with a potentially malicious content suspect |
US9355247B1 (en) | 2013-03-13 | 2016-05-31 | Fireeye, Inc. | File extraction from memory dump for malicious content analysis |
US11210390B1 (en) | 2013-03-13 | 2021-12-28 | Fireeye Security Holdings Us Llc | Multi-version application support and registration within a single operating system environment |
US10200384B1 (en) | 2013-03-14 | 2019-02-05 | Fireeye, Inc. | Distributed systems and methods for automatically detecting unknown bots and botnets |
US10122746B1 (en) | 2013-03-14 | 2018-11-06 | Fireeye, Inc. | Correlation and consolidation of analytic data for holistic view of malware attack |
US20140281510A1 (en) * | 2013-03-14 | 2014-09-18 | Shivakumar Buruganahalli | Decryption of data between a client and a server |
US9311479B1 (en) | 2013-03-14 | 2016-04-12 | Fireeye, Inc. | Correlation and consolidation of analytic data for holistic view of a malware attack |
US10812513B1 (en) | 2013-03-14 | 2020-10-20 | Fireeye, Inc. | Correlation and consolidation holistic views of analytic data pertaining to a malware attack |
US9641546B1 (en) | 2013-03-14 | 2017-05-02 | Fireeye, Inc. | Electronic device for aggregation, correlation and consolidation of analysis attributes |
US9430646B1 (en) | 2013-03-14 | 2016-08-30 | Fireeye, Inc. | Distributed systems and methods for automatically detecting unknown bots and botnets |
US10079838B2 (en) * | 2013-03-14 | 2018-09-18 | Mcafee, Llc | Decryption of data between a client and a server |
US10713358B2 (en) | 2013-03-15 | 2020-07-14 | Fireeye, Inc. | System and method to extract and utilize disassembly features to classify software intent |
US9912555B2 (en) | 2013-03-15 | 2018-03-06 | A10 Networks, Inc. | System and method of updating modules for application or content identification |
US10708150B2 (en) | 2013-03-15 | 2020-07-07 | A10 Networks, Inc. | System and method of updating modules for application or content identification |
US10594600B2 (en) | 2013-03-15 | 2020-03-17 | A10 Networks, Inc. | System and method for customizing the identification of application or content type |
US10701091B1 (en) | 2013-03-15 | 2020-06-30 | Fireeye, Inc. | System and method for verifying a cyberthreat |
US9614868B2 (en) | 2013-03-15 | 2017-04-04 | Robert Bosch Gmbh | System and method for mitigation of denial of service attacks in networked computing systems |
US9722918B2 (en) | 2013-03-15 | 2017-08-01 | A10 Networks, Inc. | System and method for customizing the identification of application or content type |
WO2014144555A1 (en) * | 2013-03-15 | 2014-09-18 | Robert Bosch Gmbh | System and method for mitigation of denial of service attacks in networked computing systems |
US9838425B2 (en) | 2013-04-25 | 2017-12-05 | A10 Networks, Inc. | Systems and methods for network access control |
WO2014176461A1 (en) * | 2013-04-25 | 2014-10-30 | A10 Networks, Inc. | Systems and methods for network access control |
US10091237B2 (en) | 2013-04-25 | 2018-10-02 | A10 Networks, Inc. | Systems and methods for network access control |
US10581907B2 (en) | 2013-04-25 | 2020-03-03 | A10 Networks, Inc. | Systems and methods for network access control |
US9495180B2 (en) | 2013-05-10 | 2016-11-15 | Fireeye, Inc. | Optimized resource allocation for virtual machines within a malware content detection system |
US10469512B1 (en) | 2013-05-10 | 2019-11-05 | Fireeye, Inc. | Optimized resource allocation for virtual machines within a malware content detection system |
US10637880B1 (en) | 2013-05-13 | 2020-04-28 | Fireeye, Inc. | Classifying sets of malicious indicators for detecting command and control communications associated with malware |
US9521138B2 (en) | 2013-06-14 | 2016-12-13 | Go Daddy Operating Company, LLC | System for domain control validation |
US9178888B2 (en) | 2013-06-14 | 2015-11-03 | Go Daddy Operating Company, LLC | Method for domain control validation |
US20140373140A1 (en) * | 2013-06-18 | 2014-12-18 | Level 3 Communications, Llc | Data center redundancy in a network |
US10785257B2 (en) | 2013-06-18 | 2020-09-22 | Level 3 Communications, Llc | Data center redundancy in a network |
US10038714B2 (en) * | 2013-06-18 | 2018-07-31 | Level 3 Communications, Llc | Data center redundancy in a network |
US10133863B2 (en) | 2013-06-24 | 2018-11-20 | Fireeye, Inc. | Zero-day discovery system |
US10505956B1 (en) | 2013-06-28 | 2019-12-10 | Fireeye, Inc. | System and method for detecting malicious links in electronic messages |
US9300686B2 (en) | 2013-06-28 | 2016-03-29 | Fireeye, Inc. | System and method for detecting malicious links in electronic messages |
US9888019B1 (en) | 2013-06-28 | 2018-02-06 | Fireeye, Inc. | System and method for detecting malicious links in electronic messages |
US9141789B1 (en) | 2013-07-16 | 2015-09-22 | Go Daddy Operating Company, LLC | Mitigating denial of service attacks |
US20200358827A1 (en) * | 2013-07-23 | 2020-11-12 | Zscaler, Inc. | Cloud based security using DNS |
US9621517B2 (en) | 2013-08-14 | 2017-04-11 | Iboss, Inc. | Selectively performing man in the middle decryption |
US20150381570A1 (en) * | 2013-08-14 | 2015-12-31 | Iboss, Inc. | Selectively performing man in the middle decryption |
US9853943B2 (en) * | 2013-08-14 | 2017-12-26 | Iboss, Inc. | Selectively performing man in the middle decryption |
US9294503B2 (en) | 2013-08-26 | 2016-03-22 | A10 Networks, Inc. | Health monitor based distributed denial of service attack mitigation |
US10187423B2 (en) | 2013-08-26 | 2019-01-22 | A10 Networks, Inc. | Health monitor based distributed denial of service attack mitigation |
US9860271B2 (en) | 2013-08-26 | 2018-01-02 | A10 Networks, Inc. | Health monitor based distributed denial of service attack mitigation |
US20150089566A1 (en) * | 2013-09-24 | 2015-03-26 | Radware, Ltd. | Escalation security method for use in software defined networks |
US9294501B2 (en) | 2013-09-30 | 2016-03-22 | Fireeye, Inc. | Fuzzy hash of behavioral results |
US11075945B2 (en) | 2013-09-30 | 2021-07-27 | Fireeye, Inc. | System, apparatus and method for reconfiguring virtual machines |
US10515214B1 (en) | 2013-09-30 | 2019-12-24 | Fireeye, Inc. | System and method for classifying malware within content created during analysis of a specimen |
US10218740B1 (en) | 2013-09-30 | 2019-02-26 | Fireeye, Inc. | Fuzzy hash of behavioral results |
US9912691B2 (en) | 2013-09-30 | 2018-03-06 | Fireeye, Inc. | Fuzzy hash of behavioral results |
US9628507B2 (en) | 2013-09-30 | 2017-04-18 | Fireeye, Inc. | Advanced persistent threat (APT) detection center |
US9910988B1 (en) | 2013-09-30 | 2018-03-06 | Fireeye, Inc. | Malware analysis in accordance with an analysis plan |
US9736179B2 (en) | 2013-09-30 | 2017-08-15 | Fireeye, Inc. | System, apparatus and method for using malware analysis results to drive adaptive instrumentation of virtual machines to improve exploit detection |
US9690936B1 (en) | 2013-09-30 | 2017-06-27 | Fireeye, Inc. | Multistage system and method for analyzing obfuscated content for malware |
US10735458B1 (en) | 2013-09-30 | 2020-08-04 | Fireeye, Inc. | Detection center to detect targeted malware |
US10657251B1 (en) | 2013-09-30 | 2020-05-19 | Fireeye, Inc. | Multistage system and method for analyzing obfuscated content for malware |
US10713362B1 (en) | 2013-09-30 | 2020-07-14 | Fireeye, Inc. | Dynamically adaptive framework and method for classifying malware using intelligent static, emulation, and dynamic analyses |
US20150113589A1 (en) * | 2013-10-01 | 2015-04-23 | Robert K. Lemaster | Authentication server enhancements |
US9578005B2 (en) * | 2013-10-01 | 2017-02-21 | Robert K Lemaster | Authentication server enhancements |
US9921978B1 (en) | 2013-11-08 | 2018-03-20 | Fireeye, Inc. | System and method for enhanced security of storage devices |
US9306974B1 (en) | 2013-12-26 | 2016-04-05 | Fireeye, Inc. | System, apparatus and method for automatically verifying exploits within suspect objects and highlighting the display information associated with the verified exploits |
US10476909B1 (en) | 2013-12-26 | 2019-11-12 | Fireeye, Inc. | System, apparatus and method for automatically verifying exploits within suspect objects and highlighting the display information associated with the verified exploits |
US10467411B1 (en) | 2013-12-26 | 2019-11-05 | Fireeye, Inc. | System and method for generating a malware identifier |
US11089057B1 (en) | 2013-12-26 | 2021-08-10 | Fireeye, Inc. | System, apparatus and method for automatically verifying exploits within suspect objects and highlighting the display information associated with the verified exploits |
US9747446B1 (en) | 2013-12-26 | 2017-08-29 | Fireeye, Inc. | System and method for run-time object classification |
US9756074B2 (en) | 2013-12-26 | 2017-09-05 | Fireeye, Inc. | System and method for IPS and VM-based detection of suspicious objects |
US10740456B1 (en) | 2014-01-16 | 2020-08-11 | Fireeye, Inc. | Threat-aware architecture |
US9262635B2 (en) | 2014-02-05 | 2016-02-16 | Fireeye, Inc. | Detection efficacy of virtual machine-based analysis with application specific events |
US9916440B1 (en) | 2014-02-05 | 2018-03-13 | Fireeye, Inc. | Detection efficacy of virtual machine-based analysis with application specific events |
US10534906B1 (en) | 2014-02-05 | 2020-01-14 | Fireeye, Inc. | Detection efficacy of virtual machine-based analysis with application specific events |
US10432649B1 (en) | 2014-03-20 | 2019-10-01 | Fireeye, Inc. | System and method for classifying an object based on an aggregated behavior results |
US11068587B1 (en) | 2014-03-21 | 2021-07-20 | Fireeye, Inc. | Dynamic guest image creation and rollback |
US10242185B1 (en) | 2014-03-21 | 2019-03-26 | Fireeye, Inc. | Dynamic guest image creation and rollback |
US9787700B1 (en) | 2014-03-28 | 2017-10-10 | Fireeye, Inc. | System and method for offloading packet processing and static analysis operations |
US10454953B1 (en) | 2014-03-28 | 2019-10-22 | Fireeye, Inc. | System and method for separated packet processing and static analysis |
US9591015B1 (en) | 2014-03-28 | 2017-03-07 | Fireeye, Inc. | System and method for offloading packet processing and static analysis operations |
US11082436B1 (en) | 2014-03-28 | 2021-08-03 | Fireeye, Inc. | System and method for offloading packet processing and static analysis operations |
US9432389B1 (en) | 2014-03-31 | 2016-08-30 | Fireeye, Inc. | System, apparatus and method for detecting a malicious attack based on static analysis of a multi-flow object |
US11297074B1 (en) | 2014-03-31 | 2022-04-05 | FireEye Security Holdings, Inc. | Dynamically remote tuning of a malware content detection system |
US10341363B1 (en) | 2014-03-31 | 2019-07-02 | Fireeye, Inc. | Dynamically remote tuning of a malware content detection system |
US11949698B1 (en) | 2014-03-31 | 2024-04-02 | Musarubra Us Llc | Dynamically remote tuning of a malware content detection system |
US9223972B1 (en) | 2014-03-31 | 2015-12-29 | Fireeye, Inc. | Dynamically remote tuning of a malware content detection system |
WO2015153849A1 (en) * | 2014-04-03 | 2015-10-08 | Automattic, Inc. | Systems and methods for protecting websites from botnet attacks |
US11438178B2 (en) | 2014-04-08 | 2022-09-06 | Cloudflare, Inc. | Secure session capability using public-key cryptography without access to the private key |
US11044083B2 (en) | 2014-04-08 | 2021-06-22 | Cloudflare, Inc. | Secure session capability using public-key cryptography without access to the private key |
US10686683B2 (en) | 2014-05-16 | 2020-06-16 | A10 Networks, Inc. | Distributed system to determine a server's health |
US9906422B2 (en) | 2014-05-16 | 2018-02-27 | A10 Networks, Inc. | Distributed system to determine a server's health |
US11361098B2 (en) | 2014-05-21 | 2022-06-14 | Crypteron, Inc. | Systems and methods for front-end and back-end data security protocols |
US20150339486A1 (en) * | 2014-05-21 | 2015-11-26 | Siddharth Shetye | Systems and methods for front-end and back-end data security protocols |
US10152605B2 (en) * | 2014-05-21 | 2018-12-11 | Siddharth Shetye | Systems and methods for front-end and back-end data security protocols |
US9594912B1 (en) | 2014-06-06 | 2017-03-14 | Fireeye, Inc. | Return-oriented programming detection |
US9973531B1 (en) | 2014-06-06 | 2018-05-15 | Fireeye, Inc. | Shellcode detection |
US9438623B1 (en) | 2014-06-06 | 2016-09-06 | Fireeye, Inc. | Computer exploit detection using heap spray pattern matching |
US10469465B2 (en) | 2014-06-23 | 2019-11-05 | Vmware, Inc. | Cryptographic proxy service |
US20150372994A1 (en) * | 2014-06-23 | 2015-12-24 | Airwatch Llc | Cryptographic Proxy Service |
US11075893B2 (en) | 2014-06-23 | 2021-07-27 | Vmware, Inc. | Cryptographic proxy service |
US9584492B2 (en) * | 2014-06-23 | 2017-02-28 | Vmware, Inc. | Cryptographic proxy service |
US10084813B2 (en) | 2014-06-24 | 2018-09-25 | Fireeye, Inc. | Intrusion prevention and remedy system |
US10757134B1 (en) | 2014-06-24 | 2020-08-25 | Fireeye, Inc. | System and method for detecting and remediating a cybersecurity attack |
US9838408B1 (en) | 2014-06-26 | 2017-12-05 | Fireeye, Inc. | System, device and method for detecting a malicious attack based on direct communications between remotely hosted virtual machines and malicious web servers |
US9661009B1 (en) | 2014-06-26 | 2017-05-23 | Fireeye, Inc. | Network-based malware detection |
US10805340B1 (en) | 2014-06-26 | 2020-10-13 | Fireeye, Inc. | Infection vector and malware tracking with an interactive user display |
US9398028B1 (en) | 2014-06-26 | 2016-07-19 | Fireeye, Inc. | System, device and method for detecting a malicious attack based on communcations between remotely hosted virtual machines and malicious web servers |
US11244056B1 (en) | 2014-07-01 | 2022-02-08 | Fireeye Security Holdings Us Llc | Verification of trusted threat-aware visualization layer |
US10404725B1 (en) | 2014-08-22 | 2019-09-03 | Fireeye, Inc. | System and method of detecting delivery of malware using cross-customer data |
US9609007B1 (en) | 2014-08-22 | 2017-03-28 | Fireeye, Inc. | System and method of detecting delivery of malware based on indicators of compromise from different sources |
US9363280B1 (en) | 2014-08-22 | 2016-06-07 | Fireeye, Inc. | System and method of detecting delivery of malware using cross-customer data |
US10027696B1 (en) | 2014-08-22 | 2018-07-17 | Fireeye, Inc. | System and method for determining a threat based on correlation of indicators of compromise from other sources |
US9756071B1 (en) | 2014-09-16 | 2017-09-05 | A10 Networks, Inc. | DNS denial of service attack protection |
US10671726B1 (en) | 2014-09-22 | 2020-06-02 | Fireeye Inc. | System and method for malware analysis using thread-level event monitoring |
US9773112B1 (en) | 2014-09-29 | 2017-09-26 | Fireeye, Inc. | Exploit detection of malware and malware families |
US10027689B1 (en) | 2014-09-29 | 2018-07-17 | Fireeye, Inc. | Interactive infection visualization for improved exploit detection and signature generation for malware and malware families |
US10868818B1 (en) | 2014-09-29 | 2020-12-15 | Fireeye, Inc. | Systems and methods for generation of signature generation using interactive infection visualizations |
US9537886B1 (en) | 2014-10-23 | 2017-01-03 | A10 Networks, Inc. | Flagging security threats in web service requests |
US9854000B2 (en) * | 2014-11-06 | 2017-12-26 | Cisco Technology, Inc. | Method and apparatus for detecting malicious software using handshake information |
US10366231B1 (en) | 2014-12-22 | 2019-07-30 | Fireeye, Inc. | Framework for classifying an object as malicious with machine learning for deploying updated predictive models |
US10902117B1 (en) | 2014-12-22 | 2021-01-26 | Fireeye, Inc. | Framework for classifying an object as malicious with machine learning for deploying updated predictive models |
US9690933B1 (en) | 2014-12-22 | 2017-06-27 | Fireeye, Inc. | Framework for classifying an object as malicious with machine learning for deploying updated predictive models |
US10075455B2 (en) | 2014-12-26 | 2018-09-11 | Fireeye, Inc. | Zero-day rotating guest image profile |
US9621575B1 (en) | 2014-12-29 | 2017-04-11 | A10 Networks, Inc. | Context aware threat protection |
US10528726B1 (en) | 2014-12-29 | 2020-01-07 | Fireeye, Inc. | Microvisor-based malware detection appliance architecture |
US10505964B2 (en) | 2014-12-29 | 2019-12-10 | A10 Networks, Inc. | Context aware threat protection |
US9584318B1 (en) * | 2014-12-30 | 2017-02-28 | A10 Networks, Inc. | Perfect forward secrecy distributed denial of service attack defense |
US10798121B1 (en) | 2014-12-30 | 2020-10-06 | Fireeye, Inc. | Intelligent context aware user interaction for malware detection |
US9838417B1 (en) | 2014-12-30 | 2017-12-05 | Fireeye, Inc. | Intelligent context aware user interaction for malware detection |
US9838423B2 (en) * | 2014-12-30 | 2017-12-05 | A10 Networks, Inc. | Perfect forward secrecy distributed denial of service attack defense |
US20170142153A1 (en) * | 2014-12-30 | 2017-05-18 | A10 Networks, Inc. | Perfect Forward Secrecy Distributed Denial of Service Attack Defense |
US9900343B1 (en) | 2015-01-05 | 2018-02-20 | A10 Networks, Inc. | Distributed denial of service cellular signaling |
US9848013B1 (en) * | 2015-02-05 | 2017-12-19 | A10 Networks, Inc. | Perfect forward secrecy distributed denial of service attack detection |
US20170366636A1 (en) * | 2015-02-13 | 2017-12-21 | Huawei Technologies Co., Ltd. | Redirection method, apparatus, and system |
US10721320B2 (en) * | 2015-02-13 | 2020-07-21 | Huawei Technologies Co., Ltd. | Redirection method, apparatus, and system |
US10834132B2 (en) | 2015-02-14 | 2020-11-10 | A10 Networks, Inc. | Implementing and optimizing secure socket layer intercept |
US10063591B1 (en) | 2015-02-14 | 2018-08-28 | A10 Networks, Inc. | Implementing and optimizing secure socket layer intercept |
US10454899B1 (en) * | 2015-03-16 | 2019-10-22 | Amazon Technologies, Inc. | Controlling firewall ports in virtualized environments through public key cryptography |
US10666686B1 (en) | 2015-03-25 | 2020-05-26 | Fireeye, Inc. | Virtualized exploit detection system |
US10148693B2 (en) | 2015-03-25 | 2018-12-04 | Fireeye, Inc. | Exploit detection system |
US9690606B1 (en) | 2015-03-25 | 2017-06-27 | Fireeye, Inc. | Selective system call monitoring |
US9438613B1 (en) | 2015-03-30 | 2016-09-06 | Fireeye, Inc. | Dynamic content activation for automated analysis of embedded objects |
US10474813B1 (en) | 2015-03-31 | 2019-11-12 | Fireeye, Inc. | Code injection technique for remediation at an endpoint of a network |
US9483644B1 (en) | 2015-03-31 | 2016-11-01 | Fireeye, Inc. | Methods for detecting file altering malware in VM based analysis |
US9846776B1 (en) | 2015-03-31 | 2017-12-19 | Fireeye, Inc. | System and method for detecting file altering behaviors pertaining to a malicious attack |
US11868795B1 (en) | 2015-03-31 | 2024-01-09 | Musarubra Us Llc | Selective virtualization for security threat detection |
US11294705B1 (en) | 2015-03-31 | 2022-04-05 | Fireeye Security Holdings Us Llc | Selective virtualization for security threat detection |
US10417031B2 (en) | 2015-03-31 | 2019-09-17 | Fireeye, Inc. | Selective virtualization for security threat detection |
US10728263B1 (en) | 2015-04-13 | 2020-07-28 | Fireeye, Inc. | Analytic-based security monitoring system and method |
US9594904B1 (en) | 2015-04-23 | 2017-03-14 | Fireeye, Inc. | Detecting malware based on reflection |
US10999245B2 (en) | 2015-06-01 | 2021-05-04 | Ntt Communications Corporation | Communication path control method, communication path control device, and communication path control program that divide a path leading to a network that accommodates a specific device into a path that passes through a filter device and a path that does not pass through a filter device |
JP5977860B1 (en) * | 2015-06-01 | 2016-08-24 | エヌ・ティ・ティ・コミュニケーションズ株式会社 | COMMUNICATION CONTROL METHOD, COMMUNICATION CONTROL DEVICE, AND PROGRAM |
US10454950B1 (en) | 2015-06-30 | 2019-10-22 | Fireeye, Inc. | Centralized aggregation technique for detecting lateral movement of stealthy cyber-attacks |
US11113086B1 (en) | 2015-06-30 | 2021-09-07 | Fireeye, Inc. | Virtual system and method for securing external network connectivity |
US10726127B1 (en) | 2015-06-30 | 2020-07-28 | Fireeye, Inc. | System and method for protecting a software component running in a virtual machine through virtual interrupts by the virtualization layer |
US10642753B1 (en) | 2015-06-30 | 2020-05-05 | Fireeye, Inc. | System and method for protecting a software component running in virtual machine using a virtualization layer |
US10715542B1 (en) | 2015-08-14 | 2020-07-14 | Fireeye, Inc. | Mobile application risk analysis |
US11082403B2 (en) * | 2015-09-10 | 2021-08-03 | Openwave Mobility Inc. | Intermediate network entity |
EP3142327A1 (en) * | 2015-09-10 | 2017-03-15 | Openwave Mobility, Inc. | Intermediate network entity |
US20170078328A1 (en) * | 2015-09-10 | 2017-03-16 | Openwave Mobility Inc. | Intermediate network entity |
GB2542175B (en) * | 2015-09-10 | 2019-12-04 | Openwave Mobility Inc | Intermediate network entity |
US9787581B2 (en) | 2015-09-21 | 2017-10-10 | A10 Networks, Inc. | Secure data flow open information analytics |
US10176321B2 (en) | 2015-09-22 | 2019-01-08 | Fireeye, Inc. | Leveraging behavior-based rules for malware family classification |
US10887328B1 (en) | 2015-09-29 | 2021-01-05 | Fireeye, Inc. | System and method for detecting interpreter-based exploit attacks |
US10033747B1 (en) | 2015-09-29 | 2018-07-24 | Fireeye, Inc. | System and method for detecting interpreter-based exploit attacks |
US11244044B1 (en) | 2015-09-30 | 2022-02-08 | Fireeye Security Holdings Us Llc | Method to detect application execution hijacking using memory protection |
US10817606B1 (en) | 2015-09-30 | 2020-10-27 | Fireeye, Inc. | Detecting delayed activation malware using a run-time monitoring agent and time-dilation logic |
US10873597B1 (en) | 2015-09-30 | 2020-12-22 | Fireeye, Inc. | Cyber attack early warning system |
US9825989B1 (en) | 2015-09-30 | 2017-11-21 | Fireeye, Inc. | Cyber attack early warning system |
US9825976B1 (en) | 2015-09-30 | 2017-11-21 | Fireeye, Inc. | Detection and classification of exploit kits |
US10601865B1 (en) | 2015-09-30 | 2020-03-24 | Fireeye, Inc. | Detection of credential spearphishing attacks using email analysis |
US10210329B1 (en) | 2015-09-30 | 2019-02-19 | Fireeye, Inc. | Method to detect application execution hijacking using memory protection |
US10706149B1 (en) | 2015-09-30 | 2020-07-07 | Fireeye, Inc. | Detecting delayed activation malware using a primary controller and plural time controllers |
US10250573B2 (en) | 2015-10-02 | 2019-04-02 | Amazon Technologies, Inc. | Leveraging transport-layer cryptographic material |
US9781081B1 (en) * | 2015-10-02 | 2017-10-03 | Amazon Technologies, Inc. | Leveraging transport-layer cryptographic material |
US10284575B2 (en) | 2015-11-10 | 2019-05-07 | Fireeye, Inc. | Launcher for setting analysis environment variations for malware detection |
US10834107B1 (en) | 2015-11-10 | 2020-11-10 | Fireeye, Inc. | Launcher for setting analysis environment variations for malware detection |
US10505984B2 (en) | 2015-12-08 | 2019-12-10 | A10 Networks, Inc. | Exchange of control information between secure socket layer gateways |
US10469594B2 (en) | 2015-12-08 | 2019-11-05 | A10 Networks, Inc. | Implementation of secure socket layer intercept |
US10846117B1 (en) | 2015-12-10 | 2020-11-24 | Fireeye, Inc. | Technique for establishing secure communication between host and guest processes of a virtualization architecture |
US10447728B1 (en) | 2015-12-10 | 2019-10-15 | Fireeye, Inc. | Technique for protecting guest processes using a layered virtualization architecture |
US11200080B1 (en) | 2015-12-11 | 2021-12-14 | Fireeye Security Holdings Us Llc | Late load technique for deploying a virtualization layer underneath a running operating system |
US10565378B1 (en) | 2015-12-30 | 2020-02-18 | Fireeye, Inc. | Exploit of privilege detection framework |
US10581898B1 (en) | 2015-12-30 | 2020-03-03 | Fireeye, Inc. | Malicious message analysis system |
US10133866B1 (en) | 2015-12-30 | 2018-11-20 | Fireeye, Inc. | System and method for triggering analysis of an object for malware in response to modification of that object |
US10050998B1 (en) | 2015-12-30 | 2018-08-14 | Fireeye, Inc. | Malicious message analysis system |
US10341365B1 (en) | 2015-12-30 | 2019-07-02 | Fireeye, Inc. | Methods and system for hiding transition events for malware detection |
US10872151B1 (en) | 2015-12-30 | 2020-12-22 | Fireeye, Inc. | System and method for triggering analysis of an object for malware in response to modification of that object |
US10445502B1 (en) | 2015-12-31 | 2019-10-15 | Fireeye, Inc. | Susceptible environment detection system |
US11552986B1 (en) | 2015-12-31 | 2023-01-10 | Fireeye Security Holdings Us Llc | Cyber-security framework for application of virtual features |
US9824216B1 (en) | 2015-12-31 | 2017-11-21 | Fireeye, Inc. | Susceptible environment detection system |
US10581874B1 (en) | 2015-12-31 | 2020-03-03 | Fireeye, Inc. | Malware detection system with contextual analysis |
US10951652B1 (en) * | 2016-01-21 | 2021-03-16 | Amazon Technologies, Inc. | Communication session resumption |
US11025603B2 (en) * | 2016-03-14 | 2021-06-01 | Ricoh Company, Ltd. | Service providing system, service delivery system, service providing method, and non-transitory recording medium |
US20190020644A1 (en) * | 2016-03-14 | 2019-01-17 | Ricoh Company, Ltd. | Service providing system, service delivery system, service providing method, and non-transitory recording medium |
US10785255B1 (en) | 2016-03-25 | 2020-09-22 | Fireeye, Inc. | Cluster configuration within a scalable malware detection system |
US10671721B1 (en) | 2016-03-25 | 2020-06-02 | Fireeye, Inc. | Timeout management services |
US10601863B1 (en) | 2016-03-25 | 2020-03-24 | Fireeye, Inc. | System and method for managing sensor enrollment |
US10476906B1 (en) | 2016-03-25 | 2019-11-12 | Fireeye, Inc. | System and method for managing formation and modification of a cluster within a malware detection system |
US11632392B1 (en) | 2016-03-25 | 2023-04-18 | Fireeye Security Holdings Us Llc | Distributed malware detection system and submission workflow thereof |
US10616266B1 (en) | 2016-03-25 | 2020-04-07 | Fireeye, Inc. | Distributed malware detection system and submission workflow thereof |
US11128623B2 (en) | 2016-03-29 | 2021-09-21 | Ricoh Company, Ltd. | Service providing system, service delivery system, service providing method, and non-transitory recording medium |
US11076010B2 (en) | 2016-03-29 | 2021-07-27 | Ricoh Company, Ltd. | Service providing system, service delivery system, service providing method, and non-transitory recording medium |
US11108772B2 (en) | 2016-03-29 | 2021-08-31 | Ricoh Company, Ltd. | Service providing system, service delivery system, service providing method, and non-transitory recording medium |
US11936666B1 (en) | 2016-03-31 | 2024-03-19 | Musarubra Us Llc | Risk analyzer for ascertaining a risk of harm to a network and generating alerts regarding the ascertained risk |
US10893059B1 (en) | 2016-03-31 | 2021-01-12 | Fireeye, Inc. | Verification and enhancement using detection systems located at the network periphery and endpoint devices |
US9680801B1 (en) | 2016-05-03 | 2017-06-13 | Iboss, Inc. | Selectively altering references within encrypted pages using man in the middle |
US20170331854A1 (en) * | 2016-05-11 | 2017-11-16 | Cisco Technology, Inc. | Short Term Certificate Management During Distributed Denial of ServiceAttacks |
US10749897B2 (en) | 2016-05-11 | 2020-08-18 | Cisco Technology, Inc. | Short term certificate management during distributed denial of service attacks |
US10104119B2 (en) * | 2016-05-11 | 2018-10-16 | Cisco Technology, Inc. | Short term certificate management during distributed denial of service attacks |
WO2017196558A1 (en) * | 2016-05-11 | 2017-11-16 | Cisco Technology, Inc. | Short term certificate management during distributed denial of service attacks |
US10686889B2 (en) | 2016-05-18 | 2020-06-16 | Cisco Technology, Inc. | Fastpath web sessions with HTTP header modification by redirecting clients |
US10264079B2 (en) | 2016-05-18 | 2019-04-16 | Cisco Technology, Inc. | Fastpath web sessions with HTTP header modification by redirecting clients |
GB2541969B (en) * | 2016-05-27 | 2019-01-30 | F Secure Corp | Mitigating multiple advanced evasion technique attacks |
GB2541969A (en) * | 2016-05-27 | 2017-03-08 | F Secure Corp | Mitigating multiple advanced evasion technique attacks |
US10169585B1 (en) | 2016-06-22 | 2019-01-01 | Fireeye, Inc. | System and methods for advanced malware detection through placement of transition events |
US10116634B2 (en) | 2016-06-28 | 2018-10-30 | A10 Networks, Inc. | Intercepting secure session upon receipt of untrusted certificate |
US10462173B1 (en) | 2016-06-30 | 2019-10-29 | Fireeye, Inc. | Malware detection verification and enhancement by coordinating endpoint and malware detection systems |
US11240262B1 (en) | 2016-06-30 | 2022-02-01 | Fireeye Security Holdings Us Llc | Malware detection verification and enhancement by coordinating endpoint and malware detection systems |
US10812348B2 (en) | 2016-07-15 | 2020-10-20 | A10 Networks, Inc. | Automatic capture of network data for a detected anomaly |
US10158666B2 (en) | 2016-07-26 | 2018-12-18 | A10 Networks, Inc. | Mitigating TCP SYN DDoS attacks using TCP reset |
US10341118B2 (en) | 2016-08-01 | 2019-07-02 | A10 Networks, Inc. | SSL gateway with integrated hardware security module |
US10592678B1 (en) | 2016-09-09 | 2020-03-17 | Fireeye, Inc. | Secure communications between peers using a verified virtual trusted platform module |
US10491627B1 (en) | 2016-09-29 | 2019-11-26 | Fireeye, Inc. | Advanced malware detection using similarity analysis |
US10382562B2 (en) | 2016-11-04 | 2019-08-13 | A10 Networks, Inc. | Verification of server certificates using hash codes |
US10795991B1 (en) | 2016-11-08 | 2020-10-06 | Fireeye, Inc. | Enterprise search |
US10587647B1 (en) | 2016-11-22 | 2020-03-10 | Fireeye, Inc. | Technique for malware detection capability comparison of network security devices |
US10250475B2 (en) | 2016-12-08 | 2019-04-02 | A10 Networks, Inc. | Measurement of application response delay time |
US11075886B2 (en) * | 2016-12-15 | 2021-07-27 | Keysight Technologies Singapore (Sales) Pte. Ltd. | In-session splitting of network traffic sessions for server traffic monitoring |
US20180176189A1 (en) * | 2016-12-15 | 2018-06-21 | Ixia | In-Session Splitting Of Network Traffic Sessions For Server Traffic Monitoring |
US10581879B1 (en) | 2016-12-22 | 2020-03-03 | Fireeye, Inc. | Enhanced malware detection for generated objects |
US10552610B1 (en) | 2016-12-22 | 2020-02-04 | Fireeye, Inc. | Adaptive virtual machine snapshot update framework for malware behavioral analysis |
US10523609B1 (en) | 2016-12-27 | 2019-12-31 | Fireeye, Inc. | Multi-vector malware detection and analysis |
US10397270B2 (en) | 2017-01-04 | 2019-08-27 | A10 Networks, Inc. | Dynamic session rate limiter |
US20210266342A1 (en) * | 2017-01-27 | 2021-08-26 | Level 3 Communications, Llc | System and method for scrubbing dns in a telecommunications network to mitigate attacks |
US11496438B1 (en) | 2017-02-07 | 2022-11-08 | F5, Inc. | Methods for improved network security using asymmetric traffic delivery and devices thereof |
USRE47924E1 (en) | 2017-02-08 | 2020-03-31 | A10 Networks, Inc. | Caching network generated security certificates |
US10187377B2 (en) | 2017-02-08 | 2019-01-22 | A10 Networks, Inc. | Caching network generated security certificates |
US10791119B1 (en) | 2017-03-14 | 2020-09-29 | F5 Networks, Inc. | Methods for temporal password injection and devices thereof |
US10911483B1 (en) * | 2017-03-20 | 2021-02-02 | Amazon Technologies, Inc. | Early detection of dedicated denial of service attacks through metrics correlation |
US20210144172A1 (en) * | 2017-03-20 | 2021-05-13 | Amazon Technologies, Inc. | Early detection of dedicated denial of service attacks through metrics correlation |
US10904286B1 (en) | 2017-03-24 | 2021-01-26 | Fireeye, Inc. | Detection of phishing attacks using similarity analysis |
US11570211B1 (en) | 2017-03-24 | 2023-01-31 | Fireeye Security Holdings Us Llc | Detection of phishing attacks using similarity analysis |
US10791138B1 (en) | 2017-03-30 | 2020-09-29 | Fireeye, Inc. | Subscription-based malware detection |
US10902119B1 (en) | 2017-03-30 | 2021-01-26 | Fireeye, Inc. | Data extraction system for malware analysis |
US10798112B2 (en) | 2017-03-30 | 2020-10-06 | Fireeye, Inc. | Attribute-controlled malware detection |
US10848397B1 (en) | 2017-03-30 | 2020-11-24 | Fireeye, Inc. | System and method for enforcing compliance with subscription requirements for cyber-attack detection service |
US10554507B1 (en) | 2017-03-30 | 2020-02-04 | Fireeye, Inc. | Multi-level control for enhanced resource and object evaluation management of malware detection system |
US11863581B1 (en) | 2017-03-30 | 2024-01-02 | Musarubra Us Llc | Subscription-based malware detection |
US11399040B1 (en) | 2017-03-30 | 2022-07-26 | Fireeye Security Holdings Us Llc | Subscription-based malware detection |
US10931662B1 (en) | 2017-04-10 | 2021-02-23 | F5 Networks, Inc. | Methods for ephemeral authentication screening and devices thereof |
DE102017210721A1 (en) * | 2017-06-26 | 2018-12-27 | Siemens Aktiengesellschaft | Method and communication system for the efficient establishment of a secure data connection between a client computer and a server computer |
US10503904B1 (en) | 2017-06-29 | 2019-12-10 | Fireeye, Inc. | Ransomware detection and mitigation |
US10855700B1 (en) | 2017-06-29 | 2020-12-01 | Fireeye, Inc. | Post-intrusion detection of cyber-attacks during lateral movement within networks |
US10601848B1 (en) | 2017-06-29 | 2020-03-24 | Fireeye, Inc. | Cyber-security system and method for weak indicator detection and correlation to generate strong indicators |
US10893068B1 (en) | 2017-06-30 | 2021-01-12 | Fireeye, Inc. | Ransomware file modification prevention technique |
US20200396217A1 (en) * | 2017-07-13 | 2020-12-17 | Microsoft Technology Licensing, Llc | Key Attestation Statement Generation Providing Device Anonymity |
US11750591B2 (en) * | 2017-07-13 | 2023-09-05 | Microsoft Technology Licensing, Llc | Key attestation statement generation providing device anonymity |
US10628228B1 (en) * | 2017-08-28 | 2020-04-21 | Amazon Technologies, Inc. | Tiered usage limits across compute resource partitions |
US10747872B1 (en) | 2017-09-27 | 2020-08-18 | Fireeye, Inc. | System and method for preventing malware evasion |
US10805346B2 (en) | 2017-10-01 | 2020-10-13 | Fireeye, Inc. | Phishing attack detection |
US10742612B2 (en) | 2017-10-16 | 2020-08-11 | Cisco Technology, Inc. | Determine payload integrity for traffic flowing across proxies |
US11637859B1 (en) | 2017-10-27 | 2023-04-25 | Mandiant, Inc. | System and method for analyzing binary code for malware classification using artificial neural network techniques |
US11108809B2 (en) | 2017-10-27 | 2021-08-31 | Fireeye, Inc. | System and method for analyzing binary code for malware classification using artificial neural network techniques |
US11240275B1 (en) | 2017-12-28 | 2022-02-01 | Fireeye Security Holdings Us Llc | Platform and method for performing cybersecurity analyses employing an intelligence hub with a modular architecture |
US11005860B1 (en) | 2017-12-28 | 2021-05-11 | Fireeye, Inc. | Method and system for efficient cybersecurity analysis of endpoint events |
US11949692B1 (en) | 2017-12-28 | 2024-04-02 | Google Llc | Method and system for efficient cybersecurity analysis of endpoint events |
US11271955B2 (en) | 2017-12-28 | 2022-03-08 | Fireeye Security Holdings Us Llc | Platform and method for retroactive reclassification employing a cybersecurity-based global data store |
US11658995B1 (en) | 2018-03-20 | 2023-05-23 | F5, Inc. | Methods for dynamically mitigating network attacks and devices thereof |
US10826931B1 (en) | 2018-03-29 | 2020-11-03 | Fireeye, Inc. | System and method for predicting and mitigating cybersecurity system misconfigurations |
US11856011B1 (en) | 2018-03-30 | 2023-12-26 | Musarubra Us Llc | Multi-vector malware detection data sharing system for improved detection |
US11003773B1 (en) | 2018-03-30 | 2021-05-11 | Fireeye, Inc. | System and method for automatically generating malware detection rule recommendations |
US10956477B1 (en) | 2018-03-30 | 2021-03-23 | Fireeye, Inc. | System and method for detecting malicious scripts through natural language processing modeling |
US11558401B1 (en) | 2018-03-30 | 2023-01-17 | Fireeye Security Holdings Us Llc | Multi-vector malware detection data sharing system for improved detection |
US11159562B2 (en) * | 2018-06-19 | 2021-10-26 | Wangsu Science & Technology Co., Ltd. | Method and system for defending an HTTP flood attack |
US11075930B1 (en) | 2018-06-27 | 2021-07-27 | Fireeye, Inc. | System and method for detecting repetitive cybersecurity attacks constituting an email campaign |
US11314859B1 (en) | 2018-06-27 | 2022-04-26 | FireEye Security Holdings, Inc. | Cyber-security system and method for detecting escalation of privileges within an access token |
US11882140B1 (en) | 2018-06-27 | 2024-01-23 | Musarubra Us Llc | System and method for detecting repetitive cybersecurity attacks constituting an email campaign |
US11228491B1 (en) | 2018-06-28 | 2022-01-18 | Fireeye Security Holdings Us Llc | System and method for distributed cluster configuration monitoring and management |
US11316900B1 (en) | 2018-06-29 | 2022-04-26 | FireEye Security Holdings Inc. | System and method for automatically prioritizing rules for cyber-threat detection and mitigation |
US11182473B1 (en) | 2018-09-13 | 2021-11-23 | Fireeye Security Holdings Us Llc | System and method for mitigating cyberattacks against processor operability by a guest process |
US11763004B1 (en) | 2018-09-27 | 2023-09-19 | Fireeye Security Holdings Us Llc | System and method for bootkit detection |
US11368475B1 (en) | 2018-12-21 | 2022-06-21 | Fireeye Security Holdings Us Llc | System and method for scanning remote services to locate stored objects with malware |
US11720660B2 (en) * | 2019-01-28 | 2023-08-08 | EMC IP Holding Company LLC | Temporary partial authentication value provisioning for offline authentication |
WO2020231688A1 (en) * | 2019-05-10 | 2020-11-19 | Akamai Technologies, Inc. | Using the state of a request routing mechanism to inform attack detection and mitigation |
US20200366689A1 (en) * | 2019-05-17 | 2020-11-19 | Charter Communications Operating, Llc | Botnet detection and mitigation |
US11627147B2 (en) * | 2019-05-17 | 2023-04-11 | Charter Communications Operating, Llc | Botnet detection and mitigation |
US11902305B2 (en) | 2019-05-17 | 2024-02-13 | Charter Communications Operating, Llc | Botnet detection and mitigation |
US11258806B1 (en) | 2019-06-24 | 2022-02-22 | Mandiant, Inc. | System and method for automatically associating cybersecurity intelligence to cyberthreat actors |
US11750632B2 (en) | 2019-06-26 | 2023-09-05 | Radware, Ltd. | Method and system for detecting and mitigating HTTPS flood attacks |
US11363044B2 (en) | 2019-06-26 | 2022-06-14 | Radware, Ltd. | Method and system for detecting and mitigating HTTPS flood attacks |
US11556640B1 (en) | 2019-06-27 | 2023-01-17 | Mandiant, Inc. | Systems and methods for automated cybersecurity analysis of extracted binary string sets |
US11392700B1 (en) | 2019-06-28 | 2022-07-19 | Fireeye Security Holdings Us Llc | System and method for supporting cross-platform data verification |
US11886585B1 (en) | 2019-09-27 | 2024-01-30 | Musarubra Us Llc | System and method for identifying and mitigating cyberattacks through malicious position-independent code execution |
US11637862B1 (en) | 2019-09-30 | 2023-04-25 | Mandiant, Inc. | System and method for surfacing cyber-security threats with a self-learning recommendation engine |
US11503052B2 (en) * | 2019-12-19 | 2022-11-15 | Radware, Ltd. | Baselining techniques for detecting anomalous HTTPS traffic behavior |
US20220303251A1 (en) * | 2020-01-14 | 2022-09-22 | Cisco Technology, Inc. | Managing Encrypted Server-Name-Indication (ESNI) at Proxy Devices |
US11356423B2 (en) * | 2020-01-14 | 2022-06-07 | Cisco Technology, Inc. | Managing encrypted server-name-indication (ESNI) at proxy devices |
US11722463B2 (en) * | 2020-01-14 | 2023-08-08 | Cisco Technology, Inc. | Managing encrypted server-name-indication (ESNI) at proxy devices |
US11949776B2 (en) | 2020-03-11 | 2024-04-02 | Cloudflare, Inc. | Establishing a cryptographic tunnel between a first tunnel endpoint and a second tunnel endpoint where a private key used during the tunnel establishment is remotely located from the second tunnel endpoint |
US10903990B1 (en) | 2020-03-11 | 2021-01-26 | Cloudflare, Inc. | Establishing a cryptographic tunnel between a first tunnel endpoint and a second tunnel endpoint where a private key used during the tunnel establishment is remotely located from the second tunnel endpoint |
US11677545B2 (en) | 2020-03-11 | 2023-06-13 | Cloudflare, Inc. | Establishing a cryptographic tunnel between a first tunnel endpoint and a second tunnel endpoint where a private key used during the tunnel establishment is remotely located from the second tunnel endpoint |
CN112104744A (en) * | 2020-03-30 | 2020-12-18 | 厦门网宿有限公司 | Traffic proxy method, server and storage medium |
US20220006654A1 (en) * | 2020-07-02 | 2022-01-06 | EMC IP Holding Company LLC | Method to establish an application level ssl certificate hierarchy between master node and capacity nodes based on hardware level certificate hierarchy |
US11165586B1 (en) * | 2020-10-30 | 2021-11-02 | Capital One Services, Llc | Call center web-based authentication using a contactless card |
US11930120B2 (en) * | 2020-10-30 | 2024-03-12 | Capital One Services, Llc | Call center web-based authentication using a contactless card |
US11621849B2 (en) * | 2020-10-30 | 2023-04-04 | Capital One Services, Llc | Call center web-based authentication using a contactless card |
US20220141024A1 (en) * | 2020-10-30 | 2022-05-05 | Capital One Services, Llc | Call center web-based authentication using a contactless card |
US20230216688A1 (en) * | 2020-10-30 | 2023-07-06 | Capital One Services, Llc | Call center web-based authentication using a contactless card |
CN115065537A (en) * | 2022-06-16 | 2022-09-16 | 公安部第三研究所 | Defense system and dynamic defense method for WEB application automation attack behavior |
CN115333873A (en) * | 2022-10-17 | 2022-11-11 | 华中科技大学 | Attack URL detection method, device and system based on behavior pattern |
Also Published As
Publication number | Publication date |
---|---|
EP2659614A1 (en) | 2013-11-06 |
US20160226896A1 (en) | 2016-08-04 |
TW201233103A (en) | 2012-08-01 |
WO2012096740A1 (en) | 2012-07-19 |
US10250618B2 (en) | 2019-04-02 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US10250618B2 (en) | Active validation for DDoS and SSL DDoS attacks | |
US11870809B2 (en) | Systems and methods for reducing the number of open ports on a host computer | |
US10003616B2 (en) | Destination domain extraction for secure protocols | |
Dayal et al. | Research trends in security and DDoS in SDN | |
US9674209B2 (en) | Method and system for detecting and mitigating attacks performed using cryptographic protocols | |
Fadlullah et al. | DTRAB: Combating against attacks on encrypted protocols through traffic-feature analysis | |
Qian et al. | Off-path TCP sequence number inference attack-how firewall middleboxes reduce security | |
US10749897B2 (en) | Short term certificate management during distributed denial of service attacks | |
Izhikevich et al. | {LZR}: Identifying unexpected internet services | |
US20130312054A1 (en) | Transport Layer Security Traffic Control Using Service Name Identification | |
WO2013112606A1 (en) | Methods and apparatus for managing network traffic | |
Gilad et al. | Off-Path Attacking the Web. | |
Gilad et al. | LOT: A defense against IP spoofing and flooding attacks | |
WO2018075965A1 (en) | Dark virtual private networks and secure services | |
Nasser et al. | Provably curb man-in-the-middle attack-based ARP spoofing in a local network | |
Bender et al. | Accountability as a Service. | |
Sharma et al. | Siegebreaker: An sdn based practical decoy routing system | |
Joarder et al. | A Survey on the Security Issues of QUIC | |
Pandey et al. | Attacks & defense mechanisms for TCP/IP based protocols | |
Fowler et al. | Impact of denial of service solutions on network quality of service | |
Hyppönen | Securing a Linux Server Against Cyber Attacks | |
Liubinskii | The Great Firewall’s active probing circumvention technique with port knocking and SDN | |
Hongach Jr | Mitigating security flaws in the tcp/ip protocol suite | |
Sharma et al. | Security enhancement on BGP protocol: A literature survey | |
Bhakthavatsalam et al. | Prevention of a SYNflood attack using ExtremeXOS modular operating system |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AS | Assignment |
Owner name: VERISIGN, INC., VIRGINIA Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:BHOGAVILLI, SURESH;GUIMARAES, ROBERTO;PANDRANGI, RAMAKANT;AND OTHERS;SIGNING DATES FROM 20101228 TO 20110208;REEL/FRAME:025979/0675 |
|
STCB | Information on status: application discontinuation |
Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION |