US7424745B2 - Anti-virus fix for intermittently connected client computers - Google Patents

Abstract

A method and system is described for a wireless client computer to be connected via an access point to a network only if the wireless client computer has executed all requisite anti-virus programs. Where necessary, a signal from the access point notifies an anti-viral program server that an anti-virus needs to be immediately downloaded to the wireless client computer. An anti-virus fix is installed on the wireless client computer, and a full session is then initiated between the wireless client computer and a wireless network via the access point.

Description

BACKGROUND OF THE INVENTION

1. Technical Field

This invention relates generally to network computing systems that have one or more client computers. More particularly, the present invention relates to a method and system for selectively allowing a wireless computer onto a Wireless Local Area Network (WLAN) only if the wireless computer has installed and run specified anti-virus programs.

2. Description of the Related Art

While early computers were “stand alone” and unable to communicate with other computers, most computers today are able to communicate with other computers for a variety of purposes, including sharing data, e-mailing, downloading programs, coordinating operations, etc. This communication is achieved by logging onto a Local Area Network (LAN), a Wireless Local Area Network (WLAN), or a Wide Area Network (WAN). While this expanded horizon has obvious benefits, it comes at the cost of increased exposure to mischief, particularly from viruses.

A virus is programming code that, analogous to its biological counterpart, usually infects an otherwise healthy piece of code. The virus causes an undesirable event, such as causing the infected computer to work inefficiently, or else fail completely. Another insidious feature of many viruses is their ability to propagate onto other computers on the network.

The four main classes of viruses are file infectors, system (or boot-record) infectors, worms and macro viruses. A file infector attaches itself to a program file. When the program is loaded, the virus is loaded as well, allowing the virus to execute its mischief. A system infector infects a master boot record in a hard disk. Such infection will often make the hard drive inoperable upon a subsequent re-boot, making it impossible to boot-up the computer. A worm virus consumes memory or network bandwidth, thus causing a computer to be non-responsive. A macro virus is among the most common viruses, and infects word processor programs.

Another common type of virus is aimed at browers and e-mail. One such virus causes a Denial of Service (DoS) attack. A DoS virus causes a website to become unable to accept visitors. Usually, such attacks cause the buffer of the website to overflow, as a result of millions of infected computers being forced (unwittingly) to hit the website.

To counter viruses, anti-viral programs are written, and are constantly updated to be effective against new viruses. Such anti-viral programs are delivered either on physical media (such as CD-ROMs), or are downloaded off a network such as the Internet. Updates are typically downloaded as well, in order to provide rapid deployment of such updates. Such updates have problems and limitations, however. The most significant limitation is that such an update may not be downloadable if the client computer is already infected. That is, if the client computer has already been infected with a virus such as a system infector, then the computer will be completely unable to boot from its primary operating system, much less download an anti-viral program. Similarly, if the client computer is already infected with a worm virus, then the client computer will be non-responsive and unable to download the anti-viral program.

Another limitation is that the client computer is exposed to the network while downloading the anti-viral program. In the case of rapidly spreading viruses, this exposure can be critical, causing the client computer to be infected while looking for and/or downloading the necessary anti-viral program.

Another limitation is that downloading a software fix from an anti-viral program server requires user intervention or user action, such as accepting the download, selecting a drive and location to store the download, running the fix, often re-booting the computer after running the fix, et al. Many times the end user of the client computer will ignore a prompt or offer to download a fix, or will fail to manually perform an update check, thus leaving infected clients on a network, thus causing other client computers on the network to become infected.

Another limitation is that access to the network by a wireless client computer is permitted by the network's access point regardless of whether the wireless client computer has adequately installed and run the latest required version of anti-virus programs.

SUMMARY OF THE INVENTION

What is needed, therefore, is a method and system that permits a wireless client computer to receive a software fix such as an anti-viral program, even if the wireless client computer is already infected, and to have the fix automatically installed without requiring any end-user action. Preferably, such a method and system limits initial network communication to traffic that is between the wireless client computer and a pre-authorized anti-viral program server. Such a traffic limitation should be caused by allowing the wireless client computer to receive only a limited authentication from an access point, thus allowing the wireless client computer to only receive authorization to communicate with the pre-authorized anti-viral program server.

As will be seen, the foregoing invention satisfies the foregoing needs and accomplishes additional objectives. Briefly described, the present invention provides a method and system for limiting full access to a wireless access point to those wireless computers that have loaded and executed required anti-viral programs.

