WO2002025402A2 - Systems and methods that protect networks and devices against denial of service attacks - Google Patents

Systems and methods that protect networks and devices against denial of service attacks Download PDF

Info

Publication number
WO2002025402A2
WO2002025402A2 PCT/US2001/029336 US0129336W WO0225402A2 WO 2002025402 A2 WO2002025402 A2 WO 2002025402A2 US 0129336 W US0129336 W US 0129336W WO 0225402 A2 WO0225402 A2 WO 0225402A2
Authority
WO
WIPO (PCT)
Prior art keywords
packets
dos
attack
dos attack
packet
Prior art date
Application number
PCT/US2001/029336
Other languages
French (fr)
Other versions
WO2002025402A3 (en
Inventor
Robert J. Donaghey
Original Assignee
Bbnt Solutions Llc
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 Bbnt Solutions Llc filed Critical Bbnt Solutions Llc
Priority to AU2002211242A priority Critical patent/AU2002211242A1/en
Publication of WO2002025402A2 publication Critical patent/WO2002025402A2/en
Publication of WO2002025402A3 publication Critical patent/WO2002025402A3/en

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/14Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
    • H04L63/1441Countermeasures against malicious traffic
    • H04L63/1458Denial of Service

Definitions

  • the present invention relates generally to networks and, more particularly, to systems and methods that protect communication networks and devices from denial of service attacks.
  • DoS attacks represent a major threat to the continuous operations of network devices.
  • DDoS Distributed DoS
  • traffic emanates from a wide range of compromised systems, and packets from these systems are directed at one or more target hosts, e.g., web servers.
  • target hosts e.g., web servers.
  • DoS attacks include smurf attacks, SYN flood attacks, and Ping of Death attacks. All of these may be effected as distributed DoS attacks, where many compromised network devices become the unwitting source of DoS traffic.
  • a smurf attack is an assault on a network that floods the network with excessive messages in order to impede normal traffic.
  • An attacking device sends ping requests to a broadcast address on the target network. The attacking device sets the return address to the victim's address. The broadcast address can generate hundreds of response messages from unwitting network devices that eventually overload the target network.
  • a SYN flood attack is an assault on a network that prevents a Transmission
  • Control Protocol/Internet Protocol (TCP/IP) server from servicing other users.
  • An attacking device sends a counterfeit source address to the server so that a final acknowledgment to the server's SYNchronize-ACKnowledge (SNY-ACK) response in the handshaking sequence is not sent. As a result, the server continues to execute the handshaking sequence until the server either overloads or crashes.
  • a Ping of Death attack is an assault on a target computer.
  • An attacking device causes the target computer to crash by sending a packet having an invalid packet size value in the packet's header.
  • ISPs Ingress packet filtering by ISPs makes tracking attack sources easier, by limiting the range of spoofed source addresses available to DoS traffic generators, but it does not prevent such traffic from reaching targets. Since DoS traffic streams often originate from outside a target's ISP, and because it is currently infeasible to filter traffic at border gateway protocol (BGP) peering points, ingress filtering relies on all other ISPs to provide protection, a bad strategy in the global Internet environment.
  • BGP border gateway protocol
  • DoS attacks With the proliferation of freely available DoS attack software, DoS attacks will become more sophisticated and more frequent and, therefore, produce more far-reaching consequences in the future. Simple filtering, based on examination of IP and TCP layer headers, will become less and less effective against more sophisticated attacks. Even traffic characterization technologies, such as Multi- Protocol Layer Switching (MPLS), that employ high speed header analysis facilities will become inappropriate for filtering DoS traffic, as the rapid reconfiguration required to respond to attacks would impose a serious burden on the backbone traffic engineering system, which is optimized for packet forwarding. Current attempts to prevent DoS attacks involve an ISP's network operations center (NOC) manually attempting to intervene in the attack.
  • NOC network operations center
  • the NOC may not be able to "break into” the network connection to thwart the attack. As a result, the NOC may need to spend many hours trying to filter the attacker's data out of their network, while at the same time calming their customers.
  • DoS attacks Since a successful DoS attack causes the customer's local network, firewall, and possibly web server to become unstable and/or unusable, those customers who rely on electronic commerce are particularly affected by DoS attacks.
  • the most advanced intrusion detection systems look for specific signatures of attacks in a data flow and then send a message to an operator for manual intervention. By the time the operator attempts to intervene, however, damage from the DoS attack may have already occurred.
  • a system protects against DoS attacks.
  • the system includes a service provider and a triage device.
  • the service provider receives a signal indicating detection of a DoS attack, receives one or more packets intended for a victim device, and transmits the one or more packets to the triage device.
  • the triage device determines, for each received packet, whether the packet is part of a DoS attack and forwards any packets that are unrelated to the DoS attack to the victim device.
  • a method protects against DoS attacks.
  • the method includes detecting the occurrence of a DoS attack, determining a target of the DoS attack, intercepting packets destined for the target, and preventing packets that are related to the DoS attack from reaching the target.
  • a device for protecting against DoS attacks includes a memory and a processor that receives, once a DoS attack has been detected, packets from a service provider, determines, for each packet addressed to the intended target, whether a packet is part of the DoS attack, forwards a packet determined not to be part of the DoS attack to a target device, and discards and/ or proxies a reply to a packet determined to be part of the DoS attack.
  • a method that protects against DoS attacks is provided.
  • the method includes passively recording, via an attack detection sensor, packets transmitted in a network, detecting an occurrence of a DoS attack, transferring, in response to the detecting, packets for a target of the DoS attack from a service provider to a triage device, retrieving recently recorded packets from the attack detection sensor, determining, for each transferred packet, whether the packet is part of the DoS attack, forwarding a packet determined not to be part of the DoS attack to the target, and discarding or proxying a reply to a packet determined to be part of the DoS attack.
  • a passive DoS attack sensor is provided.
  • the DoS attack sensor includes a memory that stores instructions and information relating to packets transferred in a network.
  • the DoS attack sensor also includes a processor that monitors the packets, stores the information in the memory, detects a DoS signature in one or more of the packets, sends a signal to a service provider in response to the detecting, and transfers the information in the memory for use in determining a history of the one or more packets.
  • FIG. l illustrates an exemplary network in which systems and methods, consistent with the present invention, that protect against denial of service attacks may be implemented;
  • FIG. 2 illustrates an exemplary triage device or attack detection sensor device configuration consistent with the present invention
  • FIG. 3 illustrates an exemplary database that maybe associated with the triage device or attack detection sensor device of FIG. 2;
  • FIG. 4 illustrates an exemplary denial of service attack scenario
  • FIG. 5 illustrates exemplary processing of an attack detection sensor consistent with the present invention
  • FIGS. 6A and 6B illustrate an exemplary process for protecting communication networks and devices against denial of service attacks in an implementation consistent with the present invention.
  • Systems and methods consistent with the present invention protect communication networks and devices against denial of service attacks.
  • a service provider Upon detection of a DoS attack, a service provider redirects traffic away from a targeted host (or hosts) and toward a triage device, that may use a combination of packet destruction, proxying for the target, other filtering mechanisms and prioritized packet forwarding to protect intended targets from attack.
  • the triage device diverts the brunt of the attack from the targets, allowing them to continue to operate during a DoS attack. Even DoS attacks that might overwhelm the access link capacity of a target can be handled by the triage device, since a service provider can provision very high capacity access links for this service.
  • Network devices can be configured to automatically detect DoS attacks and trigger the invocation of the triage device, and attacked hosts can request the invocation of the triage device through any available communication channels.
  • FIG. l illustrates an exemplary network loo in which systems and methods, consistent with the present invention, that protect against denial of service attacks may be implemented.
  • network loo includes multiple tier one service providers (SPs) 112-116, tier two service providers 122-126, customers 131-136, a triage device 140, and an attack detection sensor (ADS) 145.
  • SPs tier one service providers
  • ADS attack detection sensor
  • the tier one SPs 112-116 may include, for example, large national ISPs.
  • the tier one SPs exchange traffic with each other directly. This is known as peering. Every tier one SP peers with every other tier one SP.
  • the tier two SPs 122-126 may include, for example, regional ISPs or smaller SPs that rely on a tier one SP to provide transit service.
  • the tier two SPs generally connect to one or more tier one SP.
  • the customers 131-136 may include one or more host devices (not shown) that connect to a corresponding tier one or tier two SP 112-126 via a wired, wireless, or optical connection.
  • the host devices may include, for example, a server, personal computer, or the like.
  • the host devices may be directly connected to a SP 112-126 or may be connected to a SP 112-126 through one or more local networks (not shown).
  • the triage device 140 may include, according to an exemplary implementation, a high-end computer, a server or collection of servers, or the like, capable of protecting one or more network devices in response to a DoS attack.
  • the triage device 140 may be connected to, or implemented within, a SP 112-126 or another network device. Connection of the triage device 140 to a SP 112-126 or network device should be of such a capacity so as not to be overwhelmed by the large amount of traffic commonly associated with DoS attacks. As illustrated in FIG. 1, the triage device 140 connects to a SP or network device in such a way as to be out of the regular flow of network traffic. Network traffic may, as will be described in more detail below, be routed through the triage device 140 in those situations where a DoS attack has been detected.
  • the attack detection sensor device 145 may include, according to an exemplary implementation, a personal computer or the like, capable of passively monitoring traffic and detecting the presence of a DoS attack.
  • the attack detection sensor device 145 may be connected to, or implemented within, a SP 112-126 or another network device.
  • the number of components illustrated in FIG. 1 is provided for simplicity.
  • a typical network 100 may include a larger or smaller number of SPs 112-126, customers 131-136, triage devices 140, and attack detection sensor devices 145.
  • FIG. 2 illustrates an exemplary triage device 140 or attack detection sensor device 145 configuration consistent with the present invention.
  • the exemplary triage/ ADS device 140/145 includes a bus 202, a processor 204, a main memory 206, a read only memory (ROM) 208, a storage device 210, an optional input device 212, an optional output device 214, and a communication interface 216.
  • the bus 202 permits communication among the components of the triage/ ADS device 140/145.
  • the processor 204 may include any type of conventional processor or microprocessor that interprets and executes instructions.
  • the main memory 206 may include a random access memory (RAM) or another type of dynamic storage device that stores information and instructions for execution by the processor 204.
  • Main memory 206 may also be used to store temporary variables or other intermediate information during execution of instructions by processor 204.
  • ROM 208 may include a conventional ROM device and/or another type of static storage device that stores static information and instructions for processor 204.
  • the storage device 210 may include a magnetic disk or optical disk and its corresponding drive and/or some other type of magnetic or optical recording medium and its corresponding drive for storing information and/or instructions.
  • the input device 212 may include any conventional mechanism that permits an operator to input information to the triage/ADS device 140/145, such as a keyboard, a mouse, a microphone, a pen, voice recognition and/or biometric mechanisms, etc.
  • the output device 214 may include any conventional mechanism that outputs information to the operator, including a display, a printer, a pair of speakers, etc.
  • the communication interface 216 may include any transceiver-like mechanism that enables the triage/ADS device 140/145 to communicate with other devices and/or systems, such as SPs 112-126 or customers 131-136.
  • the communication interface 216 may include a modem or an Ethernet interface to a network.
  • communication interface 216 may include other mechanisms for communicating via a data network.
  • the triage/ADS device 140/145 protects against denial of service attacks in response to processor 204 executing sequences of instructions contained in a computer-readable medium, such as memory 206.
  • a computer-readable medium may include one or more memory devices and/or carrier waves.
  • the instructions may be read into memory 206 from another computer-readable medium, such as a storage device 210, or from a separate device via communication interface 216. Execution of the sequences of instructions contained in memory 206 causes processor 204 to perform the process steps that will be described hereafter.
  • hardwired circuitry may be used in place of or in combination with software instructions to implement the present invention. Thus, the present invention is not limited to any specific combination of hardware circuitry and software.
  • An ADS device 145 logs all recent traffic (e.g., using a circular buffer) on a continuous basis in order to provide limited audit trail data for later analysis and prosecution.
  • the attack detection sensor device 145 may log this information in an associated database.
  • the database may be stored at the attack detection sensor device 145 (e.g., in main memory 206) or externally from attack detection sensor device 145.
  • a triage device 140 consistent with the present invention, logs all traffic during an attack in order to provide extensive forensics data for later analysis and prosecution.
  • the triage device 140 may log this information in an associated database.
  • the database maybe stored at the triage device 140 (e.g., in main memory 206) or externally from triage device 140.
  • FIG. 3 illustrates an exemplary database 300, consistent with the present invention, that may be associated with triage/ADS device 140/145. While only one database is described below, it will be appreciated that database 300 may consist of multiple databases stored locally at each triage device 140 and ADS device 145 or stored at different locations throughout the network 100.
  • database 300 includes a group of entries 305. Each entry 305 includes information stored in one or more of the following exemplary fields: a source address field 310, a target address field 320, a date field 330, a time field 340, and a log entry field 350. Database 300 may contain additional fields that would aid the triage/ADS device 140/145 in searching, sorting, and/or providing information for analyzing a DoS attack.
  • the source address field 310 stores an address from a packet of information determined to be part of a DoS attack that identifies the network device from where the packet was sent, although this information will typically not be reliable.
  • the target address field 320 stores an address of the target network device to which the packet of information was sent.
  • the date field 330 stores the date on which the packet was received.
  • the time field 340 stores the time at which the packet was received.
  • the log entry field 350 stores additional information relating to the DoS attack that may aid in determining the nature of a DoS attack. This information may be automatically entered by the triage device
  • FIG. 4 illustrates an exemplary scenario 400 in which a group of adversarial network devices 410 participate in a DDoS attack on a host device 420.
  • traffic emanates from a wide range of compromised systems, and packets from these systems are directed at one or more target hosts, e.g., web servers.
  • the number of adversarial devices 410 illustrated in FIG. 4 is provided for simplicity.
  • a typical attack scenario 400 would generally include a larger number of adversarial devices 410.
  • a passive attack detection sensor 145 detects a DDoS attack on host 420 and notifies the SP 412 which invokes the triage service 140.
  • the attack detection sensor 145 maintains a limited audit trail (e.g., circular buffer) on a continuous basis.
  • the attack detection sensor 145 may send its buffer contents to the triage device's database 300 to assist in characterizing the early or precursor phases of an attack.
  • the attack detection sensor 145 maybe implemented as a purely passive system so that it does not impose any delays on traffic, nor would its failure affect normal operation of the target systems.
  • host 420 may detect the DoS attack and notify service provider 116 that an attack is underway.
  • the host 420 may notify the service provider 116 via any conventional technique, such as a telephone call, e-mail, facsimile, etc.
  • routing within the target's SP 116 may be altered to divert all traffic for the target host 420 to the triage device 140.
  • the triage device 140 takes at least one of three possible courses of action: discard the packet, proxy a reply on behalf of the host 420, or forward the packet to the host 420.
  • the triage device 140 logs detailed forensics information in the attached database 300 for later examination.
  • FIG. 5 illustrates exemplary processing of an attack detection sensor 145 consistent with the present invention.
  • the attack detection sensor 145 passively monitors the traffic passing through the service provider 116 to the customers 135 [step 505].
  • the attack detection sensor 145 may analyze each packet passing through the service provider 116 to determine whether a DoS signature is present [step 510].
  • the attack detection sensor 145 may use any conventional DoS signature detection technique.
  • a smurf type of DoS attack as described above, an attacking device causes a host device to crash by sending ping requests to a broadcast address on the host's network.
  • the attacking device sets the return address to the victim's address, causing hundreds of response messages to be generated that eventually overload the network.
  • the attack detection sensor 145 may detect the presence of the ping response messages.
  • the attack detection sensor 145 may also continuously record information regarding the packets passing through the service provider 116 in an associated buffer (or database).
  • the attack detection sensor 145 determines that no such signature exists in the packets passing through the service provider 116 [step 510], the attack detection sensor 145 returns to step 505 and continues to monitor the traffic. If, on the other hand, a DoS signature exists [step 510], then the attack detection sensor 145 may notify the service provider 116 and, possibly, the triage device 140 of the presence of an attack [step 515]. The attack detection sensor 145 may also notify the service provider 116 and triage device 140 of the identity of the intended victim device (e.g., host device 420 in FIG. 4). In an alternative implementation, the service provider 116 may determine the identity of the intended victim device.
  • the intended victim device e.g., host device 420 in FIG. 4
  • the attack detection sensor 145 Upon notifying the service provider 116 and triage device 140 of the attack, the attack detection sensor 145 returns to step 505 and continues to monitor the traffic passing through the service provider 116. At any time during this processing, the attack detection sensor 145 may receive a request from the triage device 140 requesting a recent history of packets transmitted to the target device. In response to such a request, the attack detection sensor 145 may transmit the information recorded in its buffer to the database 300 associated with the triage device 140. This information may be later used to characterize the early or precursor phases of the attack.
  • FIGS. 6A and 6B illustrate an exemplary process, consistent with the present invention, that protects communication networks and devices against denial of service attacks. Processing begins when a service provider, such as service provider 116, receives notification that a DoS attack has been detected [step 605].
  • the service provider 116 may, for example, receive the attack detection notification from an attack detection sensor, such as attack detection sensor 145, from the target device, or from another network device.
  • the service provider 116 In response to the attack notification, the service provider 116 begins to route any information received for the intended victim (i.e., host device 420) to the triage device 140 [step 610]. The service provider 116 determines whether a particular packet is intended for the host device 420 by, for example, examining target address information in the packet's header.
  • the triage device 140 In response to receiving one or more packets, the triage device 140 examines each packet to determine whether the packet is part of the DoS attack [step 615]. In the example above, the triage device 140 may determine whether the packet is a ping response message.
  • the triage device 140 may forward the packet to the host device 420 [step 625] .
  • the triage device 140 may be configured to prioritize or filter packets to be forwarded based on a variety of characteristics, or can forward packets on a first come, first delivered basis.
  • the triage device 140 may, however, drop packets in excess of the host device's 420 rated capacity to prevent a deluge of "good" packets from bringing down the host device 420.
  • the triage device 140 may discard the packet and/or proxy a reply to the attacking device on behalf of the host device 420 [step 630]. By proxying a reply to the attacking device, the attacking device may be left with the impression that the DoS attack was successful. In addition, this may aid in tracking the source of the attack.
  • the triage device 140 may receive a profile from the host device 420 describing the types of packets that the host device normally receives. If such a profile has been received by the triage device 140, the triage device 140 may divert all packets not of the types normally received as likely attack material, even if of an unknown attack variety. Moreover, if the host device 420 is capable of notifying the triage device as to which IP addresses are "good,” then the triage device 140 can filter good packets from attack packets, based on their IP address, even if they fall within the profile of an attack.
  • the triage device 140 For each packet received during the DoS attack, the triage device 140 stores information regarding the packet in database 300 [step 635]. As described above, this information may include the source address, target address, date, time, and other information that may facilitate later analysis of the attack.
  • the triage device 140 may then determine whether the DoS attack has ended [step 640] (FIG. 6B).
  • the triage device 140 may, for example, automatically determine that the attack has ended after a predetermined period of time or after a predetermined number of "good" packets have been received without having received a "bad" packet.
  • the service provider 116 or some other network device may determine that the DoS attack has ended. If the attack has not ended, the service provider 116 continues to route packets intended for the host device to the triage device 140 [step 610] (FIG. 6A).
  • the triage device 140 continues to process packets until the service provider 116 discontinues redirecting packets from the target to the triage device 140.
  • the service provider 116 may then begin to route traffic directly to the host device 420 [step 645] .
  • the triage device 140 may transfer information about the attack from its associated database 300 to a network administrator so that remedial measures maybe commenced. This transfer of information may alternatively occur during the attack. The transfer may occur automatically or in response to a request from the network administrator.
  • a service provider can redirect traffic away from a targeted host (or hosts) and toward a triage device, that may use a combination of packet destruction, proxying for the target, other filtering mechanisms, and prioritized packet forwarding to protect intended targets from attack.
  • the triage device diverts the brunt of the attack from the targets, allowing them to continue to operate during a DoS attack. Due to its modular nature, the triage device provides a flexible base for deploying new DoS attack responses as DoS attack techniques evolve. Moreover, the triage device is capable of being scaled from a single system to a multi-module, multi-homed architecture, providing cost-effective deployment for a growing target base.

Abstract

A system protects communicaton networks and devices against denial of service (DoS) attacks. A service provider (116) receives a signal indicating that a DoS attack has been detected, receives one or more packets intended for a victim device (420), and transmits the one or more packets to a triage device (140). The triage device determines whether each of the one or more packets is part of the DoS attack and forwards only packets that are deemed unrelated to the DoS attack to the victim device (420).

Description

SYSTEMS AND METHODS THAT PROTECT NETWORKS AND DEVICES AGAINST DENIAL OF SERVICE ATTACKS
FIELD OF THE INVENTION The present invention relates generally to networks and, more particularly, to systems and methods that protect communication networks and devices from denial of service attacks.
BACKGROUND OF THE INVENTION Denial of Service (DoS) attacks represent a major threat to the continuous operations of network devices. In a typical Distributed DoS (DDoS) attack, traffic emanates from a wide range of compromised systems, and packets from these systems are directed at one or more target hosts, e.g., web servers. When a DoS attack occurs across an Internet Service Provider's (ISP's) network, the transmission network may become so congested that the ISP can no longer provide adequate service. Examples of DoS attacks include smurf attacks, SYN flood attacks, and Ping of Death attacks. All of these may be effected as distributed DoS attacks, where many compromised network devices become the unwitting source of DoS traffic.
A smurf attack is an assault on a network that floods the network with excessive messages in order to impede normal traffic. An attacking device sends ping requests to a broadcast address on the target network. The attacking device sets the return address to the victim's address. The broadcast address can generate hundreds of response messages from unwitting network devices that eventually overload the target network. A SYN flood attack is an assault on a network that prevents a Transmission
Control Protocol/Internet Protocol (TCP/IP) server from servicing other users. An attacking device sends a counterfeit source address to the server so that a final acknowledgment to the server's SYNchronize-ACKnowledge (SNY-ACK) response in the handshaking sequence is not sent. As a result, the server continues to execute the handshaking sequence until the server either overloads or crashes. A Ping of Death attack is an assault on a target computer. An attacking device causes the target computer to crash by sending a packet having an invalid packet size value in the packet's header.
To date, major work on combating DoS attacks has focused on router and firewall-based packet filtering mechanisms designed to reject traffic based on simple filtering rules. Ingress packet filtering by ISPs makes tracking attack sources easier, by limiting the range of spoofed source addresses available to DoS traffic generators, but it does not prevent such traffic from reaching targets. Since DoS traffic streams often originate from outside a target's ISP, and because it is currently infeasible to filter traffic at border gateway protocol (BGP) peering points, ingress filtering relies on all other ISPs to provide protection, a bad strategy in the global Internet environment.
With the proliferation of freely available DoS attack software, DoS attacks will become more sophisticated and more frequent and, therefore, produce more far-reaching consequences in the future. Simple filtering, based on examination of IP and TCP layer headers, will become less and less effective against more sophisticated attacks. Even traffic characterization technologies, such as Multi- Protocol Layer Switching (MPLS), that employ high speed header analysis facilities will become inappropriate for filtering DoS traffic, as the rapid reconfiguration required to respond to attacks would impose a serious burden on the backbone traffic engineering system, which is optimized for packet forwarding. Current attempts to prevent DoS attacks involve an ISP's network operations center (NOC) manually attempting to intervene in the attack. If the DoS attack is successful, the NOC may not be able to "break into" the network connection to thwart the attack. As a result, the NOC may need to spend many hours trying to filter the attacker's data out of their network, while at the same time calming their customers.
Since a successful DoS attack causes the customer's local network, firewall, and possibly web server to become unstable and/or unusable, those customers who rely on electronic commerce are particularly affected by DoS attacks. Unfortunately, the most advanced intrusion detection systems look for specific signatures of attacks in a data flow and then send a message to an operator for manual intervention. By the time the operator attempts to intervene, however, damage from the DoS attack may have already occurred.
Therefore, there exists a need for systems and methods that better protect l against DoS attacks.
SUMMARY OF THE INVENTION Systems and methods consistent with the present invention address this and other needs by providing a process that protects communication networks and devices against denial of service attacks. In accordance with the purpose of the invention as embodied and broadly described herein, a system protects against DoS attacks. The system includes a service provider and a triage device. The service provider receives a signal indicating detection of a DoS attack, receives one or more packets intended for a victim device, and transmits the one or more packets to the triage device. The triage device determines, for each received packet, whether the packet is part of a DoS attack and forwards any packets that are unrelated to the DoS attack to the victim device.
In another implementation consistent with the present invention, a method protects against DoS attacks. The method includes detecting the occurrence of a DoS attack, determining a target of the DoS attack, intercepting packets destined for the target, and preventing packets that are related to the DoS attack from reaching the target.
In still another implementation consistent with the present invention, a device for protecting against DoS attacks is provided. The device includes a memory and a processor that receives, once a DoS attack has been detected, packets from a service provider, determines, for each packet addressed to the intended target, whether a packet is part of the DoS attack, forwards a packet determined not to be part of the DoS attack to a target device, and discards and/ or proxies a reply to a packet determined to be part of the DoS attack. In a further implementation consistent with the present invention, a method that protects against DoS attacks is provided. The method includes passively recording, via an attack detection sensor, packets transmitted in a network, detecting an occurrence of a DoS attack, transferring, in response to the detecting, packets for a target of the DoS attack from a service provider to a triage device, retrieving recently recorded packets from the attack detection sensor, determining, for each transferred packet, whether the packet is part of the DoS attack, forwarding a packet determined not to be part of the DoS attack to the target, and discarding or proxying a reply to a packet determined to be part of the DoS attack. In yet another implementation consistent with the present invention, a passive DoS attack sensor is provided. The DoS attack sensor includes a memory that stores instructions and information relating to packets transferred in a network. The DoS attack sensor also includes a processor that monitors the packets, stores the information in the memory, detects a DoS signature in one or more of the packets, sends a signal to a service provider in response to the detecting, and transfers the information in the memory for use in determining a history of the one or more packets.
BRIEF DESCRIPTION OF THE DRAWINGS The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate an embodiment of the invention and, together with the description, explain the invention. In the drawings,
FIG. l illustrates an exemplary network in which systems and methods, consistent with the present invention, that protect against denial of service attacks may be implemented;
FIG. 2 illustrates an exemplary triage device or attack detection sensor device configuration consistent with the present invention;
FIG. 3 illustrates an exemplary database that maybe associated with the triage device or attack detection sensor device of FIG. 2;
FIG. 4 illustrates an exemplary denial of service attack scenario; FIG. 5 illustrates exemplary processing of an attack detection sensor consistent with the present invention; and
FIGS. 6A and 6B illustrate an exemplary process for protecting communication networks and devices against denial of service attacks in an implementation consistent with the present invention.
DETAILED DESCRIPTION The following detailed description of the invention refers to the accompanying drawings. The same reference numbers in different drawings identify the same or similar elements. Also, the following detailed description does not limit the invention. Instead, the scope of the invention is defined by the appended claims.
Systems and methods consistent with the present invention protect communication networks and devices against denial of service attacks. Upon detection of a DoS attack, a service provider redirects traffic away from a targeted host (or hosts) and toward a triage device, that may use a combination of packet destruction, proxying for the target, other filtering mechanisms and prioritized packet forwarding to protect intended targets from attack. The triage device diverts the brunt of the attack from the targets, allowing them to continue to operate during a DoS attack. Even DoS attacks that might overwhelm the access link capacity of a target can be handled by the triage device, since a service provider can provision very high capacity access links for this service. Network devices can be configured to automatically detect DoS attacks and trigger the invocation of the triage device, and attacked hosts can request the invocation of the triage device through any available communication channels.
EXEMPLARY NETWORK FIG. l illustrates an exemplary network loo in which systems and methods, consistent with the present invention, that protect against denial of service attacks may be implemented. In FIG. l, network loo includes multiple tier one service providers (SPs) 112-116, tier two service providers 122-126, customers 131-136, a triage device 140, and an attack detection sensor (ADS) 145.
The tier one SPs 112-116 may include, for example, large national ISPs. The tier one SPs exchange traffic with each other directly. This is known as peering. Every tier one SP peers with every other tier one SP.
The tier two SPs 122-126 may include, for example, regional ISPs or smaller SPs that rely on a tier one SP to provide transit service. The tier two SPs generally connect to one or more tier one SP.
The customers 131-136 may include one or more host devices (not shown) that connect to a corresponding tier one or tier two SP 112-126 via a wired, wireless, or optical connection. The host devices may include, for example, a server, personal computer, or the like. The host devices may be directly connected to a SP 112-126 or may be connected to a SP 112-126 through one or more local networks (not shown).
The triage device 140 may include, according to an exemplary implementation, a high-end computer, a server or collection of servers, or the like, capable of protecting one or more network devices in response to a DoS attack. The triage device 140 may be connected to, or implemented within, a SP 112-126 or another network device. Connection of the triage device 140 to a SP 112-126 or network device should be of such a capacity so as not to be overwhelmed by the large amount of traffic commonly associated with DoS attacks. As illustrated in FIG. 1, the triage device 140 connects to a SP or network device in such a way as to be out of the regular flow of network traffic. Network traffic may, as will be described in more detail below, be routed through the triage device 140 in those situations where a DoS attack has been detected. The attack detection sensor device 145 may include, according to an exemplary implementation, a personal computer or the like, capable of passively monitoring traffic and detecting the presence of a DoS attack. The attack detection sensor device 145 may be connected to, or implemented within, a SP 112-126 or another network device. The number of components illustrated in FIG. 1 is provided for simplicity.
In practice, a typical network 100 may include a larger or smaller number of SPs 112-126, customers 131-136, triage devices 140, and attack detection sensor devices 145.
EXEMPLARY TRIAGE DEVICE/ADS DEVICE CONFIGURATION FIG. 2 illustrates an exemplary triage device 140 or attack detection sensor device 145 configuration consistent with the present invention. The exemplary triage/ ADS device 140/145 includes a bus 202, a processor 204, a main memory 206, a read only memory (ROM) 208, a storage device 210, an optional input device 212, an optional output device 214, and a communication interface 216. The bus 202 permits communication among the components of the triage/ ADS device 140/145.
The processor 204 may include any type of conventional processor or microprocessor that interprets and executes instructions. The main memory 206 may include a random access memory (RAM) or another type of dynamic storage device that stores information and instructions for execution by the processor 204. Main memory 206 may also be used to store temporary variables or other intermediate information during execution of instructions by processor 204.
ROM 208 may include a conventional ROM device and/or another type of static storage device that stores static information and instructions for processor 204. The storage device 210 may include a magnetic disk or optical disk and its corresponding drive and/or some other type of magnetic or optical recording medium and its corresponding drive for storing information and/or instructions.
The input device 212 (if any) may include any conventional mechanism that permits an operator to input information to the triage/ADS device 140/145, such as a keyboard, a mouse, a microphone, a pen, voice recognition and/or biometric mechanisms, etc. The output device 214 (if any) may include any conventional mechanism that outputs information to the operator, including a display, a printer, a pair of speakers, etc.
The communication interface 216 may include any transceiver-like mechanism that enables the triage/ADS device 140/145 to communicate with other devices and/or systems, such as SPs 112-126 or customers 131-136. For example, the communication interface 216 may include a modem or an Ethernet interface to a network. Alternatively, communication interface 216 may include other mechanisms for communicating via a data network.
The triage/ADS device 140/145 protects against denial of service attacks in response to processor 204 executing sequences of instructions contained in a computer-readable medium, such as memory 206. It should be understood that a computer-readable medium may include one or more memory devices and/or carrier waves. The instructions may be read into memory 206 from another computer-readable medium, such as a storage device 210, or from a separate device via communication interface 216. Execution of the sequences of instructions contained in memory 206 causes processor 204 to perform the process steps that will be described hereafter. In alternative embodiments, hardwired circuitry may be used in place of or in combination with software instructions to implement the present invention. Thus, the present invention is not limited to any specific combination of hardware circuitry and software.
An ADS device 145, consistent with the present invention, logs all recent traffic (e.g., using a circular buffer) on a continuous basis in order to provide limited audit trail data for later analysis and prosecution. The attack detection sensor device 145 may log this information in an associated database. The database may be stored at the attack detection sensor device 145 (e.g., in main memory 206) or externally from attack detection sensor device 145. A triage device 140, consistent with the present invention, logs all traffic during an attack in order to provide extensive forensics data for later analysis and prosecution. The triage device 140 may log this information in an associated database. The database maybe stored at the triage device 140 (e.g., in main memory 206) or externally from triage device 140.
FIG. 3 illustrates an exemplary database 300, consistent with the present invention, that may be associated with triage/ADS device 140/145. While only one database is described below, it will be appreciated that database 300 may consist of multiple databases stored locally at each triage device 140 and ADS device 145 or stored at different locations throughout the network 100.
As illustrated, database 300 includes a group of entries 305. Each entry 305 includes information stored in one or more of the following exemplary fields: a source address field 310, a target address field 320, a date field 330, a time field 340, and a log entry field 350. Database 300 may contain additional fields that would aid the triage/ADS device 140/145 in searching, sorting, and/or providing information for analyzing a DoS attack.
The source address field 310 stores an address from a packet of information determined to be part of a DoS attack that identifies the network device from where the packet was sent, although this information will typically not be reliable. The target address field 320 stores an address of the target network device to which the packet of information was sent. The date field 330 stores the date on which the packet was received. The time field 340 stores the time at which the packet was received. The log entry field 350 stores additional information relating to the DoS attack that may aid in determining the nature of a DoS attack. This information may be automatically entered by the triage device
140 or may be entered by an operator. EXEMPLARY ATTACK SCENARIO FIG. 4 illustrates an exemplary scenario 400 in which a group of adversarial network devices 410 participate in a DDoS attack on a host device 420. In a typical DoS attack, traffic emanates from a wide range of compromised systems, and packets from these systems are directed at one or more target hosts, e.g., web servers. The number of adversarial devices 410 illustrated in FIG. 4 is provided for simplicity. A typical attack scenario 400 would generally include a larger number of adversarial devices 410.
As illustrated, a number of adversarial devices 410 transmit packets of information through their associated SPs 412 in an attempt to attack host device 420. A passive attack detection sensor 145 detects a DDoS attack on host 420 and notifies the SP 412 which invokes the triage service 140. In an implementation consistent with the present invention, the attack detection sensor 145 maintains a limited audit trail (e.g., circular buffer) on a continuous basis. The attack detection sensor 145 may send its buffer contents to the triage device's database 300 to assist in characterizing the early or precursor phases of an attack. The attack detection sensor 145 maybe implemented as a purely passive system so that it does not impose any delays on traffic, nor would its failure affect normal operation of the target systems. In an alternative implementation, host 420 (or some other network device) may detect the DoS attack and notify service provider 116 that an attack is underway. The host 420 may notify the service provider 116 via any conventional technique, such as a telephone call, e-mail, facsimile, etc.
Once an attack has been detected, routing within the target's SP 116 may be altered to divert all traffic for the target host 420 to the triage device 140. For every packet directed to the target 420, the triage device 140 takes at least one of three possible courses of action: discard the packet, proxy a reply on behalf of the host 420, or forward the packet to the host 420. During the entire attack, the triage device 140 logs detailed forensics information in the attached database 300 for later examination. EXEMPLARY PROCESSING
FIG. 5 illustrates exemplary processing of an attack detection sensor 145 consistent with the present invention. The attack detection sensor 145 passively monitors the traffic passing through the service provider 116 to the customers 135 [step 505]. The attack detection sensor 145 may analyze each packet passing through the service provider 116 to determine whether a DoS signature is present [step 510]. The attack detection sensor 145 may use any conventional DoS signature detection technique. In a smurf type of DoS attack, as described above, an attacking device causes a host device to crash by sending ping requests to a broadcast address on the host's network. The attacking device sets the return address to the victim's address, causing hundreds of response messages to be generated that eventually overload the network. In such an attack, the attack detection sensor 145 may detect the presence of the ping response messages. As part of its monitoring process, the attack detection sensor 145 may also continuously record information regarding the packets passing through the service provider 116 in an associated buffer (or database).
If the attack detection sensor 145 determines that no such signature exists in the packets passing through the service provider 116 [step 510], the attack detection sensor 145 returns to step 505 and continues to monitor the traffic. If, on the other hand, a DoS signature exists [step 510], then the attack detection sensor 145 may notify the service provider 116 and, possibly, the triage device 140 of the presence of an attack [step 515]. The attack detection sensor 145 may also notify the service provider 116 and triage device 140 of the identity of the intended victim device (e.g., host device 420 in FIG. 4). In an alternative implementation, the service provider 116 may determine the identity of the intended victim device.
Upon notifying the service provider 116 and triage device 140 of the attack, the attack detection sensor 145 returns to step 505 and continues to monitor the traffic passing through the service provider 116. At any time during this processing, the attack detection sensor 145 may receive a request from the triage device 140 requesting a recent history of packets transmitted to the target device. In response to such a request, the attack detection sensor 145 may transmit the information recorded in its buffer to the database 300 associated with the triage device 140. This information may be later used to characterize the early or precursor phases of the attack.
FIGS. 6A and 6B illustrate an exemplary process, consistent with the present invention, that protects communication networks and devices against denial of service attacks. Processing begins when a service provider, such as service provider 116, receives notification that a DoS attack has been detected [step 605]. The service provider 116 may, for example, receive the attack detection notification from an attack detection sensor, such as attack detection sensor 145, from the target device, or from another network device.
In response to the attack notification, the service provider 116 begins to route any information received for the intended victim (i.e., host device 420) to the triage device 140 [step 610]. The service provider 116 determines whether a particular packet is intended for the host device 420 by, for example, examining target address information in the packet's header.
In response to receiving one or more packets, the triage device 140 examines each packet to determine whether the packet is part of the DoS attack [step 615]. In the example above, the triage device 140 may determine whether the packet is a ping response message.
If a packet is determined to not be part of the DoS attack [step 620], the triage device 140 may forward the packet to the host device 420 [step 625] . The triage device 140 may be configured to prioritize or filter packets to be forwarded based on a variety of characteristics, or can forward packets on a first come, first delivered basis. The triage device 140 may, however, drop packets in excess of the host device's 420 rated capacity to prevent a deluge of "good" packets from bringing down the host device 420.
If a packet is determined to be a part of the DoS attack [step 620], the triage device 140 may discard the packet and/or proxy a reply to the attacking device on behalf of the host device 420 [step 630]. By proxying a reply to the attacking device, the attacking device may be left with the impression that the DoS attack was successful. In addition, this may aid in tracking the source of the attack.
In an implementation consistent with the present invention, the triage device 140 may receive a profile from the host device 420 describing the types of packets that the host device normally receives. If such a profile has been received by the triage device 140, the triage device 140 may divert all packets not of the types normally received as likely attack material, even if of an unknown attack variety. Moreover, if the host device 420 is capable of notifying the triage device as to which IP addresses are "good," then the triage device 140 can filter good packets from attack packets, based on their IP address, even if they fall within the profile of an attack.
For each packet received during the DoS attack, the triage device 140 stores information regarding the packet in database 300 [step 635]. As described above, this information may include the source address, target address, date, time, and other information that may facilitate later analysis of the attack.
The triage device 140 may then determine whether the DoS attack has ended [step 640] (FIG. 6B). The triage device 140 may, for example, automatically determine that the attack has ended after a predetermined period of time or after a predetermined number of "good" packets have been received without having received a "bad" packet. Alternatively, the service provider 116 or some other network device may determine that the DoS attack has ended. If the attack has not ended, the service provider 116 continues to route packets intended for the host device to the triage device 140 [step 610] (FIG. 6A). The triage device 140 continues to process packets until the service provider 116 discontinues redirecting packets from the target to the triage device 140.
Once the DoS attack has ended [step 640], the service provider 116 may then begin to route traffic directly to the host device 420 [step 645] . Also, the triage device 140 may transfer information about the attack from its associated database 300 to a network administrator so that remedial measures maybe commenced. This transfer of information may alternatively occur during the attack. The transfer may occur automatically or in response to a request from the network administrator.
CONCLUSION Systems and methods consistent with the present invention provide a mechanism that protects communication networks and devices against denial of service attacks. Upon detection of a DoS attack, a service provider can redirect traffic away from a targeted host (or hosts) and toward a triage device, that may use a combination of packet destruction, proxying for the target, other filtering mechanisms, and prioritized packet forwarding to protect intended targets from attack. The triage device diverts the brunt of the attack from the targets, allowing them to continue to operate during a DoS attack. Due to its modular nature, the triage device provides a flexible base for deploying new DoS attack responses as DoS attack techniques evolve. Moreover, the triage device is capable of being scaled from a single system to a multi-module, multi-homed architecture, providing cost-effective deployment for a growing target base.
The foregoing description of exemplary embodiments of the present invention provides illustration and description, but is not intended to be exhaustive or to limit the invention to the precise form disclosed. Modifications and variations are possible in light of the above teachings or may be acquired from practice of the invention. For example, while a series of steps have been shown with respect to FIGS. 5, 6A, and 6B, the order of the steps may vary in other implementations consistent with the present invention. The scope of the invention is defined by the following claims and their equivalents.

