Patent Publication Number: US-2023164176-A1

Title: Algorithmically detecting malicious packets in ddos attacks

Description:
FIELD OF THE INVENTION 
     Embodiments of the present invention relate generally to methods and systems for malware detection and mitigation, and specifically to algorithmically detecting malicious packets in Distributed Denial of Service (“DDoS”) attacks. 
     BACKGROUND OF THE INVENTION 
     Attacks, such as attacks utilizing flooding, denial of service, DDoS, viruses, worms, trojan horses, rouge applications, malware, exploits, spam, phishing, etc., are becoming an ever-increasing problem in today&#39;s Internet. For example, by sending large amounts of malicious packets, denial of service attacks can cause consumption and/or overload of scarce, limited, and/or non-renewable system and/or network resources, such as bandwidth, disk space, CPU time, and/or allocations thereof; destruction and/or alteration of configuration information, such as routing information; disruption of normal operating system functionality; and/or physical destruction and/or alteration of network components, etc. 
     DDoS attacks may be aimed at different types of services available on a network including, for example, DNS, HTTP (e.g., web traffic), encryption, time services, streaming services, VoIP. DDoS attacks may be aimed at vulnerable corporate services such as, for example, DNS that translates Internet names to addresses. DDoS attacks come in mainly two varieties. One attempts to shut down the DNS system specifically in relation to the target site so that no legitimate user can obtain a valid translation and make a request from that site, such as by altering the operation of the DNS server to provide an invalid translation. Another type of DDoS attack attempts to overload a DNS server directly with a flood of malicious packets that exceeds the capacity of the server, thereby preventing access to all sites whose address translations are dependent thereon. 
     Once an attack is successfully detected, standard mitigation tactics are typically inadequate in resolving a DDoS attack. Typical mitigation policies involve discarding all packets destined to a victim server without analyzing whether the packets originated from a legitimate user or an attacker. Also, standard approaches do not offer the ability to export real-time data to other apparatuses, nor do they allow an operator to configure a flexible, customized policy. It should be noted that, in many cases, the malicious packets sent by the attackers have similar structure and layout which, if detected, may be used to drop the malicious packets. 
     As such, a new, scalable, and robust DDoS Detection and Mitigation approach with inherent intelligence, which addresses all the shortcomings discussed above, is desirable. Such an approach should be capable of maintaining accurate state information to check for anomalous traffic patterns (to detect a variety of high rate DDoS attacks), should be capable of distinguishing between an attacker and a legitimate user when an attack is detected, should allow an operator to configure a flexible mitigation policy, and should be capable of operating without degrading the overall system performance (forwarding data path or control plane CPU). 
     SUMMARY OF THE INVENTION 
     The purpose and advantages of the illustrated embodiments will be set forth in and apparent from the description that follows. Additional advantages of the illustrated embodiments will be realized and attained by the devices, systems and methods particularly pointed out in the written description and claims hereof, as well as from the appended drawings. 
     In accordance with a purpose of the illustrated embodiments, in one aspect, a monitoring system and method for detecting patterns using statistical analysis is provided. The method includes receiving a subset of structured data having a plurality of fields. A plurality of value combinations is generated for the plurality of fields using a statistical combination function. Each combination of the generated plurality of value combinations is stored as a separate entry in a results table. The entry in the results table includes a counter associated with the stored combination. A value of the counter is incremented for every occurrence of the stored combination in the generated plurality of value combinations. The results table is sorted based on the counters&#39; values and based on a number of fields in each combination. One or more of the following is calculated: a) Time-to-live distribution for each combination; b) average packet length and standard deviation for each combination; c) average inter-packet length and standard deviation for each combination; and d) the packet per second rates for each combination using first and last seen timestamps. One or more entries having highest counter values are identified in the results table. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
       The accompanying appendices and/or drawings illustrate various, non-limiting, examples, inventive aspects in accordance with the present disclosure: 
         FIG.  1    is a schematic diagram showing network architecture and the relationship between an attack mitigation device and protected network according to one embodiment of the present invention; 
         FIG.  2    is a flowchart illustrating a method for detecting patterns using statistical analysis in accordance with the illustrated embodiments; 
         FIG.  3    is a block diagram of the attack mitigation device of  FIG.  1   , in accordance with an embodiment of the present invention; and 
         FIG.  4    is an exemplary screenshot of a user interface displaying malicious attack detection results, according to one or more embodiments discussed herein. 
     
    
    
     DETAILED DESCRIPTION OF CERTAIN EMBODIMENTS 
     The present invention is now described more fully with reference to the accompanying drawings, in which illustrated embodiments of the present invention are shown wherein like reference numerals identify like elements. The present invention is not limited in any way to the illustrated embodiments as the illustrated embodiments described below are merely exemplary of the invention, which can be embodied in various forms, as appreciated by one skilled in the art. Therefore, it is to be understood that any structural and functional details disclosed herein are not to be interpreted as limiting, but merely as a basis for the claims and as a representative for teaching one skilled in the art to variously employ the present invention. Furthermore, the terms and phrases used herein are not intended to be limiting but rather to provide an understandable description of the invention. 
     Unless defined otherwise, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this invention belongs. Although any methods and materials similar or equivalent to those described herein can also be used in the practice or testing of the present invention, exemplary methods and materials are now described. It must be noted that as used herein and in the appended claims, the singular forms “a”, “an,” and “the” include plural referents unless the context clearly dictates otherwise. Thus, for example, reference to “a stimulus” includes a plurality of such stimuli and reference to “the signal” includes reference to one or more signals and equivalents thereof known to those skilled in the art, and so forth. 
     It is to be appreciated the embodiments of this invention as discussed below are preferably a software algorithm, program or code residing on computer usable medium having control logic for enabling execution on a machine having a computer processor. The machine typically includes memory storage configured to provide output from execution of the computer algorithm or program. 
     As used herein, the term “software” is meant to be synonymous with any code or program that can be in a processor of a host computer, regardless of whether the implementation is in hardware, firmware or as a software computer product available on a disc, a memory storage device, or for download from a remote machine. The embodiments described herein include such software to implement the equations, relationships and algorithms described below. One skilled in the art will appreciate further features and advantages of the invention based on the below-described embodiments. Accordingly, the invention is not to be limited by what has been particularly shown and described, except as indicated by the appended claims. 
     In exemplary embodiments, a computer system component may constitute a “module” that is configured and operates to perform certain operations as described herein below. Accordingly, the term “module” should be understood to encompass a tangible entity, be that an entity that is physically constructed, permanently configured (e.g., hardwired) or temporarily configured (e.g. programmed) to operate in a certain manner and to perform certain operations described herein. 
     It is to be further understood the illustrated embodiments of the present invention describe a system, apparatus and method for avoiding and mitigating the harmful effects of a DDoS attack on a computer system/device or network. 
     Turning now descriptively to the drawings, in which similar reference characters denote similar elements throughout the several views,  FIG.  1    illustrates the relationship between the protected network  100 , attack mitigation device  102 , Internet  104 , and external host devices  106   a ,  106   b  . . .  106   n.    
     In a typical implementation, the external host devices  106   a ,  106   b  . . .  106   n  (also referred to as external devices or host devices) attempt to connect to protected devices  108  within the protected network  100  typically via a private network or a public computer network such as the Internet  104 . Examples of external host devices include servers, laptops, desktop computers, tablet devices, mobile phones, mobile computing devices, video games systems, televisions and other similar devices and systems having Internet connectivity. 
     In a preferred embodiment, the protected network  100  is protected by the attack mitigation device  102  preferably located between the Internet  104  and the protected network  100 . Usually, the protected network  100  is an enterprise network, such as a school network, business network, and government network, to list a few examples. In other embodiments, the attack mitigation device  102  is located within the Internet, service provider network or enterprise network rather than as a network edge as illustrated. It is to be appreciated that when deployed within the protected network, traffic is diverted to the mitigation device  102 . 
     The mitigation device  102  preferably includes a packet processing system preferably having an external high-speed network interface  110  and a protected high-speed network interface  112 . Under current technology, these interfaces are capable of handling 1.0-100 Gbps, for example. The mitigation device  102  may further include processors  114  that preferably process the packets received at interfaces  110  and  112 . Additionally, a central processing unit (CPU), random access memory (RAM), and a storage medium  116  are preferably used to further support the processing of the received packets and are described in detail below in conjunction with  FIG.  3   . The storage medium  116  also preferably stores results tables  118  used in the below described pattern detection process as well as other possible information such as predefined filter rules. 
     In a typical implementation, the mitigation device  102  authenticates all external host devices  106   a ,  106   b  . . .  106   n  before allowing the external devices to access the protected devices  108  within the protected network  100 . 
     To protect against DoS attacks, the mitigation device  102  distinguishes between requests from legitimate hosts  106   a - 106   n  and attack traffic from attacking host  120  by performing an analysis procedure that combines content analysis with statistical analysis. Advantageously, the mitigation device  102  can perform the analysis either on live or stored data. In either case, the results of such analysis can enable the mitigation device  102  to provide sophisticated attack protection services such as blocking packets matching the detected patterns in attack traffic, either in a manual or automated fashion. The mitigation device  102  can also perform pattern detection analysis on the packet payload, to immediately detect, for example, a particular application specific malicious attack pattern. 
     As noted above, typically, the mitigation device  102  may employ a combination of different analysis procedures/algorithms (e.g., content analysis and statistical analysis). The mitigation device  102  stores the results of the combined analysis in a results table  118 . In one embodiment, the results table  118  is a data structure that stores unique combinations of all field values contained in a subset of structured data (such as combinations of all fields contained in the packet headers). As used herein, the term “structured data” refers to data that is defined or organized according to a fixed structure. The results table  118  also includes one or more counters that keep track of the number of times a particular unique combination of fields is detected. The host table is  118  is typically allocated a fixed amount of memory for storing this information. However, it should be noted, that at least some of the protected devices  108  (e.g., DNS servers) may handle millions of requests every hour from many different external devices  106   a - 106   n . In a conventional DDoS attack mitigation device, the large volume and large number of unique host addresses may make analyzing incoming traffic packets on an individual basis problematic, because it may consume too much system resources. Thus, the conventional DDoS protection solutions are ill-suited to mitigate large-scale attacks. 
     Advantageously, the embodiments disclosed herein offer a novel approach that can detect and mitigate a large-scale attack campaign where a vast number of attack tools participate in attacking the protected network  100 . As discussed further below, the attack mitigation device  102  is configured to utilize one or more statistical techniques to detect attack patterns much faster and in much greater detail than existing malicious attack mitigation solutions, thusly making the disclosed technique more efficient in responding to distinct changes in attack patterns. In various embodiments, the combination of content and statistical analysis enables the mitigation device  102  to fully automate the “detect-mitigate- analyze results” cycle, thereby reducing the time needed to detect and mitigate sophisticated attacks in fully automated mode and improve the overall user experience. 
     According to exemplary configuration illustrated in  FIG.  1   , the attack mitigation device  102  may comprise a Client Edge (CE) device. The CE device can provide entry points into the protected network  100 . In alternative configuration, the attack mitigation device  102  may comprise a virtual device. In other words, at least some of the embodiments do not require the attack mitigation device  102  to be a physical hardware device or to be located in a particular part of the network infrastructure, as long as the attack mitigation device  102  can be in the path of the incoming traffic to the protected network  100 . 
       FIG.  2    shows an exemplary and non-limiting flowchart illustrating a method for mitigating network attacks in accordance with certain illustrated embodiments. Before turning to description of  FIG.  2   , it is noted that the flow diagram in  FIG.  2    shows example in which operational steps are carried out in a particular order, as indicated by the lines connecting the blocks, but the various steps shown in this diagram can be performed in any order, or in any combination or sub-combination. It should be appreciated that in some embodiments some of the steps described below may be combined into a single step. In some embodiments, one or more additional steps may be included. 
     While the embodiments describe the network attack mitigation device with specific reference to steps directed to detect security and performance issues and/or mitigate detected breaches of a security policy, alternative data analyzing devices may be used provided they are adapted to apply content-specific logic to processing structured data in order to detect underlying patterns. 
     Existing security solutions for different types of networks typically identify attacks by either analyzing individual packets for malicious content (such systems as, but not limited to, Intrusion Detection Systems (IDS) and Intrusion Protection Systems (IPS)) or by counting how many times a specific value is seen in packet flow (e.g., Netflow analysis systems). Even under ideal circumstances, significant computing resources are required to perform such analysis on pre-stored network data. In contrast, various embodiments of the present invention contemplate an alternative approach that combines content analysis with statistical analysis to efficiently detect underlying attack patterns either on live data to be directed out of the live network environment or network traffic data stored in a file or other storage (e.g., register and/or memory) location. In one embodiment described below, to protect against DDoS attacks, the mitigation device  102  utilizes this approach to take a snapshot of the attack traffic (either volume or time based) and then calculate how often both the content of each packet header field and each field combination appear in the attack traffic. 
     More specifically, at step  202 , the mitigation device  102  receives a subset of structured data having a plurality of fields. For example, this subset may include a subset (snapshot) of the traffic flow records. In one embodiment, the mitigation device  102  may obtain data that is representative of particular network traffic transmitted over a network during a particular time interval which may be loaded, for example, from a Packet Capture (PCAP) file or some other type of log file. In another embodiment, packets flowing through the network may be intercepted and analyzed by the mitigation device  102  to detect whether or not one or more components of the protected network  100  are being attacked and/or protect the one or more protected components  108  from being overloaded. In some embodiments functionality of the mitigation device  102  may include selective interception of packets, selective modification of those intercepted packets and the subsequent release/reinsertion of the packets, modified or unmodified, and/or release of new packets, back into the general stream of network traffic. Table 1 shown below illustrates an exemplary snapshot that includes packet header information associated with ten different packets. While only ten packets are shown in Table 1, a subset can comprise any number of packets. For example, a subset can comprise from approximately 1000 packets to approximately 5000 packets. As computational systems become more powerful, it is conceivable that the mitigation device  102  can process a substantially higher number of packets without degrading the overall performance of the system. 
     
       
         
           
               
               
               
               
               
               
             
               
                 TABLE 1 
               
               
                   
               
               
                   
                   
                 Source  
                 Destination  
                 Destination 
                 Packet  
               
               
                   
                 Source IP 
                 Port 
                 IP 
                 Port 
                 Length 
               
               
                   
               
             
            
               
                   
               
            
           
           
               
               
               
               
               
               
            
               
                   
                  1.2.3.4 
                 1234 
                 10.2.55.87 
                 80 
                 120 
               
               
                   
                  4.5.6.7 
                 54321 
                 10.2.55.87 
                 80 
                 55 
               
               
                   
                  8.9.10.11 
                 5324 
                 10.2.55.87 
                 80 
                 230 
               
               
                   
                 12.13.14.15 
                 33434 
                 10.2.55.87 
                 80 
                 45 
               
               
                   
                 16.17.18.19 
                 3433 
                 10.2.55.87 
                 80 
                 55 
               
               
                   
                  1.2.3.4 
                 5324 
                 10.2.55.87 
                 80 
                 15 
               
               
                   
                 20.21.22.23 
                 8879 
                 10.2.55.87 
                 80 
                 55 
               
               
                   
                  1.2.3.4 
                 1234 
                 10.2.55.87 
                 80 
                 400 
               
               
                   
                 24.25.26.27 
                 4234 
                 10.2.55.87 
                 80 
                 55 
               
               
                   
                 28.29.30.31 
                 8774 
                 10.2.55.87 
                 80 
                 55 
               
               
                   
               
            
           
         
       
     
     Next, at step  203 , the structured data of step  202  is sorted by its timestamp to facilitate calculation of inter-packet delay, as described herein. In accordance with the illustrated embodiments, it is to be appreciated that during the below described statistical analysis process, information about how often each potential combination of all fields in network packets is generated and analyzed. This information is then preferably analyzed further, producing a list of the most commonly seen combinations of traffic patterns in the PCAP. Thus, by extending this process for each packet seen in the PCAP, DDoS Metadata is inferred providing additional information about the observed properties, including (but not limited to): 1) The distribution and frequency of Source and Destination IP addresses, whereby by analyzing the distribution and frequency of source and destination IP addresses, it is determine if an attacker is using an advanced attack technology called Carpet Bombing to either attack an entire subnet or is using the destination services as Carpet Bombing Reflectors against other victims; 2) Average packet length and standard deviation of packets matching a combination whereby, for instance, during a UDP flooding attack, an attacker will often vary the size and content of the attack payload, thus the average packet length and standard deviation can then in many scenarios be used to distinguish attack traffic from legitimate traffic, hence allowing for more surgical precision when mitigating the attack; 3) Inter-packet timing and standard deviation, whereby in transactional type traffic generated by typical users (e.g., Web browsing), the internet traffic will often be bursty, with both random and long delays between bursts. Thus, in many scenarios, the attack traffic (which is typically machine generated), exhibit either fixed intervals between individual attack packets and/or includes patterns which can be identified with inter-packet timing analysis. Thus, in regard to Application Layer DDoS attacks, the attacker typically establishes multiple sessions attempting to overload the destination server and/or application(s). In accordance with the illustrated embodiments, using inter-packet timing analysis for the source IPs of both suspected attackers and legitimate users, machine generated network traffic can be readily distinguished from legitimate user traffic thus enabling rapid detection and mitigation of these type of attacks; and 4) using a Time-to-live (TTL) analysis, when a network packet is generated by a network connected device, it will have an initial TTL value which varies based on the operating system used (e.g., Windows=128, Linux=64). This TTL value is preferably be decreased by 1 for each network hop which the packet traverses. Thus, by analyzing the TTL distribution of the network packets matching a specific combination, it is possible to: A) determine if the suspect attack is spoofed. For instance, if the TTL values for a combination including the IP source address have large variations, this is a very strong indicator of the network packets matching the combination are spoofed and being generated by a distributed Botnet. And B) match the measured TTL distribution against expected values so as to identify the TTL ranges for the attack traffic to then mitigate (e.g., block/drop) traffic which is outside expected values. It is to be appreciated that if the expected values are not known, there will however be present in many scenarios large additional spikes in the TTL distribution which can then be used for more detailed analysis, or if the TTL ranges for the customer base are known, it can be used to mitigate suspected attack traffic matching these unexpected spikes. 
     Next, at step  204 , the mitigation device  102  generates all possible value combinations of the plurality of fields. In other words, according to an embodiment of the present invention, at step  204 , the mitigation device  102  calculates all combinations of all fields extracted from the header portion of each received packet using a statistical function C (n, r). All possible combinations are generated beginning with individual packet header fields and continuing up to the max number of packet header fields (where n=5 and r=1, 2, 3, 4 and 5). More specifically, continuing with the example above, for the first packet in Table 1, the mitigation device  102  calculates all possible combinations: C(5,1)+C(5,2)+C(5,3)+C(5,4)+C(5,5). In this case the statistical function (5,1) would produce 5 singleton combinations—{1.2.3.4}, {1234}, {10.2.55.87}, {80}, {120}; statistical function (5,2) would produce 10 pair combinations {1.2.3.4, 1234}, {1.2.3.4, 10.2.55.87}, {1.2.3.4, 80}, {1.2.3.4, 120}, {1234, 10.2.55.87}, {1234, 80}, {1234, 120}, {10.2.55.87, 80}, {10.2.55.87, 120} and {80,120}; statistical function (5,3) would produce 10 triple field combinations—{1.2.3.4, 1234, 10.2.55.87}, {1.2.3.4, 1234, 80}, {1.2.3.4, 1234, 120}, {1.2.3.4, 10.2.55.87, 80}, {1.2.3.4, 10.2.55.87, 120}, {1.2.3.4, 80, 120}, {1234, 10.2.55.87, 80}, {1234, 10.2.55.87, 120},{1234, 80, 120},{10.2.55.87, 80,120}; statistical function (5,4) would produce 5 quadruple field combinations—{1.2.3.4, 1234, 10.2.55.87, 80},{1.2.3.4, 1234, 10.2.55.87, 120},{1.2.3.4, 1234, 80, 120},{1.2.3.4, 10.2.55.87, 80, 120}, {1234, 10.2.55.87, 80, 120} and statistical function (5,5) would produce one combination containing all header fields—{1.2.3.4, 1234, 10.2.55.87, 80,120}. Thus, just for the first packet alone the mitigation device  102  generate 31 combinations (5+10+10+5+1) of all possible field values, where only five fields are being analyzed. 
     Next, at step  206 , and as part of a TTL analysis, counters are incremented for observed TTL values preferably by matching packet combinations. And then as part of a packet length analysis, the packet length is retrieved so as to calculate incremental standard deviation sums and values for an average packet length (step  208 ). Next, at step  210 , the timestamps are retrieved so as to update a first-seen timestamp combination and an inter-packet delay is calculated preferably utilizing a last stored timestamp and the current timestamp for the combination so as to calculate incremental standard deviation sums and values. The last-seen timestamp is also then preferably updated. Next, the mitigation device  102  stores each generated combination in a dedicated results table as a separate entry. It should be noted that each entry in the results table may have one or more counters associated therewith. According to an embodiment of the present invention, as part of the results storing operation, at step  211  the mitigation device  102  determines if any of the newly generated combinations already exists in the results table. In response to determining that a newly generated combination does not already exist (decision block  206 , “No” branch), the mitigation device  102  stores such combination in the results table (step  212 ). 
     Returning to step  211 , if the newly generated combination already exists in the results table (decision block  211 , “Yes” branch), the mitigation device  102  then increments the counter associated with that particular entry, step  214 . Continuing with the example above, once the mitigation device  102  generates all 31 combinations corresponding to first packet of the exemplary snapshot, it uses the same statistical approach to generate all possible field value combinations for the second data packet. For example, calculating C (5, 2) function for the second data packet would yield the following combinations: {4.5.6.7, 54321}, {4.5.6.7, 10.2.55.87}, {4.5.6.7, 80}, {4.5.6.7, 55}, {54321, 10.2.55.87}, {54321, 80}, {54321, 55}, {10.2.55.87, 80}, {10.2.55.87, 55}, {80, 55}. However, the combination {10.2.55.87, 80} has been already generated for the first packet. In this case, instead of storing this particular combination in the results table for a second time, the mitigation device  102  increments the counter associated with the results table entry for {10.2.55.87, 80} (step  210 ). In other words, calculation of the C (5, 2) function for the second packet generates 10 combinations, 9 of which are new and unique and are stored in the results table as separate entries (step  208 ), but since the entry for the combination {10.2.55.87, 80} already exists in the result table, the mitigation device  102  increments the counter associated with that particular entry. 
     At step  216 , the mitigation device  102  determines if all incoming subset of data has been processed. For example, step  216  may include determining if additional data packets have not been processed. If all incoming data received in step  202  has not been processed (decision block  211 , “No” branch), the mitigation device  102  may repeat processing steps  204 - 211  for the next portion of packets until all data packets received in step  202  have been processed. Processing of all received packets results in a table such that the table contains all possible unique packet header field combinations for all received packets as separate entries. Furthermore, each entry in the table is associated with a counter. A value of the counter is incremented by the mitigation device  102  for every occurrence of the stored combination in the generated plurality of value combinations. 
     According to an embodiment of the present invention, at step  218 , in response to determining that the entire subset was processed (decision block  216 , “Yes” branch), the mitigation device  102  may sort the results stored in the table. In one embodiment, the mitigation device  102  may sort the results by number of packet header fields in each combination and by number of occurrences for each combination. It should be noted that the table entries having the greatest number of packet header fields and matches (counter values) represent data patterns that occur most frequently in the analyzed portion of data (such as the snapshot shown in Table 1 above). These patterns in the collected data are most likely to be representative of suspicious traffic. Accordingly, at step  220  the mitigation device  102  may identify table entries having the highest counter values. Still continuing with the example above, if the mitigation device  102  sorts all generated combinations for the ten packets shown in Table 1 and the sorting is performed on the number of fields per combination and the counter value associated with each combination, the two following entries would be at the top of the sorted list:
     {1.2.3.4, 1234, 10.2.55.87, 80}—3 matches   {10.2.55.87, 80, 55}—5 matches
 
