CAN UNCLASSIFIED
Remote Collection of Network Information (ReCoN)
Scott Milne Scott Milne Consulting Inc. Prepared by: Scott Milne Scott Milne Consulting Inc. 280 Albert Street, Suite 1000 (10th FLOOR) Ottawa, Ontario K1P 5G8 Task ID: 0007 Version: 1.0.2 PSPC Contract Number: W7714-176208/001/IPS Technical Authority: Jonathan Risto, Research Engineer Contractor's date of publication: January 2020 The body of this CAN UNCLASSIFIED document does not contain the required security banners according to DND security standards. However, it must be treated as CAN UNCLASSIFIED and protected appropriately based on the terms and conditions specified on the covering page.
Defence Research and Development Canada Contract Report DRDC-RDDC-2020-C076 May 2020 CAN UNCLASSIFIED CAN UNCLASSIFIED
IMPORTANT INFORMATIVE STATEMENTS
This document was reviewed for Controlled Goods by Defence Research and Development Canada using the Schedule to the Defence Production Act.
Disclaimer: This document is not published by the Editorial Office of Defence Research and Development Canada, an agency of the Department of National Defence of Canada but is to be catalogued in the Canadian Defence Information System (CANDIS), the national repository for Defence S&T documents. Her Majesty the Queen in Right of Canada (Department of National Defence) makes no representations or warranties, expressed or implied, of any kind whatsoever, and assumes no liability for the accuracy, reliability, completeness, currency or usefulness of any information, product, process or material included in this document. Nothing in this document should be interpreted as an endorsement for the specific use of any tool, technique or process examined in it. Any reliance on, or use of, any information, product, process or material included in this document is at the sole risk of the person so using it or relying on it. Canada does not assume any liability in respect of any damages or losses arising out of or in connection with the use of, or reliance on, any information, product, process or material included in this document.
Template in use: C20-0226-03436 - cover dcd.dotm
© Her Majesty the Queen in Right of Canada (Department of National Defence), 2020 © Sa Majesté la Reine en droit du Canada (Ministère de la Défense nationale), 2020
CAN UNCLASSIFIED Remote Collection of Network Information (ReCoN) Scott Milne Scott Milne Consulting Inc. Prepared By Scott Milne Scott Milne Consulting Inc. Task ID: 0007 Version: 1.0.2 PSPC Contract Number: W7714-176208/001/IPS Technical Authority: Jonathan Risto Contractor’s date of publication: January 2020
Page 1 of 31 Remote Collection of Network Information (ReCoN) Task ID: 0007 Scott Milne Jan 08, 2020 Version 1.0.2 REVISION HISTORY
DATE VERSION DESCRIPTION AUTHOR
Dec 2019 1.0.0 Scott Milne
Dec 2019 1.0.1 Updated based on feedback from DRDC Scott Milne
Jan 2020 1.0.2 Updated based on feedback from DRDC Scott Milne
Page 2 of 31 Table of Contents 1. INTRODUCTION ...... 4 1.1 ABSTRACT ...... 4 1.1.1 Background concept ...... 4 1.1.2 Results ...... 4 1.1.3 Conclusion ...... 4 1.2 PROJECT SCOPE ...... 5 1.2.1 Windows Hosts ...... 5 1.2.2 Linux Hosts ...... 6 1.2.3 Network Infrastructure Elements ...... 6 1.2.4 Firewall ...... 7 1.2.5 Peripherals ...... 7 1.2.6 Additional Considerations ...... 7 1.3 REFERENCES ...... 8 1.3.1 Product: Lansweeper ...... 8 1.3.2 Product: SolarWinds ...... 8 1.3.3 Product: GLPI with Fusion Inventory ...... 8 1.4 ASSUMPTIONS ...... 8 2. OVERVIEW ...... 8 2.1 OVERALL SUMMARY...... 8 2.1.1 Test Network ...... 8 2.1.2 Products Evaluated ...... 9 2.1.3 Products Not Fully Evaluated ...... 10 3. DETAILED ANALYSIS ...... 11 3.1 LANSWEEPER ...... 11 3.1.1 Test Network Topology ...... 12 3.1.2 Section 6.1 to 6.5 Summary ...... 12 Figure 3: Test Topology...... 12 3.1.3 Section 6.6 results ...... 12 3.2 SOLARWINDS...... 16 3.2.1 Test Network Topology ...... 16 3.2.2 Section 6.1 to 6.5 Summary ...... 17 3.2.3 Section 6.6 Results ...... 17 3.3 GPL WITH FUSION INVENTORY ...... 22 3.3.1 Test Network Topology ...... 22 3.3.2 Section 6.1 to 6.5 Summary ...... 23 3.3.3 Section 6.6 Results ...... 23 4. CONCLUSION ...... 26 APPENDIX A ...... 27 Section 6.1 - Windows ...... 27 Section 6.2 - Linux ...... 28 Section 6.3 - Network Infrastructure Elements...... 29 Section 6.4 - Firewall ...... 30 Section 6.5 – Peripherals...... 31
Page 3 of 31 1. Introduction 1.1 Abstract
1.1.1 Background concept 1. The COSW section at DRDC has been conducting significant work in the area of automated CND. The capability to accurately identify problems in the network and to offer remediation techniques requires that specific information be available from the assets and devices on the network. Network identification activities encounter various network states. The states that this work will be required to consider include: · Full network connectivity and uninterrupted access to internal and external resources (e.g. classic enterprise network with internet connectivity). · Limited or unstable/intermittent network bandwidth to remote sites (e.g. network connections between some network sites is limited) · No external network access (e.g. an isolated network) 2. For each of the network states 1-3 above, the COSW section requires the information listed in Sections 6.1-6.5 to be provided with consideration of the factors listed in Section 6.6. For each category of device/information, at a minimum two products must be identified that can provide the listed information. Both open source and commercial solutions should be considered if available. 3. The intent of an end-solution is to both gather and combine information on each type of asset into a central repository. Therefore, solutions that address all of the different technologies would be of interest, as would solutions that make such integration possible through open APIs or by exposing their databases. Suitability of each solution to this goal should also be considered.
1.1.2 Results 1. The results display the existence of products capable of collecting the required information, and where out of the box functionality lacks, can be supplemented by customizations. 2. Through the use of provided configuration optimizations, products can work in a network disadvantaged environment. This, when used in conjunction with product agents, can allow for a large amount of flexibility when working in different connected environments. This functionality also allows for scalability to large installation as well as heterogeneous connection state satellite sites
1.1.3 Conclusion 1. Products currently on the market place exist that can, with a certain amount of customization, collect and maintain an inventory of network elements in a variable connection state environment.
1.2 Résumé
1.2.1 Concept d'arrière-plan 1. La section COSW de RDDC a effectué des travaux importants dans le domaine des CND automatisés. La capacité à identifier avec précision les problèmes du réseau et à proposer des techniques de correction nécessite que des informations spécifiques soient disponibles à partir des actifs et des périphériques du réseau. Les activités d'identification de réseau rencontrent différents
Page 4 of 31 états de réseau. Les états que ces travaux devront prendre en considération sont les suivants: • Connectivité réseau complète et accès ininterrompu aux ressources internes et externes (par exemple, réseau d'entreprise classique avec connectivité Internet). • Bande passante réseau limitée ou instable / intermittente vers des sites distants (par exemple, les connexions réseau entre certains sites réseau sont limitées) • Pas d'accès au réseau externe (par exemple un réseau isolé) 2. Pour chacun des états de réseau 1 à 3 ci-dessus, la section COSW exige que les informations énumérées aux sections 6.1 à 6.5 soient fournies en tenant compte des facteurs énumérés à la section 6.6. Pour chaque catégorie d'appareil / d'informations, au moins deux produits doivent être identifiés pour fournir les informations répertoriées. Les solutions open source et commerciales doivent être envisagées si elles sont disponibles. 3. Le but d'une solution finale est de rassembler et de combiner des informations sur chaque type d'actif dans un référentiel central. Par conséquent, les solutions qui traitent de toutes les différentes technologies seraient intéressantes, tout comme les solutions qui permettent une telle intégration via des API ouvertes ou en exposant leurs bases de données. L'adéquation de chaque solution à cet objectif doit également être considérée.
1.2.2 Résultats 1. Les résultats montrent l'existence de produits capables de collecter les informations requises et, là où la fonctionnalité prête à l'emploi fait défaut, peuvent être complétés par des personnalisations. 2. Grâce à l'utilisation des optimisations de configuration fournies, les produits peuvent fonctionner dans un environnement réseau défavorisé. Ceci, lorsqu'il est utilisé conjointement avec des agents de produit, peut permettre une grande flexibilité lors du travail dans différents environnements connectés. Cette fonctionnalité permet également une évolutivité vers une grande installation ainsi que des sites satellites à état de connexion hétérogène
1.2.3 Conclusion 1. Il existe des produits actuellement sur le marché qui peuvent, avec un certain degré de personnalisation, collecter et maintenir un inventaire des éléments de réseau dans un environnement à état de connexion variable.
1.3 Project Scope 1. To identify products that satisfy some or all of the requirements listed by target category - Windows hosts, Linux hosts, Network Elements, Firewalls, and Peripherals. A minimum of 2 products must be identified for each of the requirements listed. 2. All products identified through this work must be standalone pieces of software, not native operating system commands. The products must also be actively maintained or updated products. 3. For each of the products identified the Additional Considerations section needs to be documented
1.3.1 Windows Hosts 1. IP address (s)
Page 5 of 31 2. Hostname/Computer name 3. OS name 4. OS version 5. Installed memory make, size, slot location and serial numbers 6. Installed hard-drive make, model, installation location and serial numbers 7. Motherboard serial number 8. Installed hardware (e.g. cards) 9. System UUID/ Device ID 10. Security software installed and state (enabled or disabled) 11. Active security software configuration (if possible) 12. Open ports and associated processes (at time of collection) 13. Installed software (name, version, date installed, location) 14. Installed patches and date installed 15. Running processes (at time of collection) 16. Firewall state 17. Firewall settings
1.3.2 Linux Hosts 1. IP address (s) 2. Hostname/Computer name 3. OS name 4. OS version 5. Installed memory make, size, slot location and serial numbers 6. Installed hard drive make, model, installation location and serial numbers 7. Motherboard serial number 8. Installed hardware (e.g. cards) 9. System UUID/ Device ID 10. Security software installed and state (enabled or disabled) 11. Active security software configuration (if possible) 12. Open ports and associated processes (at time of collection) 13. Installed software (name, version, date installed, location) 14. Installed patches and date installed 15. Running processes (at time of collection) 16. Firewall state 17. Firewall settings
1.3.3 Network Infrastructure Elements 1. IP addresses assigned to the device (IPv4 and IPv6) 2. Make and model information 3. Installed software version(s) 4. Running software version 5. Installed models/daughter boards 6. Ports available (IPv4 and IPv6) (e.g. 48 port switch, all ports) 7. Ports active(IPv4 and IPv6) (e.g. 15 ports with connectivity detected) 8. CAM table 9. Routing table (if layer 3) (IPv4 and IPv6) 10. Configuration 11. ACL’s (if configured) (IPv4 and IPv6) 12. MAC’s associated with each active port(IPv4 and IPv6) 13. Netflow data (if available) (IPv4 and IPv6)
Page 6 of 31 14. Port statistics (at time of collection) (IPv4 and IPv6)
1.3.4 Firewall 1. IP addresses assigned to the device (IPv4 and IPv6) 2. Make and model information 3. Installed software version(s) 4. Running software version 5. Installed models/daughter boards 6. Ports available (IPv4 and IPv6) 7. Ports active (IPv4 and IPv6) 8. CAM table 9. Configuration/ruleset (IPv4 and IPv6) 10. MAC’s associated with each active port (IPv4 and IPv6)
1.3.5 Peripherals 1. IP addresses assigned to the device (IPv4 and IPv6) 2. Make and model information 3. Installed software version(s) 4. Running software version 5. Installed models/daughter boards 6. Services available and active (IPv4 and IPv6) 7. Configuration (if available)
1.3.6 Additional Considerations 1. Deployment method for tool (agent vs agentless) 2. Expandability (adding new modules and functionality to the tool) 3. Data storage (how is this done) 4. Manual data entry (methods, if any) 5. Timeout concerns (e.g. network delays) 6. Ability to provide a real-time view of the network (e.g. daily scan, immediate update) 7. Acceptance and use of the product 8. Bandwidth consumption for proper usage 9. Ability to integrate with other systems/products and which products 10. Method/protocols used to collect information from the target systems 11. How data is pushed and/or pulled (exported) from the product (e.g. API, XML) 12. Ability to configure and customize settings 13. How changes to information is presented to the users 14. How changes to information is propagated to other systems/clients/subscribers 15. How the data is natively presented to the user (e.g. tabular, graphically) 16. Ability to send customized or unique commands to the monitored devices through the product 17. How does the product handle unknown or empty values within the data 18. How does the products handle errors in data collection and processing 19. How large of a network can the product monitor 20. Cost to deploy on a 1,000 node network 21. Other devices supported beyond the requested devices listed
Page 7 of 31 1.4 References
1.4.1 Product: Lansweeper · https://www.lansweeper.com
1.4.2 Product: SolarWinds · https://www.solarwinds.com/network-performance-monitor · https://www.solarwinds.com/server-configuration-monitor · https://www.solarwinds.com/user-device-tracker · https://www.solarwinds.com/solutions/orion · https://www.solarwinds.com/network-configuration-manager
1.4.3 Product: GLPI with Fusion Inventory · http://fusioninventory.org · https://glpi-project.org/
1.5 Assumptions · Access to the devices either directly or via the network · An administrator level account/access is available · Both managed and non-managed devices · Systems are not locked down to the point that collection is blocked · Firewalls will allow the required access to target systems · Obfuscating technology is not being used · Virtual instances and clones have all been properly prepared using steps such as ‘sysprep’ on Windows · Network devices respond to ICMP and ICMP traffic is allowed to traverse the network unhindered · When Agent based solutions are not possible or desirable, that WMI and/or SNMP is allowed, configured, and can traverse the network unhindered
2. Overview 2.1 Overall Summary 1. Given the specific set of requirements supplied, it was determined that 3 Network Inventory products would best represent the capabilities currently available in the marketplace. There was an additional 4 products that did not make it through the full evaluation for reasons that are described below. Given that this report is not intended to be an exhaustive survey of the landscape, and other than the criteria identified, there was no specific use case, it was determined that this would suffice. 2. All of the products tested in both an online and offline environment and, unless otherwise noted, there was no degradation in performance.
2.1.1 Test Network 1. All testing was done on a single workstation running VMWare Workstation 15 which ran all of the virtual machines. The Cisco Catalyst 2950, HP 2600n LaserJet printer and the unmanaged switch were all separate physical devices. ESXi was a virtual machine running
Page 8 of 31 within VMWare Workstation 15 and the Paloalto Firewall was a virtual machine running within that ESXi instance. 2. The test network was flat in its topology since it was deemed that this level of complexity was all that was needed to evaluate the functionality of the various products with respect to the identified requirements. 3. Tests were performed with the internet connection coming in at the unmanaged switch which meant that all of the devices including the Test_Server had access to the Internet. Tests were later performed with the Internet connection severed (unplugged from the unmanaged switch), isolating the entire network from the Internet. Installations were not performed with the internet disconnected, this being said, the 3 products that were fully evaluated gave no indication in the documentation or the installation process which would indicate that they could not be installed offline. 4. SNMP v2c was configured with the same Community string for the Cisco Catalyst 2950, Paloalto Firewall and the HP 2600n LaserJet printer. 5. All local administrator and user passwords were set to the same value.
Figure 1: Test network topology 2.1.2 Products Evaluated 1. Lansweeper: Offers centralized hardware, software and user inventory and reporting with an intuitive and up-to-date user interface 2. Solarwinds: Suite of products that offer a comprehensive variety of network administration product modules that sit atop of the Orion application framework 3. GLPI with Fusion Inventory: Open source asset management solution with a minimalist user interface, what it lacks in presentation it makes up for as a cost effective solution
Page 9 of 31 2.1.3 Products Not Fully Evaluated 1. Tripwire Enterprise: Tripwire seems to concentrate on Compliance reports and reporting. There are policies that can be defined for determining if a system is compliant. · There are rules to gather the information that is needed to determine compliance. · You can write these rules to pull any data that you would like, and you can make a report that will display inventory information, but this is something that you need to do. · Out of the box it does not pull all the information that you would need to produce a hardware inventory with the depth of information that is required. · Windows and Linux information was sparse. Out of the box Information about network elements, firewalls or peripherals was not gathered. 2. Network Inventory Advisor - Clear Apps There were issues with Network Inventory Advisor (NIA) network scans: · It pulled only basic network information (ip address, hostname) from the peripheral (HP 2600n LaserJet Printer) · Did not pick up the Windows 2019 target server during network scans, and was only able to pull information when a targeted (entered its IP) scan was performed on the machine. · Subnet scan did not find either of the Linux machines, Paloalto Firewall, or the ESXi host. Target scans of the Linux machines were able to pull information. A targeted scan of the Paloalto firewall caused the NIA server to freeze up (unresponsive UI). · There seemed to be a good variety of export options for the reports, but because of the trial license I was unable to test these. · Even when the target machines had been detected by NIA, only the Windows machine had good coverage on the criteria. The information pulled from the Linux machine was sparse, and since I could not successfully scan the Paloalto, I could not determine what information could have been pulled. 3. Network Inventory – Spiceworks: Network scanning seemed to work well with the ability to define subnets and credentials for the various host types. · There was not good coverage of the criteria with the server pulling less than half of the required items for Windows, even less for Linux, Network Infrastructure Elements, Firewalls and Peripherals. · When testing connected to the internet, ads were being displayed on the server interface. · The paid version was supposed to get rid of the ads and be capable of running offline, but due to the poor performance in gathering the required information, the server was never tested offline. The Agent was only able to run on Windows all other information gathering would need to rely on remote protocols (SNMP, ICMP, etc.) 4. Splunk: Splunk on it own does not collect the required information and was not capable of performing the scans. · Add-ons were available that did collect some of the required information, but coverage for Windows and Linux was sparse. · Additionally, out-of-the-box, not all of the information that was being collected had displays and so these would need to be developed by the end user. This also made evaluation of Splunk difficult since it could not easily be verified that the correct information was being collected
Page 10 of 31 3. Detailed Analysis 3.1 Lansweeper 1. Lansweeper as a company, originated in Belgium in the mid 2000’s and has continued to evolve its core product of an asset inventory system to include IT Helpdesk functionality. The centralized server is targeted to run on the Windows operating system, with Agent software that can be deployed to Windows, Linux and MacOS. Inventory information can be collected agentless via SNMP, WMI, SSH, and WinRM which supplements the Agent based collection. 2. The Lansweeper agent software (LsAgent) can be used to relay information from a host device to the Lansweeper server directly or be relayed through a cloud based server if a direct connection is not possible. Information is transmitted using TLS 1.2, ensuring that the data is encrypted in transit. 3. The densely packed UI is logically laid out to display the most information possible while still remaining intuitive to use.
Figure 2: Lansweeper user interface
Page 11 of 31 3.1.1 Test Network Topology Agents were deployed to the Ubuntu_Target and Windows Server 2019_Target machines
3.1.2 Section 6.1 to 6.5 Summary From the perspective of the listed requirements, Lansweeper was quite capable, being able to identify most of the items that were required. The downside was the lack of customizations with respect to retrieving and storing new host attributes, making it unable to retrieve all of the attributes identified by the requirements.
Figure 3: Test Topology
3.1.3 Section 6.6 results
3.1.3.1 Deployment method for tool 1. Lansweeper can operate with an agent, LsAgent, or without. Without an agent the product will use WMI (Windows), SSH (Linux) and SNMP (other Network Devices) to gather information from the target machines. ICMP will be used to perform initial scans to determine if a machine exists at a particular IP address. Later ICMP will be used to find out if the device is still responding to network traffic. 2. To initially populate Lansweeper with all of the network elements a network scan can be performed. Global Windows credentials can be entered for Windows WMI scans, global SSH credentials for the *nix scans, and global SNMP credentials can be entered for the SNMP enabled devices. For later scans, the ability to enter credentials for other types of devices can be entered through the Scanning → Scanning Credentials page. 3. The agent can be deployed in one of two ways: · logging into the target machine, downloading the agent, performing an installation · performing a silent install from the Lansweeper server to a Windows machine. 4. The download and install method for the Agent is straightforward for *nix and Windows machines, just download the Agent for Windows or Linux from either the website located at https://www.lansweeper.com/download/lsagent or copied from the local Lansweeper server from the default directory C:\Program Files (x86)\Lansweeper\PackageShare\Installers, run the installer and follow the prompts. 5. For Windows or Linux machines you can create/use a silent installer that will push/pull the LsAgent from the server to the target Windows machine. This action is performed as an Installer Package, and these can be found under the Deployment → Installer Packages page in the Lansweeper server UI. There should already by an Installer Package for the LsAgent which targets Windows, so it should just be a matter of targeting the subnet or specific
Page 12 of 31 resources to install the LsAgent to. If you want to target a Linux machine, then the installer will need to be created but this process is relatively straightforward. Progress for the installation can be seen under the Deployment → Installer Logs page. 6. Regardless of how LsAgent was installed, after LsAgent is installed you can check in the Lansweeper server UI under the Scanning → LsAgent Scanning page to make sure that the machine is now showing up as having reported back to the server that it has an agent installed.
3.1.3.2 Expandability (adding new modules and functionality to the tool) 1. It’s possible to create custom registry key scanning, although according to the documentation “Retrieving all values within a key or searching the entire registry for a specific value is not possible” 2. https://www.lansweeper.com/knowledgebase/report-based-on-registry-keys/ 3. This would mean scanning for all firewall rules would not be possible but you would be able to check the status of a single defined firewall rule with this mechanism. 4. Scanning a new files attributes (Windows only), new SNMP OID and Custom Performance Scanning (Windows and *nix only) can all be done in a similar UI found under the “Scanning -> Data Selection” menu header. 5. New Asset Actions can be defined in the “Configuration->Asset Pages” section of the UI. These actions will be executed from the server, and will need to take this into account. These Actions cannot retrieve information to be stored or displayed by Lansweeper.
3.1.3.3 Data storage (how is this done) 1. By default Lansweeper installs with Microsoft SQL Compact (4GB limit) on the same machine. Lansweeper can also make use of MS-SQL Server installed on a separate machine.
3.1.3.4 Manual data entry (methods, if any) 1. Manual editing and adding of an asset can be done through the Asset view. Assets can also be manually imported via import of a spreadsheet. 2. The data for a scanned device can be edited via the Asset page for that device and selecting to edit the asset from the left hand menu. Information that is pulled via a scan will take precedence over manually entered data unless that field is locked from scanning. Not all fields are lockable, so manual edits for non-lockable fields should be done with this in mind.
3.1.3.5 Timeout concerns (e.g. network delays) 1. For active scanning a timeout will result in a failure to retrieve data from that device. Errors (including timeouts) will be displayed under Scanning -> Scanning Errors. Use of the LsAgent can alleviate timeouts since the LsAgent can be configured to forward data to a Cloud Relay server if it cannot report back to the Lansweeper scan server directly.
3.1.3.6 Ability to provide a real-time view of the network (e.g. daily scan, immediate update) 1. Lansweeper Scan Server will poll network devices on a user defined schedule with daily scans being the default. If using the LsAgent, the agent will report back daily unless configured otherwise. The scan server can be directed to immediately scan network
Page 13 of 31 resources through the user interface, and progress of the scan can be monitored via the Scanning Queue.
3.1.3.7 Acceptance and use of the product 1. Lansweeper cannot boast to be used by x number of the top 1000 companies, but what it can boast is that for end users it seems to be well received. Reviews tend to rate it among the top software in the IT Asset Management category, this despite the fact that it does not have a large recognizable company like HP, Cisco or Microsoft to lend them credibility. 2. Lansweeper boasts a decent sized list of worldwide partners for deployment and sales of its core product which can be found at 3. https://www.lansweeper.com/find-a-partner/
3.1.3.8 Bandwidth consumption for proper usage 1. A normal scheduled scan will quite often be less than 50KB for a Windows or Linux node, while an entire rescan or an initial scan can be around 500KB.
3.1.3.9 Ability to integrate with other systems/products and which products 1. Has current integrations with SCCM, VMware Airwatch. 2. A current list of integrations can be found at https://www.lansweeper.com/integrations/ 3. License Dashboard - a software license monitor https://www.licensedashboard.com/combining-license-manager-and-lansweeper/ 4. Unify Cloud - a cloud solution provider https://www.unifycloud.com/ 5. Plixer Scrutinizer - a network traffic analysis system https://www.plixer.com/products/scrutinizer/
3.1.3.10 Method/protocols used to collect information from the target systems 1. Lansweeper can pull data from any device that has one or more of the following protocols enabled: Bonjour, DNS-SD, FTP, HTTP, HTTPS, JetDirect, mDNS, SIP, SMTP, SNMP (SNMPv1, SNMPv2 or SNMPv3), SSDP, SSH, Telnet, UPnP or WMI
3.1.3.11 How data is pushed and/or pulled (exported) from the product (e.g. API, XML) 1. Report data can be exported to Excel (XLSX), CSV or XML. This is done manually in the report section of the user interface. 2. Report data can also be sent automatically on a configured schedule via email in Excel (XLSX), XML or HTML formats. 3. Asset data can be exported directly from the Asset tables in the UI as Excel (XLSX), CSV or XML files. This again is done manually. 4. Finally the data is all stored in a MS SQL database and the schema documentation is available directly through the Lansweeper UI under the Reports section. This would allow for programmatic queries and exports from the database.
3.1.3.12 Ability to configure and customize settings 1. The view and behavior of the Lansweeper server can be modified via the Configuration menu in the Lansweeper UI.
Page 14 of 31 3.1.3.13 How changes to information is presented to the users 1. Alerts will be displayed to the user in the Lansweeper UI Dashboard Main Page by default with this placement being configurable. 2. Items of note are highlighted in red.
3.1.3.14 How changes to information is propagated to other systems/clients/subscribers 1. Alerts can be sent via email notifications to a user defined list of recipients.
3.1.3.15 How the data is natively presented to the user (e.g. tabular, graphically) 1. Summary information is present as charts with more detailed information presented as tables.
3.1.3.16 Ability to send customized or unique commands to the monitored devices through the product 1. Through the use of Custom Actions you can run commands from the server. Custom Actions can be defined in the Configuration-->Asset Pages page under Asset Actions section. Of note though, there is no easy way for an Action to pull data which can then be used to populate the asset in Lansweeper.
3.1.3.17 How does the product handle unknown or empty values within the data 1. For values that are erroneous, these would be replaced by “undefined”, “unknown” or similar text in the data displayed to the user.
3.1.3.18 How does the products handle errors in data collection and processing 1. Data collection occurs asynchronously in what appears to be multiple threads. What this means in practice is if an asset fails to respond to a request, that the polling of other resources is not hindered while awaiting that response. In order to see how it would respond, Lansweeper was intentionally misconfigured to scan a non-existent subnet; sending commands to machines that were powered off; entering wrong credentials. At no point did the server seem sluggish or unresponsive. Scanning errors can be found in the Scanning menu or in the Scanning Errors section of any of the Scanning pages.
3.1.3.19 How large of a network can the product monitor 1. Multiple scan servers can be deployed to support thousands of nodes each, with the scan servers reporting to a centralized database server. Given this architecture it’s possible to support 10s of thousands of nodes on a network or beyond.
3.1.3.20 Cost to deploy on a 1,000 node network 1. Available as an annual subscription for $1 per node. So 1000 nodes would be $1000 annually.
3.1.3.21 Other devices supported beyond the requested devices listed in 6.1 through 6.5 1. There is full support for MacOS including a version of the LsAgent. Also has the ability to scan/monitor VMware, Hyper V and Citrix virtualization installations, cloud based AWS and Azure resources, Android, iOS, Windows Mobile, ChromeOS devices. A full listing of the asset types and brands can be seen at https://www.lansweeper.com/assets/
Page 15 of 31 3.2 SolarWinds 1. Founded in 1999, SolarWinds is based out of Austin Texas and as a multi-billion dollar company has acquired a number of companies and associated IP, to expand its offerings in the network management sector. 2. The Orion Platform is a single framework that the application modules are plugged into. This allows for the expansion of functionality through the addition of new product modules when requirements change. Modules like the Network Performance Monitor and Server Configuration Monitor are licensed separately so that only functionality that is needed is licensed. 3. Network Performance Monitor (NPM) can map the network, monitor nodes on the network and provide alerts when criteria are met. 4. Server Configuration Monitor (SCM) offers hardware and software inventory tracking as well as server configuration management. 5. Network Configuration Manager (NCM) keeps track of network configuration, allows for the automation of configuration and management tasks over one or multiple devices. 6. User Device Tracker (UDT) allows for the discovery, monitoring and management of switchports and interfaces.
Figure 4: SolarWinds user interface
3.2.1 Test Network Topology The SolarWinds agent was installed on the WindowsServer2019_Target, CentOS_Target and the Ubuntu_Target machines.
Page 16 of 31 Figure 5: SolarWinds test network topology
3.2.2 Section 6.1 to 6.5 Summary 1. SolarWinds and the Orion Platform offers a single consistent framework onto which various application modules can be installed. These modules like Network Performance Monitor (NPM) and SCM (Server Configuration Manager) offer a functionality tailored to a specific problem space. This allows the entire platform to be quite capable as can be seen in the summary matrix in Appendix A. In those areas where out of the box functionality was lacking, the ability to add custom attributes, filled the gaps.
3.2.3 Section 6.6 Results
3.2.3.1 Deployment method for tool 1. Network Discovery attempts to use WMI (Windows), SNMP (Network Devices), and ICMP for all other machines (including Linux). You can choose to add devices that only respond to ICMP, which would be the case for Linux machines, or machines without properly configured WMI or SNMP settings. 2. Once nodes have been discovered Agents can be pushed to the node through the server UI. This process can deploy agents to several machines at once, and different credentials can be assigned if necessary. Agents can be pushed to Windows or Linux machines in this way. 3. Alternatively, you can choose to just add the node without scanning by supplying the address and credentials, then have Solarwinds automatically install the agent. 4. Finally the agents can be installed from the target machines by downloading the Windows or Linux installer onto the target machine and running the installer. While this is the most “traditional” method of installation, it is also the least preferred. The Add Node with automatic agent install mentioned previously, being the preferred method according to the Solarwinds documentation.
Page 17 of 31 5. If agentless monitoring is preferred, then Solarwinds will make use of WMI for Windows machines and SNMP for non-Windows machines. Since WMI can gather the majority of information, deployment of the Agent on Windows may not be as critical. But with Linux the agent is pretty much required in order to get a proper amount of information. ICMP is also used for monitoring the running status of discovered nodes.
3.2.3.2 Expandability (adding new modules and functionality to the tool) 1. “The Orion SDK is open source software that makes it easier for system administrators and developers to use SWIS
3.2.3.3 Data storage (how is this done) Makes use of MS-SQL Server or Azure SQL with the database schema available here: https://solarwinds.github.io/OrionSDK/schema/
3.2.3.4 Manual data entry (methods, if any) 1. Nodes can be entered manually via the Orion Web Console menu, navigate to Settings → Manage Nodes, select Add Node and fill in the required information 2. Custom properties can be added via the Admin → Manage Custom Properties → Manage Custom Properties page. Custom properties should be used to record items like asset numbers that can be reported or queried on. 3. Node name, polling settings, alert thresholds, and custom properties can be edited for an individual node in the Settings → Manage Nodes view by selecting the Edit Properties for the target node. 4. Not all fields are editable, with most of the fields that can be polled being uneditable.
3.2.3.5 Timeout concerns (e.g. network delays) 1. Orion agents can operate in either Server initiated communication mode or Agent initiated mode so if a device has infrequent network access changing between modes can better fit with the environment.
Page 18 of 31 2. Agents can be configured directly on the client machines in cases where the server cannot communicate with the Agents directly. 3. Server initiated polling can be configured to occur as frequently or infrequently as desired. Timeout and retry values as well as health calculation and threshold values can likewise be configured so as to allow for more or less tolerance to network aberrations. 4. For remote sites, additional instances of the Orion server can be installed and then this information aggregated back to a centralized Enterprise Operations Console.
3.2.3.6 Ability to provide a real-time view of the network (e.g. daily scan, immediate update) 1. Polling can be Agent or Server initiated. Schedules for reporting can be configured on the client Agent machines or on the Server depending on the direction of reporting. Reporting can occur at whatever frequency is required to allow for a real-time display. This needs to be balanced with the network overhead incurred as high frequency polling of a large number of nodes may impact network performance as a whole.
3.2.3.7 Acceptance and use of the product 1. The Solarwinds group of products appears to have wide industry use, and boasts large customers like Lockheed Martin, Emerson Electric, Nielsen and Accenture. Within the Solarwinds Orion platform, there quite a few products that exist,each with their own metrics and attribute that they monitor. NPM (Network Performance Monitor) seems to have the widest appeal, with the solid implementation of network performance monitoring. While NPM does not support all of the features that this report focuses on, it was valuable for pulling down a few of the more performance orientated attributes. SCM (Server Configuration Monitor), while having a smaller audience, still seems to be reviewed highly.
3.2.3.8 Bandwidth consumption for proper usage 1. Polls for a specific Windows or Linux host will consume approximately 50KB of data. Depending on the configuration of the individual product module, there may also be more frequent traffic to support real time updates. This will again vary by product and configuration of that product.
3.2.3.9 Ability to integrate with other systems/products and which products 1. In addition to the large number of interrelated products available from SolarWinds on the Orion platform, there are a plethora of integrations are available with just a few being: 2. Microsoft Azure services 3. CiscoWorks LAN Management Solution 4. Citrix XenApp 5. Blackberry Enterprise Server 6. AppInsight for Active Directory 7. Nagios Linux File & Directory Count Script
3.2.3.10 Method/protocols used to collect information from the target systems 1. Primary protocols used by the Pollers are SNMP, WMI and ICMP. Standard TCP with TLS1.2 communication would be used to communicate between the Orion Server and Agents deployed on client machines.
Page 19 of 31 3.2.3.11 How data is pushed and/or pulled (exported) from the product (e.g. API, XML) 1. Information can be manually exported to XLS, XML, HTML, TXT. Additionally, the Orion SDK could be used or even interacting with the Orion database directly to extract information.
3.2.3.12 Ability to configure and customize settings 1. All aspects of polling, information display, data storage can be customized through one or multiple of the Orion applications.
3.2.3.13 How changes to information is presented to the users 1. In the main display an Alerts icon in the top right will display a summary count of events that have transpired. As well, for Server Configuration Manager as an example, the configuration events are displayed by default in a panel on the bottom right of the view. These views can be individually configured to display more or less information, and their position can be changed to better suit the user.
3.2.3.14 How changes to information is propagated to other systems/clients/subscribers 1. Alerts can be sent via email, paging or SMS service, play a sound when an alert is triggered, send an SNMP trap, use the speech synthesizer to read alerts.
3.2.3.15 How the data is natively presented to the user (e.g. tabular, graphically) 1. The default set of views are a mix of tables, graphs and charts. Graphs are available to display network topology as well as relaying physical and geographic layouts. Charts relay summary information like node OS counts. Tables relay summary information about a series of hosts. Property pages are available for more detailed information about different elements. Since the platform is highly extensible with access to the SDK, it is quite possible to create views that do not currently ship with the products.
3.2.3.16 Ability to send customized or unique commands to the monitored devices through the product 1. Custom bash, python or perl scripts can be run on remote *nix hosts, and custom Powershell scripts can be run on remote Windows hosts and the results returned to the server.
3.2.3.17 How does the product handle unknown or empty values within the data 1. Minor holes in the data will be presented as empty strings, if the data was corrupt then an alert/event would be presented to the user(s)
3.2.3.18 How does the products handle errors in data collection and processing 1. While tasks are described to be running in the background, implying that they are being run asynchronously, the main server UI seems to become less responsive when performing tasks like deploying agents. This also seems to happen when importing new nodes. This could have been an artifact of the test deployment, or something that could possibly be optimized through adjusting the server configuration. This is an unknown at this time. 2. Events and Alerts, which include errors are presented in the Dashboard for the relevant product.
Page 20 of 31 3.2.3.19 How large of a network can the product monitor 1. Additional Polling Engines as well as additional Orion Web Server Engines can be added for distributed polling and management of large networks. Licensing and resources would be the only constraint for the size of the network monitored.
3.2.3.20 Cost to deploy on a 1,000 node network 1. Purchase fees include a perpetual license for the product and the first year of maintenance included. Ongoing annual maintenance fees will be approximately 20-25% of the original purchase cost. 2. Server Configuration Monitor lists as $23,000 for a 1000 node license. 3. Network Performance Monitor lists as $19,795 for a 2000 node license or $10,695 for a 500 node license 4. Network Topology Mapper lists as $1,495 for an unlimited node license 5. Network Configuration Manager lists as $12,295 for a 1000 node license.
3.2.3.21 Other devices supported beyond the requested devices listed in 6.1 through 6.5 1. Any SNMP enabled device can be supported since additional OIDs can be imported. Direct support is available for any device that uses SNMP MIB2. For a list of supported devices visit https://documentation.solarwinds.com/en/Success_Center/orionplatform/Content/core- supported-vendors-added-in-2019-4.htm
Page 21 of 31 3.3 GPL with Fusion Inventory 1. GLPI is a free IT Asset Management system written in PHP and distributed under the GNU General Public License. The project was started in 2003 and in 2015 roadmap management and development leadership was handed over to Techlib. The open source status remains one of the core tenants of GLPI, and the project remains on GitHub under the glpi-project, open for development. 2. Fusion Inventory agent and GLPI plugin are free and open source, with projects on GitHub found under the fusion inventory project. The Fusion Inventory Agent is responsible for collecting the asset information from the network nodes and forwarding it to the Fusion Inventory plugin for GLPI, which then translates the information, injects it into the GLPI data models making it available within GLPI.
Figure 6: GLPI user interface
3.3.1 Test Network Topology
Page 22 of 31 Figure 7: GLPI and Fusion Inventory test network topology 3.3.2 Section 6.1 to 6.5 Summary 1. Fusion Inventory was able to collect most of the information, it is the lack of simple customization that has Fusion Inventory lagging behind the other two products. That said, since the project is open source, and there are allowances for running arbitrary perl modules at the agents, it is possible to add customized code on the agents, it is just more effort.
3.3.3 Section 6.6 Results
3.3.3.1 Deployment method for tool 1. Agents are used to scan the network, so although it is possible to deploy agents to numerous machines, it’s not required. The agents will use SNMP, ICMP and WMI to scan for network elements. 2. Fusion Inventory Agent installation is officially a manual process, requiring that the agent is downloaded to the target machine (Windows or Linux) then installed according to the installation documents found at http://fusioninventory.org/documentation/agent/installation/ 3. This can be a very manual process with several installation steps and prerequisites. For Windows there is an unofficial VisualBasic script that will attempt to pull down the Windows agent installer and install it to a specified list of Windows machines. The link for this script can be found at the end of the Windows agent installation page. A similar method for Linux installations could also be developed using Perl, Bash or other scripting language, quite easily. 4. The Fusion Inventory Agent can be tasked with polling using WMI (for Windows), SNMP (for other network devices) and ICMP for basic online status indicators.
3.3.3.2 Expandability (adding new modules and functionality to the tool) 1. The source for both the Fusion Inventory Agent and the Fusion Inventory plugin for GLPI are available on GitHub under the Fusion Inventory project: https://github.com/fusioninventory
Page 23 of 31 2. New fields can be pulled from an Agent host by creating and adding a Perl module to the Agent directory structure. Then server side PHP scripts will need to be written in order for GLPI to understand, store and visualize the new content. The procedure and examples for this can be found at http://fusioninventory.org/documentation/agent/additional_content.html
3.3.3.3 Data storage (how is this done) 1. Data is stored in a database, namely MySQL >= 5.6 or MariaDB >= 10.0 2. The database structure is documented here https://glpi-developer- documentation.readthedocs.io/en/master/devapi/database/dbmodel.html Note: this is not a complete schema.
3.3.3.4 Manual data entry (methods, if any) 1. Data can be input manually in the GLPI UI under the Assets menu, selecting the asset type menu, then selecting the “+” next to the breadcrumbs section of the UI. 2. Assets can also be created via the Administration->Fusion Inventory- >Tasks->Import agent XML file action. This will import the asset defined in the XML file that was produced by the fusioninventory-netinventory application on a client machine.
3.3.3.5 Timeout concerns (e.g. network delays) 1. The GLPI server will reach out to the installed agents on an administrator defined schedule to pull the information needed. There is a somewhat limited ability to modify the frequency of agent contact, with increments of 1 hour from 1 hour up to 10 days (240 hours). The SNMP timeout values can be adjusted for each agent on the network. 2. It is also possible to run fusioninventory-* commands (examples: fusioninventory- netdiscovery; fusioninventory-netinventory) from where an agent is installed and export the results to an XML file. This XML file can then be manually imported to the Fusion Inventory plugin on the GLPI server. This allows for the maintenance of inventory information for nodes that are entirely disconnected from the GLPI server.
3.3.3.6 Ability to provide a real-time view of the network (e.g. daily scan, immediate update) 1. The scheduled contact frequency can be as often as once an hour. An immediate scan can be requested of the agents through the server.
3.3.3.7 Acceptance and use of the product 1. GLPI has been around for over 15 years as an open source project. Its gathered users from large French and European companies like Airbus, La Poste and Meteo France. Being an open source product, its ability to be customized is quite extensive. There are several partners (listed here https://glpi-project.org/partners/) that can provide support and assistance for installation, hosting and customization.
3.3.3.8 Bandwidth consumption for proper usage 1. For a normal scheduled scan the traffic between the GLPI server and an Ubuntu agent totaled around 250KB bidirectional, and about 75KB bidirectional for the Windows agent. Note that
Page 24 of 31 this is highly dependent on the tasks associated with each of the agents (netdiscovery, netinventory, inventory, etc.) and the number of nodes that they are reporting on.
3.3.3.9 Ability to integrate with other systems/products and which products 1. GLPI will work with OCS Inventory in addition to Fusion Inventory. 2. Fusion Inventory will work with compatible servers such as OCS Inventory, GLPI, OTRS, Uranos
3.3.3.10 Method/protocols used to collect information from the target systems 1. Fusion Inventory Agent communicates with the GLPI server using zlib compressed XML transmitted via HTTP/HTTPS. 2. The Fusion Inventory Agent will utilize WMI, SNMP and ICMP to discover and inventory hosts on a network.
3.3.3.11 How data is pushed and/or pulled (exported) from the product (e.g. API, XML) 1. Information can be collected directly from the agent (using fusioninventory-* applications) and this would be formatted in XML. 2. In GLPI the inventory can be exported as an XML file. 3. There is also the ability to perform a SQL or XML dump of the database from the GLPI server under the Administration → Maintenance page.
3.3.3.12 Ability to configure and customize settings 1. There is a limited ability to configure GLPI and Fusion Inventory. Since the UI is rather spartan, and the scope is rather limited, the configuration options should be enough to satisfy most use cases.
3.3.3.13 How changes to information is presented to the users 1. Under the specific asset in the Historical section, a list of changes will be provided along with the date of change.
3.3.3.14 How changes to information is propagated to other systems/clients/subscribers 1. Notifications are distributed via email.
3.3.3.15 How the data is natively presented to the user (e.g. tabular, graphically) 1. The user interface relies largely on tabular displays of information.
3.3.3.16 Ability to send customized or unique commands to the monitored devices through the product 1. There does not seem to be way through the user interface to send custom or unique commands to an agent to execute. If there were commands that needed to be implemented, these could be coded into the agent, given that the Fusion Inventory agent is open source and has the ability to run arbitrary perl modules copied into its directory tree as referred to in the page http://fusioninventory.org/documentation/agent/additional_content.html
Page 25 of 31 3.3.3.17 How does the product handle unknown or empty values within the data 1. Depending on the data that is missing it could either be skipped and displayed as an empty value, or if it was required for the asset rules, then the update could be rejected.
3.3.3.18 How does the products handle errors in data collection and processing 1. Errors in updates could result in a failure that would present itself in the Logs found under the Administration menu item, or under the Administration → Fusion Inventory → Rules → Assets skipped during import 2. GLPI server has a more passive role in managing agents that the other products reviewed. The GLPI server really just queues job requests for the agents, the agents retrieve these jobs and execute them remotely, then the results are returned back to the GLPI server sometime later. The server therefore is not impacted by long running polls by agents. Additionally, the Fusion Inventory GLPI plugin parses the results that are returned from the agents, and if there is an error in these results, it’s removed/replaced by placeholders (empty or error string) before it’s committed to the GLPI database and made available for consumption on the GLPI server. This makes GLPI and Fusion Inventory plugin quite resistant to errors in reported data.
3.3.3.19 How large of a network can the product monitor 1. GLPI out of the box is documented to support thousands of monitored clients.
3.3.3.20 Cost to deploy on a 1,000 node network 1. So long as this is not purchased from a reseller with support agreements or a cloud service agreement, then an onsite installation would be free.
3.3.3.21 Other devices supported beyond the requested devices listed in 6.1 through 6.5 1. Currently there is a GLPI Android Agent available at https://github.com/glpi-project/android- inventory-agent 2. Supported platforms for the fusioninventory agent are: o OS X, o Linux, o Windows, o AIX, Solaris, o HP-UX, o BSD, and o Android 4. Conclusion While there is no one product that satisfies all of the criteria out of the box, it is possible with a certain amount of customization to get coverage on most of the criteria. SolarWinds with the single Orion Platform and a wide array of product modules, comes the closest to satisfying all of the requirements. GLPI with Fusion Inventory does track a large number of the required attributes, but for those attributes that need to be added it comes at the cost of a large amount of time and effort in writing custom scripts to pull, parse, store and display the information. Lansweeper satisfies a lot of the requirements but lacks the level of customization that would be required to fully cover the criteria list.
Page 26 of 31 Appendix A The following tables refer to the sections as laid out in the requirement document. ‘x’ indicates that the product is able to gather and display that criteria item with its default out of the box configuration ‘C’ indicates that the product is able to gather that information with some user defined customization ‘-’ indicates that the product is not able to gather the information
Section 6.1 - Windows solarwinds: Network Performance Monitor and Server Fusion Configuration Inventory Product LanSweeper Manager on Orion and GLPI
Windows
IP address (s) x x x
Hostname/Computer name x x x
OS name x x x
OS version x x x
Installed memory make, size, slot location and serial numbers x x (see note 1) x
Installed hhard drivemake, model, installation location and serial numbers x x x
Motherboard serial number x x
Installed hardware (e.g. cards) x x x
System UUID/ Device ID x C x C (see Security software installed and state (enabled or disabled) x x note 2)
Active security software configuration (if possible) x C C
Open ports and associated processes (at time of collection) - C C
Installed software (name, version, date installed, location) x x x
Installed patches and date installed x x x
Running processes (at time of collection) x C C
Firewall state C x C
Firewall settings C C C Notes: 1. Serial Number was not being collected/displayed
Page 27 of 31 2. Antivirus software was listed under installed software but was not detected and/or listed in the antivirus software section
Section 6.2 - Linux solarwinds: Network Performance Monitor and Server Configuration Fusion Manager on Inventory Product LanSweeper Orion and GLPI
Linux
IP address (s) x x x
Hostname/Computer name x x x
OS name x x x
OS version x x x
Installed memory make, size, slot location and serial numbers x x x
Installed hard-drive make, model, installation location and serial numbers x C x
Motherboard serial number x x x
Installed hardware (e.g. cards) x x x
System UUID/ Device ID x C x C (see note Security software installed and state (enabled or disabled) - C below)
Active security software configuration (if possible) - C C
Open ports and associated processes (at time of collection) - x C
Installed software (name, version, date installed, location) x C x
Installed patches and date installed - C x
Running processes (at time of collection) - C C
Firewall state - C C
Firewall settings - C C Note: Antivirus software was listed under installed software but was not detected and/or listed in the antivirus software section
Page 28 of 31 Section 6.3 - Network Infrastructure Elements solarwinds: Network Performance Monitor and Server Configuration Fusion Manager on Inventory Product LanSweeper Orion and GLPI
Network Infrastructure Elements
IP addresses assigned to the device (IPv4 and IPv6) x x x
Make and model information x x x
Installed software version(s) x x x
Running software version - x x - (see note Installed models/daughter boards - - below) Ports available (IPv4 and IPv6) (e.g. 48 port switch, all ports) x x x Ports active(IPv4 and IPv6) (e.g. 15 ports with connectivity detected) x x x
CAM table x x x
Routing table (if layer 3) (IPv4 and IPv6) - x C
Configuration - x C
ACL’s (if configured) (IPv4 and IPv6) - x C
MAC’s associated with each active port(IPv4 and IPv6) x x x
Netflow data (if available) (IPv4 and IPv6) - x -
Port statistics (at time of collection) (IPv4 and IPv6) - x C Note: There were sections dedicated to displaying this information, but the information was not present, more than likely due to the method of import which was the manual import using the results of the fusioninventory-netinventory application
Page 29 of 31 Section 6.4 - Firewall solarwinds: Network Performance Monitor and Server Configuration Fusion Manager on Inventory Product LanSweeper Orion and GLPI
Firewall C (see note IP addresses assigned to the device (IPv4 and IPv6) x x below)
Make and model information x x x
Installed software version(s) - x x C (see note Running software version - x below) - (see note Installed models/daughter boards - - below)
Ports available (IPv4 and IPv6) x x x
Ports active (IPv4 and IPv6) x x x
CAM table - x C
Configuration/ruleset (IPv4 and IPv6) - x C
MAC’s associated with each active port (IPv4 and IPv6) x x x Note: There were sections dedicated to displaying this information, but the information was not present, more than likely due to the method of import which was the manual import using the results of the fusioninventory-netinventory application
Page 30 of 31 Section 6.5 – Peripherals solarwinds: Network Performance Monitor and Server Configuration Fusion Manager on Inventory Product LanSweeper Orion and GLPI
Peripherals C (see note IP addresses assigned to the device (IPv4 and IPv6) x x below)
Make and model information x x x C (see note Installed software version(s) - x below) C (see note Running software version x x below) - (see note Installed models/daughter boards - - below) C (see note Services available and active (IPv4 and IPv6) x x below) C (see note Configuration (if available) - C below) Note: There were sections dedicated to displaying this information, but the information was not present, more than likely due to the method of import which was the manual import using the results of the fusioninventory-netinventory application
Page 31 of 31
DOCUMENT CONTROL DATA *Security markings for the title, authors, abstract and keywords must be entered when the document is sensitive 1. ORIGINATOR (Name and address of the organization preparing the document. 2a. SECURITY MARKING A DRDC Centre sponsoring a contractor's report, or tasking agency, is entered (Overall security marking of the document including in Section 8.) special supplemental markings if applicable.) Scott Milne Consulting Inc. CAN UNCLASSIFIED 280 Albert Street, Suite 1000 (10th FLOOR) Ottawa, Ontario K1P 5G8 2b. CONTROLLED GOODS NON-CONTROLLED GOODS DMC A
3. TITLE (The document title and sub-title as indicated on the title page.) Remote Collection of Network Information (ReCoN)
4. AUTHORS (Last name, followed by initials – ranks, titles, etc., not to be used) Milne, S.
5. DATE OF PUBLICATION 6a. NO. OF PAGES 6b. NO. OF REFS (Month and year of publication of document.) (Total pages, including (Total references cited.) Annexes, excluding DCD, covering and verso pages.) January 2020 31 0
7. DOCUMENT CATEGORY (e.g., Scientific Report, Contract Report, Scientific Letter.) Contract Report
8. SPONSORING CENTRE (The name and address of the department project office or laboratory sponsoring the research and development.) DRDC – Ottawa Research Centre Defence Research and Development Canada, Shirley's Bay 3701 Carling Avenue Ottawa, Ontario K1A 0Z4 Canada 9a. PROJECT OR GRANT NO. (If appropriate, the applicable 9b. CONTRACT NO. (If appropriate, the applicable number under research and development project or grant number under which which the document was written.) the document was written. Please specify whether project or grant.) W7714-176208/001/IPS 05ac
10a. DRDC PUBLICATION NUMBER (The official document number 10b. OTHER DOCUMENT NO(s). (Any other numbers which may be by which the document is identified by the originating assigned this document either by the originator or by the sponsor.) activity. This number must be unique to this document.) DRDC-RDDC-2020-C076
11a. FUTURE DISTRIBUTION WITHIN CANADA (Approval for further dissemination of the document. Security classification must also be considered.) Public release
11b. FUTURE DISTRIBUTION OUTSIDE CANADA (Approval for further dissemination of the document. Security classification must also be considered.)
12. KEYWORDS, DESCRIPTORS or IDENTIFIERS (Use semi-colon as a delimiter.) Cyber; Computer Network Defence (CND); Computer Networking; asset inventory 13. ABSTRACT/RÉSUMÉ (When available in the document, the French version of the abstract must be included here.)