Claims

WHAT IS CLAIMED IS:
1. A system that protects against denial of service (DoS) attacks, comprising: a service provider configured to receive a signal indicating detection of a DoS attack, receive one or more packets intended for a victim device, and transmit the one or more packets; and a triage device configured to receive the one or more packets, determine whether each of the one or more packets is related to the DoS attack, and forward any packets that are unrelated to the DoS attack to the victim device.
2. The system of claim l further comprising: a passive attack detection sensor configured to examine packets transmitted in a network for a DoS signature and transmit the signal to the service provider when a DoS signature is detected.
3. The system of claim 2 wherein the passive attack detection sensor is further configured to: store information about the packets when the DoS signature is detected. 4. The system of claim 3 wherein the passive attack detection sensor is further configured to: transmit the information to the triage device. 5. The system of claim 1 wherein the victim device transmits the signal to the service provider indicating detection of a DoS attack against itself. 6. The system of claim 1 wherein the triage device is further configured to: discard any packets that are related to the DoS attack.
7. The system of claim 1 wherein the triage device is further configured to: proxy a reply to a packet that is related to the DoS attack.
8. The system of claim 1 wherein the triage device includes a database configured to store information relating to the DoS attack.
9. The system of claim 8 wherein the triage device is further configured to: transfer the information relating to the DoS attack to a network administrator for determining characteristics of the DoS attack.
10. The system of claim 1 wherein the triage device is further configured to: determine an end to the DoS attack and transmit a signal indicating the end to the DoS attack to the service provider. u. The system of claim 10 wherein the service provider is configured to: receive the signal indicating the end to the DoS attack and transmit packets directly to the victim device in response to the signal received.
12. The system of claim 1 wherein the triage device is further configured to: receive a normal packet profile, determine whether each of the one or more packets matches the profile, and discard any packets not matching the profile. 13. The system of claim 1 wherein the triage device is further configured to: receive a list of acceptable source addresses, determine whether a source address associated with each of the one or more packets matches an acceptable source address in the list of acceptable source addresses, and discard any packets having a source address not matching an acceptable source address in the list.
14. A system that protects against denial of service (DoS) attacks, comprising: means for detecting an occurrence of a DoS attack; means for determining a target of the DoS attack; means for intercepting at least one packet destined for the target; means for preventing the at least one packet from reaching the target when the at least one packet is part of the DoS attack.
15. A method that protects against denial of service (DoS) attacks, comprising: detecting an occurrence of a DoS attack; determining a target of the DoS attack; intercepting packets destined for the target; and preventing packets that are related to the DoS attack from reaching the target.
16. The method of claim 15 wherein the detecting includes: detecting a DoS signature.
17. The method of claim 15 wherein the preventing includes: discarding a packet when the packet is part of the DoS attack. 18. The method of claim 15 wherein the preventing includes: proxying a reply to a device that sent a packet when the packet is part of the DoS attack.
19. The method of claim 15 wherein the preventing includes: forwarding a packet to the target when the packet is not part of the DoS attack.
20. The method of claim 15 further comprising: storing information about a packet when the packet is part of the DoS attack.
21. The method of claim 20 wherein the information includes at least one of a source address and forensic data.
22. The method of claim 20 further comprising: routing the information to a network administrator for performing at least one of analysis, characterization, and reporting of the DoS attack.
23. The method of claim 15 wherein the intercepting includes: transferring packets for the target from an Internet service provider to a triage device.
24. The method of claim 15 wherein the preventing includes: receiving a normal packet profile, determining whether each of the packets matches the profile, and discarding any packets not matching the profile.
25. The method of claim 15 wherein the preventing includes: receiving a list of acceptable source addresses, determining whether a source address of each of the packets matches an acceptable source address in the list of acceptable source addresses, and discarding any packets having a source address not matching an acceptable source address in the list.
26. A device for protecting against denial of service (DoS) attacks, comprising: a memory configured to store instructions; and a processor configured to execute the instructions to receive, once a DoS attack has been detected, packets from a service provider, determine, for each packet, whether the packet is related to the DoS attack, forward the packets determined to be unrelated to the DoS attack to a target device, and at least one of discard the packets and proxy a reply to the packets determined to be related to the DoS attack.
27. The device of claim 26 wherein the processor is further configured to: store information in the memory for each of the packets determined to be related to the DoS attack.
28. The device of claim 27 wherein the information includes at least a source address associated with the packet determined to be related to the DoS attack.
29. The device of claim 26 wherein the processor is further configured to: receive a normal packet profile, determine whether each of the packets matches the profile, and discard any packets not matching the profile. 30. The device of claim 26 wherein the processor is further configured to: receive a list of acceptable source addresses, determine whether a source address in each of the packets matches a source address in the list of acceptable source addresses, discard each packet having a source address not matching a source address in the list of acceptable source addresses. 31. A computer-readable medium containing instructions for controlling at least one processor to perform a method that protects against denial of service (DoS) attacks, the method comprising: receiving, once a DoS attack has been detected, packets intended for a target device; determining, for each of the packets, whether the packet is part of the DoS attack; forwarding packets determined not to be part of the DoS attack to the target device; and discarding packets determined to be part of the DoS attack. 32. The computer-readable medium of claim 31 further comprising : proxying a reply on behalf the target device to a source device when a packet is determined to be part of the DoS attack.
33. The computer-readable medium of claim 31, wherein the determining includes: receive a normal packet profile, and determine whether each of the packets matches the profile.
34. The computer-readable medium of claim 31, wherein the determining includes: receive a list of acceptable source addresses, and determine whether a source address in each of the packets matches a source address in the list of acceptable source addresses.
35. A method that protects against denial of service (DoS) attacks, comprising: passively recording, via by an attack detection sensor, packets transmitted in a network; detecting an occurrence of a DoS attack; transferring, in response to the detecting, packets for a target of the DoS attack from a service provider to a triage device; retrieving recently recorded packets from the attack detection sensor; determining, for each transferred packet, whether the packet is part of the DoS attack; forwarding a packet determined not to be part of the DoS attack to the target; and discarding or proxying a reply to a packet determined to be part of the DoS attack.
36. An attack detection sensor comprising: a memory configured to store instructions and information relating to packets transferred in a network; and a processor configured to execute the instructions to monitor the packets, store the information in the memory, detect a denial of service attack signature in one or more of the packets, send a signal to a service provider in response to the detecting, and transfer the information in the memory for use in determining a history of the one or more packets.
PCT/US2001/029336 2000-09-20 2001-09-19 Systems and methods that protect networks and devices against denial of service attacks WO2002025402A2 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
AU2002211242A AU2002211242A1 (en) 2000-09-20 2001-09-19 Systems and methods that protect networks and devices against denial of service attacks

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US66611400A 2000-09-20 2000-09-20
US09/666,114 2000-09-20