After determining that the wireless computer needs required anti-viral programs, the access point instructs an anti-virus (antidote) server to download the needed anti-viral programs or fixes. The anti-virus program and/or fix are installed on the wireless client computer, and a full session is then initiated between the wireless client computer and a wireless network via the access point.

Similarly, if a peer-to-peer session is requested between a first wireless computer and a second wireless computer, the two wireless computers interrogate each other to ensure that both have successfully executed any requisite anti-virus programs before initiating a peer-to-peer session.

BRIEF DESCRIPTION OF THE DRAWINGS

The novel features believed characteristic of the invention are set forth in the appended claims. The invention itself, however, as well as the preferred modes of use, further objects and advantages thereof, will best be understood by reference to the following detailed description of an illustrative embodiment when read in conjunction with the accompanying drawings, wherein:

FIG. 1 depicts a schematic diagram illustrating a computer network within which the present invention may be used;

FIG. 2 illustrates an exemplary client computer that needs an anti-virus;

FIG. 3 depicts an exemplary fix server that supplies the anti-virus to the client computer;

FIG. 4ais a flow-chart of steps taken to download the anti-virus using a primary operating system (OS) to reconfigure a Network Interface Card (NIC) driver, such that the NIC only communicates with the fix server, when the client computer is initially turned off;

FIG. 4bis a flow-chart of steps taken to download the anti-virus using the primary OS to reconfigure the NIC driver when the client computer is initially turned on;

FIG. 5ais a flow-chart of steps taken to download the anti-virus using a secondary OS to reconfigure the NIC driver when the client computer is initially turned off;

FIG. 5bis a flow-chart of steps taken to download the anti-virus using the secondary OS to reconfigure the NIC driver when the client computer is initially turned on;

FIG. 6ais a flow-chart of steps taken to download the anti-virus using a hardware Service Processor (SP) to reconfigure the NIC driver when the client computer is initially turned off;

FIG. 6bis a flow-chart of steps taken to download the anti-virus using the SP to reconfigure the NIC driver when the client computer is initially turned on;

FIG. 7ais a flow-chart of steps taken to download the anti-virus using a virtual machine (VM) and virtual machine monitor (VMM) to reconfigure the NIC driver when the client computer is initially turned off;

FIG. 7bis a flow-chart of steps taken to download the anti-virus using the VM and VMM to reconfigure the NIC driver when the client computer is initially turned on;

FIG. 8 is a system virtualization layer diagram showing the abstraction layers in a client running virtualization software which includes a virtual machine monitor;

FIG. 9 is a block diagram of an embodiment in which various functions ofFIGS. 4a-8 are performed in hardware;

FIG. 10 is a diagram of a Wireless Local Area Network (WLAN) in which the present invention is utilized;

FIG. 11 is a flow-chart of steps taken to connect a wireless client computer to the WLAN only after confirming that the wireless client computer has run all requisite anti-virus programs; and

FIG. 12 is a flow-chart of steps taken to connect a first wireless client computer to a second peer-to-peer client computer only after confirming that both wireless client computers have run all requisite anti-virus programs.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT

While the present invention will be described more fully hereinafter with reference to the accompanying drawings, in which a preferred embodiment of the present invention is shown, it is to be understood at the outset of the description which follows that persons of skill in the appropriate arts may modify the invention here described while still achieving the favorable results of this invention. Accordingly, the description which follows is to be understood as being a broad, teaching disclosure directed to persons of skill in the appropriate arts, and not as limiting upon the present invention.

Referring now to the drawing Figures, in which like numerals indicate like elements or steps throughout the several views, a preferred embodiment of the present invention will be described. In general, the present invention provides an improved method and system for configuring a network interface to selectively download anti-viruses from a trusted source by selectively configuring a client computer's Network Interface Card (NIC).

With reference now toFIG. 1, there is depicted an exemplary diagram of aclient computer102 coupled to asecure network104, which is coupled to afix server106. In an alternate embodiment, communication betweenclient computer102 and fixserver106 may be via an insecure network, such as theInternet108.

Fix server106 is capable of delivering (downloading) software fixes, such as patches, anti-viruses, etc. For purposes of clarity and simplicity, these software fixes will usually be referred to as “anti-viruses,” although it is understood to be within the scope of the present invention that any software fix used to correct a defect in software, including a virus, an outdated version, a “bug,” etc., is within the scope and vision of the present invention. Additional details ofclient computer102 and fixserver106 are given below.

