Detecting network devices and mapping topology using network introspection by collaborating endpoints

Detection of network devices (e.g., stealth devices) and mapping network topology are performed via network introspection by collaborating endpoints/nodes. The method includes receiving (e.g., by a node on a network) an assignment to be a supernode that will manage multiple agents of a subnetwork within an overall network. This assigned supernode instructs two or more of the agents to perform a set of network traffic fingerprinting tests of the subnetwork by passing information across the subnetwork to each other. The supernode receives results of the tests from the clients and detects one or more intermediate devices located between the clients based on an effect of the intermediate devices on the information passed between the clients. The supernode can further map the topology of the subnetwork (including the detected devices) which can be used in mapping the overall network topology.

BACKGROUND OF THE INVENTION

1. Field of the Invention

This invention pertains in general to computer security, and more specifically to detecting network devices and to mapping the topology of networks using network introspection by collaborating nodes/endpoints.

2. Description of the Related Art

In order to effectively protect networks, it is necessary to gather information about these networks and determine their configuration. Situational awareness for system and network administrators in large, distributed enterprise organizations requires detailed understanding and information about the networks supporting the organization's information systems and the assets running on those networks. Networks are constantly changing as assets come and go and network elements are configured and reconfigured to provide required services.

Yet, understanding networks is a difficult problem. Information regarding the network, including network topology and configuration, is difficult to collect and costly to maintain due to the different types of network equipment, each potentially requiring proprietary software for administration and monitoring. There are also significant challenges in the processes and tools that acquire and continuously maintain the relevant data, and these tools/protocols for network management are dependent upon proper configuration and administrative control. Further, production networks tend to grow by accretion, with branches, subnetworks, and servers added on an as-needed basis. As networks get larger, responsibility (and authority) over such networks tends to become more convoluted. In large enterprises, the responsibility for security is generally divided into entirely different organizations, and different aspects and regions of the networks are further divided. Limited and/or out-of-date views severely hamper the ability to detect the presence of attacks and attackers (including potentially malicious “stealth” devices), or result in networks that are needlessly open. In addition, the process for collecting topology information is so labor intensive that mapping occurs sporadically and quickly becomes out of date.

Current technologies in the areas of network mapping, network coordinate systems, bandwidth estimation, and network tomography have been unable to solve these problems. These approaches are commonly applied to the problem at the scale of mapping the Internet and do not utilize key advantages that one has when mapping the network topology of a managed enterprise. Even products that provide some enterprise-scale network-management capabilities generally use network-management protocols to communicate directly with network devices and ask them for information about the systems with which they have communicated. These products require administrators to know which devices form the backbone of their network, and do not provide management privileges over, or the ability to communicate with, all forms of network devices. Further, these products cannot identify systems that fail to identify themselves in response to identification requests or that report themselves as one entity, but may actually be a very different entity (e.g., a stealth or rogue device). Other tools rely on various protocols to build a picture of what is actually present on the network, but these point-in-time scans quickly become out of date and also tend to focus on mapping of the entire Internet.

Therefore, there is a need in the art for a solution that reliably and securely detects network devices (including devices that may be hiding from detection or reporting themselves as something different from what they actually are), and that can also map the topology of regularly changing networks in real-time and can accurately maintain this topology over a period of time.

DISCLOSURE OF INVENTION

The above and other needs are met by a computer-implemented method, computer system, and computer-readable storage medium in which a network detection sensor detects devices in a subnetwork based on communication between agents and maps a topology of the subnetwork. Embodiments of the computer-implemented method comprise receiving an assignment (e.g., to be a supernode managing multiple agents of a subnetwork), and instructing two or more agents to perform a set of network traffic fingerprinting tests of the subnetwork (e.g., by passing information across the subnetwork to each other for detecting whether any intermediate devices are located between the agents). The method also includes receiving results of these tests from the agents and detecting one or more intermediate devices located between the agents based on the effect of the devices on the information passed between the agents. The method also includes mapping (or modifying a map of) the topology of the subnetwork including the intermediate devices detected.

Embodiments of the computer-readable storage medium store executable computer program instructions for detecting devices in a subnetwork and mapping network topology The instructions comprise instructions for performing the steps of receiving an assignment (e.g., to be a supernode), and instructing two or more agents to perform a set of network traffic fingerprinting tests of the subnetwork. The instructions further comprise instructions for receiving results of these tests from the agents and detecting one or more intermediate devices located between agents based on the effect of the devices on the information passed between the agents. The instructions also include instructions for mapping (or modifying a map of) the topology of the subnetwork including the intermediate devices detected.

Embodiments of the computer system comprise a system for detecting devices in a subnetwork and mapping network topology. An assignment module receives an assignment (e.g., to be a supernode), and an instruction module instructs two or more agents to perform a set of network traffic fingerprinting tests of the subnetwork. A results-receiving module receives results of these tests from the agents and a detection module detects one or more intermediate devices located between the agents based on the effect of the devices on the information passed between the agents. A mapping module maps (or modifies a map of) the topology of the subnetwork including the intermediate devices detected.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

I. Management Architecture

FIG. 1is a high-level block diagram illustrating a networking environment/system100according to an embodiment. The network mapping system100can employ a managed overlay network for its management architecture, including a hierarchy of nodes with various layers of management. At the lowest level inFIG. 1are multiple subnetworks118, each having various nodes assigned to that subnetwork118. Specifically, each subnetwork118has a supernode111managing the agents on that subnetwork118and various agents110on each node on that subnetwork118. The supernodes115at the next level up in the hierarchy each manage a subnetwork114that includes some of the lower level subnetworks118containing the supernodes111and agents110. The central management server116and top-level supernode117sit at the topmost layer of the hierarchy and are responsible for mapping the entire network112that includes the various subnetworks114,118lower in the hierarchy. In this arrangement, the agents110can receive instructions from their supernodes111, and the supernodes111can receive instructions from various mid-level supernodes114, which can receive instructions from the top-level supernode117or from the server116. Only a limited number of agents110and supernodes111,115,117are shown inFIG. 1in order to simplify and clarify the description. However, embodiments of the computing environment100can have thousands or millions of agents110and supernodes111,115,117associated with many subnetworks114,118(as represented by the ellipses inFIG. 1), as well as multiple servers116. In addition, the number of layers can vary, and there can be many additional layers of the networking environment100including many different subnetworks besides subnetworks118,114shown inFIG. 1. As used herein, a “node” refers to a connection point or a communication endpoint on a network, and so can be any computer or device on a network, such as those hosting the agents110and supernodes111,115,117.

