WO2004070547A2 - Method and device for monitoring data traffic and preventing unauthorized access to a network - Google Patents

Abstract

A method of protecting a network from potentially harmful data traffic comprised of data packets traversing data ports of the network is disclosed. The method provides a means for monitoring attributes of data traffic across data ports of a network. The improved Traffic Limiting Intrusion Detection System (TLIDS) incorporates procedures for defining areas that characterize network traffic, to monitor and analyze data packets associated only within the defined area. Policies (referred to as 'policies') are defined in association with a defined area, to monitor and analyze the data packets or traffic along the network. Policies may also include triggers which, when tripped, generate predetermined responses to limit or otherwise manage traffic on the network. One or more sets of policies can be associated with a defined area, and multiple areas may be defined, each having its own associated policy or policies. Similarly, one or more responses may be triggered by each policy.

Description

METHOD AND DEVICE FOR MONITORING DATA TRAFFIC AND PREVENTING UNAUTHORIZED ACCESS TO A NETWORK

RELATED APPLICATIONS

[0001] This patent application claims the benefit of provisional patent applications (U.S.), Ser. No. 60/ 444,488 and Ser. No. 60/444,571, both filed February 3, 2003. This patent application is a continuation-in-part of U.S. patent application Ser. No. 09/844,794 filed April 27, 2001.

REFERENCE TO COMPUTER PROGRAM LISTING SUBMITTED ON CD

[0002] This application incorporates by reference the computer program listing appendix submitted on (1) CD-ROM entitled "Captus Traffic Limiting Intrusion Detection System Computer Program Listing" in accordance with 37 C.F.R. § 1.52(e). Pursuant to 37 C.F.R. § 1.77(b)(4), the material on said CD-ROM is incorporated by reference herein.

[0003] A portion of the disclosure of this patent document including said computer program listing contains material that is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the Patent and Trademark Office patent file or records, but otherwise reserves all copyright rights whatsoever.

FIELD OF THE INVENTION

[0004] The present invention relates to monitoring data traffic and, more particularly, to identifying specific network data traffic intended to attack data ports and the like, as well as preventing the transmission of such attack data across the data ports.

BACKGROUND OF THE INVENTION

[0005] The increase of data traffic across the Internet, including the growth in the number of users of the Internet, as well as the number of merchants and businesses having a web presence, has resulted in a need to provide individualized management and monitoring of data traffic flow. Merchants and businesses are realizing the increased need to monitor traffic flow, as the number of attacks on the web sites of these merchants and businesses has increased dramatically.

[0006] The number of "hackers" continues to increase, and attacks on web sites are becoming a more common occurrence. Merchants and businesses are particularly concerned with obtrusive attacks on their web pages. In these attacks, "hackers" use all ports of a network system in an attempt to gain unauthorized access. Such attacks include for example denial of service (DoS) attacks (which include Buffer Overflow attacks, SYN attacks, Ping of Death attacks, Teardrop attacks and Smurf attacks) that have potentially serious ramifications. DoS attacks attempt to shut down a network by flooding it with data traffic. These attacks attempt to exploit the limitations in the Transmission Control Protocol/Internet Protocol (TPC/T-P) and deprive the networks of resources and can, in cases of large attacks, force a web site to temporarily cease operation. Such attacks can also destroy programming and files in a computer system. The "hackers" that attack these web sites are not necessarily interested in obtaining confidential information from the web sites, but are interested in shutting down the sites by flooding a particular web page with a large number of "hits," resulting in an overload of the server for the web site of the merchant or business. This results in an interruption in access to the site by consumers and essentially shuts down the web site which, for purely online businesses, is shutting down the entire business. For merchants and businesses that rely on the Internet for a large portion of their sales or for all of their sales, any period of non-operation is extremely costly in both time and money. Other attacks include routing-based attacks and unauthorized access to certain protected services.

[0007] Attempts have been made to develop systems to prevent unauthorized access to or from networks. Most commonly, firewalls are provided to control access to networks and prevent access by unauthorized users. Essentially, these firewalls are configured with a set of predetermined rules, which are usually static, and examine data traffic traversing the firewall to determine whether or not access should be denied, based upon the predetermined rules. Examples of firewalls include packet filters, which look at each packet transmitted to a network to determine whether it should be accepted or rejected based on a set of pre-defined rules; application gateways, which provide security to particular applications such as File Transfer Protocol (FTP) servers; circuit-level gateways, which provide security when certain connections, such as a TCP connection, are established, thereafter allowing data packets to flow between hosts without further checking; and proxy servers, which capture all data packets entering or leaving a network, thereby hiding the true network addresses. These firewalls are typically used in connection with a network policy and other authentication mechanisms that define the set of rules. Also, these firewalls can be implemented by numerous devices, including routers, personal computers or Internet hosts.

[0008] Attacks on a network may occur from an outside source but may also occur from a source within the network. Therefore, firewalls must provide for monitoring of traffic from both sides of the network. Even though networks rely on security methods other than firewalls to protect their systems, these methods do not always effectively protect the networks due to, for example, failure to update monitoring systems or complexity in the networks. This results in networks that are more susceptible to attack. A firewall adds to network protection and provides another line of defense against attacks.

[0009] Although different types of firewalls exist, they are generally provided with static rules that limit the adaptability of the firewall. Also, these firewalls examine each of the actual packets, which reduces data traffic throughput, and generally only examine data traffic in one direction across network ports. Further, the firewalls typically deny access to and from an entire data port when detecting unauthorized data, instead of denying access to or from a single IP address, which results in an unnecessarily broad denial of access.

[0010] In many instances, even authorized users are subject to restrictions. It is necessary to control certain characteristics of authorized user traffic, such as where a user purchases network capacity based on allotted bandwidth, or a user's cost rate is based upon usage during a certain period of the day (off-peak hours or weekends), or some combination of characteristics. Network administrators and operators require the ability to "shape" or restrict traffic when it exceeds the allowable network parameters, even when the network traffic is not related to attacks. In this respect, the need for controlling network capacity is not limited to defending the network against hackers, but to management of authorized user traffic as well.

SUMMARY OF THE INVENTION [0011] A method is disclosed for protecting a network from potentially harmful data traffic traversing a plurality of data ports of the network, the data traffic comprising data packets. The TLIDS method comprises providing a means for monitoring attributes of data traffic traversing a plurality of data ports of a network, and means for responding when an attack on said network is determined to occur. Also, a set of attack parameters is defined from attributes of one or more data packets traversing a network, such that when said defined set of parameters are met an attack on said network is presumed to occur. A set of responses are specified that may be taken in response to an attack, the responses being defined by a set of response policies. Response policies are designed to select one or more responses from the set of specified responses based upon monitored attack parameters. All the data packets traversing the data ports are monitored with said monitoring means to determine when the attack parameters have been met.

[0012] Attack parameters and said response policies are compared and coordinated to select one or more of the set of specified responses based upon said monitored attack parameters. One or more selected responses are provided through the response providing means to protect said network from said attack.

[0013] The disclosed method is implemented by a plurality of independently executing threads, including a first thread for initializing data structures and activating all system threads; a second thread for processing all packet headers, updating threshold conditions, and initiating responses; a third thread for removing response commands when threshold conditions cease to be satisfied; fourth thread for initiating and updating configurations and terminating processes; and a fifth thread for collecting statistics associated with one or more Radix trees and transmitting said statistics to processes external to said method upon request.

