Open for Voting

NTM - Distributed Scan input

I would like the NTM product to be able to do one of two things in a distributed network.

     1) Create a mapping "agent" on a remote network that can be managed from the central NTM and report the mapping results back to the central NTM for inclusion in large network maps.

     2) If #1 cannot be done, then provide a way that Nmap (or other tool) output from remote locations can be imported into a map in the NTM software.

  • You are correct in your assumptions.

    We use several other packages (Nessus Scanners, Splunk, etc) that use similar "agents" to perform the remote work. In the Nessus example, the remote agent only needs port 8834 open to the main machine.

    In this case, the Main (Primary) machine makes all of the rules, generates the config files, etc, and the remote (Secondary) machine phones home on a scheduled basis to fetch them, and then executes them on its own local environment. It then sends the results back via that same connection and the primary machine reports them to the user.

    The above would be the way that I would use it.

    I do see another option that should be considered, however. If for some reason the machines have absolutely no connectivity, the remote machine could be configured to perform scans on a schedule and then export the file to disk. This file could then be send via email or some other method (preferably secured) and "imported" into the primary machine. This was what I was thinking about the ability to read Nmap files in the beginning.

    Hope this helps!

  • I take it bandwidth is not the problem then.  Am I correct in assuming that a location could see all locations if not for the firewalls?  In other words, there is not segmentation due to IP overlap or no connectivity (VPN or circuits) between two locations?  Is the issue purely access through the firewall?

    Thinking this through, if the issue is purely the firewalls not permitting NTM discovery traffic through would a remote agent solve the problem?  One way or another that agent would need to communicate back to the central NTM node, either with initiation from the agent or from the central node.  That traffic would have to be allowed through the firewall.  If part of the goal is to not allow anything new through the firewall, then I'm not sure that would work.  It would definitely limit the traffic that needs to be allowed considerably.  Instead of allowing one machine to access many machines over many ports/protocols, you would only allow the agent to reach the central node through one port.  Would that be helpful enough or is there a better option?

  • In some degree, both. We have several subsidiaries that are tied together in a metropolitan LAN but some of their segments are firewalled for PCI and other reasons. It is not possible to have the NTM running on a single machine that can see ALL of the segments from where it sits. Right now I am physically taking a laptop with NTM on it to each segment every quarter to do scans of the topology for PCI documentation purposes. If I had one centralized NTM machine that could receive the output from some other "agent" (NTM lite, or nmap, etc) then I could incorporate the entire network ( I think). I realize that the "topology" information would not be available with something like nmap, but I would have to work that out.

  • Is the network distributed in the sense that it's large and spread over a WAN or distributed in the since that it's segmented by firewalls and other security functions?  I'd like to understand what the pain point is a bit better.  What do you do now given the absence of this distributed scan feature?