The central management server116serves information or content to agents110and supernodes111,115,117via the network112and via subnetworks118,114. In one embodiment, the server116is located at a website provided by SYMANTEC CORPORATION, although the server can also be provided by another entity. In another embodiment, the server116is a top-level server or management server in an enterprise. The server116can include a database109storing information (e.g., a fingerprint database109storing fingerprint data identifying network devices, a mapping database for storing network topology mapping data) and a web server for interacting with agents110and supernodes111,115,117. The database109is shown as being connected to the server116, but various nodes may have access to this database109or a portion of it either via the server, via the top-level supernode, or directly. The server116can send information (e.g., instructions for performing network testing, software updates) across the network112and to the agents110or supernodes111,115,117. The server116can also collect or receive information from the agents110and supernodes111,115,117(e.g., reports of network testing results; data regarding mapping of subnetworks). One or more of the functions of the server116can also be executed on the agent110, on supernodes111,115,117, or in a cloud computing environment. As used herein, cloud computing refers to a style of computing in which dynamically scalable and often virtualized resources are provided as a service over the Internet.

The agents110are computers or other electronic devices that can interact with a supernode111,115,117, and with other agents110. In some case, the agents110interact directly or indirectly (via supernodes111) with higher-level supernodes115,117and the central management server116. These agents110are “managed clients” in that they are endpoint systems operating within an enterprise, under control of, and managed by, the enterprise's system administrators. The supernodes111,115,117are also computers or other electronic devices that can interact directly or indirectly with the central management server116, with other supernodes, and with the agents110. Further, the supernodes111,115,117are also “managed clients” that have been temporarily assigned, through a selection process, to act as supernodes that will perform network data collection and network mapping. The agents110and supernodes111,115,117for example, can be personal computers executing a web browser that allows the user to browse and search for information available at a website associated with the server116. In other embodiments, one or more of the agents110or supernodes111,115,117are network-capable devices other than a computer, such as a personal digital assistant (PDA), a mobile telephone, a pager, a television “set-top box,” etc. Any of the agents110or supernodes111,115,117could also be a server. The agents110and supernodes111,115,117preferably execute an operating system (e.g., LINUX®, one of the versions of MICROSOFT WINDOWS®), which controls the operation of the computer system, and executes one or more application programs.

The agents110and the supernodes111,115,117can perform activities and make requests for or otherwise acquire information (e.g., instructions to perform network testing, software updates). These can be requests to the server116, to the supernodes111,115,117or other computers. The agents110and the supernodes111,115,117can also send information (e.g., reports of network testing results, data regarding mapping of subnetworks). The information can be sent to the server116, supernodes111,115,117or other computers. In some embodiments, one or more of the supernodes111,115,117are agents that have been designated to act as supernodes that are responsible for mapping a portion of or all of a network, including managing other agents110. Thus, whether a node in the middle of the hierarchy is a supernode or an agent can be a matter of perspective, since a given node, such as node111ofFIG. 1, can be a supernode relative to the agents110, but can be an agent110relative to supernodes115,117.

The network112and subnetworks114,118enable communications among the entities connected to them. In one embodiment, the network112is the Internet, and one or more of the subnetworks114,118are intranets or networks within intranets. In another embodiment, the network112is an intranet, and the subnetworks114,118are site networks or other smaller divisions of networks within the intranet. The subnetworks114,118can include a small group of agents110(e.g., two or more) within a network112or they can include a larger group of agents110(e.g., hundreds, thousands, millions of agents110). The networks112,114,118can use standard communications technologies and/or protocols. Thus, the network112,114,118can include links using technologies such as Ethernet, 802.11, worldwide interoperability for microwave access (WiMAX), 3G, digital subscriber line (DSL), asynchronous transfer mode (ATM), InfiniBand, PCI Express Advanced Switching, etc. Similarly, the networking protocols used on the networks112,114,118can include multiprotocol label switching (MPLS), the transmission control protocol/Internet protocol (TCP/IP), the User Datagram Protocol (UDP), the hypertext transport protocol (HTTP), the simple mail transfer protocol (SMTP), the file transfer protocol (FTP), etc. The data exchanged over the networks112,114,118can be represented using technologies and/or formats including the hypertext markup language (HTML), the extensible markup language (XML), etc. In addition, all or some of links can be encrypted using conventional encryption technologies such as the secure sockets layer (SSL), transport layer security (TLS), virtual private networks (VPNs), Internet Protocol security (IPsec), etc. In another embodiment, the entities use custom and/or dedicated data communications technologies instead of, or in addition to, the ones described above.

In the embodiment illustrated inFIG. 1, all of the agents110and supernodes111,115execute a network detection sensor120for detecting devices in a subnetwork114,118within an overall network112based on communication between agents110. Also in the embodiment ofFIG. 1, the central management server116executes a network mapping manager130. In some embodiments, the top-level supernode can execute a network detection sensor120or a network mapping manager130, or both. The network detection sensor120and network mapping manager130can be discrete application programs, or can be integrated into another application program or the operating system of the agents110, supernodes111,115,117or server116. In some embodiments, a sensor120or a portion of a sensor120is executed on the central management server116or in a cloud computing environment. Similarly, the network mapping manager130or portions thereof can be executed on other nodes in the system100or in a cloud computing environment. In addition, various portions of or functions of the network detection sensor120or network mapping manager130can sometimes be divided in different ways across agents110, supernodes111,115,117and servers116.

The network detection sensor120can have a variety of functions which can differ based on the machine on which the module120is running and the current status of the machine in the networking environment100. For example, when the module120is running on a supernode111,115,117, the module120can perform more managerial functions (e.g., instructing agents110regarding what network tests to perform). When the module120is running on an agent110that is performing network testing, the module120can perform subordinate functions (e.g., receiving instructions regarding the network tests to perform). As stated above, in some embodiments, one or more of the supernodes111,115,117can be agents110and perform managerial and subordinate functions. Further, the status of a node can change over time, such that agents110can sometimes become supernodes111,115,117and supernodes111,115,117can become agents110. Similarly, since there can be multiple layers of management in the network mapping system100, there can be different levels of supernodes in the structure, and a supernode can be promoted to a higher-level supernode or demoted to a lower-level supernode. Thus, as each node changes levels in the hierarchy, the functions of the network detection sensor120executed by that node can also change.

In brief summary, the network detection sensor120detects devices in a network (or in a subnetwork114,118of an overall network112) based on communication between agents110. The sensor120can receive (e.g., from the central management server116or a supernode111,115,117) an assignment in the network hierarchy. For example, the sensor120might receive instructions to act as a supernode in some level of the hierarchy or to act as an agent110. Where the sensor120receives an assignment to be a supernode111,115,117, the sensor120can instruct two or more agents110to perform a set of network traffic fingerprinting tests of the subnetwork114,118mapped by that supernode. The sensor120of the supernode receives the results of the tests from the agents110and detects any intermediate devices (e.g., stealth devices hiding on the network or previously undetected devices) located between the agents110based on the effect of the intermediate devices on information passed between the agents110. The sensor120can further use this data in mapping the topology of the subnetwork114,118, which can be combined with results from other supernodes for mapping all of or a larger portion of the network112.