[0014] The method also comprises an optional flow cache for storing packet header data. A policy lookup device is associated with the second (packet handling) thread for accessing the cache to determine whether an incoming packet matches one of the stored packet header data flows, and if a data flow is matched in the cache, accessing an external node of said Radix trees from a pointer associated with the matching stored packet header data flow.

[0015] The method also comprises storing packet header data in an array defined in kernel memory and sharing the header data by accessing the array from user memory, and reading packet header data, and marking said packet header data as it is read. Data in the shared kernel memory defined array is aged out and replaced by new packet header data. [0016] The method also includes evaluating the threshold conditions by using a virtual machine byte-code interpreter. Threshold evaluation is accomplished by indicating the data that is to be collected from packet header processing; and indicating if collected data exceeds predefined threshold conditions. The byte-code comprises a predefined set of instructions.

[0017] In one aspect of the disclosed method, packet headers include a virtual network (NLAN) indentifier. NLAN support comprises using a table indexed by NLAN that associates a NLAN tag to the policy Radix tree.

[0018] In general, in another aspect, a computer program product, disposed on a computer readable medium, includes instructions for causing a processor to receive network packets headers handled by a network entity and to analyze the packet headers according to a predetermined set of area and protocol Radix trees in order to configure and implement network traffic policies through a network bridge device.

[0019] It is an object of the present invention to provide a traffic limiting- intrusion detection system with the capability of monitoring specified data traffic by area addresses and protocols for implementing one or more network policies.

[0020] It is another object of the invention to provide a method of traversing a Radix tree to determine policies applicable to data traffic, and further, to provide a means by which the system may bypass the steps of traversing the Radix when packets match existing packets stored in a flow cache.

[0021] It is yet another object of the present invention to provide a shared memory buffer in kernel space, directly accessible by the TLIDS computer application in user memory to avoid the need for copying all incoming packets into user defined memory storage.

[0022] Another advantage of the present invention is the ability to define the scope of the policy, such that a policy associated with a defined area may trigger responses that expand the scope of the policy beyond the associated area, to block traffic in other areas, or to block all network traffic, simply by defining the match policy.

[0023] A further object of the present invention is to provide virtual machine code instructions for evaluating trigger threshold conditions.

[0024] Yet another object of the present invention is to provide monitoring of data traffic for virtual network addresses, or NLAN's. DESCRIPTION OF THE DRAWINGS

Fig. 1 is a chart showing the thread relationships; and

Fig. 2 is a chart showing the expanded Radix tree associations.

Fig. 3 is a flow diagram for the packet flow cache and policy match routine;

Fig. 4 is a diagraϊn of the kernel and user mode ADS table in shared kernel memory;

Fig. 5 is a diagram of a Radix tree configuration for a single area with multiple policies associated with the area;

Fig. 6 is a diagram of a Radix tree configuration for multiple areas with multiple policies associated with each area;

Fig. 7 is an enlarged view of a leaf structure representing a node in the Radix tree of Fig. 6; and

Fig. 8 is a diagram of a NLAN configuration for multiple NLAN's and multiple policies.

DETAILED DESCRIPTION THE INVENTION

[0025] In the Traffic Limiting Intrusion Detection System (TLIDS) developed by Captus Networks, Inc., and described in United States patent application serial number 09/844,794, it was recognized that certain protocols, e.g., File Transfer Protocols (FTP), result in high traffic flow over a port, while others (e.g. DNS) generate a much lower traffic flow over a port. Providing an analysis of the protocol in combination with an improved system of rules to be implemented as selected from a rule making decisional tree would provide greater flexibility in the identification of an attack and in the responses thereto.

[0026] The response disclosed by the Pktd method was primarily directed to denial of access when denial conditions were met, which denial was removed after a lockout period if the transmitting source was no longer transmitting attack data packets. That system was also limited to a single response, primarily, the denial of access when denial conditions were met.

[0027] TLIDS provides responses, in addition to denial, including an "alert" response which entails sending an alert to the system administrator or other supervisory personnel or devices, a "throttling" response which queues packets and sends them out at a controlled rate, and a "redirection" response, wherein the attack from the source is redirected to another destination selected by the system administrator or other supervisory personnel or devices so that the attack can be captured and analyzed as desired or required.

[0028] These responses were made possible in the earlier TLIDS, because it did not simply look at source and destination, determining the number of packets from each source traversing the data ports during a predetermined period of time and denying access to the data ports to data packets from a particular source if the number of packets traversing the ports from that source was greater than a predetermined number during the predetermined period of time. Instead, the earlier version of TLIDS performed an analysis of the protocol used to send the data packets, as certain types of protocols by their nature generate high traffic while others do not. Analyzing traffic flow versus protocol employed provides a more accurate determination and identification of denial of service attacks. Thus, the earlier TLIDS monitored source address, destination address, destination port, source port and protocol, and when parameters are exceeded indicating an attack is in progress in combination with the Radix rules tree, and was able to respond with an alert, denial of service, request for throttling, redirection and combinations thereof in response to the attack. A user specified a singular set of attack parameters and a singular set of responses to be taken when the attack parameters were met. The Radix rules tree was used to coordinate the attack parameters and the response.

[0029] In addition to greater flexibility in response and greater accuracy in identifying the attack, the earlier TLIDS, by analyzing the protocol and other parameters, can deny service not simply based upon source address but upon any combination of these parameters as determined by the rules tree. Thus, a source that is transmitting from one source address both attack with a first protocol and non- attack data packets via a second protocol can be permitted to continue to sending the non-attack data packets as opposed to denying all data packets from that source address. Faster analysis and rule association are permitted using a Radix decisional tree structure.

[0030] In addition to the configuration script described in the Pktd embodiment (e.g., threshold hit values and time intervals) are selected by the system administrator, in the earlier TLIDS, the system administrator selects rules that affect certain data packets based on source address, source port, destination address, destination port, protocol or other parameters. [0031] The earlier TLIDS was preferably suited to a multiple port data router using non-promiscuous mode packet detection, meaning preferably only data packets destined for the particular port's hardware MAC address are captured.

The Enhanced TLIDS

[0032] The method of the present invention, also referred to as the Traffic Limiting Intrusion Detection System (TLIDS), is preferably adapted in a bridge device, rather than a router, and operating in a promiscuous mode, meaning that all packets on the attached Ethernet network segment are monitored. The improved TLIDS incorporates improved procedures for defining areas that characterize network traffic, to monitor and analyze data packets associated only within the defined area (representing a range of IP addresses). Rules (also referred to as "policies") are defined in association with a defined area, to monitor and analyze the data packets or traffic along the network. Policies may also include triggers which, when tripped, generate predetermined responses to limit or otherwise manage traffic on the network.

[0033] The policy can match "any" packets identified in the packet header as being sent from a source network, to "any" (or all) packets identified in the packet header as being sent to a destination network. The "any" command causes traffic from each IP address within the range of a specified network or port address to be monitored and analyzed separately. Also, the policy can match "all" packets identified in the packet header as being sent from a source network, to "any" or "all" packets identified in the packet header as being sent to a destination network. The "all" command causes traffic from all IP addresses within the range of a specified network or port address to be monitored and analyzed as a unit. The "match" policy may be limited to a specific protocol type.

[0034] Another feature of the present invention is the ability to define and restrict policies with respect to an area, or subset, according to IP addresses. By delimiting the data packets by area, it is possible to create multiple policies, and to trigger a variety of policies responsive to said policies. It is possible to further subdivide the policies by protocol, so that only a specified protocol in a designated area will be affected or controlled by a certain policy.

