US9197602B2 - Propagation of viruses through an information technology network - Google Patents
Propagation of viruses through an information technology network Download PDFInfo
- Publication number
- US9197602B2 US9197602B2 US10/457,091 US45709103A US9197602B2 US 9197602 B2 US9197602 B2 US 9197602B2 US 45709103 A US45709103 A US 45709103A US 9197602 B2 US9197602 B2 US 9197602B2
- Authority
- US
- United States
- Prior art keywords
- host
- hosts
- record
- data
- requests
- 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.)
- Active, expires
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
- H04L63/1441—Countermeasures against malicious traffic
- H04L63/145—Countermeasures against malicious traffic the attack involving the propagation of malware through the network, e.g. viruses, trojans or worms
-
- 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/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
- H04L63/0227—Filtering policies
Definitions
- the present invention relates to the propagation of viruses through a network of interconnected processing entities.
- any processing entity is at one time or another connected to one or more other hosts.
- a host in the form of a computer such as a client, a server, a router, or even a printer for example
- ITN information technology
- a host in the form of a computer is frequently connected to one or more other computers, whether within an intranet of a commercial organisation, or as part of the Internet.
- a host in the form of a mobile telephone is, merely by virtue of its intrinsic purpose, going to be connected to one or more other hosts from time to time, and an inevitable result is that the opportunities for the propagation of viruses are enhanced as a result.
- IP Internet Protocol
- the virus once assimilated within a host the virus operates to generate Internet Protocol (“IP”) addresses of other potential hosts at random, and then instructs the host to send a copy of the virus to each of these randomly-generated IP addresses.
- IP Internet Protocol
- the potential hosts are genuine (since the IP addresses are randomly generated)
- sufficient of the randomly generated addresses are real addresses of further hosts to enable the virus to self propagate rapidly through the Internet, and as a result to cause a substantial drop in performance of many commercial enterprise's computing infrastructure.
- a virus is data which is assimilable by a host that may cause a deleterious effect upon the performance of either: the aforesaid host; one or more other hosts; or a network of which any of the above-mentioned hosts are a part.
- a characteristic effect of a virus is that it propagates either through self-propagation or through human interaction.
- a virus may act by becoming assimilated within a first host, and subsequent to its assimilation may then cause deleterious effects within that first host, such as corruption and/or deletion of files.
- the virus may cause self-propagation to one or more further hosts at which it will then cause similar corruption/deletion and further self-propagation.
- the virus may merely be assimilated within the first host and cause no deleterious effects whatsoever, until it is propagated to one or more further hosts where it may then cause such deleterious effects, such as, for example, corruption and/or deletion of files.
- a virus may for example become assimilated within a first host, and then cause itself to be propagated to multiple other hosts within the network.
- the virus may have no deleterious effect upon any of the hosts by whom it is assimilated, however the self-propagation through the network per se may be of a sufficient magnitude to have a negative effect on the speed of “genuine” network traffic, so that the performance of the network is nonetheless affected in a deleterious manner.
- the three examples given above are intended for illustration of the breadth of the term virus, and are not intended to be regarded in any way as exclusively definitive.
- Viral infection is prevented using virus-checking software, which attempts to check all incoming data, for example email attachments. If subsequently a virus is discovered within a host, that host is typically removed from the network immediately, and disinfected once the nature of the virus has been established. In accordance with this philosophy each host may be thought of as contributing to protecting the network against widespread infection firstly by avoiding incidence of infection, and secondly in the event of infection, by its sacrificial removal from the network.
- the present invention provides alternative approaches to infection and propagation of viruses in a network of hosts.
- a method of restricting propagation of viruses in a network having a plurality of hosts comprises the steps of: (1) monitoring network traffic from a first host of the plurality and establishing a record which is at least indicative of identities of hosts to whom data has been sent by the first host; and (2) limiting passage of data from the first host to other hosts within the network over the course of a first time interval, so that during the first time interval the first host is unable to send data to more than a predetermined number of hosts not in the record.
- Another aspect of the invention relates to a host having a gateway for outbound data.
- the gateway is adapted to: (1) monitor requests to send data to other hosts; (2) maintain a record of identifies of hosts in a network to which data has been sent; and (3) prevent dispatch of data to another host within the network whose identity is not in the record.
- a further aspect of the invention is related to a method of operating a host within a network of a plurality of hosts.
- the method comprises the steps of: (1) monitoring requests to send data to other hosts in the network over the course of successive intervals of time; and (2) for each interval of time, creating (a) a dispatch record for requests that have occurred within the scope of a policy, and (b) a buffer record for requests that have occurred outside the scope of the policy.
- the dispatch record contains data entries identifying destination hosts to whom data has been sent.
- a maximum number of entries the dispatch record can contain is defined by the policy.
- the dispatch record is preferably periodically updated at predetermined time intervals to indicate identities of destination hosts to whom data has most recently been sent in accordance with the policy.
- the policy permits data to be sent to a predetermined number of destination hosts (which are not identified in the dispatch record) during each of the time intervals.
- the dispatch record preferably identifies a predetermined number of destination hosts to which data has most recently been sent in accordance with the policy.
- Updating the dispatch record preferably includes deleting an entry identifying a destination host from the dispatch record and replacing the deleted entry with an entry identifying a destination host to whom data has more recently been sent.
- the buffer record preferably includes a plurality of entries each identifying a request to send data to destination hosts which are not identified in the dispatch record. Each entry in the buffer record identifies the destination hosts in respect of which the request was made.
- the destination host's identity is compared with destination hosts identified in the dispatch record. If the dispatch record does not identify the destination host, an entry to the buffer identifying the aforesaid request is added.
- a number of entries are removed from the buffer record in accordance with policy at the end of a time interval.
- the buffer record thereby provides, following the removal step, a record of requests to send data which are outside the scope of the policy.
- the policy may specify removal of a predetermined number of entries on a first in, first out basis.
- a determination of whether the aforesaid number is above or below a threshold defining viral infection is preferably made by monitoring the number of entries identified in the buffer record.
- a signal is generated in response to an indication that the rate of increase of the buffer record exceeds a threshold value.
- the record is established by monitoring the identities of hosts to which data has been sent by the first host over the course of a further time interval preceding the first time interval.
- the record is preferably updated to include the identity of at least one host to which data was sent by the first host during the first time interval and which was not in the record during the first time interval.
- the record preferably includes a predetermined number of identities. Upon updating the record with the identity of a host not previously in the record the identity of a host previously stored in the record is deleted from the record.
- the first and further time intervals are preferably of equal predetermined durations.
- a request to send data from one host to another host includes at least one sub-request to send further data to a further host on whose behalf a destination host specified in the request acts as a proxy for receipt of the further data.
- a further record is preferably established of other hosts within the network having an identity specified in a sub-request.
- the passage of further data from the first host to other hosts within the network is limited during the first time interval, so that during the first time interval the first host is unable to send further data to more than a predetermined number of hosts not in the further record.
- requests to contact hosts not in the record are diverted to a delay buffer.
- the predetermined number of requests is transmitted from the delay buffer.
- a signal is generated in response to a determination indicating the size of the delay buffer exceeds a predetermined size.
- a signal is also preferably generated in response to a determination indicating the rate of increase of the size of the delay buffer exceeds a predetermined rate.
- a signal is also preferably generated in response to a determination indicating there is an increase in the size of the delay buffer per time interval that exceeds a predetermined size.
- a signal is also preferably generated in response to a determination indicating the size of the delay buffer exceeds a predetermined size for a predetermined number of successive time intervals.
- the value of a parameter “slack” is determined based upon a number of successive time periods that pass when no new requests are made to send data from the first host to hosts not in the record. In response to slack exceeding a predetermined value un-impeded passage of data from the first host to other hosts not in the record is allowed.
- Requests to contact hosts not in the record are preferably diverted to a delay buffer.
- Slack is based upon a number of successive time periods during which the buffer is empty.
- Slack is preferably decremented each time an un-impeded passage of data from the first host to a host not in the record is allowed.
- the method preferably includes varying with time at least one parameter selected from the group consisting of: number of hosts in the record; and the predetermined number of hosts not in the record. At least one of the parameters is varied as a function of time of day and/or in response to a perceived threat level.
- At least one of the parameters is changed between a first set of values and a second set of values at a predetermined rate or is randomly changed according to a predetermined probability distribution as a function of time.
- the method includes varying at least one parameter selected from the group consisting of: (a) number of hosts in the record; and (b) the predetermined numbers of hosts not in the record that govern the operation of the method; and determining the value of at least one of the parameters by performing an automated search on a set of data indicative of normal network traffic.
- Steps of the method also preferably comprise: (1) receiving a request to send a multiple recipient email; (2) determining the value of a parameter (“mslack”) based on a number of successive time periods that pass when no multiple recipient emails are sent from the first host; and (3) allowing un-impeded passage of the multiple recipient email in response to mslack exceeding a predetermined value.
- the multiple recipient email is allowed un-impeded passage if mslack is greater than or equal to a number of intended recipients of the email.
- MSlack is set to zero after the multiple recipient email has been sent.
- the gateway is preferably adapted to (1) monitor requests to transmit data to another host within the network over the course of a series of time intervals, and transmit data to another host within the network, wherein the identity of the another host is not in the record on a predetermined number of occasions in any given time interval.
- the gateway is adapted to divert request to a delay buffer.
- the diverted requests are to network hosts having identities that are not in the record.
- FIG. 1 is a block diagram of one form of a typical prior art network architecture
- FIG. 2 is a schematic illustration of the conventional operational architecture of a computing entity forming a part of, for example, the network of FIG. 1 ;
- FIG. 3 is a flow diagram of how a connection is established in accordance with an application protocol from FIG. 2 ;
- FIG. 4 is a schematic illustration of data transmission in accordance with a further application protocol from FIG. 2
- FIG. 5 is a schematic illustration of an operational architecture according to an embodiment of the present invention of a computing entity forming a part of a network
- FIG. 6 is a graphical representation of the operation of a method according to an embodiment
- FIG. 7 is a flowchart illustrating the operation of the method of FIG. 6 ;
- FIGS. 8A and B are flowcharts illustrating further aspects of embodiments of methods
- FIG. 9 is a schematic description illustration of an information technology network
- FIGS. 10A-D are schematic illustrations of network traffic from a first host of the network illustrated in FIG. 9 to assist in describing the management of such network traffic;
- FIG. 11 is a flow chart illustrating operation of an aspect of a method according to one embodiment
- FIGS. 12A and B are flow charts of further aspects of a method
- FIGS. 13A-C are waveforms helpful in describing the operating of an aspect of the invention.
- FIG. 14 is a flowchart of steps for performing the method associated with FIGS. 13A-C ;
- FIG. 15 is a flow chart of steps of a further embodiment.
- each of the entities 10 includes what may be thought of as three functional parts: one or more application programs 100 , which in general terms may be thought of as enabling implementation of a particular task that a user of the entity may wish to perform, such as browsing the Internet, word processing and so on; hardware 300 (such as a hard drive 310 , memory 320 , a processor 330 , and a network card 340 ); and an operating system 200 .
- application programs 100 which in general terms may be thought of as enabling implementation of a particular task that a user of the entity may wish to perform, such as browsing the Internet, word processing and so on
- hardware 300 such as a hard drive 310 , memory 320 , a processor 330 , and a network card 340
- an operating system 200 such as a hard drive 310 , memory 320 , a processor 330 , and a network card 340 .
- the operating system 200 can be thought of, in part, as an interface between the application programs 100 and the hardware 300 , performing scheduling of tasks required by application programs 100 , system 200 allocates memory and storage space amongst other things.
- the operating system 200 typically, in accordance with this way of describing the architecture of a computing entity, includes a hierarchy, or stack 400 of programs which provide entity 10 with the ability to dispatch and receive data to and from other entities in the network, in accordance with a number of different sets of formal rules governing the transmission of data across a network, known as protocols.
- the network stack 400 can be thought of as being inserted into the operating system 200 so that stack 400 and system 200 operate in conjunction with each other.
- the stack 400 includes a strata of low level programs which perform low level protocols 404 , concerned for example with the formation of bundles of data known as “packets” (which are discussed in more detail later), the order in which bytes of data are to be sent and, where appropriate, error detection and correction.
- low level protocols usually implemented within applications programs (“application protocols”), apply in conjunction with the low level protocols to provide for the dispatch and receipt of data at the behest of applications programs.
- the application program uses four different high level protocols 402 ; RTSP (real time streaming protocol), FTP (file transfer protocol), SMTP (simple mail transfer protocol—used for email), and HTTP (hyper text transfer protocol—used primarily in internet related applications), and the operating system implements two low level protocols 404 : UDP (User Datagram Protocol for use with RTSP), and TCP (Transfer Control Protocol for use with the remaining three application protocols), both low level protocols being implemented above, and in conjunction with Internet Protocol (IP).
- the network stack 400 includes a system program known as a driver 410 for the network card, which in essence is low level software that controls the network card.
- the process of establishing a connection in accordance with HTTP will be considered.
- a request for such a connection is made by the web browser application program, and this in turn is most likely to be at the behest of a user operating the web browser.
- the request will identify the address or “URL” within the network of the computing entity with which a connection is sought, initially using alphanumeric characters entered at the address bar of the browser application program (for example http://www.hp.com).
- these are “resolved” into a numerical “IP address” of the form: xxx.xxx.xxx.xxx, where xxx is an integer between 0 and 255 inclusive.
- An example of an IP address is 192.168.2.2.
- the IP address is subsequently further resolved into what is known as a physical, or Media Access Control (“MAC”) address of the network card of the destination computing entity.
- MAC Media Access Control
- Resolution of the URL into an IP address, and the IP address to a MAC address usually takes place at dedicated computing entities within the network, in a manner which is well known per se, and will not be described further herein.
- This description of the connection process in accordance with HTTP, well known per se has described connections legitimately requested by a user, and by means of a URL. However it should be appreciated that it is possible for example to request a connection from the web browser application program using an IP address, rather than the alphanumeric characters of the URL. This is an aspect of the system behaviour which has been exploited by viruses, some of which randomly generate IP addresses in accordance with the rules governing their allowable format, and then seek connection to those randomly generated addresses.
- connection is a term of art, and is used to refer to a manner of transmitting messages in which acknowledgement of receipt of data is required, so that in the absence of an acknowledgement the connection is deemed either not to have been established, or to have failed, and the transmitted message deemed not to have arrived.
- HTTP HyperText Transfer Protocol
- FIGS. 2 and 3 An example of the establishment of a connection in accordance with HTTP will now be described with reference to FIGS. 2 and 3 .
- a connection in accordance with HTTP is typically established at the behest of a web browser application program (i.e. a program in the applications layer 100 in FIG. 2 ) within the client entity, which requests a connection with a server entity, for example.
- a socket is effectively an allocated memory space in which data relating to the communication sought by the web browser (in this instance) is stored.
- the operating system Upon receiving a request for a socket, the operating system duly creates or “opens” one (which in effect means that memory is allocated), and returns a socket number, which is the identifier for that particular socket.
- the particular socket is indicated by reference numeral 450 , and the number of the socket is “z”, while the part of the operating system which allocates the socket is shown as a “layer” above the network stack, by which it is sought to indicate that, from a methodological perspective, use of the socket (further uses of which will subsequently be described) in the case of outgoing data, precedes the passage of data from the application program through the network stack.
- the web browser requests that the socket z is “bound” firstly to the IP address with which a connection is sought, and secondly is a parameter known as the “port” number (which is essentially a label identifying the application protocol used), by writing these parameters in the socket (which in due course will additionally contain further data).
- the port number for connections via HTTP is usually port 80 .
- a socket Once a socket has been created and bound the browser then requests that a connection be established, and this causes the emission of what is known as a data packet P 10 (shown in FIG. 3 ) to the destination computing entity.
- the requesting packet P 10 contains: an identification of the destination port, i.e.
- an identification of the suitable application protocol for handling messages transmitted over the requested connection (here, because the connection is established in accordance with HTTP, port 80 ); a source port (here 3167 ) which is an arbitrary number (but one which is not: (i) already in use at that time, and (ii) not already allocated as a standard number to define a port identified in accordance with established standards) whose purpose is to provide, to the client requesting the connection, an identification of the connection in acknowledgement messages (e.g., since it is entirely possible that there may simultaneously be two are more connections using the same protocol this may be used to distinguish one such connection from the other); a flag indicating that the synchronisation status of the requesting entity is set to “on” (meaning that sequence numbers—which indicate the order of the packet in a total number of packets sent—between the requesting and destination computing entity are to be synchronised), and an initial sequence number 50 (this could be any number).
- the destination machine Upon receipt of this packet, the destination machine sends back a packet P 20 identifying the source port as 80 , the destination port as 3167 , a flag indicating that the acknowledgement status is “on”, an acknowledgement number 51 which increments the sequence number by one, and its own synchronisation flag number 200 .
- the requesting entity receives this packet it returns a further packet P 30 once again identifying the source and destination ports, and a flag indicating that its acknowledgement status is on, with an acknowledgement number 201 (i.e. which increments the sequence number by one).
- the socket comprises an area 460 allocated to store the actual body of the message which it is desired to transmit (sometimes known as the outbound message content, or the outgoing payload), and similarly a further area 470 allocated to store the body of messages which are received (inbound message content, or incoming payload).
- the TCP layer breaks it up into packets (i.e. data structures such as those illustrated above in FIG. 3 , but further including at least part of the payload), and the IP layer attaches an IP address header.
- packets i.e. data structures such as those illustrated above in FIG. 3 , but further including at least part of the payload
- IP layer attaches an IP address header.
- an incoming message arrives, it passes up through the network stack, i.e. from the network card 340 , up through the Internet Protocol software, etc., and is written in to the relevant socket (as identified, inter alia from the port number), from which the application program retrieves the incoming payload.
- Data may alternatively be transmitted using the protocols RSTP/UDP/IP (indicating the hierarchy of protocols in the network stack adopted in conjunction with each other to transmit the data) which do not require a connection; the dispatching entity sends a packet to the destination entity, and does not require an acknowledgement of receipt.
- RSTP/UDP/IP indicating the hierarchy of protocols in the network stack adopted in conjunction with each other to transmit the data
- media for example is streamed to a client entity 10 from a media server 20 in a series of packets P 100 , P 120 , P 120 . . . , and the client does not acknowledge receipt of any of them.
- Streaming in accordance with this protocol typically follows an initial request to establish a connection between the client and the server by some other connection based protocol, for the purpose of identifying a destination port on the client, amongst other things.
- a layer of viral propagation monitoring software (VPMS) 500 runs within the network stack of one or more machines (i.e., computer entities 10 ) within the network.
- the VPMS acts as a gateway for all outbound data from the computing entity 10 on which it is running, and operates to monitor the propagation of viruses within the network by observing what is, in accordance with a predetermined policy, defined as “unusual” behaviour in contacting other entities (also known as “hosts”, since they may act as hosts for viral infection) within the network.
- a predetermined policy defined as “unusual” behaviour in contacting other entities (also known as “hosts”, since they may act as hosts for viral infection) within the network.
- hosts also known as “hosts”
- non-virally related is characterised by a relatively low frequency of events in which data is sent to destination hosts (i.e. hosts which are the intended destination for data) within the network which have previously not been contacted.
- destination hosts i.e. hosts which are the intended destination for data
- virally-related traffic is often characterised by relatively high frequency events in which data is dispatched (or attempts are made to dispatch data) to previously uncontacted destination hosts.
- the function of the VPMS is to monitor abnormal and therefore possibly virally-related traffic, as defined in accordance with a predetermined policy, and to record such abnormal traffic.
- the VPMS operates upon the basis of a series of time intervals or time windows, which in the present illustrated example are of predetermined and constant length T n.
- T n the VPMS monitors requests to send data to “new” destination hosts, i.e. destination hosts whose identities differ from those specified in a record of identities of destination hosts most recently contacted.
- the record only holds a predetermined number N of destination host identities, so that a destination host is classified as new if it is not one of the N most recently contacted destination hosts.
- the number of new hosts allowed per time window, and the value of N are determined on the basis of the policy, typically defined by a system administrator, and the policy is preferably formulated to take account of the nature of non virally-related network traffic. In this way, the VPMS operates to monitor the speed at which a virus resident on the host propagates from that host to other hosts within the network.
- various applications programs running on the workstation send requests via the VPMS to send data (whether by connection or otherwise) to other hosts within the network (“outbound requests”): the email application program, which requests dispatch of an email message (having multiple addressees) to a mail server, Mail (Request A) using SMTP, the file management application program requesting dispatch of a file recording a text document to another user (Request B) via FTP, and the web browser program which requests connection, (typically via a Web Proxy server), W/Server in order to connect to a site using HTTP (Request C).
- outbound requests to the VPMS from each of these hosts are requests to send data to an identified destination host, and are ultimately manifested by the dispatch of one or more data packets in accordance with the relevant application protocol.
- the term “request” is intended to be interpreted broadly to encompass any indication (usually from an application program, although by no means necessarily) that contact with a destination host is sought, and for ease of terminology, the transmission of a request is to be interpreted as indicating that data is transmitted pursuant to a request to transmit such data.
- the VPMS a computer program in entity 10 , operates in accordance with the flow diagram illustrated in FIG. 7 , whose features will now be described in more detail in conjunction with FIGS. 6A-C .
- FIG. 7 should be regarded as a generic flow diagram of the operation of the VPMS routine, rather than a specific flow diagram of individual events depicted in FIG. 6 .
- the VPMS operates with reference to a series of time intervals, or windows, which in the example of FIG. 6 are of constant length.
- the VPMS program is initiated at step 702 by a clock (typically the clock which defines the time windows) indicating that a time window has commenced.
- the VPMS program then updates a dispatch record, which is a record of the identities of a predetermined number N (which in this example is 3) of destination hosts most recently contacted (in accordance with the policy—see later) the previous time window.
- N which in this example is 3
- the updated dispatch records are stored, as shown for each time window in FIG. 6 ).
- the VPMS program is effectively in a waiting mode until the program receives a request to send data at step 706 (a dotted arrow from step 704 indicating that receipt of request occurs temporarily after step 704 but is not consequential to its occurrence).
- Step 706 may be thought of as a triggering event, so that when a request passes into the VPMS, the identity of the requested destination host specified in the request is matched with the dispatch record. This matching process therefore determines whether the requested destination host is a new host, and is represented at step 708 .
- the time interval T 1 is the first time interval after start-up of the computing entity.
- the VPMS therefore matches the destination host identities for each of the Requests A-C against identities held in a “default” dispatch record 610 for the time period T 1 , which, in the illustrated example, is simply a record of the three hosts most frequently contacted during the lifetime of the host on which the VPMS is running.
- the three most frequently contacted hosts, and therefore the three identities retained in the default dispatch record are those of the mail server (Request A), the file server (Request B) and the web proxy server (Request C).
- Each of the three outbound requests from the workstation during the time period T 1 identifies a destination host matching one of the three host identities in the default dispatch record. Therefore none of the requests is seeking to establish contact with a new destination host and the VPMS therefore takes no action and simply ends at step 710 .
- the VPM S program adds a copy of the Request D as an entry to a virtual buffer in VPMS; the virtual buffer contents are shown in FIG. 6C .
- the entire contents of the socket relating to Request D are duplicated to form the entry in the virtual buffer.
- this is omitted.
- the VPMS On receipt of Request B, the VPMS establishes at a step 708 that B is present in the dispatch record, and so the VPMS routine ends at step 710 .
- Request E is also a new request within the time window T 2 and so at a step 712 the identity of host E is added to the virtual buffer.
- the virtual buffer of VPMS program 500 contains two new requests.
- the policy which the VPMS is designed to monitor comes into play.
- the policy provides that a single new host is contacted per time interval. This element of the policy is monitored by a first buffer management routine of VPMS program 500 .
- the first virtual buffer management routine is illustrated schematically in flowchart form in FIG.
- step 802 begins at step 802 with the advent of a clock timeout, that is to say that the clock (not shown) which defines the time intervals T n has completed another time period, following which, at step 803 the program counts the number of requests in the virtual buffer to update the variable known as LogNo, i.e., the number of entries (each identifying a request) in the virtual buffer at any moment.
- the program determines whether there are any entries in the virtual buffer by examining the value of LogNo, to determine whether its value is greater than 0. If there are no entries in the virtual buffer the routine ends at step 806 . In the present illustrated example, however, during time interval T 2 entries for two requests, D and E have accumulated in the virtual buffer.
- step 808 the entry for the first request RQ 1 (i.e. the one which has been in the buffer for the longest time) is deleted from the buffer.
- step 810 the program then searches the buffer for other entries specifying the same destination host and deletes any such entries, since they are effectively regarded as one entry identity.
- step 810 can be omitted.
- the program then advances to step 812 during which the dispatch record is updated so that it accurately stores the identity of the three hosts most recently contacted in accordance with policy. It should be noted that the dispatch record does not therefore necessarily reflect the identities of hosts which have most recently actually been contacted, if requests to these hosts are outside of the policy.
- the destination host of Request E which although contacted, was not contacted in accordance with the policy of one new destination host per time interval.
- This updating of the dispatch record is indicated in FIG. 6B , where the dispatch record contains the identities of Requests D, C, B.
- the final step in the first buffer management routine is the updating of the value of the variable LogNo denoting the size of the virtual buffer, which in this example, following the transmission of the Request D, is one (i.e. the single Request E).
- the virtual buffer is effectively a record at any instant of requests which have been transmitted outside that policy. This result is achieved in the same way that the dispatch record is a record of recent requests which have been transmitted in accordance with policy.
- One role of the virtual buffer of the VPMS program is to enable a determination to be made with regard to whether the host upon which the VPMS is running is virally infected.
- One way in which this can be manifested is the size of the virtual buffer.
- a state of viral infection can therefore be defined in terms of the size of the buffer, and the stage of any such viral infection by the rate of change of the buffer size. This follows from the generally different behaviour of virally-related and non virally-related network traffic, in that non virally-related or “legitimate” network traffic usually involves contacting only a relatively small number of new destination hosts. Because viruses tend to propagate by transmission to as many disparate destination hosts as possible, an instance of a large number of requests to contact a new destination host is typically indicative of viral infection.
- the virtual buffer can be thought of as a queue of virtual new requests waiting for opportunities to be virtually transmitted in accordance with policy (since their “counterpart” real requests are simply transmitted without hindrance).
- the size of the virtual buffer is therefore one indication of whether there is a viral infection, since a large buffer size is indicative of a large number of requests to contact a new host within a short space of time.
- An alternative indication of viral infection is the existence of an increasing buffer size. Conversely, generally speaking, a buffer size which is steadily declining from a relatively high value might be indicative of a temporary increase in legitimate traffic levels. It can be seen therefore that buffer size can be used to interpret the existence of viral infection with varying levels of complexity, the interpretation typically being something which is defined in the policy.
- a second buffer management routine monitors the virtual buffer, and is triggered by performance of step 814 from the routine of FIG. 8A , or from step 803 , or from step 712 in FIG. 7 i.e. an update in the value of the variable LogNo.
- the program advances from step 814 to decision step 842 , during which the program determines whether the size of the buffer is greater than a quantity V i , which the policy has determined represents viral infection.
- decision step 842 making a “yes” determination the program advances to step 844 during which the program generates a virus alert.
- the virus alert may simply be a visual alert to a user of the workstation 10 , or a message to the network administrator, or both, or even a trigger for automated action to shut down the network, as desired.
- the program determines whether the variable V i is increasing above a given rate. If step 846 makes a “yes” determination, the program during step 848 , issues a further warning indicating the onset of viral infection. After step 848 , the program ends.
- FIGS. 6A-C A situation in which the second buffer management routine generates a viral infection warning is seen in FIGS. 6A-C .
- a single Request A (which it will be recalled from the time interval T 1 is to contact the mail server), and two Requests C are received.
- the dispatch record 614 for time interval T 3 does not contain Request A, the dispatch record adds the identity of host A to the virtual buffer, but not the identify of host C.
- the virtual buffer of the VPMS program therefore contains Request E (stored in the virtual buffer since time interval T 2 ) and Request A.
- Request E Since only one new request is transmitted per time window in accordance with policy, and since Request E has been in the virtual buffer since time interval T 2 , whereas Request A has just been added, Request E is deleted from the virtual buffer (a process with may be thought of as “virtual transmission”), so that at the virtual buffer contains only Request A. This indicates that at the start of time interval T 4 only one more request has been transmitted than the policy allows.
- the first Request for connection in time interval T 4 is Request B, which illustrates that over the course of the three proceeding time intervals, during which only normal network traffic has been transmitted, connection has only been requested to five different destination hosts. However, Request B is nonetheless defined as new because it is not in the dispatch record 616 for time interval T 4 .
- the identity of host B is stored in the virtual buffer (this action being illustrated at the same point in the timeline in FIG. 6C ).
- the program receives two groups of five virtually simultaneous requests, i.e., F-J, and K-O. Since requests F-J and K-O are also new, their identities are also added to the virtual buffer.
- the virtual buffer has increased from a size of one, to 12. In accordance with the policy, such an increase is defined as viral infection, since in the present example a buffer size of greater than five generates this alert.
- the rate of change is positive and rapid (from 1 to 12 in a single time interval)
- the increase in FIG. 6C during T 4 is indicative of the onset of infection. Thus the likelihood is that a substantial number of the requests transmitted during the course of time interval T 4 have been virally related.
- the type of information sought may typically include: (1) the destinations to which a virus has been propagated, (2) where applicable, the application program or programs which the virus uses to propagate itself, and (3) the action and behaviour of the virus.
- the nature of the information which can be obtained directly from the virtual buffer, or which can be deduced therefrom depends to an extent upon the nature of the data stored in the virtual buffer, and the operating system of the host concerned.
- the destination host is recorded in the buffer, and possibly, in the case where the virus copies itself to the socket as the outgoing payload, also the virus.
- the operating system records an identifier in the socket denoting the application program requesting the socket, and an ability to map this process identifier to the requesting application program after the socket has been closed (remembering that the virtual buffer contains a copy of the socket, while the actual socket is transient since it is used to implement the request to send data and is then deleted)
- the application program responsible for requesting data transmission can be identified.
- the use of the data in a socket is only one way to collect data relating to possible viral infection.
- the reliability of copying of the sockets is likely to vary. For example, if, as referenced above, the fullest data (including e.g. copies of the payload) is to be retained, further copies of the sockets in the virtual buffer (stored for example in a manner which tags them to the copy of the socket in the virtual buffer) are preferably made over time as the contents of the socket change over time.
- further copies of the sockets in the virtual buffer stored for example in a manner which tags them to the copy of the socket in the virtual buffer
- two functional elements within the host can cause a change in the data in a socket (e.g. the writing of outgoing data to a socket by an application program, and removal from the socket of outgoing data by the network stack), maintaining a complete record may nevertheless still be difficult simply from observing the contents of sockets.
- the network stack additionally includes a layer 502 (illustrated in FIG. 5 ), known as a packet logger, known per se.
- a packet logger when a viral warning is generated as a result of the virtual buffer size (the virtual buffer of this embodiment still being made of a single copy of a socket), the logger 502 is switched on, and makes copies of outgoing packets. All of the outgoing packets can be copied, or only packets identified by one or more particular destination IP address, the identity of which may, for example, be established from the copies of the sockets in the virtual buffer.
- the logger enables incoming packets from designated IP addresses to be logged, to provide valuable information in circumstances, for example, where a virus has a “hand-shake” action with another host (i.e. sends back a packet to its originating host from a destination host) as part of its propagation process (as is the case, for example with the Nimda worm).
- the relatively early provision of warning of viral infection is potentially extremely beneficial, since in the case of many viruses the rate at which the viruses can establish infection accelerates over time. For example, in the case of the code red virus, it has been established that over the course of the first 16 hours, 10,000 hosts were infected, but that in the subsequent 8 hours the virus infected a further 340,000 hosts.
- the early collection of data on viral infection can thus enable action to be taken, either within the hosts within which infection has been detected, and/or within other hosts, which can substantially reduce the extent of subsequent infection.
- a single outbound request (Request A) to the VPMS specifying a single destination host, namely the mail server, actually contains a plurality of email messages to different specified addressees.
- This outbound request can therefore be thought of as a carrier request for a plurality of sub-requests, having the form of putative email messages intended for dispatch from the mail server to a list of addressees specified within the outbound carrier request.
- the mail server can be thought of as acting as a proxy destination host for the ultimate addressees specified in the outbound carrier requests. In this situation, allowing transmission of the data packet constituting the message to the mail server effectively allows the workstation to contact multiple other hosts within the network (i.e.
- the outbound carrier request will only count as a single request which may not even be recognised as new if, as may be likely, the mail server is identified in the current dispatch record.
- the VPMS operates simply to record in the virtual buffer those new destination hosts to be contacted per time window on the basis only of those destination hosts which are ostensibly identified in the outbound request, the desired monitoring of viral propagation can be circumvented or reduced.
- the desired monitoring can be reduced or circumvented because a single outbound request specifying the mail server does not necessarily represent only a single email subsequently propagating through the network after processing and forwarding by the mail server.
- the VPMS program includes a step of identifying the application program by which an outbound request has been generated. Because certain applications programs are more likely than others to use outbound carrier requests which invoke the use of a proxy (for example the above-mentioned instance of email, or the case of a web browser program) it is possible in advance to specify criteria. The advance criteria can be based on the provenance of an outbound request, identifying those outbound requests likely to be carrier requests. If the packet is generated by one such specified application program, then the VPMS invokes the concerned application protocol to reveal the identities of the destination hosts specified in the sub-requests; here the eventual addressees for whom the email message is intended.
- the identities of the destination hosts specified in the sub-request are regulated in accordance with the same policy which applies to all other requests, and the identities of the destination hosts are matched against the host identities within the dispatch record in the manner previously described in the embodiment described in connection with FIGS. 6-8 .
- Multiple-addressee email messages can be handled as discussed below.
- each VPMS operates independently on a category of requests which it is intended to process, using its own dispatch record, and following a policy for outbound requests tailored to the traffic it is set up to control, for example in the manner previously described and illustrated in connection with FIGS. 6 and 7 .
- the two policies can be the same (e.g. a dispatch record of 3 identities, a time window of constant duration T n , and one new host per outbound request/sub-request), or different as desired.
- the choices of the length of the time window, the number of identities retained in a dispatch record, and the number of new hosts to be allowed per time window are all dependent upon the likely “normal” performance of the network within which the VPMS is operating, and more particularly, the nature of the network traffic the VPMS is intended to control. Therefore, while a policy such as that illustrated in connection with FIGS. 6 and 7 may be effective in monitoring the propagation of viruses through the network to a rate of infection of one new host per time interval, it may also be susceptible to false warnings caused by non virally-related, or “legitimate” network traffic whose characteristic behaviour differs substantially from the policy the VPMS is performing.
- each VPMS implementing a policy tailored specifically to minimise the chance of false warnings with legitimate network traffic.
- an individual VPMS is provided for each application protocol which the hosting entity supports, and requests are routed to appropriate VPMS on the basis of the port identified in outgoing requests from application software.
- the establishment of a record indicative of the normal traffic destination hosts is employed to restrict the propagation of viruses within a network, an example of which is described with reference to FIGS. 9 to 14 .
- FIG. 9 a network, which as previously described, includes a plurality of interconnected hosts.
- FIG. 9 includes a workstation 910 , typically a personal computer, a mail server 912 (“Mail”) which handles email communications within the network, a file server 914 (“F/Server”) on which shared data within the network is stored, and a web proxy server 916 via which any communication between any host within the intranet and an external host passes.
- the network includes further hosts, illustrated under the denomination A. N. OTHER, and whose function within the network has no bearing upon the description of FIG. 9 .
- the workstation 910 runs a plurality of Application software programs concurrently.
- Workstation 910 includes an operating system software and usual workstation hardware, such as memory 920 , storage 922 , and an Ethernet card.
- Examples of the sort of applications programs which run on the workstation 910 include programs to handle the receipt and dispatch of email from the mail server 912 , a web browsing program, a file manager program enabling the organisation and transportation of files, and instant messaging software enabling the dispatch and receipt of ASCII text messages directly to and from peers within the network.
- workstation 910 includes a further software program, i.e., Virus Anti-Propagation Software (VAPS), that runs within the network stack, in the same position as the VPMS in FIG. 5 , i.e., adjacent the networking software.
- VAPS Virus Anti-Propagation Software
- the VAPS handles all requests to send outbound data from the workstation 910 , and operates to restrict the propagation of viruses within the network by limiting the extent to which the workstation can engage in what may be thought of as “unusual” behaviour in contacting other hosts.
- normal network traffic i.e. non-virally related
- virally-related traffic is frequently characterised by a relatively high rate of connection, or attempted connection to previously uncontacted hosts.
- the function of the VAPS is to impede virally-related traffic, while allowing non-virally related traffic to flow with little or no impediment.
- the VAPS operates on the basis of a series of time intervals or time windows, which in the present illustrated example are of predetermined and constant length T n .
- T n the VAPS operates to prevent the host upon which it is running from transmitting requests to more than a predetermined number of “new” hosts, i.e. hosts whose identities differ from those specified in a dispatch record containing identities of destination hosts to whom requests have recently been transmitted.
- the dispatch record only holds a predetermined number N of destination host identities, so that a destination host specified in a request is classified as new if it is not one of the N destination hosts to which a request has been transmitted.
- Policy determines the number of new hosts allowed per time window and the value of N.
- a system administrator typically defines the policy that is preferably formulated to take account of the nature of non virally-related network traffic. In this way, the VAPS operates to limit the speed at which a virus resident on the host can propagate from that host to other hosts within the network.
- various applications programs running on the workstation 910 send requests to the VAPS to connect and send data to destination hosts within the network.
- the requests are sent to (1) the email application program that requests dispatch of an email message (having multiple addressees) to mail server 912 , (Request A), (2) the file management application program that requests dispatch of a file to the file server 914 , to save a text document on a shared network drive (Request B), and (3) the web browser program that requests the web proxy server 916 to contact a site external to the subnet within which the workstation 910 is located (Request C).
- requests to the VAPS from each of these hosts may be in the form of requests to establish a connection to an identified destination host, or requests for use of connection of all protocols.
- request is to be broadly interpreted to encompass any indication that contact with an identified destination host is required.
- a request for connection, if allowed, is followed by data typically in the form of data packets transmitted from the relevant application program to the identified destination host.
- FIG. 11 is a flow diagram of the VAPS program. The various steps that take place during the course of this routine are now described in more detail with reference to the graphical representations of FIGS. 10A-D in combination with the flowchart of FIG. 11 .
- each of the outbound requests hereinafter abbreviated as Requests A, B, C, passes from the respective application by which it was generated, to the VAPS in the network stack, whereupon the process within the VAPS which processes the requests is initiated in step 1102 .
- the identity of the requested destination host specified in each packet is matched with a dispatch record which stores the identities of a predetermined number N (which in this example is 3) of the destination hosts most recently contacted in the previous time window (and which are shown for each time window in FIG. 10B ). Matching the identifies enables VAPS to determine whether the requested destination host is a new host, as represented at step 1104 .
- the example of FIG. 10 somewhat artificially illustrates the principles underlying embodiments of the present invention.
- the time interval T 1 is the first time interval after start-up of the workstation 910 .
- VAPS matches the destination host identities for each of the Requests A-C against identities held in a “default” dispatch record 1010 .
- record 1010 is simply a record of the three hosts most frequently contacted during the lifetime of workstation 910 .
- the three most frequently contacted hosts, and therefore the three identities retained in the default dispatch record are those of the mail server 912 (Request A), the file server 914 (Request B) and the web proxy server 916 (Request C). Since each of the three outbound requests from workstation 910 during the time period T 1 identify a host destination matching one of the three host identities in the default dispatch record, and therefore none of the Requests A, B or C is seeking to establish contact with a new destination host, the VAPS transmits each request at step 1106 . In the example of FIG.
- VAPS allows a connection to be established from workstation 910 to each of hosts 912 , 914 and 916 .
- Transmission of the request during period T 1 is illustrated schematically on the graph of FIG. 10D , which has the same time scale as FIGS. 10A-C , meaning that the temporal relationship between events illustrated in each of these graphs can be readily appreciated.
- workstation 910 During the course of the second time interval T 2 , workstation 910 generates three further outbound requests identifying host destinations “Intranet Peer 1” (Request D), Request B (which as indicated above corresponds to the File Server 914 ) and “Intranet Peer 2” (Request E) are received by the VAPS from: an instant messaging application program (in the case of Requests D and E), and the word processing application, in the case of Request B.
- an instant messaging application program in the case of Requests D and E
- the word processing application in the case of Request B.
- the dispatch record however is now a genuine record of the identities of the three hosts to whom requests have been transmitted most recently in accordance with the policy during the previous time window T 1 (although coincidentally this is identical to the default dispatch record).
- the VAPS Upon receipt of Request D, the VAPS establishes at step 1014 that the identity of Internal Peer 1 is not in the dispatch record, i.e. that it is a new destination host, whereupon VAPS denies the request, and stores the request in a delay buffer of VAPS, step 1108 .
- the delay buffer is effectively a queue of requests which VAPS has not allowed to be transmitted, and the contents of the delay buffer are illustrated schematically in FIG. 10C (the delay buffer is shown in FIG. 10C on each occasion that its contents change).
- VAPS including a first buffer management program, which is illustrated schematically in flowchart form in FIG. 12A .
- the program of FIG. 12A begins at step 1202 with the advent of a clock timeout, that is, that the clock (not shown) which defines the time intervals T n has completed another time period.
- step 1203 the program determines whether there are any entries in the delay buffer (identifying new requests), and it does this using a variable known as LogNo, which is the number of entries in the delay buffer at any moment. If LogNo is not greater than 1 (step 1204 ), i.e. there are no entries in the delay buffer, the program ends at step 1206 . In the present illustrated example however during time interval T 2 two requests, D and E have occurred, causing two corresponding entries to accumulate in the buffer. Therefore the program proceeds to step 1208 , during which VAPS allows the first request RQ 1 (i.e. the one which has been in the buffer for the longest time) to be transmitted.
- RQ 1 i.e. the one which has been in the buffer for the longest time
- step 1210 the program searches the buffer for other entries that identify requests specifying the same destination host and transmits any such requests.
- the logic behind this is that, if there is a virus in the first transmitted request RQ 1 , further copies of the virus are not likely to be deleterious to any great extent.
- step 1210 can be omitted.
- the program advances to step 1212 during which VAPS updates the dispatch record so that the dispatch record accurately reflects the identity of the three most recently contacted hosts.
- FIG. 10B indicates the dispatch record contains the identities D, C, B, which are the three most recently transmitted requests, as indicated in FIG. 10D in accordance with policy.
- the final step in the first buffer management program is updating the value of the variable LogNo that denotes the size of the buffer. In the example of FIG. 10 the buffer size is one (i.e. the single request E), following the transmission of the Request D.
- the buffer stores a record of requests occurring outside the bounds of the policy.
- the buffer size plays an important role in performance by the VAPS of another aspect of the policy.
- Buffer size enables VAPS to detect a state of viral infection in terms of the size of the buffer, and the stage of any such viral infection by the rate of change of the buffer size. This follows from the generally different behaviour of virally-related and non virally-related network traffic, because non virally-related or “legitimate” network traffic usually involves contacting only a relatively small number of new destination hosts. In contrast, viruses tend to propagate by transmission to as many disparate destination hosts as possible. Consequently, an instance of a large number of requests to contact a new destination host is typically indicative of viral infection.
- the size of the buffer is one indication of whether there is viral infection, since a large buffer size indicates a large number of requests to contact a new host within a short space of time.
- increases in buffer size indicate the onset of viral infection, whereas a steadily declining buffer size, although large, indicate of the end of a viral infection.
- a second buffer management program that VAPS stores (illustrated in FIG. 12B ) performs this rate of change part of the policy.
- the program of FIG. 12B is triggered at step 1240 by the occurrence of an update of the value of LogNo (this being step 1214 in the first buffer management program of FIG. 12A ).
- the program of FIG. 12B can also be triggered by step 1203 , or step 1108 in FIG. 11 .
- the program of FIG. 12B advances to step 1242 , during which the program determines whether the size of the buffer is greater than a quantity V i , which the policy has determined represents viral infection. If step 1242 produces a yes result, the program generates a virus alert, step 1244 .
- the virus alert of step 1244 can simply be a visual alert to a user of the workstation 910 , or a message to the network administrator, or both, or a trigger for automated action to shut the network down, as desired.
- the program then advances to step 1246 , during which the routine program determines whether the variable V i is increasing above a given rate. If the determination of step 1246 is yes, VAPS issues a further warning indicating the onset of viral infection at step 1248 , following which the routine ends.
- a situation in which the second buffer management routine generates a viral infection warning can be seen by considering time intervals T 3 and T 4 of FIGS. 10A-D .
- VAPS of workstation 910 receives a single Request A (which it will be recalled from the time interval T 1 is to contact the mail server 912 ), and two Requests C. Because the dispatch record 1014 at the beginning of time interval T 3 does not contain Request A, VAPS (1) denies Request A and sends it to the delay buffer, and (2) transmits the two Requests C. At the end of the time interval T 3 the buffer of VAPS therefore contains Request E (stored in the delay buffer since time interval T 2 ) and Request A.
- the first buffer management routine transmits Request E at the end of the time interval T 3 , meaning that at the start of time interval T 4 the buffer contains only Request A.
- the first request for connection in time interval T 4 is Request B (the File Server).
- Request B the File Server
- VAPS therefore sends Request B to its buffer (this action being illustrated at the same point in the timeline in FIG. 10C ).
- VAPS receives, two groups of five virtually simultaneous requests: F-J, and K-O.
- VAPS adds them to the buffer upon receipt and processing.
- the buffer has increased from a size of one, to 12.
- the new buffer size is defined as viral infection, since in the present example a buffer size of greater than five generates this alert.
- the rate of change of buffer size is positive and rapid (from 1 to 12 in a single time interval), to indicate of the onset of infection.
- the VAPS has been configured to delay outbound requests. This has the advantage of being able to use the delay buffer to provide useful information.
- delaying outbound requests for connection is generally regarded as being compatible with the operation of many computer systems and networks.
- the VAPS may be configured to operate in a number of ways. For example, in accordance with an alternative embodiment, where the computer system permits, the VAPS may, having denied the request for connection, simply return a suitable error message to the dispatching application program by which the packet was generated, and then delete the packet. In accordance with this embodiment the dispatching application program must (if the packet is eventually to be successfully dispatched) then resend the packet.
- the policy relating to the number of new requests which are to be transmitted per time interval can be implemented by initialising a variable corresponding to the number of new requests received in a particular time interval, and incrementing this variable whenever a new request is received. Requests can then either be instantaneously transmitted (in the same manner as requests already in the dispatch record) or denied and deleted on the basis of whether the variable indicative of the number of new requests per time interval has reached a maximum set in accordance with the policy (i.e. in the previous example, one).
- the dispatch record lists transmitted requests in historical order, with the ordinal numbering signifying the temporal order in which the hosts were contacted, i.e. No. 1 indicating the host most recently contacted, and No. 3 indicating the host contacted the longest time previously (i.e., “first in first out)”. This is not essential, and it is equally possible to list the transmitted requests in another order, such as “first in last out” for example, or “least recently used”.
- a single outbound request (Request A) to the VAPS specifying a single destination host, namely the mail server, actually contains a plurality of email messages to different specified addressees.
- the VAPS operates simply to restrict the number of new destination hosts to be contacted per time window on the basis of only those destination hosts which are ostensibly identified in the outbound request, the desired restrictive effect on virus propagation can be circumvented or reduced, because a single outbound request specifying the mail server does not necessarily represent only a single email subsequently propagating through the network after processing and forwarding by the mail server.
- the VAPS includes within its routine a step of identifying the application program which has generated an outbound request. Because certain applications programs are more likely than others to use outbound carrier requests which invoke the use of a proxy (for example the above-mentioned instance of email, or the case of a web browser program) it is possible in advance to specify criteria, based on the provenance of an outbound request, identifying those outbound requests likely to be carrier requests. If the packet is generated by one such specified application program, then the VAPS invokes the use of the concerned application program to reveal the identities of the destination hosts specified in the sub-requests; here the eventual addressees for whom the email message is intended.
- a proxy for example the above-mentioned instance of email, or the case of a web browser program
- the identities of the destination hosts specified in the sub-request can be regulated in accordance with the same policy which applies to all other requests for connections, and they can be matched against the host identities within the dispatch record in the manner previously described in the embodiment of FIG. 11 .
- the surplus addressees can, depending upon the operation of the email program, either be purged from the list, and the message transmitted (such surplus messages can alternatively be dealt with in a different manner, which may also be specified in accordance with the policy), or preferably they are stored in a delay buffer as described in connection with FIGS. 10 and 11 .
- each VAPS operates independently, using its own dispatch record, and peforming a policy for outbound requests tailored to the traffic it is set up to control, for example in the manner previously described and illustrated in connection with FIGS. 10 and 11 .
- the two policies can be the same (e.g. a dispatch record of three identities, a time window of constant duration T n , and one new host per outbound request/sub-request), or different as desired.
- the choice of the length of the time window, the number of identities retained in a dispatch record, and the number of new hosts to be allowed per time window all depend upon the likely “normal” performance of the network within which the VAPS is operating, and more particularly, the nature of the network traffic the VAPS is intended to control. Therefore, while a policy such as that illustrated in connection with FIGS. 10 and 11 is effective in limiting the propagation of viruses through the network to a rate of infection of one new host per time interval, it may also be susceptible to interfering with non virally-related, or “legitimate” network traffic whose characteristic behaviour differs substantially from the policy the VAPS is performing. To ameliorate this difficulty, it is possible to provide a version of VAPS for each application program from which network traffic emanates, with each VAPS performing a policy tailored specifically to minimise the level of impediment to legitimate network traffic.
- FIG. 13A is a plot of activity (i.e. the number of requests processed by the VAPS) against time for the example of FIG. 10A . From graph of FIG. 13A it can be readily appreciated that prior to the viral infection signified by the rapid increase in the number of requests during the time interval T 4 , only a relatively low number of requests are processed per time interval, and that therefore it is possible to use the VAPS to perform a policy of preventing connection to more than one new host per time interval without impeding legitimate network traffic to any significant extent.
- FIG. 13B illustrates an excerpt of a graph illustrating legitimate traffic flow in FIG. 13B , where there are significant levels of activity, interspersed by a much shorter period of time during which there is no activity at all.
- FIG. 13C An example of such a policy is illustrated in FIG. 13C , where two sorts of time intervals are illustrated; S l , a relatively long time interval, and S s , a relatively short time interval. From FIG. 13C it can be seen that when placed together alternately, the time intervals S l correspond to the time interval in the graph of the traffic flow from FIG. 13B where there is a flow of traffic, and the time interval S s where there is no traffic flow to Interval S s is between two long time intervals. By segmenting time for a VAPS using these two time intervals therefore, it is possible to construct a policy which matches closely the legitimate behaviour illustrated in FIG. 13B , but still provides an impediment to the propagation of viruses.
- Such a policy for the VAPS is provided using the variable LogNo, which as explained above corresponds to the number of requests present in the delay buffer at the end of any given time interval. In the present example it is desirable to provide a policy which does not impede the free flow of the legitimate traffic pattern illustrated in FIG. 13C .
- the flow diagram of FIG. 14 is a modified first buffer management program that VAPS performs based on FIG. 13 .
- the program determines at step 1404 whether the LogNo is greater than a predetermined number, in this instance 10.
- the number 10 is chosen, in conjunction with the number of request identities held in the dispatch record. Ten is equal or slightly larger than the number of requests typically received during a “long” time interval S l . If LogNo is greater than 10, then the programs defaults to step 1408 , where the program transmits only the first request in the delay buffer, and then proceeds to step 1412 where VAPS permits transmission of identical requests.
- the program then advances to step 1414 during which VAPS updates the record, then to step 1416 during which VAPS updates the value of LogNo.
- step 1404 determines LogNo is less than 10, i.e. less than 10 new requests have been received during the course of the time interval under consideration, then the program proceeds to step 1406 , during which VAPS determines whether a further variable LogNoLast, equal to the number of new requests received during the previous time interval, is greater than zero. If the determination of step 1406 is yes, the program defaults once again to step 1408 where only a single request is transmitted from the delay buffer. If the determination of step 1406 is no, i.e., no new requests were received during the previous time interval, then the routine acts to transmit, at step 1410 , requests 1 - 10 from the delay buffer, followed by previously described steps 1412 to 1416 .
- VAPS when VAPS receives 10 or less new requests during a time interval, and no new requests were received during the previous time interval, VAPS transmits all 10 requests. This mimics the legitimate activity during a “long” time interval S l , where the activity level is relatively high, but in the previous short time interval activity was zero.
- the routine defaults to what may be thought of as the “standard” policy of one new request per time interval.
- VAPS throttles activity differing from usual legitimate activity, and which is likely to be virally-related.
- the modified VAPS program performs a policy which conforms generally to the behaviour pattern illustrated in FIG. 13C .
- This modified policy has been achieved using two time intervals of different lengths, and a modified version of the buffer management routine, effectively to augment the number of destination hosts which, ultimately (i.e. in this example, at the end of time intervals S l ) end up as not being regarded as new. It is however possible to provide policies involving varying other parameters, such as the number of destination host identities retained in the dispatch record, thereby increasing for any given time interval, the number of destination hosts which will not be regarded as being new, and consequently transmitting a greater number of destination hosts per time interval (or in the case of FIGS. 13C and 14 , per alternate time interval). This would be appropriate in circumstances where the legitimate traffic flow of FIG.
- 13B is characterised by contact with 10 destination hosts whose identities are the same, or similar each time.
- two dispatch records for the destination hosts are used; one for the time intervals S l , containing 10 destination host identities, and the other for the time intervals S s , containing no destination host identities, with the two dispatch records being used alternately.
- the legitimate traffic flow is characterised by contact with a predetermined number (in this example 10) different destination hosts during each time interval S l , this modification would not be appropriate because it would still impede this legitimate traffic flow.
- NreqNo, and NreqNolast denoting the number of new requests in a particular time interval, and the number of new requests in the preceding time interval (and thus the real time equivalents to LogNo and LogNolast) are used to transmit new requests contemporaneously.
- This modification has the advantage of allowing requests to pass immediately, which in cases where legitimate traffic levels are high, prevents undue impediment to legitimate traffic flow.
- new requests which are not transmitted are once again stored in the delay buffer, which as previously, inter alia, enables an indication of viral infection from the value of the LogNo variable.
- VAPS has been illustrated herein on a single workstation within a network. However, in order to be most advantageous it is desirably provided on a plurality of hosts within the network; the greater the number of hosts upon which VAPS is provided results in a greater limit on the ability of viruses to propagate through the network.
- VAPS running concurrently, with one VAPS per application program is preferred, since it enables the performance of different policies for different application programs and thus policies designed to minimise impediment to legitimate traffic flow, while simultaneously providing protection against viral propagation via the appropriated use of application programs.
- Other arrangements are possible, such as: a single VAPS providing a single policy for all applications programs; a plurality of VAPS, some of which deal with traffic from a specified application program, and some of which deal with traffic to a particular destination port (which can be thought of generally as dealing with traffic using a particular communications protocol); or a plurality of VAPS may be provided with each one dealing with traffic for a particular destination port.
- the detection of viral activity can be determined in a number of manners. For instance, it has been described above that a virus is detected if the size of the delay buffer exceeds a predetermined value. However, it is possible for viruses to operate in a manner which maintains a delay buffer at a large value, just less than the predetermined threshold used to indicate viral activity. Such viruses can be said to be “riding the threshold”. Consequently, various other techniques can be used to detect viral activity, either as an alternative to the predetermined threshold size of the delay buffer, or in combination with this or other techniques.
- a transient increase in the size of the delay buffer can provide an indication of viral activity.
- increases in the size of the delay buffer increase greater than a predetermined threshold (i.e., the amount by which the size of the delay buffer increases in a predetermined time), can indicate viral infection.
- a virus can be regarded as active if there is a constant non-zero value in the size of the delay buffer for a predetermined time e.g. for a predetermined number of time intervals.
- a virus could be regarded as active if the size of the delay buffer is greater than a predetermined value for more than a predetermined number of time intervals. This could correspond to a virus attempting to beat the virus detection or protection technique, by riding the threshold.
- the virus may be providing a large number of requests to new hosts. However, if the virus is attempting to maintain the number of requests less than the absolute value for the predetermined number of time intervals an alarm for indicating viral activity is activated.
- An additional parameter can be introduced into the above embodiments, to take into account situations in which no traffic has passed through the VPMS or the VAPS.
- This parameter is termed “slack”.
- a host does not send requests for a relatively long time, and then suddenly wishes to send a number of requests simultaneously. This could, for instance, correspond to a user returning from a lunch break, and then wanting to send a number of emails and/or browse a number of web sites on the Internet.
- the slack parameter is suitable for accommodating such a situation and operates to augment the number of new requests which might be transmitted and yet not stored in a virtual buffer (the case of VPMS). Otherwise, if no traffic has passed through the monitoring system for a relatively long period of time, then such a burst of traffic might be regarded as indicating the presence of a virus by the VPMS. Alternatively, the VAPS might act to delay the new connection.
- the value of the slack parameter is based on the number of time periods in which no new traffic passes through the VAPS or VPMS. There are two alternative, preferred ways of using the slack parameter. The first slack procedure corresponds to no new requests being made to the VAPS or VPMS; the second corresponds to no new requests being despatched from the VAPS or VPMS.
- the slack is incremented for every predetermined time interval or period in which there are no new requests (i.e. no requests to a host not on the despatch record).
- the slack is incremented for every predetermined time interval or period during which the delay queue (e.g. the buffer) is empty.
- the slack value is incremented up to some predetermined maximum value (“maxslack”).
- the slack parameter is thus very useful in dealing with bursty traffic that is on average below the normal operating rate of the network, but is transiently above the limit. Consequently, the slack parameter helps to prevent VAPS or VPMS from interfering with normal operational behaviour of the network.
- slack is only incremented every time a time interval expires and the delay buffer is empty.
- a similar parameter can be used for methods associated with emails e.g. for restricting propagation of viruses via emails.
- VAPS and VPMS operate on the assumption that normal network traffic (e.g. emails) occurs at a low rate compared to network traffic instigated by a virus. For emails sent to single recipients this is largely true. It takes time to compose an email, and emails sent quickly tend to be to addresses that have been emailed recently. For instance, typical parameter values are a host record size of 4, a clock time out Tn of 1 minute, maxslack of 1.
- VAPS or VPMS Multiple recipient emails appear to the VAPS or VPMS as viruses, as they are effectively a large number of messages sent very quickly. Further, the addresses used on multiple recipient emails are often fairly random, and thus are unlikely to fall within the record of normal destinations. To achieve minimal impact on normal traffic would need a large host record, and a large value for the slack parameter. Preferably, the record and the slack are small, otherwise the virus is able to send messages to many recipients before being limited.
- mSLACK a new parameter, termed herein “mSLACK,” which has a value between zero and “maxMSLACK” (i.e., the maximum value of “mSLACK”).
- maxMSLACK the maximum value of “mSLACK”.
- the value of mSLACK is incremented for every time period or interval that the user does not send any multiple emails, up to the maximum value of maxMSLACK.
- the value of mSlack can be incremented by either of the methods described previously.
- the value of mSLACK is reset (e.g. to zero) after every multiple email has been sent.
- a typical value for maxMSLACK is 25.
- a typical clock time out period (Tn) to utilise is one minute, which can be the same value as the time period used for sending emails to single recipients.
- a VAPS or VPMS for emails can be used on a host machine that sends the emails, or more preferably it is provided on an email server (for instance either a Microsoft Exchange Server or an SMTP server), or on an input to the server.
- a VAPS or VPMS is provided for each email client e.g. per host machine or per email user.
- an email client sends a single multiple recipient email to a server.
- the server then generates a separate email (a copy of the multiple recipient email) per recipient within the address field of the multiple recipient email, and then sends these copies to each recipient.
- a VAPS or VPMS utilising the parameter mSLACK is implemented on a host machine (e.g. the machine with the email client), it is preferable that the email client (or the VAPS or VPMS) is arranged to split every multiple recipient message into a multiple number of single recipient emails.
- FIG. 15 is a flow chart illustrating a VAPS program for email, and utilising the parameter mSLACK.
- a VAPS determines if the email is addressed to be sent to a single recipient, or to multiple recipients (step 1510 ). If the email is to be sent to a single recipient, then the email is processed in the normal manner (step 1530 ) with a check made as to whether the intended recipient is a recipient within the dispatch record.
- VAPS determines the value of the parameter mSLACK (step 1512 ).
- mSLACK There are two alternative, preferred procedures to obtain the mSLACK parameter. The first procedure corresponds to no new requests being made to the VAPS or VPMS to send a multiple recipient e-mail; the second corresponds to no new requests being despatched from the VAPS or VPMS.
- the mSLACK is incremented for every predetermined time interval or period in which there are no new requests (i.e. no requests to send a multiple recipient e-mail).
- the mSLACK variable is incremented for every predetermined time interval or period in which a delay queue (such as provided by the buffer) is empty.
- VAPS then checks to determine whether or not the value of mSLACK is greater than or equal to the number of recipients of the multiple email (step 1514 ). If the value of mSLACK is greater than or equal to the number of recipients, then the multiple recipient email is sent to all the recipients (step 1516 ), and the value of mSLACK reset to zero (step 1520 ).
- Option 1 if the value of mSLACK is less than the number of recipients, then a delay mechanism (step 1518 ) is utilised. If the multiple recipient email is being processed so as to be sent out as a multiple number of single recipient emails, then the first mSLACK of these single recipient emails is dispatched, with the remainder of the single recipient emails generated being queued in the VAPS buffer; the emails in the VAPS buffer are considered to be in a delay queue. These emails are then taken off the delay queue or buffer at a predetermined rate (i.e. one per time period). It is envisaged that the single recipient and the multiple recipient mails can share the same delay queue.
- Option 2 Alternatively, if the multiple recipient email is not being split into a multiple number of single recipient emails at this point (e.g. if the VAPS is a program in a host machine that sends a single multiple recipient email to an email server), then the multiple recipient email is delayed. In other words, the email has a send time placed on it that is equivalent to the time that the last email would have been sent if option 1 had been utilised.
- VAPS sends a warning to the user of the email client.
- This warning may include an indication that the number of emails sent is high, that the number of emails sent is indicative of viral activity, and that the outgoing emails are stopped if similar activity persists.
- outgoing emails from the host are stopped.
- incoming emails are still permitted. This allows the user to be kept informed of events, and to be given instructions on how to remove the email block.
- Outgoing messages can be stopped by placing a stop on messages being sent from the buffer.
- the buffer would subsequently increase in size, as more requests to send emails are made. This has the disadvantage of taking up memory, but would potentially allow the recovery of valid messages at a later stage.
- the server could simply refuse any further connections from that user (e.g. that host machine or email client) that attempt to send email. Further, the server could place a stop on sending any locally stored messages that originated from that user. In such a situation, it is likely that the host machine will store the message (e.g. the messages will be stored in the local out box).
- VPMS or VAPS is dependent upon a number of parameters, which exist both as variables and thresholds. Altering such parameters varies the sensitivity of the virus detection or virus, the severity with which propagation is throttled. For instance, if the record used to indicate identities indicative of hosts to which data has been sent by the first host decreases in size, then the throttling or virus detection method will be made severe i.e. data passage will be more limited and/or more warnings indicative of viral activity are likely to occur.
- the parameters can be varied with the time of day so the parameters are systematically varied by predetermined amounts over the course of a day.
- Such a technique could be used, for instance, to provide more severe throttling or viral detection outside of the working hours (when normal network traffic is likely to be lower).
- an extra parameter can be introduced corresponding to a perceived threat level.
- This extra parameter can be introduced by a system administrator, or alternatively might be performed by automatic detection of the rest of the network e.g. when the rest of the network is believed to be under virus attack, then the threat level parameter is increased.
- a high threat level parameter corresponds to the parameters being adjusted to provide more severe throttling or viral detection on a host computer.
- the parameters can be changed randomly by small amounts.
- the parameters can be pulsed between parameters that provide a severe operating regime and those that provide a more relaxed operating regime.
- Such a determination can be performed automatically, by providing a set of data corresponding to normal network traffic (such a set can either be pre-recorded, or collected “live” as the network operates).
- a cost function is then provided, including indications of desired performance of the VAPS or VPMS, and desired trends in parameters, e.g. which parameters can be altered, and by how much.
- An automated search is then conducted to find the optimum set of parameters and parameter values given the set of data on network traffic.
- the automated search algorithm can take a number of forms, and may use techniques such as hill climbing, or simulated annealing, or it may be an evolutionary algorithm.
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)
- Health & Medical Sciences (AREA)
- General Health & Medical Sciences (AREA)
- Virology (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Computer And Data Communications (AREA)
Abstract
Description
Claims (35)
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US14/725,080 US9648038B2 (en) | 2002-06-07 | 2015-05-29 | Propagation of viruses through an information technology network |
Applications Claiming Priority (6)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
GB0213053A GB2391419A (en) | 2002-06-07 | 2002-06-07 | Restricting the propagation of a virus within a network |
GB0213053.2 | 2002-06-07 | ||
GB0224396.2 | 2002-10-19 | ||
GB0224396A GB2394382A (en) | 2002-10-19 | 2002-10-19 | Monitoring the propagation of viruses through an Information Technology network |
GB0309844A GB2401280B (en) | 2003-04-29 | 2003-04-29 | Propagation of viruses through an information technology network |
GB0309844.9 | 2003-04-29 |
Related Child Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US14/725,080 Division US9648038B2 (en) | 2002-06-07 | 2015-05-29 | Propagation of viruses through an information technology network |
Publications (2)
Publication Number | Publication Date |
---|---|
US20040103159A1 US20040103159A1 (en) | 2004-05-27 |
US9197602B2 true US9197602B2 (en) | 2015-11-24 |
Family
ID=9938122
Family Applications (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US10/457,091 Active 2030-03-25 US9197602B2 (en) | 2002-06-07 | 2003-06-09 | Propagation of viruses through an information technology network |
US14/725,080 Expired - Lifetime US9648038B2 (en) | 2002-06-07 | 2015-05-29 | Propagation of viruses through an information technology network |
Family Applications After (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US14/725,080 Expired - Lifetime US9648038B2 (en) | 2002-06-07 | 2015-05-29 | Propagation of viruses through an information technology network |
Country Status (2)
Country | Link |
---|---|
US (2) | US9197602B2 (en) |
GB (1) | GB2391419A (en) |
Families Citing this family (18)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6886099B1 (en) * | 2000-09-12 | 2005-04-26 | Networks Associates Technology, Inc. | Computer virus detection |
GB2391419A (en) | 2002-06-07 | 2004-02-04 | Hewlett Packard Co | Restricting the propagation of a virus within a network |
GB2394382A (en) | 2002-10-19 | 2004-04-21 | Hewlett Packard Co | Monitoring the propagation of viruses through an Information Technology network |
US20050021938A1 (en) * | 2003-06-10 | 2005-01-27 | Kabushiki Kaisha Toshiba | Document access control system and method |
US20050081051A1 (en) * | 2003-10-09 | 2005-04-14 | International Business Machines Corporation | Mitigating self-propagating e-mail viruses |
GB2431316B (en) * | 2005-10-12 | 2008-05-21 | Hewlett Packard Development Co | Propagation of malicious code through an information technology network |
GB2431321B (en) * | 2005-10-12 | 2010-06-09 | Hewlett Packard Development Co | Propagation of malicious code through an information technology network |
US8203941B2 (en) * | 2004-05-28 | 2012-06-19 | Hewlett-Packard Development Company, L.P. | Virus/worm throttle threshold settings |
US7870200B2 (en) * | 2004-05-29 | 2011-01-11 | Ironport Systems, Inc. | Monitoring the flow of messages received at a server |
US9467462B2 (en) * | 2005-09-15 | 2016-10-11 | Hewlett Packard Enterprise Development Lp | Traffic anomaly analysis for the detection of aberrant network code |
US7725549B2 (en) * | 2006-01-30 | 2010-05-25 | International Business Machines Corporation | System and method for hunting out mail recipients in order to obtain a response |
US8612437B2 (en) * | 2006-08-28 | 2013-12-17 | Blackberry Limited | System and method for location-based searches and advertising |
US7987260B2 (en) | 2006-08-28 | 2011-07-26 | Dash Navigation, Inc. | System and method for updating information using limited bandwidth |
US20080059424A1 (en) * | 2006-08-28 | 2008-03-06 | Assimakis Tzamaloukas | System and method for locating-based searches and advertising |
US8856313B2 (en) * | 2007-11-13 | 2014-10-07 | International Business Machines Corporation | Systems and methods for using provenance information for data retention in stream-processing |
JP4488074B2 (en) * | 2008-02-13 | 2010-06-23 | 日本電気株式会社 | Pattern detection device, pattern detection system, pattern detection program, and pattern detection method |
US9054949B2 (en) * | 2012-04-17 | 2015-06-09 | International Business Machines Corporation | Updating zone information in a distributed switch of data forwarders |
US10229431B1 (en) * | 2015-05-28 | 2019-03-12 | Sprint Communications Company L.P. | Explicit user history input |
Citations (39)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
GB2001227A (en) | 1977-07-14 | 1979-01-24 | Int Standard Electric Corp | Common control telecommunication switching system |
US5341491A (en) | 1990-06-29 | 1994-08-23 | Digital Equipment Corporation | Apparatus and method for ensuring that lock requests are serviced in a multiprocessor system |
US5699513A (en) * | 1995-03-31 | 1997-12-16 | Motorola, Inc. | Method for secure network access via message intercept |
GB2315967A (en) | 1995-05-31 | 1998-02-11 | 3Com Ireland | Storm protection mechanism |
WO1998033333A2 (en) | 1997-01-22 | 1998-07-30 | British Telecommunications Public Limited Company | Congestion control in a communications network |
EP0986229A2 (en) | 1998-09-09 | 2000-03-15 | JSB Software Technology plc | Method and system for monitoring and controlling network access |
US6044402A (en) | 1997-07-02 | 2000-03-28 | Iowa State University Research Foundation | Network connection blocker, method, and computer readable memory for monitoring connections in a computer network and blocking the unwanted connections |
US6122740A (en) | 1996-12-19 | 2000-09-19 | Intel Corporation | Method and apparatus for remote network access logging and reporting |
US6256671B1 (en) | 1998-06-24 | 2001-07-03 | Nortel Networks Limited | Method and apparatus for providing network access control using a domain name system |
GB2362076A (en) | 2000-05-03 | 2001-11-07 | 3Com Corp | Network intrusion detector which detects pre-attack probes or scans |
WO2001086895A1 (en) | 2000-05-05 | 2001-11-15 | Thomson Licensing S.A. | Method for reducing the spread of computer viruses in an electronic mail network |
WO2002003084A1 (en) | 2000-06-21 | 2002-01-10 | Netrake Corporation | Method for preventing denial of service attacks |
US6339784B1 (en) | 1997-05-20 | 2002-01-15 | America Online, Inc. | Self-policing, rate limiting online forums |
US20020013858A1 (en) | 2000-02-09 | 2002-01-31 | Anderson Keith R. | ARP caching apparatus and method |
US6356836B1 (en) | 1997-06-12 | 2002-03-12 | Michael Adolph | Method and device for generating, merging and updating of destination tracking data |
US6370125B1 (en) * | 1998-10-08 | 2002-04-09 | Adtran, Inc. | Dynamic delay compensation for packet-based voice network |
GB2367714A (en) | 2000-07-07 | 2002-04-10 | Messagelabs Ltd | Monitoring e-mail traffic for viruses |
GB2368163A (en) | 2000-09-11 | 2002-04-24 | Ibm | Web server apparatus for virus checking |
WO2002045380A2 (en) | 2000-11-30 | 2002-06-06 | Lancope, Inc. | Flow-based detection of network intrusions |
US20020073338A1 (en) * | 2000-11-22 | 2002-06-13 | Compaq Information Technologies Group, L.P. | Method and system for limiting the impact of undesirable behavior of computers on a shared data network |
US20020104024A1 (en) | 2001-01-29 | 2002-08-01 | Fujitsu Limited | Method for detecting and managing computer viruses in system for sending or receiving electronic mail |
GB2373130A (en) | 2001-03-05 | 2002-09-11 | Messagelabs Ltd | Method and system for processing e-mail to detect unsolicited bulk and/or commercial e-mail. |
US20020199109A1 (en) | 2001-06-25 | 2002-12-26 | Boom Douglas D. | System, method and computer program for the detection and restriction of the network activity of denial of service attack software |
US20030005081A1 (en) * | 2001-06-29 | 2003-01-02 | Hunt Preston J. | Method and apparatus for a passive network-based internet address caching system |
EP1280297A2 (en) | 2001-07-23 | 2003-01-29 | Primary Network, Inc. d/b/a Acme Packet, Inc. | System and method for determining flow quality statistics for real-time transport protocol data flows |
EP1280298A1 (en) | 2001-07-26 | 2003-01-29 | BRITISH TELECOMMUNICATIONS public limited company | Method and apparatus of detecting network activity |
EP1369766A2 (en) | 2002-06-07 | 2003-12-10 | Hewlett-Packard Development Company, L.P. | Propogation of viruses through an information technology network |
GB2391419A (en) | 2002-06-07 | 2004-02-04 | Hewlett Packard Co | Restricting the propagation of a virus within a network |
GB2394382A (en) | 2002-10-19 | 2004-04-21 | Hewlett Packard Co | Monitoring the propagation of viruses through an Information Technology network |
US6775657B1 (en) | 1999-12-22 | 2004-08-10 | Cisco Technology, Inc. | Multilayered intrusion detection system and method |
US6789203B1 (en) | 2000-06-26 | 2004-09-07 | Sun Microsystems, Inc. | Method and apparatus for preventing a denial of service (DOS) attack by selectively throttling TCP/IP requests |
GB2401280A (en) | 2003-04-29 | 2004-11-03 | Hewlett Packard Development Co | Propagation of viruses through an information technology network |
US6886099B1 (en) * | 2000-09-12 | 2005-04-26 | Networks Associates Technology, Inc. | Computer virus detection |
US6941348B2 (en) | 2002-02-19 | 2005-09-06 | Postini, Inc. | Systems and methods for managing the transmission of electronic messages through active message date updating |
US6961341B1 (en) | 1996-07-02 | 2005-11-01 | Microsoft Corporation | Adaptive bandwidth throttling for network services |
US6965777B1 (en) | 2000-11-16 | 2005-11-15 | Thomas Cast | Method of delivering short messages using a SMPP gateway with standard interface |
US7032023B1 (en) | 2000-05-16 | 2006-04-18 | America Online, Inc. | Throttling electronic communications from one or more senders |
US7096498B2 (en) * | 2002-03-08 | 2006-08-22 | Cipher Trust, Inc. | Systems and methods for message threat management |
US7278159B2 (en) | 2000-09-07 | 2007-10-02 | Mazu Networks, Inc. | Coordinated thwarting of denial of service attacks |
-
2002
- 2002-06-07 GB GB0213053A patent/GB2391419A/en not_active Withdrawn
-
2003
- 2003-06-09 US US10/457,091 patent/US9197602B2/en active Active
-
2015
- 2015-05-29 US US14/725,080 patent/US9648038B2/en not_active Expired - Lifetime
Patent Citations (39)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
GB2001227A (en) | 1977-07-14 | 1979-01-24 | Int Standard Electric Corp | Common control telecommunication switching system |
US5341491A (en) | 1990-06-29 | 1994-08-23 | Digital Equipment Corporation | Apparatus and method for ensuring that lock requests are serviced in a multiprocessor system |
US5699513A (en) * | 1995-03-31 | 1997-12-16 | Motorola, Inc. | Method for secure network access via message intercept |
GB2315967A (en) | 1995-05-31 | 1998-02-11 | 3Com Ireland | Storm protection mechanism |
US6961341B1 (en) | 1996-07-02 | 2005-11-01 | Microsoft Corporation | Adaptive bandwidth throttling for network services |
US6122740A (en) | 1996-12-19 | 2000-09-19 | Intel Corporation | Method and apparatus for remote network access logging and reporting |
WO1998033333A2 (en) | 1997-01-22 | 1998-07-30 | British Telecommunications Public Limited Company | Congestion control in a communications network |
US6339784B1 (en) | 1997-05-20 | 2002-01-15 | America Online, Inc. | Self-policing, rate limiting online forums |
US6356836B1 (en) | 1997-06-12 | 2002-03-12 | Michael Adolph | Method and device for generating, merging and updating of destination tracking data |
US6044402A (en) | 1997-07-02 | 2000-03-28 | Iowa State University Research Foundation | Network connection blocker, method, and computer readable memory for monitoring connections in a computer network and blocking the unwanted connections |
US6256671B1 (en) | 1998-06-24 | 2001-07-03 | Nortel Networks Limited | Method and apparatus for providing network access control using a domain name system |
EP0986229A2 (en) | 1998-09-09 | 2000-03-15 | JSB Software Technology plc | Method and system for monitoring and controlling network access |
US6370125B1 (en) * | 1998-10-08 | 2002-04-09 | Adtran, Inc. | Dynamic delay compensation for packet-based voice network |
US6775657B1 (en) | 1999-12-22 | 2004-08-10 | Cisco Technology, Inc. | Multilayered intrusion detection system and method |
US20020013858A1 (en) | 2000-02-09 | 2002-01-31 | Anderson Keith R. | ARP caching apparatus and method |
GB2362076A (en) | 2000-05-03 | 2001-11-07 | 3Com Corp | Network intrusion detector which detects pre-attack probes or scans |
WO2001086895A1 (en) | 2000-05-05 | 2001-11-15 | Thomson Licensing S.A. | Method for reducing the spread of computer viruses in an electronic mail network |
US7032023B1 (en) | 2000-05-16 | 2006-04-18 | America Online, Inc. | Throttling electronic communications from one or more senders |
WO2002003084A1 (en) | 2000-06-21 | 2002-01-10 | Netrake Corporation | Method for preventing denial of service attacks |
US6789203B1 (en) | 2000-06-26 | 2004-09-07 | Sun Microsystems, Inc. | Method and apparatus for preventing a denial of service (DOS) attack by selectively throttling TCP/IP requests |
GB2367714A (en) | 2000-07-07 | 2002-04-10 | Messagelabs Ltd | Monitoring e-mail traffic for viruses |
US7278159B2 (en) | 2000-09-07 | 2007-10-02 | Mazu Networks, Inc. | Coordinated thwarting of denial of service attacks |
GB2368163A (en) | 2000-09-11 | 2002-04-24 | Ibm | Web server apparatus for virus checking |
US6886099B1 (en) * | 2000-09-12 | 2005-04-26 | Networks Associates Technology, Inc. | Computer virus detection |
US6965777B1 (en) | 2000-11-16 | 2005-11-15 | Thomas Cast | Method of delivering short messages using a SMPP gateway with standard interface |
US20020073338A1 (en) * | 2000-11-22 | 2002-06-13 | Compaq Information Technologies Group, L.P. | Method and system for limiting the impact of undesirable behavior of computers on a shared data network |
WO2002045380A2 (en) | 2000-11-30 | 2002-06-06 | Lancope, Inc. | Flow-based detection of network intrusions |
US20020104024A1 (en) | 2001-01-29 | 2002-08-01 | Fujitsu Limited | Method for detecting and managing computer viruses in system for sending or receiving electronic mail |
GB2373130A (en) | 2001-03-05 | 2002-09-11 | Messagelabs Ltd | Method and system for processing e-mail to detect unsolicited bulk and/or commercial e-mail. |
US20020199109A1 (en) | 2001-06-25 | 2002-12-26 | Boom Douglas D. | System, method and computer program for the detection and restriction of the network activity of denial of service attack software |
US20030005081A1 (en) * | 2001-06-29 | 2003-01-02 | Hunt Preston J. | Method and apparatus for a passive network-based internet address caching system |
EP1280297A2 (en) | 2001-07-23 | 2003-01-29 | Primary Network, Inc. d/b/a Acme Packet, Inc. | System and method for determining flow quality statistics for real-time transport protocol data flows |
EP1280298A1 (en) | 2001-07-26 | 2003-01-29 | BRITISH TELECOMMUNICATIONS public limited company | Method and apparatus of detecting network activity |
US6941348B2 (en) | 2002-02-19 | 2005-09-06 | Postini, Inc. | Systems and methods for managing the transmission of electronic messages through active message date updating |
US7096498B2 (en) * | 2002-03-08 | 2006-08-22 | Cipher Trust, Inc. | Systems and methods for message threat management |
GB2391419A (en) | 2002-06-07 | 2004-02-04 | Hewlett Packard Co | Restricting the propagation of a virus within a network |
EP1369766A2 (en) | 2002-06-07 | 2003-12-10 | Hewlett-Packard Development Company, L.P. | Propogation of viruses through an information technology network |
GB2394382A (en) | 2002-10-19 | 2004-04-21 | Hewlett Packard Co | Monitoring the propagation of viruses through an Information Technology network |
GB2401280A (en) | 2003-04-29 | 2004-11-03 | Hewlett Packard Development Co | Propagation of viruses through an information technology network |
Non-Patent Citations (8)
Title |
---|
Chapman, D. B. et al., "Building Internet Firewalls: Chapter 6-Packet filtering," Building Internet Firewalls, 1995, pp. 131-188. |
European Search Report for EP 03 25 3538 dated Sep. 27, 2005. |
European Search Report for EP 03 25 6431 dated Sep. 27, 2005. |
Ganger, G.R. et al., "Better Security Via Smarter Devices," Proceedings Eighth Workshop on Hot Topics in Operating Systems IEEE Comput. Soc Los Alamitos, CA, USA, May 20, 2001, pp. 100-105. |
Johnson, C., Tarpitting with qmail-smtpd, Retrieved from the Internet [retrieved on Mar. 29, 2007], 1 page. |
Johnson, C., Tarpitting with qmail-smtpd, Retrieved from the Internet <http://web.archive.org/web/20021004000235/http://www.palomine.net/qmail/tarpit.html> [retrieved on Mar. 29, 2007], 1 page. |
Messmer, Ellen, "Behavior Blocking Repels New Viruses," Network World Fusion, 'Online! www.networkworld.com/news/2002/0128antivirus.html, Jan. 28, 2002. |
Williamson, Matthew M., "Throttling Viruses: Restricting Propagation to Defeat Malicious Mobile Code," HP Labs Technical Report, www.hp1.hp.com/techreports/2002/hp1-2002-172.html, Jun. 17, 2002. |
Also Published As
Publication number | Publication date |
---|---|
US20040103159A1 (en) | 2004-05-27 |
GB2391419A (en) | 2004-02-04 |
US20160028747A1 (en) | 2016-01-28 |
GB0213053D0 (en) | 2002-07-17 |
US9648038B2 (en) | 2017-05-09 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US9648038B2 (en) | Propagation of viruses through an information technology network | |
US8046624B2 (en) | Propagation of viruses through an information technology network | |
US7796515B2 (en) | Propagation of viruses through an information technology network | |
EP1757063B1 (en) | Methods and systems for computer security | |
US8478831B2 (en) | System, method and program to limit rate of transferring messages from suspected spammers | |
US8272060B2 (en) | Hash-based systems and methods for detecting and preventing transmission of polymorphic network worms and viruses | |
US7080408B1 (en) | Delayed-delivery quarantining of network communications having suspicious contents | |
CA2607005C (en) | Identifying threats in electronic messages | |
US7865965B2 (en) | Optimization of distributed anti-virus scanning | |
US7958557B2 (en) | Determining a source of malicious computer element in a computer network | |
US8601065B2 (en) | Method and apparatus for preventing outgoing spam e-mails by monitoring client interactions | |
US7373665B2 (en) | Propagation of viruses through an information technology network | |
US20060010209A1 (en) | Server for sending electronics messages | |
US7437758B2 (en) | Propagation of viruses through an information technology network | |
US20060265459A1 (en) | Systems and methods for managing the transmission of synchronous electronic messages | |
US9143524B2 (en) | Propagation of malicious code through an information technology network | |
EP1369766B1 (en) | Propogation of viruses through an information technology network | |
US20070083914A1 (en) | Propagation of malicious code through an information technology network |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AS | Assignment |
Owner name: HEWLETT-PACKARD DEVELOPMENT COMPANY, L.P., TEXAS Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:HEWLETT-PACKARD LIMITED (BRACKNELL, ENGLAND);BRAWN, JOHN MELVIN;REEL/FRAME:014963/0949;SIGNING DATES FROM 20040126 TO 20040127 Owner name: HEWLETT-PACKARD DEVELOPMENT COMPANY, L.P., TEXAS Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:HEWLETT-PACKARD LIMITED (BRACKNELL, ENGLAND);BRAWN, JOHN MELVIN;SIGNING DATES FROM 20040126 TO 20040127;REEL/FRAME:014963/0949 |
|
STCF | Information on status: patent grant |
Free format text: PATENTED CASE |
|
AS | Assignment |
Owner name: HEWLETT PACKARD ENTERPRISE DEVELOPMENT LP, TEXAS Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:HEWLETT-PACKARD DEVELOPMENT COMPANY, L.P.;REEL/FRAME:037079/0001 Effective date: 20151027 |
|
AS | Assignment |
Owner name: ENTIT SOFTWARE LLC, CALIFORNIA Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:HEWLETT PACKARD ENTERPRISE DEVELOPMENT LP;REEL/FRAME:042746/0130 Effective date: 20170405 |
|
AS | Assignment |
Owner name: JPMORGAN CHASE BANK, N.A., DELAWARE Free format text: SECURITY INTEREST;ASSIGNORS:ATTACHMATE CORPORATION;BORLAND SOFTWARE CORPORATION;NETIQ CORPORATION;AND OTHERS;REEL/FRAME:044183/0718 Effective date: 20170901 Owner name: JPMORGAN CHASE BANK, N.A., DELAWARE Free format text: SECURITY INTEREST;ASSIGNORS:ENTIT SOFTWARE LLC;ARCSIGHT, LLC;REEL/FRAME:044183/0577 Effective date: 20170901 |
|
MAFP | Maintenance fee payment |
Free format text: PAYMENT OF MAINTENANCE FEE, 4TH YEAR, LARGE ENTITY (ORIGINAL EVENT CODE: M1551); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY Year of fee payment: 4 |
|
AS | Assignment |
Owner name: MICRO FOCUS LLC, CALIFORNIA Free format text: CHANGE OF NAME;ASSIGNOR:ENTIT SOFTWARE LLC;REEL/FRAME:050004/0001 Effective date: 20190523 |
|
AS | Assignment |
Owner name: MICRO FOCUS LLC (F/K/A ENTIT SOFTWARE LLC), CALIFORNIA Free format text: RELEASE OF SECURITY INTEREST REEL/FRAME 044183/0577;ASSIGNOR:JPMORGAN CHASE BANK, N.A.;REEL/FRAME:063560/0001 Effective date: 20230131 Owner name: NETIQ CORPORATION, WASHINGTON Free format text: RELEASE OF SECURITY INTEREST REEL/FRAME 044183/0718;ASSIGNOR:JPMORGAN CHASE BANK, N.A.;REEL/FRAME:062746/0399 Effective date: 20230131 Owner name: MICRO FOCUS SOFTWARE INC. (F/K/A NOVELL, INC.), WASHINGTON Free format text: RELEASE OF SECURITY INTEREST REEL/FRAME 044183/0718;ASSIGNOR:JPMORGAN CHASE BANK, N.A.;REEL/FRAME:062746/0399 Effective date: 20230131 Owner name: ATTACHMATE CORPORATION, WASHINGTON Free format text: RELEASE OF SECURITY INTEREST REEL/FRAME 044183/0718;ASSIGNOR:JPMORGAN CHASE BANK, N.A.;REEL/FRAME:062746/0399 Effective date: 20230131 Owner name: SERENA SOFTWARE, INC, CALIFORNIA Free format text: RELEASE OF SECURITY INTEREST REEL/FRAME 044183/0718;ASSIGNOR:JPMORGAN CHASE BANK, N.A.;REEL/FRAME:062746/0399 Effective date: 20230131 Owner name: MICRO FOCUS (US), INC., MARYLAND Free format text: RELEASE OF SECURITY INTEREST REEL/FRAME 044183/0718;ASSIGNOR:JPMORGAN CHASE BANK, N.A.;REEL/FRAME:062746/0399 Effective date: 20230131 Owner name: BORLAND SOFTWARE CORPORATION, MARYLAND Free format text: RELEASE OF SECURITY INTEREST REEL/FRAME 044183/0718;ASSIGNOR:JPMORGAN CHASE BANK, N.A.;REEL/FRAME:062746/0399 Effective date: 20230131 Owner name: MICRO FOCUS LLC (F/K/A ENTIT SOFTWARE LLC), CALIFORNIA Free format text: RELEASE OF SECURITY INTEREST REEL/FRAME 044183/0718;ASSIGNOR:JPMORGAN CHASE BANK, N.A.;REEL/FRAME:062746/0399 Effective date: 20230131 |
|
MAFP | Maintenance fee payment |
Free format text: PAYMENT OF MAINTENANCE FEE, 8TH YEAR, LARGE ENTITY (ORIGINAL EVENT CODE: M1552); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY Year of fee payment: 8 |