Patent Grant
7802303
1. Field of the Invention
The present invention relates generally to data processing, and more particularly but not exclusively to detection of computer viruses.
2. Description of the Background Art
Computer viruses, worms, Trojans, and spyware are examples of malicious codes that have plagued computer systems throughout the world. Although there are technical differences between each type of malicious code, malicious codes are collectively referred to as “viruses.” For example, commercially available “antivirus software” is designed to scan a computer for viruses as well as worms and other malicious codes.
Traditional antivirus techniques are file-based that require random access of object files. Although very effective in purely file access environments, the random access nature of these file-based techniques makes them relatively difficult to apply to stream-based data. A file-based antivirus needs to buffer a file before it can scan the file for viruses. Depending on implementation details, this may lead to relatively low throughput and large memory requirement. Unfortunately, with the advent of the Internet, detection and blocking of viruses embedded in network data streams have become very important. Packet level scanning solutions that monitor packet level behavior rather than virus bodies encoded and encapsulated in data streams may not be effective enough to deal with the latest threats. Packet level scanning solutions that rely exclusively on special-purpose hardware for scanning may not be flexible enough for low end applications and may not be able to handle compressed data.
In one embodiment, a data stream is scanned for presence of computer viruses using a stream-based protocol parser, a stream-based decoder/decompressor, and a stream-based pattern matching engine. The protocol parser may be configured to extract application layer content from the data stream to generate a file stream. The protocol parser may stream the file stream to the decoder/decompressor, which may decode/decompress the file stream to generate a plain stream. The decoder/decompressor may stream the plain stream to the pattern matching engine, which in turn may scan the plain stream for viruses. Advantageously, the aforementioned components may perform its function as soon as streaming data becomes available, without having to wait for the entirety of the data.
These and other features of the present invention will be readily apparent to persons of ordinary skill in the art upon reading the entirety of this disclosure, which includes the accompanying drawings and claims.
a) schematically shows the format of a conventional compressed archive file.
b) shows a state diagram illustrating the operation of a stream-based decoder/decompressor, in accordance with an embodiment of the present invention.
a)-8(d) further illustrate the method of
The use of the same reference label in different drawings indicates the same or like components.
In the present disclosure, numerous specific details are provided, such as examples of apparatus, components, and methods, to provide a thorough understanding of embodiments of the invention. Persons of ordinary skill in the art will recognize, however, that the invention can be practiced without one or more of the specific details. In other instances, well-known details are not shown or described to avoid obscuring aspects of the invention.
Referring now to
In the example of
A protocol stream may comprise data exchanged between communicating computers, the data representing information defined by a communication protocol. For example, Hyper Text Transfer Protocol (HTTP) data exchanged between a client and a server comprise an HTTP stream. Files may be extracted from application layer protocol streams. For example, a file may be extracted from a payload in an HTTP stream. In the Open Systems Interconnection (OSI) seven layer model, a protocol stream may contain upper layer protocol streams. For example, HTTP streams (layer 7 protocol in the OSI model) may be extracted from Transmission Control Protocol (TCP) streams (layer 4 protocol in the OSI model).
File streams may comprise data transferring file contents from one computer to another. File streams may contain encoded or compressed contents. File streams may be extracted from protocol streams.
Plain streams may comprise file streams that do not need to be decoded or decompressed to be scanned for viruses.
In one embodiment, the stream-based protocol parser 303 comprises computer program code for extracting file streams from protocol streams or upper layer protocol streams from lower layer protocol streams. The protocol parser 303 may intercept, capture, and parse protocol packets and extract payloads from the protocol packets for virus scanning. For example, the protocol parser 303 may comprise an HTTP parser that receives network traffic as data streams and extracts application layer payloads from the data streams. The protocol parser 303 may also support other protocols at other layers without detracting from the merits of the present invention.
In one embodiment, the protocol parser 303 is implemented using a state machine. Because embodiments of the present invention may be used for transparent anti-virus filtering at different network layers, e.g. layers 2, 3, and 7, the state machine preferably traces the states of both communicating computers instead of just one of them. In general, Internet protocols and upper layer protocols, e.g. TCP, HTTP, FTP, IRC, IM protocols, etc., are preferably parsed using a stream-based algorithm to extract payload data or file and at the same time stream scanned for virus scanning. Even for random accessing protocols, such as CIFS and NFS, a stream-based algorithm is feasible as long as the client is accessing a complete file serially.
In operation, the protocol parser 303 receives protocol streams from the data streams 301 (line 302). The protocol parser 303 identifies and sequentially extracts file streams from the data streams 301, and forwards the extracted file streams to the stream-based decoder/decompressor 307 (line 306) if the file stream carries an encoded or compressed file. If the file carried by the file stream is not encoded or compressed (i.e., a plain stream), the protocol parser 303 forwards the file stream directly to the stream-based pattern matching engine 311 (305). The protocol parser 303 may process a data stream several times (line 304) to extract file streams from the various layers of the communication protocol. For improved performance, the protocol parser 303 forwards the file stream as portions of it are extracted rather than waiting for the entirety of the file to be extracted.
In one embodiment, the stream-based decoder/decompressor 307 comprises program code for decoding/decompressing encoded/compressed files. In the example of
In one embodiment, the stream-based pattern matching engine 311 comprises computer program code for sequentially scanning a data unit, such as a file, for viruses. The pattern matching engine 311 may receive a plain stream from the protocol parser 303 (line 305), the decoder/decompressor 307 (line 310), or directly from the data streams 301 (line 312). The pattern matching engine 311 may scan the plain stream for viruses by comparing the contents of the plain stream to virus patterns in the pattern file 601 (see
In state 401, the protocol parser 303 waits for an HTTP request header, which may be from a client computer 270 of the private computer network 250 (
The state machine changes from state 411 to state 401 after the pattern matching engine 311 completes the scanning of the content and finds the content to be virus-free (line 413). The state machine exits when the connection goes down or there are no more HTTP requests (line 414).
The state machine changes from state 401 to state 404 when the protocol parser 303 receives a request header that has a content part (line 403). In that case, the protocol parser 303 forwards the content directly or indirectly (e.g., by way of the decoder/decompressor 307; see
From state 404 or 411, the state machine changes to state 406 if the pattern matching engine 311 detects a virus in the content part of the request header (line 405) or in the content part of the response header (line 412). The pattern matching engine 311 or another component of the antivirus 262 may initiate shutdown of the HTTP connection (line 407) upon detection of a virus. The user or the network administrator may also be informed of the presence of one or more viruses in the HTTP connection.
A protocol parsing state machine, such as the one in
Turning now to
b) shows a state diagram illustrating the operation of a stream-based decoder/decompressor 307, in accordance with an embodiment of the present invention. In the example of
In the example of
The decoder/decompressor 307 may stream the decompressed portions of the content 503 to the pattern matching engine 311 (line 315 in
Stream-based decompression using a state machine takes advantage of the fact that popular compression formats employ a one-pass algorithm. This allows a state machine like that in
Some message formats, such as MIME Base64 and UUEncode, utilize text-based encoding. To detect in-line detection of viruses embedded in such encoded messages, a decompression-like state machine-based approach may also be used. Memory cost will also be relatively small. For example, it is estimated that a state machine will use no more than 1 Kbytes of memory for each MIME Base64 encoded stream. By using a stream-based decoding or decompression process, recursively encoded or compressed files may be supported automatically by concatenate multiple decoding/decompression state machines.
Referring now to
In one embodiment, a signature part 610 includes an offset information 613 (i.e., 613-1, 613-2, . . . ), a signature segment 612 (i.e., 612-1, 612-2, . . . ), and a distance information 614 (i.e., 614-1, 614-2, . . . ). A signature segment 612 may be a binary string indicative of a presence of a virus. A signature part 610 may have more one or more signature segments 612.
Offset information 613 specifies an offset to a location in a data stream where a signature segment 612 should be found. The offset information 613 may be relative to a byte in the data stream, for example. Offset information 613 is optional. When not present in a virus signature part 610, it means the corresponding signature segment 612 may be found at any number of bytes from a reference position in the data stream. Otherwise, the signature segment 612 must occur at an offset indicated by the offset information 613.
It is also optional to have distance information 614 or to have more than one signature segment 612 in a signature part 610. When there are two or more signature segments 612 in a signature part 610, distance information 614 indicates the distance (e.g., in bytes) between two signature segments 612 in the data stream. When two signature segments 612 occur in the data stream but are not separated by a distance corresponding to the distance information 614, the signature segments 612 do not satisfy the conditions of the virus signature. In one embodiment, the distance information 614 is in the form “{min-max}” where “min” indicates the minimum separation between signature segments 612 and “max” indicates the maximum separation between signature segments 612. For example, {0-10} may indicate that there may be zero to ten bytes separating the signature segments 612 in the data stream. As another example, and depending on implementation, {0-0} may indicate that there is no limit on the number of bytes separating two signature segments 612.
In one embodiment, each signature segment 612 comprises a binary string, such as a fixed byte string 620 (i.e., 620-1, 620-2, . . . ). Depending on implementation, a signature segment 612 may also comprise a variable length byte string. A byte string 620 may be 12 to about 256 bytes in length, for example. In one embodiment, each byte string 620 is a unique byte string. In
Other suitable virus signature formats may also be used without detracting from the merits of the present invention.
In step 701, the pattern matching engine 311 receives a plain stream from the decoder/decompressor 307 (line 310 in
In steps 706 and 707, if a signature segment 612 occurs in the plain stream, the pattern matching engine 311 checks the location of the signature segment 612 in the plain stream against associated offset information 613 and distance information 614, if any. In step 708, if the signature segment 612 occurs in the correct location in the plain stream, the pattern matching engine 311 determines whether all conditions (e.g., signature parts and logical relationship between signature parts) of a virus signature 600 that includes a signature part 610 that in turn includes the found signature segment 612 are now satisfied. If so, in step 709, the pattern matching engine 311 deems that a virus is found in the plain stream.
In step 710, if no signature segment 612 is found between the portions of the plain stream or if a found signature segment 612 is not in the correct location in the plain stream or if the conditions of a virus signature 600 are not fully satisfied, the pattern matching engine 311 determines whether the plain stream is still streaming. If so, the pattern matching engine moves the pointer to another portion (e.g., next byte) of the plain stream for another round of virus scanning. Otherwise, the virus scanning process ends.
a)-8(d) further illustrate the method 700. In the example of
The first virus signature of Table 1 has a single signature part with the following specifications:
a) name of the virus=vir1;
b) offset information=8;
c) first signature segment=“0102030405060708090a0b0c”;
d) second signature segment=“1112131415161718191a1b1c”;
e) distance information between first and second signature segments={10-10} or exactly 10 bytes.
The second virus signature of Table 1 has single signature part with the following specifications:
a) name of the virus=vir2;
b) offset information=none;
c) first signature segment=“0102030405060708090a0b0c”;
d) second signature segment=“2122232425262728292a2b2c”;
e) distance information between first and second signature segments={0-0} (i.e., can be any distance).
Note that there are three unique byte strings between the signature segments of viruses vir1 and vir2. These byte strings are labeled as “ID=1”, “ID=2”, and “ID=3” in Table 2. Byte string ID=1 is a signature segment common to both viruses vir1 and vir2, byte string ID=2 is a signature segment of the virus vir2, and byte string ID=3 is a signature segment of the virus vir2.
Turning now to
In
In
Because of the large number of byte strings too look for, it is preferable to scan for all or most of these byte strings at the same time, in parallel, using a Bloom filter or TCAM (ternary content-addressable memory), for example. Even then, the pattern matching engine 311 preferably remains stream-based by sequentially scanning received plain streams, from the first received byte to the last received byte of the stream, once and in a forward (i.e., toward later received bytes) direction, recording matched strings and locations of those matched strings as opposed to historical content. This is preferable to traditional file based solutions that need to randomly access different portions of the plain stream.
While specific embodiments of the present invention have been provided, it is to be understood that these embodiments are for illustration purposes and not limiting. Many additional embodiments will be apparent to persons of ordinary skill in the art reading this disclosure.
| Number | Name | Date | Kind |
|---|---|---|---|
| 5623600 | Ji et al. | Apr 1997 | A |
| 5951698 | Chen et al. | Sep 1999 | A |
| 6449658 | Lafe et al. | Sep 2002 | B1 |
| 6615166 | Guheen et al. | Sep 2003 | B1 |
| 7107617 | Hursey et al. | Sep 2006 | B2 |
| 7363655 | Franczek et al. | Apr 2008 | B2 |
| 7409714 | Gupta et al. | Aug 2008 | B2 |
| 7454418 | Wang | Nov 2008 | B1 |
| 20030014662 | Gupta et al. | Jan 2003 | A1 |
