Patent Application
20110066841
1. Field of the Invention
Generally, the invention relates to management of enterprise-scale networks of computational devices. More particularly, the invention relates to a Platform for a policy-driven communication and management infrastructure.
2. Background Discussion
Information technology (IT) administrators in enterprises everywhere face a daunting task of managing the software and hardware on tens, hundreds, or thousands of machines in their domains. With many incompatibilities, patches, and policy advisories being announced every day, the management task involves much more than just acquisition and installation of updates and patches, for example. Simply keeping aware of all potentially problematic situations on hardware and software products used in an enterprise is more than a full-time job. Dealing with user requests and complaints adds still further to the demands of the job. Thus, it is required that IT managers be able to anticipate situations which may arise in a specific enterprise and address them proactively. Maintaining such a state of readiness may require an IT manager to understand the configuration of the hardware and software in a given network, to keep track of policy advisories, updates, incompatibilities and patches relevant to the specific enterprise, and to match those policy advisories, updates, and patches with the specific equipment in the enterprise. In a large enterprise, such management tasks involve monitoring of and policy dissemination to, perhaps, hundreds of thousands of computational devices by an administrator. Conventionally, management Platforms in such large enterprises employ a communication infrastructure that is conducive mainly to coarse-grained, one-to-many interaction, typically involving large numbers of devices, occasionally even the entire network rather than a fine-grained, per-endpoint policy determination.
A policy-driven communication and management infrastructure may include components such as Agent, Server and Console, policy messages, and Relays to deliver security and system management to networked devices. An Agent resides on a Client, acting as a universal policy engine for delivering multiple management services. Relays are Clients additionally configured to each behave as though they were a proxy for the root Server, Relaying information to and from other Clients, permitting Clients to interact with the root Server through the Relay, and facilitating information exchange between Client and Server. Such information exchange allows Clients to gather information, such as new policy messages, from the Server, to pass status messages to the Server and to register their network address so that they can be readily located. Automatic Relay selection enables Clients and Relays to select their own parent Relays, thus allowing Clients and Relays to discover routing paths through the existing network without administrator input.
A policy-driven communication and management infrastructure may include components such as Agent, Server and Console, policy messages, and Relays to deliver security and system management to networked devices. An Agent resides on a Client, acting as a universal policy engine for delivering multiple management services. Relays, Clients additionally configured to each behave as though they were a root Server, Relaying information to and from other Clients, permit Clients to interact with the root Server through the Relay, enabling information exchange between Client and Server. Such information exchange allows Clients to gather information, such as new policy messages, from the Server, to pass status messages to the Server and to register their network address so that they can be readily located. Automatic Relay selection enables Clients and Relays to select their own parent Relays, thus allowing Clients and Relays to discover new routing paths through the network without manual administrator input.
Action: actions are typically scripts that can customize a specific solution for each Client, using a series of scripting commands and Relevance expressions. Although the Relevance language itself can't alter a Client, it can be used to direct actions in a way that parallels the original trigger. For instance, a Fixlet might use the Relevance language to inspect a file in the system folder. Using a similar Relevance clause, the Action can then target that same file without knowing explicitly where that folder resides. This allows the Action author (and issuer) to concentrate on the issue at hand without worrying about the vagaries of each individual computer system. AKA “ActionScript”.
ActionID: a unique identifier for an Action
Agent: Software that resides on Client and acts as a universal policy engine capable of delivering multiple management services. A single Agent can execute a diverse and extensible array of management services ranging from real-time Client status reporting, to patch and software distribution, to security policy enforcement. By assigning responsibility for reporting and management actions to endpoints themselves, the Platform enables visibility and management of IT infrastructures ranging from hundreds to hundreds of thousands of desktop, mobile and Server computers.
Client: an endpoint device in a network under management by a Platform for policy-driven communication and management infrastructure.
Console: an operations control center for administrators, which connects to the Server, that includes graphical displays of device, group, and enterprise-wide device status and dashboards for executing management actions through the infrastructure. The Console also includes reporting functions and templates that enable graphical and tabular views of infrastructure status.
Dashboard: Dashboard documents pop up in the main window of the Console when selected from a ‘Dashboards’ icon in a Domain Panel navigation tree. Dashboards tap into the Platform Database to provide the Operator with timely and compact high-level views of the network and allow an administrator to take action based on those views.
Download Request: In an embodiment, a download request may include a hash and a size that uniquely identify the file being requested, along with the information on how to retrieve the file. If a Client wants multiple files for an Action, it submits a set of DownLoadRequests in one interaction with the Relay. Although the interaction is batched, each request is handled individually by both Relays and the Server.
Dynamic Download aka “Client-initiated Download”: In an embodiment, a download whose hash, size and URL are not known at the time an Action is issued. Instead, the Client determines this information and then provides it to the Server, which fetches the file for the Client.
FileID: A FileID is a pair combination of (SHA-1, file size (bytes)) used to uniquely identify a file
Fixlet or Fixlet message: Instructions disseminated to the Agent to perform a management or reporting Action. Fixlet messages can be programmed to target specific groups of devices to perform management actions.
Hash-based Download: In an embodiment, a download that is requested or referred to by a “HashSizePair”. In an embodiment, this type of download is requested by a Client using a “DownloadRequest” plug-in, rather than the magic URLs that index-based downloads rely on. A hash-based download can be either static or dynamic.
Index-based Download aka “Legacy Download”: In an embodiment, a download that is referred to by a Client using an ActionID/Index pair, where the index is generated at the time the Action is issued. In an embodiment, an “indexed download” is a species of static download, because it is difficult to accommodate in the indexing strategy the case where the index is unknown at the time an Action is created. In an embodiment, indexed downloads can be requested without providing a hash, in which case the download represents whatever the URL happens to contain at the time an Action is created.
Relay: A Relay is a software module that executes as a shared service on non-dedicated hardware. Alternatively, “Relay” can refer to the hardware on which Relay software is running. Relays act as concentration points for Fixlet messages on network infrastructures and help reduce network bandwidth requirements for distribution of Fixlets and content such as software, patches, updates, and other information. Relays also offer a failover mechanism to keep managed Clients in touch with the Console should normal communications channels go dark or become overloaded with other traffic.
Server: Software that provides a control center and repository for managed system configuration data, software updates and patches, and other management information. In the alternative, “Server” can denote a computing machine running such software within a network under management.
Site: Sites are collections of Fixlet messages and other content to which an Operator of a Platform deployment may subscribe one or more Clients in the Operator's network. Sites may be created by the Platform manufacturer or by one or more third parties. Additionally, deployment Operators may create custom sites that contain internally generated content. Furthermore, the Operator may create sites, Integrations, which integrate internally- and externally-sourced content.
Static Download aka “Server-initiated Download”: In an embodiment, a download requested by the Console at the time an Action is taking place.
Referring now to
The computer system 100 includes a processor 102, a main memory 104 and a static memory 106, which communicate with each other via a bus 108. The computer system 100 may further include a display unit 110, for example, a liquid crystal display (LCD) or a cathode ray tube (CRT). The computer system 100 also includes an alphanumeric input device 112, for example, a keyboard; a cursor control device 114, for example, a mouse; a disk drive unit 116, a signal generation device 118, for example, a speaker, and a network interface device 128.
The disk drive unit 116 includes a machine-readable medium 124 on which is stored a set of executable instructions, i.e. software, 126 embodying any one, or all, of the methodologies described herein below. The software 126 is also shown to reside, completely or at least partially, within the main memory 104 and/or within the processor 102. The software 126 may further be transmitted or received over a network 130 by means of a network interface device 128.
In contrast to the system 100 discussed above, a different embodiment of the invention uses logic circuitry instead of computer-executed instructions to implement processing offers. Depending upon the particular requirements of the application in the areas of speed, expense, tooling costs, and the like, this logic may be implemented by constructing an application-specific integrated circuit (ASIC) having thousands of tiny integrated transistors. Such an ASIC may be implemented with CMOS (complimentary metal oxide semiconductor), TTL (transistor-transistor logic), VLSI (very large scale integration), or another suitable construction. Other alternatives include a digital signal processing chip (DSP), discrete circuitry (such as resistors, capacitors, diodes, inductors, and transistors), field programmable gate array (FPGA), programmable logic array (PLA), programmable logic device (PLD), and the like. It is to be understood that embodiments of this invention may be used as or to support software programs executed upon some form of processing core (such as the Central Processing Unit of a computer) or otherwise implemented or realized upon or within a machine or computer readable medium. A machine-readable medium includes any mechanism for storing or transmitting information in a form readable by a machine, e.g. a computer. For example, a machine readable medium includes read-only memory (ROM); random access memory (RAM); magnetic disk storage media; optical storage media; flash memory devices; electrical, optical, acoustical or other form of propagated signals, for example, carrier waves, infrared signals, digital signals, etc.; or any other type of media suitable for storing or transmitting information.
Referring now to
Key components of the Platform include the Agent 202, the Server and Console 204, the Fixlet messages, and the Relays 206, 208. The Platform creates a lightweight communications and management infrastructure for delivery of security and system management services to networked desktop, laptop/notebook and Server computers. By assigning responsibility for reporting and management actions on endpoints themselves, the Platform enables visibility and management of IT infrastructures ranging from hundreds to hundreds of thousands of desktop, mobile and Server computers.
The Agent 202 resides on managed devices and acts as a universal policy engine capable of delivering multiple management services. A single Agent 202 can execute a diverse and extensible array of management services that range from real-time Client status reporting, to patch and software distribution, to security policy enforcement.
The Agent's role in the Platform may be described as that of a Policy Engine: a piece of software and a computational context for evaluating content. Thus, the Agent constitutes a computational resource that uses one or more inspectors to examine its context, decide what is relevant, report properties, take Action in that environment, and report on the success or failure of the actions. Thus, the Agent gives an administrator visibility into the context and controls it. The motivation for provision of a policy engine thus may be the realization that any computing resource, including physical or virtual machines, or a machine, that is a delegate for another machine or a piece of hardware can benefit from management by having a policy engine that can inspect properties of the entity that is being managed, apply changes to the environment and report on the fact that those changes were effective or not.
The Agent also automatically notifies the Server and Console 204 of changes in managed device configuration, providing a real-time view of device status. In addition to a standard array of management services, customers and developers can create custom policies and services using a published authoring language. In various embodiments, the Agent runs on all versions of the MICROSOFT WINDOWS (Microsoft Corporation, Redmond Wash.) operating system since WINDOWS 95, UNIX, LINUX and MAC OS (APPLE COMPUTER, INC., Cupertino Calif.) operating systems, as well WINDOW MOBILE and POINT-OF-SALE variants of the Windows operating system, enabling administrators to consolidate management of heterogeneous infrastructures from the Console.
The invention herein extends the notion of an Agent beyond a computer to devices or logical structures, such as proxy-agents (also referred to as pseudo-agents), that are physically or logically proximate to a computer, and that are used to give visibility and control of assets that cannot, for technical or policy reasons, have a native agent installed. Proxy-agents are disclosed, for example, in co-assigned patent application to Lippincott, L. E., et al, Pseudo-Agents, U.S. patent application Ser. No. 12/044,614 (filed Mar. 7, 2008), and is incorporated herein in its entirety by this reference thereto.
Proxy-agents can be understood by reference to
Another important variant is a proxy-agent that indirectly manages a set of devices by way of one or more other management systems. The example shown in
The Server 204 is a software-based package that provides a control center and repository for managed system configuration data, software updates and patches, and other management information. In an embodiment, the Console 204, which runs from the Server 204, provides an operations control center for administrators that includes graphical displays of device, group, and enterprise-wide device status and dashboards for executing management actions through the management infrastructure. The Console may also include reporting functions and templates that enable graphical and tabular views on infrastructure status.
Fixlet messages are instructions to the Agent 202 to perform a management or reporting Action. Fixlet messages can be programmed to target specific groups of devices to perform management actions. As noted above, in an embodiment, users have the option of writing custom Fixlet messages.
Relays 206, 208 act as concentration points for Fixlet messages on network infrastructures. Relays are a software module that execute as a shared service on non-dedicated hardware. Relays help reduce network bandwidth requirements for distribution of Fixlets and content such as software, patches, updates, and other information. In an embodiment, Relays 206, 208 include a failover mechanism to keep managed Clients in touch with the Console should normal communications channels go dark or become overloaded with other traffic. In an embodiment, Relays allow an N-tier hierarchy to be created for the transmission of information from the Clients to the Server in the enterprise.
In an embodiment, Relays are included as network components to significantly improve the performance of an installation. Downloads and patches, which are often large files, represent, by far the greatest fraction of bandwidth. Relays are designed to take over the bulk of the download burden from the Server. Rather than downloading patches directly from a Server, Clients can instead be instructed to download from designated Relays, significantly reducing both Server load and network traffic. Relays help in the upstream direction as well, compiling and compressing data received from the Clients before passing it on the Server. As above, any Client can be programmed to serve as a Relay.
Relays simultaneously mitigate at least two bottlenecks:
Relieving the Load on Servers
The Server has many duties, among them, the taxing job of distributing patches and other files. A Relay can be set up to ease this burden, so that the Server does not need to distribute the same files to every Client. Instead, the file is sent once to the Relay, which in turn distributes it to other Clients. The overhead on the Server is reduced by the ratio of Relays to Clients. If one has a hundred Clients and one Relay, the Server need only process one percent of the downloads.
Reducing Congestion on Low-Bandwidth Connections If, for example, one has a Server communicating with a dozen computers in a remote office over a slow VPN (virtual private network), one of those computers may be designated as a Relay. Then, instead of sending patches over the VPN to every Client independently, the Server need only send a single copy to the Relay. That Relay, in turn, distributes the file to the other computers in the remote office over its own fast LAN (local area network). This effectively removes the VPN bottleneck for remote groups on the network.
Relays also function to reduce total the network usage when used on subnets connected through switches on a LAN.
Relay Characteristics
In an embodiment, a Relay takes over most of the download duties of the Server. If several Clients simultaneously request files from a Relay, a significant amount of the computer's resources may be used to serve those files. Other than that, the duties of the Relay are relatively undemanding. The requirements for a Relay computer vary widely depending on or more of the following: (1) The number of connected Clients that are downloading files: (2) the size of each download; and (3) the period of time allotted for the downloads.
A Relay can be installed on any ordinary workstation, but if several Clients simultaneously download files, it may slow the computer down. Workgroup file Servers and other Server-quality computers that are always turned on may be good candidates for installing a Relay.
Relay Selection
Although Clients can automatically seek out and connect to the available Relay, one may want to control the process manually. If so, for each Client in the network, one may specify both a primary and secondary Relay. The Client first attempts to download any patches from its primary Relay. However, if the primary Relay is unavailable (because the computer has crashed, the hard drive has run out of space, the computer is off, etc.), the Clients can download files from the secondary Relay.
In an embodiment, Relays have failover capability. Thus, if the primary Relay fails, the Client connects to the second Relay. If the secondary also fails (or if no secondary has been designated) then the Client automatically reverts to downloading files directly from the Server. In an embodiment, one or more tertiary Relays can be designated for a Client. In an embodiment, one can optimize a pair of Relays by splitting the connected Clients into two groups of roughly equal size. One group designates computer A as primary and B as secondary. The other group reverses the order, thus cutting the overhead of each Relay by two, while still providing a backup.
In an embodiment, configuring a Client computer as a Relay may involve using the Console to edit settings for the Client computer to run a Relay Server on the Client.
Once a Relay has been set up on a Client, in addition to functioning as a Client, the Client behaves in the same manner as a Root Server, so that other Clients can do all the interactions they would do with a Root Server through the Relay.
The use of Relays significantly reduces the Client/Server communication necessary for patch application and management. Clients may start to download from designated Relays, minimizing the load on thin connections to the Server. The Clients may also upload their status information to the Relay, which compiles it and compresses it before passing it up to the Server.
In an embodiment, Relays may help enormously to spread out and optimize network traffic, ensuring maximum responsiveness with minimum bandwidth. Relays are especially attractive with remote offices connected by relatively slow VPNs. The Server sends a single download to the remote Relay, which can then distribute it to the Clients over a faster local subnet.
Manual Relay Selection 300 (shown in
By way of the Console UI 1600, for each Client or for groups of Clients:
Agent Autoselection Algorithm 400 (shown in
Failover Behavior 500 (shown in
Relay Reselection Strategy (shown in
Automatic Selection (
While Relay selection is in progress (601):
Manual Selection (
Triggers for Relay Selection
Intervals are configurable by settings;
Typical Relay Functions
As above, Relays are usually Clients that have that have been specially configured to function as a Server does, in addition to their normal functioning as a Client. Thus, like Clients, Relays themselves can be configured, as described above, to automatically seek out and connect to the nearest Relay. In effect, the connecting Relay is choosing its parent in a Relay hierarchy. Thus, in an embodiment, automatic Relay selection provides for a Relay that determines its parent Relay dynamically, so that as the state of the network changes, different hierarchies and routing paths through the network are constantly being discovered by Clients and Relays without any modification of the hardware or the network topology and without any input from an administrator. As will be described in greater detail herein below, the ability of Clients and Relays to discover routings through the network enables a multitude of use cases all based on the establishment of dedicated pathways through the network for particular purposes.
In an embodiment, Fixlet messages can download and run specified payloads whose SHA-1 checksums have been captured at the time the Fixlet is created. Thus, actions created from such Fixlets will run only the specific executable that was referred to by the source Fixlet.
Certain applications, however, may involve objects, updates for which need to be downloaded regularly. In particular, vendors of antivirus software update their antivirus definitions, occasionally as often as several times per day. There exists, however, a significant possibility of damage or attack when downloading a file without knowing exactly what it is.
While it would be possible to manually download and deploy the object, manual download would be time- and labor-intensive to most users of the Platform. What is needed is a trustworthy way to deploy the latest version of the object, for example, the latest version of an antivirus engine to Clients that request it. It would be desirable to offer providers of anti-virus and of spyware, for example, the ability to deploy a policy Action to tell Agents to periodically update the anti-virus definitions on the Client to the latest version, while taking advantage of the Relay distribution infrastructure.
Furthermore, it would be desirable to be able to configure a Client to automatically apply all critical updates in a particular site. Additionally if would be desirable to automatically push updated sales lists to field sales laptops, or to push to push data files to retail locations.
In an embodiment, a Fixlet message is authored and deployed that instructs a Client to trust an arbitrary piece of content to run, delegating the responsibility for knowing that the content is safe to run to a piece of trusted logic on the Client. In order to request the arbitrary piece of content, the Client need only supply certain information about the object, for example, a unique identifier for the object such as a hash of the object. Thus, by means of the Fixlet message, any Client in the system can be configured for this interaction wherein untrusted content is downloaded to the Client. Any Client can ask the Relay to retrieve a particular file by providing the file size and the hash of the file. After the information is provided, the Relay can mirror the file through, from the Root Server, from the Internet and back down through the Relay hierarchy. In an embodiment, the Client knows in advance what it is asking for. Thus, Dynamic downloading provides the ability to use relevance clauses to specify URLs.
An embodiment makes use of the Platform's site-signing and distribution capability to flow untrusted content, such as antivirus definitions, with the ability to merge the untrusted content from other sources with the assurance to users that the particular untrusted content can be trusted. When the content flows down through the Relay infrastructure to the Client, it may be merged with an Action instructing the Client to run whatever the content tells the Client to run.
Thus, in an embodiment, an object or an item of content may need to flow down to the Clients in order to be processed. Trusted software on a Client evaluates the content and decides the URL, the SHA-1 and size of the file necessary to update the Client. Then, the URL, the SHA-1 and file size flow back up from the Clients to the Server. The Server is then able to produce the specified file, whereupon the file flows down through the Relays and is executed in the context of Clients that have been configured to automatically apply an update policy whenever the SHA-1 changed.
Thus, it could be that a single piece of content may contain the information necessary for a piece of antivirus software to update itself. In addition to that, it could also contain antivirus definitions, such that a combined Agent could say, “yes, I need these three files” or a antivirus Agent could say “I only need this one file.” They could then both derive the information necessary to specify what file to download from the same content feed—the same piece of data that flowed down from the Server. The choice would then be conveyed back through the hierarchy to the Server to collect the appropriate file.
It will be apparent, that, at the time when a policy is published, at least some of the information that the policy concerns itself with may not be static. For example, in the case of a virus definition file, the information changes whenever a new version of the virus definition file is published, perhaps as often as several times per day.
In an embodiment, an Operator inspects ActionScripts and approves them for execution on the Client. ActionScripts may be static, in which case it is a fairly simple task to inspect them to see which steps will be executed on the Client. In the case of dynamic content, however, where dynamic elements change in an ActionScript, the ActionScript uses variables to refer to the dynamic content.
Additionally, the foregoing approach protects the confidentiality of customers of the Platform vendor, reassuring them that an excessive amount of control has not been surrendered to, for example, a software vendor who is producing the virus definition file.
In an embodiment, the Client is enabled to look up the dynamic information indirectly and fill it into the variables. In this way, the Operator is able to inspect the sequence of instructions as they are to be executed on the Client, allowing the Operator to better decide whether or not to trust the content and to approve the ActionScript.
One embodiment enables performance of dependency resolution, in order to install various pieces of software and to update that software. Dependency resolution is useful in the case of an arbitrary collection of software, at least some items of which depend on other software being installed. Any particular piece of software might have incompatibilities with other pieces of installed software. There may exist requirements such as if a first piece of software is updated another piece will need to be updated. It becomes a quite complicated process to resolve all those dependencies.
An embodiment of the Dynamic Download application provides data in the form of a set of packages to a process on the machine itself that is able to analyze the set of packages. The process produces a list of URLs, SHA1 checksums, and sizes that need to be downloaded for the particular machine in order for it to update to a new version of a package. That same set of information can be processed by different computers, and each may arrive at a different answer because of the software already installed on the machine.
As an example, one could author and rollout an Action to install the newest version of the [Apache] Web Server, for example.
The Action is rolled out to a number of machines. Each machine may have thereon a data file that defines the set of URLs, SHA1 checksums and sizes that contains specific versions of other packages upon which that version of the Web Server depended for use in extracts the set of other packages needed to be applied to that machine in order to update it to the newest version of that Web Server.
Thus, in this case, the ActionScript is written such that it may use one or both of relevance substitution and some local processing of the Client, to look through a large list of URLs, SHA1 checksums, sizes and dependency information about what each one of the package requires and is compatible with, to determine the set of downloads needed to be pulled down to this particular machine to execute just that set.
It will be appreciated that a common feature of the foregoing embodiments of the Dynamic Download Application is that they are based on knowledge of the context of the item or items sought. Thus, a requestor doesn't provide just an address. Instead, the requestor is asked to describe, through a SHA1 checksums, exactly what is sought, in order for a Relay to pull it by specifying, at least, the size of the file and the hash of the file. An additional common feature is the evaluation of relevance for a particular Client, because each Client may have different update requirements or download requirements.
An embodiment implements the Dynamic Download application as shown in
As with static downloads, Dynamic Downloads must specify files with the confirmation of a size or SHA-1. However, the URL, size, and SHA-1 are allowed to come from a source outside of the ActionScript. This outside source may be a manifest containing a changing list of new downloads. This technique makes it easy to access files that change quickly or on a schedule, such as antivirus or security monitors.
This flexibility entails extra scrutiny. Because any Client can use Dynamic Downloading to request a file, it creates an opportunity for people to use the Server to host files indiscriminately. To prevent this, in an embodiment, Dynamic Downloading uses a White-list. Any request to download from a URL (that is not explicitly authorized by use of a literal URL in the ActionScript) must meet one of the criteria specified in a White-list of URLs on the Server. In an embodiment, the White-list may contain one or more regular expressions in, for example, a Perl regex format, separated by newlines, such as shown in Table 1, below:
The first line is the least restrictive, allowing any file at the entire site-a domain to be downloaded. The second line requires a specific domain host, while the third expression is most restrictive, limiting the URL to a single file named “JustThisOneFile.qfx”. The foregoing description of the White-list is illustrative only and is not intended to be limiting. If a requested URL fails to match an entry in the White-list, the download immediately fails, with status NotAvailable. A note may be made in a Relay log of the URL that failed to pass. In an embodiment, an empty or non-existent White-list causes all URL downloads to fail. In the other hand, a White-list entry of “.*” (dot star) allows any URL to be downloaded. Other methods of composing and formatting a White-list are consistent with the spirit and scope of the subject matter described in the attached Claims.
While the foregoing embodiments describe Dynamic Downloads either from the Server or from a Relay, an embodiment permits Relays to download directly from the Internet. In such a case, a file that the Root Server has already told the Relay is available can be downloaded directly by the Relay.
In an embodiment, status reporting for Dynamic Downloads is integrated with reporting for static downloads, being displayed side-by-side. In an embodiment, reporting on any given Action is limited to a configurable number of Dynamic Downloads, for example, the twenty most recent, in order to avoid overwhelming an Action document and the connection between Server and Console.
As described above, the primary key or download request is the hash and the file size. Thus, in a case of different download requests for the same hash/file size, with each request naming a different URL, the second URL is ignored. Alternatively, if the first URL fails, a request for the second URL may succeed by changing the URL of the file recorded on the system.
In the event that a request fails, the Client may re-try the download by resubmitting the request.
In an embodiment, failures may not be propagated down to the network. Instead, Console status reporting is operative to alert the Console Operator of the failure, so that it can issue a notification to the Client to discontinue sending a request that has failed a number of times. In an embodiment, Clients are discouraged from making frequent retry requests by configuring a long delay interval between retries.
In an embodiment, DownloadRequests may have a serialization format as shown below in Table 2:
In an embodiment, DownloadResponses may have a serialization format as shown below in Table 3:
In an embodiment, Clients and Relays may request a download from their parents by providing, for example:
In an embodiment, the file size and the URL are not technically necessary. However, the file size reinforces the SHA-1 mechanism and the URL allows the Server to fetch the file directly from the Internet without having to check a local index.
The file size/SHA-1 uniquely identifies a download request. If the Server has a matching entry in its cache, the provided URL does not need to be used. As above, the URL, in fact may not even match the original URL used to request the file.
In an embodiment, Clients are provided with the ability to request an arbitrary URL.
In an embodiment, a record of file downloads and progress is stored in a table that uses FileID as the primary key. In an embodiment, the URL, the file location and the status are stored as values.
In an embodiment, the cache is implemented using SQLITE. Other embodiments may employ other database engines that support in-memory databases and triggers.
As above, a download triple consists of SHA-1, filesize and URL. The URL describes the location of the file and the SHA-1 and filesize function to verify the file. In an embodiment, a Client may send a download notification that includes a list of download triples. The Relay evaluates the triples and signals the Client when to start the download. This may be either immediately, if the file is present on the Client's Relay parent or after the download to the Relay is complete.
Given two Clients, C1 and C2 and one Relay, R, it may occur that C1 and C2 request the same file. When the download request comes into Relay R, and is processed, a lock may be held so that only one download request is processed at a time.
Example:
In an embodiment, failures are not propagated to children. Thus, Clients do not need to be responsible for a retry, eliminating the necessity for a Client that switches to another Relay to check an additional state for a file. Instead, the Client can just do a re-try after a timeout. Such a practice also aids in Relay failure; thus, if a Relay state is lost, the default is that the Client eventually requests a re-try.
In order to keep the Relay cache synchronized with the actual files located on the Relay, on a Relay reboot, all states mapping to a file download request are removed. Thus, the cache can rebuild itself by checking what files are actually on the Relay. Typically, the Relay mailbox contains response and requests that map to files in the cache with the states NEW and REQUEST_SUBMITTED, respectively. The cache may either remove partially downloaded files or make a list of them and add them as files in the cache with state DOWNLOADING.
An embodiment incorporates a Distributed Server Architecture. In an embodiment, Distributed Servers do not download from each other because all Servers are assumed to have the same level of network connectivity. Additionally, there is no replication of the Servers' download caches. In an embodiment, download White-lists are not replicated. Thus, they may be manually configured on each Server.
Additionally, Download Requests may succeed and fail completely independently on different Servers. Because all of the necessary logic is stored on the Clients and in the White-list, exchange of information between Servers is rendered unnecessary.
As described above, the Dynamic Download feature can render the limitation that URLs and SHA-1s be known at Action creation time unnecessary. With Dynamic Downloads it is sufficient that URLs and SHA-1s be computable by the Clients prior to Action execution. Client processing may be impacted in at least the following ways:
When processing an ActionScript containing the begin pre-fetch block/end pre-fetch block commands, as shown herein below, a Client can identify files to be downloaded to a Relay by providing the URL/checksum of each file. In an embodiment, multiple requests are consolidated by a Relay into single requests to a parent Relay. Ultimately the requests arrive at the Root Server. The Root Server then verifies the URLs through the White-list, and provides the file, either from its cache or by attempting to download the file. If the URL produces the appropriate SHA-1 file, the Relays are then notified of the availability of the files, and they pull them down if they have descendants that have requested the file. Agents are notified of the availability of these files, via a Notification message, which they pull them down if they are interested.
If a URL/SHA-1 is not available, Agents continue to request it, until (1) the Action that drove the request is stopped or (2) the URL/SHA-1 becomes available, or (3) the request has been made a number of times.
In an embodiment, the Action language provides an explicit pre-fetch block of ActionScript to be used to identify pre-fetch downloads. Actions triggering the dynamic download feature may be authored with the pre-fetch block, thus making it easier to identify pre-fetch Action activity.
The following Action language commands identify the boundaries of the pre-fetch block:
A number of commands are allowed within the pre-fetch block:
Commands allowed within the pre-fetch block that are not allowed outside it:
When processing actions with pre-fetch blocks, certain commands should not be used, such as:
In addition to the above, when processing actions with pre-fetch blocks, downloading that is permitted during Action execution may be triggered by a ‘download now’ command. In an embodiment, pre-fetching specifications may be placed at the top of the ActionScript, thus making it easier for readers to understand which files are being collected.
For example:
“Only a single begin pre-fetch block is allowed”;
“Only comments and blank lines are allowed before pre-fetch block”;
“End pre-fetch block found before begin pre-fetch block”;
“Command invalid inside pre-fetch block”;
“Command invalid outside pre-fetch block”;
“Relevance substitution missing trailing ‘}’”;
“Relevance substitution is not allowed”;
“Missing required argument url=”;
“Missing required argument size=”;
“Missing required argument sha1=”;
“Argument not allowed sha1=”; and
“Argument is not recognized”.
For example:
Presence identifies new style Action;
One allowed per Action;
Comments and blank lines may precede this command; and
Paired with a matching ‘end pre-fetch block’ command.
Paired with a ‘begin pre-fetch block’ command
Only commands inside true condition pathways are performed.
When a Client builds a download list, if there are ActionID/ordinal downloads but no URL/SHA-1 downloads, the Client uses the request mechanism without URL/SHA-1. If there are any URL/SHA-1 downloads present, it uses the URL/SHA-1-based request mechanism, which allows for ActionID/ordinal requests and URL/SHA-1 requests to be co-mingled. The Client verifies the signature of the Action before it does any download pre-fetching calculations from the ActionScript. If a Relay or Server do not support the URL/SHA-1 based request mechanism, the Client blocks the Action from executing.
Several inspectors allow an ActionScript to be written in a consistent manner that refers to files in the pre-fetch folder when an Action is not active, and to files in the download folder when the Action is active. In an embodiment, Pre-fetch files are collected to a per-Action-pre-fetch-folder until the Action is ready to run. They exist in the per-Action-pre-fetch-folder with various names that indicate the progress of the pre-fetch activities. At various stages in processing these files may be renamed to the names specified in the pre-fetch commands. The named versions of the files when the Action is inactive after every ‘collect pre-fetch items’ may be placed into a ‘named’ folder. Before an Action is run, the pre-fetch files are moved from the ‘named’ folder to a ‘Download’ folder of the Action site. When the Action completes, any files remaining in the ‘Download’ folder are moved into the download cache or utility cache and renamed to their SHA-1.
One or more of the following inspectors can be used to locate files during the pre-fetch processing or while the Action is running:
Temporal Distribution with Downloads
In an embodiment, the Client asks for a ‘0’ file. Once the ‘0’ file is available, Clients calculate their time to start, causing the Relays to collect the file as soon as the first Client requests it, so that all of the Clients are not downloading at the same time.
In dynamic download situations, a set of pre-fetch files identified by a first ‘collect pre-fetch items’ statement is requested. If no ‘collect pre-fetch items’ statement is used, the full set is requested. When they become available, the Clients calculate their time to start. Once that time to run is reached, the Client sees if there are more files it needs; if so it requests them, then it runs. It will not pick a different time to run. The effect of this is that the Clients that choose an early distribution time trigger any additional files to be downloaded. Thus, the later Clients do not have to wait for them.
Client Requests Files when All Files Already Available in Cache
In an embodiment, Clients go to their caches before they ask the Relay if the files are available.
Name Collisions
In an embodiment, Clients run the Action with the last file with that name in place, regardless of how many other downloads have the same name.
This example assumes a version comparison is used to detect that a change (upgrade or rollback) is necessary. Other techniques might use Dates, or compute SHA-1's of saved versions of a server configuration file to trigger the update. This is formatted in a fashion that assumes the wizard constructing it has access to key pieces of information required to generate the Action.
This example assumes a version comparison can be used to detect that the update is necessary. This arrives as a Fixlet. The values are substituted from a server configuration file when the Fixlet is authored by an on-demand wizard. In this situation, Server_bf.ini.PatternVersion, for example, is read from the Server initialization file when the wizard is used to create an on-demand update Fixlet. To build this expression, the name of the custom site must be known. The Client may be configured to know where the auto-update Server_bf.ini and Server_bf.ini come from.
In an embodiment, the Platform provides a security model having at least the following capabilities:
In the foregoing approach, Clients are assigned unique identifiers when they register. Any entity, such as a machine or network, that requests a registration interaction with the Server is issued a unique identifier and is trusted. Many of the properties associated with a particular Client that can be viewed by an operator by way of the UI to the Console are aligned with that Client based on that identifier that was handed out at the time of registration. Accordingly, the foregoing approach provides strong authentication of the Server and the Administrators by the endpoints (Clients). That is, whenever a Client receives a command from an Administrator, the Client knows exactly who issued it by virtue of the strong cryptographic mechanisms. Additionally, the channel can be encrypted through strong cryptographic mechanisms. However, information flowing in the opposite directions, from endpoints (Clients) into the system, is not authenticated because there previously has not existed a reliable way to authenticate the endpoints. Not being able to reliably authenticate an endpoint may provide an opportunity for such attacks as spoofing, in which a person or program successfully masquerades as another by falsifying data and thereby gaining some illegitimate advantage.
There exist, for example, simple techniques that attackers use to spoof information, such that the Console would display the spoofed information as if it were genuine—as if it was coming from the particular Client associated to a particular Client identifier. A Client authentication mechanism, in which a cryptographic credential is established on each Client (endpoint), provides a much stronger, more robust security model that greatly minimizes the risk of spoofing attacks.
In an embodiment, the Client Authentication mechanism extends the previous security model to include a mirror image of the above-mentioned capabilities:
The foregoing embodiments of the security model present complementary challenges:
A solution to the above challenges allows anyone to enter the system and generate a new identity and builds trust from that starting point, unlike conventional security systems, which specifically require that a new resource be explicitly joined to the system by an Administrator. Referring now to
Assuming that the private key created on the Client is not distributed to any other devices, it can authenticate content coming from that Client, making it possible to verify any messages sent from the Client.
Overview
In an embodiment, a cryptographic protocol, such as OPENSSL is employed to create public/private key pairs for each new Client in a deployment. When a Client initially registers, it submits a public key with a request that the key be associated to a new computer ID. The response to the Client request, in turn, is signed with a key that can be authenticated by the Client. Thus, the Client may not be deceived, thinking that it has registered with the root directly with a Root Server when it has, in fact, registered through a malicious middleman who has switched the public key submitted to the Root. The Root Server stores the Client's public key in a map of computer IDs to public keys. The key remains associated with the ID for the life of the ID.
On subsequent interactions, reports or file uploads, for example, the Client signs the interaction with its private key. When the Root Server receives a report, before updating the data for the computer ID provided, it verifies that the report is signed by a key that matches the public key on file for that ID.
To send secure data to a Client, the Root Server exposes APIs, for example, by way of the database or SOAP (simple object access protocol), that allow lookup of public keys given a computer ID. In an embodiment, the data is trusted, to assure that the data gets encrypted against the intended target, and not a maliciously-inserted target. In an embodiment, database security and/or signing the data provide a sufficient degree of trust. Given the public key, any program can encrypt data and provide to the Client however it wishes.
Server Data (per Client):
If Client Computer ID !=0, and public/private key pair is functional:
If Server Registration Request with Computer ID=0:
If Subsequent Server Registration Request with Computer ID!=0 (
Client report
Server Report
The person of ordinary skill will notice that the foregoing embodiments employ the SHA-1 cryptographic hash algorithm. Other embodiments may incorporate other cryptographic hash algorithms such as MD4, MD5, SHA-0, SHA-2 or SHA-3.
As shown in
In addition, the foregoing model also provides a mechanism for doing clone detection, in the event that a key does become compromised. The cloning detection, when it detects a cloned key during a registration attempt, invalidates the Computer ID associated with the cloned key. Subsequently, the Client must generate a new key pair and begin the registration process anew, thus enabling the detection of key reuse by a different party.
It will be appreciated that the level of trust established by the foregoing Client Authentication model may be raised through combination with other authentication mechanisms. For example, a higher level of trust may be achieved by establishing a second data pathway to secure a confirmation; for example, by requiring the registering party to confirm that they, in fact, are the registering party by email. Alternatively, a higher level of trust may be established if a Client is able to authenticate through a Server's active directory, or if the Client and Server can exchange keys via a protocol such as SSH (secure shell). A still higher level of trust may be achieved through by physically verifying that the machine's credentials can be trusted; for example by having an operator access the machine and verify the public key. Additionally, Clients accorded varying levels of trust may be identified in the Console interface. For example, Clients accorded the primary trust level are grouped together in one region of the display, while Clients accorded the highest trust level are grouped together in another region of the display.
While the foregoing Client Authentication model has been discussed primarily in connection with Client/Server interactions, the model also finds application in interactions between Client, for example a clustering relationship involving a number of endpoints.
Additionally, while the Client Authentication model has been discussed primarily in connection with Client/Server interaction, in an embodiment, it may also play a role in interactions between a Relay and a Client. As described above, Relays are typically Clients that have been additionally configured to behave as a Server. Accordingly, because a Relay is also a Client, the Relay can also be issued authentication credentials like a Client. By authenticating the Relay, a Client knows that it is talking to a Relay, thus providing additional protection against Snooping attacks, such as man-in-the-middle attacks.
An embodiment of the Client Authentication model finds application in the sending of a password down the hierarchy to a Client from the Server. It is a common IT management task to reset the password on a Client. Conventionally, a password, when it is sent to a Client is scrambled. The Client is then given a utility to unscramble the password. However, giving the Client the unscramble utility, in essence, gives it to the rest of the world. Thus, even though the scrambled password is not plaintext, it is not secure. There exists, therefore a great need for a secure way to send a password down to a Client. Because the Client Authentication model includes a key pair for the Client, the password can be encrypted using the Client's public key, which is then pushed to the Client. Because only the Client has the private key, only the Client can decrypt the password.
As above, an embodiment of the Platform provides the ability to facilitate a connection between a Console operator and a remote computer, as shown in
Among the use cases are:
Using the Platform to establish either synchronous or asynchronous one-to-one connections between the Console and a Client readily circumvents a host of restrictions imposed by network topology. For example, the Relay hierarchy readily allows penetration of NAT (network address translation) protocols—a technique that allows a number of machines to share a single IP address from the outside world's perspective—so that it is possible, assuming that a Relay exists behind the NAT, to communicate with Clients behind the NAT.
One embodiment enables routing through the infrastructure into a Relay inside a subnet and then allowing the last leg of communication to take place over an IP address that can directly connect to the target machine.
The Relay hierarchy and the Relay hierarchy discovery mechanisms that employ hop count as a measure of Relay suitability for a machine to connect to greatly simplifies the configuration of routes through the hierarchy. Upon registering with the most suitable Relay by a Client, not only is a connection established with the Relay, but through the Relay all the way up to the Server, such that messages can then be forwarded down the pathway to the particular Client.
In an embodiment, the present Direct Connect methodology uses the pathway to establish a connection. For example, a rendezvous technique may wake up the target machine, inform it that a direct connection is requested and inform the target of the network topology or pathway to use to connect. In an embodiment, it is possible to directly connect across a network.
In an embodiment, the Relay infrastructure may be used as a communication mechanism to trigger a rendezvous, and subsequently to facilitate communications by keeping sockets open in both directions with all of the internet Relays handing off traffic in both connections as packets flow between the two. For example, the Relay infrastructure can be used with certain distributed computing applications wherein a connection is opened up between two ports that wouldn't otherwise be able to connect; the connecting Server can then step out of the middle, so there is no longer any Server involvement.
In an embodiment, as shown in
In an embodiment, by means of a user interface displayed on the desktop of each Client in the network, the user is able to specify a machine that the user would like to connect to and initiate a connection, for example, with a simple mouse click, triggering an activity that, behind the seasons, makes the connection available to the Client.
In an embodiment, a Relay may be used to provide an execution environment for other functions inside a container, thus providing a place in which Server functionalities can be made more widely available to Clients on the network.
In an embodiment, Relays may be used to host software depositories, for example software updates, so that the updates could be readily flowed to any Relay that has been configured to host the updates.
In an embodiment, Relays may be used to host computational entities such as distributed pattern databases that ideally are scattered throughout the enterprise.
Additionally, Relays may be used to host computational entities such as virtual environments to give the Relay cross-Platform capability, allowing it to run software for any operating system.
In an embodiment Relays can be designated as processing points for a variety of computational tasks.
In an embodiment, Relays can provide a direct connection from a management point to an end point, thus enabling management technologies such as VPRO.
Wake-on-LAN is a computer networking standard that allows a computer to be turned on or woken up by a network message. Conventionally, the wake-up message is referred to as a “magic packet”, for example, a broadcast frame containing within its payload 6 bytes of 255 with all bits set to the ‘on’ position, followed by sixteen repetitions of the target computer's MAC address. Thus, the challenge is to direct a magic packet down to a target computer to wake it up. However, the magic packets used by Wake-on-LAN have the special property that they only work if they are broadcast within a subnet. Additionally, most networks do not permit sending a broadcast packet to other subnets because they can be easily abused to launch, for example, SMURF attacks.
To circumvent the limitations involved in using a magic packet to wake up a computer, the Relay infrastructure herein described is used to find a way to route a broadcast packet down from any central point within the system, from the management Console, from within an integration point, to any computer that exists within the system by taking advantage of the fact that, when a Client registers with its Relay, up to the root Server, the Client sends up a list of the interfaces that it knows it has to communicate with, what subnets they're in, and what their MAC addresses are. As above, the MAC (media access control) address is the address used for these wakeup commands. Thus, whenever a Client talks to a Relay, it sends up information saying “Here's where I am and here's how you can get in contact with me.”
The Relay retains this information, passing it up through the hierarchy all the way to the root, so that at the root of the deployment, an Administrator is able to readily determine what subnet a target computer occupies. The administrator next needs to find some other computer that is awake in the target computer's subnet that can broadcast the magic packet to the target computer. Because the Relay hierarchy has collected all of the necessary information for the Administrator, he/she knows of, for example, eighty computers that are all on the same subnet as the target computer, and they may be reporting in to, for example, two different Relays.
The administrator may then send a message down through the Relays, to reach the two target Relays which know how to contact the target's subnet, and they both then send out messages to all of the target's peers, requesting that the target be woken up. The Clients are configured to listen for the UDP messages sent out by the Relays asking that the target be woken up. When a Client hears one, it immediately broadcasts one of these Wake-on-LAN messages to the target computer.
Thus, unlike the conventional approach, which usually requires that a computer be designated in each subnet that must be powered-on at all times to provide a point of communication, all of the computers in the target subnet are told to wake-up the target machine. It is highly likely, that out of all of the computers in the target subnet, at least one will be found that is powered-on and can issue a Wake-on-LAN message to the target computer. Because the requirement of a single point of communication has been eliminated, the network is considerably more robust, and easier to consider.
The Clients send out the magic packet on the same interface they're already listening on and they see when other Clients start sending out the same packet. The Clients stop sending immediately when they see this duplicate traffic, so there is a likelihood of a small amount of duplicate traffic, but in the event of duplicate traffic, the Clients elect among themselves which Client will broadcast the magic packet. All Clients that elect to wait a while are silent the next time they see a forwarding request until, a period of time elapses, for example, a second. If they see that Client queried hasn't responded, for example, because it was powered-off, the next Client in line will try.
The election process uses a technique that relies on a unique computer ID and a comparison operation that each computer can use to decide whether or not it should take precedence over the other computers. Any individual computer observing all the UDP traffic to wake up a particular machine in the subnet can decide whether or not it should take precedence. That is, it should be the one who should take precedence in that subnet versus the other ones. Thus, the Client that takes precedence prevails and takes over. The other Clients stay out of the way unless they detect that the designated computer isn't performing its tasks, in which case they also chime in again and again. Whoever becomes dominant is controlled by the ordering of the individual machines according to the machines' unique identities. Thus, there is a built-in technique where the Clients do this election process based on a unique identifier and a colation order for determining precedence.
It should be noted that a Relay is generally a Client also, so that, as long as it fulfills the requirement of being in the same subnet as the target computer, a Relay could be the one to wake-up the target computer.
In view of the foregoing discussion, it will be apparent that the broadcast packet, within the context of the subnet, is actually a broadcast type of communication. The other messages that are actually happening inside of the system are directed messages. So what's flowing down through the Relay hierarchy after some user says “I want to wake up Bob's machine”, is not a broadcast. It is instead directed to the particular machines that are in that subnet that this particular machine reported that it was a member of.
The target machine resides inside a particular subnet; and so its peers within the subnet are notified through directed mechanisms saying “if you're in this subnet—you should wake up Bob (the target machine)”, with his MAC address and so on. Each peer constructs the magic packet with that information, and they tag it with the unique identifier that allows them and their peers to coordinate who's in charge of that subnet and delivering that message. And then they transform it into a broadcast message within the subnet
Thus, a fundamental advantage of the Relays and the Relay hierarchy herein described is that any computer in the system can be contacted through the Relay hierarchy. Unlike conventional network topologies, of for example, 100,000 machines, wherein each computer has an IP address and routes may exist between all of them, but many of those machines are not allowed to contact each other, or they are prevented from contacting each other because of the presence of firewalls, network segmenting, and so on.
The discovered routing that is established as a result of Relays and the automatic Relay selection makes it possible to reuse that routing to get a message back down to the computer. In fact, it is possible to find a routing between any two computers the administrator might want to talk to. By starting with a Relay and forwarding from one machine to a next until a message reaches the target, the Administrator can get a message through. Thus, it is to be appreciated that the Platform, in addition to providing the one-to-many communication of a broadcast system, allows direct one-to-one communication between any two machines within a network topology under management via the Platform.
In an embodiment, an Asset Network Map, as shown in
The aggregated data is rendered as a human readable graph using, for example, a force-directed algorithm, such as a spring algorithm. Additionally, the Operator can apply various filters to the data in order to create a map that highlights particular aspects of the data. For example, the Operator may specify that the link between a Relay and a Client should be 300 kilobytes/second.
While the Network Asset map can display historical data, in an embodiment it can be updated in real-time as the network infrastructure changes. Thus, the Network Asset Map can function to display data even as it is being generated. In this way, network traffic can be depicted visually, in real-time, so that the Operator, can, for example, detect, even as it is happening, that a particular area of the network is becoming overloaded.
In the foregoing specification, the invention has been described with reference to specific exemplary embodiments thereof. It will, however, be evident that various modifications and changes may be made thereto without departing from the broader spirit and scope of the invention as set forth in the appended claims. The specification and drawings are, accordingly, to be regarded in an illustrative sense rather than a restrictive sense.
This application claims benefit of U.S. provisional patent application No. 61/242,278, filed Sep. 14, 2009, the entirety of which is incorporated herein by this reference thereto. This application is related to U.S. patent application Ser. No. 10/804,799, now U.S. Pat. No. 7,398,272, filed Mar. 19, 2004, the entirety of which is incorporated herein by this reference thereto.
| Number | Date | Country | |
|---|---|---|---|
| 61242278 | Sep 2009 | US |