Publications (2)

Publication Number Publication Date
WO2002025402A2 true WO2002025402A2 (en) 2002-03-28
WO2002025402A3 WO2002025402A3 (en) 2002-08-01

Family

ID=24672884

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2001/029336 WO2002025402A2 (en) 2000-09-20 2001-09-19 Systems and methods that protect networks and devices against denial of service attacks

Country Status (2)

Country Link
AU (1) AU2002211242A1 (en)
WO (1) WO2002025402A2 (en)

Cited By (20)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20030009887A (en) * 2001-07-24 2003-02-05 주식회사 케이티 A system and method for intercepting DoS attack
EP1364297A2 (en) * 2000-10-17 2003-11-26 Wanwall, Inc. Methods and apparatus for protecting against overload conditions on nodes of a distributed network
EP1566947A1 (en) * 2004-02-18 2005-08-24 AT&T Corp. Method for distributed denial-of-service attack mitigation by selective black-holing in MPLS VPNs
EP1616269A2 (en) * 2003-04-09 2006-01-18 Riverhead Networks Inc. Selective diversion and injection of communication traffic
WO2006081507A1 (en) * 2005-01-28 2006-08-03 Broadcom Corporation Method and system for mitigating denial of service in a communication network
EP1691529A1 (en) * 2005-02-15 2006-08-16 AT&T Corp. Method for defending a network against DDoS attacks
EP1705863A1 (en) * 2005-03-25 2006-09-27 AT&T Corp. Method and apparatus for traffic control of dynamic denial of service attacks within a communications network
EP1744516A1 (en) * 2005-07-15 2007-01-17 AT&T Corp. Distributed denial-of-service attack mitigation by selective black-holing in IP networks
WO2007019213A1 (en) * 2005-08-05 2007-02-15 Lucent Technologies Inc. Method for defending against denial of service attacks in ip networks by target victim self-identification and control
WO2007035207A1 (en) * 2005-08-05 2007-03-29 Lucent Technologies Inc. Method for defending against denial of service attacks in ip networks by target victim self-identification and control
EP1804446A1 (en) * 2004-10-12 2007-07-04 Nippon Telegraph and Telephone Corporation Service disabling attack protecting system, service disabling attack protecting method, and service disabling attack protecting program
US7308716B2 (en) 2003-05-20 2007-12-11 International Business Machines Corporation Applying blocking measures progressively to malicious network traffic
WO2008001247A2 (en) * 2006-06-26 2008-01-03 Nokia Corporation A sip redirect server for managing a denial of service attack
US7444417B2 (en) 2004-02-18 2008-10-28 Thusitha Jayawardena Distributed denial-of-service attack mitigation by selective black-holing in IP networks
US7464404B2 (en) 2003-05-20 2008-12-09 International Business Machines Corporation Method of responding to a truncated secure session attack
US7617526B2 (en) 2003-05-20 2009-11-10 International Business Machines Corporation Blocking of spam e-mail at a firewall
US7797419B2 (en) * 2003-06-23 2010-09-14 Protego Networks, Inc. Method of determining intra-session event correlation across network address translation devices
US8438241B2 (en) 2001-08-14 2013-05-07 Cisco Technology, Inc. Detecting and protecting against worm traffic on a network
US8478831B2 (en) 2004-08-26 2013-07-02 International Business Machines Corporation System, method and program to limit rate of transferring messages from suspected spammers
US20220030011A1 (en) * 2020-07-23 2022-01-27 Micro Focus Llc Demand management of sender of network traffic flow

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5958053A (en) * 1997-01-30 1999-09-28 At&T Corp. Communications protocol with improved security
US6298445B1 (en) * 1998-04-30 2001-10-02 Netect, Ltd. Computer security
US6301668B1 (en) * 1998-12-29 2001-10-09 Cisco Technology, Inc. Method and system for adaptive network security using network vulnerability assessment

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5958053A (en) * 1997-01-30 1999-09-28 At&T Corp. Communications protocol with improved security
US6298445B1 (en) * 1998-04-30 2001-10-02 Netect, Ltd. Computer security
US6301668B1 (en) * 1998-12-29 2001-10-09 Cisco Technology, Inc. Method and system for adaptive network security using network vulnerability assessment

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
SMITH R., BHATTACHARYA S.: 'Operating firewalls outside the LAN perimeter' MOTOROLA INC. February 1999, ARIZONA, pages 493 - 498, XP000859730 *
VAZHKUDAI S., MAGINNIS T.: 'A high performance communication subsystem for PODOS' MISSISSIPPI UNIVERSITY December 1999, MISSISSIPPI, pages 81 - 91, XP010365647 *

