WO2005069578A1 - Procede et appareil de systeme de detection des intrusions dans un reseau - Google Patents

Procede et appareil de systeme de detection des intrusions dans un reseau Download PDF

Info

Publication number
WO2005069578A1
WO2005069578A1 PCT/US2005/000160 US2005000160W WO2005069578A1 WO 2005069578 A1 WO2005069578 A1 WO 2005069578A1 US 2005000160 W US2005000160 W US 2005000160W WO 2005069578 A1 WO2005069578 A1 WO 2005069578A1
Authority
WO
WIPO (PCT)
Prior art keywords
hash
signature
data
memory
value
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
PCT/US2005/000160
Other languages
English (en)
Inventor
Satish N. Anand
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Corrent Corp
Original Assignee
Corrent Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Corrent Corp filed Critical Corrent Corp
Publication of WO2005069578A1 publication Critical patent/WO2005069578A1/fr
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
    • H04L63/1408—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic by monitoring network traffic
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
    • H04L63/1408—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic by monitoring network traffic
    • H04L63/1425—Traffic logging, e.g. anomaly detection

Definitions

  • the present invention generally relates to computer network monitoring and, more particularly, to a system and method of monitoring a computer network for unauthorized access and intrusion.
  • Intrusion detection is a security technology that attempts to identify and isolate potential intrusions into a computer system.
  • An intrusion may include unauthorized usage or misuse of a computer system, or various other types of anomalous activity related to the computer system.
  • Such intrusions which in many instances are attempted by so-called "computer hackers," may include, for example, computer viruses and Trojan horses.
  • many computer systems include some type of intrusion detection system.
  • a NIDS operates on network data flow to detect improper activity.
  • a NIDS uses a network adapter in promiscuous mode that listens to and analyzes all network traffic in real-time as the traffic traverses the network.
  • a NIDS interprets the traffic and attempts to detect intrusions by monitoring for patterns of suspicious activity in the traffic.
  • a NIDS can typically discern attacks that involve low-level manipulation of the network, and correlate data regarding attacks against multiple machines on a network.
  • a NIDS monitors traffic using a network segment to which it is connected as a data source.
  • NIC network interface card
  • NIDS network interface card
  • Packets are considered to be of interest if they match a signature, which typically corresponds to a specific type of intrusion.
  • signatures There are three primary types of signatures: header condition signatures, port signatures, and string signatures. Most signatures may use a combination of header, port, and string signatures.
  • Header signatures correspond to dangerous or illogical combinations in packet headers.
  • a well-known header signature is a TCP packet with both the SYN and FIN flags set, which signifies that the requestor wishes to start and stop a connection at the same time.
  • String signatures correspond to a text string in the payload that indicates a possible intrusion.
  • a UNIX signature may be "/bin/chmod" which may indicate an attempt by an intruder to change user permissions.
  • a compound string signature for a common Web server attack might be "cgi-bin” AND “aglimpse” AND “IFS”.
  • Another compound string signature for a common Web server attack might be the presence of "/view-source” and "../” strings in a packet.
  • the data size "n" of a packet may e, for example, up to 1,522 bytes.
  • the number of byte comparisons would be 64,713,600.
  • a larger number of signatures requiring searching may create a significant processing burden for a NIDS.
  • FIG. 1 illustrates a gateway device coupling an internal network to an external network
  • FIG. 2 illustrates a simplified functional block diagram of a specific example of a system architecture suitable for use in implementing a network intrusion detection system and method, in accordance with an embodiment of the present invention
  • FIG. 3 illustrates a high-level simplified functional block diagram of a network intrusion detection system, in accordance with an embodiment of the present invention.
  • FIG. 4 illustrates a more-detailed functional block diagram of the hash circuit of FIG. 3, in accordance with an embodiment of the present invention.
  • FIG. 1 An exemplary communications system 100 that may be used to implement an embodiment of the present invention is shown in FIG. 1, and includes two communication networks, an external communication network 102 and an internal communication network 104, which are coupled to one another via a gateway device 106.
  • the external communication network 104 is any one of numerous communication networks that may be used to communicate a remote network or device with the internal communication network.
  • the external communication network 102 may be the Internet, which may in turn provide a connection to yet another (non-illustrated) external network, or one or more non-illustrated single-user computers.
  • the internal network 106 may any one of numerous types of local network communication systems such as, for example, a local Ethernet network.
  • the gateway device 106 is used to facilitate communication between the external 102 and internal 104 networks. It will be appreciated that the gateway device 106 may be any one of numerous known devices useful for providing this functionality including, for example, a router, a network switch, a network processor, or at least part of a network interface card (NIC).
  • NIC network interface card
  • the gateway device 106 preferably performs various packet classifications and other network processing functions, and further performs security processing such as encryption, decryption, and authentication.
  • security processing such as encryption, decryption, and authentication.
  • the gateway device 106 preferably integrates the functions of a stateful firewall, a VPN (virtual private network), and network intrusion detection.
  • the gateway device 106 extracts so-called "flow information" from the header of IP data packets it receives, and searches the extracted flow information in a lookup table or database (not shown).
  • the flow information of an IP data packet header typically includes data representative of the IP Source Address, the IP Destination Address, the Layer 4 Source Port, the Layer 4 Destination Port, and the protocol byte (e.g., TCP, UDP, etc).
  • the flow information is typically referred to as a "five-tuple.”
  • the results from the lookup table or database are used to form a data structure known as a connection table entry. It will be appreciated that the firewall and NPN lookup results may be combined, in which case the connection table entry will have a pointer to the VPN security association.
  • the gateway device 106 also includes several processors (not shown in FIG. 1) that, among other things, examine data packet headers and, for the most-common packets, perform modifications to them. This functionality is typically referred to as fast-path processing. Data packets that cannot be handled by the fast-path processing are sent as exception items for so-called slow-path processing.
  • the slow-path processing preferably combines the policy tables of the firewall and VPN with a NIDS policy (not shown). However, if not so combined, the slow-path processing functionality searches the NIDS policy during the formation of a connection table entry, and adds the resulting flow identifier information from the search to the connection table.
  • the NIDS policy is administered by a rules file, which is read during initialization and whenever the NIDS policy is updated.
  • the NIDS initialization software builds two databases, a NIDS flow database and a NIDS signature database (neither of which is shown in FIG. 1).
  • the NIDS flow database entries are similar to the firewall rules, in that the entries are also five-tuples, but with the addition of several checks to header variables and patterns. The difference in the five-tuple lookup is that all five-tuple lookups belonging to the same type of flow may be classified together. For example, all http server traffic may have the NIDS flow identifier.
  • FIG. 2 a particular embodiment of the gateway device 106 that implements the above-described function is shown is functional block diagram form, and will now be described in more detail.
  • the gateway device 106 includes a plurality of packet engines 202, a plurality of cryptographic core processors 204, and a NIDS 206.
  • the gateway device 106 includes three packet engines 202, which are configured to operate in parallel, and thus supply three channels of network processing. It will be appreciated that this is merely exemplary, and that the gateway device 106 could be implemented with more or less than this number of packet engines 202, to thereby provide more or less network processing channels.
  • each packet engine 202 is preferably coupled to, and transmits data packets to/receives data packets from, an I/O interface 208.
  • the data packets may be formatted according to any one of numerous transmission protocols such as, for example, internet protocol (IP) packets.
  • IP internet protocol
  • the data packet may be an IP packet, or the IP packet may be assembled externally into a stream such as, for example, a TCP or UDP stream, and a window of bytes from this stream may be sent to the NIDS 206.
  • the data packet may be normalized data for a particular flow.
  • the data packet may be http normalized data, instead of raw data.
  • Each packet engine 202 is * in operable communication with one of the cryptographic core processors 204, via a pre-crypto bus 210 and a post-crypto bus 212.
  • the cryptographic core processors 204 implement security processing such as, for example, IPSec and/or SSL processing for IP packets, and further implement data encryption/decryption and authentication routines on packets of data each receives from its associated packet engine 202. It will be appreciated that clear text data packets that have not been encrypted are supplied to the cryptographic core processors 204 via the pre-crypto bus 210, and that post-decryption clear text data packets are supplied to the packet engines 202 via the post-crypto bus 212.
  • the NIDS 206 which is described in more detail further below, is configured to match parts of a data packet (e.g., the packet header, payload, trailer) against one or more signatures in the above-mentioned NIDS signature database (not shown in FIG. 2). For example, during fast-path processing, the header information of a data packet arriving via the I/O interface 208, may be examined and passed to the NIDS 206, which then uses the header and flow identifier information written by the fast-path processing functionality to aid in its search for possible signature pattern matches. In the depicted embodiment, the NIDS 206 is configured to implement this signature matching routine only on clear text data packets. Thus, as is shown in FIG.
  • the NIDS 206 is coupled to receive clear text data packets from the pre-crypto 210 or post-crypto buses, depending on whether the data packets are encrypted or decrypted. It will be appreciated, that this configuration is merely exemplary, and that the NIDS 206, in an alternative embodiment, could be configured to implement the routine on encrypted data packets.
  • the NIDS 206 is also coupled to a register bus 214, which is used to provide set-up and control information for fast-path and/or slow-path processing, and to the packet engines 202 to assist in controlling future related traffic flow that is determined to be suspect.
  • FIG. 3 a high-level simplified functional block diagram of the
  • the NIDS 206 includes a packet memory 302, a hash circuit 304, a hash memory 306, an address memory 308, a signature request circuit 310, a signature database 312, a signature compare circuit 314, and a command and status circuit 316.
  • the packet memory 302 is coupled to receive clear text data packets from the pre-crypto 210 and post-crypto 212 busses.
  • the packet memory is coupled to receive clear text data packets from the pre-crypto 210 and post-crypto 212 busses.
  • the pre-crypto 210 and post-crypto 212 busses are 32-bit data busses, and the packet memory 302 is configured to receive the clear text data packets in 64 byte bursts. It will be appreciated that this is merely exemplary, and that the pre-crypto 210 and post-crypto 212 busses could be implemented to transmit more or less than this number of bits, and the packet memory 302 could be implemented to receive data bursts of more or less than this number of bytes.
  • packet memory 302 may be implemented using any one of numerous memory types, sizes, and configurations, but in the depicted embodiment it is implemented as a one kilobyte, first-in first-out (FIFO) buffer, with 512 bytes being used for each data stream.
  • FIFO first-in first-out
  • the hash circuit 304 is in operable communication with, and is configured to receive clear text data packets from, the packet memory 302. Although the manner in which the clear text data packets are supplied to the hash circuit 304 may vary, in the depicted embodiment, the data packets are supplied in 8 byte bursts via, for example, a 64-bit data bus 303.
  • the hash circuit 304 performs "N" hash computations on sequential bytes of the data packets, to thereby provide a set of "N" hash values.
  • the hash circuit 304 converts all the packet data bytes to upper case (e.g., characters "a" to "z” are converted to characters "A" to "Z").
  • the "N" hash values are used as read addresses 318 into the hash memory 306.
  • the hash circuit 304 retrieves the data stored at these addresses 318 in the hash memory 306 and, using the retrieved data, supplies a read request to the address memory 308.
  • a functional block diagram of the hash circuit 304 is shown in FIG. 4, and before describing the remainder of the NIDS 206, it will be described in more detail.
  • each signature content string should be compared to the packet data at each and every byte offset of the packet data.
  • each signature content string has a size of less than 48 bytes. Larger content strings may be accommodated by using the multiple content signature feature discussed herein, for up to, for example, seven signatures per multiple content signature, each of which may be up to 48 bytes in length.
  • the hash circuit 304 includes a state machine 402 and a plurality of hash units 404 (404-1, 404-2, 404-3, .
  • the state machine 402 receives the clear text packet data stored in the packet memory 302, via the 64-bit bus 303, as described above.
  • the state machine 402 converts the packet data to upper case, as described above, and supplies the converted data 406, byte-by-byte, to the hash units 404.
  • the state machine 402 is also configured to retrieve data from the hash memory 306, to supply one or more address data values to the address memory 308, and, if necessary, to implement an arbitration routine prior to supplying the address data values to the address memory 308.
  • the data that the state machine 402 retrieves from the hash memory 304 is based on the hash values computed by the hash units 404, and the address data values correspond to the computed hash values.
  • the hash units 404 are each configured to receive two data values and, using the same hash algorithm, to supply a hash value 408 having a width of Na-bits.
  • one of the two data values supplied to each hash unit 404 is the same, in that each hash unit 404 is coupled to receive the same data byte 406 from the state machine 402.
  • the second data value supplied to each hash unit 404 is different.
  • the. second data value supplied to the first hash unit 404-1 is a fixed initial value 410, while the second data value supplied to the remainder of the hash units 404-2, 404-3, 404-4, . . .
  • the second data value supplied to the second hash unit 404-2 is the hash value 408-1 output from the first hash unit 404-1
  • the second data value supplied to the third hash unit 404-3 is the hash value 408-2 output from the second hash unit 404-2
  • the Nth hash unit 404-N for which the second data value is the hash value 408-(N-l) output from the (N-l) hash unit.
  • the second hash unit 404-2 supplies a hash value 408-2 that reflects a 2-byte hash.
  • the third hash unit 404-3 supplies a hash value 408-3 that reflects 3-bytes, and so on to the Nth hash unit, which supplies a hash value 408-N that reflects N-bytes.
  • the state machine 402 supply the second data byte 406 to each hash unit 404, but the first hash unit 404-1 supplies a second valid data value (i.e., its resultant hash value 408-1) to the second hash unit 404-2.
  • the first 404-1 and second 404-2 hash units will supply valid hash values 408-1, 408-2.
  • the first 404-1, second 404-2, and third 404-3 hash units will supply valid hash values 408-1, 408-2, 408-3, and so on until all of the hash units 404 supply valid hash values 4xx-l, 408-2, 408-3, . . . 408-N.
  • the hash units 404 operate in parallel to provide the set of N hash values, as mentioned above, as read addresses 318 to hash memory 306.
  • the initial value 410 supplied to the first hash unit 404-1 may be a fixed, predetermined value, or it may be programmable. It will additionally be appreciated that in other embodiments the bit size of the data 406 provided to each hash unit 404 may be longer or shorter than one byte. Moreover, in a particular preferred embodiment, the hash circuit 304 is implemented with 48 hash units 404. However, it will be appreciated this number is merely exemplary, and that the hash circuit 304 may be implemented with more or less than this number of hash units 404.
  • bit- width (Na) of the hash values 408 computed by each hash unit 404 will depend, at least in part, on the hash algorithm that the hash units 404 implement.
  • the implemented hash algorithm is a 12-bit cyclic redundancy check polynomial (CRC12).
  • CRC12 cyclic redundancy check polynomial
  • the hash units 404 could implement any one of numerous other hash algorithms, including any one of numerous other CRC polynomials that generate hash values of different widths.
  • the CRC 12 generator polynomial generates the following 12-bit CRC result:
  • G(x) x u + x 11 + x 3 + x 2 + x + 1 .
  • the hash memory 306 stores a plurality of single-bit datum that indicate whether the valid hash values 408 computed by the hash circuit 304, and which are used as hash memory 306 read addresses 318, match one or more hash values that result from the hash of one or more signatures stored in the signature database 312. More specifically, each data bit stored in the hash memory 306 represents either a logical "0" or a logical "1.” If the data bit at a particular address in the hash memory 306 is set (e.g., a logical "1"), this indicates that the particular hash value 408 computed by the hash circuit 304 matches the hash value resulting from the hash of the content string of one or more signatures in the signature database 312.
  • the first hash unit 404-1 supplies a 12-bit hash value of "HI,” and the data bit stored at address "HI" in the associated portion of hash memory 306 is a logical "1,” then the content string of one or more signatures also hashed to a 12-bit hash value of "HI.”
  • the hash memory 306 may be implemented in any one of numerous configurations, which may depend, for example, on the specific hash algorithm implemented in the hash circuit 304.
  • the above-described hash memory 306 configuration may be implemented using either a single memory or a plurality of memories, -which may be either on-chip memories, off-chip memories, or a combination of both.
  • the hash memory 306 may be implemented using N-number of arrays or memories.
  • one memory (or array) is associated with each hash value 408 calculated by the hash circuit 304, and each memory (or array) has a width of 2 Na bits, and a depth of 1 bit.
  • the data 320 retrieved from the hash memory 306 during each clock cycle has a length of "N" bits.
  • the hash memory 306 is implemented using 48 memories (or arrays), each with a width of 4,096 bits (e.g., 2 12 ) and a depth of 1 bit, and the data 320 retrieved therefrom has a length of 48 bits.
  • the hash memory 306 may be modified to save chip area by sharing the memories for sets of hash values 408 calculated by the hash circuit 304.
  • a first memory (not shown) may contain data corresponding to the first hash value 408-1, the second hash value 408-2, the third hash value 408-3, and the fourth hash value 408-1
  • a second memory (not shown) may contain data corresponding to the fifth hash value 408-5, the sixth hash value 408-6, the seventh hash value 408-7, and the eighth hash value 408-8, and so on.
  • sharing in this manner may cause a false positive hit by indicating a hash value match in the hash memory 306 when the signature content strings correspond to different byte offsets, but any such false positive hit will be later corrected when all fields of the signature data are accessed from the signature database (as describe in more detail below) and the content string byte length is compared to the byte length of the corresponding hash value 408 that was used as the read address 318 for the hash memory 306.
  • the hash circuit 304 uses the data 320 retrieved from the hash memory 306, supplies a read request 322 to the address memory 308. More specifically, the hash circuit 304, based on the N-bit length data 320 retrieved from the hash memory 306, uses one or more of the calculated hash values 408 as a read address 324 for the address memory 308.
  • Thehash values 408 indicate at least the data packet offset and the byte length of the corresponding hash values 408 computed by the hash circuit 304.
  • hash circuit 304 As portions of the clear text data packet are processed by hash circuit 304, if the data 320 read from the hash memory 306 indicates that there is more than one signature match (e.g., two or more bits in the data 320 are set), then the hash circuit 304, as previously alluded to, implements an arbitration routine to select the order in which to send the plurality of hash values 408 to the address memory 308.
  • an arbitration routine to select the order in which to send the plurality of hash values 408 to the address memory 308.
  • the address memory 308 stores data representative of the start addresses of linear linked lists of one or more signatures that are stored in the signature database 312.
  • the address memory 308 may be implemented in any one of numerous configurations, but preferably has the same depth as the hash memory 306 (e.g., 2 Na words). It will be appreciated that the width of each word stored in the address memory 308 depends on the maximum address to be requested by the address memory.
  • the address memory 308 includes a 16-bit wide base address register 326 and a 16-bit wide RAM 328. With this implementation, the address register 326 is used to store the higher address bits (e.g., bits 16-31) of the linked list starting addresses, and the
  • RAM 328 is used to store the lower address (e.g., bits 0-15) linked list starting addresses.
  • each word in address memory RAM 328 may store a data bit to indicate whether the signature data is located on-chip or off-chip. For example, this bit may be set to "1" to indicate that the linked list starting address is located on-chip, or set to "0" to indicate that it is located off-chip.
  • the address memory 308 in response to the read requests 322 received from the hash circuit 304, supplies the linear linked list starting addresses 330, and signature read requests 332 to the signature request circuit 312.
  • the address memory 308 also preferably passes the data representative of the data packet offset and the byte length for the corresponding hash values to the signature request circuit 310.
  • the signature request circuit 310 is in operable communication with the address memory 308, the signature database 312, and the signature compare circuit 314.
  • the signature request circuit 310 receives the linked-list starting addresses 330 and the signature read requests 332 from the address memory 308 and, in response, issues read requests 334 to the signature database 312 using the linear linked list starting addresses.
  • the signature request circuit 310 also supplies the data representative of the offset and byte length to the signature compare circuit 314 along with the signature read from the signature database 312.
  • the signature request circuit 310 is implemented in a pipelined configuration, which allows the signature request circuit 310 to issue multiple read requests before the completion of a previous read request.
  • the signature database 312 stores each of the signatures that are compared, if necessary, to the network data packets.
  • the signatures are each preferably stored in the signature database 312 using a data structure that includes the pattern content string of the signature, the length (in bytes) of the content string, and the range to search for the first content string.
  • the range is specified by two parameters, the offset and the depth.
  • the offset specifies the number of bytes to ignore from the start of a packet payload
  • the depth specifies the maximum byte offset to search for a content string.
  • a subsequent content may specify offset and depth from the previous content match (sometimes referred to using the terms "distance" and "within").
  • the data structure further includes one or more fields indicating the type of packet communication protocol (e.g., TCP, UDP, or ICMP) that is associated with the signature, the case sensitivity of the content string, a flow identifier to identify the particular data packet flow of which the data packet is a part, a field to indicate whether a selected number or all of a signature's fields must match a data packet for a signature match to occur, and a pattern identifier number to identify the particular signature.
  • TCP Transmission Control Protocol
  • UDP User Datagram Protocol
  • ICMP e.g., ICMP
  • the signature database 312 is implemented using two memories, an on-chip signature memory 336 and an off-chip signature memory 338.
  • the on-chip signature memory 336 is preferably used to store signatures that have a higher probability of a match in the hash memory 306, or signatures that have a higher collision count in the linear linked list. For example, signatures having a length of one byte are preferably stored in the on-chip signature memory 336, since these will typically have a higher probability of a hit.
  • 64 kilobytes of the on-chip memory 336 are configured as 8,192 words, using a 64-bit data width. Of this total memory, 256 bytes are reserved as a cache, which is used as a temporary space for caching signatures read from off-chip memory 310. After allocating this portion of the on-chip memory 336, the remaining portion is first allocated to those signatures having a length of one byte and then, if available, to signatures having a higher probability of a hit or a higher collision count in the linked list. Once all of the on-chip memory 336 space is allocated, the remaining signatures in the signature database are allocated to the off-chip memory 338. No matter the specific location of a signature in the signature database 312, be it in on-chip signature memory 336 or the off-chip signature memory 338, each signature that is read from the signature database 312 is supplied to the signature compare circuit 314.
  • the signature compare circuit 314 is in operable communication with the packet memory 302, the signature request circuit 310, the signature database 312, and the command and status circuit 316.
  • the signature compare circuit 314 is coupled to, and receives the data packet presently stored in, the packet memory 302, via a 64-bit data bus 339.
  • the signature compare circuit 314 also receives each of the signatures, one by one, in the linear linked list of signatures that are read from the signature database 312.
  • the signature compare circuit 314 is coupled to receive the signatures directly from either the on-chip memory 336 or the off-chip memory 338, as appropriate. It will be appreciated that this is merely exemplary, and that the signature compare circuit 314 could receive the read signatures from, for example, the signature request circuit 310.
  • the signature compare circuit 314 Upon receipt of the currently stored data packet and the signatures, the signature compare circuit 314 compares the data packet to one or more fields of each signature in the linear linked list.
  • the specific fields that the signature compare circuit 314 is to compare may depend, for example, on whether the current data packet was a pre-crypto data packet or a post-crypto data packet. This information is supplied to the command and status circuit 316, which in turn communicates the specific fields to be compared to the signature compare circuit 314.
  • the hash circuit 304 converts all packet data to upper case prior to conducting the hash computations and thus does not take case sensitivity into account.
  • the signature compare circuit 314 is preferably configured to examine both upper and lower cases during content string comparisons.
  • the signature compare circuit 314 determines that the data packet and the signature match if, for example, the content string, the offset, and the byte length fields in the signature data structure match the data packet content, offset, and byte length information. It will be appreciated that the signature compare circuit 314 may be configured to compare one or more additional signature data structure fields to one or more additional characteristics associated with the data packet, before determining whether a match occurs. Some non-limiting examples of additional fields that may be checked in the signature compare circuit 314 include IP, TCP flags, TCP sequence number, TCP acknowledge number, ICMP type, ICMP code, ICMP sequence number, ICMP identifier, and flow identifier.
  • the signature compare circuit 31 is configured such that the signature comparison for each signature in the linked list is conducted serially. It will thus be appreciated that the longer the linear linked list is, the more time it will take to process the entire list. Therefore, as will now be discussed in more detail, the signature compare circuit 314 is preferably configured to compare the signature data structure fields with the data packet in manner that optimizes the operational efficiency of the NIDS 204 (e.g., in a minimum number of clock cycles).
  • the comparison of the signature data structure content string to the data packet is preferably made conditional on other signature data structure fields matching the data packet. For example, if the signature byte length does not match, then the signature compare circuit 314 determines that there is no match and does not perform a content string comparison. Similarly, if the signature data structure offset or packet protocol fields do not match the data packet characteristics, then the signature compare circuit 314 does not perform the content string comparison. It will be appreciated that these conditional comparisons are merely exemplary, and that the signature compare circuit 314 could be configured such that a full comparison is not implemented unless the signature flow identifier field matches the data packet flow identifier and/or that the signature depth field matches the hit identified for the data packet.
  • the first transfer of packet data from the packet memory 302 is not affected. Moreover, if the content string comparison fails in the initial fields of the first transfer, then subsequently accessed packet data bytes will be ignored, and as a result, no further transfer requests will occur.
  • the signature compare circuit 314 supplies a request to the signature request circuit 310 to fetch the next signature in the linear linked list. It is noted here that the location of the next signature in the linear linked list is indicated by an address increment field in each signature data structure. If the next signature in the linear linked list also does not match, then additional signatures in the linear linked list are similarly tested until each signature in the linear linked list are tested. The end of the linear linked list is indicated, for example, if all of the bits in the address increment field have a "0" value.
  • the signature compare circuit sends status data resulting from the comparisons it performs to the command and status circuit 316. If a signature match is found, then the signature compare circuit 314 supplies status data regarding the match to the command and status circuit 316.
  • status data may be, for example, a 64-bit word indicating the byte offset at which the match occurred, the pattern identifier, and any relative minimum and maximum distances (if present). In the case of multiple content signature matches, relative minimum and maximum distances between strings are passed to the command and status circuit 316 for ordered checking.
  • the command and status circuit 316 is in operable communication with the register bus 214 and the signature compare circuit 314.
  • the command and status circuit 316 receives control and configuration information from the register bus 214.
  • the command and status circuit 316 also supplies status data, which indicates, among other things, the pattern identifier of a matched signature, to the register bus 214 for subsequent communication to the fast path software.
  • the fast path software preferably sends a list of pattern identifiers to an exception path, thereby avoiding the need for the slow path software to repeat a search for the signature. This latter functionality is discussed further below.
  • the command and status circuit 316 is coupled to the signature compare circuit 314 and, as was noted above, is configured to supply the signature compare circuit 314 with packet field data that is representative of the specific fields that the signature compare circuit 314 is to use when comparing the current data packet for a signature match.
  • the register bus 214 also preferably supplies the command and status circuit 316 with header-specific data for each packet.
  • the command and status circuit 316 is also configured to receive the status data that is supplied from the signature compare circuit 314.
  • the command and status circuit 316 orders the status data based on absolute offsets and pattern identifiers.
  • the command and status circuit 316 checks whether all of the multiple content signatures are found with the correct relative minimum and maximum distances.
  • the system and method improves the efficiency of, and/or reduces the number or extent of, signature or content comparisons that used to implement network access or intrusion monitoring and detection.
  • the NIDS 206 implements filtering that compares several header fields in the packet data to that in the signature, which reduces the number of false positive detections.
  • the NIDS 206 is preferably implemented along with a stateful firewall and VPN, which enhances network traffic monitoring by searching data before encryption or after decryption, and which permits combining the five-tuple lookup database for all three functionalities. As a result, only one lookup needs to be performed for each data packet.
  • the resulting connection table entry includes a flow identifier, which is used by the NIDS 206 to compare the data packet to only those signatures that are relevant to that packet's traffic flow, and for a VPN connection may additionally include a security association (if present).

Landscapes

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

Abstract

La présente invention concerne un système et un procédé de surveillance de l'accès à un réseau, NIDS, dans lesquels un paquet de données (303) est reçu, ce paquet de données comprenant au moins un multiplet de données. Une valeur de hachage est calculée (304) pour chacun des multiplets du paquet de données afin d'obtenir une pluralité de valeurs de hachage calculées. Une ou plusieurs valeurs de données sont lues (318, 320) dans une mémoire de hachage (306) à l'aide d'au moins une adresse de lecture des valeurs de hachage calculées. A partir des valeurs de données lues dans la mémoire de hachage, une des valeurs de hachage calculées est sélectionnée. Une valeur de données d'adresse de départ est lue (324) dans une mémoire d'adresses (306) au moyen de la valeur de hachage sélectionnée en tant qu'adresse de lecture. Une ou plusieurs signatures est/sont lue(s) dans une mémoire de signatures (312) au moyen de la valeur de données d'adresse de départ lue dans la mémoire d'adresses en tant qu'adresse de lecture. Les signatures lues dans la mémoire de signatures sont ensuite comparées (314) à au moins des parties du paquet de données reçu.
PCT/US2005/000160 2004-01-05 2005-01-04 Procede et appareil de systeme de detection des intrusions dans un reseau Ceased WO2005069578A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US53428304P 2004-01-05 2004-01-05
US60/534,283 2004-01-05

Publications (1)

Publication Number Publication Date
WO2005069578A1 true WO2005069578A1 (fr) 2005-07-28

Family

ID=34794260

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2005/000160 Ceased WO2005069578A1 (fr) 2004-01-05 2005-01-04 Procede et appareil de systeme de detection des intrusions dans un reseau

Country Status (1)

Country Link
WO (1) WO2005069578A1 (fr)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB2442758A (en) * 2006-10-10 2008-04-16 Umu Ltd Computer virus detection using a Boyer Moore search algorithm
CN114238279A (zh) * 2021-12-20 2022-03-25 北京天融信网络安全技术有限公司 数据库安全防护方法、装置、系统、存储介质和电子设备

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5319779A (en) * 1989-01-23 1994-06-07 International Business Machines Corporation System for searching information using combinatorial signature derived from bits sets of a base signature
WO2002027443A2 (fr) * 2000-09-25 2002-04-04 Itt Manufacturing Enterprises, Inc. Systeme de detection d'intrusion dans un reseau informatique mondial
US20030110393A1 (en) * 2001-12-12 2003-06-12 International Business Machines Corporation Intrusion detection method and signature table
US20030149887A1 (en) * 2002-02-01 2003-08-07 Satyendra Yadav Application-specific network intrusion detection
US20030154399A1 (en) * 2002-02-08 2003-08-14 Nir Zuk Multi-method gateway-based network security systems and methods
US6609205B1 (en) * 1999-03-18 2003-08-19 Cisco Technology, Inc. Network intrusion detection signature analysis using decision graphs

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5319779A (en) * 1989-01-23 1994-06-07 International Business Machines Corporation System for searching information using combinatorial signature derived from bits sets of a base signature
US6609205B1 (en) * 1999-03-18 2003-08-19 Cisco Technology, Inc. Network intrusion detection signature analysis using decision graphs
WO2002027443A2 (fr) * 2000-09-25 2002-04-04 Itt Manufacturing Enterprises, Inc. Systeme de detection d'intrusion dans un reseau informatique mondial
US20030110393A1 (en) * 2001-12-12 2003-06-12 International Business Machines Corporation Intrusion detection method and signature table
US20030149887A1 (en) * 2002-02-01 2003-08-07 Satyendra Yadav Application-specific network intrusion detection
US20030154399A1 (en) * 2002-02-08 2003-08-14 Nir Zuk Multi-method gateway-based network security systems and methods

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB2442758A (en) * 2006-10-10 2008-04-16 Umu Ltd Computer virus detection using a Boyer Moore search algorithm
CN114238279A (zh) * 2021-12-20 2022-03-25 北京天融信网络安全技术有限公司 数据库安全防护方法、装置、系统、存储介质和电子设备

Similar Documents

Publication Publication Date Title
US11032190B2 (en) Methods and systems for network security universal control point
US7703138B2 (en) Use of application signature to identify trusted traffic
US8490158B2 (en) Firewall including local bus
CA2445751C (fr) Filtre de paquets dynamiques faisant appel a la recherche de session
US7577758B2 (en) Hardware support for wire-speed, stateful matching and filtration of network traffic
EP1908219B1 (fr) Analyseur actif de contenu de paquet pour réseau de communication
US7356599B2 (en) Method and apparatus for data normalization
US7831822B2 (en) Real-time stateful packet inspection method and apparatus
US7463590B2 (en) System and method for threat detection and response
US9270643B2 (en) State-transition based network intrusion detection
CN101052934B (zh) 用于检测网络上未经授权的扫描的方法、系统和计算机程序
US20040039940A1 (en) Hardware-based packet filtering accelerator
US20030200441A1 (en) Detecting randomness in computer network traffic
US7623450B2 (en) Methods and apparatus for improving security while transmitting a data packet
US20200213238A1 (en) Hierarchical pattern matching devices and methods
US6363071B1 (en) Hardware address adaptation
US20080134283A1 (en) Security apparatus and method for supporting IPv4 and IPv6
WO2005069578A1 (fr) Procede et appareil de systeme de detection des intrusions dans un reseau
TW202226779A (zh) 用於在機動車輛中監測資料網路之方法，以及切換裝置和機動車輛
US20230262071A1 (en) Method for monitoring data traffic between control devices of a motor vehicle and vehicle equipped accordingly
US8516588B1 (en) String detection system and method of detecting a string
KR102046612B1 (ko) Sdn 기반의 dns 증폭 공격 방어시스템 및 그 방법
TWI807454B (zh) 用於監測機動車輛的控制單元間的資料流量之方法以及經適當裝備之機動車輛
WO2004059448A2 (fr) Examen de paquet
JP6883470B2 (ja) パケット中継装置及びパケット中継システム

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

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

AL Designated countries for regional patents

Kind code of ref document: A1

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

121 Ep: the epo has been informed by wipo that ep was designated in this application
NENP Non-entry into the national phase

Ref country code: DE

WWW Wipo information: withdrawn in national office

Country of ref document: DE

122 Ep: pct application non-entry in european phase