Migrate Tenable Nessus to a New Linux Server
During the lifecycle of a Tenable Nessus scanner or Tenable Nessus Manager installed on Linux, you may need to perform a migration from one server to another. The following topic outlines the migration steps for same-to-same, cross-platform, and/or cross-architecture migrations and provides some considerations.
Prerequisites
Ensure your target server has an operating system that is supported for the target version of Tenable Nessus and that it meets all other system and hardware requirements.
Next, ensure the Tenable Nessus version is the same on the source and target servers.
Run the /opt/nessus/sbin/nessusd -v command to determine the version on both servers. If the source version is lower than the target version, do one of the following:
-
Upgrade the source server Tenable Nessus to the same version as the target server's.
-
Downgrade the target server Tenable Nessus to the same version as the source server's.
-
To downgrade Tenable Nessus on Tenable Core, run the pkexec /usr/libexec/tenablecore/backup/applicationDowngrade.sh command on the target server, select the Tenable Nessus version to downgrade to, then press Enter.
Note: Due to a Cockpit limitation in Tenable Core Oracle Linux 8 (OL8), it is not possible to run this command in Tenable Core OL8's terminal. You must run it in a Secure Shell (SSH) session instead.
-
To downgrade Tenable Nessus on any other operating system, uninstall Tenable Nessus, then install the version matching the source server's.
-
Transfer the Data
Transfer the data from the source to the target server using one of the following two options. Both options exclude specific directories (including backups and logs) that are non-essential to the migration. Back these up separately, if needed. A remote sync is the faster option, as it does not require to create, transfer and restore a backup.
Notes:
-
All commands must be run as root.
-
If you have a non-root user (providing sudo privilege escalation is allowed for your account), you may switch to a root prompt by using the sudo -i command and entering your non-root user password again.
-
Some operating systems may show a "tar: invalid option -- '▒'" error when copying and pasting a tar command. Manually entering the command resolves this issue.
Adjustments
Perform the following steps on the target server to ensure a consistent, working state after you have transferred or restored the data:
-
To prevent a FIPS module error from being shown when running nessuscli and ensure the correct platform-specific binaries are in place, perform a forced Tenable Nessus upgrade with the appropriate command for Red Hat or Debian-based operating systems.
Red Hat-based operating systems
rpm -Uvh --force /tmp/Nessus-<version>.x86_64.rpm
Note: On Oracle Linx 8 instances of Tenable Core, you can run the yum download Nessus command to download the latest Tenable Nessus RPM file to the present working directory. On older instances of Tenable Core, you can run yumdownloader Nessus to achieve the same result.
Debian-based operating systems
dpkg --force-all -I /tmp/Nessus-<version>.amd64.deb
-
Start the Tenable Nessus service on the target server:
service nessusd start
-
To allow the download of plugins and prevent a “Could not validate this preference file. Have installation files been copied from another system?” error, log in to Tenable Nessus, then navigate to Settings > Overview and apply the license again. To re-use the same license, first reset it in https://community.tenable.com/s/products. After applying the license, Tenable Nessus signs you out.
Notes:
-
If configured to update online, Tenable Nessus attempts to update shortly thereafter, with the login screen showing “Plugins are compiling, Nessus functionality will be limited until compilation is complete” for up to 20 minutes. During that time, backend.log shows "<[info] [globaldb] Waiting for Nessus to be ready>". While you will be able to log in and check your data is all there, it will not be possible to run scans until after this completes. When done, the user interface shows “Plugins are done compiling”, while backend.log shows "[info] [globaldb] cleanup is starting" and other activity.
You can use the tail -f /opt/nessus/var/nessus/logs/backend.log command to monitor the progress in backend.log.
If applicable, Tenable Nessus Manager also starts generating agent DB files, which will take an additional 10 minutes. Next, Tenable Nessus Manager checks if the feed offers a new agent core version. If so, it downloads the new agent core version.
-
Air-gapped Tenable Nessus installations require a manual plugins update. You can force the generation of agent DB files for Tenable Nessus Manager after a plugins update using the following command:
/opt/nessus/sbin/nessuscli manager generate-plugins –force
-
Information exchange between Tenable Nessus Manager cluster nodes is dependent on a pre-shared secret. If, for example, you run nessuscli fix --reset was performed, a new certificate was generated, or a custom CA uploaded to the Tenable Nessus Manager parent, an "Invalid certificate signature" error may appear in a child node's backend.log. If so, follow Invalid Certificate signature on cluster nodes to reset the pre-shared secret and re-enable communication between the nodes.
-
Configure the Hostname and IP address
A stand-alone Tenable Nessus may use a different hostname and/or IP address. However, as agents will have been linked to one or the other, a Tenable Nessus Manager target server should have the same IP address and hostname as the source server. After transferring the data, make note of the source server hostname and IP address, then shut down the source server and assign the same to the target server.
Notes:
-
If a different hostname and/or IP address is used for the Tenable Nessus Manager target server, agents linked to the previous hostname or IP address will have an Offline status in the console. To correct this, you must remove each agent’s Tenable tag (/etc/tenable_tag or HKLM\SOFTWARE\Tenable\TAG) before relinking them to the target server.
-
Not removing the Tenable tag before attempting to relink the agent results in a 409 error, as the Tenable Nessus Manager will already have an agent with the same Tenable tag.
-
After deleting the Tenable tag, restart the agent service using service nessusagent restart to create a new one.
-
The relinking of an agent with a new Tenable tag results in an update of the agent in the Tenable Nessus Manager console.
-
Configure the hostname using one of the following two options:
To change the target server’s IP address, determine the interface name associated with the IP address to be changed in the ip a output, then update the IP address in /etc/sysconfig/network-scripts/ifcfg-<network interface name> in a Red Hat-based operating system, or in /etc/network/interfaces in a Debian-based operating system, and then reboot the server.