[0035] A policy may optionally specify a first protocol-specific argument, to "match any" or "match all" of a second protocol-specific argument. A list of the relevant arguments is set forth in Table 3 below.

Table 3

[0036] In addition, the policy optionally permits the analysis and monitoring of data packets by identifying flags, corresponding to Transmission Control Protocol (TCP) control flags characteristics which are defined in the packet header. In the disclosed embodiment, valid flag values may include, in any combination, F (fin), S(syn), R (rst), P (psh), A (ack), and U (urg).

[0037] It should be noted that other parameters present in any data packet may be selected for monitoring, and that those parameters specifically identified herein are used by way of example and not by limitation. For example, TCP data packets include other header fields, such as quality-of-service (QOS), type-of-service (TOS), or time-to-live (TTL) to name a few.

[0038] In example 2, network traffic characteristics are defined for Area 1, Policy 1. The characteristics are defined as traffic that is from any IP address in the 192.168.1.0/24 network (the any source-network argument) and using any port within the range 1024-65535 (the protocol-argumentl argument) with both the F(fin) and A(ack) TCP control flags set (the flags argument) to any IP address in the 192.168.1.0/24 network (the to any destination-network argument) using tcp (the protocol argument) and using any port within the range 1-1023 (the protocol- argument2 argument) with both the F (fin) and A (ack) TCP control flags set (the flags argument). Matching traffic will be monitored and analyzed by Area 1, Policy 1.

(Example 2 ) IPS : tlids : area 1 : olicy 1# match any 192 . 168 . 1. 0 /24 to any 192 . 168 .1. 0/24 tcp any 1024 - 65535 any 1 - 1023 flags FA

IPS : tlids : area 1 : policy 1#

[0039] A further feature of the present invention is the ability to set threshold conditions, referred to as triggers, in one or more logical strings. In the present embodiment, up to nine trigger sets may be defined for a policy. One or more triggers may be defined within a trigger set. The triggers are selected from the group defined as follows:

Command Description greater than avpkt average packet size fills rate of acceleration uses port scanning threshold

[0040] The trigger commands specify conditions which, when met (or "tripped"), cause the system to respond to traffic on the network. Trigger sets have a logical "OR" relationship. Each trigger set can include multiple triggers within a trigger set. The triggers within a trigger set have a logical "AND" association.

[0041] For scalability purposes, triggers can be set for varying data units. The data or packet rate may be set as gigabits per second (g/s), kilobits per second (k/s), megabits per second (m/s), or packets per second (p/s). The time period may also be set for hours or minutes for measuring data units per period of time.

Virtual Machine (VM) code

[0042] The dynamic nature of the TLIDS trigger and response functionality requires efficient trigger evaluation. In the present invention, the TLIDS trigger evaluation mechanism is provided using the TLIDS trigger virtual machine (VM) code, as set forth in Table 1 below. The TLIDS trigger VM is implemented as a byte- code interpreter. The bytecode is produced by the configuration thread during the conversion of the TLIDS configuration and is stored as an array in the policy leaf node.

[0043] The first two bytes in the NM code array serve as a bitmask, indicating what data needs to be collected during packet processing. The bitmask is not one of the bytecodes defined in the bytecode table. This bitmask is defined by applying a Boolean OR operation, setting a bit indicating what field in the node needs updating. This bitmask is also used by the bookkeeping thread to update the counters associated with the "> n ΗSf duration" trigger, the "fills" trigger, and the "uses services" trigger.

[0044] The bits and their associated meaning are set forth in Table 1.

Table 1

[0045] The bytecode interpreter has an instruction pointer (IP) register which contains the index of the instruction being evaluated and a single RESULT register that contains the result of the trigger evaluation. Fields contained in the node contain the threshold and current collection counters for each TLIDS trigger. Table 2 sets forth a listing of defined bytecodes and their semantic meaning. This list is not intended to be exhaustive, and it will be understood by those skilled in the art that additional bytecodes may be defined and implemented that are tailored to the desired actions.

Table 2

VMCODE Evaluation

[0046] The TLIDS NM code is used by both the packet processing thread and the bookkeeping thread, which are discussed in greater detail below. Both the packet processing thread and the bookkeeping thread use the stored NM code in the following ways; first, using the first two bytes of the NM code, a decision is made on what node collection data counters need to be updated; and second, the subsequent NM codes drive the evaluation of triggers.

[0047] The NM collection updater performs a logical bit test of each bit in the first two bytes of the NM code array. If the bit is set, TLIDS performs the operations as defined in Table 2.

[0048] The NM trigger evaluator is defined by the following procedure:

[Initialize] RESULT = 0; IP = index of first opcode (skips first two flag bytes)

[Fetch] current_opcode = opcode at IP

[Evaluate] perform steps as defined in TABLE1 updating RESULT [Done?] If NMCODE is NMJRET return RESULT [Increment] Increment IP [Loop] Goto step 2 [Fetch]

[0049] The evaluator loop continues until a NM_RET instruction is executed. During NM code generation, a NM_RET instruction is always placed at the end of the NM code byte array.

[0050] Responses include alert, deny, reroute, throttle, and duration. The alert command sends a notification in response to the specified trigger. The reroute command reroutes traffic in response to a specified trigger. All traffic may be rerouted, or traffic limted by protocol or a specified area may be rerouted. The throttle command limits the rate of traffic in response to a specified trigger, and may be limited by protocol or a specified area. The duration command allows the user to define the amount of time the response will be applied to traffic, after which the response is either switched off, or switched to another response for another period of time. The latter arrangement is referred to as "staging" the responses. A policy may be configured with multiple responses. Although typically not more than 9 response are employed, in the preferred embodiment there are no limits on the number of responses that may be configured.

[0051] When a policy includes multiple responses, TLIDS inserts the first response and waits the specified duration, then inserts the second response (and removes the first response) and waits the specified duration, etc., until the attack stops. After the attack stops, TLIDS now removes the last response, and no other responses will be in place. Additionally, TLIDS permits the user to define multiple actions for a response.

[0052] The following is an illustration of the method implemented on a network:

[0053] The system monitors and analyzes traffic according to defined areas. Network traffic characteristics defined by the user determine which area monitors and analyzes a packet. In the preferred embodiment, a user may define up to 1,024 areas. Each packet is monitored and analyzed by only one area. In example 3, only one area is defined.

IPS:tlids# area 1

IPS :tlids: area 1# match 0.0.0.0/0 <-> 0.0.0.0/0 IPS : tlids : area 1#

EXAMPLE 3

[0054] This match command for the traffic characteristics for Area 1 is as inclusive as possible, meaning all IP addresses (and all packets) are included in Area 1.

[0055] Within an area, traffic is monitored and analyzed based upon policies and additional traffic characteristics defined by the user. In the preferred embodiment, a user may define up to 1,024 policies for an area. In example 3, one policy is defined for Area 1.

[0056] In example 4, the traffic characteristics for Area 1, Policy 1 include any traffic from one specified network using a specified protocol (TCP) and using any port within a specified range of ports to another specified network using TCP and using any port within a specified range of ports. The traffic characteristics for a policy are defined by the match (policy) command. A name for a policy may be defined by the name command.

IPS : tlids : area 1# policy 1

IPS : tlids : area l :policy 1# match any 192.168.1. 0/24 to any 192.168.1.0/24 tcp any 1024-65535 any 1-1023

IPS : tlids : area 1:policy 1# name simple_tcp IPS: lids: area l:policy 1#

EXAMPLE 4

