EP2676402A2 - Procédés et systèmes de détection et d'atténuation d'une attaque par déni de service distribué (ddos) à haut débit - Google Patents

Procédés et systèmes de détection et d'atténuation d'une attaque par déni de service distribué (ddos) à haut débit

Info

Publication number
EP2676402A2
EP2676402A2 EP12865509.9A EP12865509A EP2676402A2 EP 2676402 A2 EP2676402 A2 EP 2676402A2 EP 12865509 A EP12865509 A EP 12865509A EP 2676402 A2 EP2676402 A2 EP 2676402A2
Authority
EP
European Patent Office
Prior art keywords
attack
probability
traffic
anomaly
threshold
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.)
Withdrawn
Application number
EP12865509.9A
Other languages
German (de)
English (en)
Other versions
EP2676402A4 (fr
Inventor
Surya Pappu
Sanjay Oza
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Sable Networks Inc
Original Assignee
Sable Networks Inc
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Sable Networks Inc filed Critical Sable Networks Inc
Publication of EP2676402A2 publication Critical patent/EP2676402A2/fr
Publication of EP2676402A4 publication Critical patent/EP2676402A4/fr
Withdrawn legal-status Critical Current

Links

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/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
    • H04L12/00—Data switching networks
    • H04L12/02—Details
    • H04L12/22—Arrangements for preventing the taking of data from a data transmission channel without authorisation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/02—Capturing of monitoring data
    • H04L43/026—Capturing of monitoring data using flow identification
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/24—Traffic characterised by specific attributes, e.g. priority or QoS
    • H04L47/2441—Traffic characterised by specific attributes, e.g. priority or QoS relying on flow classification, e.g. using integrated services [IntServ]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/24—Traffic characterised by specific attributes, e.g. priority or QoS
    • H04L47/2483—Traffic characterised by specific attributes, e.g. priority or QoS involving identification of individual flows
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/41—Flow control; Congestion control by acting on aggregated flows or links
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/70—Admission control; Resource allocation
    • H04L47/80—Actions related to the user profile or the type of traffic
    • 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
    • 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/1408—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic by monitoring network traffic
    • H04L63/1425—Traffic logging, e.g. anomaly detection
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/22—Parsing or analysis of headers

Definitions

  • a Distributed Denial of Service (DDoS) attack can compromise and debilitate the bandwidth and resources not only of the targeted system, but of entire networks.
  • Legacy routers and traditional surveillance and monitoring techniques have major limitations in defending against DDoS attacks on their own - both in terms of the attack detection accuracy and in scaling performance (i.e., to be able to perform detection and potentially mitigate attack traffic while still allowing legitimate users access to the server, at high speeds of the order of tens of gigabits per second).
  • a variety of protocols are prone to high-rate attacks (e.g., ICMP ping flood, UDP flood, TCP SYN attack) such that a system for detecting and mitigating a high-rate DDoS attack must address a wide range of flood-attacks.
  • high-rate attacks e.g., ICMP ping flood, UDP flood, TCP SYN attack
  • a system for detecting and mitigating a high-rate DDoS attack must address a wide range of flood-attacks.
  • Anti-DDoS systems and security appliances target the detection of specific DDoS attacks and hence require CPU-intensive operations.
  • the tremendous amount of state information needed to detect every type of attack greatly limits system performance and precludes having a scalable solution (i.e., a solution that can scale to the order of tens of gigabits per second).
  • a scalable solution i.e., a solution that can scale to the order of tens of gigabits per second.
  • Several reported instances of devices crashing during a DDoS attack in the recent past demonstrate the ease with which security appliances/anti-DDoS systems can be overwhelmed, thereby defeating the purpose of having such a device in the network.
  • the rapid response necessary to detect and mitigate DDoS attacks can degrade data path and CPU performance in the current model of security devices.
  • Legacy routers and Layer 3 devices that support DDoS attack detection use a range of traffic anomaly algorithms that are primarily based on sampling packets from the data path. Such an approach can be fairly inaccurate (as it is plagued with a high false positive or false negative rate) and it can result in degraded data path or CPU performance, depending on the sampling frequency used.
  • a majority of the flows e.g., identified using five tuple
  • the typical packet sampling techniques will fail to detect such attacks due to missed samples from the flow, especially if the sampling frequency is too low.
  • a higher sampling frequency with an improved attack detection can be achieved, but will result in degraded data path (or CPU) performance.
  • Figure 1 depicts an example environment in which the method and system for detecting and mitigating high-rate DDoS attacks can be implemented.
  • Figure 2A depicts an example block diagram illustrating a system for detecting and mitigating a high-rate DDoS attack.
  • Figure 2B depicts an example block diagram illustrating detailed example processes of the BSR module, packet processing module, and flow-state block.
  • Figure 3 depicts a flow diagram illustrating an example process of local- tier detection and mitigation, according to one embodiment.
  • Figure 4 depicts a flow diagram illustrating a detailed example process of local tier detection, according to one embodiment.
  • Figure 5 depicts a flow diagram illustrating an example process of computing an attack probability from a traffic deviation parameter.
  • Figure 6 depicts a flow diagram illustrating an example process of local mitigation, according to one embodiment.
  • Figure 7 depicts a flow diagram illustrating an example process of global-tier detection and mitigation, according to one embodiment.
  • FIG. 1 and the following discussion provide a brief, general description of a representative environment in which the method and system for detecting and mitigating high-rate DDoS attacks (generally termed a "DDoS solution”) can be implemented, according to one embodiment.
  • DDoS solution the method and system for detecting and mitigating high-rate DDoS attacks
  • system may refer to some or all of the elements of Figure 1 , or other aspects of the DDoS solution).
  • Figure 1 depicts an example environment 100 comprising one or more DDoS attackers 1 10A-N and one or more legitimate users 130A-N coupled via a network (e.g., Internet) 120, a DDoS solution 150 having one or more local-tier mechanisms 140A-N and an additional global-tier mechanism 160, one or more security appliance 170 [e.g., Intrusion Prevention System (IPS), Intrusion Detection System (IDS), Anti-DDoS System], a switch 180, and plurality of servers 190. While an embodiment of the local-tier mechanism 140 is shown as a router in Figure 1 , the local-tier mechanism may be implemented in other systems as well (e.g., security appliance, legacy routers).
  • the network 120 may include, but is not limited to, a telephonic network or an open network, such as the Internet.
  • the network 120 may be any collection of distinct networks operating wholly or partially in conjunction to provide connectivity to the electronic devices and may appear as one or more networks to the serviced systems and devices.
  • communications over the network 120 may be achieved by a secure communications protocol, such as secure sockets layer (SSL), or transport layer security (TLS).
  • SSL secure sockets layer
  • TLS transport layer security
  • communications can be achieved via one or more wireless networks, such as, but is not limited to, one or more of a Local Area Network (LAN),
  • LAN Local Area Network
  • WLAN Wireless Local Area Network
  • PAN Personal area network
  • CAN Metropolitan area network
  • WAN Wide area network
  • WWAN Wireless wide area network
  • GSM Global System for Mobile Communications
  • PCS Personal Communications Service
  • D-Amps Digital Advanced Mobile Phone Service
  • Bluetooth Wi-Fi
  • Fixed Wireless Data 2G, 2.5G, 3G networks
  • EDGE enhanced data rates for GSM evolution
  • GPRS General packet radio service
  • enhanced GPRS messaging protocols such as, TCP/IP, SMS, MMS, extensible messaging and presence protocol (XMPP), real time messaging protocol (RTMP), instant messaging and presence protocol (IMPP), instant messaging, USSD, IRC, or any other wireless data networks or messaging protocols.
  • XMPP extensible messaging and presence protocol
  • RTMP real time messaging protocol
  • IMPP instant messaging and presence protocol
  • instant messaging USSD, IRC, or any other wireless data networks or messaging protocols.
  • the example environment shown in Figure 1 illustrates an example DDoS solution 150 whereby the plurality of servers 190 are monitored for attacks.
  • the DDoS solution 150 can be implemented via a two-tier approach, whereby each tier includes a detection phase and a mitigation phase.
  • the first tier 140 of this embodiment comprises of the local detection and local mitigation phases.
  • the local-tier is based on a local view of traffic to the servers on an individual basis.
  • the second tier 160 of this embodiment also performs detection and mitigation functions, but performed on a more holistic (e.g., global) basis that accounts for system and network level requirements. That is, the global tier is based on aggregating data from multiple local tiers to give a more comprehensive view of traffic to a server.
  • the detection phase of the second tier includes periodically receiving data from one or more local tier entities.
  • the mitigation phase of the global tier includes applying a more comprehensive policy that can address a particular anomaly as it allows unaffected activity to resume.
  • the DDoS solution 150 solely comprises of one or more local mechanisms 140A-N performing local detection and mitigation of a high- rate DDoS attack.
  • the detection phase of a local-tier mechanism 140 identifies a high-rate DDoS attack by proactively looking for anomalous traffic patterns localized to the server(s) 190.
  • the mitigation phase of the local-tier mechanism 140 includes controlling a high-rate DDoS attack to particular server(s) by dynamically applying a policy suited for the type of attack (such as enforcing a punitive action on traffic coming from the attackers).
  • a policy suited for the type of attack such as enforcing a punitive action on traffic coming from the attackers.
  • a "flow” can be described as a stream of IP packets going from a particular source IP address and port to a particular destination IP address and port, in which all of the packets are using the same protocol (e.g., voice call, video call, file transfer, or web access).
  • a flow-state router will thusly route flows, and not packets, and keeps state information on every flow (i.e., updated as every packet belonging to the flow) traveling through the system.
  • State information may include, but is not limited to, forwarding, Quality of Service (QoS), application specific information and information about traffic type, traffic rate, application, and service needs.
  • QoS Quality of Service
  • the first local-tier mechanism 140A-N is a flow-state router.
  • a flow is automatically established when the first packet of a flow traverses the flow-state router, which then labels a flow with a unique header (e.g., five tuple header containing source address and port, destination address and port, protocol type) and creates a unique record of the flow's state information.
  • the cumulative statistics of each flow record can be combined to form various types of "aggregate data", which can be classified according to its source (SA), destination (e.g., DA), etc.
  • SA source
  • DA destination
  • the flow-state router updates the record whenever that particular packet of the flow (or a new packet) traverses the first tier local mechanism 140.
  • the flow-state router can apply a specific treatment or action to the entire flow (i.e., every packet in it) based on a classification, rule, or policy, etc.
  • the flow-state router reserves the appropriate resources needed to apply the policy so as to guarantee the resources' availability for subsequent packets in the flow.
  • the flow-state router can, in some embodiments, operate differently in comparison to traditional routers well-known in the art. For example, while traditional routers perform routing table lookups on every packet and forward every packet that is individually encountered, flow-state routers can perform one look-up for the first packet of a new flow, save the result/state in a flow record and then process all subsequent packets of the flow in accordance to specific policies, application needs, control parameters, assigned QoS profiles, or other guidelines saved in the flow record without incurring lookups again.
  • flow state information for each flow can be redirected to an internal or external device for further monitoring, logging, and analysis - all such flow information is the most accurate snapshot of traffic passing through the router.
  • FIG. 2A depicts a simplified block diagram illustrating a system 200 for detecting and mitigating a high-rate DDOS attack.
  • the DDoS solution 150 is a composite approach of both hardware and software to detect and mitigate high-rate DDoS attacks.
  • the local-tier mechanism 140 can be an infrastructure of hardware, such as one or more linecards 210 (e.g., Sable Network's S-Series line card) for maintaining flow state of millions of flows.
  • the DDoS solution further includes a global-tier mechanism 160 including software 270A-N such as Sable Network's Service & Application Vision [SAVi] software, to monitor, analyze, and control individual or aggregate flows.
  • software 270A-N can be implemented on an external apparatus 260A-N such as one or more servers and the software 270A-N can be partially or wholly internal to one or more servers.
  • the local- tier mechanism and the global-tier mechanism may be a fully integrated solution.
  • the local-tier mechanism includes one or more linecards 210A-N communicatively coupled to the global tier (e.g., external apparatuses 260A- N) via a network interface 250.
  • Each linecard 210 includes a communications module 245, Bulk Statistics Record (BSR) module 230 executed by a general purpose processor 220, a packet processing module 240 with associated functions (including traffic classification, forwarding, and QoS), a memory 280 including a flow- state block 290 (see related patents under "Cross-references" for more details). Additional or fewer modules may be included in addition to the presence of a firewall (not shown). Details regarding each of these components are discussed further below. Local-Tier Detection and Mitigation
  • the DDoS solution 150 includes local tier 140 detection and mitigation.
  • the detection phase monitors and updates flow data in a system by monitoring real-time statistics.
  • the detection phase also includes identifying anomalous traffic patterns in which more than one anomaly algorithms are implemented to detect deviations in traffic.
  • an algorithm may define "normal" traffic conditions to be a predetermined proportion of sent packets/flows to number of bytes in a given observation period on a specific incoming/outgoing interface or destination address [DA] (server).
  • DA destination address
  • an "attack” can be considered to be any deviation from "normal” by a certain factor.
  • the local tier 140 detection is performed by one or more linecards 210A-N that are integrated into a device (e.g., flow router 140) in the system (termed "inline"). Given the linecard's 210 position in the system, it can act as a first line of defense and quickly identify anomalous traffic patterns within a short time (e.g., tens of seconds).
  • the linecard 2 0 includes multiple modules and/or components that may be coupled to one another and each is illustrated as being individual and distinct. However, in some embodiments, some or all of the components, and/or the functions represented by each of the components can be combined in any convenient and/or known manner.
  • the modules of the linecard 210 may be implemented on a single device, multiple devices, and/or in a distributed fashion.
  • the blocks/modules of the linecard 210 are functional units that may be divided over multiple devices and/or processing units or combined on a single device. Furthermore, the functions represented by the blocks/modules can be implemented individually in hardware, software, or a combination of hardware and software. Different and additional hardware modules and/or software agents may be included in the linecard 210 without deviating from the spirit of the disclosure.
  • the packet processing module 240 collects flow data by monitoring a stream of IP packets. By operating on a flow-state basis, the packet processing module 240 processes the flow record data for every individual flow, which in turn can be accumulated to create aggregate data (see above for description of aggregate data). The packet-processing module 240 maintains this record of individual flow and aggregate data (based on Source Address, Destination Address, protocol or any other combination of fields from the packet header) for further analysis and periodically exports this data to the BSR module 230, discussed in detail below.
  • the packet processing module 240 is a custom packet processing ASIC which provides a "sample” (i.e., up-to-date flow state information at a given time) of a flow to the BSR module 230.
  • a sample i.e., up-to-date flow state information at a given time
  • the packet processing module 240 provides different types of samples, such as a "first sample” that is the very first sample of a flow, a "middle sample” that is a statistically chosen from the flow (e.g., sent when every Nth packet of a flow is received), and a "close sample” that is a final or summary sample when the flow ends or ages out.
  • Each sample sent to BSR module 230 contains information from the flow state block 290 maintained and updated by the packet processing module 240. Flow state samples are, therefore, sent to the BSR module 230 for each and every flow, thus ensuring the accuracy of aggregate data that is maintained and used by the BSR 230.
  • Figure 2B depicts an example block diagram illustrating detailed example processes of the BSR module 230, packet processing module 240, and flow-state block 290 included in the memory 280.
  • Figure 2B shows first, middle, close samples coming from the flow-state block 290 directly. These samples are received by the BSR module 230, whereby it maintains individual flow records and filtered aggregate records (based on DA, SA).
  • the "samples" referred to herein are accurate flow state data that is sent periodically, and are not statistically-sampled packets.
  • the linecard 210 also comprises a memory 280 which includes a flow-state block 290.
  • the flow-state is created and updated as packets belonging to the flow are received by packet processing module 240.
  • the state information maintained by the flow-state block 290 includes information about traffic type, traffic rate, application, and service needs.
  • state information examples include IPSA, IPDA, incoming (i.e., ingress) interface, outgoing (i.e., egress) interface, quality of service (QoS) data, forwarding action, packet filtering action, timestamp-creation, statistics (e.g., byte, packet, or drop count), protocol, source port, destination port and the like.
  • IPSA IP Security
  • IPDA IP Data Management Entity
  • incoming (i.e., ingress) interface i.e., ingress) interface
  • QoS quality of service
  • forwarding action e.g., packet filtering action
  • timestamp-creation e.g., byte, packet, or drop count
  • the first, middle, and close samples can contain the following information: flow keys to identify the flow such as source IP address, destination IP address, source port number, destination port number, IP protocol, egress and ingress interface information, flow statistics such as cumulative number of packets in flow forwarded until that sampling instance, cumulative number of bytes in flow forwarded until that sampling instance, cumulative number of packets dropped until that sampling instance, and Quality of Service (QoS) data that includes jitter, flow rate, packet arrival/departure timestamps etc.
  • flow keys to identify the flow such as source IP address, destination IP address, source port number, destination port number, IP protocol, egress and ingress interface information
  • flow statistics such as cumulative number of packets in flow forwarded until that sampling instance, cumulative number of bytes in flow forwarded until that sampling instance, cumulative number of packets dropped until that sampling instance
  • QoS Quality of Service
  • the linecard 210 also comprises a general purpose processor 220 executing a Bulk Statistics Record (BSR) module 230.
  • the BSR module 230 receives sample information on flows (e.g., flow state records) from the packet processing module 240 and can accumulate the received samples into continuous flow records and aggregate records.
  • the BSR module 230 then computes ratios of various attributes of the aggregate records (or other similar records towards the server) in a set period of time.
  • the BSR 230 then operates on these attribute ratios using a variety of algorithms to detect traffic anomaly towards the protected server DAs.
  • the detection logic in the BSR module 230 comprises of computing traffic deviation ratios using data harvested from the packet processing module 240 and running various anomaly algorithms (discussed in more detail below).
  • the BSR module 230 can run anomaly algorithm(s) at different levels of granularity to detect any traffic deviations from "normal.” Additional features peripheral to this main function can be performed by the BSR module 230, such as providing periodic reports of flow or aggregate records to other modules.
  • Running detection algorithms on the BSR module 230 does not degrade the forwarding performance or processing capabilities of the packet processing module 240, since the anomaly detection is not occurring in the main data path of the packet processing module 240.
  • the BSR 230 harvests flow data for only interested flows using classification/filtering criteria, thus conserving bandwidth between the packet processing module 240 and the BSR 230.
  • the BSR module 230 harvests statistics at different levels of granularity (e.g., interface [such as network interface 250], Source Address [SA], Destination Address [DA], etc.) using flow state samples obtained from packet processing module 240.
  • the techniques described herein refer primarily to the DA aggregate level (e.g., monitoring traffic to one or more servers being protected), one skilled in the art will understand that the techniques may be practiced in other ways, such as on the interface level (e.g., monitor network interface 250 traffic coming from or going to a server).
  • the linecard 210 includes a communications module 245 or a combination of communications modules communicatively coupled to the network interface 250 to manage a one-way, two-way, and/or multi-way communication sessions over a plurality of communications protocols.
  • the communications module 245 transmits and/or receives data (e.g., information, commands, requests, and/or messages) over a network.
  • the communications module 245 is typically compatible with receiving and/or interpreting data originating from various communication protocols, the communications module 245 is able to establish parallel and/or serial communication sessions with operators of remote client devices for data and command exchange (e.g., alerts and/or operator commands).
  • data and command exchange e.g., alerts and/or operator commands
  • the network interface 250 can be one or more networking devices that enable the linecard 210 to mediate data in a network with an entity that is external to the linecard, through any known and/or convenient communications protocol supported by the linecard and the external entity.
  • the network interface 250 can encompass one or more of a network adaptor card, wireless network interface card, router, access point, wireless router, switch, multilayer switch, protocol converter, gateway, bridge, bridge router, hub, digital media receiver, and/or repeater.
  • a firewall can, in some embodiments, be included to govern and/or manage permission to access/proxy data in a computer network, and track varying levels of trust between different machines and/or applications.
  • the firewall (not shown) can be any number of modules having any combination of hardware and/or software components able to enforce a predetermined set of access rights between a particular set of machines and applications, machines and machines, and/or applications and applications, for example, to regulate the flow of traffic and resource sharing between these varying entities.
  • the firewall may additionally manage and/or have access to an access control list which details permissions including for example, the access and operation rights of an object by an individual, a machine, and/or an application, and the circumstances under which the permission rights stand.
  • the functionalities of the network interface 250 and the firewall are partially or wholly combined and the functions of which can be implemented in any combination of software and/or hardware, in part or in whole.
  • Figure 3 depicts a flow diagram illustrating an example process 300 of local-tier detection and mitigation, according to one embodiment.
  • the process starts in normal mode wherein no DDoS attack is present.
  • the system (BSR module 230) runs more than one anomaly detection algorithms.
  • the frequency with which the anomaly detection algorithms are run can vary.
  • the system can run anomaly algorithm(s) periodically (i.e., every certain time period) in the background.
  • the system can continuously run the algorithm(s).
  • simple algorithms requiring minimal processing overhead are used to quickly perform a first pass detection.
  • several complex algorithms are deployed in parallel at the same time. In such an embodiment, if a majority of algorithms deem the traffic deviation to be an attack, this is often a strong indication of an attack. On the other hand, if the number of algorithms that deem the traffic deviation as an attack is a minority, this often signifies a lower risk of a real attack and/or indicates a false positive. [0054] A deviation in the traffic ratios is often indicative of a potential threat.
  • the system e.g., the BSR or other such module where algorithms are run determines from the running algorithm(s) whether a traffic anomaly is observed. Further details regarding the process of identifying a traffic anomaly is described below relating to Figure 4. In general, a traffic anomaly is observed if one or more algorithms detect attack traffic at a given level (e.g., DA aggregate level).
  • a traffic anomaly is not observed (block 330 - No)
  • the system returns to block 310 where it continues to run anomaly detection algorithms.
  • a traffic anomaly is observed (block 320 - Yes)
  • the system proceeds to perform local-tier mitigation.
  • the system enters a threat-detected mode 330; whereupon operator- configured mitigation actions can be initiated.
  • a proactive alert can be issued via activity updates/logs and an operator can be notified at the first sign of any unusual activity. Further details regarding the processes of this threat-detected mode is described below relating to Figure 5.
  • Figure 4 depicts a flow diagram illustrating an example process 400 of local-tier detection, according to one embodiment.
  • Each anomaly detection algorithm yields an associated traffic deviation factor, and from this traffic deviation factor, a probability of attack can be computed as shown in Figure 5.
  • a probability of attack can be computed.
  • the example process of local-tier detection occurs at the DA level and uses a combination of algorithms and heuristics. Certain anomaly algorithms as well as particular heuristic detection algorithms can be selected for use. After each anomaly algorithm and heuristic algorithm is assigned a weight, a net probability of attack can be computed.
  • the below instructions offer a simplified example of an illustrative detection algorithm: DAAggr:ddos_check() ⁇
  • multiple (more than one) anomaly algorithms are run to detect traffic deviations such that the combination of algorithms can yield a greater likelihood of detection at a higher confidence level.
  • multiple (more than one) anomaly detection algorithms can be run in various ways using different timing schemes (e.g., concurrently, serially, sporadically and the like).
  • each algorithm that is used to detect an anomaly is associated with a weight (w) wherein the sum of all weights is equal to one.
  • weights (w) can be assigned to an algorithm at block 410 based on a false positive rate.
  • Each anomaly detection algorithm can posses a certain false positive rate (fp) (usually expressed as a percentage), whereby the lower a false positive rate, the more accurate the algorithm is.
  • the false positive rate in one embodiment, is a predetermined value that can be statistically defined or arbitrarily assigned by, for example, an operator or a creator of the algorithm.
  • Algorithm 1 Algoi
  • Algorithm 2 Algoi
  • Algoi a series of flow heuristics monitoring
  • fp 2 0.2
  • Algo ⁇ has twice the false positive rate than Algo 1t Algoi is more accurate and thusly weighted two times more than Algo 2 . That is, Wi for Algoi is 0.67 and w 2 for Algoz is 0.33.
  • the weight assigned to an algorithm may be inversely proportional to the false positive rate ⁇ wi is proportional to Mfpi).
  • weights may be assigned to each algorithm on a case-by-case basis, as shown:
  • weight can be manually assigned to by an operator.
  • a weight for each algorithm can be pre- assigned with default values.
  • the weights can be calculated and automatically assigned.
  • the process of calculating and assigning a weight for each algorithm 410 can be an optional step that may be bypassed altogether.
  • the weight that is assigned may vary.
  • the weight can be an arbitrary value.
  • the weight can be a pre-determined parameter based on its efficacy in relation to other algorithms. For example, a larger weight is assigned to an algorithm or method that is relatively more effective in identifying an actual DDoS attack.
  • Various modifications and combinations of these are possible as those skilled in the relevant art will recognize.
  • a probability of attack is computed for each algorithm based on a traffic deviation (td) factor.
  • Each anomaly detection algorithm notes the traffic at a given level such as the DA-level (i.e., monitoring all traffic to the protected servers). For example, ingress and egress data are monitored at a particular node such that any change to this data can be potentially noted as an attack in accordance to the algorithm.
  • the traffic pattern may be monitored with respect to number of bytes, packets, flows, rates over a certain period of time, or any combination thereof.
  • the "traffic deviation" (td) factor is an indicator of the current state of traffic patterns compared to a normal baseline and can serve as a measure of observed anomalous traffic.
  • td An example process by which a probability of attack is computed in block 415 is illustrated in Figure 5.
  • FIG. 5 depicts a flow diagram illustrating an example process 500 of computing an attack probability of an algorithm based on a traffic deviation parameter.
  • a traffic deviation parameter td
  • the current process involves extrapolating or modifying the algorithm to derive a td.
  • an attack probability is computed as discussed below. For example, attack probability calculations can be simultaneous such that more than one Pattack is computed at the same time.
  • an algorithm is selected for which a traffic deviation, and thus a probability of attack are to be computed.
  • threshold traffic deviation parameters are defined for the algorithm.
  • a low-traffic deviation threshold (tdi ow ) and a high-traffic deviation threshold (td h ig h ) are defined.
  • the low-traffic deviation specifies the lower threshold at which the anomaly algorithm may indicate a potential attack and the high-traffic deviation specifies the higher threshold at which the anomaly algorithm is known to indicate an attack.
  • the thresholds can be manually assigned by an operator.
  • the thresholds for each algorithm can be pre-assigned with default values. In yet another embodiment, the thresholds can be calculated and automatically defined. In addition, the step of defining the thresholds for the algorithm 510 can be an optional step that may be bypassed altogether.
  • a corresponding probability of attack ⁇ Pattack) parameter is associated to each threshold traffic deviation (td) parameter, such as a low- probability of attack (Pattack ⁇ ow ) and a high-probability of attack (Pattack ⁇ ), in accordance to one embodiment.
  • the Pattack parameter represents the probability with which one can state that the traffic anomaly deviation, indicated by td, is an attack. For example, if Pattack is 0.7, it implies that there is a 70% probability that the anomalous traffic deviation seen is an attack and not a legitimate traffic surge.
  • the low-probability of attack is the probability of attack when the traffic deviation is equal to td iow.
  • Pattack ⁇ m value may be the lowest attack probability at which a mitigation action will be initiated.
  • the high-probability of attack is the probability of attack when the traffic deviation is equal to td igh-
  • Pattack ig h may be the greatest attack probability at which one can state with certainty that the traffic anomaly seen is really an attack. Accordingly, there can be a more punitive mitigation action that can be enforced.
  • the parameters can be manually assigned by an operator.
  • the parameters for each algorithm can be pre- assigned with default values (e.g., 0.5, 1.0).
  • the thresholds can be calculated and automatically defined.
  • flow diagram 500 runs the algorithm selected in block 505 in order to compute a traffic deviation ⁇ td) factor.
  • the individual probability of attack for the selected algorithm can be derived in a variety of ways.
  • linear extrapolation is used at block 525 to determine the probability of attack (Pattack) through the following equations:
  • the probability of attack can be computed in a non-linear fashion at block 535 (e.g., exponential, other distribution).
  • the probability of attack can be determined at block 530 using discrete methods for various values of td.
  • the following description explains how the probability of attack is calculated with an example algorithm, the C Kotsokalis algorithm (algorithm details below).
  • the following traffic ratios (monitored at the interface such as network interface 250 or aggregate level such as DA aggregate level) track each other closely when conditions are normal, wherein B ra tio, Pratio, and F ra ti 0 are respectively ratios of byte, packet, and flow counts:
  • traffic deviation can be defined as (B ra tio / Pratio) and/or (B ra tio Fratio).
  • the traffic deviation is expected to be close to 1.0.
  • the traffic pattern indicates an anomaly in traffic that may be considered an attack.
  • the C Kotsokalis algorithm indicates a certain traffic pattern wherein the td calculated at block 520 is 1 .48.
  • a net probability of attack is then determined.
  • a net probability of attack can be computed using the Pattack of each algorithm at block 420.
  • individual attack probabilities are derived from each algorithm and their corresponding traffic deviation (td) factor
  • td traffic deviation
  • a net attack probability is computed from these individual attack probabilities.
  • this probability threshold is defined as P/owjhwshoid representing the minimum probability at which an operator determines a threat is detected and mitigation logic should come into force.
  • the probability threshold can be defined by an operator.
  • the probability threshold can be pre-defined with a default value (e.g., 0.5 if the net attack probability is 50%) wherein a potential threat may be implied and the operator wants to enforce mitigation.
  • the probability threshold can be calculated and automatically defined. Various modifications and combinations of this are possible as those skilled in the relevant art will recognize.
  • the system determines that the net probability of attack is greater than a probability threshold (block 425 - Yes)
  • the system proceeds to perform local- tier mitigation (additional details are described further below).
  • the system determines that the net probability of attack is not greater than a probability threshold (block 425 - No)
  • the system returns to block 405, whereupon the process of local-tier detection begins again and the anomaly detection algorithms are run.
  • the higher the net Pattack the more punitive the mitigation can be. This is because a higher attack probability indicates a higher degree of confidence that the anomaly is really an attack.
  • FIG. 6 depicts a flow diagram illustrating an example process 600 of local-tier mitigation, according to one embodiment.
  • any observed traffic anomalies on a certain level e.g., DA
  • the system enters the threat mitigation mode once Pattack crosses the probability threshold as shown in block 425. This indicates that there is a real possibility of attack at the server (DA) being monitored (block 605).
  • the system determines that a DA is under an attack (decision block 605 - Yes)
  • the system proceeds to maintain a list of users (or SAs) (shown in block 615) that are sending traffic to the victim server.
  • FIG. 6 primarily depicts local-tier mitigation related to a DA (i.e. based on observing traffic anomalies at DA aggregate level); however, one skilled in the art will recognize that the techniques may be practiced on other levels (such as the interface level whereby an interface is a network interface such as 250 shown in Figure 2A).
  • the anomaly algorithms can continue to be executed (block 610). Note that additional heuristic measurements such as low average packet size, large percentage of TCP or UDP packets, or a high number of flows, etc. may be considered as part of anomaly algorithms being run as well, in order to detect traffic deviations.
  • the local mitigation process in Figure 6 proceeds to decision block 620 to determine whether the SAs involved in the high-rate DDoS attack are spoofed.
  • the system can determine whether the attacker is using a legitimate or spoofed address in various ways as known in the art.
  • a reverse path check of the source address can be performed to determine if the attack is from a spoofed address.
  • TCP SYNs are correlated with TCP SYN+ACKs or other significant discrepancies in traffic ratios are identified to detect spoofed SAs. .
  • the mitigation algorithm can apply a policy of dropping the flow (block 625), in accordance to one embodiment. This can be a default action.
  • the mitigation algorithm can send an alert to external servers and the system logs the details of the spoofed address to trace its origin. If there is no spoofing (block decision 620 - No), it indicates that the SA under consideration is using a valid IP address for its traffic to the server. The task now is to determine if this user (SA) is a legitimate user trying to access the server or if it is an attacker (i.e., compromised user). The system determines if the heuristics indicate the SA to be an attacker or not at block 630.
  • the source can be deemed to be legitimate and the system forwards traffic from this SA (block 640).
  • the system next decides at block 645 whether all SAs have been checked. If not (decision block 645 - No), then the system checks the next SA on the list at block 650 and repeats the evaluation process starting at block 620 for each SA. After all SAs have been checked (decision block 645 - Yes), the system returns to running anomaly algorithms at block 610 and determines whether a noticeable deviation in traffic can still be observed (e.g., is the DA still under attack). The process can repeat again and a new list of SAs (which may be different each time depending on which SA is sending traffic to the server) is created again (block 615) for which to apply local-tier mitigation policies.
  • the system can automatically apply a DDoS mitigation policy (block 635) that dynamically controls the attack traffic.
  • a DDoS mitigation policy (block 635) that dynamically controls the attack traffic.
  • attack probability Pattack
  • SAs connection admission control of new flows, reducing bandwidth
  • the mitigation action taken can be milder and less robust; at least until the activity is further validated as an attack by the global tier mechanism. As will be described below, the intensity of the mitigation policy can be adjusted.
  • the local-tier mitigation phase includes the ability of the operator to customize the mitigation policies to flexibly allow a range of policies.
  • the operator configures the mitigation action on the impacted SAs (attackers) with the server DA being the victim of the attack, based on differing attack probability values. Probability of Attack
  • Threshold 1 If attack-probability > 90% Reduce bandwidth from each attacking SA by 70%; drop all traffic for spoofed
  • Threshold 2 If attack-probability between 80% and 90% Reduce bandwidth from attacking
  • Threshold 3 If attack-probability between 70% and 80% Reduce bandwidth from attacking
  • Threshold 4 If attack-probability ⁇ 70% No Action; alert/log
  • Table 1 illustrates another example of a customized mitigation policy.
  • specific thresholds of attack probabilities correspond to different mitigation actions. For example, a probability of attack that is greater than 90% corresponds to an action to reduce bandwidth from attacking SA by 70%; an attack- probability between 80%-90% corresponds to an action to reduce bandwidth from attackers by 50%; an attack-probability between 70-80% corresponds to an action to reduce attacker bandwidth by 30%; and an attack-probability less than 70% corresponds to no action.
  • parameters such as attack-probability at which to apply mitigation, mitigation actions, and bandwidth reduction percentage are individually configurable.
  • a default mode automatically applies whereby details of every attacker are logged.
  • the local tier mechanism 140 can selectively send aggregate data for anomaly analysis by the global tier.
  • the local tier mechanism can send flow data on just the top heavy users to the global tier mechanism (in contrast to data of every user) for an in-depth anomaly analysis.
  • the local-tier mechanisms are based on a local view of traffic destined to a particular node (e.g., server DA, interface).
  • the DDoS solution can additionally include a global tier mechanism which holistically detects and mitigates a high-rate DDoS attack (shown in Figure 1 as 160). Detection and mitigation of the global-tier mechanism is based on aggregating data from multiple local tiers and provides a more comprehensive view of traffic to a particular node (e.g., server, interface). Using the information from multiple local tiers, the global-tier can similarly use more than one algorithm to correlate and analyze flow data to detect and mitigate a DDoS attack.
  • the global tier mechanism (e.g., 160 in Fig. 1) can identify and/or control the high-rate DDoS attack with software 270A-N running on external server(s) 260A-N.
  • the external server(s) 260A-N may store information such as software, databases, system information, descriptive data, images, video, and/or any other data item utilized by the server 260 for operation.
  • the global-tier mechanism(s) 260A-N can receive data from one or more local tiers 210A-N of one system or from multiple systems (not shown).
  • Databases may be managed by a database management system (DBMS), for example, but not limited to, Oracle, DB2, Microsoft Access, Microsoft SQL Server, PostgreSQL, MySQL, FileMaker, etc. and can be implemented via object-oriented technology and/or via text files, and can be managed by a distributed database management system, an object-oriented database management system (OODBMS) (e.g., ConceptBase, FastDB Main Memory Database Management System, JDOInstruments, ObjectDB, etc.), an object-relational database management system (ORDBMS) (e.g., Informix, OpenLink Virtuoso, VMDS, etc.), a file system, and/or any other convenient or known database management package.
  • DBMS database management system
  • DBMS database management system
  • DBMS object-oriented database management system
  • ODDBMS object-oriented database management system
  • ORDBMS object-relational database management system
  • a file system e.g., Informix, OpenLink Virtuoso, VMDS, etc.
  • the external server(s) 260A-N can be implemented using one or more processing units, such as server computers, UNIX workstations, personal computers, and/or other types of computers and processing devices.
  • the server 260 includes multiple components and/or devices that may be coupled to one another and each is illustrated as being individual and distinct. However, in some embodiments, some or all of the components, and/or the functions represented by each of the components can be combined in any convenient and/or known manner.
  • the components of the server(s) 260A-N are functional units that may be divided over multiple devices and/or processing units.
  • the functions represented by the devices can be implemented individually or in any combination thereof, in hardware, software, or a combination of hardware and software. Different and additional hardware modules and/or software agents may be included on the server(s) 260A-N without deviating from the spirit of the disclosure.
  • the local-tier mechanism 140 can export individual flow and aggregate data (such as DA aggregates) to the global-tier mechanism 160 for additional monitoring and analysis on a more comprehensive level.
  • the global tier utilizes a more comprehensive approach which holistically detects and mitigates a high-rate DDoS attack.
  • the global tier receiving data from multiple linecards in a system and/or from multiple systems, can evaluate and analyze the empirical data of every node within the network.
  • the global tier can initiate specific mitigation policies localized to a particular node.
  • the global-tier mitigation policies are very similar to those of the local-tier in that multiple algorithms are used to determine a net attack probability.
  • Figure 7 depicts a flow diagram illustrating an example process of global-tier detection and mitigation, according to one embodiment.
  • software 270 on external server(s) 260A-N can periodically receive individual flow records and/or aggregate data (e.g., DA-based) from one or more local tier mechanisms (e.g., Figure 2A linecards 210A-N).
  • flow record data from one or more local tiers are received at block 710.
  • sorted aggregate data for the top N users is received based on several different criteria. Examples of criteria include heavy byte usage, heavy flows per user, and the like.
  • the global tier can receive alerts from multiple linecards 210A-N when an anomaly is initially detected.
  • the global tier can use the information from multiple local tiers to correlate and analyze the data using the anomaly algorithms, as is done at the local level.
  • flow data and aggregate data to a DA are correlated at block 720 while running anomaly algorithms.
  • any alerts can trigger the global tier to receive only the flow records of the specific addresses (i.e. source addresses, destination address, source-destination aggregates) for which the anomaly was detected.
  • the global tier mechanism e.g., software 270 on the external server(s) 260A-N] can address the detected anomalous traffic patterns identified during the global detection phase.
  • the initiated anomaly detection and mitigation tactics are similar to local-tier detection and mitigation, but incorporate mitigation policies specific to the global-tier.
  • the software can apply a more refined policy to control only the specific flows or flows-aggregates while allowing other non-anomalous flows to pass normally (thus, continuing access to the non-affected devices or by legitimate non- attacking users).
  • the global mitigation phase can apply any of the mitigation policies available on the local level. As indicated in block 740, such a global mitigation policy may be applied to one or more specific nodes based on information on the node that most contributed to the attack traffic.
  • the traffic patterns e.g., computed ratios/thresholds
  • the traffic patterns should begin to return to a "normal" state as the DDoS attack subsides.
  • any mitigation policies implemented in the local and global tier of the DDoS solution 150 can be terminated.
  • the DDoS solution 150 can automatically suspend any mitigation policies that were applied.
  • control of the mitigation policies can be transferred to an operator for manual or real-time handling. In a case where indicators of an attack remain, mitigation policies can continue to be implemented until traffic patterns return to normal. .
  • Z Mao Z Mao et al
  • the primary observations of Z Mao include the ideas that the majority of attacks (e.g., greater than 70%) last for less than an hour, use TCP, and TCP-based attacks primarily comprise of ACK or SYN floods. Additionally, packet rates are typically in the tens of thousands per second and maximum packet rates are approximately one million packets per second. Also, most attacks only consist of packets smaller than 100B.
  • the Z Mao algorithm presents a variety of indicators which would signify a possible DDoS attack.
  • a high packet rate in the tens of thousands per second or more is potentially an attack.
  • more than 95% of packets in the flows are either ICMP packets or UDP packets originating from a large number of source IPs, this flooding of respective ICMP or UDP packets can also be considered an attack.
  • an attack can be signified by any of the following: if more than 90% of traffic is TCP and all TCP packets have a single flag (e.g., SYN, RST, ACK); if more than 80% of traffic has packets smaller than 100B; if a small percentage of ingress interfaces or DAs may carry more than 90% of attack traffic; or if targeted services include http, ssh, dns, or ire.
  • a single flag e.g., SYN, RST, ACK
  • C Kotsokalis et al Another algorithm is by C Kotsokalis et al (hereinafter C Kotsokalis) and utilizes a threshold for detecting high-rate attacks to address Denial of Service (DoS) and DDoS attacks.
  • the router-based detection algorithm correlates various network traffic attributes observed before and during the attack. For example, a pattern of byte, packet, and flow counts can be observed, collected, and analyzed in a backbone router for a week.
  • an observation period can be defined as the period during which the number of byes, flows, and packets are counted.
  • the average number of bytes, flows, and packets are computed across several observation periods.
  • the maximum number of packets/flows/bytes seen across all the observation periods are monitored and tracked.
  • ratio calculations of maximum bytes to average bytes can be computed.
  • the aforementioned three ratios track each other fairly closely under normal traffic conditions.
  • MaxBytes/AvgBytes is approximately equal to MaxPkts/AvgPkts, which in turn is approximately equal to MaxFlows/AvgFlows.
  • a genuine increase in the number of packets or flows ought to correspond to a proportionate increase in the number of bytes.
  • C Kotsokalis algorithm can be extrapolated at the DA level by monitoring the traffic ratios to a server (instead of monitoring at the interface level).
  • the C Kotsokalis technique flags any surge of activity and correlates the ratios of packets or flows with that of bytes to detect a high-rate attack. For example, if the ratio of MaxPkts/AvgPkts or MaxFlows/AvgFlows is a predetermined factor (e.g., 1.25X, 1.5X, 2X) higher than MaxBytes/AvgBytes, then the anomaly can be flagged as an attack. As previously discussed, the three ratios track each other pretty closely under normal conditions. However, because most high-rate attacks generate numerous connections (i.e., flows) with very few packets in each, the packet and flow ratios likely will not track the byte count in the event of an attack and thus, can be flagged as an anomaly.
  • V Chatzigiannakis et al algorithm Another known theory that can be implemented as an anomaly algorithm is the V Chatzigiannakis et al algorithm (hereinafter V Chatzigiannakis).
  • V Chatzigiannakis The V Chatzigiannakis
  • Chatizigiannakis algorithm checks an entity, such as a user, computer, or link, for deviations from normal behavior and can be used for high-rate attacks.
  • Chatizigiannakis tracks packets and flows and monitors metrics such as the number of flows with a short lifetime, the number of flows with a small number of packets, a percentage of TCP/UDP traffic, and current packets/flows or average packets/flows from interface i to j.
  • data structures can be used to implement V
  • Chatizigiannakis such as, for example, a destination IP table which tracks the number of packets and flows for every pair of interfaces.
  • Another known theory that can be implemented as an anomaly algorithm is by Y Chen er al (hereinafter Y Chen).
  • the algorithm monitors traffic for a "super flow" to cover all packets sharing the same n bit prefix in their IPDA.
  • Y Chen watches for short term deviations from long-term average behavior.
  • the algorithm can monitor all flows at each interface and counts the incoming/outgoing packets per time slot. If there is an abnormal increase in the incoming rate on a super flow, the router will check for a pattern of change and how it propagates through the system.
  • the algorithm defines an abnormal traffic increase as a deviation from an average (DFA).
  • Y Chen can use a running weighted average to describe long-term behavior.
  • DDoS solution is herein described as operating on a flow-state basis, the DDoS solution is not limited to this platform and can be adapted for other platforms, including legacy systems (e.g., legacy routers, Intrusion Detection, Intrusion Prevention and Anti-DDOS systems).
  • legacy systems e.g., legacy routers, Intrusion Detection, Intrusion Prevention and Anti-DDOS systems.
  • legacy routers e.g., legacy routers, Intrusion Detection, Intrusion Prevention and Anti-DDOS systems
  • DA extrapolated to monitor traffic deviations at other levels
  • processes or blocks are presented in a given order, alternative embodiments may perform routines having steps, or employ systems having blocks, in a different order, and some processes or blocks may be deleted, moved, added, subdivided, combined, and/or modified to provide alternative or subcombinations.
  • Each of these processes or blocks may be implemented in a variety of different ways.
  • processes or blocks are at times shown as being performed in series, these processes or blocks may instead be performed in parallel, or may be performed at different times. Further any specific numbers noted herein are only examples: alternative implementations may employ differing values or ranges.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