Where the sensor120receives an assignment to be an agent110, it performs the testing side of the operation instead of the managerial role. In some embodiments, no assignment is given because any node that is not assigned to be a supernode is by default an agent110. The sensor120can receive instructions from a supernode111,115,117to perform a set of network traffic fingerprinting tests of the subnetwork114,118by sending information back and forth with other agents110in the subnetwork114,118. It can provide the test results to the supernode111,115,117which can be used in detecting devices and mapping the network topology. In some cases, the sensor120may be performing both managerial and subordinate operations. It may perform supernode functions by providing testing instructions and collecting the results, but it may also be itself performing some network testing based on instructions from a higher-level supernode and providing results to that higher-level supernode.

In implementing the network detection sensor120, the system100can take advantage of a pre-existing management infrastructure of an enterprise's network, including many “managed clients” of the network that can be utilized by the system100as agents. Each of these managed clients used as agents110by the system100can include at least one ubiquitous endpoint security solution or management program via which the central management server116or top-level supernode117can easily deploy sensors120to the agents110, can appoint certain agents to be supernodes, can collect reports from agents/supernodes, and can send out updates to the agents/supernodes, and so forth. Further, these agents110are trusted systems (e.g., having a security code or other verification method to ensure their reliability) that provide a mechanism to deploy software securely. In this manner, the system100provides a managed overlay network that uses the agents from this pre-existing infrastructure to extend the system's functions of performing device detection and mapping the network. The system100can communicate with and distribute sensors120to remote corners of the network112to develop a much more thorough map of the network topology. The network detection sensor120is described below in more detail with regard toFIG. 3.

Referring now in brief summary to the network mapping manager130, this manager130provides the overall management of the system100. The network mapping manager130handles the creation of the management architecture of system100by dividing the network112into various components of the hierarchy or subnetworks114,118. The manager130further appoints various supernodes to be responsible for mapping the subnetworks, and manages the reconfiguration of the system100where needed (e.g., appointing of additional supernodes, demoting of supernodes, merging of subnetworks). In addition, the manager130collects testing results and/or mapping data from the various supernodes111,115,117regarding their subnetworks114,118and uses this to map the overall network112.

As used herein, the term “intermediate device” or “intermediary device” refers to a device for which detection is desired, that is located between and connected via a network/subnetwork112,114,118to two or more nodes (e.g., agents110, supernodes111,115,117), including devices that have not been previously detected/mapped, stealth devices (e.g., rogue machines, rogue access points, and backdoors to the Internet, “bumps on the wire,” transparent devices that attempt to hide their presence), and also stealth devices that are malicious (e.g., performing some damage or harm to the network, surreptitiously collecting information for a harmful purpose or in an undesired way). The system100can also detect other information regarding devices (e.g., by collecting configuration data on these devices, themselves), including identifying nodes that are using virtualization, dual-homed, network sharing, and performing other on-host techniques that could circumvent network security policies.

FIG. 2is a high-level block diagram illustrating an example of a computer200for use as a server116, a supernode111,115,117, and/or an agent110. Illustrated are at least one processor202coupled to a chipset204. The chipset204includes a memory controller hub220and an input/output (I/O) controller hub222. A memory206and a graphics adapter212are coupled to the memory controller hub220, and a display device218is coupled to the graphics adapter212. A storage device208, keyboard210, pointing device214, and network adapter216are coupled to the I/O controller hub222. Other embodiments of the computer200have different architectures. For example, the memory206is directly coupled to the processor202in some embodiments.

The storage device208is a computer-readable storage medium such as a hard drive, compact disk read-only memory (CD-ROM), DVD, or a solid-state memory device. The memory206holds instructions and data used by the processor202. The pointing device214is a mouse, track ball, or other type of pointing device, and is used in combination with the keyboard210to input data into the computer system200. The graphics adapter212displays images and other information on the display device218. The network adapter216couples the computer system200to the network116. Some embodiments of the computer200have different and/or other components than those shown inFIG. 2.

The computer200is adapted to execute computer program modules for providing functionality described herein. As used herein, the term “module,” “network detection sensor,” or “network mapping manager” refers to computer program instructions and other logic used to provide the specified functionality. Thus, a module/sensor/manager can be implemented in hardware, firmware, and/or software. In one embodiment, program modules/sensors formed of executable computer program instructions are stored on the storage device208, loaded into the memory206, and executed by the processor202.

The types of computers200used by the entities ofFIG. 1can vary depending upon the embodiment and the processing power used by the entity. For example, an agent110that is a mobile telephone typically has limited processing power, a small display218, and might lack a pointing device214. The server116, in contrast, may comprise multiple blade servers working together to provide the functionality described herein.

FIG. 3Ais a high-level block diagram illustrating the functional modules within the network detection sensor120, according to one embodiment of the present invention. The network detection sensor120, in the embodiment illustrated inFIG. 3A, includes an assignment module302, a test-receiving module304, a testing module306, a reporting module308, an instruction module310, a results-receiving module312, a detection module314, and a mapping module316. Some embodiments of the network detection sensor120have different and/or additional modules than those shown inFIG. 3Aand the other figures. Likewise, the functionalities can be distributed among the modules in a manner different than described herein. Certain modules and functions can be incorporated into other modules of the network detection sensor120and/or other entities on the network112, including the server116.

The assignment module302of the sensor120receives an assignment from the server116(or from a supernode) regarding the role the node will play in the management structure. The module302can receive an assignment to be a supernode111,115,117that will manage multiple agents110of a subnetwork114,118, and that can be managed by one or more supernodes and the server116. The module302can also receive an assignment to be an agent110that will be managed by one or more supernodes111,115,117. In some embodiments, the module302can both be a supernode111,115,117and an agent110. In other embodiments, computers executing the sensor120are assumed by default to be agents, unless instructed otherwise to be supernode. In this case, the only actual assignments received are assignments to be supernodes.

Once the assignment has been received, the sensor120can take on the role assigned to it, whether it be subordinate (e.g., agent), managerial (e.g., supernode), or both.FIG. 3Aillustrates the subordinate modules (e.g., modules304through308) associated with the subordinate functions of performing network testing, and the managerial modules (e.g., modules310through316) associated with the supernode functions of managing various agents110. As noted above, however, the roles of any given node on the network112can vary, so the sensor120on each node is capable of performing either or both managerial and subordinate tasks depending on the role assigned to that sensor120. Thus, while the subordinate modules are described predominantly in terms of agents' actions and the managerial modules are described predominantly in terms of supernodes' actions, any of these actions can be performed by either agents or supernodes.

