The present invention relates to the propagation of viruses through a network of interconnected processing entities.
In current network environments virtually any processing entity (or “host”) is at one time or another connected to one or more other hosts. Thus for example in the case of an information technology (IT) environment, a host in the form of a computer (such as a client, a server, a router, or even a printer for example) is frequently connected to one or more other computers, whether within an intranet of a commercial organisation, or as part of the Internet. Alternatively, in the case of a communications technology environment, 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. For example in the case of a computer virus known as the “Code Red” 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. Although not all of 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.
Within the context of this specification 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. Thus for example, 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. In addition 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. Alternatively 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. In yet a further alternative scenario, 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.
It has been established that in situations where viruses are likely to cause deleterious effects upon either one or more hosts, or the network infrastructure as a whole, one of the most important parameters in attempting to limit and then to reverse such effects is the speed of propagation of a virus. Human responses to events are typically one or more orders of magnitude slower than the propagation speeds of viruses, and so substantial difficulties are frequently apt to arise within a network before any human network administrator is either aware of the problem, or capable of doing anything to remedy it. Therefore any reduction in the initial rate of propagation of a virus through a network is likely to be of benefit to attempts to limit any negative effects, and/or to remedy them.
One existing and relatively popular approach to tackling the problems of virus propagation within a network may be thought of as an absolutist approach. 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.
According to one aspect of the invention, 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.
Preferably 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.
After updating, 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.
Preferably, upon receipt of a request to send data to a destination host, 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.
Preferably a signal is generated in response to an indication that the rate of increase of the buffer record exceeds a threshold value.
Preferably, 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.
Preferably, there is a determination of whether 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.
Preferably requests to contact hosts not in the record are diverted to a delay buffer. At the end of the first time interval, the predetermined number of requests is transmitted from the delay buffer.
Preferably 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.
Preferably 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.
Preferably 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.
Preferably 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.
The above and still further objects, features and advantages of the present invention will become apparent upon consideration of the following detailed description of one specific embodiment thereof, especially when taken in conjunction with the accompanying drawings.
Referring now to
In the illustrated examples, the process of establishing a connection in accordance with HTTP will be considered. Usually 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. Where this is the case, 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). Ultimately however 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. 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.
In the context of the present document it should be appreciated that the term “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. One application protocol which operates using connections is HTTP, and an example of the establishment of a connection in accordance with HTTP will now be described with reference to
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. In
When the outgoing payload is to be transmitted, the TCP layer breaks it up into packets (i.e. data structures such as those illustrated above in
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.
Referring now to
Thus far all that has been described is entirely conventional.
Referring now to
In the present example 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 Tn. In any given time window Tn 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.
Referring to
The VPMS, a computer program in entity 10, operates in accordance with the flow diagram illustrated in
At this point, 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). This is a step whose occurrence is entirely outside the control of the VPMS since it usually is initiated at the behest of an application program, as is the case with Requests A, B and C. Each of these requests passes, to the VPMS, through the relevant application protocol layer in the network stack from the respective application program by which they were generated, this event is labelled in
During the second time interval T2, three further outbound requests are received, identifying host destinations “Intranet Peer 1” (Request D), Request B (described above) and “Intranet Peer 2” (Request E). As in the previous time window, as each request triggers an individual VPMS routine for that request, i.e. a step 706 as it passes through the VPMS, and is followed by the step 708 of matching the identity of the host destination in the request with the identities present in the dispatch record 612 for this time window, T2 is performed in order to establish whether the request is new. The dispatch record however is now a genuine record of the identities of the three hosts contacted most recently during the previous time window T1 (although coincidentally this is identical to the default dispatch record). Upon receipt of Request D, the consequently triggered VPMS program for that request establishes at step 708 that the identity of this host is not in the dispatch record 612, i.e. that it is a new destination host. The program therefore proceeds to step 712 and then ends at 710. In step 712 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
Because receipt of requests is the trigger for the commencement of the program illustrated in
At the end of the time window T2, the virtual buffer of VPMS program 500 contains two new requests. At this juncture (i.e. at end of time period T2), the policy which the VPMS is designed to monitor comes into play. In the present example, 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
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, illustrated in
A situation in which the second buffer management routine generates a viral infection warning is seen in
In the event that a viral warning is generated, various further actions can then be taken, the majority of which are directed toward finding out more about the nature of any possible virus. Specifically 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. For example in the case of one preferred embodiment in which the virtual buffer simply copies the socket, including payload, 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. Additionally, where 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), then 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. Depending upon the extent of the data collected, 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. However, because 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.
In an alternative embodiment, the network stack additionally includes a layer 502 (illustrated in
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.
In the scenario illustrated in connection with
In a modification of the embodiment thus far described therefore, 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. Once the identities of the genuine or ultimate addressees have been obtained, there are several options for processing the request. In accordance with one alternative, 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
In the case for example of email, it is the norm for the outbound carrier requests be sent to a host that acts as a proxy for the ultimate addressees of the email messages. Consequently a modification enables different versions of VPMS to run simultaneously, (effectively operating in parallel with each other). One version applies to hosts specified in the outbound request (including carrier requests), and another version applies to hosts specified in any sub-requests identified by the email application program. In such a situation, 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
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
In a further embodiment, 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
Referring now to
The workstation 910 runs a plurality of Application software programs concurrently. Workstation 910, as described in connection with
As with the VPMS, 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. As mentioned previously in connection with the VPMS, in many networks, normal network traffic (i.e. non-virally related) is characterised by a relatively low rate of connection to hosts within the network which have previously not been contacted. In contrast, virally-related traffic is frequently characterised by a relatively high rate of connection, or attempted connection to previously uncontacted hosts. Broadly speaking, the function of the VAPS is to impede virally-related traffic, while allowing non-virally related traffic to flow with little or no impediment. In the present example 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 Tn. In any given time window Tn 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.
Referring to
These requests are processed in accordance with an incoming request routine, forming part of the VAPS;
During the course of the second time interval T2, 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. As in the previous time window, as each request passes to the VAPS, and as previously indicated in step 1104, the identity of the host destination in the request is matched with the identities present in the dispatch record 1012. 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 T1 (although coincidentally this is identical to the default dispatch record). 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
Thus, at the end of the time period T2, no requests to new destination hosts have been transmitted, and the delay buffer contains two entries. At this juncture (i.e. at end of time period T2), the policy which the VAPS is designed to perform comes into play. In the present example, the policy is that a single new host can be contacted per time interval. This element of the policy is performed by VAPS including a first buffer management program, which is illustrated schematically in flowchart form in
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. Given that the buffer is effectively a queue of new requests waiting to be transmitted, 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. In addition, 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
A situation in which the second buffer management routine generates a viral infection warning can be seen by considering time intervals T3 and T4 of
In the example described above 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. In addition, delaying outbound requests for connection is generally regarded as being compatible with the operation of many computer systems and networks. However, 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. In this alternative embodiment, 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).
In the present example, 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”.
In a similar way to that described in connection with the first embodiment, 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. As previously, in such a situation therefore, if 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.
As with the first embodiment, in a modification of the second embodiment thus far described, 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. Once the identities of the genuine or ultimate addressees have been obtained, there are several options for processing the request. In accordance with one alternative 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
Since in the case for example of email, the use of outbound carrier requests to a host acting as a proxy for the ultimate addressees of the email messages is the norm, it is, in a modification, possible for different versions of VAPS to run simultaneously, effectively operating in parallel with each other; one VAPS version applies to hosts specified in the outbound request (including carrier requests), and another which applies to hosts specified in any sub-requests identified by the email application program. In such a situation, each VAPS operates independently, using its own dispatch record, and performing 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
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
An example of such a policy is illustrated in
The flow diagram of
If 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. Thus, 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 Sl, where the activity level is relatively high, but in the previous short time interval activity was zero. Correspondingly, in any time window where there were more than 10 new requests (i.e. a greater level of activity than usual in a longer time interval) or where, in the previous time window there were more than zero new requests (which is the pattern of legitimate traffic flow illustrated in
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 Sl) 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
Yet a further and more refined version of this policy employs a modified version of the program of
The operation of the 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.
The use of a number of different 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.
For instance, a transient increase in the size of the delay buffer can provide an indication of viral activity. In other words, 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.
This can be measured as an instantaneous value, or over a single time interval, or over a plurality of time intervals.
Alternatively, 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. For instance, 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”. In some circumstances, 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.
In the first slack parameter procedure 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). In the second slack procedure, the slack is incremented for every predetermined time interval or period during which the delay queue (e.g. the buffer) is empty. In both procedures, the slack value is incremented up to some predetermined maximum value (“maxslack”).
The value of the slack parameter is decremented by each new request that VAPS allows, down to a minimum value (e.g. minslack=0). If the slack value is at the minimum, then any further new requests are treated in the normal manner (e.g. as potentially indicative of viral infection, or delayed).
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.
Instead of measuring the time period since the last new request, preferably slack is only incremented every time a time interval expires and the delay buffer is empty.
A similar parameter, analogous to the above-mentioned slack parameter, can be used for methods associated with emails e.g. for restricting propagation of viruses via emails.
Both 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.
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.
As a solution to this, in addition to the previously described VAPSN/VPMS for single recipient emails, a different process is used for multiple recipient emails. The different process uses a new parameter, termed herein “mSLACK,” which has a value between zero and “maxMSLACK” (i.e., 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. Preferably, a VAPS or VPMS is provided for each email client e.g. per host machine or per email user.
Normally, 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.
If 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.
Once an email has been generated by a user, 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.
If VAPS determines during step 1510 that the email is to be sent to multiple recipients, then VAPS determines the value of the parameter mSLACK (step 1512). 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.
In the first procedure 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). In the second procedure, 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: However, 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.
By utilising such a parameter, small dispatch records can be utilised without unduly delaying multiple recipient emails.
Typically, in all email arrangements, it will be desirable to provide two thresholds on the buffer to trigger other activities. When the buffer size reaches a predetermined first threshold, 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.
If the size of the buffer exceeds the second, high threshold, then outgoing emails from the host are stopped. Preferably, 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.
Alternatively, if the technique is being implemented within an email server, 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).
It will be appreciated from the above description that the performance of 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.
However, the present inventors have appreciated that in some circumstances, it can be advisable to vary the parameters.
For instance, 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).
If desired, 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.
It is conceivable that some viruses might attempt to spread whilst remaining undetected or relatively un-impeded by operating at levels (i.e. sending new requests) just less than that would be detectable or throttled. In order to fool such viral attacks that attempt to “ride the threshold”, the parameters can be changed randomly by small amounts. Alternatively, the parameters can be pulsed between parameters that provide a severe operating regime and those that provide a more relaxed operating regime.
Regardless of whether or not the parameters are varied as a function time, it is desirable to be able to determine parameters that effectively detect or limit the propagation of viruses within a network. 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.
All of the features disclosed in this specification (including any accompanying claims, abstract and drawings), and/or all of the steps of any method or process so disclosed, can be combined in any combination, except combinations where at least some of such features and/or steps are mutually exclusive.
Each feature disclosed in this specification (including any accompanying claims, abstract and drawings) can be replaced by alternative features serving the same, equivalent or similar purpose, unless expressly stated otherwise. Thus, unless expressly stated otherwise, each feature disclosed is one example only of a generic series of equivalent or similar features.
Number | Date | Country | Kind |
---|---|---|---|
0213053.2 | Jun 2002 | GB | national |
0224396.2 | Oct 2002 | GB | national |
0309844.9 | Apr 2003 | GB | national |
Number | Date | Country | |
---|---|---|---|
Parent | 10457091 | Jun 2003 | US |
Child | 14725080 | US |