L'invention porte sur des procédés et des systèmes de détection et d'atténuation d'attaques par déni de service distribué (DDoS) à haut débit. La présente invention envisage diverses techniques améliorées pour utiliser un mécanisme de collecte de statistiques à base de flux pour surveiller et détecter des écarts dans des données d'utilisation de serveur. Le procédé consiste en outre à combiner de multiples algorithmes d'anomalie d'une manière unique pour améliorer la précision d'identification d'une attaque DDoS à haut débit. La solution DDoS comprend une approche en deux phases, détection et atténuation, qui opèrent toutes les deux sur une base locale et une base globale. A l'aide d'une collecte de statistiques à base de flux, la solution DDoS surveille des données d'enregistrement de flux, sur un niveau individuel et un niveau agrégé, et détecte des écarts dans du trafic qui sont indicatifs d'une menace potentielle. La détection consiste à collecter et analyser des données d'état de flux de réseau afin de déterminer une probabilité d'attaque (typiquement par calcul d'une somme pondérée des résultats de multiples algorithmes) sur la base d'un écart de trafic, et afin de déterminer si une attaque provient d'une adresse usurpée ou légitime. La solution DDoS peut surveiller et analyser des données de flux afin d'identifier rapidement quand une attaque DDoS est en cours. En outre, les algorithmes d'anomalie peuvent être modifiés ou extrapolés pour obtenir les paramètres d'écart de trafic et en conséquence les probabilités d'attaque. Des politiques d'atténuation peuvent être basées sur la probabilité d'attaque déterminée et permettre à l'opérateur de configurer les actions appropriées pour l'attaque. Selon un mode de réalisation, la solution DDoS peut maîtriser l'attaque en temps réel sans aucune dégradation des performances ni de la puissance de traitement par l'intermédiaire d'un mécanisme local d'une carte de lignes. Selon un autre mode de réalisation, la solution DDoS comprend en outre un mécanisme global tel qu'une application logicielle externe qui prend une décision sur l'attaque sur une base plus globale avec une vue à l'échelle du réseau.
EP12865509.9A 2011-02-17 2012-02-16 Procédés et systèmes de détection et d'atténuation d'une attaque par déni de service distribué (ddos) à haut débit Withdrawn EP2676402A4 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US201161444083P 2011-02-17 2011-02-17
PCT/US2012/025362 WO2013105991A2 (fr) 2011-02-17 2012-02-16 Procédés et systèmes de détection et d'atténuation d'une attaque par déni de service distribué (ddos) à haut débit

Publications (2)

Publication Number Publication Date
EP2676402A2 true EP2676402A2 (fr) 2013-12-25
EP2676402A4 EP2676402A4 (fr) 2015-06-03

Family

ID=46653852

Family Applications (1)

Application Number Title Priority Date Filing Date
EP12865509.9A Withdrawn EP2676402A4 (fr) 2011-02-17 2012-02-16 Procédés et systèmes de détection et d'atténuation d'une attaque par déni de service distribué (ddos) à haut débit

Country Status (4)

Country Link
US (2) US9167004B2 (fr)
EP (1) EP2676402A4 (fr)
KR (1) KR101747079B1 (fr)
WO (1) WO2013105991A2 (fr)

Families Citing this family (135)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9412123B2 (en) 2003-07-01 2016-08-09 The 41St Parameter, Inc. Keystroke analysis
US10999298B2 (en) 2004-03-02 2021-05-04 The 41St Parameter, Inc. Method and system for identifying users and detecting fraud by use of the internet
US11301585B2 (en) 2005-12-16 2022-04-12 The 41St Parameter, Inc. Methods and apparatus for securely displaying digital images
US8938671B2 (en) 2005-12-16 2015-01-20 The 41St Parameter, Inc. Methods and apparatus for securely displaying digital images
US8151327B2 (en) 2006-03-31 2012-04-03 The 41St Parameter, Inc. Systems and methods for detection of session tampering and fraud prevention
US9112850B1 (en) 2009-03-25 2015-08-18 The 41St Parameter, Inc. Systems and methods of sharing information through a tag-based consortium
US10754913B2 (en) 2011-11-15 2020-08-25 Tapad, Inc. System and method for analyzing user device information
EP2817726A4 (fr) * 2012-02-20 2015-12-09 Virtustream Canada Holdings Inc Systèmes et procédés impliquant l'isolation d'hôte de machine virtuelle sur un réseau
US9633201B1 (en) * 2012-03-01 2017-04-25 The 41St Parameter, Inc. Methods and systems for fraud containment
US9521551B2 (en) 2012-03-22 2016-12-13 The 41St Parameter, Inc. Methods and systems for persistent cross-application mobile device identification
EP2850793B1 (fr) 2012-05-14 2016-09-21 Sable Networks, Inc Système et procédé destinés à garantir une équité d'abonné à l'aide d'une détection de valeurs aberrantes
WO2014022813A1 (fr) 2012-08-02 2014-02-06 The 41St Parameter, Inc. Systèmes et procédés d'accès à des enregistrements via des localisateurs de dérivé
CN102868685B (zh) * 2012-08-29 2015-04-15 北京神州绿盟信息安全科技股份有限公司 一种判定自动扫描行为的方法及装置
US11095665B2 (en) * 2012-08-31 2021-08-17 Fastly, Inc. User access rate limiting among content delivery nodes
US8943587B2 (en) * 2012-09-13 2015-01-27 Symantec Corporation Systems and methods for performing selective deep packet inspection
CN102833268B (zh) * 2012-09-17 2015-03-11 福建星网锐捷网络有限公司 抵抗无线网络泛洪攻击的方法、设备及系统
WO2014078569A1 (fr) 2012-11-14 2014-05-22 The 41St Parameter, Inc. Systèmes et procédés d'identification globale
US9456001B2 (en) * 2013-01-31 2016-09-27 Hewlett Packard Enterprise Development Lp Attack notification
US9692775B2 (en) * 2013-04-29 2017-06-27 Telefonaktiebolaget Lm Ericsson (Publ) Method and system to dynamically detect traffic anomalies in a network
US9344440B2 (en) * 2013-06-20 2016-05-17 Arbor Networks, Inc. Forced alert thresholds for profiled detection
US9282113B2 (en) * 2013-06-27 2016-03-08 Cellco Partnership Denial of service (DoS) attack detection systems and methods
US9172721B2 (en) 2013-07-16 2015-10-27 Fortinet, Inc. Scalable inline behavioral DDOS attack mitigation
CN104348811B (zh) * 2013-08-05 2018-01-26 深圳市腾讯计算机系统有限公司 分布式拒绝服务攻击检测方法及装置
US10902327B1 (en) 2013-08-30 2021-01-26 The 41St Parameter, Inc. System and method for device identification and uniqueness
CN103442076B (zh) * 2013-09-04 2016-09-07 上海海事大学 一种云存储系统的可用性保障方法
CN103581172A (zh) * 2013-09-10 2014-02-12 昆山奥德鲁自动化技术有限公司 长距离以太网tcp协议的实现方法
US9503465B2 (en) 2013-11-14 2016-11-22 At&T Intellectual Property I, L.P. Methods and apparatus to identify malicious activity in a network
CN104753863B (zh) * 2013-12-26 2018-10-26 中国移动通信集团公司 一种分布式拒绝服务攻击的防御方法、设备及系统
CN103916387B (zh) * 2014-03-18 2017-06-06 汉柏科技有限公司 一种防护ddos攻击的方法及系统
US9686312B2 (en) * 2014-07-23 2017-06-20 Cisco Technology, Inc. Verifying network attack detector effectiveness
US9800592B2 (en) 2014-08-04 2017-10-24 Microsoft Technology Licensing, Llc Data center architecture that supports attack detection and mitigation
WO2016032491A1 (fr) * 2014-08-28 2016-03-03 Hewlett Packard Enterprise Development Lp Détection distribuée d'acteurs malveillants en nuage
US10509909B2 (en) 2014-09-06 2019-12-17 Mazebolt Technologies Ltd. Non-disruptive DDoS testing
US10091312B1 (en) 2014-10-14 2018-10-02 The 41St Parameter, Inc. Data structures for intelligently resolving deterministic and probabilistic device identifiers to device profiles and/or groups
US11533255B2 (en) 2014-11-14 2022-12-20 Nicira, Inc. Stateful services on stateless clustered edge
CN104378288B (zh) * 2014-11-19 2017-11-21 清华大学 基于路由交换范式的构件组装方法及系统
US9769186B2 (en) * 2014-12-23 2017-09-19 Mcafee, Inc. Determining a reputation through network characteristics
US10484406B2 (en) * 2015-01-22 2019-11-19 Cisco Technology, Inc. Data visualization in self-learning networks
US10484405B2 (en) 2015-01-23 2019-11-19 Cisco Technology, Inc. Packet capture for anomalous traffic flows
US20160219066A1 (en) * 2015-01-26 2016-07-28 Cisco Technology, Inc. Event correlation in a network merging local graph models from distributed nodes
US10187404B2 (en) * 2015-03-18 2019-01-22 Hrl Laboratories, Llc System and method for detecting attacks on mobile ad hoc networks based on network flux
CN106161333B (zh) * 2015-03-24 2021-01-15 华为技术有限公司 基于sdn的ddos攻击防护方法、装置及系统
US9866576B2 (en) 2015-04-17 2018-01-09 Centripetal Networks, Inc. Rule-based network-threat detection
US10033766B2 (en) * 2015-06-05 2018-07-24 Cisco Technology, Inc. Policy-driven compliance
US10536357B2 (en) 2015-06-05 2020-01-14 Cisco Technology, Inc. Late data detection in data center
US10142353B2 (en) 2015-06-05 2018-11-27 Cisco Technology, Inc. System for monitoring and managing datacenters
CN106487742B (zh) * 2015-08-24 2020-01-03 阿里巴巴集团控股有限公司 用于验证源地址有效性的方法及装置
WO2017035717A1 (fr) * 2015-08-29 2017-03-09 华为技术有限公司 Procédé de détection d'attaque de déni de service distribué et dispositif associé
US9838409B2 (en) * 2015-10-08 2017-12-05 Cisco Technology, Inc. Cold start mechanism to prevent compromise of automatic anomaly detection systems
US10063575B2 (en) * 2015-10-08 2018-08-28 Cisco Technology, Inc. Anomaly detection in a network coupling state information with machine learning outputs
GB2547202B (en) * 2016-02-09 2022-04-20 Darktrace Ltd An anomaly alert system for cyber threat detection
US10333968B2 (en) * 2016-02-10 2019-06-25 Verisign, Inc. Techniques for detecting attacks in a publish-subscribe network
US11297098B2 (en) 2016-03-10 2022-04-05 Telefonaktiebolaget Lm Ericsson (Publ) DDoS defence in a packet-switched network
US10659333B2 (en) * 2016-03-24 2020-05-19 Cisco Technology, Inc. Detection and analysis of seasonal network patterns for anomaly detection
US10432650B2 (en) 2016-03-31 2019-10-01 Stuart Staniford System and method to protect a webserver against application exploits and attacks
US10681059B2 (en) * 2016-05-25 2020-06-09 CyberOwl Limited Relating to the monitoring of network security
JP6599819B2 (ja) * 2016-06-02 2019-10-30 アラクサラネットワークス株式会社 パケット中継装置
US9584381B1 (en) * 2016-10-10 2017-02-28 Extrahop Networks, Inc. Dynamic snapshot value by turn for continuous packet capture
US10715548B2 (en) * 2016-10-17 2020-07-14 Akamai Technologies, Inc. Detecting device masquerading in application programming interface (API) transactions
US10305931B2 (en) * 2016-10-19 2019-05-28 Cisco Technology, Inc. Inter-domain distributed denial of service threat signaling
CN106790035A (zh) * 2016-12-15 2017-05-31 郑州云海信息技术有限公司 一种协议分析装置、方法及系统
US10397270B2 (en) * 2017-01-04 2019-08-27 A10 Networks, Inc. Dynamic session rate limiter
AU2018207582B2 (en) 2017-01-14 2021-12-23 Hyprfire Pty Ltd Method and system for detecting and mitigating a denial of service attack
US10887341B2 (en) 2017-03-06 2021-01-05 Radware, Ltd. Detection and mitigation of slow application layer DDoS attacks
US10951648B2 (en) 2017-03-06 2021-03-16 Radware, Ltd. Techniques for protecting against excessive utilization of cloud services
US10567285B2 (en) * 2017-03-17 2020-02-18 Citrix Systems, Inc. Increasing QoS throughput and efficiency through lazy byte batching
US11381509B2 (en) 2017-03-17 2022-07-05 Citrix Systems, Inc. Increased packet scheduling throughput and efficiency using úber batching
US10476673B2 (en) 2017-03-22 2019-11-12 Extrahop Networks, Inc. Managing session secrets for continuous packet capture systems
CN107040554B (zh) * 2017-06-22 2020-07-17 四川长虹电器股份有限公司 一种防御cc攻击的方法
EP3422659A1 (fr) * 2017-06-30 2019-01-02 Thomson Licensing Procédé de blocage des attaques par déni de service distribué et appareil correspondant
US10951584B2 (en) 2017-07-31 2021-03-16 Nicira, Inc. Methods for active-active stateful network service cluster
US11296984B2 (en) 2017-07-31 2022-04-05 Nicira, Inc. Use of hypervisor for active-active stateful network service cluster
US11570092B2 (en) * 2017-07-31 2023-01-31 Nicira, Inc. Methods for active-active stateful network service cluster
US11005865B2 (en) * 2017-08-31 2021-05-11 Charter Communications Operating, Llc Distributed denial-of-service attack detection and mitigation based on autonomous system number
US10911473B2 (en) * 2017-08-31 2021-02-02 Charter Communications Operating, Llc Distributed denial-of-service attack detection and mitigation based on autonomous system number
CN107465693B (zh) * 2017-09-18 2020-06-16 北京星选科技有限公司 请求消息处理方法和装置
US10116671B1 (en) 2017-09-28 2018-10-30 International Business Machines Corporation Distributed denial-of-service attack detection based on shared network flow information
US9967292B1 (en) 2017-10-25 2018-05-08 Extrahop Networks, Inc. Inline secret sharing
US11606387B2 (en) * 2017-12-21 2023-03-14 Radware Ltd. Techniques for reducing the time to mitigate of DDoS attacks
US11032315B2 (en) * 2018-01-25 2021-06-08 Charter Communications Operating, Llc Distributed denial-of-service attack mitigation with reduced latency
JP6943196B2 (ja) * 2018-02-05 2021-09-29 日本電信電話株式会社 制御システム及び制御方法
US10389574B1 (en) 2018-02-07 2019-08-20 Extrahop Networks, Inc. Ranking alerts based on network monitoring
US10038611B1 (en) 2018-02-08 2018-07-31 Extrahop Networks, Inc. Personalization of alerts based on network monitoring
US10270794B1 (en) 2018-02-09 2019-04-23 Extrahop Networks, Inc. Detection of denial of service attacks
US10382340B1 (en) * 2018-02-09 2019-08-13 Juniper Networks, Inc. Dynamic filtering of network traffic
US11153122B2 (en) 2018-02-19 2021-10-19 Nicira, Inc. Providing stateful services deployed in redundant gateways connected to asymmetric network
US11347867B2 (en) 2018-05-18 2022-05-31 Ns Holdings Llc Methods and apparatuses to evaluate cyber security risk by establishing a probability of a cyber-attack being successful
US10411978B1 (en) 2018-08-09 2019-09-10 Extrahop Networks, Inc. Correlating causes and effects associated with network activity
US10594718B1 (en) 2018-08-21 2020-03-17 Extrahop Networks, Inc. Managing incident response operations based on monitored network activity
CN109067787B (zh) * 2018-09-21 2019-11-26 腾讯科技（深圳）有限公司 分布式拒绝服务ddos攻击检测方法和装置
US10768990B2 (en) 2018-11-01 2020-09-08 International Business Machines Corporation Protecting an application by autonomously limiting processing to a determined hardware capacity
RU2703329C1 (ru) * 2018-11-30 2019-10-16 Открытое Акционерное Общество "Информационные Технологии И Коммуникационные Системы" Способ обнаружения несанкционированного использования сетевых устройств ограниченной функциональности из локальной сети и предотвращения исходящих от них распределенных сетевых атак
US10965702B2 (en) 2019-05-28 2021-03-30 Extrahop Networks, Inc. Detecting injection attacks using passive network monitoring
US11522874B2 (en) 2019-05-31 2022-12-06 Charter Communications Operating, Llc Network traffic detection with mitigation of anomalous traffic and/or classification of traffic
US11165814B2 (en) 2019-07-29 2021-11-02 Extrahop Networks, Inc. Modifying triage information based on network monitoring
US10742530B1 (en) 2019-08-05 2020-08-11 Extrahop Networks, Inc. Correlating network traffic that crosses opaque endpoints
US11388072B2 (en) 2019-08-05 2022-07-12 Extrahop Networks, Inc. Correlating network traffic that crosses opaque endpoints
US10742677B1 (en) 2019-09-04 2020-08-11 Extrahop Networks, Inc. Automatic determination of user roles and asset types based on network monitoring
US20210105300A1 (en) * 2019-10-08 2021-04-08 Secure64 Software Corporation Methods and systems that detect and deflect denial-of-service attacks
CN110855657B (zh) * 2019-11-07 2021-05-18 深圳市高德信通信股份有限公司 一种计算机网络用的网络安全控制系统
US11165823B2 (en) 2019-12-17 2021-11-02 Extrahop Networks, Inc. Automated preemptive polymorphic deception
WO2021137182A1 (fr) * 2019-12-31 2021-07-08 Edgehawk Security Ltd. Techniques de détection et d'atténuation désagrégées d'attaques par refus de service distribuées
US11405418B2 (en) 2020-06-16 2022-08-02 Bank Of America Corporation Automated distributed denial of service attack detection and prevention
US11652833B2 (en) * 2020-07-24 2023-05-16 Microsoft Technology Licensing, Llc Detection of anomalous count of new entities
US11601457B2 (en) * 2020-08-26 2023-03-07 Bank Of America Corporation Network traffic correlation engine
CN112165464B (zh) * 2020-09-15 2021-11-02 江南大学 一种基于深度学习的工控混合入侵检测方法
US11463466B2 (en) 2020-09-23 2022-10-04 Extrahop Networks, Inc. Monitoring encrypted network traffic
EP4218212A4 (fr) 2020-09-23 2024-10-16 ExtraHop Networks, Inc. Surveillance de trafic réseau chiffré
US11765195B2 (en) 2021-02-16 2023-09-19 Icf International Distributed network-level probabilistic attack graph generation
US12034755B2 (en) * 2021-03-18 2024-07-09 International Business Machines Corporation Computationally assessing and remediating security threats
CN113179256B (zh) * 2021-04-12 2022-02-08 中国电子科技集团公司第三十研究所 一种时间同步系统时间信息安全融合方法及系统
CN113365249B (zh) * 2021-05-06 2023-01-03 西安交通大学 一种面向5G大规模机器通信的终端劫持DDoS攻击检测方法
US11349861B1 (en) 2021-06-18 2022-05-31 Extrahop Networks, Inc. Identifying network entities based on beaconing activity
US11962615B2 (en) 2021-07-23 2024-04-16 Bank Of America Corporation Information security system and method for denial-of-service detection
CN113536508B (zh) * 2021-07-30 2023-11-21 齐鲁工业大学 一种制造网络节点分类方法及系统
US11296967B1 (en) 2021-09-23 2022-04-05 Extrahop Networks, Inc. Combining passive network analysis and active probing
EP4413697A4 (fr) 2021-10-07 2025-08-06 Mazebolt Tech Ltd Procédés et systèmes non perturbateurs de test de diagnostic et d'attaque
US11799761B2 (en) 2022-01-07 2023-10-24 Vmware, Inc. Scaling edge services with minimal disruption
US12348557B2 (en) 2022-01-19 2025-07-01 Arbor Networks, Inc. Slowing requests from malicious network clients using a tarpitting technique
US11962564B2 (en) 2022-02-15 2024-04-16 VMware LLC Anycast address for network address translation at edge
US11843606B2 (en) 2022-03-30 2023-12-12 Extrahop Networks, Inc. Detecting abnormal data access based on data similarity
CN115190107B (zh) * 2022-07-07 2023-04-18 四川川大智胜系统集成有限公司 基于泛域名多子系统管理方法、管理终端及可读存储介质
US12470621B2 (en) 2022-07-22 2025-11-11 VMware LLC Transparent load balancing
US12052131B2 (en) 2022-11-08 2024-07-30 T-Mobile Usa, Inc. Multi-dimensional correlation for network incident management
EP4254876B1 (fr) * 2023-03-21 2025-11-12 Ovh Procédés et systèmes de détection d'attaques par déni de service sur un réseau
EP4436108B1 (fr) * 2023-03-22 2026-08-05 Ovh Systèmes et procédés de configuration de dispositifs de réseautage
CN117395070B (zh) * 2023-11-16 2024-05-03 国家计算机网络与信息安全管理中心 一种基于流量特征的异常流量检测方法
US20250220032A1 (en) * 2024-01-01 2025-07-03 A10 Networks, Inc. Network traffic behavioral histogram analysis and attack detection
CN117879969A (zh) * 2024-02-06 2024-04-12 国家计算机网络与信息安全管理中心 一种数据异常监测方法、装置、电子设备及存储介质
US20250350629A1 (en) * 2024-05-07 2025-11-13 Microsoft Technology Licensing, Llc Adaptive multi-dimensional anomaly detection
WO2026076559A1 (fr) * 2024-10-08 2026-04-16 Mediatek Inc. Méthode pour protéger un ue d'une attaque d'usurpation gnss
FR3170047A1 (fr) * 2024-12-12 2026-06-19 Commissariat à l'Energie Atomique et aux Energies Alternatives Procédé de surveillance du trafic de données d’un système de communication
US12483384B1 (en) 2025-04-16 2025-11-25 Extrahop Networks, Inc. Resynchronizing encrypted network traffic
US12652312B1 (en) 2025-10-21 2026-06-09 Extrahop Networks, Inc. Detecting social engineering threats
US12647441B1 (en) 2026-02-04 2026-06-02 Extrahop Networks, Inc. Ranking entity importance via network monitoring

Family Cites Families (43)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH03108845A (ja) 1989-09-21 1991-05-09 Toshiba Corp 輻輳回避制御方式
US5014265A (en) 1989-11-30 1991-05-07 At&T Bell Laboratories Method and apparatus for congestion control in a data network
JP3241716B2 (ja) 1990-08-31 2001-12-25 株式会社東芝 Ａｔｍ交換方法
US5555100A (en) 1993-10-07 1996-09-10 Audiofax, Inc. Facsimile store and forward system with local interface translating DTMF signals into store and forward system commands
GB9326476D0 (en) 1993-12-24 1994-02-23 Newbridge Networks Corp Network
US5436886A (en) 1994-07-14 1995-07-25 Northern Telecom Limited ATM switch in dual switch plane operation
US5467343A (en) 1994-07-27 1995-11-14 Motorola, Inc. Method and device for consolidation of preferential resource constraints
JP2723097B2 (ja) 1995-12-04 1998-03-09 日本電気株式会社 Ｑｏｓルーティング装置
US5995503A (en) 1996-06-12 1999-11-30 Bay Networks, Inc. Method and apparatus for providing quality of service routing in a network
US5701291A (en) 1996-08-22 1997-12-23 The Whitaker Corporation ATM systems
US5909440A (en) 1996-12-16 1999-06-01 Juniper Networks High speed variable length best match look-up in a switching device
US6081522A (en) 1997-06-30 2000-06-27 Sun Microsystems, Inc. System and method for a multi-layer network element
US6081524A (en) 1997-07-03 2000-06-27 At&T Corp. Frame relay switched data service
US6072797A (en) 1997-07-31 2000-06-06 International Business Machines Corporation Methods, apparatus and computer program products for aggregated transmission groups in high speed networks
US6006264A (en) 1997-08-01 1999-12-21 Arrowpoint Communications, Inc. Method and system for directing a flow between a client and a server
US6249519B1 (en) 1998-04-16 2001-06-19 Mantra Communications Flow based circuit steering in ATM networks
GB9810376D0 (en) 1998-05-15 1998-07-15 3Com Technologies Ltd Computation of traffic flow by scaling sample packet data
US6487170B1 (en) 1998-11-18 2002-11-26 Nortel Networks Limited Providing admission control and network quality of service with a distributed bandwidth broker
US6760775B1 (en) 1999-03-05 2004-07-06 At&T Corp. System, method and apparatus for network service load and reliability management
US6801502B1 (en) 1999-05-07 2004-10-05 At&T Corp. Method and apparatus for load-sensitive routing of long-lived packet flows
US6195697B1 (en) 1999-06-02 2001-02-27 Ac Properties B.V. System, method and article of manufacture for providing a customer interface in a hybrid network
US6574195B2 (en) 2000-04-19 2003-06-03 Caspian Networks, Inc. Micro-flow management
DE60108861T2 (de) 2000-05-05 2006-04-06 Nomadix, Inc., Westlake Village Gerät und verfahren zur überwachung der netzwerkauslastung
US6944673B2 (en) * 2000-09-08 2005-09-13 The Regents Of The University Of Michigan Method and system for profiling network flows at a measurement point within a computer network
NZ516346A (en) * 2001-12-21 2004-09-24 Esphion Ltd A device for evaluating traffic on a computer network to detect traffic abnormalities such as a denial of service attack
US7681235B2 (en) 2003-05-19 2010-03-16 Radware Ltd. Dynamic network protection
US7266754B2 (en) * 2003-08-14 2007-09-04 Cisco Technology, Inc. Detecting network denial of service attacks
US7854003B1 (en) * 2004-03-19 2010-12-14 Verizon Corporate Services Group Inc. & Raytheon BBN Technologies Corp. Method and system for aggregating algorithms for detecting linked interactive network connections
US8243593B2 (en) * 2004-12-22 2012-08-14 Sable Networks, Inc. Mechanism for identifying and penalizing misbehaving flows in a network
KR100628328B1 (ko) * 2005-03-10 2006-09-27 한국전자통신연구원 적응적 침해 방지 장치 및 방법
US8001601B2 (en) * 2006-06-02 2011-08-16 At&T Intellectual Property Ii, L.P. Method and apparatus for large-scale automated distributed denial of service attack detection
US8248946B2 (en) * 2006-06-06 2012-08-21 Polytechnic Institute of New York Unversity Providing a high-speed defense against distributed denial of service (DDoS) attacks
US8015249B2 (en) 2006-10-10 2011-09-06 Microsoft Corporation Mitigating data usage in messaging applications
JP4905086B2 (ja) 2006-11-29 2012-03-28 富士通株式会社 イベント種類推定システム、イベント種類推定方法およびイベント種類推定プログラム
US8176167B2 (en) 2006-12-05 2012-05-08 Qualcomm Incorporated Methods and apparaus for requesting wireless communication device performance data and providing the data in optimal file size
EP2142994B1 (fr) 2007-03-30 2014-07-09 CA, Inc. Procédé et système de détection statistique d'une anomalie de réseau
EP2112800B1 (fr) * 2008-04-25 2017-12-27 Deutsche Telekom AG Procédé et système pour une reconnaissance améliorée des attaques sur des systèmes informatiques
US8069471B2 (en) * 2008-10-21 2011-11-29 Lockheed Martin Corporation Internet security dynamics assessment system, program product, and related methods
CN102204167B (zh) 2008-10-31 2015-07-01 电子湾有限公司 测试应用编程接口(api)调用的方法、系统和响应仿真器
US8280968B1 (en) * 2009-04-20 2012-10-02 The Florida State University Research Foundation, Inc. Method of detecting compromised computers in a network
GB2470071B (en) 2009-05-08 2013-06-05 Vodafone Plc Telcommunications networks
US9195713B2 (en) 2009-11-08 2015-11-24 Hewlett-Packard Development Company, L.P. Outlier data point detection
US8495196B2 (en) 2010-03-22 2013-07-23 Opanga Networks, Inc. Systems and methods for aligning media content delivery sessions with historical network usage

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See references of WO2013105991A2 *

Also Published As

Publication number Publication date
KR20140037052A (ko) 2014-03-26
US20150312273A1 (en) 2015-10-29
WO2013105991A3 (fr) 2013-10-17
EP2676402A4 (fr) 2015-06-03
WO2013105991A2 (fr) 2013-07-18
KR101747079B1 (ko) 2017-06-14
US20120216282A1 (en) 2012-08-23
US9167004B2 (en) 2015-10-20

Similar Documents

Publication Publication Date Title
US9167004B2 (en) Methods and systems for detecting and mitigating a high-rate distributed denial of service (DDoS) attack
US7607170B2 (en) Stateful attack protection
US8001601B2 (en) Method and apparatus for large-scale automated distributed denial of service attack detection
Xue et al. Linkscope: Toward detecting target link flooding attacks
US9935974B2 (en) Hardware-logic based flow collector for distributed denial of service (DDoS) attack mitigation
Mirkovic et al. D-WARD: a source-end defense against flooding denial-of-service attacks
Hofstede et al. Towards real-time intrusion detection for NetFlow and IPFIX
US10911473B2 (en) Distributed denial-of-service attack detection and mitigation based on autonomous system number
EP2158740B1 (fr) Traitement de flux de paquets
Kumar et al. A distributed approach using entropy to detect DDoS attacks in ISP domain
US7743415B2 (en) Denial of service attacks characterization
Chen et al. Collaborative change detection of DDoS attacks on community and ISP networks
Chou et al. Proactive surge protection: a defense mechanism for bandwidth-based attacks
Noh et al. Protection against flow table overflow attack in software defined networks
Şimşek A new metric for flow‐level filtering of low‐rate DDoS attacks
Mohammadi et al. Practical extensions to countermeasure dos attacks in software defined networking
Ahmed Investigation model for DDoS attack detection in real-time
Xia et al. Cids: Adapting legacy intrusion detection systems to the cloud with hybrid sampling
CN121690842A (zh) 网络攻击防护方法、交换设备、介质和程序产品
Reichle et al. Analysis and detection of DDoS attacks in the internet backbone using netflow logs
Sinha et al. SrcTCAM-Def: A Source-based Detection System against Slow-Rate TCAM DDoS Attacks in SDN
Sardana et al. Dual-level attack detection and characterization for networks under DDoS
Ahmed Detection and avoidance technique of anomalous congestion at the network gateways
Jeong et al. An effective DDoS attack detection and packet-filtering scheme
Luo et al. Differentiated service protection of multimedia transmission via detection of traffic anomalies

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20130826

AK Designated contracting states

Kind code of ref document: A2

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

DAX Request for extension of the european patent (deleted)
A4 Supplementary search report drawn up and despatched

Effective date: 20150506

RIC1 Information provided on ipc code assigned before grant

Ipc: H04L 12/22 20060101AFI20150428BHEP

Ipc: H04L 12/26 20060101ALI20150428BHEP

Ipc: H04L 29/06 20060101ALI20150428BHEP

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20180901