Cited By (39)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1364297A2 (en) * 2000-10-17 2003-11-26 Wanwall, Inc. Methods and apparatus for protecting against overload conditions on nodes of a distributed network
EP1364297A4 (en) * 2000-10-17 2009-04-08 Wanwall Inc Methods and apparatus for protecting against overload conditions on nodes of a distributed network
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
KR20030009887A (en) * 2001-07-24 2003-02-05 주식회사 케이티 A system and method for intercepting DoS attack
US8438241B2 (en) 2001-08-14 2013-05-07 Cisco Technology, Inc. Detecting and protecting against worm traffic on a network
EP1616269A2 (en) * 2003-04-09 2006-01-18 Riverhead Networks Inc. Selective diversion and injection of communication traffic
EP1616269A4 (en) * 2003-04-09 2011-01-12 Cisco Tech Inc Selective diversion and injection of communication traffic
EP2977910A1 (en) * 2003-04-09 2016-01-27 Cisco Technology, Inc. Selective diversion and injection of communication traffic
US7308716B2 (en) 2003-05-20 2007-12-11 International Business Machines Corporation Applying blocking measures progressively to malicious network traffic
US7464404B2 (en) 2003-05-20 2008-12-09 International Business Machines Corporation Method of responding to a truncated secure session attack
US7617526B2 (en) 2003-05-20 2009-11-10 International Business Machines Corporation Blocking of spam e-mail at a firewall
US7797419B2 (en) * 2003-06-23 2010-09-14 Protego Networks, Inc. Method of determining intra-session event correlation across network address translation devices
US7444417B2 (en) 2004-02-18 2008-10-28 Thusitha Jayawardena Distributed denial-of-service attack mitigation by selective black-holing in IP networks
US7925766B2 (en) 2004-02-18 2011-04-12 At&T Intellectual Property Ii, L.P. Method for distributed denial-of-service attack mitigation by selective black-holing in MPLS VPNS
EP1566947A1 (en) * 2004-02-18 2005-08-24 AT&T Corp. Method for distributed denial-of-service attack mitigation by selective black-holing in MPLS VPNs
US8478831B2 (en) 2004-08-26 2013-07-02 International Business Machines Corporation System, method and program to limit rate of transferring messages from suspected spammers
EP1804446A4 (en) * 2004-10-12 2007-11-28 Nippon Telegraph & Telephone Service disabling attack protecting system, service disabling attack protecting method, and service disabling attack protecting program
EP1804446A1 (en) * 2004-10-12 2007-07-04 Nippon Telegraph and Telephone Corporation Service disabling attack protecting system, service disabling attack protecting method, and service disabling attack protecting program
US8479282B2 (en) 2004-10-12 2013-07-02 Nippon Telegraph And Telephone Corporation Denial-of-service attack defense system, denial-of-service attack defense method, and computer product
WO2006081507A1 (en) * 2005-01-28 2006-08-03 Broadcom Corporation Method and system for mitigating denial of service in a communication network
US8719446B2 (en) 2005-02-15 2014-05-06 At&T Intellectual Property Ii, L.P. Systems, methods, and devices for defending a network
US9497211B2 (en) 2005-02-15 2016-11-15 At&T Intellectual Property Ii, L.P. Systems, methods, and devices for defending a network
US10367831B2 (en) 2005-02-15 2019-07-30 At&T Intellectual Property Ii, L.P. Systems, methods, and devices for defending a network
EP1691529A1 (en) * 2005-02-15 2006-08-16 AT&T Corp. Method for defending a network against DDoS attacks
US8346960B2 (en) 2005-02-15 2013-01-01 At&T Intellectual Property Ii, L.P. Systems, methods, and devices for defending a network
US8089871B2 (en) 2005-03-25 2012-01-03 At&T Intellectual Property Ii, L.P. Method and apparatus for traffic control of dynamic denial of service attacks within a communications network
EP1705863A1 (en) * 2005-03-25 2006-09-27 AT&T Corp. Method and apparatus for traffic control of dynamic denial of service attacks within a communications network
EP1744516A1 (en) * 2005-07-15 2007-01-17 AT&T Corp. Distributed denial-of-service attack mitigation by selective black-holing in IP networks
JP2009504100A (en) * 2005-08-05 2009-01-29 ルーセント テクノロジーズ インコーポレーテッド Method of defending against DoS attack by target victim self-identification and control in IP network
JP4768020B2 (en) * 2005-08-05 2011-09-07 アルカテル−ルーセント ユーエスエー インコーポレーテッド Method of defending against DoS attack by target victim self-identification and control in IP network
JP4768021B2 (en) * 2005-08-05 2011-09-07 アルカテル−ルーセント ユーエスエー インコーポレーテッド Method of defending against DoS attack by target victim self-identification and control in IP network
US7889735B2 (en) 2005-08-05 2011-02-15 Alcatel-Lucent Usa Inc. Method and apparatus for defending against denial of service attacks in IP networks based on specified source/destination IP address pairs
JP2009504099A (en) * 2005-08-05 2009-01-29 ルーセント テクノロジーズ インコーポレーテッド Method of defending against DoS attack by target victim self-identification and control in IP network
WO2007035207A1 (en) * 2005-08-05 2007-03-29 Lucent Technologies Inc. Method for defending against denial of service attacks in ip networks by target victim self-identification and control
WO2007019213A1 (en) * 2005-08-05 2007-02-15 Lucent Technologies Inc. Method for defending against denial of service attacks in ip networks by target victim self-identification and control
WO2008001247A3 (en) * 2006-06-26 2008-04-24 Nokia Corp A sip redirect server for managing a denial of service attack
WO2008001247A2 (en) * 2006-06-26 2008-01-03 Nokia Corporation A sip redirect server for managing a denial of service attack
US20220030011A1 (en) * 2020-07-23 2022-01-27 Micro Focus Llc Demand management of sender of network traffic flow
US11683327B2 (en) * 2020-07-23 2023-06-20 Micro Focus Llc Demand management of sender of network traffic flow