[0057] Policies optionally may include triggers which, when tripped, respond to traffic. Policies may include multiple trigger sets. Trigger sets have a logical OR relationship, i.e., packet analysis would trip only one of the trigger sets defined for a policy. Additionally, each trigger set can include multiple triggers. Multiple triggers within a trigger set have a logical AND relationship, i.e., a packet is tested against each trigger in the trigger set.

[0058] In example 5 ,Trigger 1 defines a rate of acceleration threshold using the fills command. The rate of acceleration threshold recognizes a sudden increase in traffic by measuring a specified amount of traffic (the bucket size keyword and argument) relative to a specified rate at which traffic ages-out each second (the rate keyword and argument). Trigger 1 is tripped when the rate of acceleration threshold is exceeded: IPS: lids :area l:policy 1# trigger 1

IPS: tlids : area l:policy 1: trigger 1# fills data bucket size 100 rate 20 IPS .-tlids: area 1.-policy 1: trigger 1# exit IPS: lids : area l:policy 1#

EXAMPLE 5

[0059] In the configuration of example 5, Trigger 1 has been defined. The next step is to define a response set for Trigger 1.

[0060] If a policy includes one or more triggers, it must also include responses to those triggers. Responses send an alert or automatically insert firewall rules that limit or shape traffic. One or more response sets may be defined for a policy. Each response set can include multiple responses. Multiple responses within a response set have a logical AND relationship, i.e., each response is executed if the trigger for that response set is tripped.

[0061] Multiple responses in a response set are defined one response at a time. Responses include commands for actions to limit or shape traffic (the alert, deny, reroute, and throttle commands). Another response is a duration command, which allows defines the amount of time the response will be applied to traffic.

[0062] In example 6, Response 1 to Trigger 1 is to send an alert (the alert command) and reroute traffic to a specified host (the reroute command) for a specified amount of time (the duration command). The specified traffic keywords in the reroute command mean that traffic to be rerouted must match the source and destination network addresses and the source and destination port addresses defined as traffic characteristics for Policy 1 using the match (policy) command.

IPS .-tlids .-area l.-policy 1# response 1

IPS :tlids :area l:policy 1:response 1# alert

IPS : tlids :area l:policy l:response 1# reroute specified traffic to

192.168.1.30

IPS: lids :area 1:policy 1: response 1# duration 2 m

IPS: tlids : area l:policy 1: response l# exit

IPS: lids :area l:policy 1#

EXAMPLE 6

Multiple trigger sets may optionally be defined.

[0063] Trigger 2 in example 7 defines a port scanning threshold. A port scanning threshold is defined by the uses command. This threshold detects port scanning by measuring a specified number of ports scanned (the number-of-services services argument and keyword) relative to a specified amount of time (the in time- period time-units keyword and arguments). Trigger 2 also may define a rate threshold by using the > command. The rate threshold measures a specified amount of data (the datapacket-rate argument) relative to a specified rate (the rate-units argument). Trigger 2 is tripped when the port scanning and rate thresholds are exceeded.

IPS : lids :area l:policy 1# trigger 2

IPS : tlids : area l:policy 1: trigger 2# uses 5 services in 1 m

IPS : tlids:area l:policy l:trigger 2# > 10 p/s

IPS : tlids :area l:policy l:trigger 2# exit

IPS .-tlids:area 1:policy 1#

EXAMPLE 7

[0064] In example 8, Response 2 corresponding to Trigger 2 is set to deny traffic. The specified traffic keywords in the deny command means that traffic to be rerouted must match the source and destination network addresses and the source and destination port addresses defined as traffic characteristics for Policy 1 using the match (policy) command.

IPS : tlids :area l:policy 1# response 2

IPS : tlids :area l:policy l:response 2# deny specified traffic

IPS : tlids: area 1:policy 1: response 2# exit

IPS : tlids : area l:policy 1# exit

IPS: tlids:area 1# exit

IPS:tlids# exit

IPS :configure# exit

IPS :main#

EXAMPLE 8

Multi-Thread Design

[0065] The monitoring system of the present invention is preferably provided in a multi-threaded design. This allows each thread to execute independently of the other threads, thereby increasing performance. Preferably, each thread shares the same data space with the other threads, resulting in simplified inter-process communication. Critical data structure (e.g., packet information to analyze to determine if the packets exceed user defined parameters) is protected using semaphores, which also facilitate coordination and synchronization of the multithreaded processes.

[0066] In the most preferred embodiment, five threads handle the various functions of the monitoring system 50. Specifically, the following threads are preferably provided: (1) Configuration Thread: initializes IDS data structures, activates the other threads and waits for the other threads to complete their processes; (2) Packet Capture Thread: processes each packet, updates trigger conditions, and starts a response; (3) Bookkeeper Thread: runs each second, and stops responses if trigger conditions are no longer satisfied; (4) Signal Thread: re-reads configuration file and handles IDS process cleanup and termination and (5) Status thread sends statistics to other processes if requested. It is noted that an incremental configuration thread could be added, for example, to adjust the Radix trees in real time.

[0067] The packet capture thread 14 and the bookkeeper thread effect firewall rules and traffic control commands which are constructed based on the information contained in both the node and the actions being performed.