With reference now toFIG. 2, additional detail ofclient computer102 is given. A Central Processing Unit (CPU)202 connects via a processor interface bus204 (also referred to in the art as a “front side bus,” “host bus,” or “system bus”) to aNorth Bridge206.North Bridge206 is a chip or chipset arbiter logic circuit having a memory controller207 connected to asystem memory212. Avideo controller228 is coupled toNorth Bridge206 and avideo display230 for viewing a graphical user interface of software operations being performed onclient computer102 byremote fix server106. Also connected toNorth Bridge206 is a highspeed interconnect bus208.North Bridge206 is connected viainterconnect bus208, which may be a Peripheral Component Interconnect (PCI) bus, to aSouth Bridge210.

South Bridge210 is a chip or chipset Input/Output (I/O) arbiter that includes the necessary interface logic to convey signals frominterconnect bus208 to (typically slower) I/O interfaces, including a Super I/O216. Super I/O216 is preferably a chip or chipset including necessary logic and interfaces for aparallel port218 and a non-USB (Universal Serial Bus)serial port220, as are understood in the art of computer architecture. Super I/O216 may also include controllers for non-USB devices such as akeyboard controller222 for a non-USB keyboard and an Enhanced Integrated Device Electronics (EIDE)port226, to which is connected to one or more Compact Disk-Read Only Memory (CD-ROM) drives234. Also connected to Super I/O216 is afloppy disk controller224.Floppy disk controller224 supports an interface with one or more floppy disk drives236.

Coupled withSouth Bridge210 is aUSB host controller213, which provides a USB interface from USB compliant devices (not shown) toclient computer102, includingCPU202. USB compliant devices may be floppy disk drives, CD-ROM drives, keyboards and other peripheral devices that are configured to comply with the “Universal Serial Bus Specification” release 2.0, Apr. 27, 2000 (USB.org), which release or later is herein incorporated by reference in its entirety.USB host controller213, which is likewise USB compliant, may be implemented in a combination of hardware, firmware and/or software.

Communication betweenclient computer102 and outside networks, such assecure network104 ornon-secure Internet108, is via a Network Interface Card (NIC)240, which is connected toSouth Bridge210 via interconnect (PCI)bus208. Alternatively,NIC240 is connected via asystem management bus242 to a Service Processor (SP)214, which is connected to interconnectbus208.SP214 is a specialized hardware processor that can be used to configure NIC drivers forNIC240, as described in greater detail below.

WithinSP214 is anagent238.Agent238 is a software program that performs a variety of tasks related to downloading anti-viruses, as described in further detail. Whileagent238 is depicted as being integral withSP214,agent238 may alternately be stored inmemory212 or any other storage area accessible toclient computer102, particularly ifclient computer102 does not have anSP214.

With reference now toFIG. 3, there is depicted a block diagram of anexemplary fix server106. A Central Processing Unit (CPU)302 connects via a processor interface bus304 (also referred to in the art as a “front side bus,” “host bus,” or “system bus”) to aNorth Bridge306.North Bridge306 has a memory controller307 connected to asystem memory312. Stored withinsystem memory312 arefixes332, which may be any type of software fixes, including anti-virus programs, program “patches,” program updates, etc. Also stored withinsystem memory312 is a fixed (i.e., “repaired,” “updated,” etc.)client list334, which contains a listing of all client computers under fix server's106 authority that have (or have not) received a fix stored and listed infixes332. Alternatively,fix server106 may broadcast an offer to receive and execute a fix to all client computers on a network, thereby ensuring higher client coverage.

Also connected toNorth Bridge306 is a highspeed interconnect bus308. Also connected toNorth Bridge306 is avideo controller328, which drives avideo display330.

North Bridge306 is connected viainterconnect bus308, which may be a Peripheral Component Interconnect (PCI) bus, to aSouth Bridge310.South Bridge310 includes the necessary interface logic to convey signals frominterconnect bus308 to a Super I/O316. Connected to Super I/O316 may be the types of peripherals described above with regard to Super I/O216 inFIG. 2. Connected to interconnectbus308 is a Network Interface Card (NIC)322, which provides an interface, via eithersecure network104 or theInternet108, withclient computer102.