Also Published As

Publication number Publication date
AU2002211242A1 (en) 2002-04-02
WO2002025402A3 (en) 2002-08-01

Similar Documents

Publication Publication Date Title
US11818167B2 (en) Authoritative domain name system (DNS) server responding to DNS requests with IP addresses selected from a larger pool of IP addresses
WO2002025402A2 (en) Systems and methods that protect networks and devices against denial of service attacks
US7870611B2 (en) System method and apparatus for service attack detection on a network
US8438241B2 (en) Detecting and protecting against worm traffic on a network
US7058976B1 (en) Intelligent feedback loop process control system
US7478429B2 (en) Network overload detection and mitigation system and method
US7627677B2 (en) Process to thwart denial of service attacks on the internet
US7307999B1 (en) Systems and methods that identify normal traffic during network attacks
US20060212572A1 (en) Protecting against malicious traffic
US20050108415A1 (en) System and method for traffic analysis
EP1588264A2 (en) Mitigating denial of service attacks
KR20120060655A (en) Routing Method And Apparatus For Detecting Server Attacking And Network Using Method Thereof
EP1595193B1 (en) Detecting and protecting against worm traffic on a network
WO2003050644A2 (en) Protecting against malicious traffic
EP1461704B1 (en) Protecting against malicious traffic
JP2007259223A (en) Defense system and method against illegal access on network, and program therefor
JP2004248185A (en) System for protecting network-based distributed denial of service attack and communication device
JP4084317B2 (en) Worm detection method
JP4326423B2 (en) Management device and unauthorized access protection system
WO2023175682A1 (en) Control system, router, control method, and program
KR20110080971A (en) Method and system for preventing denial of service attacks
JP2004166029A (en) Method, system and program for controlling distributed service rejection
JP2008252221A (en) DoS ATTACK/DEFENCE SYSTEM, AND ATTACK/DEFENCE METHOD AND DEVICE IN DoS ATTACK DEFENCE/SYSTEM

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A2

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NO NZ PL PT RO RU SD SE SG SI SK SL TJ TM TR TT TZ UA UG US UZ VN YU ZA ZW

AL Designated countries for regional patents

Kind code of ref document: A2

Designated state(s): GH GM KE LS MW MZ SD SL SZ TZ UG ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

AK Designated states

Kind code of ref document: A3

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NO NZ PL PT RO RU SD SE SG SI SK SL TJ TM TR TT TZ UA UG US UZ VN YU ZA ZW

AL Designated countries for regional patents

Kind code of ref document: A3

Designated state(s): GH GM KE LS MW MZ SD SL SZ TZ UG ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
REG Reference to national code

Ref country code: DE

Ref legal event code: 8642

122 Ep: pct application non-entry in european phase
NENP Non-entry into the national phase in:

Ref country code: JP