Turning first to the subordinate modules of the agents110, the test-receiving module304receives instructions from the supernode to perform a set of network traffic fingerprinting tests of the subnetwork114,118. For example, the module304might receive instructions to pass information across the subnetwork to other agents for detecting whether any intermediate devices are located between the agents110. The module304might be instructed to send out a particular message or packet of data. The module304might be further instructed to respond in a particular way to a message or to data received from another agent110. Similarly, the module304might be instructed to perform monitoring of the subnetwork114,118, or otherwise individually collect data about the subnetwork114,118in a manner that does not require interaction with other agents110.

The testing module306performs the communication/fingerprinting tests received by the test-receiving module304and carries out the particular instructions indicated, including instructions to send and receive information across the subnetwork118,114to/from one or more other agents110. A variety of different tests can be performed by the testing module306, including those described below, and different tests can be dynamically generated. Throughout this description, it should be noted that the examples provide a sampling of tests that can be performed with system100, not an exhaustive catalog. One of ordinary skill in the art will recognize that many other testing options arc possible.

One embodiment of the testing procedures performed by the agents110is a client-to-client protocol for mapping intermediary network devices. In some embodiments, the agents110or supernodes (e.g.,111) can have an administrative channel (described regardingFIG. 3B) back to central management server116, and the system100can take advantage of this to coordinate testing of the link between two arbitrary agents110in an enterprise. Using a battery of tests, system100can determine the presence of one or more intermediate layer 1 devices (e.g., hubs or repeaters), layer 2 devices (e.g., network switches or network bridges), and layer 3 devices (e.g., network switches that process data at network layer or multi layer switches) on the network112. Based on the specific test results, the system100can infer the specific make and model of intermediate devices. When more than one intermediate device is present, system100can detect the composite results and will attempt to extract the full sequence of devices.

Before performing extensive network profiling, the testing module306can be instructed to perform initial querying/testing. The module306can query each device on the network to identify itself using a variety of common administrative port values. Further, when two agents110communicate, they can first use traceroute in some cases to determine the number of layer 3 devices between them. Traceroute is a commonly used command that sends out packets of information to a destination network address, and each intermediate computer along the path to the destinations responds, indicating its presence on the path and further providing data regarding the time taken for the packets to travel between each computer in the chain. But there may also be additional devices that offer layer 1 or layer 2 functionality, or that perform transparent in-line security functions without presenting their own Internet Protocol (IP) address or even Media Access Control (MAC) address. The system100can identify the presence of local layer 2 devices by the fact that they respond to Address Resolution Protocol (ARP) requests and present themselves. The existence of intermediate devices can further be inferred by the effect they have on passing traffic (e.g., data sent back and forth) between the agents110. This effect can be measured in latencies and also in specific packet transformations and restrictions that are observed with regard to the passing traffic.

The testing module306can use many characteristics of different network stack implementations to determine the hardware and/or operating system of an intermediate device. In some embodiments, it does this in a manner similar to that employed by Nmap, an open source utility for network exploration or security auditing. For example, there are a number of different strategies for choosing Transmission Control Protocol (TCP) sequence numbers—the module306can communicate several times with a target intermediate device to narrow down which strategy that target is using. The module306can use different combinations of TCP options flags and observe how the target responds to them. The module306can send a SYN/ACK packet or a RESET packet to a port that did not initiate a communication to see how it handles those error cases. It can send additional data to a port after the port is closed to see how it responds. A variety of additional tests can be performed by testing module306. Some examples are provided below.

a. Detecting Switches and Hubs

Although some network mapping tools (e.g., Nmap) can provide information about managed switches, they arc unable to detect unmanaged switches, to determine which machines are attached to which switch, or to detect when switches and hubs are being chained or lined up in a sequence on the network. The testing module306can apply device latency tests to uncover switches in series. Every hub and switch can have latency characteristics. Using various probes, the module306can detect the presence of intermediate switches and hubs within a subnetwork114,118. By initiating probes from many different agents110, the agents110can be grouped into classes. In embodiments involving a marginally-invasive protocol, an agent110can broadcast a request for other agents110on the subnetwork114,118to go silent in order to conduct the most accurate latency tests possible. Alternately, the other agents110can be told to flood the switch with traffic in order to determine how it handles such cases.

In addition to latency tests, the testing module306can use tests to tell if two devices are on the same switch by generating a false return MAC address from one agent110and then attempting to address packets to that MAC address from another agent110. If they are on the same switch, the traffic can be sent to the proper port. If they are not, the switch will not have seen the false address and will broadcast the connection attempt. If necessary, a third agent110can be involved to watch for these broadcasts.

In order to get specific information about the model of switch being used, the testing module306can generate a sequence of false MAC addresses in order to overflow the address table in the switch (e.g., using the “macof” command in some LINUX distributions). This overflow condition can be observed by sending a correctly addressed packet and determining whether it is broadcast or simply delivered. Cheaper switches generally have much smaller address tables and can be easily overflowed. By varying these tests, the size of the address table can be estimated. All of these characteristics can be combined to provide an estimate of the hardware present on the subnetwork114,118. These techniques can also be employed to attempt to identify logically distinct switches that may in fact be a virtual local area network (LAN) residing on the same physical hardware. Further, managed switches and network access devices also generally implement the 802.1x protocol for network admission control. There are numerous implementations of this protocol and tests can be developed to differentiate between manufacturer implementations based on how they respond to error conditions, flooding, etc.

b. Basic Network Behavior

The testing module306can run a variety of tests to determine the basic network behavioral characteristics of the link between agents110. These low-level tests can be performed in isolation and also in combination with other higher-level protocols to determine characteristics of specific devices that might be filtering specific protocols. As one example, the testing module306can generate a series of packet fragments, some of which can be delivered in order, and others of which can be delivered out of order. If packet fragments are delayed until the entire packet is transmitted, it can indicate that some intermediary device is performing packet reassembly. The module306can also transmit series of overlapping packet fragments, such that certain parts of the packet are defined ambiguously in more than one fragment, again sending the fragments in different orders. The results can be observed to see what packet fragment disambiguation strategy is being used and provide insight into any intermediate device performing packet reassembly.

As another example, the testing module306can transmit a series of packets using different maximum transmission unit (MTU) values. If fragmentation occurs, this can indicate the presence of an intermediate link with a lower value. This can be used to detect the presence of certain wireless links and also specific VPN technology.

As a further example, the testing module306can test for the precise location (in hops) of an Intrusion Prevention System (IPS) device by taking advantage of a known vulnerability in the IP implementation for the hop limit/hop count field of the header. The agents110can synchronize the test, such that the receiving agent110understands the hop count from the sending agent110. It can then decrement the hop count by one and proceed to send a series of packets. By varying the hop counts and sending some packets multiple times with different hop counts, an intermediate IPS can be tricked into revealing itself when it blocks packets that it believes are duplicates. By varying the hop count, it is possible to pinpoint the location of the IPS in the sequence of layer 3 devices.

