Published on August 5, 2019

Thanks to the wonderful user feedback from Beta 5, a handful of bug fixes and improvements have been deployed along with a new feature: Network Bridge Detection!

Rumble Scanner Bridges Report

The bridge report shows external networks in red, internal networks in green, and multihomed assets that bridge these networks in orange. Zooming in will show asset and subnet details, while clicking a node will take you to the asset page for bridge nodes and to a CIDR-based inventory search for network nodes. This view is not a typical network map, but instead shows possible paths that can be taken through the network by traversing multihomed assets. Assets where Rumble only detected a single IP address are not shown in order to keep the graph readable.

Bridge detection is useful when validating network segmentation and ensuring that an attacker can’t reach a sensitive network from an untrusted network or asset. Examples of this include laptops plugged into the internal corporate network that are also connected to a guest wireless segment and systems connected to an untrusted network, such as a coffee shop’s wireless network that also have an active VPN connection to the corporate network.

Rumble detects network bridges by looking for extra IP addresses in responses to common network probes (NetBIOS, SNMP, MDNS, UPnP, and others) and only reports bridges when there is at least one asset identified with multiple IP addresses. Typical hardening steps, such as desktop firewalls and disabled network services will usually prevent multihomed assets from being detected by Rumble. The screenshot below shows how to search for multihomed assets in the Rumble inventory.

Rumble Multihomed Asset Detection

Bridge reports can be found in the Inventory under the new Reports drop-down menu.

Rumble Report Menu

Network segmentation is a critical security control for many businesses, but verifying that segmentation is working correctly can be challenging, especially across large and complex environments. Common techniques to validate segmentation, such as reviewing firewall rules and spot testing from individual systems can only go so far, and comprehensive testing, such as running full network scans from every segment to every segment, can be time intensive and are hard to justify on a regular basis. For businesses subject the PCI DSS requirements, validating cardholder data environment (CDE) segmentation is an important part of the security audit process. The image below is from the PCI guidance on scoping and segmentation and demonstrates a common CDE administration model.

Logical Data Flow: Administration of CDE Systems from a Security-Impacting System in the Corporate LAN

The network bridge detection in Rumble is opportunistic and far from perfect, but it may highlight areas where segmentation is broken, and can cut down on the number of surprises encountered in a future security audit. We hope you find this report useful and we would love your feedback.

Happy scanning!

Other changes since Beta 5

  • The Search Query Syntax documentation has been overhauled for readability and clarity.

  • The Inventory now supports queries for network ranges using the net:CIDR/MASK syntax.

  • The Inventory now supports queries for the Last Seen and First Seen fields using relative and absolute dates (lastseen:>5days or firstseen:<2019-06-01).

  • The new Subnet Utilization Report can provide a quick breakdown of where assets were found.

  • Scans now support individual network ranges up to a /8 (16.7 million IPs). Scans can support multiple ranges to encompass even larger address space.

  • The urls.txt file generated by the scanner now uses the fully qualified host name, if DNS names were used as scan targets.

  • A race condition that could cause large scans to crash was identified and resolved.

  • An issue scanning services that produce large responses was identified and resolved.

  • Scan exclusions were not working properly, this has been corrected and new test cases put in place.

  • Empty output directories would be created if the scanner was run without targets, this is now fixed.

  • The Nmap XML output has been updated to be slightly more correct (utf-8, prevent invalid values for the down host count).

  • The npcap package has been upgraded to version 0.9982.

Similar Content

Rumble Scanner Updates & Data Transparency
Published on January 28, 2020
Data transparancy is one of the key drivers of Rumble development. We do our best to ensure that any data gathered, transmitted, or downloaded is easy to view, import, export, and reprocess. Data generated by the Rumble Agent can be downloaded and reprocessed by the Rumble Scanner. Raw data from the Rumble Scanner can be imported into the Rumble Console. This data is consistently formatted and almost always backwards compatible between versions.
Uncovering Unknowns Through Topology Analysis
Published on November 19, 2019
Version 1.1.5 of the Rumble platform is live! This release includes a new Switch Topology report, updates to the Network Bridges report, and improvements to how SNMP data is collected during scans. Combined, these updates can shine a light on misconfigured network segmentation and help identify assets that may not have been scanned at all. This post will walk through these updates and highlight how these reports can be used to identify unknown risks.
Authenticated SNMP v3 Support
Published on November 19, 2019
After announcing v1.1.5 with the new Switch Topology report, quite a few folks wrote in to ask if this feature was available in SNMPv3 environments. As of this evening, the answer is yes. To leverage SNMP v3 credentials in a Rumble scan, set the following options in the Advanced Options section of the Scan Configuration screen. Depending on your environment, these settings may require some tweaking. The standard security levels of NoAuthNoPriv, AuthNoPriv, and AuthPriv map to these options as follows: