US20100058469A1 - Anomaly information distribution with threshold - Google Patents
Anomaly information distribution with threshold Download PDFInfo
- Publication number
- US20100058469A1 US20100058469A1 US12/203,658 US20365808A US2010058469A1 US 20100058469 A1 US20100058469 A1 US 20100058469A1 US 20365808 A US20365808 A US 20365808A US 2010058469 A1 US2010058469 A1 US 2010058469A1
- Authority
- US
- United States
- Prior art keywords
- address
- dispersion information
- matching
- address dispersion
- anomaly
- 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.)
- Granted
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
- H04L63/1408—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic by monitoring network traffic
- H04L63/1416—Event detection, e.g. attack signature detection
Definitions
- Embodiments of the present disclosure generally relate to network security and, more particularly, to detection of malicious payload.
- malware malicious code
- anomalies In networks, malicious code (commonly referred to as anomalies or malware) may intrude and steal system resources.
- malware is often polymorphic in nature, avoiding detection by altering the content of their payload in an effort to avoid detection.
- Advanced detection techniques utilize Automatic Signature Extraction (ASE) algorithms that are capable of extracting common signatures for malware packets, even if some portion of the content is altered.
- ASE Automatic Signature Extraction
- Embodiments of the present disclosure generally provide methods and apparatus for distributing information about possible anomalies in a network.
- the method generally includes detecting matching packets with payloads that match an anomaly signature, gathering address dispersion information for the matching packets, the address dispersion information providing an indication of a number of different addresses of the matching packets, wherein the different addresses comprise at least one of source addresses and destination addresses, and distributing the address dispersion information for the matching packets to one or more peer nodes if the address dispersion information indicates the number of different addresses of the matching packets exceeds a distribution threshold.
- One apparatus generally includes logic for detecting matching packets, received over a network, with payloads that match an anomaly signature, a data structure for gathering address dispersion information for the matching packets, the address dispersion information providing an indication of a number of different addresses of the matching packets, wherein the different addresses comprise at least one of source addresses and destination addresses, and logic for distributing the address dispersion information for the matching packets to one or more peer nodes in the network if the address dispersion information indicates the number of different addresses of the matching packets exceeds a distribution threshold.
- One apparatus generally includes means for detecting matching packets, received over a network, with payloads that match an anomaly signature, means for gathering address dispersion information for the matching packets, the address dispersion information providing an indication of a number of different addresses of the matching packets, wherein the different addresses comprise at least one of source addresses and destination addresses, and means for distributing the address dispersion information for the matching packets to one or more peer nodes in the network if the address dispersion information indicates the number of different addresses of the matching packets exceeds a distribution threshold.
- FIG. 1 illustrates an example network topology according to an embodiment in the present disclosure.
- FIG. 2 illustrates an example sensor according to an embodiment in the present disclosure.
- FIG. 3 is a flow chart of example operations for distributing information about a potential anomaly to neighbor sensors according to an embodiment in the present disclosure.
- FIG. 4 is a flow chart of example operations for processing information about an anomaly received from a neighbor sensor according to an embodiment in the present disclosure.
- FIG. 5A-5D illustrate traffic flow for distributing information about a potential anomaly according to an embodiment in the present disclosure.
- FIG. 6 is a flow chart of example operations for classifying a potential anomaly as a valid threat according to an embodiment in the present disclosure.
- FIG. 7A-7C illustrate traffic flow for classifying a potential anomaly as a valid threat transactions for distributing information according to an embodiment in the present disclosure.
- Embodiments of the present disclosure provide techniques for a network sensor to distribute information about possible anomalies to neighboring sensors in a network.
- information such as address dispersion information generated by monitoring source/destination address of packets with payloads that match an anomaly signature
- the network of sensors may be able to more quickly classify an anomaly as a valid threat, which may prevent damage.
- address dispersion information may be generated and tracked by setting bits in source and/or destination bitmaps to indicate addresses observed in matching packets. Each bit may correspond to an address, range of addresses, or a hash generated based on an address. In any case, a high count of bits set in a bitmap corresponds to a high degree of address dispersion (which may indicate wide spread propagation). Sharing this address dispersion information with other sensors lets those sensors know packets matching a given signature have been observed at other sensor locations, and how often. As a result, each sensor may have an up-to-date view of the network, which may lead to faster anomaly detection.
- FIG. 1 illustrates an example network 100 in which anomaly information may be shared among multiple sensors, in accordance with embodiments of the present disclosure.
- four sensors S 1 -S 4 are shown however, actual networks may have hundreds of sensors or more.
- the term sensor generally refers to any type of device used to inspect network traffic and, in some embodiments, may implement Automatic Signature Extraction (ASE) algorithms.
- ASE Automatic Signature Extraction
- a sensor may be a standalone device or may be integrated into a network component, such as a switch or router.
- the network 100 may use any combination of wireless and wireline transmission services and may include Intranet and/or the Internet.
- the sensors may operate as peers in a peer-to-peer network that share information about potential threats, as described herein.
- the network may have a collector component 104 .
- the sensors may notify the collector 104 of potential threats and the collector 104 may serve as a repository for information on potential threats and may also notify some or all the sensors when a potential threat has been validated.
- the sensors may include any suitable components to monitor network traffic, extract signatures for potential anomalies, detect when payload in packets match a given signature, and gather corresponding information or “metadata” about the signature.
- FIG. 2 illustrates an example sensor 200 according to an embodiment. As illustrated, the sensor 200 may include signature detection logic 202 , threshold logic 207 and a signature database 204 .
- the signature detection logic 202 may monitor network traffic in an effort to packets with payloads that match an anomaly signature (matching packets).
- the anomaly signatures may be generated, for example, based on analysis of packets with similar content.
- the signature detection logic 202 may employ any suitable signature extraction algorithm.
- the signature detection logic may utilize algorithms that generate different hash values on different portions of a packet to overcome polymorphic attacks that vary certain content in an effort to avoid detection.
- the signature detection logic 202 may extract various types of parameters, collectively referred to as signature metadata 206 , based on content of the matching packet. For some embodiments, the signature detection logic 202 may not bother to generate and maintain signature metadata 206 until a signature has been observed for some predetermined number of times (e.g., a prevalence threshold).
- the metadata may include a variety of different data elements, such as a signature hash 208 , source address bitmap 210 , destination address bitmap 212 and one or more bitmap counters 214 .
- the signature hash 208 may be generated by any suitable signature generation algorithm. While a list of source and destination addresses could be maintained, such a list might grow very large and maintaining such lists for several anomalies might prove prohibitive.
- bitmaps provide an efficient structure to track address dispersion information.
- the bitmaps may be used to track address dispersion, by providing an indication of the number of different addresses (or address ranges) that have been observed in source and destination addresses of matching packets.
- High address dispersion may be indicative of an attack that is spreading to different network nodes. A large number of different source addresses will indicate the attack has already spread to different nodes, while a large number of destination addresses will indicate the attack is still propagating to other nodes.
- Each bit in an address bitmap may be indicative of the observance of a corresponding address (or address in a given address range) in a matching packet. Therefore, a measure of address dispersion may be provided by counters 214 that track the number of bits that are set in an address bitmap.
- the threshold logic 207 may track address dispersion by monitoring the bitmap count(s) 214 and comparing them against one or more thresholds to decide if signature information should be propagated and/or an anomaly should be classified as a probable threat.
- the threshold logic 207 may compare bitmap counters to a distribution threshold set to correspond to a given level of address dispersion that warrants notifying neighboring sensors. If this distribution threshold is exceeded, a sensor will distribute anomaly information (e.g., address dispersion in the form of the bitmaps and other information) to peer sensors.
- anomaly information e.g., address dispersion in the form of the bitmaps and other information
- an originating sensor may distribute anomaly information in the form of a request for information sent to neighbor sensors.
- receiving nodes may aggregate the information received from the originating sensor with locally generated information about the anomaly.
- a receiving sensor may reply to such a request (from an originating sensor) with a response that includes its own information gathered for the corresponding anomaly.
- the receiving sensor may also propagate the request to its neighbors, based on an intelligent distribution algorithm designed to limit redundant transmissions.
- parameters such as the number of occurrences of each anomaly are also shared between the sensors for categories such as port, timeframe, and protocol, or more generally, anything that can help determine if a bitstream is anomalous or not.
- Information shared may be a list of suspected signatures along with the occurrence rate of each signature which may be sent in summary form by using a Bloom Filter.
- a bitmap counter that summarizes a list of source and destination addresses that have been traversed may be shared.
- a list of IP addresses that are suspected of sending packets with a probable threat may be shared.
- Aggregate header information about suspected anomalies (SYN, SYN ACK, ICMP and RST, etc.) may also be shared.
- a sensor may choose to notify other sensors of an anomaly by sharing information after enough packets matching a signature for the anomaly have been seen. This sharing of information may allow each sensor to maintain a current view of the activity of the potential threat in the network and may help speed detection, limit propagation, and minimize damage.
- FIG. 3 illustrates example operations 300 that may be performed at a sensor for distributing information about an anomaly according to an embodiment.
- the operations begin, at 302 , by monitoring traffic to detect packets with payloads that match an anomaly signature.
- the sensor sets bits in source and destination address bitmaps for the anomaly signature to track address dispersion.
- the sensor may continue to monitor traffic and gather address dispersion information by setting bits in the address bitmaps until the bit count exceeds a distribution threshold, as determined at 306 .
- the sensor may distribute information about a corresponding anomaly, at 308 .
- the information may be distributed in the form of a request that serves to both provide neighbor sensors with anomaly information generated by the originating sensor as well as request information about the anomaly generated by the neighbor sensors receiving the request.
- Sharing anomaly information among sensors may help speed detection of an attack. For example, if many sensors see the same anomaly, there is a greater chance of the anomaly turning out to be a probable threat.
- a sensor may know with a greater degree of certainty that an anomaly is a probable threat if the ratio of the sensors which have seen the anomaly to those who have not seen the anomaly is greater than one. This ratio may be computed when gathering address information to prevent false positives.
- Sensors receiving information from an originating sensor may act on the information in a number of ways.
- the receiving sensor may distribute information to other neighbor sensors within some path distance, for example, within two hops of the originating sensor.
- a receiving node may intelligently propagate a request containing information to other sensors, for example, based on a probability inversely proportional to the number of hops between the originating sensor and the possible receiving sensor.
- FIG. 4 illustrates example operations 400 that a sensor may perform when receiving anomaly information from another sensor.
- the operations 400 begin, at 402 , when the sensor receives information about an anomaly signature from an originating node (e.g., in the form of a request).
- the information may be propagated to other peer nodes. As described above, the propagation may occur based on a hop distance between the receiving node and the originating node or a probability.
- received address dispersion information may be aggregated with locally generated address dispersion information, for example, by performing a bitwise OR function on bits in received bitmaps with local bitmaps. As will be described in greater detail below, if the aggregated address dispersion information indicates the number of different addresses of the matching packets exceeds a detection threshold (e.g., hither than the distribution threshold), the anomaly signature may be reported as a probable anomaly.
- a detection threshold e.g., hither than the distribution threshold
- the receiving sensor may respond to the originating sensor. How and when the sensor responds may depend on a particular embodiment and particular circumstance. For example, a receiving node may delay responding to a request until after collecting more information. On the other hand, a receiving node may respond pro-actively (sooner) if the threat is perceived to be significant. The severity of the threat may be determined by checking gathered address dispersion information to see if the sensor has seen packets pertaining to the threat earlier. The severity of the threat may also be determined by checking to see if the received address dispersion information and the local address dispersion information of the receiving node are significantly different. If the receiving sensor deems the threat severe enough according to varying degrees of the above one or more factors, the receiving sensor may answer the originating sensor and/or send out its own request.
- sensors may maintain a table of the unique original sender ID, and a sequent number of the (original) address dispersion information message may be stored at the sensor so if the same message is received again, it will not be re-distributed. Additionally, when the message is sent, a sensor may append its source ID to the message so if it is seen again it will not be forwarded.
- NAT Network Address Translation
- multiple hosts may be sharing a few IP addresses. These hosts often use private IP addresses that may overlap with other sensors which may be problematic because the NAT addressing scheme may interfere with the accurate gathering of address dispersion information.
- NAT Network Address Translation
- One way to solve this problem is to enable sensing only on the directional traffic of the public interface. This method may best be used on NAT routers with multiple public IP's or NAT routers that sense just one or two active hosts.
- Another way to prevent this problem is to reverse the public IP endian and XOR the result with the private IP addresses. This XOR'ed value will be relatively unique.
- Another method to solve this problem may be to map one private IP address to the public IP address and map subsequent private IP addresses seen with the signatures using the XOR method described above.
- FIG. 5A-5D illustrate example transactions for distributing anomaly information in the network 100 according to an embodiment of the present disclosure.
- sensor S 1 detects malicious payload 502 (e.g., that matches an anomaly signature).
- malicious payload 502 e.g., that matches an anomaly signature.
- S 1 sets bits in the bitmaps, the distribution threshold is exceeded.
- S 1 distributes anomaly information in the form of a request 504 to neighbor sensors S 2 and S 4 .
- the anomaly information in the request may include a variety of information, such as the address bitmaps, bitmap counts, anomaly signature hash, and the like.
- receiving sensors may propagate the request, in some cases, within some distance from the originating sensor.
- sensor S 2 may propagate the request 504 to neighboring sensor S 3 .
- a receiving sensor may also respond to the request, in an effort to share its own information regarding the anomaly. For example, as illustrated in FIG. 5D , S 2 may send a response 506 back to originating sensor Si.
- an anomaly when a bit count exceeds a detection threshold, an anomaly may be classified as a probable threat and notification may be sent, for example, to a collector and/or to other nodes.
- the bit count may exceed a detection threshold as a result of increasing the bit count in response to “locally” detecting a matching packet or by aggregating bit maps received from an originating sensor with locally generated bitmap.
- a collector receiving a notification from a sensor may send out a signature bitmap to a set of sensors or all sensors of a network to notify them of the validated threat.
- FIG. 6 is a flow chart of example operations 600 that may be performed by a sensor to classify a threat as valid when a detection threshold is exceeded.
- the operations begin, at 602 , by monitoring traffic to detect packets with payloads that match an anomaly signature.
- the sensor sets bits in source/destination address bitmaps for the anomaly signature to track address dispersion.
- the sensor receives information about an anomaly signature from other (peer) sensors, for example, in the form of requests.
- this received information about the anomaly signature is aggregated with local information, for example, by bit-wise ORing of address bitmaps. If the received information included different address bits, the aggregation will result in additional bits being set.
- the sensor may continue to gather information in this manner until the bit count exceeds the detection threshold, as determined at 610 . Once the bit map exceeds the detection threshold, the threat may be classified as a probable threat, at 612 , and other nodes may be notified.
- notification may be sent to other nodes via the collector, as illustrated in FIGS. 7A-7C .
- FIG. 7A illustrates S 1 detecting payload that results in the bit count exceeding the detection threshold.
- aggregating bit map information received from another sensor may also result in the detection threshold being exceeded.
- S 1 may send anomaly information to the collector 104 .
- the collector 104 may serve as a repository of anomaly information and, as illustrated in FIG. 7C , may also distribute confirmed anomaly signature information to sensors S 1 -S 4 .
- the distribution and detection thresholds may be set to values chosen in a manner that attempts to efficiently distribute information among sensors and classify anomalies as threats.
- one or more of the thresholds may be adaptive.
- the distribution threshold may be adaptive, based on network traffic. For example, if too many distribution messages are being generated, flooding the network with unnecessary traffic, the distribution threshold may be increased. As an alternative, the distribution threshold may be decreased if relatively few messages are being generated.
- Some form of history-based adjustments may also be employed with either the distribution or detection thresholds. For example, one or more of these threshold values change in response to a distributed address dispersion information. Either threshold value may change, for example, based on whether the distributed address dispersion information gathered based on an anomaly signature, actually turns out to be a probable anomaly.
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Computer Hardware Design (AREA)
- Computing Systems (AREA)
- General Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
Description
- 1. Technical Field
- Embodiments of the present disclosure generally relate to network security and, more particularly, to detection of malicious payload.
- 2. Description of the Related Art
- In networks, malicious code (commonly referred to as anomalies or malware) may intrude and steal system resources. Such malware is often polymorphic in nature, avoiding detection by altering the content of their payload in an effort to avoid detection.
- Advanced detection techniques utilize Automatic Signature Extraction (ASE) algorithms that are capable of extracting common signatures for malware packets, even if some portion of the content is altered. Unfortunately, such malware may spread rapidly, propagating too many network nodes before detection.
- Therefore, what is needed is a technique to rapidly detect malware.
- Embodiments of the present disclosure generally provide methods and apparatus for distributing information about possible anomalies in a network.
- The method generally includes detecting matching packets with payloads that match an anomaly signature, gathering address dispersion information for the matching packets, the address dispersion information providing an indication of a number of different addresses of the matching packets, wherein the different addresses comprise at least one of source addresses and destination addresses, and distributing the address dispersion information for the matching packets to one or more peer nodes if the address dispersion information indicates the number of different addresses of the matching packets exceeds a distribution threshold.
- One apparatus generally includes logic for detecting matching packets, received over a network, with payloads that match an anomaly signature, a data structure for gathering address dispersion information for the matching packets, the address dispersion information providing an indication of a number of different addresses of the matching packets, wherein the different addresses comprise at least one of source addresses and destination addresses, and logic for distributing the address dispersion information for the matching packets to one or more peer nodes in the network if the address dispersion information indicates the number of different addresses of the matching packets exceeds a distribution threshold.
- One apparatus generally includes means for detecting matching packets, received over a network, with payloads that match an anomaly signature, means for gathering address dispersion information for the matching packets, the address dispersion information providing an indication of a number of different addresses of the matching packets, wherein the different addresses comprise at least one of source addresses and destination addresses, and means for distributing the address dispersion information for the matching packets to one or more peer nodes in the network if the address dispersion information indicates the number of different addresses of the matching packets exceeds a distribution threshold.
- So that features of the present disclosure can be understood in detail, a particular description of the present disclosure may be had by reference to embodiments, some of which are illustrated in the appended drawings. It is to be noted, however, that the appended drawings illustrate only typical embodiments of this disclosure and are therefore not to be considered limiting of its scope, for the present disclosure may admit to other equally effective embodiments.
-
FIG. 1 illustrates an example network topology according to an embodiment in the present disclosure. -
FIG. 2 illustrates an example sensor according to an embodiment in the present disclosure. -
FIG. 3 is a flow chart of example operations for distributing information about a potential anomaly to neighbor sensors according to an embodiment in the present disclosure. -
FIG. 4 is a flow chart of example operations for processing information about an anomaly received from a neighbor sensor according to an embodiment in the present disclosure. -
FIG. 5A-5D illustrate traffic flow for distributing information about a potential anomaly according to an embodiment in the present disclosure. -
FIG. 6 is a flow chart of example operations for classifying a potential anomaly as a valid threat according to an embodiment in the present disclosure. -
FIG. 7A-7C illustrate traffic flow for classifying a potential anomaly as a valid threat transactions for distributing information according to an embodiment in the present disclosure. - Embodiments of the present disclosure provide techniques for a network sensor to distribute information about possible anomalies to neighboring sensors in a network. By distributing information, such as address dispersion information generated by monitoring source/destination address of packets with payloads that match an anomaly signature, the network of sensors may be able to more quickly classify an anomaly as a valid threat, which may prevent damage.
- For certain embodiments, address dispersion information may be generated and tracked by setting bits in source and/or destination bitmaps to indicate addresses observed in matching packets. Each bit may correspond to an address, range of addresses, or a hash generated based on an address. In any case, a high count of bits set in a bitmap corresponds to a high degree of address dispersion (which may indicate wide spread propagation). Sharing this address dispersion information with other sensors lets those sensors know packets matching a given signature have been observed at other sensor locations, and how often. As a result, each sensor may have an up-to-date view of the network, which may lead to faster anomaly detection.
-
FIG. 1 illustrates anexample network 100 in which anomaly information may be shared among multiple sensors, in accordance with embodiments of the present disclosure. For illustrative purposes, four sensors S1-S4 are shown however, actual networks may have hundreds of sensors or more. As used herein, the term sensor generally refers to any type of device used to inspect network traffic and, in some embodiments, may implement Automatic Signature Extraction (ASE) algorithms. A sensor may be a standalone device or may be integrated into a network component, such as a switch or router. - The
network 100 may use any combination of wireless and wireline transmission services and may include Intranet and/or the Internet. The sensors may operate as peers in a peer-to-peer network that share information about potential threats, as described herein. As illustrated, the network may have acollector component 104. As will be described in greater detail below, the sensors may notify thecollector 104 of potential threats and thecollector 104 may serve as a repository for information on potential threats and may also notify some or all the sensors when a potential threat has been validated. - The sensors may include any suitable components to monitor network traffic, extract signatures for potential anomalies, detect when payload in packets match a given signature, and gather corresponding information or “metadata” about the signature.
FIG. 2 illustrates anexample sensor 200 according to an embodiment. As illustrated, thesensor 200 may includesignature detection logic 202,threshold logic 207 and asignature database 204. - The
signature detection logic 202 may monitor network traffic in an effort to packets with payloads that match an anomaly signature (matching packets). The anomaly signatures may be generated, for example, based on analysis of packets with similar content. Thesignature detection logic 202 may employ any suitable signature extraction algorithm. For some embodiments, the signature detection logic may utilize algorithms that generate different hash values on different portions of a packet to overcome polymorphic attacks that vary certain content in an effort to avoid detection. - In response to detecting a matching packet, the
signature detection logic 202 may extract various types of parameters, collectively referred to assignature metadata 206, based on content of the matching packet. For some embodiments, thesignature detection logic 202 may not bother to generate and maintainsignature metadata 206 until a signature has been observed for some predetermined number of times (e.g., a prevalence threshold). - As illustrated, the metadata may include a variety of different data elements, such as a
signature hash 208,source address bitmap 210,destination address bitmap 212 and one ormore bitmap counters 214. Thesignature hash 208 may be generated by any suitable signature generation algorithm. While a list of source and destination addresses could be maintained, such a list might grow very large and maintaining such lists for several anomalies might prove prohibitive. For certain embodiments, bitmaps provide an efficient structure to track address dispersion information. - The bitmaps may be used to track address dispersion, by providing an indication of the number of different addresses (or address ranges) that have been observed in source and destination addresses of matching packets. High address dispersion may be indicative of an attack that is spreading to different network nodes. A large number of different source addresses will indicate the attack has already spread to different nodes, while a large number of destination addresses will indicate the attack is still propagating to other nodes. Each bit in an address bitmap may be indicative of the observance of a corresponding address (or address in a given address range) in a matching packet. Therefore, a measure of address dispersion may be provided by
counters 214 that track the number of bits that are set in an address bitmap. - The
threshold logic 207 may track address dispersion by monitoring the bitmap count(s) 214 and comparing them against one or more thresholds to decide if signature information should be propagated and/or an anomaly should be classified as a probable threat. - For example, the
threshold logic 207 may compare bitmap counters to a distribution threshold set to correspond to a given level of address dispersion that warrants notifying neighboring sensors. If this distribution threshold is exceeded, a sensor will distribute anomaly information (e.g., address dispersion in the form of the bitmaps and other information) to peer sensors. - For certain embodiments, an originating sensor may distribute anomaly information in the form of a request for information sent to neighbor sensors. As will be described in greater detail below, receiving nodes may aggregate the information received from the originating sensor with locally generated information about the anomaly. A receiving sensor may reply to such a request (from an originating sensor) with a response that includes its own information gathered for the corresponding anomaly. For certain embodiments, the receiving sensor may also propagate the request to its neighbors, based on an intelligent distribution algorithm designed to limit redundant transmissions.
- In addition to sharing address dispersion information, parameters such as the number of occurrences of each anomaly are also shared between the sensors for categories such as port, timeframe, and protocol, or more generally, anything that can help determine if a bitstream is anomalous or not. Information shared may be a list of suspected signatures along with the occurrence rate of each signature which may be sent in summary form by using a Bloom Filter. A bitmap counter that summarizes a list of source and destination addresses that have been traversed may be shared. A list of IP addresses that are suspected of sending packets with a probable threat may be shared. Aggregate header information about suspected anomalies (SYN, SYN ACK, ICMP and RST, etc.) may also be shared.
- As described above, under certain conditions, a sensor may choose to notify other sensors of an anomaly by sharing information after enough packets matching a signature for the anomaly have been seen. This sharing of information may allow each sensor to maintain a current view of the activity of the potential threat in the network and may help speed detection, limit propagation, and minimize damage.
-
FIG. 3 illustratesexample operations 300 that may be performed at a sensor for distributing information about an anomaly according to an embodiment. The operations begin, at 302, by monitoring traffic to detect packets with payloads that match an anomaly signature. At 304, the sensor sets bits in source and destination address bitmaps for the anomaly signature to track address dispersion. - The sensor may continue to monitor traffic and gather address dispersion information by setting bits in the address bitmaps until the bit count exceeds a distribution threshold, as determined at 306. When the bit count exceeds the distribution threshold, the sensor may distribute information about a corresponding anomaly, at 308. As described above, the information may be distributed in the form of a request that serves to both provide neighbor sensors with anomaly information generated by the originating sensor as well as request information about the anomaly generated by the neighbor sensors receiving the request.
- Sharing anomaly information among sensors may help speed detection of an attack. For example, if many sensors see the same anomaly, there is a greater chance of the anomaly turning out to be a probable threat. A sensor may know with a greater degree of certainty that an anomaly is a probable threat if the ratio of the sensors which have seen the anomaly to those who have not seen the anomaly is greater than one. This ratio may be computed when gathering address information to prevent false positives.
- Sensors receiving information from an originating sensor may act on the information in a number of ways. In some embodiments, the receiving sensor may distribute information to other neighbor sensors within some path distance, for example, within two hops of the originating sensor. In an effort to reduce redundant messaging and unnecessarily flooding the network with traffic, a receiving node may intelligently propagate a request containing information to other sensors, for example, based on a probability inversely proportional to the number of hops between the originating sensor and the possible receiving sensor.
-
FIG. 4 illustratesexample operations 400 that a sensor may perform when receiving anomaly information from another sensor. Theoperations 400 begin, at 402, when the sensor receives information about an anomaly signature from an originating node (e.g., in the form of a request). At 404, the information may be propagated to other peer nodes. As described above, the propagation may occur based on a hop distance between the receiving node and the originating node or a probability. - At 406, received address dispersion information may be aggregated with locally generated address dispersion information, for example, by performing a bitwise OR function on bits in received bitmaps with local bitmaps. As will be described in greater detail below, if the aggregated address dispersion information indicates the number of different addresses of the matching packets exceeds a detection threshold (e.g., hither than the distribution threshold), the anomaly signature may be reported as a probable anomaly.
- At 408, the receiving sensor may respond to the originating sensor. How and when the sensor responds may depend on a particular embodiment and particular circumstance. For example, a receiving node may delay responding to a request until after collecting more information. On the other hand, a receiving node may respond pro-actively (sooner) if the threat is perceived to be significant. The severity of the threat may be determined by checking gathered address dispersion information to see if the sensor has seen packets pertaining to the threat earlier. The severity of the threat may also be determined by checking to see if the received address dispersion information and the local address dispersion information of the receiving node are significantly different. If the receiving sensor deems the threat severe enough according to varying degrees of the above one or more factors, the receiving sensor may answer the originating sensor and/or send out its own request.
- When distributing address dispersion information in the form of request messages, duplicated messages may be seen. To eliminate duplicate messages, sensors may maintain a table of the unique original sender ID, and a sequent number of the (original) address dispersion information message may be stored at the sensor so if the same message is received again, it will not be re-distributed. Additionally, when the message is sent, a sensor may append its source ID to the message so if it is seen again it will not be forwarded.
- Further, in a Network Address Translation (NAT) scheme, multiple hosts may be sharing a few IP addresses. These hosts often use private IP addresses that may overlap with other sensors which may be problematic because the NAT addressing scheme may interfere with the accurate gathering of address dispersion information. There are several ways to solve this problem. If only a small amount of sensors are using NAT, NAT will not pose a material impact on false negatives and NAT may be ignored. One way to solve this problem is to enable sensing only on the directional traffic of the public interface. This method may best be used on NAT routers with multiple public IP's or NAT routers that sense just one or two active hosts. Another way to prevent this problem is to reverse the public IP endian and XOR the result with the private IP addresses. This XOR'ed value will be relatively unique. Another method to solve this problem may be to map one private IP address to the public IP address and map subsequent private IP addresses seen with the signatures using the XOR method described above.
-
FIG. 5A-5D illustrate example transactions for distributing anomaly information in thenetwork 100 according to an embodiment of the present disclosure. As illustrated inFIG. 5A , sensor S1 detects malicious payload 502 (e.g., that matches an anomaly signature). For purposes of illustration, it is assumed that when S1 sets bits in the bitmaps, the distribution threshold is exceeded. - Therefore, as illustrated in
FIG. 5B , S1 distributes anomaly information in the form of arequest 504 to neighbor sensors S2 and S4. As described above, the anomaly information in the request may include a variety of information, such as the address bitmaps, bitmap counts, anomaly signature hash, and the like. - As described above, receiving sensors may propagate the request, in some cases, within some distance from the originating sensor. For example, as illustrated in
FIG. 5C , sensor S2 may propagate therequest 504 to neighboring sensor S3. - A receiving sensor may also respond to the request, in an effort to share its own information regarding the anomaly. For example, as illustrated in
FIG. 5D , S2 may send aresponse 506 back to originating sensor Si. - As previously described, when a bit count exceeds a detection threshold, an anomaly may be classified as a probable threat and notification may be sent, for example, to a collector and/or to other nodes. The bit count may exceed a detection threshold as a result of increasing the bit count in response to “locally” detecting a matching packet or by aggregating bit maps received from an originating sensor with locally generated bitmap. For certain embodiments, a collector receiving a notification from a sensor, may send out a signature bitmap to a set of sensors or all sensors of a network to notify them of the validated threat.
-
FIG. 6 is a flow chart ofexample operations 600 that may be performed by a sensor to classify a threat as valid when a detection threshold is exceeded. The operations begin, at 602, by monitoring traffic to detect packets with payloads that match an anomaly signature. At 604, the sensor sets bits in source/destination address bitmaps for the anomaly signature to track address dispersion. At 606, the sensor receives information about an anomaly signature from other (peer) sensors, for example, in the form of requests. At 608, this received information about the anomaly signature is aggregated with local information, for example, by bit-wise ORing of address bitmaps. If the received information included different address bits, the aggregation will result in additional bits being set. - The sensor may continue to gather information in this manner until the bit count exceeds the detection threshold, as determined at 610. Once the bit map exceeds the detection threshold, the threat may be classified as a probable threat, at 612, and other nodes may be notified.
- For some embodiments, notification may be sent to other nodes via the collector, as illustrated in
FIGS. 7A-7C .FIG. 7A illustrates S1 detecting payload that results in the bit count exceeding the detection threshold. As described above, aggregating bit map information received from another sensor may also result in the detection threshold being exceeded. - In any case, as illustrated in
FIG. 7B , S1 may send anomaly information to thecollector 104. Thecollector 104 may serve as a repository of anomaly information and, as illustrated inFIG. 7C , may also distribute confirmed anomaly signature information to sensors S1-S4. - The distribution and detection thresholds may be set to values chosen in a manner that attempts to efficiently distribute information among sensors and classify anomalies as threats. For some embodiments, one or more of the thresholds may be adaptive. For example, the distribution threshold may be adaptive, based on network traffic. For example, if too many distribution messages are being generated, flooding the network with unnecessary traffic, the distribution threshold may be increased. As an alternative, the distribution threshold may be decreased if relatively few messages are being generated.
- Some form of history-based adjustments may also be employed with either the distribution or detection thresholds. For example, one or more of these threshold values change in response to a distributed address dispersion information. Either threshold value may change, for example, based on whether the distributed address dispersion information gathered based on an anomaly signature, actually turns out to be a probable anomaly.
- While the foregoing is directed to embodiments of the present disclosure, other and further embodiments of the present disclosure may be devised without departing from the basic scope thereof, and the scope thereof is determined by the claims that follow.
Claims (20)
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US12/203,658 US8677480B2 (en) | 2008-09-03 | 2008-09-03 | Anomaly information distribution with threshold |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US12/203,658 US8677480B2 (en) | 2008-09-03 | 2008-09-03 | Anomaly information distribution with threshold |
Publications (2)
Publication Number | Publication Date |
---|---|
US20100058469A1 true US20100058469A1 (en) | 2010-03-04 |
US8677480B2 US8677480B2 (en) | 2014-03-18 |
Family
ID=41727323
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US12/203,658 Active 2032-03-20 US8677480B2 (en) | 2008-09-03 | 2008-09-03 | Anomaly information distribution with threshold |
Country Status (1)
Country | Link |
---|---|
US (1) | US8677480B2 (en) |
Cited By (8)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20120207046A1 (en) * | 2009-09-01 | 2012-08-16 | Nec Europe Ltd. | Method for monitoring a network and network including a monitoring functionality |
US8789176B1 (en) * | 2011-03-07 | 2014-07-22 | Amazon Technologies, Inc. | Detecting scans using a bloom counter |
US8943598B1 (en) * | 2014-08-12 | 2015-01-27 | Bank Of America Corporation | Automatic compromise detection for hardware signature for payment authentication |
US20150156213A1 (en) * | 2012-08-13 | 2015-06-04 | Mts Consulting Pty Limited | Analysis of time series data |
US9462040B2 (en) | 2011-12-07 | 2016-10-04 | Cisco Technology, Inc. | Network-based dynamic data management |
US9824356B2 (en) | 2014-08-12 | 2017-11-21 | Bank Of America Corporation | Tool for creating a system hardware signature for payment authentication |
US20170366935A1 (en) * | 2016-06-17 | 2017-12-21 | Qualcomm Incorporated | Methods and Systems for Context Based Anomaly Monitoring |
US11341016B2 (en) * | 2019-05-21 | 2022-05-24 | Cartesiam | Learning method for the detection of anomalies implemented on a microcontroller and associated method for detecting anomalies |
Families Citing this family (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US9699205B2 (en) | 2015-08-31 | 2017-07-04 | Splunk Inc. | Network security system |
GB2584895B (en) * | 2019-06-20 | 2022-03-09 | 1E Ltd | Determining a state of a network |
Citations (10)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20030196095A1 (en) * | 2002-04-11 | 2003-10-16 | International Business Machines Corporation | Detecting dissemination of malicious programs |
US20030212903A1 (en) * | 1998-11-09 | 2003-11-13 | Porras Phillip Andrew | Network surveillance |
US20050229254A1 (en) * | 2004-04-08 | 2005-10-13 | Sumeet Singh | Detecting public network attacks using signatures and fast content analysis |
US20060291490A1 (en) * | 2005-06-28 | 2006-12-28 | Fujitsu Limited | Computer-readable recording medium having recorded worm determination program, worm determination method, and worm determination apparatus |
US20070094730A1 (en) * | 2005-10-20 | 2007-04-26 | Cisco Technology, Inc. | Mechanism to correlate the presence of worms in a network |
US7457965B2 (en) * | 2004-03-05 | 2008-11-25 | Fujitsu Limited | Unauthorized access blocking apparatus, method, program and system |
US20090154406A1 (en) * | 2007-12-18 | 2009-06-18 | Electronics And Telecommunications Research Institute | Dynamic address allocation method for mobile ad hoc network |
US7673342B2 (en) * | 2001-07-26 | 2010-03-02 | Mcafee, Inc. | Detecting e-mail propagated malware |
US7849187B2 (en) * | 2005-09-28 | 2010-12-07 | Electronics And Telecommunications Research Institute | Network status display device and method using traffic pattern map |
US7917957B2 (en) * | 2007-05-29 | 2011-03-29 | Alcatel Lucent | Method and system for counting new destination addresses |
-
2008
- 2008-09-03 US US12/203,658 patent/US8677480B2/en active Active
Patent Citations (11)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20030212903A1 (en) * | 1998-11-09 | 2003-11-13 | Porras Phillip Andrew | Network surveillance |
US7673342B2 (en) * | 2001-07-26 | 2010-03-02 | Mcafee, Inc. | Detecting e-mail propagated malware |
US20030196095A1 (en) * | 2002-04-11 | 2003-10-16 | International Business Machines Corporation | Detecting dissemination of malicious programs |
US7457965B2 (en) * | 2004-03-05 | 2008-11-25 | Fujitsu Limited | Unauthorized access blocking apparatus, method, program and system |
US20050229254A1 (en) * | 2004-04-08 | 2005-10-13 | Sumeet Singh | Detecting public network attacks using signatures and fast content analysis |
US20080307524A1 (en) * | 2004-04-08 | 2008-12-11 | The Regents Of The University Of California | Detecting Public Network Attacks Using Signatures and Fast Content Analysis |
US20060291490A1 (en) * | 2005-06-28 | 2006-12-28 | Fujitsu Limited | Computer-readable recording medium having recorded worm determination program, worm determination method, and worm determination apparatus |
US7849187B2 (en) * | 2005-09-28 | 2010-12-07 | Electronics And Telecommunications Research Institute | Network status display device and method using traffic pattern map |
US20070094730A1 (en) * | 2005-10-20 | 2007-04-26 | Cisco Technology, Inc. | Mechanism to correlate the presence of worms in a network |
US7917957B2 (en) * | 2007-05-29 | 2011-03-29 | Alcatel Lucent | Method and system for counting new destination addresses |
US20090154406A1 (en) * | 2007-12-18 | 2009-06-18 | Electronics And Telecommunications Research Institute | Dynamic address allocation method for mobile ad hoc network |
Cited By (16)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US8953472B2 (en) * | 2009-09-01 | 2015-02-10 | Nec Europe Ltd. | Method for monitoring a network and network including a monitoring functionality |
US20120207046A1 (en) * | 2009-09-01 | 2012-08-16 | Nec Europe Ltd. | Method for monitoring a network and network including a monitoring functionality |
US8789176B1 (en) * | 2011-03-07 | 2014-07-22 | Amazon Technologies, Inc. | Detecting scans using a bloom counter |
US9462040B2 (en) | 2011-12-07 | 2016-10-04 | Cisco Technology, Inc. | Network-based dynamic data management |
US10581932B2 (en) | 2011-12-07 | 2020-03-03 | Cisco Technology, Inc. | Network-based dynamic data management |
US20150156213A1 (en) * | 2012-08-13 | 2015-06-04 | Mts Consulting Pty Limited | Analysis of time series data |
US9578046B2 (en) * | 2012-08-13 | 2017-02-21 | Arbor Networks, Inc. | Analysis of time series data |
US9824356B2 (en) | 2014-08-12 | 2017-11-21 | Bank Of America Corporation | Tool for creating a system hardware signature for payment authentication |
US8943598B1 (en) * | 2014-08-12 | 2015-01-27 | Bank Of America Corporation | Automatic compromise detection for hardware signature for payment authentication |
US20170366935A1 (en) * | 2016-06-17 | 2017-12-21 | Qualcomm Incorporated | Methods and Systems for Context Based Anomaly Monitoring |
US9961496B2 (en) * | 2016-06-17 | 2018-05-01 | Qualcomm Incorporated | Methods and systems for context based anomaly monitoring |
CN109196887A (en) * | 2016-06-17 | 2019-01-11 | 高通股份有限公司 | Method and system for the exception monitoring based on situation |
KR20190018633A (en) * | 2016-06-17 | 2019-02-25 | 퀄컴 인코포레이티드 | Methods and systems for situation-based abnormal monitoring |
KR102495816B1 (en) | 2016-06-17 | 2023-02-02 | 퀄컴 인코포레이티드 | Methods and systems for condition-based abnormal monitoring |
US11341016B2 (en) * | 2019-05-21 | 2022-05-24 | Cartesiam | Learning method for the detection of anomalies implemented on a microcontroller and associated method for detecting anomalies |
US11868197B2 (en) | 2019-05-21 | 2024-01-09 | Stmicroelectronics International N.V. | Learning method for the detection of anomalies implemented on a microcontroller and associated method for detecting anomalies |
Also Published As
Publication number | Publication date |
---|---|
US8677480B2 (en) | 2014-03-18 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US8677480B2 (en) | Anomaly information distribution with threshold | |
US8201252B2 (en) | Methods and devices for providing distributed, adaptive IP filtering against distributed denial of service attacks | |
CN107710680B (en) | Method and device for sending network attack defense strategy and network attack defense | |
US9413616B2 (en) | Detection of network address spoofing and false positive avoidance | |
US8397284B2 (en) | Detection of distributed denial of service attacks in autonomous system domains | |
Weaver et al. | Detecting Forged TCP Reset Packets. | |
JP5015014B2 (en) | Traffic analysis / diagnosis device, traffic analysis / diagnosis system, and traffic tracking system | |
US20120054869A1 (en) | Method and apparatus for detecting botnets | |
CN106534068B (en) | Method and device for cleaning counterfeit source IP in DDOS defense system | |
US10778699B1 (en) | Network attack mitigation based on distributed packet analysis | |
CN106357660B (en) | Method and device for detecting forged source IP in DDOS defense system | |
US20060168649A1 (en) | Method and system for addressing attacks on a computer connected to a network | |
Sahu et al. | Distributed denial of service attacks: a review | |
Maheshwari et al. | Defending network system against IP spoofing based distributed DoS attacks using DPHCF-RTT packet filtering technique | |
JP4259183B2 (en) | Information processing system, information processing apparatus, program, and method for detecting communication abnormality in communication network | |
WO2009064114A2 (en) | Protection method and system for distributed denial of service attack | |
Geneiatakis et al. | A multilayer overlay network architecture for enhancing IP services availability against DoS | |
Nashat et al. | Detecting syn flooding agents under any type of ip spoofing | |
KR101211147B1 (en) | System for network inspection and providing method thereof | |
Al Abri | Detection of MITM attack in LAN environment using payload matching | |
Lokare et al. | Cooperative Gray Hole Attack Discovery and Elimination using Credit based Technique in MANET | |
Cucurull et al. | Surviving attacks in challenged networks | |
Yim et al. | Probabilistic route selection algorithm to trace DDoS attack traffic source | |
Sardana et al. | Dual-level attack detection and characterization for networks under DDoS | |
Bellaïche et al. | SYN flooding attack detection by TCP handshake anomalies |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AS | Assignment |
Owner name: CISCO TECHNOLOGY, INC., CALIFORNIA Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:YEN, CHIU-TIN;LUGANI, SAUMYAVAPUH;MUKHOPADHYAY, SNIGDHENDU;AND OTHERS;SIGNING DATES FROM 20080819 TO 20080827;REEL/FRAME:021477/0265 Owner name: CISCO TECHNOLOGY, INC.,CALIFORNIA Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:YEN, CHIU-TIN;LUGANI, SAUMYAVAPUH;MUKHOPADHYAY, SNIGDHENDU;AND OTHERS;SIGNING DATES FROM 20080819 TO 20080827;REEL/FRAME:021477/0265 |
|
AS | Assignment |
Owner name: CISCO TECHNOLOGY, INC., CALIFORNIA Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:YEN, CHUI-TIN;LUGANI, SAUMYAVAPUH;MUKHOPADHYAY, SNIGDHENDU;AND OTHERS;SIGNING DATES FROM 20080908 TO 20080910;REEL/FRAME:021517/0179 Owner name: CISCO TECHNOLOGY, INC.,CALIFORNIA Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:YEN, CHUI-TIN;LUGANI, SAUMYAVAPUH;MUKHOPADHYAY, SNIGDHENDU;AND OTHERS;SIGNING DATES FROM 20080908 TO 20080910;REEL/FRAME:021517/0179 |
|
STCF | Information on status: patent grant |
Free format text: PATENTED CASE |
|
MAFP | Maintenance fee payment |
Free format text: PAYMENT OF MAINTENANCE FEE, 4TH YEAR, LARGE ENTITY (ORIGINAL EVENT CODE: M1551) Year of fee payment: 4 |
|
MAFP | Maintenance fee payment |
Free format text: PAYMENT OF MAINTENANCE FEE, 8TH YEAR, LARGE ENTITY (ORIGINAL EVENT CODE: M1552); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY Year of fee payment: 8 |