Note that the exemplary embodiments shown inFIGS. 2 and 3 are provided solely for the purposes of explaining the invention and those skilled in the art will recognize that numerous variations are possible, both in form and function. All such variations are believed to be within the spirit and scope of the present invention.

Referring now toFIG. 4a, there is illustrated a flow-chart describing steps taken to download a fix such as an anti-virus. Proceeding frominitiator step402, a condition is assumed that the client computer is initially turned off (step404). The fix server then wakes up the client computer, preferably using a Wake On LAN (WOL) protocol, in which a “magic packet” (message which includes sixteen sequential iterations of the client computer's Media Access Control-MAC address) received at the client computer's NIC wakes up the client computer from a reduced power state. The fix server has checked the fixed client list, and “knows” that the client computer has not received the anti-virus. Alternatively, the fix server does not care if the contacted client computer has received the fix, and simply broadcasts the offer for the fix to any client on the network. Such a broadcast preferably uses a User Datagram Protocol (UDP) formatted datagram, thus providing a checksum to verify that the fix offer has been transmitted intact.

In the preferred embodiment, during the WOL operation the magic packet includes instructions to the client computer to apply a filter to the NIC drivers allowing the NIC to communicate only with the pre-authorized fix server (step406). The client computer then fully wakes up, and receives and applies (installs and runs) the anti-virus (step408). The client computer is then rebooted without the NIC driver filter, allowing theclient computer410 to communicate with any other resource on the network (block410), and the process is ended (terminator block412).

FIG. 4bdepicts steps taken that are similar to those described inFIG. 4a, except that the client computer is initially turned on (blocks414 and416). The fix server sends an anti-virus alert to client computer (block418). An agent stored in the client computer informs the user of the client computer that an imminent re-boot is about to occur, in order to force the downloading of an anti-virus (block420). The agent then disengages the client computer from the network (block422), permitting the NIC to communicate with only the fix server, as described above inFIG. 4a. The agent fetches the anti-virus (fix) from the fix computer and installs it (block424). The agent then re-boots the client computer, applying the changes prompted by the anti-virus fix (block426), and the client computer is put back on line with the entire network (blocks428 and430).

While the process described inFIGS. 4a-bis usually be effective, there may be occasions in which the primary OS has been corrupted to the point of being inoperable or non-responsive. The method depicted inFIGS. 5a-baddress this situation. Referring now toFIG. 5a, assume first that the client computer is initially turned off (blocks500 and502). The fix computer sends a Wake-on-LAN (WOL) packet to the client computer (block504). The packet includes instructions to the client computer to pre-boot from an alternate OS, if present, in the client computer, rather than the client computer's primary OS. (If an alternate OS is not present, then the client computer receives the fix as described inFIG. 4a.) This pre-boot operation identifies what anti-virus action is required (block506) according to the anti-virus sent in the packet from the fix server.

The pre-boot configures the pre-boot NIC driver to communicate only with the fix server (block508). The secondary OS's pre-boot fetches the anti-virus from the fix server, and stages fixes an installs changes (e.g., new drivers, flags, settings, etc.) in the primary OS (block510). That is, the pre-boot of the secondary OS repairs, the primary OS while the primary OS is inactive. The pre-boot of the secondary OS then reboots the primary OS (block512), and the primary OS completes available changes (new drivers, flags, settings, etc.) according to the anti-virus instructions (block514). The primary OS then fully boots up the client computer, including setting the NIC driver to allow unfettered communication with any computer on the network (blocks516 and518).

FIG. 5bdescribes a similar procedure as shown inFIG. 5a, except that the computer is initially turned on (blocks522 and524). Upon receipt of an anti-virus packet received from the fix server, the client computer's agent informs a user of the client computer that a re-boot is imminent (block526), allowing the user to shut down the computer, or else be aware that the client computer will automatically shut down (after saving data, settings, etc.). The client computer's agent program then reboots to the pre-boot of the secondary OS (block528). The pre-boot receives the anti-virus and identifies what action is required by the anti-viral instructions (block530).

The pre-boot configures the secondary OS to isolate the client computer from the network by resetting the NIC drivers in a manner that only the fix server can be contacted (block532). The NIC the fetches the anti-virus from the fix server, and makes appropriates staging and changes installation in the primary OS (block534). The pre-boot of the secondary OS then reboots in the primary OS (block536), the primary OS installs requisite changes, if necessary, according to the downloaded anti-virus (block538), and the agent then puts the client computer back on the full network by re-setting the NIC drivers (blocks540 and542).

The two methods above have a limitation that there may be occasions in which the primary and secondary OS are both corrupted by the virus. Such a situation is addressed by the process described inFIGS. 6a-b. Referring now toFIG. 6a, assume that the client computer is initially turned off (blocks600 and602). The fix server sends a packet including a fix (anti-virus) as well as WOL signal to the client computer. A service processor (SP) in the client computer, described above inFIG. 2, queries software and memory inclient computer102 to see if the client computer has already installed the sent anti-virus (block604). If not (query block606), completely isolates the client computer from the network (block608). The SP then boots the pre-boot of the primary OS with instructions pre-stored in the SP (block610), and identifies antiviral actions required by the instructions (block612).

The SP then resets the NIC drivers to communicate only with the fix server (block614). That is, the SP performs the NIC driver setting operation that was performed by the OS's described inFIGS. 4 and 5, but with the use of hardware only, which is impervious to viruses since it is isolated from viral attack. The pre-boot fetches and stages the anti-viral fixes (block616), and reboots the primary OS (block618). The primary OS installs the changes causes by the anti-virus (block620), and the client computer is put back on full line on the network by the SP (blocks622 and624).

FIG. 6baddresses a similar condition as addressed inFIG. 6a, but the client computer is initially running (blocks626 and628). If the agent in the client computer determines that the anti-virus being offered by the fix server has not been previously downloaded (query block630), then the agent informs the user of the client computer that a forced re-boot is imminent (block632). The SP totally isolates the client computer from the network by disabling the NIC (block634), and the SP reboots to pre-boot in the primary (or alternately in the secondary) OS.

The pre-boot in the OS identifies what antiviral action is required (block638), and then configures the NIC drivers to communicate only with the fix server (block640). The pre-boot fetches and stages the anti-virus (block642), and then re-boots in the primary OS (block644). The primary OS installs the changes causes by the anti-virus (block646), and the SP puts the client computer back on the full network (blocks646 and650).

In a preferred embodiment,client computer102 monitors, using any known system monitoring software and/or hardware, whetherclient computer102 can configure theNIC240 as described above using a primary OS, a secondary OS, or a Service Processor, such asSP214. That is, if theclient computer102 has anSP214, then the first choice is to useSP214 to configureNIC240 in a manner described inFIGS. 6a-b. Ifclient computer214 does not have anSP214, then theNIC240 is configured using a secondary (alternate) OS, as described inFIGS. 5a-b. Finally, if theclient computer214 does not have an alternate OS, then theNIC240 is configured as described inFIGS. 4a-b.

An embodiment of the invention with an even higher level of security can be implemented by utilizing the “virtual machine monitor” and associated “virtual machine” technologies referred to in the background section. This can be implemented by modifying the virtual machine monitor according to the example given below with reference toFIGS. 7aand7b. These modifications can be applied to currently available virtualization software executed byCPU202 out ofmemory212, such as the ESX Server software product by VMware Corp.

Additionally, for a higher level of security, support for virtualization can be built into any or all ofCPU202,North Bridge206, and Memory Controller207. For example, any of these components can be modified to physically block inter-memory access for different virtual machines, contain redundant hardware for virtualization purposes, and provide specialized access including encrypted access to hardware resources. Moreover, it is well known in the art that software components can be readily implemented as hardware and visa-versa. Accordingly, alternative embodiments can include portions of the virtual machine manager itself, which can be implemented in any or all ofCPU202,North Bridge206, and Memory Controller207.

Virtual machines and virtual machine monitors address the need to run applications written for different operating systems concurrently on a common hardware platform, or for the full utilization of available hardware resources. A Virtual Machine Monitor (VMM), sometimes referred to in the literature as a “hypervisor,” is a thin piece of software that runs directly on top of the hardware and virtualizes all the hardware resources of the machine. Since the virtual machine monitor's interface is the same as the hardware interface of the machine, an operating system cannot determine the presence of the VMM. Consequently, when the hardware interface is one-for-one compatible with the underlying hardware, the same operating system can run either on top of the virtual machine monitor or on top of the raw hardware. It is then possible to run multiple instances of operating systems or merely instances of operating system kernels if only a small subset of system resources are needed. Each instance is referred to as a virtual machine. The operating system can be replicated across virtual machines or distinctively different operating systems can be used for each virtual machine. In any case, the virtual machines are entirely autonomous and depend on the virtual machine monitor for access to the hardware resources such as hardware interrupts.

Referring now toFIG. 7aand assuming that the client computer is initially turned off (blocks700 and702). The fix server sends a packet including a fix (anti-virus) as well as WOL signal to the client computer. A virtual machine monitor (VMM), rather than theSP214 ofFIG. 2, can perform the functions described relative toagent238 in the client computer to query software and memory inclient computer102 to see if the client computer has already installed the sent anti-virus (block704). If not (query block706), the VMM then resets the NIC drivers to communicate only with the fix server and otherwise completely isolates the client computer from the network (block708). That is, the VMM performs the NIC driver setting operation that was performed by the OS's described inFIGS. 4 and 5, but with the use of the VMM and the main processor, both of which are impervious to viruses since they are isolated from viral attack. Moreover, any of the known methods of network isolation (block708) can be used including application of a filter or mask to any level of communication code ranging from the driver level all the way to the UDP or TCP/IP level or higher.

The VMM then initiates a virtual machine (VM) with instructions pre-stored in the VMM (block710), and identifies antiviral actions required by the instructions (block712). As an alternative to initiating a VM, the VMM can perpetually maintain an active VM just for this purpose and transfer control to the VM when corrective action is required. If the fixes are installable by the VM (or alternately the VMM) directly (decision block714), the VM fetches and directly installs the anti-viral fixes (block715), and the client computer is put back on full line on the network by the VMM (blocks722 and724). Otherwise, the VM fetches and stages the anti-viral fixes (block716), and reboots the primary OS (block718). The primary OS installs the changes causes by the anti-virus (block720), and the client computer is put back on full line on the network by the VMM (blocks722 and724).

FIG. 7baddresses a similar condition as addressed inFIG. 7a, but the client computer is initially running (blocks726 and728). If the VMM determines that the anti-virus being offered by the fix server has not been previously downloaded (query block730), then the VMM informs the user of the client computer that a forced re-boot is imminent (block732). The VMM then resets the NIC drivers to communicate only with the fix server and otherwise completely isolates the client computer from the network (block734), and the VMM invokes a VM or transfers control to a perpetual VM as described above.

The VM identifies what antiviral action is required (block738). If the fixes are directly installable by the VM (or the VMM) (decision block740), the VM fetches and directly installs the anti-viral fixes (block741), and the client computer is put back on full line on the network by the VMM (blocks748 and750). Otherwise, the VM fetches and stages the anti-virus (block742), and then re-boots in the primary OS (block744). The primary OS installs the changes caused by the anti-virus (block746), and the VMM puts the client computer back on the full network (blocks748 and750).

FIG. 8 is a system virtualization layer diagram showing the abstraction layers in a client running virtualization software which includes a virtual machine monitor. At the lowest level of abstraction is the hardware layer808; this is the physical hardware layer of the client machine. A Virtual Machine Monitor layer806 is an intermediary layer which sits on top of the hardware layer808 and intercepts all access attempts to the physical hardware by software running on the client machine. It is within the Virtual Machine Monitor layer806 that theAntidote Agent238 runs and is executed as part of the virtual machine monitor and as such has all the security and isolation features of the virtual machine monitor. At the highest level of abstraction lie the virtual machines802 and804 which ultimately run operating systems and software applications. Virtual machines can be configured so as to know not of the existence of other virtual machines; they can be isolated and autonomous as would be the case for virtual machine804 which executes the anti-virus instructions provided by and under the control of theAntidote Agent238 from the Virtual Machine Monitor layer806. Arrows810 indicate the isolation of the NIC to virtual machine802 during a virus fix operation while allowing VM Antidote machine804 to communicate only with the fix server as described above relative toFIGS. 7aand7b.

Using the VM Antidote Machine804 under the control of the Antidote Agent running as part of the virtual machine monitor in layer806 allows for the control and monitoring of all communications present in the client computer, including Modem, WAN, WLAN, Serial Port, USB and other ports. This embodiment is both immune from attack and utilizes theprimary CPU202 and the entire client computer for fix/patch management if desired.

In a preferred embodiment,client computer102 monitors, using any known system monitoring software and/or hardware, whetherclient computer102 can configure theNIC240 as described above using a primary OS, a secondary OS, a Service Processor, such asSP214, or a virtual machine manager. That is, if theclient computer102 has a virtual machine manager, then the first choice is to use the virtual machine manager to run the Antidote Agent in a manner described inFIGS. 7a-8. If client computer has anSP214, then the second choice is to useSP214 to configureNIC240 in a manner described inFIGS. 6a-b. Ifclient computer214 does not have anSP214, then theNIC240 is configured using a secondary (alternate) OS, as described inFIGS. 5a-b. Finally, if theclient computer214 does not have an alternate OS, then theNIC240 is configured as described inFIGS. 4a-b.

Embodiments of the present invention include various functions, which have been described above with reference toFIGS. 4a-8. The functions may be performed by hardware components or may be embodied in machine-executable instructions, which may be used to cause a general-purpose or special-purpose processor programmed with the instructions to perform the functions. Alternatively, the functions may be performed by a combination of hardware and software.

FIG. 9 is a block diagram of an embodiment in which various functions ofFIGS. 4a-8 are performed in hardware, and in particular, in the hardware associated withclient computer102 depicted inFIGS. 1-2. Fix detector902, Isolator904, Downloader906, Boot Strap908, Switch910, andNIC240 ofFIG. 2 are all coupled to the high speed interconnect (PCI)bus208. Fix detector902 discerns an offer for a software fix from a fix server as described with respect to any of the previously described embodiments. Isolator904 is responsible for controlling and isolatingNIC240 such that communication can only occur with the fix server upon a receipt of the offered software fix. Isolator904 can perform the isolation function according to any of the embodiments previously described. Downloader906 functions to effect the transfer of the software fix from the fix server to the client computer according to any of the above described embodiments. Boot strap908 reboots the client computer according to any previous embodiment after the software fix has been downloaded and executed. Isolator904 reconnects the client computer to the network without restrictions after the software fix is loaded and executed. Switch910 selects the best method according to availability of a primary OS, a secondary OS, a Service Processor, such asSP214, or a virtual machine manager as described above.

With reference now toFIG. 10, a diagram of an exemplary Wireless Local Area Network (LAN)1000 used by the present invention is depicted. Also depicted inFIG. 10 are numbered steps taken to permit awireless computer1002 to be accorded a full session with anetwork1008. As indicated byStep1, a request for access tonetwork1008 is sent from thewireless computer1002 to anaccess point1004, which is a wireless transceiver capable of communicating with and coupling wireless computers to a Wireless Local Area Network (WLAN). Theaccess point1004 then returns (Step2) a message that checks on the anti-virus status of thewireless computer1002. This checking message requests the wireless computer to send a status message indicating, preferably through the use of flags or other indicators, which anti-virus programs have been run in thewireless computer1002, including the version and date run. InStep3, thewireless computer1002 replies by sending this status message to theaccess point1004.

Theaccess point1004 has a list of requisite anti-viral programs that must be run by a wireless computer before that wireless computer is allowed to have a full session (unlimited access to) withnetwork1008. If the status message indicates to theaccess point1004 that not all of the requisite anti-viral programs have been run, then the access point sends an anti-virus request to an antidote server1010. This request, as indicated by Steps4a-c, is sent through anaccess switch1006 and thenetwork1008 to the antidote server1010. InStep5, the antidote server1010 sends the necessary anti-viral program(s) and/or anti-virus fix (program portion) to thewireless computer1002.

Next, as indicated inSteps6a, thewireless computer1002 initiates a full session with theaccess point1004, assuming that Steps1-3 have been re-run and theaccess point1004 has determined that all requisite anti-viral programs have been executed in thewireless computer1002. As shown inSteps6b-d, the session request is sent to anauthentication server1012, which derives with wireless computer1002 a key that is necessary for thewireless computer1002 andaccess point1004 to establish a full session, according to authentication protocols used byaccess point1004. These authentication protocols include, but are not limited to 801.1x, Extensible Authentication Protocol (EAP), and Cisco's® Wireless authentication protocol LEAP. Details of the protocol for 801.1x are found in IEEE's Network Working Group's RFC 3580, “RFC 3580—IEEE 802.1X Remote Authentication Dial In User Service (RADIUS) Usage Guidelines,” which is herein incorporated by reference in its entirety. Details of the protocol for EAP are found in IEEE's Network Working Group's RFC 2284, “RFC2284—PPP Extensible Authentication Protocol (EAP), which is herein incorporated by reference in its entirety. Details of the protocol for LEAP are found in the white paper titled “Cisco SAFE: Wireless LAN Security in Depth,” authored by Convery et al. and published by Cisco Systems, Inc., and herein incorporated by reference in its entirety.

Referring now toFIG. 11, a flow-chart of steps shown inFIG. 10 is given. Afterinitiator block1102, a request is sent from the wireless computer to the access point requesting a session (block1104). The access point, which preferably contains a listing of the requisite anti-viral programs that must be run before a session is allowed, queries the wireless computer to determine if the requisite anti-viral programs have been run (block1106). If the requisite anti-viral programs have not been run (query block1108), then the necessary anti-viral programs or anti-virus fixes are downloaded from the antidote server to the wireless computer (block1110). Otherwise, a Wired Equivalent Privacy (WEP) key, as required by EAP, is derived between the wireless computer and the authentication server (block1112), and the wireless computer initiates a full access session with the access point and connected network (block1114), thus ending the process (terminator block1116).

As suggested by the dashed line inFIG. 10, thewireless computer1002 may also establish a communication session directly with another wireless computer (shown as peer-to-peer wireless computer1014) using a peer-to-peer session, thus avoidingaccess point1004. Care must be taken to ensure that such sessions do not result in one wireless computer infecting another wireless computer. To address this concern, reference is now made to the steps depicted inFIG. 12.

Afterinitiator block1202, a request is sent from a first wireless computer to a second peer-to-peer computer requesting a communication session (block1204). Both computers query each other about their respective anti-virus status (block1206), as described above between thewireless computer1002 and theaccess point1004. If either wireless computer has not run the requisite anti-viral programs (query block1208), then the necessary anti-viral programs and/or fixes are downloaded from the antidote server to the wireless computer needing the update (block1210). Otherwise, the two wireless computers are directly wirelessly coupled in an ad hoc (peer-to-peer) format (block1212), and the process ends (terminator block1214). Note that in such a peer-to-peer scheme, at least one of the wireless computers must know which anti-viral programs are required. Thus, in a preferred embodiment, one of the wireless computers must first establish a session with the access point, in a manner described above, before establishing a peer-to-peer connection.

An embodiment of the present invention may be provided as a computer program product which may include a machine-readable medium having stored thereon instructions which may be used to program a computer (or other electronic devices) to perform a process according to the any of the embodiments of the present invention. The machine-readable medium may include, but is not limited to, floppy diskettes, optical disks, CD-ROMs, and magneto-optical disks, ROMs, RAMs, EPROMs, EEPROMs, magnet or optical cards, or other type of media \ machine-readable medium suitable for storing electronic instructions. Moreover, an embodiment of the present invention may also be downloaded as a computer program product, wherein the program may be transferred from a remote computer to a requesting computer by way of data signals embodied in a carrier wave or other propagation medium via a communication link (e.g., a modem or network connection).

The present invention has been described in relation to particular embodiments that are intended in all respects to be illustrative rather than restrictive. For example, while the present invention has been described as connecting a wireless computer to a WLAN, the present invention may be utilized in any analogous system in which client computers are likewise intermittently connected to a network. Alternative embodiments will become apparent to those skilled in the art to which the present invention pertains without departing from its spirit and scope. Accordingly, the scope of the present invention is defined by the appended claims rather than the foregoing discussion.

Claims (2)

1. A method comprising:

sending a request for a peer-to-peer communication session directly from a first wireless computer to a second wireless computer;

transmitting a status check from the first wireless computer to the second wireless computer to determine an anti-virus status on the second wireless computer, wherein the anti-virus status is determined by an execution of all requisite anti-virus programs;

transmitting a status check from the second wireless computer to the first wireless computer to determine the anti-virus status on the first wireless computer; and

establishing the peer-to-peer communication session between the first and second wireless computers only if both wireless computers have executed all of the requisite anti-virus programs.

2. The method ofclaim 1, further comprising:

in response to both wireless computers not having executed all of the requisite anti-virus programs, downloading an antidote fix from an antidote server to each wireless computer that has not executed all of the requisite anti-virus programs, wherein the antidote fix contains all software needed by the wireless computers to complete an execution of all of the requisite anti-virus programs.

Images