[0068] Referring to Figs. 1 & 2, a chart depicts the operation of TLIDS 100. packet capture thread 114 handles incoming packet 112. The incoming packets 112 are preferably captured for inspection by an interface, for example, by using available libpcap libraries, or, in the preferred embodiment, a kernel module. The kernel module buffers a configurable number of headers, then sends this buffer to the packet capture thread 114 for processing. The signal thread 118 primarily functions to awaken the bookkeeper thread 120 once per second. The signal function thread 118 uses setitimer to deliver itself a SIGALRM once per second. Upon receipt, a counter is incremented and the signal thread 118 determines if the bookkeeper thread 120 is running (meaning it has not completed the previous iteration's run). In this case, it simply waits for the next signal to arrive. This way, the next time the bookkeeper thread 120 is awakened, it is told to use a time argument higher than 1 when updating the rules tree thread 126. Using this scheme, clock drift should not occur for more than a few seconds at a time and only under extreme loads. This provides a means to ensure that if an action is specified to last for a certain time period, it does not last for a significantly longer amount of time. The signal thread 118 also handles miscellaneous signals such as SIGNAL ("SIGINT"). The SIGINT (interrupt) signal is used as described above. The SIGHUP (hangup) signal is used to restart the service. This usage is consistent with current common practices.

[0069] Both the bookkeeper thread 120 and the packet capture thread 114 access the areas Radix tree, and then the rules tree 126 to match their statistics to applicable policies. If a policy associated with either the packet capture thread 114 matches a condition that triggers a response, the packet capture thread 114 sends a response to the firewall or traffic control command 124. The bookkeeper thread 120 detects when the trigger for a response is no longer applicable, and sends a stop signal to the firewall or traffic control command 124 to cancel the response.

[0070] Also shown in Fig. 1 is a status thread 128 that stores statistical information related to the network traffic, and sends it to other processes when requested. A configuration or main thread 122, initializes IDS data structures, activates the other threads and waits for the other threads to complete their processes provides network configuration information to the rules tree 126.

[0071] Referring next to Fig. 2, a second chart depicts the operation of TLIDS Radix trees including area rules. Packet capture thread 204 handles incoming packet 200. The rules Radix tree is now extended (as explained in more detail below), by associating a Radix tree for each area and configured protocol. Each node in the area Radix tree points to an array of unique, per-protocol Radix trees, in effect creating a tree of trees. An area Radix tree 208 accesses the per-protocol pointers 234 to rules Radix trees 236-240. Pointers 234 then associate the rules trees according to the appropriate protocol identified in the packet header. The protocols include ICMP 236, TCP 238, and UDP 240. The list of network protocols is too numerous to list here, and those identified are shown by way of example and not by limitation, so that any existing or even newly created protocol is readily adapted to the present invention. The bookkeeper thread 224 also accesses the per-protocol Radix rules 236- 240 through the area Radix tree 208.

[0072] Rules contained in the leaves of a Radix tree are constructed from the values of the rule's source and destination addresses. The nodes of this tree simply have two 32-bit quantities (for the Radix comparisons), pointers to the node's left and right descendants (if any), or a pointer to a leaf structure if there are no descendants. The leaf structure contains a mutex so that the packet and bookkeeper threads cannot access the leaf simultaneously. Rules may have the same source and destination addresses with different netmasks so the leaf contains a linked list of rules. The rules are stored in data structures which, unfortunately, are presently called nodes for historical reasons (the tree was once constructed from these). These "nodes" contain all of the information a rule conveys: source and destination addresses and masks, protocol, maximum rate, port ranges, etc. There is also an array of linked lists of actions (more on the action structure later). If any "anys" have been specified in the rule, a hash is used to track the various connections. This hash is an adaptive hash; that is the number of "buckets" it uses grows if the number of connections it is tracking becomes larger than a certain threshold.

[0073] The packet capture thread 204 and the bookkeeper thread 224 both reach the Rules Radix tree 232 via the areas Radix tree 208, as indicated by arrows 206 and 226, respectively. The packet capture thread 206 finds the area node whose network specification best matches the packet being processed; then based on the packet's protocol and per-protocol pointers 234, finds the appropriate Rules Radix tree 236-240. Every second, the bookkeeper thread 224 updates nodes in the area Radix tree 208 (also referred to as "walking the tree") and the per-protocol rules Radix tree 236, 238 and 240.

[0074] Upon request, the statistics (or status) 128 thread reads information from each node of the areas tree 232 and, in turn, each node in every per-protocol rules Radix tree 236-240. The configuration thread 122 adds, updates, deletes, and rebalances trees, as necessary, based on the configuration request. A thread reaches an appropriate area Radix tree 232 node that, via the per-protocol pointers 234, points to the appropriate Rules tree 236-240. Also upon request, the status 128 thread reads information from each node of the Areas tree 208 and, in turn, each node in every per- protocol Rules Radix tree 236-240. The Configuration thread 122 adds, updates, deletes, and rebalances trees, as necessary, based on the configuration request.

[0075] A rule is not limited to a single response, as discussed above. A rule may have a response which varies over time. That is, if a response is activated according to a rule, that response may be changed to a different response, if the trigger(s) are still met, and TLIDS determines that the triggers have been met for a predetermined period of time.

[0076] A sample TLIDS configuration is set forth below, illustrating the definitions of binding, area, policy, response and trigger, and associated commands.

IPS -.main# show tlids tlids

(A) bind em2 , em3

(B) area 1

(C) match 0.0.0.0/0 <-> 0.0.0.0/0

(D) policy 1

(E) match any 192.168.1.0/24 to any 192.168.1.0/24 tcp any 1024-65535 any 1-1023

(F) name simple_tcp

(G) trigger 1 fills data bucket size 100 rate 20 exit

(H) trigger 2 uses 5 services in 1 s > 10 p/s exit (G) response 1 alert reroute specified traffic to 192.168.1.30 duration 2 m exit (H) response 2 deny specified traffic exit exit exit exit IPS:tnain#

Where the letters in parentheses indicate the following:

A= bind definition

B= area definition

C = area network traffic characteristics definition

D = policy definition

E = policy network traffic characteristics definition

F = policy name definition

G = policy trigger and response definition (set 1 )

H = policy trigger and response definition (set 2)

[0077] "Packets" generally refers to Layer-3 (e.g., IP) datagrams. Frames refer to Layer-2 (e.g., Ethernet) datagrams. A router passes packets. A bridge passes frames. Frames contain other addressing information, for example, NLAN identification that TLIDS also has the capacity to examine. Thus, moving the application from a router to a bridge allows the present invention to also examine frame headers, as well as packet headers. It is therefore within the scope of the appended claims to process frames the same as packets for purposes of monitoring and responding to data traffic. The Layer-2 monitoring enhances the TLIDS capability by permitting monitoring of packets within packets, such as a header associated with a NLAN or a partition of a network. The policies are thus "encapsulated" in relation to a specified subset or partition of the network.

[0078] Another feature of the present invention is the ability to define the scope of the policy. That is, if a policy is associated with a defined area, it may trigger responses that expand the scope of the policy beyond the associated area, to block traffic in other areas, or to block all network traffic, simply by defining the match policy. [0079] Policies may be configured dynamically as a function of time. For example, during peak business hours, certain areas or types of traffic may be restricted or prohibited, under a defined policy. When the time parameter is no longer applicable, i.e., after business hours, a different policy is substituted.

The Packet Flow Cache

[0080] A packet flow cache 300 as shown in Fig. 3 is created in the TLIDS packet handling thread. The packet flow cache 300 facilitates searching for TLIDS rules that match packet header data. When an incoming packet is received a policy lookup 302 accesses the packet flow cache 300, as indicated by arrow 304. If a flow matching the packet header information is found already within the packet flow cache 300, the Radix tree root 306 and interior nodes 308, 310 are bypassed. The hash table entry in the packet flow cache 300 will point directly at a list of Radix tree exterior nodes 312, 314 and 316 that match the flow. If, however, there is no matching packet header information found in the packet flow cache, a Radix tree search beginning at the Radix tree root or area rules tree is performed. If the flow is found in the Radix tree, a new flow table entry will be added to the packet flow cache, with the results of the Radix tree search. In this way, a complete traversal of the Radix tree is only performed for new flows that are not present in the packet flow cache, while those packet headers matching existing flows in the packet flow cache bypass directly to the Radix tree exterior node records.

[0081] The packet flow cache is configured as a separate table for each NLAN. Entries are found by hashing the source and destination IP addresses of the packet header tap record and looking them up in a standard hash table. Hash collisions are handled using a linked list overflow method. The packet flow cache is only a short circuit to the existing Radix tree nodes. Port and flag matches begin "walking the tree" from the Radix tree root 306, according to the area rules search mechanism.

[0082] Also, the Radix tree data structure includes a chain of enclosing rules determined by the rules IP address. For example, the CIDR address 10.24.0.0/16 "encloses" the CIDR address 10.24.1.0/24. The enclosing rules facilitate the rule that a packet header matches all possible rules.

The central data structure for the packet flow cache is the flow entry.

Flow_key.saddr and flow_key.daddr variables are used to compute the hash value used in table lookup. One embodiment of the flow entry is as follows: typedef struct flo _key Flow_key;

Flow_key { u int32_t saddr,- u int32_t daddr ,- u_intl6_t pal; u_intl6_t pa2 ; u int8_t proto ; u intlδ t vlanid;

Each populated hash table entry will point to a flow_list. One embodiment of a flow list is as follows: typedef struct flow_list Flow_list ;

Flow_list {

Flow_key key;

Flow_list* nextHas ; // collision chain

Flow_list* next ; // next oldest flow

Flow_list* previous ; // points to next younger flow

Rtree* policy; // rules for this flow

};

The hash table proper, and the associated hash table bookkeeping variables are kept in a table. One embodiment of the flow table is as follows: typedef struct flow_table Flow_table ;

Flow_table {

Flow_list* newest; // newest flow

Flow_list* oldest; // oldest flow

Flow_list* freelist; // free list

Flow_list* table [TABLE_SIZE] ,- // the table proper

The Kernel Tap

[0083] Referring next to Fig. 4, the current ADS device driver, /dev/ads, assigns a region (preferably about 64MB) of kernel memory 410 when the device is opened. When the block of memory is defined, the necessary data structures to maintain a circular array 412 of ADS tap entries are initialized. Only one process at a time may access the ADS tap. The memory assigned when the device opens is preferably provided to the TLIDS user process 414 by a system call. This method of sharing kernel memory facilitates very fast data flow from the kernel to TLIDS, as it is not necessary to copy packets from the ADS tap to user memory outside of the kernel.

[0084] A network interface 416 transmits all incoming packets to a packet classifier module 418, which passes packet headers to the ADS table circular array 412. Packets are then passed from packet classifier module 418 to Ethernet demux 420 for forwarding to a network firewall (not shown).

[0085] In order to synchronize access to the circular array between the kernel and TLIDS, the kernel first checks if the data at the "end" of the array has been read by TLIDS before it adds flow data to the array. Synchronization is discussed in greater detail below. If TLIDS has read the data, the array entry is then updated and marked that unread kernel data is available. If there is no space for this entry, a "dropped ADS tap" counter is updated to reflect lost data. The kernel also determines if TLIDS is waiting for ADS tap data to be available. If TLIDS indicates that it is waiting, a wakeup signal notifies TLIDS to resume.

[0086] In the user memory, TLIDS reads the head of the circular array to determine if unread kernel data is available. If data is available, TLIDS copies the data to a local buffer, then updates the array entry and process the new data. The data is matched to TLIDS rales and firewall rules are inserted if appropriate. If there is no unread data available in the circular array, TLIDS signals the kernel that it is waiting to read new data from the ADS tap. When TLIDS exits or calls close and the file reference count has reached zero, the kernel un-maps the shared memory region to prevent the next instance of TLIDS from processing stale data.

[0087] An additional shared kernel/user memory buffer may be created for use by TLIDS firewall entries. This buffer behaves substantially as described above, but provides data flow in the opposite direction, i.e., from user to kernel space. These entries are only used to add "TLIDS" firewall rules.

[0088] The TLIDS ADS tap data structure includes the kernel/user synchronization byte, as mentioned above. This byte contains the value 1 when there is unread kernel data available, and the value 0 when the TLIDS user process has read the entry. One embodiment of the data structure for ADSent is as follows: struct ADSENT { u_intl6_t ifidx; u_int32_t saddr; u_int32_t daddr; u_intl6_t len; u_intl6_t pal; u_intl6_t pa2; u_intl6_t vlanid; u_int8_t proto ,- u_int8_t synch;

} ;

[0089] Those having ordinary skill in the art will readily appreciate that the above data structures may be created using different variable definitions and naming conventions, yet still fall within the same structure so as to fall within the spirit and scope of the appended claims.

[0090] Referring next to Fig. 5, there is depicted a graphical representation of one configuration of a Radix tree defining a single area and seven policies. The configured tree is generally designated as 510. An incoming packet header 512 is first tested for a match with a pre-existing data flow in flow cache 514. If the packet header matches an existing data flow, the header data is processed directly to an external node 522 of the rules tree 510, bypassing internal layers of the tree 516-520.

[0091] If no matching flow is presently indicated in flow cache 514, packet header is tested first against an area range 516. Note that in the configuration shown in Fig. 5, only one area is being monitored. Multiple-area configurations may be defined, which will be discussed below. All configurations are shown by way of example and not by limitation, as the number of configurations are determined by the system administrator, for monitoring any range of IP addresses, NLAN addresses, protocols and combinations thereof. Ranges of IP addresses may also be configured that overlap more than one set of rules trees.

[0092] In the example of Fig. 5, a CIDR address sets the associated with the source addresses to apply to any packets (CIDR address = 0.0.0.0/0). The CIDR address associated with the destination addresses defines a specific area of destination IP addresses (CIDR address = 1.1.1.0/29). Thus, packet headers matching the specified destination address range advance to the protocol matching layer 518 of the Radix tree 510 as indicated by arrow 542. In the configuration in Fig. 5, (TREEO) is defined for protocol (6), designating the TCP protocol.

[0093] Thus, packet headers that match the area configured in the area range 516 layer and the protocol - TCP - configured in the protocol matching layer 518, are next processed in the policies Radix tree 520 as indicated by area 544. Packet headers are sorted in the policy Radix tree 520 in the first 520a layer into two classifications, as indicated by arrows 546, 548. In the next layer, at trees 520b and c, headers are further sorted into 4 more classifications, as indicated by arrows 550-556. In the third layer of the policy Radix tree 520, rales trees 520d-g further subdivide packet headers into seven classifications and forward the packet headers to the policies layer 522 of the Radix tree 510, as indicated by arrows 558-570. RTREE2572 indicates a case where all packet headers are forwarded directly to a leaf or node of the tree, placing it effectively in the policy layer 522 of the tree 510. Broken lines 574-580 designate the separate layers of Radix tree - area 516, protocol 518, policy Radix tree 520, policies 522 and nodes 524 (also referred to as leafs).

[0094] Path 582 shows the an optional bypassing of the interior layers of the tree when an incoming packet header 512 matches an existing flow. The advantage of the flow cache 514 can be appreciated, as the number of steps for processing a matching packet is reduced to one, to reach the exterior layer 522 of the tree. Only the non-matching packets traverse the interior layers of the tree. Once a packet header successfully traverses the tree, it is identified as a new data flow and added to the flow cache, so that related dated packets will find their way to the external layer via the flow cache. It should be noted that the flow cache 514 is an optimization feature that is optional, and that the method may be implemented without the flow cache.

[0095] The following TLIDS instructions correspond to the Radix tree depicted in Fig. 5: tlids bind dcO, del area 1 match 0.0.0.0/0 -> 1.1.1.0/29 policy 01 match any 0.0.0.0/0 to any 1.1.1.1./32 tcp all

1-65535 all 1-65535 trigger 1 uses 8 services in 60 s exit response 1 duration 1 h deny specified traffic exit exit policy 02 match any 0.0.0.0/0 to any 1.1.1.2./32 tcp all 1-65535 all 1-65535 trigger 1 uses 8 services in 60 s exit response 1 duration 1 h deny specified traffic exit exit policy 03 match any 0.0.0.0/0 to any 1.1.1.3./32 tcp all 1-65535 all 1-65535 trigger 1 uses 8 services in 60 s exit response 1 duration 1 h deny specified traffic exit exit policy 04 match any 0.0.0.0/0 to any 1.1.1.4./32 tcp all 1-65535 all 1-65535 trigger 1 uses 8 services in 60 s exit response 1 duration 1 h deny specified traffic exit exit policy 05 match any 0.0.0.0/0 to any 1.1.1.5./32 tcp all 1-65535 all 1-65535 trigger 1 uses 8 services in 60 s exit response 1 duration 1 h deny specified traffic exit exit policy 06 match any 0.0.0.0/0 to any 1.1.1.6./32 tcp all 1-65535 all 1-65535 trigger 1 uses 8 services in 60 s exit response 1 duration 1 h deny specified traffic exit exit policy 07 match any 0.0.0.0/0 to any 1.1.1.7./32 tcp all 1-65535 all 1-65535 trigger 1 uses 8 services in 60 s exit response 1 duration 1 h deny specified traffic exit exit exit > exit

[0096] In this configuration, TLIDS monitors tcp traffic for the specified areas. A response is triggered if the TLIDS detect the use of eight services over a 60 second interval. The response is to deny all traffic from the source areas for one hour, then re-evaluates the policy conditions.

[0097] Referring next to Fig. 6, a multiple-area configuration including multiple policies, is depicted. In this example configuration, seven areas and seven policies area configures.

[0098] Incoming packets headers (not indicated) are tested against area Radix tree 612 at the first layer of tree 610. Seven areas 612 a-g are defined and matched for forwarding to the protocol 614 tree layer. If the protocol matches the criteria of protocol Radix trees 614 a-g, the associated packet headers are forwarded next to the policy Radix tree 616 layer, and processed by RTREEO - RTREE6616 a-g to the associated policies 618.

[0099] It should be noted that the flow cache may be used for all configurations, so that packet headers matching existing flows would bypass the interior layers of the Radix trees in the example of Fig. 6, as described above.

[00100] The following TLIDS instructions correspond to the Radix tree depicted in Fig 6: tlids bind dcO , del area 1 match 0.0.0.0/0 -> 1.1.1.0/32 policy 01 match any 0.0.0.0/0 to any 1.1.1.1./32 tcp all

1-65535 all 1-65535 trigger 1 uses 8 services in 60 s exit response 1 duration 1 h deny specified traffic exit exit policy 02 match any 0.0.0.0/0 to any 1.1.1.2./32 tcp all 1-65535 all 1-65535 trigger 1 uses 8 services in 60 s exit response 1 duration 1 h deny specified traffic exit exit policy 03 match any 0.0.0.0/0 to any 1.1.1.3./32 tcp all 1-65535 all 1-65535 trigger 1 uses 8 services in 60 s exit response 1 duration 1 h deny specified traffic exit exit policy 04 match any 0.0.0.0/0 to any 1.1.1.4./32 tcp all 1-65535 all 1-65535 trigger 1 uses 8 services in 60 s exit response 1 duration 1 h deny specified traffic exit exit policy 05 match any 0.0.0.0/0 to any 1.1.1.5./32 tcp all 1-65535 all 1-65535 trigger 1 uses 8 services in 60 s exit response 1 duration 1 h deny specified traffic exit exit policy 06 match any 0.0.0.0/0 to any 1.1.1.6./32 tcp all 1-65535 all 1-65535 trigger 1 uses 8 services in 60 s exit response 1 duration l h deny specified traffic exit exit policy 07 match any 0.0.0.0/0 to any 1.1.1.7./32 tcp all 1-65535 all 1-65535 trigger 1 uses 8 services in 60 s exit response 1 duration 1 h deny specified traffic exit exit exit exit

[00101] Fig. 7 corresponds to a node or leaf representing policy 02 in the TLIDS instructions above. The left column 710 of the node 700 includes the area rules and protocol designation for matching source and destination addresses, corresponding to the defined area. Center Column 720 represents the protocol ranges for source and destination, in this instance corresponding to all protocols. The right column 730 represents trigger counters, NM codes and responses as indicated in the policy.

[00102] If NLAΝ tags are present, area Radix tree is bypassed. The tree is traversed beginning at the protocol layer. The flow cache may be used for NLAΝ tags also, to bypass the protocol layer if an existing flow matches a NLAΝ packet.

[00103] A NLAΝ configuration 800 is illustrated in Fig. 8. The configuration defines six NLAΝs 810. The protocol Radix trees 824a thru f are defined in the first layer, and are then associated with a policy Radix tree 820, containing one or more policies 826 a-f, for each NLAΝ and protocol (in this example, only one protocol - tcp - is monitored.) Nodes 828a-f are associated with each policy 826a-f.

The code that is represented by the NLAN configuration 800 depicted in figure is as follows: tlids bind dc0,dcl area 1 vlan 1 policy 01 match any 0.0.0.0/0 to any 1.1.1.1/32 tcp all 1-65535 all 1-

65535 trigger 1 uses 8 services in 60 s exit response 1 duration 1 h deny specified traffic exit exit exit area 2 vlan 2 policy 01 match any 0.0.0.0/0 to any 1.1.1.2/32 tcp all 1-65535 all 1-

65535 trigger 1 uses 8 services in 60 s exit response 1 duration 1 h deny specified traffic exit exit exit area 3 vlan 3 policy 01 match any 0.0.0.0/0 to any 1.1.1.3/32 tcp all 1-65535 all 1-65535 trigger 1 uses 8 services in 60 s exit response 1 duration 1 h deny specified traffic exit exit exit area 4 vlan 4 policy 01 match any 0.0.0.0/0 to any 1.1.1.4/32 tcp all 1-65535 all 1-

65535 trigger 1 uses 8 services in 60 s exit response 1 duration 1 h deny specified traffic exit exit exit area 5 vlan 5 policy 01 match any 0.0.0.0/0 to any 1.1.1.5/32 tcp all 1-65535 all 1-

65535 trigger 1 uses 8 services in 60 s exit response 1 duration 1 h deny specified traffic exit exit exit area 6 vlan 6 policy 01 match any 0.0.0.0/0 to any 1.1.1.6/32 tcp all 1-65535 all 1-

65535 trigger 1 uses 8 services in 60 s exit response 1 duration 1 h deny specified traffic exit exit exit exit

[00104] In an alternate embodiment of the invention, areas and policies may be configured while the system is operating, and implemented by creating, updating or destroying nodes in the appropriate area or rules Radix trees.

[00105] Additional matching commands may include inverted match

(i.e., match all that is not); and match some (rather than any/all). Areas may have their "capacity" defined; policies then make use of this capacity by referring to percentages in the trigger conditions and the "throttle" response command. Thus, a specific number of packets containing a monitored attribute may not indicate an attack, unless that number exceeds a defined percentage of the total data packets that were captured.

[00106] In general, in another aspect, a computer program product, disposed on a computer readable medium, includes instructions for causing a processor to receive network packets headers handled by a network entity and to analyze the packet headers according to a predetermined set of area and protocol Radix trees in order to configure and implement network traffic policies through a network bridge device.

[00107] There are other various changes and modifications which may be made to the particular embodiments of the invention described herein, as recognized by those skilled in the art. However, such changes and modifications of the invention may be constructed without departing from the scope of the invention. Thus, the invention should be limited only by the scope of the claims appended hereto, and their equivalents.

Claims

We claim:

1. A method of protecting a network from potentially harmful data traffic traversing a plurality of data ports of the network, the data traffic comprising data packets, the method comprising the steps of: a. providing a means for monitoring attributes of data traffic traversing a plurality of data ports of a network; b. providing a means for responding when an attack on said network is determined to occur; c. defining a set of attack parameters from attributes of one or more data packets traversing a network, such that when said defined set of parameters are met an attack on said network is presumed to occur; d. specifying a set of responses that may be taken in response to said attack, wherein said responses are defined by a set of response policies, said response policies being designed to select one or more of said responses from said set of specified responses based upon monitored attack parameters; e. monitoring all the data packets traversing the data ports from a plurality of sources with said monitoring means to determine when said attack parameters have been met; f. comparing and coordinating said attack parameters and said response policies to select one or more of said set of specified responses based upon said monitored attack parameters; and g. providing said one or more selected responses through said response providing means to protect said network from said attack; wherein said method being implemented by a plurality of independently executing threads, including

1) a first thread for initializing data structures and activating all system threads;

2) a second thread for processing all packet headers, updating threshold conditions, and initiating responses;

3) a third thread for removing response commands when threshold conditions cease to be satisfied;