STUN (Simple Traversal of UDP through NAT (network address translation)) and TURN (Traversal Using Relay NAT) are used by peer-to-peer protocols to map devices and their addresses to those present on the egress side of their access points. In another testing example, the testing module306can use this information to provide the specific addresses used in the address pool for devices utilizing Network Address Translation. This gives a better indication of the addresses used throughout the network and any private subnetworks being created by the NAT device. The testing modules306of two agents110can be instructed to have one agent110present itself as a STUN server and the other agent110initiate a STUN connection to it. The STUN protocol can determine a great deal of information about the specific type of any NAT device behind which the agent110resides. The protocol can then be repeated with the second agent110emulating a STUN server.

The testing module306can also be designed to detect the presence of Internet Protocol Version 6 (IPv6) and can use some of the transitioning technologies to determine the presence of devices that may provide IPv6 to IPv4 between two agents110. In some cases, a dual-stack implementation of IPv4/IPv6 may be required. For each IPv6 fingerprinting test described below, the agents110can synchronize the test such that an indication is returned on the reception or failure to receive the attack.

As a first example of an IPv6 test, one agent110can issue IPv6 renumbering and duplicate address attacks to another agent110when both have an IPv6 address assignment. The presence of a security device between the agents110will prevent the attack from occurring, and such a prevention can help to reveal this type of intermediate security device. As a second example, one agent110can issue an IPv6 Neighbor UnReachable attack to another agent110when both have an IPv6 address assignment. The presence of a security device between the agents110will prevent the attack from occurring, thus again revealing such an intermediate security device. As a third example, when one agent110has an IPv6 address assignment, it can issue an IPv6 to IPv4 Translation test to another agent110that does not have an IPv6 address. The presence of a gateway/router device between the agents110allows the transmission of traffic to occur. This test uses the Stateless IP/ICMP (Internet Message Control Protocol) Translation (SIIT) protocol to traverse the network access point. As a fourth example, when only one agent110has an IPv6 address assignment, it can attempt to issue an IPv6 to IPv4 Translation test to another agent110using Network Address Translation—Protocol Translation (NAT-PT) to traverse any intermediate network access point. A variety of other IPv6 tests are also possible.

The testing module306can also take advantage of higher-level protocols, such as Domain Name Service (DNS), SMTP, and HTTP to discover the presence of network security devices, such as firewalls, IPSs, and Intrusion Detection Systems (IDSs). Specifically, the module306can be used to take advantage of well-known limitations and vulnerabilities within these protocols to detect the presence of intermediate filtering, even when those filtering devices attempt to be transparent. Observing how the IPS treats each of these specific cases can provide a great deal of insight into the exact type of device present.

There are various different tests that the testing module306can use to identify DNS and security devices that may be in line to protect this service. As a first example, implementations of Berkeley Internet Name Domain (BIND) below version 9 did not randomize the transaction ID and are vulnerable to a replay attack. Most security systems are sensitive to this vulnerability and will automatically randomize the ID. The testing module306can exploit this feature of security systems by generating DNS traffic that uses sequential transaction IDs and observing whether they are rewritten or blocked (indicating an intermediate security device). Some security devices disallow DNS requests to arbitrary systems and may redirect the request, report an error, or simply drop the request. Each of these actions indicates the presence of a specific type of security device. As a second example, a known “Birthday Paradox” vulnerability can be used to determine the presence of a firewall, IPS, or IDS. For this test, multiple, simultaneous recursive queries for the same IP address can be sent by the testing module306to the DNS service. A firewall or an IDS/IPS will prevent recursive lookups and result in the request being dropped or modified, thus indicating that such a firewall or an IDS/IPS is present. As a third example, since Nov. 1, 2007, the address for the L Root server has changed from 198.32.64.12 to 199.7.83.42. Many firewalls will prevent or redirect this request to the correct L Root server, again revealing their presence on a network. As a fourth example, a restriction on truncated DNS UDP packets can be used by the testing module306to determine the presence of a firewall. In general, firewall implementations prevent the response of a UDP DNS request on port53to be truncated. If an intermediate security device is present, it will either redirect the request using TCP, or fail and return an error to the agent110requesting the lookup.

The SMTP mail delivery service is ubiquitous and has a history of significant vulnerabilities. A variety of different SMTP fingerprinting tests can be performed by the testing module306to exploit these vulnerabilities. As a first example, embedded content within an SMTP response can be used by the testing module306to detect the presence of a firewall with anti-virus capability. A first agent110can send an SMTP request with embedded content and a known (opaque) vulnerability. Modification of the content in the request, or the return of an error message to the sender, indicates the presence of an anti-virus capable intermediate device. This test can be performed bidirectionally to detect both ingress and egress filtering. As a second example, some firewalls and IPS devices limit the size and content type, which is reported in the SMTP header “CONTENT-TYPE” and “CONTENT-DISPOSITION.” Many implementations limit this size, with some limiting to 200 and others to 1024, whereas the actual allowable size defined within RFC 2822 is 8192. The testing module306can issue a number of requests of various types using the known default sizes for different brands of firewalls and can observe which ones are truncated or blocked, indicating the presence of an intermediate device. As a third example, every firewall and IPS/IDS device prevents the use of known vulnerabilities within the SMTP “command” request, particularly with any use of the “DEBUG” or “Wiz” commands. Particular implementations can differ, however. Some firewalls parse the header and only block requests that have these strings in the COMMAND field. Others simply scan the entire header and block anything containing those strings. This can be used to detect intermediate devices and to identify the particular implementation used.

Like SMTP, HTTP is both ubiquitous and has numerous vulnerabilities. It is also used to tunnel other services. Observing how thoroughly a device filters HTTP misuse provides insight into the specific device. As a first example, the testing module206can embed specific vulnerabilities into HTTP traffic and observe which ones are blocked. These can range from trivial header buffer overflows to complex JavaScript race conditions, and can be used to identify the sophistication of the filtering device. Varying the age of vulnerabilities can also help to identify the age and version of the filtering device. As a second example, the testing module306can send instant messenger, Simple Object Access Protocol (SOAP), and Secure Shell (SSH) traffic through ports80and443. A simple filtering firewall will allow these. A more complex proxying firewall will block one or more of them. This test can be used to distinguish between these two firewall types. As a third example, HTTP provides the ability to perform anti-virus scanning in such a way that the response to the server is “trickled” to prevent session timeouts. One agent110can request a large document from another agent110, which requires trickling. Based on the inability to trickle (e.g., a timeout occurs) or the trickle method used, the intermediate security device can be detected and characterized. These are just some examples, and a variety of other higher-level protocol tests are also possible.

2. Client Data Collection

In addition to the client-to-client protocol, there is a great deal of relevant network information that can be collected on and by each agent110individually. Each agent110can have the following capabilities in addition to the client-to-client protocol described above:

1. Passive monitoring of traffic (primarily broadcast) on local network interfaces

2. Preliminary data collection

3. Collecting of host-based network information

