The present teachings relate to systems and methods for network management using a secure mesh command and control framework, and more particularly to platforms and techniques for generating and managing the delivery of network management commands between target machines based on relationships with trusted supervisory hosts, using direct secure channels between the target machines.
A variety of network management platforms exist to assist network administrators with installing and configuring network resources. In many platforms, a management server can be used to issue commands to hosts or other network nodes to manage the configuration of the network hosts, underlying clients or other devices. In the case of comparatively large-scale networks, and/or networks in which nodes are relatively widely dispersed geographically, the distribution of commands can become more problematic. For one thing, the systems administrator may not be aware of the best connection route or pathway through the network to a set of target machines, to most effectively “push” the commands to their destination. For example, certain systems may be reachable only through intermediate systems due to firewall configurations, and multiple levels of firewalls may be in place.
For further example, it may be desirable to reduce or minimize the number of network nodes or “hops” that the commands need to traverse to arrive at the intended target machines. For again further example, in the case of relatively large-scale networks, for example on the order of hundreds or thousands of hosts and/or nodes or more, it may be desirable to transmit the commands as few times as necessary to avoid repetitively transmitting the commands over again each time.
For yet further example, the reliance on a rigid control hierarchy where only a supervisory host can issue management commands can curtail the ability of lower-level machines to perform management functions directly with each other, since all command traffic must instead pass through a supervisory host. Responsiveness and flexibility can therefore be affected. It may thus be desirable to provide methods and systems that overcome these network management difficulties, and permit enhanced or more flexible network management at the level of target machines.
The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments of the present teachings and together with the description, serve to explain the principles of the present teachings. In the figures:
Embodiments of the present teachings relate to systems and methods for network management using a secure mesh command and control framework. More particularly, embodiments relate to platforms and techniques in one regard for generating and distributing network configuration commands that can be shared between lower-level targets or “minions” without a need for communication via a set of supervisory hosts (which can be referred to as “overlord” servers). The set of targets along with other network elements can share a common certificate authority, which can be used to establish trusted relationships between the targets or minions, directly. In embodiments the set of lower-level hosts and/or targets can comprise comparatively large-scale networks or deployments, on the order for example of ten thousand machines, or less or more machines.
Reference will now be made in detail to exemplary embodiments of the present teachings, which are illustrated in the accompanying drawings. Where possible the same reference numbers will be used throughout the drawings to refer to the same or like parts.
Set of supervisory hosts 112 can support or serve an underlying set of targets 116, for example via a local area network, or other network(s) or connections. Set of targets 116 can be or include a set of personal computers, network-enabled media devices, or other clients, devices, or machines. Other hierarchies, topologies, and connections between network management server 102, set of supervisory hosts 112, any intermediate hosts, and/or set of targets 116 can be used. In embodiments, communications between network management server 102, set of supervisory hosts 112, and/or set of targets 116 or other entities can be conducted via one or more secure channels, such as the secure channel and related resources described in copending U.S. application Ser. No. 12/130,424, filed May 30, 2008, entitled “Systems and Methods for Remote Management of Networked Systems Using Secure Modular Platform,” which published as U.S. Patent Application Publication No. 2009/0300180, assigned or under obligation of assignment to the same entity as this application, and which application is incorporated by reference herein.
Network management server 102 can include or access resources to support the generation and transmission of one or more commands 120 via auto-discovered or other pathways to manage set of supervisory hosts 112, and/or set of targets 116, including a network store 104. Network store 104 can be or include a database or other data store, and in embodiments can store a network map 106. Network map 106 can record information related to the configuration and topology of network connections between set of supervisory hosts 112, and/or set of targets 116, as well as other data. In embodiments, network map 106 can be recorded in a file, tree, database, or other record.
According to embodiments in one regard, network management server 102 can access network map 106 to carry out issue one or more commands 120 via one or more hosts in set of supervisory hosts 112 to underlying hosts, targets, and/or other devices. When network management server 102 generates one or more commands 120, network management server 102 can access network map 106 to identify one or more supervisory hosts in set of supervisory hosts 112 to which to transmit one or more commands 120. The recipient supervisory host(s) can receive one or more commands 120 and, in embodiments, access network map 106 and/or communicate with network management server 102 to extract a pathway by which to relay or transmit one or more commands 120 to underlying devices. The supervisory host(s) can then transmit the one or more commands 120 to a target or targets in set of targets 116, using the identified pathway.
In embodiments, it will be appreciated that any of network management server 102, set of supervisory hosts 112, any intermediate hosts, and/or set of targets 116 or other entities can be significantly or substantially geographically distributed, and can represent relatively large-scale groupings or clusters. For instance, different hosts in set of supervisory hosts 112 and/or associated targets in set of targets 116 can be located in different metropolitan areas, in different sections of a country, in different countries, or in different continents. For further instance, different hosts in set of supervisory hosts 112 and/or sets of targets in set of targets 116 can represent hundreds, thousands, or greater or lesser numbers of collective devices.
According to embodiments as for instance shown in
Once one or more targets in set of targets 116 are validated via respective credential 118, as illustrated in
According to embodiments, with one or more secure channel 108 or other connection in place between two or more targets, the authenticated or trusted target(s) can initiate command and control operations by communicating command data 120 to the subject target(s). In embodiments, each target can maintain an access control list 122 to determine the identity of trust machines include other targets, which are authorized to run commands on or perform other actions on that machine via command data 120 or other instructions. In embodiments, the command data 120 can be or include data, commands, instructions, scripts, links, and/or other information to carry out network management and control functions on the subject target(s). In embodiments, command data 120 can be or include, for instance, an inventory command, a test command, a setup command, a configuration command, a trend command, a security command, and/or other commands.
An authenticated or trusted target A can, for example, exchange command data 120 to monitor target B for processor load, bandwidth, or other properties or functions, and gain access to target B via secure channel 108 to monitor that target directly, again without necessarily invoking or communicating via a supervisory host. In general, each target which receives a request for access via command data 120 from another target can follow a process of for determining if any other target/minion can execute a command, including receive the incoming command data 120/other communication, and then checking the certificate or other credential 118 of the incoming communication to ensure it was signed by the common certificate authority for the local mesh/network of set of targets 116. If credential 118 was signed and is correct for the requesting target, the access control list 122 can be consulted to see if the requesting target has the authority to run the requested method.
In embodiments, because in one regard more than one secure channel 108 or other connection can be built directly between two or more targets, the command data 120 and security operations performed by local targets need not depend on the support of any one supervisory host or channel. Because, in part, the potential trusted mesh between targets in set of targets 116 can be defined by access control list 122, credential 118 for various targets, and other security data, the possible set of secure command subnetworks can be re-configured or dynamically change over time, in response to varying network operations and other factors.
In 410, a secure channel 108 can be established between a trusted or authenticated target and one or more subject target(s), based on the authentication. In embodiments, secure channel 108 can be or include a secure socket layer (SSL) connection, a public/private key infrastructure or connection, or other channel or connection. In 412, an access control list 122 can be read or accessed by one or more participating targets, one or more supervisory hosts in set of supervisory hosts 112, network management server 102, or other entity to determine the actions or access permitted by the trusted or authenticated target on the subject target. In embodiments, two targets can be mutually authenticated to act upon each other. In 414, command data 120 can be communicated to the subject target(s) to initiate or perform management operations, such as to generate hardware, software, or other inventories of a subject target. In 416, the resulting configuration or other operational data related to the subject target can be reported to authenticated target(s), supervisory host(s), network management server 102, or other entity or destination. In 418, the mesh or network of authenticated or trusted targets and other entities can be dynamically adapted or updated based on a revised access control list 122, versions of one or more credential 118, and/or other data. In 420, as understood by persons skilled in the art, processing can repeat, return to a prior processing point, jump to a further processing point, or end.
The foregoing description is illustrative, and variations in configuration and implementation may occur to persons skilled in the art. For example, while embodiments have been described in which configuration commands or other data are generated and transmitted from one network management server 102, in embodiments more than one server or other device or resource can serve as a control point. For further example, while embodiments have been described in which one or more hosts in a set of supervisory hosts 112 coordinate the distribution of commands and data to a set of targets 116, in embodiments, implementations can involve the dissemination of commands or other data through different network hierarchies, trees, nodes, or arrangements. For instance, in embodiments, commands or other data can be delegated via supervisory hosts through more than two sub-hosts or other sub-levels. For yet further example, while embodiments have been described involving one level or layer of supervisory hosts, in embodiments, the overall network can be configured with multiple levels or layers of supervisory hosts (or “overlords”). Similarly, various targets in set of targets 116 can be configured at different levels within the overall network.
Yet further, while embodiments have been described in which two targets installed or operating at the same hierarchical level can connect or mesh for secure command exchange, in embodiments, two or more targets occupying different network levels can connect and exchange commands or other data on a trusted basis. Other resources described as singular or integrated can in embodiments be plural or distributed, and resources described as multiple or distributed can in embodiments be combined. The scope of the present teachings is accordingly intended to be limited only by the following claims.
Number | Name | Date | Kind |
---|---|---|---|
6282652 | Scheifler | Aug 2001 | B1 |
6477572 | Elderton et al. | Nov 2002 | B1 |
6611869 | Eschelbeck et al. | Aug 2003 | B1 |
7003560 | Mullen et al. | Feb 2006 | B1 |
7036010 | Wray | Apr 2006 | B2 |
7082460 | Hansen et al. | Jul 2006 | B2 |
7082464 | Hasan et al. | Jul 2006 | B2 |
7127742 | Kramer et al. | Oct 2006 | B2 |
7200662 | Hasan et al. | Apr 2007 | B2 |
7284042 | Beadles et al. | Oct 2007 | B2 |
7305550 | Oliver et al. | Dec 2007 | B2 |
7310669 | Webb et al. | Dec 2007 | B2 |
7315826 | Guheen et al. | Jan 2008 | B1 |
7383433 | Yeager et al. | Jun 2008 | B2 |
7434253 | Crall et al. | Oct 2008 | B2 |
7480907 | Marolia et al. | Jan 2009 | B1 |
7509487 | Lu et al. | Mar 2009 | B2 |
7596227 | Illowsky et al. | Sep 2009 | B2 |
7600113 | Kuehnel et al. | Oct 2009 | B2 |
7627617 | Kavuri et al. | Dec 2009 | B2 |
7653008 | Patrick et al. | Jan 2010 | B2 |
7668947 | Hutchinson et al. | Feb 2010 | B2 |
7671735 | Karaoguz et al. | Mar 2010 | B2 |
7734910 | Nasu | Jun 2010 | B2 |
7779119 | Ginter et al. | Aug 2010 | B2 |
7787863 | van de Groenendaal | Aug 2010 | B2 |
7792986 | Donoho et al. | Sep 2010 | B2 |
7827590 | Hopen et al. | Nov 2010 | B2 |
8051181 | Larson et al. | Nov 2011 | B2 |
8073908 | Heins et al. | Dec 2011 | B2 |
8103783 | Plamondon | Jan 2012 | B2 |
8117314 | Croft et al. | Feb 2012 | B2 |
8131825 | Nord et al. | Mar 2012 | B2 |
8131851 | Harlow | Mar 2012 | B2 |
8205240 | Ansari et al. | Jun 2012 | B2 |
8336089 | Ahmed et al. | Dec 2012 | B1 |
8346929 | Lai | Jan 2013 | B1 |
8355407 | Wookey et al. | Jan 2013 | B2 |
8370528 | Bryers et al. | Feb 2013 | B2 |
8407687 | Moshir et al. | Mar 2013 | B2 |
8429630 | Nickolov et al. | Apr 2013 | B2 |
8498941 | Felsher | Jul 2013 | B2 |
8504696 | Larson et al. | Aug 2013 | B2 |
8713177 | DeHaan et al. | Apr 2014 | B2 |
20020099787 | Bonner et al. | Jul 2002 | A1 |
20030145083 | Cush et al. | Jul 2003 | A1 |
20050108369 | Sather et al. | May 2005 | A1 |
20060039340 | Ptasinski et al. | Feb 2006 | A1 |
20070078988 | Miloushev et al. | Apr 2007 | A1 |
20070239858 | Banerji et al. | Oct 2007 | A1 |
20070294369 | Ginter et al. | Dec 2007 | A1 |
20080002588 | McCaughan et al. | Jan 2008 | A1 |
20080016515 | Naim et al. | Jan 2008 | A1 |
20080170510 | Singh | Jul 2008 | A1 |
20080209033 | Ginter et al. | Aug 2008 | A1 |
20080215668 | Hu | Sep 2008 | A1 |
20080301780 | Ellison et al. | Dec 2008 | A1 |
20090235349 | Lai et al. | Sep 2009 | A1 |
20090249336 | Vasilevsky et al. | Oct 2009 | A1 |
20090300180 | DeHaan | Dec 2009 | A1 |
20100131632 | DeHaan | May 2010 | A1 |
20100235433 | Ansari et al. | Sep 2010 | A1 |
20110061045 | Phillips | Mar 2011 | A1 |
20120185559 | Wesley et al. | Jul 2012 | A1 |
Entry |
---|
Ziegler et al., Secure Profile Management in Smart Home Networks, 2005, Retrieved from the Internet <URL: ieeexplore.ieee.org/xpls/abs—all.jsp?arnumber=1408274>, pp. 1-5 as printed. |
Ellison, UPnP Security ceremonies, 2003, Retrieved from the Internet <URL: upnp.org/specs/sec/UPnP-sec-UPnPSecurityCeremonies-v1.pdf>, pp. 1-18 as printed. |
No stated author, OSGi Service Platform Service Compendium, Apr. 2007, Retrieved from the Internet <URL: osgi.org/download/r4v41/r4.cmpn.pdf>, pp. 1-5 as printed. |
No stated author, Understanding Universal Plug and Play, Retrieved from the Internet <URL: web.archive.org/web/20030501000000*/http://www.upnp.org/download/UPNP—understandingUPNP.doc>, pp. 1-45 as printed. |
Waugh; Taking your desktop virtual with VNC; 2005; Retrieved from the Internet <URL: redhat.com/magazine/006apr05/features/vnc/; pp. 1-5 as printed. |
No stated author; Chapter 23. Remote management of guests; Mar. 2015; Retrieved from the Internet <URL: access.redhat.com/documentation/en-US/Red—Hat—Enterprise—Linux/5/html/Virtualization/chap-Virtualization-Remote—management—of—virtualized—guests.html>; pp. 1-12 as printed. |
No stated author; 1.6. Creating a User Account; Mar. 2015; Retrieved from the Internet <URL: access.redhat.com/documentation/en-US/Red—Hat—Enterprise—Linux/4/html/Step—by—Step—Guide/s1-starting-create-account.html>; pp. 1-2 as printed. |
Runge; Using Apache as an SSL Gateway to x11vnc servers inside a firewall; Aug. 2008; Retrieved from the Internet <URL: karlrunge.com/x11vnc/ssl-portal.html>; pp. 1-10 as printed. |
No stated author; VNC documentation 4.0 >> Windows >> VNC Server; Mar. 2015; Retrieved from the Internet <URL: realvnc.com/products/vnc/documentation/4.0/win/winvnc.html>; pp. 1-12 as printed. |
USPTO Office Action for U.S. Appl. No. 12/130,424, mailed Dec. 10, 2010. |
USPTO Office Action for U.S. Appl. No. 12/130,424, mailed Mar. 29, 2010. |
Microsoft, “How SNMP Works,” <http://technet.microsoft.com/en-us/library/cc783142(v=ws.10).aspx>, retrieved Aug. 14, 2012, 9 pages. |
Microsoft, “How to configure Network Security for the SNMP Service in Windows Server 2003,” <http://support.microsoft.com/kb/324261>, retrieved Aug. 14, 2012, 3 pages. |
USPTO Office Action for U.S. Appl. No. 12/130,424, mailed Aug. 21, 2013. |
USPTO Office Action for U.S. Appl. No. 12/130,424, mailed May 2, 2013. |
Number | Date | Country | |
---|---|---|---|
20100223473 A1 | Sep 2010 | US |