4) a fourth thread for initiating and updating configurations and terminating processes; and 5) a fifth thread for collecting statistics associated with one or more Radix trees and transmitting said statistics to processes external to said method upon request.

2. The method as set forth in claim 1, wherein said method also comprising a cache for storing packet header data, a policy lookup device associated with said second thread for accessing said cache to determine whether an incoming packet matches one of said stored packet header data, and accessing an external node of said Radix trees from a pointer associated with said matching stored packet header data.

3. The method as set forth in claim 2, wherein said method also comprises storing packet header data in an array defined in kernel memory, accessing said array from user memory, reading packet header data, and marking said packet header data as it is read.

4. The method as set forth in claim 3, also comprising aging out the oldest packet header data in said array and replacing said packet header data with new packet header data.

5. The method as set forth in claim 1, also comprising evaluating said threshold conditions with a byte-code interpreter, wherein evaluating comprises: a. indicating the data that is to be collected from packet header processing; and b. indicating if collected data exceeds predefined threshold conditions; wherein said byte-code comprises a predefined set of instructions.

6. The method as set forth in claim 1, wherein one of said packet attributes includes a virtual network (NLAN) indentifier, and associating a first Radix tree corresponds to a network protocol, and having further associated with it a second Radix tree including one or more rules.

7. A method of protecting a network from potentially harmful data traffic traversing a plurality of data ports of the network, the data traffic comprising data packets, the method comprising the steps of: a. providing a means for monitoring attributes of data traffic traversing a plurality of data ports of a network; b. providing a means for responding when an attack on said network is determined to occur; c. defining a set of attack parameters from attributes of one or more data packets traversing a network, such that when said defined set of parameters are met an attack on said network is presumed to occur; d. specifying a set of responses that may be taken in response to said attack, wherein said responses are defined by a set of response policies, said response policies being designed to select one or more of said responses from said set of specified responses based upon monitored attack parameters; e. monitoring all the data packets traversing the data ports from a plurality of sources with said monitoring means to determine when said attack parameters have been met; f. comparing and coordinating said attack parameters and said response policies to select one or more of said set of specified responses based upon said monitored attack parameters; and g. providing said one or more selected responses through said response providing means to protect said network from said attack.