4. Monitoring of wireless network interfaces on the system

Each of these capabilities is described below.

a. Passive Monitoring of Broadcast Traffic

The testing modules306of agents can monitor broadcast traffic. Modern networks are extremely chatty. Although switched environments have reduced the ability to listen promiscuously to other agents' traffic, there is still a significant amount of broadcast traffic providing information about local network entities and services. At the lowest levels, devices use ARP broadcasts to map IP addresses to MAC addresses. Also, file and printer sharing services use Name Message Block (NMB) broadcasts to map machine names to physical addresses. This trend is increasing—modern printers and other devices use Zero Configuration Networking (zeroconf), such as Bonjour, to facilitate plug and play discovery. Even when devices are not actively broadcasting, they are often configured to respond to broadcast requests for information, allowing any host on the same network segment to locate them. The testing module306of an agent110can maintain a list of all local MAC and IP addresses that it has observed broadcasting on its local segment. When requested, the agent110can maintain a list of all Bonjour, NMB, and other broadcast service advertisements or requests that it observes. The agent110can also maintain a lightweight list of three-way handshake information for recent TCP connections involving the host.

b. Preliminary Data Collection

The testing modules306of the agents110can perform certain preliminary testing in a manner similar to that done by Nmap. For example, ARP requests can be used to derive a list of active devices on the local network. Each device can then be enumerated to ascertain the network protocols capable within that targeted device. The module306can determine the use of IPv4 or IPv6 and, using reverse DNS resolution, can determine the names of the devices found. For each device, it can use targeted probes to derive a set of features that are available for the system. This information can be used for device classification because it provides data needed for identifying systems that have a rich set of features enabled and that can act as more than just a network endpoint. For those devices that have extended features, such as HTTP, SMTP, or other services, the module306can ascertain the protocol versions and implementations in use. In addition, the module306can determine the specific operating system that a device is running

The testing module306can use a traceroute facility (e.g., such as that within Nmap) to determine which devices act as access points to extended networks. For this operation, two traces can be obtained, one to an Internet-identified agent110and the second to the assigned supernode. This information can be used for both the mapping of the network and the identification of routers, gateways, firewalls and other security devices that may reside in the egress and ingress paths. Many devices may be readily identifiable. For example, most routers and managed switches have an administrative port that will provide the model and version of the device using protocols such as HTTP, Universal Plug and Play (UP&P), or Simple Network Management Protocol (SNMP). Databases of these characteristics of routers and managed switches provided by other mapping tools (e.g., Nmap) can be also used in this mapping. Before performing extensive network profiling, the module306can ask each device to identify itself using a variety of common administrative port values. A tentative network model can be constructed from these replies and then verified using the client-to-client protocol and other communication testing. The module306can also attempt to profile both local systems and other enterprise systems with which the agents110interact. In a managed enterprise, agents110often do not interact directly with external systems for services—communications are with internal proxy or application servers (web, mail, internal applications, file, authentication and directory, network-attached storage) and other agents110. Each supernode111,115,117can compile a list of the servers with which its agents110communicate, as well as the protocols used. It can then collect information about those servers (e.g., using basic facilities provided by other networking tools, such as Nmap) and can incorporate them into the network model. If more details are required, the system100can assign a single supernode with the responsibility of performing additional testing and mapping it in detail.

c. Collecting of Host-Based Network Information

The testing modules306of agents110can also be used for collecting host-based network information. Modern agents110are becoming increasingly complex. The vast majority of laptops now contain more than one network interface and some contain as many as four. Virtualization is becoming increasingly common as a way of providing backwards- or cross-compatibility. Many APPLE® systems use virtualization to run MICROSOFT® operating systems, and WINDOWS 7® includes virtualization for running WINDOWS XP® programs. Many agents110now contain wireless hardware that, even when not in use, represents a risk of data exfiltration or network bridging. Finally, agents110can host software that provides overlay networks, tunneling, cloud services, and other services meant to bypass corporate firewalls or corporate security policy. All of these client-based networking concerns manifest themselves as normal network traffic. While they could be discovered through deep packet inspection or traffic profiling, it is more straightforward to collect this information on each agent110. An agent110can report a list of every local network interface (including virtual network devices) that it observes, providing the IP, MAC, netmask, and local routing rules. The agent110can further use a variety of techniques to reliably determine whether the managed system itself appears to be running on a virtual machine.

d. Monitoring of Wireless Interfaces

The testing modules306of agents can also be used for monitoring of wireless interfaces. When wireless hardware is available and in use, an agent110can maintain a list of each of the broadcasting wireless networks that it observes or joins, including SSID, signal strength, and encryption. When wireless hardware is available but not in use, the agent110can be capable of performing sniffing of local wireless traffic in order to observe networks that are being used but not broadcasting their service set identifications (SSIDs). Any attempts to connect to hidden networks can be reported with the MAC address of both the origin and destination devices. In some embodiments, the testing module306uses Aircrack-ng program functionality to crack weak Wired Equivalent Privacy (WEP) keys and determine whether any traffic traversing over those networks either originates from, or is destined to, a managed enterprise host.

Returning again to the subordinate modules ofFIG. 3A, the reporting module308provides the results of the tests performed by testing module306to the supernode111,115,117for detection of intermediate devices located between the agents110(e.g., based on an effect of the intermediate device on the information passed between the identified agents). In cases where the agent110that performed the testing is a supernode within a larger subnetwork managed by a higher-level supernode, the reporting module308of the supernode can provide the results of the tests to the higher-level supernode.

Turning next to the managerial modules of the supernodes111,115, the instruction module310can identify two or more of the agents110to perform a set of network traffic fingerprinting tests of the subnetwork114,118, and can then instruct those identified agents110to perform the tests. The module310can instruct the agents110to perform any of the tests described above, including various client-to-client communication tests involving passing information back and forth among the agents110. The testing instructions can be received by test-receiving module304and performed by testing module306of the agents110. The supernode111,115,117will have a reliable communication channel with one or more agents110, and so the supernode111,115,117can instruct the various agents110about which tests to perform and when to perform them. It can then collect data from the various agents110and correlate the results. In some embodiments, the supernode111,115,117can exploit the results of early tests to focus further tests using a decision-tree model.

In some embodiments, the supernode111,115,117uses a two-phase commit model to coordinate agents110. It can deliver the instructions to two agents110, and then notify the two agents110when both agents110have acknowledged the instructions. The agents110can both begin monitoring the network at the first message from the supernode111,115,117, but may only begin transmitting data at the second message from the supernode111,115,117. Both agents110can use some reasonable timeout to abort if messages are lost. As part of the test suite, the agents110can attempt to find at least one open port between them. If any such port exists, they can use it to deliver synchronization messages. Otherwise, they can report to the supernode111,115,117to determine whether any further testing is needed.