Since, at least in some implementations, the results table may include all possible combinations generated based on the information contained in thousands of packets, in this step the mitigation device  102  may identify entries with the highest counter values that exceed a predetermined threshold to avoid false positives. In one embodiment this predetermined threshold may comprise, for example, 10 percent of all analyzed packets.
   

     Next, at step  222 , the mitigation device  102  may analyze the content of the identified entries. The first identified entry having 3 matches would be considered legitimate by the mitigation device  102  as this entry contains some constant information, such as a constant source IP address (1.2.3.4) and source port number (1234) and yet packet length is not constant. The second identified entry having 5 matches would be considered to be malicious by the mitigation device  102  as this entry&#39;s source IP address and source port number information is not constant, while the packet length is constant. In alternative embodiments, the mitigation device  102  may include logic configured to analyze packet payload information to detect potential malicious application specific attacks. 
     Next, at step  224 , the mitigation device  102  calculates the TTL distribution for each combination, preferably using a using a range finder algorithm (e.g., Jenks Natural Breaks), in conjunction with a TTL analysis. At step  226 , the average packet length/standard deviation is then calculated for each combination, in conjunction with a packet length analysis. At step  228 , the average inter-packet length/standard deviation is then calculated for each combination, in conjunction with an inter-packet delay analysis. Then at step  230 , the packet per second rates for each combination is calculated using timestamps representing first seen/last seen. And at step  232 , the distribution and frequency of source and destination IP addresses is analyzed by mitigation device  102  to detect clusters of IP addresses. As discussed herein, this may be used to detect if an attack exhibits carpet bombing characteristics. As known to one skilled in the art, network carpet bombing describes DDoS attacks that target a range of addresses or subnets, which can contain hundreds or even thousands of destination IP addresses. Carpet bombing can impact a service provider&#39;s ability to deliver service (either generally or to a specific customer). It can also be used to obfuscate the individual target, thus increasing the difficulty of mitigation. 
     In accordance with the illustrated embodiments, it is to be appreciated that after the above described the statistical analysis process is completed, an Attack Vector matching process may be performed by the mitigation device  102  (as described in U.S. patent application Ser. No. 17/017,379, which is incorporated by reference), whereby the calculated Metadata may be extracted for each combination directly (average packet length, inter-packet timing) or stored values (e.g., TTL) may be used to generate a TTL distribution using a range finder algorithm (e.g., Jenks Natural Breaks). It is to be additionally appreciated that carpet bombing attacks may be detected by analyzing the source and destination IP addresses in the PCAP, as described below. 
     According to an embodiment of the present invention, at step  234 , the mitigation device  102  may present results of the performed attack mitigation analysis to a user by utilizing a user interface. 
     In accordance with the illustrated embodiments, and utilizing the above process of  FIG.  2   , now described is an algorithm for detecting Carpet Bombing attacks. In a first step, after the statistical analysis process performed by the mitigation device  102  has been completed whereby Attack Vectors have been classified (e.g., as described in U.S. patent application Ser. No. 17/017,379), the combinations which match each detected Attack Vector are then analyzed a second time to extract the destination IP addresses. This provides a list of the destination IP addresses which exceed a configurable threshold (e.g., default 1%) of the attack traffic in a specific Attack Vector. In a second step, these destination IP addresses are then analyzed to determine if they match a specific Classless Inter-Domain Routing (CIDR) block (e.g., going from a /24 down to a /16). If the number of IP addresses matched are greater than a configurable threshold (default 5), the Attack Vector is reclassified as a “Carpet Bombing” Attack Vector whereby the recommended countermeasures are updated if necessary. In a third step, steps 1 and 2 may be repeated focusing on the source IP addresses. For instance, if there is a match, the attacker is attempting to use the resources under protection as unwilling participants in an outbound Carpet Bombing attack against some other target. This will result in the attack vector being reclassified accordingly and the recommended countermeasures are updated as required. 
     In accordance with additional illustrated embodiments, described now is a technique preferably performed by mitigation device  102  for providing CIDR block classification. In accordance with this technique, for each IP address with attack traffic exceeding a threshold of network traffic, a CIDR network block is generated that matches the IP address from sizes /16 up to /24. The current CIDR network block is then added to a list of candidate CIDR blocks for the specific IP address, to calculate the start and end of the CIDR block. For each IP address with attack traffic exceeding a threshold of network traffic, a determination is made as to whether the IP address is within the start/end of the calculated network block. If yes, a counter is incremented for the current CIDR block. And for each CIDR block candidate from size /24 down to /16, a determination is made as to whether the match counter exceeds a threshold. If yes, a stop is made for matching CIDR blocks with repetition of the above procedure for the next IP address having attack traffic exceeding a threshold of network traffic. This preferably provides a list of CIDR blocks matching at least 5 IP addresses detected in the Attack Vector where the most specific matches are preferred (a /24 match is preferred to a /16). 
     Referring now to  FIG.  4   , illustrated is an exemplary screenshot of a graphical user interface (GUI) displaying attack detection results, according to one or more embodiments discussed herein. The GUI provides a window  400  for navigating the various PCAP files or some other types of log files stored or loaded into the memory of the mitigation device  102 . The GUI further displays a file menu  402  for accessing the various files. In this exemplary embodiment, the GUI may also display file information  404 , fields information  406  and analysis results information  408 . The file information section  404  may provide information related to a number and one or more types of captured packets (e.g., TCP packets, UDP packets, ICMP packets) contained within the analyzed file. The fields information section  406  may provide information related to all fields within each captured packet that have been analyzed by the mitigation device  102 . According to an embodiment of the present invention, users may also have an ability to adjust threshold values  410  utilized in detecting malicious traffic by the mitigation device  102 . The analysis results section  408  may be used to display information associated with the entries identified as potentially suspicious traffic by the mitigation device  102  in step  214 . It should be noted that the counter values  412  associated with each entry may be presented in a sorted order from highest to lowest value. 
     Referring back to  FIG.  2   , optionally, at step  236 , the mitigation device  102  may automatically implement one or more attack mitigation measures based on the results of the performed analysis. For instance, continuing with the example above, the mitigation device  102  may automatically generate a packet filter which would drop all packets having the destination IP address=10.2.55.87, destination port number=80 and packet length=55. Further, the mitigation device  102  can initiate specific mitigation policies localized to a particular application. 
     With reference now to  FIG.  3   , illustrated is an exemplary and non-limiting block diagram of the attack mitigation device  102  constructed according to an illustrated embodiment. The attack mitigation device  102  is communicatively coupled to the protected network  100  and to the database  330  (i.e., storage medium  116  storing results tables  118  and/or storing network traffic flow information), as shown in  FIG.  3   , and is at least configured to execute the method for mitigating network attacks as described in greater detail above. The attack mitigation device  102  preferably includes a processor  310  coupled to a memory  315  and a network-interface module  320 . The network-interface module  320  allows the communication with the protected network  100 . The processor  310  uses instructions stored in the memory  315  to execute attack detection tasks as well as to control and enable the operation of the network-interface module  320 . 
     In summary, various embodiments of the present invention disclose a novel approach to detecting data patterns by employing a combination of different analysis procedures/algorithms (e.g., content analysis and statistical analysis). In one embodiment, this approach takes a different perspective on how to provide an effective response to a DoS/DDoS type of attack than do conventional approaches. The disclosed approach provides a number of advantages. In one aspect, software programming code embodying the present invention provides an ability to perform analysis either on live or stored network data. In another aspect, the attack mitigation device  102  may use the results of the malware detection analysis to block packets matching detected patterns, either in a manual or automated fashion. As yet another advantage, although the method depicted in  FIG.  2    is described with reference to the IP packet header analysis, it is not limited thereto. The disclosed processing functionality performed by the attack mitigation device  102  may be applicable to packet payload analysis, as well as any other structured data analysis. 
     Most preferably, the various embodiments disclosed herein can be implemented as any combination of hardware, firmware, and software. Moreover, the software is preferably implemented as an application program tangibly embodied on a program storage unit or computer readable medium. The application program may be uploaded to, and executed by, a machine comprising any suitable architecture. Preferably, the machine is implemented on a computer platform having hardware such as one or more central processing units (“CPUs”), a memory, and input/output interfaces. The computer platform may also include an operating system and microinstruction code. The various processes and functions described herein may be either part of the microinstruction code or part of the application program, or any combination thereof, which may be executed by a CPU, whether or not such computer or processor is explicitly shown. In addition, various other peripheral units may be connected to the computer platform such as an additional data storage unit and a printing unit. Furthermore, a non-transitory computer readable medium is any computer readable medium except for a transitory propagating signal. 
     The flowchart and block diagrams in the Figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various embodiments of the present invention. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware-based systems that perform the specified functions or acts, or combinations of special purpose hardware and computer instructions. 
     The descriptions of the various embodiments of the present invention have been presented for purposes of illustration, but are not intended to be exhaustive or limited to the embodiments disclosed. Many modifications and variations will be apparent to those of ordinary skill in the art without departing from the scope and spirit of the described embodiments. The terminology used herein was chosen to best explain the principles of the embodiments, the practical application or technical improvement over technologies found in the marketplace, or to enable others of ordinary skill in the art to understand the embodiments disclosed herein.