8. The method of claim 7 wherein said set of responses is selected from the group consisting of a denial of access response, an alert response wherein an alert of said attack is provided, a throttling response wherein data packets are queued and sent along the network at a controlled rate, a redirection response wherein the attack from an attacking source is redirected to another destination, a duration response wherein a time period is specified for application of one or more response, and combinations thereof.

9. The method of claim 8 wherein said step of comparing and coordinating said attack parameters and said response policies utilizes a Radix tree.

10. The method of claim 9 wherein said means for monitoring attributes of data traffic traversing a plurality of data ports of a network is through promiscuous packet capturing on a firewall device.

11. The method of claim 9 wherein said means for responding when an attack on said network is determined to occur is through insertion of flow control policies on the firewall device.

12. The method of claim 7 wherein said attributes of said data packets are selected from the group consisting of a data packet's source address, a data packet's destination address, a data packet's source port, a data packet's destination port, the number of data packets from a source address per unit of time; the number of data packets from a source port per unit of time, the rate of fill corresponding to an amount of traffic relative to the rate at which traffic ages-out, the average size of data packets, a data packet's protocol, and combinations thereof.

13. The method of claim 12 where said response is selected based upon said data packet attributes selected from the group consisting of a data packet's source address, a data packet's destination address, a data packet's source port, a data packet's destination port, the number of data packets from a source address per unit of time; the number of data packets from a source port per unit of time, a data packet's protocol, and combinations thereof.

