Installing an Agent

Rumble requires the use of at least one Agent within your environment to enable network discovery. The agent should be installed on a system with reliable connectivity to the network you want to discover. For internal networks, Rumble works best when installed on a system with a wired (vs wireless) connection.

For external network discovery, nearly any cloud provider with a reliable connection should do. If the Rumble agent is installed in a container or virtualized system, ensure that it has direct access to the network (host networking in docker, bridged networking in VMware, etc).

Installation

To install the Rumble agent, login to the Rumble Console and switch to the Organization that should be associated with the agent. The agent download link is specific to your active Organization and using the wrong link can result a new agent being associated with the wrong Organization.

Download the correct binary for your system from the agent download page. For most systems, select the 64-bit (x86_64) architecture. For embedded devices, such as the Raspberry Pi 3+, choose the ARM7 architecture. Windows binaries are signed with a valid Authenticode signature, which should be validated before the executable is launched.

The agent installation process requires administrative privileges. On Windows, a UAC prompt may be displayed. On Linux and macOS the downloaded binary should be made executable (chmod u+x rumble-agent.bin) and then executed with root privileges (sudo or from root shell). In either case, the agent should install itself as a system service and start immediately, displaying a new entry in the agents page.

System Requirements


  • Windows Server 2012 R2+ or Windows 10 Build 1604+
  • Processor running at 2.0Ghz or faster
  • At least 4Gb of memory (1Gb available)
  • At least 1Gb of free storage space

Windows Server 2008, Windows Server 2012, Windows 7, and Windows 8 may be able to run the agent in a pinch, but are not officially supported.

  • Kernel version 2.6.23 or later
  • Processor running at 2.0Ghz or faster
  • At least 2Gb of memory (1Gb available)
  • At least 1Gb of free storage space

Linux ARM devices with limited processing power and memory, such as the Raspberry Pi, can run the Rumble Agent, but may have trouble scanning larger networks.

  • macOS 10.11 (El Capitan) or newer
  • Processor running at 2.0Ghz or faster
  • At least 2Gb of memory (1Gb available)
  • At least 1Gb of free storage space

macOS systems running Catalina (10.15) or newer need to use the curl download method to avoid issues with the new Notary requirements.

  • Processor running at 2.0Ghz or faster
  • At least 2Gb of memory (1Gb available)
  • At least 1Gb of free storage space

Requires root access to a system running a recent version of the operating system.
(FreeBSD 11.2 or newer, recent versions of NetBSD/DragonFly/OpenBSD)

Quick Links


Web Screenshots

Google Chrome or Chromium should be installed on the Agent system to enable web screenshots. Please note that “snap”-based Chromium installs (Ubuntu 20.04 and newer) don’t appear to work properly in headless mode and the official Chrome packages should be used instead.

Network Communication

The agent connects to the hosts hub.rumble.run, console.rumble.run, and rumble-scans-prod.s3.us-east-2.amazonaws.com on TCP port 443 using TLS. This hub.rumble.run connection is used for agent registration, job scheduling, and status messages while the S3 host is used for submission of completed scan jobs. For completely offline environments, the Rumble Scanner can be used to create scan data files that can be uploaded later via the Inventory Import action. The host console.rumble.run is used for automatic updates of the agent executable.

Please note that certain web proxies that perform TLS inspection do not handle Websocket communication properly and TLS inspection will need to be disabled for the Rumble agent to successfully connect. The most popular product with this problem is the Sophos (previously Cyberoam) security appliance. Websense users may need to add a bypass rule for *.rumble.run.

Proxy support is handled automatically in most cases. On the Windows platform, proxy information is read from the registry keys (used by Chrome, Edge, and IE).

On non-Windows operating systems the proxy can be configured by setting the HTTPS_PROXY environment variable. The value of the HTTPS_PROXY environment variable should be a hostname and port (proxy:8080) or just a hostname (proxy). Environment variables are read from the file /opt/rumble/bin/.env on these platforms and apply to all installed agents.

Removing an Agent

The easiest way to remove an agent is to use the Agents page Manage menu and select the Uninstall Agent option. This will remove the service and terminate the current agent process. If you would like to remove the agent without using the Rumble Console, there are a couple options.

On the Windows platform, each agent will be listed in Programs and Features, and can be uninstalled like any other application.

On all platforms, including Windows, the agent can uninstall itself if run with the uninstall argument from a root or Administrator shell:

Windows

c:\Program Files\Rumble\rumble-agent-[oid].exe uninstall

Other Platforms

/opt/rumble/rumble-agent-[oid] uninstall