The results-receiving module312receives results of the tests from the agents110. In some embodiments, the results received are the raw results of the testing performed (e.g., the data returned or the observations made as a result of performing the tests). In other embodiments, the agents110have performed some additional analysis or interpretation of the results, including determining particular information about an intermediate device (e.g., the type of device, where it is located, what it is connected to). In this case, the results received may include additional information about detected devices.

In embodiments in which the supernode is a higher-level supernode115,117, the results-receiving module312can receive, from lower-level supernodes (e.g., supernodes111), testing results for each of the subnetworks118managed by those lower-level supernodes. For example, supernode111managing a number of agents110can collect testing results from those agents110and provide those to supernode115, and supernode115can similarly receive testing results from various supernodes111that can be used for device detection/topology mapping. The results received can include identifying data about the various devices detected on the subnetwork, including the type of device, its operation parameters, where it is located and how it is connected to other devices, etc. In some embodiments, each supernode111is responsible for mapping its subnetwork118, and the results provided to the higher-level supernode115are the mapping results from the topology mapping of the subnetwork118(described below).

The detection module314detects one or more intermediate devices located between the agents110based on an effect of the intermediate devices on the information passed between the agents110or based on other characterizing information about the intermediate devices. For example, the module314can interpret the results of the various tests described above that were performed by the testing modules306. The module314can determine information, such as whether an intermediate device is present, what type of device it is including the specific make and model or version, how it is implemented, where it is located, the physical ordering of intermediate devices relative to other such devices or relative to the agents110, to what other devices it is connected, operation parameters of the intermediate device, whether an intermediate device is failing to respond to requests to identify itself, whether it is a stealth device (e.g., hiding from detection, a rogue device or wireless access point), whether it is malicious, whether it is collecting data regarding the network, and other characterizing data.

These various data points collected about the intermediate device by a number of agents110can be combined by the detection module314to form a fingerprint or signature for the intermediate device. In some embodiments, the detection module314compares the fingerprint to a fingerprint database109for network devices to determine what type of network device it is or to otherwise classify the device. In these embodiments, the comparison can be done by providing the fingerprint information up to various higher-level supernodes, where it can be combined with other fingerprint data, until the complete collection of fingerprint data is received by the top-level supernode117which performs the comparison to the fingerprint database or provides the data to the server116for this comparison. In other embodiments, other supernodes may also have access to the database109or a portion of it to perform the comparison or a part of the comparison. A fingerprint set can be used to validate the request or response of a network device, including validating that a network device is really what it says it is in response to a request to identify itself.

As new devices are detected that had not previously been detected, the system100(e.g., the server116or certain supernodes) can dynamically generate new fingerprint tests for detection of this new type of device. These tests can then be provided to some or all of the supernodes on the network112. These supernodes receive these dynamically-generated tests and can then instruct their agents110to perform these tests when needed, and can apply these to detect other instances of the new type of device. These fingerprints may further be automatically updated to support additional tests or identify additional devices. Fingerprint definitions may be provided by a number of sources (e.g., research labs and security response teams). A combination or series of fingerprints can be grouped to define a single device fingerprint. Full sets or subsets of these fingerprints can be deployed to the detection module314, depending on the detection requirement of the subnetwork.

The mapping module316can map the topology of the network112,114,118including the one or more intermediate devices detected. This mapping can also include modifying a model of the topology of the network112,114,118to include the devices. The module316can also report, via reporting module308, the mapping results up the chain of management to the higher-level supernodes, and possibly ultimately to the top-level supernode117and/or central management server116. In some embodiments, each supernode111,115,117maps its respective network/subnetwork. For example, a lower-level supernode111can map its subnetwork118, and can provide the local mapping data to supernode115, which incorporates the mapping results along with results from other lower-level supernodes111to map its own subnetwork114. This can continue up the chain until the entire network112has been mapped (or its existing map has been modified accordingly). In other embodiments, each lower supernode is not responsible for mapping its own local subnetwork, but instead provides the results up the chain to a higher-level supernode or to the top-level supernode117or server116for performing the mapping/modifying of the network topology. The module316can store the map or data associated with the map or its modification (or can provide this information to higher supernodes or to the server for storage) in a database (e.g., database109).

III. Network Mapping Manager130of Central Management Server/Supernode

FIG. 3Bis a high-level block diagram illustrating the functional modules within the network mapping manager130that can be present on the central management server116and/or on the top-level supernode117, according to one embodiment of the present invention. The module130, in the embodiment illustrated inFIG. 3B, includes a grouping module352, an appointment module354, a collection module356, and a mapping module358.

The grouping module352groups the network112into multiple subnetworks114,118. With the management architecture described above, the mapping and detection of devices can be divided amongst subcomponents of the network112. If every agent110were to collect all the possible data available to it, the networking environment/system100would be overwhelmed. The management hierarchy prevents this by decomposing the detection of device and network mapping into subproblems that are managed within each subnetwork by the agents110and supernode111of that subnetwork, and the results then can be aggregated and reported to higher level supernodes in the hierarchy. In this manner, the management burden can be distributed to some of the agents110that can be designated as supernodes, so that when a remote section of the network is to be mapped, the coordination of that effort can occur on a system local to the remote network, which can deliver the final results to a centralized management server116or top-level supernode117.

In setting up the management hierarchy, the grouping module352initially collects rudimentary network data from each agent110(e.g., IP address, subnet, and local gateway for each interface). The module352can use this information and any other data collected (e.g., Time To Live (TTL) on packets received from the agent110) to group nodes into candidate equivalence classes (e.g., subnetworks). Further, in enterprise networks in which there are no agents110on certain portions of the network, such as a data center, an agent110can be added to the data center or a monitoring device can be developed that can also listen on a spanning port in the data center.

The appointment module354assigns supernode status to various nodes in the network112. The module354can select nodes from each such group created by the grouping module352to act as local supernodes. In some embodiments, the supernodes are selected using a modified clustering algorithm. During analysis, the management server116may discover that a new supernode is required and can promote an agent110to a supernode111,115. In some embodiments, each supernode111,115is responsible for discovering and mapping the cluster of systems assigned to it under its subnetwork114,118. If one cluster is found to contain systems that are actually separated by network infrastructure equipment, the grouping module352can further decompose these into two clusters and the appointment module354can select a second supernode to manage the new cluster. In some embodiments, each supernode is also responsible for measuring the links to other supernodes. If two such supernodes are found to be equivalent, then the grouping module352can merge their clusters of systems or their subnetworks. In some embodiments, the module354incorporates a simple delegation model using chained digital signatures to ensure that agents110cooperate with the appropriate supernodes but cannot be fooled by any other agent110claiming to be a supernode.

Applying this approach recursively results in a tree-like decomposition of the network into a reporting hierarchy, and this decomposes a complex mapping problem into a number of much smaller problems that can be distributed across a number of systems. It ensures that each local network is mapped locally, and it prevents links between subnetworks from being saturated by hundreds of pairs of systems trying to test the same link.