14. The method according to claim 8 wherein the step of denying access to the source is automatic.

15. The method according to claim 7 further comprising the step of accessing data packets from a shared memory buffer in kernel mode for monitoring.

16. The method according to claim 7 wherein the step of monitoring further comprises monitoring both incoming and outgoing data packets traversing the data ports.

17. The method according to claim 7 where the step of monitoring further comprises separately monitoring the data packets traversing each of the data ports.

18. The method according to claim 8 further comprising allowing data packets from sources other than the denied source to traverse the data ports.

19. The method according to claim 8 further comprising allowing packets from protocols other than the denied protocol to traverse the data ports.

20. The method according to claim 8 further comprising allowing packets at a controlled rate from selected source addresses or protocols or combinations thereof.

21. The method according to claim 7 wherein said response policies are user defined.

22. The method of claim 8, wherein said set of responses is applied in stages over two or more defined periods of time, such that a first response is applied in a first time period, a second response is substituted for said first response during a second time period, until an attack condition is no longer detected, and the response is removed.

23. The method of claim 22, wherein a plurality of n stages is applicable to n time periods associated with n responses, where n is an integer value that is virtually unlimited, until an attack condition is no longer detected and the response is removed.

24. The method according to claim 9 wherein said Radix tree comprises a first Radix tree corresponding to an area of one or more sets of IP addresses of the network, each said set of IP addresses being associated with a single node in the first Radix tree; and each said one or more nodes having further associated with it a second Radix tree corresponding to one or more network protocols, each of said network protocols being associated with one or more nodes in the second Radix tree; and each said one or more nodes having further associated with it a third Radix tree including one or more rules.

25. The method of claim 24, wherein each said second Radix tree associated with each of said one or more nodes corresponds to a network protocol.

26. The method of claim 25, wherein each said third Radix tree issues responses to manage network traffic according to a variably configurable set of policies, wherein said set of policies define one or more comparison characteristics and one or more threshold settings arranged in a logic algorithm which causes one or more response to be inserted or removed in a firewall.

27. The method of claim 3, wherein policies may also include inverted matches selected from the group consisting of (1) match all that is not and (2) match some (rather than any/all),

28. The method according to claim 7, wherein the data traffic also including frame headers containing address information for a Layer-2 datagram, and packet header information, and processing said frames as packet headers for purposes of monitoring and responding to data traffic.

29. The method according to claim 13, wherein at least one of said attributes are measured as a percentage of the total packets captured to determine whether an attack condition has occurred.

30. The method according to Claim 14, wherein said response is selected based upon at least one of said attributes being measured as a percentage of the total packets captured to determine whether an attack condition has occurred.

31. The method according to claim 9 wherein monitored data packets includes Layer-2 dataframes.

32. The method according to claims 9, wherein areas and policies may be configured while the system is operating, and implemented by creating, updating or destroying nodes in the appropriate area or policies Radix trees.

33. The method according to claim 9, wherein the policies may be configured dynamically as a function of time such that a different policy is substituted depending on the time of day, week month or year.

34. The method according to claim 9, wherein, if a policy is associated with a defined area, said policy may trigger responses that expand the scope of the policy beyond the associated area, to block traffic in other areas, or to block all network traffic, simply by defining the match policy.

35. A system for protecting a network, the system comprising a data monitoring means programmed to sample data packets transmitted to and from the network, a memory for storing the sampled data packets and a processor for comparing and coordinating selected attack parameters based upon one or more attributes of said data packets and a set of specified responses defined by one or more response policies to select one or more of said set of specified responses based upon said monitored attack parameters and provide said one or more selected responses to protect said network from said attack.

36. The system of claim 35, wherein said data monitoring means, said memory, and said processor are contained within a network bridge device.

37. The method as set forth in claim 1, wherein said NLAN is associated directly with a Radix tree including one or more rules.