Configuration

The Rumble Agent can be configured by setting variables in a .env file located in the same directory as the executable. On Windows this file should be created in C:\Program Files\Rumble\.env, while other platforms should use /opt/rumble/bin/.env. The format of this file is VAR=VAL with one variable per line.

Log Management

The Rumble Agent logs to a file and to standard output by default. On Windows the default log file location is the installation directory (C:\Program Files\Rumble) while other platforms log to the files /var/log/rumble.log and /var/log/rumble.err. The default configuration limits log files to 100Mb, creates three backups, and expires logs after 90 days. These defaults can be be changed by setting the following values in the .env file:

  • The RUMBLE_AGENT_LOG_MAX_SIZE setting controls the maximum log size in megabytes. The default is 100.
  • The RUMBLE_AGENT_LOG_MAX_BACKUPS setting controls the number of backup files created by log rotation. The default is 3.
  • The RUMBLE_AGENT_LOG_MAX_AGE setting controls the maximum age in days, this applies to all files, including backups. The default is 90.
  • The RUMBLE_AGENT_LOG_COMPRESS setting determines whether to gzip compress the backups. The default is false.
  • The RUMBLE_AGENT_LOG_STDOUT setting determines whether to write logs to standard output (and syslog for systemd/upstart). The default is true.

The agent must be restarted for these settings to take effect.

To Restart an Agent

The quickest way would be to force an update from the cloud console, otherwise you can find the service name and restart it by hand.

On Linux systems using systemd, first obtain the name of the agent service:

$ systemctl | grep rumble-agent

Then restart the service using this name:

$ systemctl restart rumble-agent-[uuid-value]

A kill -9 of the agent pid should cause a restart as well.

Certificate Authorities

The Rumble Agent uses the system-installed certificate authorities to validate TLS connections in addition to an internal CA certificate bundle (derived from Debian 10). By default, both the system certificate roots, and the bundled roots are considered for all secure TLS connections. This behavior can be controlled via environment variables (set in the .env file or at the system level):

  • The RUMBLE_TLS_IGNORE_SYSTEM_ROOTCA setting can be set to true to ignore the system CA roots.
  • The RUMBLE_TLS_IGNORE_EMBEDDED_ROOTCA setting can be set to true to ignore the bundled CA roots.

Manual Mode

If a supported system service manager, such as systemd or upstart, is not detected, the Rumble Agent will switch to manual mode, running in the foreground, and replacing and re-executing its own binary as new updates become available. For temporary agent installations or to run the agent in a container environment, the argument “manual” can be specified:

$ sudo ./rumble-agent.bin manual

Storage Locations

The Rumble Agent installs into %PROGRAMFILES%\Rumble on Windows and /opt/rumble on all other platforms. Temporary files are stored in the default operating system locations. These locations can be overridden using the .env file. Note that the agent service needs to be restarted (or force updated) for these changes to take effect.

On Windows, the temporary file location is chosen from the first non-empty environment value of TMP, TEMP, or USERPROFILE, falling back to the Windows directory. To override this location, set an entry in .env like the following:

TMP=D:\Storage\Rumble

On all other platforms, the temporary file location is chosen based on the value of TMPDIR, falling back to /tmp otherwise. To override this location, set an entry in .env like the following:

TMPDIR=/home/storage/rumble

Any scans that fail to upload are stored in the Rumble Agent installation directory and can be imported into the platform manually or using the Rumble Scanner’s --import and --upload options.

Container Installations

The Rumble Agent can run in standard container environments, but may require additional configuration. To run as a standalone executable, the agent can be run with the argument manual. For non-persistent containers an agent identifier needs to be persisted through an environment variable. This can be done by setting the variable RUMBLE_AGENT_HOST_ID to a 32-character hexadecimal string. This identifier is used to uniquely identify the agent within an organization.

To generate a suitable identifier, the openssl tool may be used:

$ openssl rand -hex 16
01b0283809b24511929d0b062bd36109

Automated Installations

The Rumble Agent will automatically install when executed if root or Administrative privileges are available.

On Linux and BSD systems, automatic installation depends on the presence of a supported init service like systemd or upstart. If no supported init service is found, the agent will instead run in manual mode, automatically overwriting and re-executing itself with each update. To automatically deploy an agent on systems without a supported init service, the agent should be executed in the background and with the nohup wrapper.

On Windows systems, the agent will automatically install when run interactively or when the updater parameter is passed to the binary. For environments where MSIs are required, the Agent MSI wrapper can be used to deploy an agent from the Rumble Console or a local mirror.