The collection module356collects testing results and mapping data from the various supernodes111,115. As stated above, every supernode can be responsible for commanding and collecting the data from each of its agents110, thus decomposing the problem of mapping its section of the network, delegating responsibility to other nodes, and collecting and aggregating the results. The supernodes111,115can then provide the results of their testing/mapping up to the collection module356. In some embodiments, any or all of the nodes on the network112can include at least one ubiquitous endpoint security solution or management program (e.g., SYMANTEC® ENDPOINT PROTECTION (SEP), ALTIRIS® AGENT or CLIENT MANAGEMENT SUITE from SYMANTEC®). Via this mechanism, the central management server116or top-level supernode117can provide assignments to agents/supernodes, can collect reports from agents/supernodes, and can send out updates to the agents/supernodes. This type of infrastructure allows network detection sensors120to be easily distributed to most or all corners of a network112regardless of underlying network topology, and provides control channels between agents110(through the management server as intermediary if necessary). In some embodiments, since the server116gets certain data from an existing client management server associated with an enterprise, the server116might be on the same system as this client management server, though this is optional. However, in other embodiments, the sensors120do not depend on the existence of such a ubiquitous management system, but can be installed on lab systems and configured using conventional software deployment and configuration methods.

The mapping module358maps the overall network112. This module358can take all of the testing and/or mapping data collected by the various lower-level supernodes111,115and can combine this data to create a new network topology map or to modify an existing network topology map. In some embodiments, the entire network topology will be periodically regenerated in entirety. Other embodiments include an incremental model that periodically checks that the current topology is accurate and notifies the server116or administrator of only those elements that have changed. The module358can store the map or data associated with the map or its modification in a database (e.g., database109). Network maps are commonly presented visually, and in some embodiments, the system100can produce network maps in an XML format that can easily be integrated into other visualization tools. In other embodiments, a common tool for network diagrams, such as an exporter for MICROSOFT® VISIO, can be used.

IV. Methods of Operation

Referring now toFIG. 4, there is shown a flowchart illustrating the operation of the network detection sensor120, according to some embodiments of the present invention. It should be understood that these steps are illustrative only. Different embodiments of the network detection sensor120may perform the illustrated steps in different orders, omit certain steps, and/or perform additional steps not shown inFIG. 4.

As shown inFIG. 4, the network detection sensor120receives402an assignment in the hierarchy (e.g., receives an assignment to be a supernode or an agent110). In some embodiments, where no assignment is received, the sensor is by default an agent110. Where the machine is to be an agent110, the network detection sensor120receives404instructions from a supernode111,115,117to perform a set of network fingerprinting tests (e.g., to send certain information back and forth between agents, to collect certain data based on this information). The sensor120performs406the network fingerprinting tests instructed and provides408the results of the tests to the supernode111,115,117. The tests performed can be any of those described above, including client-to-client protocol tests and individual agent tests, or other similar types of tests. The sensor120can repeat the steps each time new instructions are received404.

Where the machine is appointed a supernode111,115,117, the sensor120instructs410two or more of the agents110identified to perform a set of network traffic fingerprinting tests of the subnetwork114,118, including any of the tests describe above, or other similar types of tests. In some cases, the tests may be one or more dynamically-generated tests received from the server116or higher-level supernode for detecting new or previously undetected devices. The sensor120receives412results of the tests from the agents110, and detects414one or more intermediate devices located between the identified agents110(e.g., based on an effect of the intermediate devices on the information passed between the agents110). In some embodiments, it does this detection by combining the data received from the testing into a fingerprint for an intermediate device that it can compare to a fingerprint database109or that it can provide to a higher level supernode or server116for comparison to a fingerprint database109. The sensor120can also map416the topology of its local subnetwork114,118or modify an existing network topology, and can store417the map generated. The sensor120can further report the results418(e.g., detection results or fingerprint data, local subnetwork mapping results) to a higher-level supernode, such as supernode115,117, or to the central management server116. The sensor120can repeat the steps each time it is necessary to instruct410an agent110regarding tests to be performed.

In some cases, the supernode can be a mid- or higher-level supernode (including top-level supernode117), and so it performs some additional steps. Instead of just reporting results to a higher supernode, it can also receive420results reported418by lower supernodes. The supernode can then combine422the results received420from one or more lower-level supernodes. In some embodiments, the supernode can also combine422the results received420from lower-level supernodes with results from its own detection416and/or mapping418steps. The supernode can further map424the topology of its network112,114,118or can modify an existing map to reflect the new devices detected, and it can store426the map created. The steps can be repeated as new results are received420. In some cases, the supernode only performs managerial steps, such as410to426and does not perform any of the steps associated with the agents, including steps404to408. In some cases, the supernode only performs managerial steps420,422,424,426and does not perform steps410to418, in which case the supernode only receives420results from other supernodes, but does not instruct410any agents110regarding performing tests.

In this manner, a thorough map of the overall network112can be generated by potentially enlisting every agent110on the network as a sensor and mapping agent, providing detailed visibility into all corners of the network, even those whose existence was not previously known by network management software. Rather than having a single- or limited-sensor view of the network (like many traditional network scanning tools), the system100takes advantage of having multiple agents110in providing and maintaining a more detailed and up-to-date map that tracks network configuration changes dynamically, in real time, from multiple viewpoints. The system100also avoids problems associated with lack of authorization or administrative privileges to communicate with all forms of network hardware, since it uses agents110and it only needs to profile examples of such devices in order to be able to identify them. The system100further takes advantage of the enormous processing power distributed across client workstations to divide and distribute the network mapping problem, and offers the scalability benefits of a peer-to-peer system, but takes advantage of the trustworthiness of agents to avoid much of the complexity from which traditional peer-to-peer systems suffer.

As will be understood by those familiar with the art, the invention may be embodied in other specific forms without departing from the spirit or essential characteristics thereof. Likewise, the particular naming and division of the modules, managers, features, attributes, methodologies and other aspects are not mandatory or significant, and the mechanisms that implement the invention or its features may have different names, divisions and/or formats. Furthermore, as will be apparent to one of ordinary skill in the relevant art, the modules, managers, features, attributes, methodologies and other aspects of the invention can be implemented as software, hardware, firmware or any combination of the three. Of course, wherever a component of the present invention is implemented as software, the component can be implemented as a script, as a standalone program, as part of a larger program, as a plurality of separate scripts and/or programs, as a statically or dynamically linked library, as a kernel loadable module, as a device driver, and/or in every and any other way known now or in the future to those of skill in the art of computer programming. Additionally, the present invention is in no way limited to implementation in any specific programming language, or for any specific operating system or environment. Accordingly, the disclosure of the present invention is intended to be illustrative, but not limiting, of the scope of the invention, which is set forth in the following claims.