Opsani VCTR - Vulnerability Scanner for Plesk
Opsani VCTR free:
- analyzes your server configuration and reports security vulnerabilities in packages distributed by the operating system vendor
- reports whether or not the vendor has released an update which fixes a vulnerability
Opsani VCTR pro:
- allows you to select and fix vulnerabilities from the user interface
- can be configured to automatically fix all, or just critical, vulnerabilities on a daily basis
- provides email and dashboard notification for automatically fixed vulnerabilities and newly discovered critical vulnerabilities
Activating the Extension
Once the extension is installed under Plesk, it must be activated before use. Activation creates an account for this system with the Opsani service and sends telemetry data to this service for reliability and vulnerability analysis. To activate the extension:
- select the checkbox indicating you agree with the Opsani Terms & Conditions
- select the checkbox indicating you are not a robot, and, as required, solve the reCAPTCHA
- optionally select the checkbox to receive occasional messages from Opsani
- click on the Activate button
If the activation page is not presented, and instead you see a page indicating the Opsani telemetry client was not installed, please see Manual Installation of the Opsani Telemetry Client.
Once the extension is activated, it presents a user interface such as the one in the image below, taken from the pro version. The free version does not include controls for fixing vulnerabilities.
Each time the main page is loaded or refreshed, the extension checks to see if the system configuration has changed. If so, it automatically rescans the system for vulnerability analysis. You do not need to worry about performing manual scans.
The UI includes a summary section on the top and three tabs beneath:
- Vulnerabilities: this tab shows all of the vulnerabilities currently affecting the system
- Packages: this tab shows all of the packages currently installed on the system
- Update History (pro version): this tab shows a history of package update operations performed by the extension to fix vulnerabilities
An overview of each of these is presented below.
The results summary on the top of the page includes the following information.
- OS / Version: the operating system name and version
- Last System Update: the last time the system configuration changed, e.g., from a package update, install or removal
- Last Scan: the last time Opsani VCTR analyzed the system for vulnerabilities
- Rescan now: rescan the system for vulnerability analysis, whether or not its configuration has changed
- link to this documentation
- link to Opsani support
- print the current page
- extension settings
- link to the Plesk Onyx System Updates manager
- Max Severity: the maximum severity rating among all vulnerabilities
- Max After Fixes: the maximum severity rating among vulnerabilities which will remain after applying all updates
- Fix All Vulnerabilities, Fix Critical, and Fix Selected (pro version):
- These buttons can be used to fix all vulnerabilities, fix critical vulnerabilities (severity 8.0-10.0), or fix vulnerabilities which have been selected using the checkboxes in the vulnerabilities tab.
- Clicking one of these buttons opens a popup showing a list of packages to be updated and their update targets (new versions). If the extension does not find any update targets, disabling the safe repository check may remediate this. Please see the sections below on Troubleshooting Updates and the Safe Repository Check .
Opsani VCTR pro includes controls for automatic updates. The UI displays the current auto update settings, and a button to change these settings:
There are just three auto-update settings:
- Daily Auto Update:
- Fix All: automatically fix all vulnerabilities
- Fix Critical: automatically fix all critical vulnerabilities
- Off: do not automatically fix any vulnerabilities
- Dashboard Notifications:
- Create a dashboard notification when vulnerabilities are automatically fixed. This notification occurs when auto updates are set to Fix All or Fix Critical
- Create a dashboard notification when a new critical vulnerability is discovered. this notification occurs when auto updates are set to Off.
- Email Notifications:
- Create an email notification as per the dashboard notifications. Email notifications are sent to the Plesk administrator email address. Please check your spam folder, as that is where these notifications may initially end up.
When enabled, dashboard notifications are created on the administrator home page as a Plesk promo block. For example:
The vulnerabilities tab presents a table of the known vulnerabilities currently affecting the operating system. The total number of vulnerabilities is displayed on the tab out, while each row represents a single vulnerability. Critical vulnerabilities have a background color of yellow, orange or red based on severity.
The vulnerabilities table may be sorted by clicking on the links in the header row to sort by: CVE ID, severity rating, vulnerability attack vector, or fix availability. The vulnerabilities table includes the following columns:
- checkbox (pro version): this column includes a checkbox for selecting each fixable vulnerability. The checkbox in the header row selects or deselects all vulnerabilities.
- CVE ID: the vulnerability CVE (Common Vulnerabilities and Exposures) identifier. This is also a link to the operating system vendor’s security information for this particular vulnerability. Further information on CVEs can be found at the MITRE and NVD websites.
- Severity: the vulnerability severity rating as assigned by Opsani. Please see the section on Evaluating Vulnerability Impact below for an overview of these ratings.
- Description: the vulnerability description as published by the National Vulnerability Database, or, where this is unavailable, by the operating system vendor
- Vector: the attack vector for the vulnerability;
- Network: remotely exploitable over the network
- Adjacent: exploitable over the same physical or logical (e.g., local IP subnet) network
- Local: exploit requires local read/write/execute capabilities
- Physical: exploit requires physical access to the system
- Packages: a list of vulnerable packages. Full package version and release information is displayed in a tooltip.
- Fix Available:
- Yes: the operating system vendor has released package update(s) which fix the vulnerability
- Partial: the operating system vendor has release package update(s) which fix some, but not all, of the listed packages
- No: fixes for the vulnerable package(s) have not been released
- (pro version): this column may also include one of these clickable icons:
- fix this vulnerability now
- show information about fixing this vulnerability, e.g., fixing this vulnerability requires an update to one or more kernel packages. The extension does not install updates to kernel packages as these typically require a reboot and should be performed in conjunction with an overall system update. Please see the section on Manual System Updates below.
The packages tab presents a table of all the packages currently installed on the system. The total number of packages is displayed on the tab out, while each row represents a single package.
The table may be sorted by clicking on the Name link in the header row to sort by package name. The packages table includes the following columns:
- Name: package name
- Version: package version and release
- Arch: package architecture
Update History Tab
The update history tab presents a table of all historical package update operations performed by the extension, most recent first. The total number of historical updates is displayed on the tab out. The update history table includes the following columns:
- Date: the date and time of the update operation
- manual: update manually performed using the extension user interface
- automatic: auto-update performed by the extension
- CVE IDs: a list of CVE IDs selected for the update
Clicking on a row of this table expands that row vertically to show details of the particular update operation, as seen in the image below:
Update details include:
- Selected Vulnerabilities: the vulnerabilities selected to be fixed. The rightmost column of this table indicates whether or not the system is currently vulnerable to this CVE.
- Updated Packages: a list of packages updated by this operation, showing the original and updated package versions. If any dependent package updates were required, these are also shown in their own section.
- Opsani IDs: these identify the system and update operation. This information is shown as a reference in case needed when contacting Opsani support.
In many cases you may want to learn more about a vulnerability before deciding whether to take action and what action to take. The CVE IDs on the vulnerability tab are linked to the OS vendor security information for each CVE, and this is a good place to look for more detailed information, including vendor specific vulnerability details and severity ratings.
Detailed information on CVEs is also available from the NVD website. The NVD data also includes CVSS (Common Vulnerability Scoring System) metrics, and references providing additional information from vendors and security analysts. You can also just search for the CVE ID on the Internet.
The vulnerability severity ratings in the extension are provided by the Opsani service, and can be understood as follows:
|10.0||Critical vulnerabilities with severe impact (e.g., gaining root access or crash), typically exploitable remotely, relatively easy to exploit and having known active exploits||Most externally visible servers should be fixed immediately, even if they are not hosting mission critical apps or apps storing personal information|
|9.0||Critical vulnerabilities with severe impact and known active exploits; unlike severity 10, these are harder to exploit on servers (e.g., man-in-the-middle attacks)||Servers in medium sensitivity environments will also want to fix these right away, while most others may schedule the update as part of a regular maintenance process|
|8.0||Critical vulnerabilities that are either hard to exploit or unlikely to be affect most typical server installations (e.g., Java vulnerabilities requiring custom code to exploit)||Highly sensitive apps and/or apps executing subscriber-uploaded code (e.g., PaaS) may need to be updated immediately; most others can be updated as part of a regular maintenance process|
|1.0-5.0||All other vulnerabilities; the severity value is based on the NVD CVSS base score and vendor-provided severity levels, with 5.0 being the highest risk/impact and 1.0 being the lowest.||Impact and vulnerability should be evaluated to determine whether immediate action is required; for most systems, updates/fixes can be applied in regular scheduled intervals batching multiple updates together|
|0.0||Unknown severity level, e.g., for new and not-yet-published vulnerabilities||Review/find more information to decide on update action. As we compile information from multiple sources, in many cases we can provide more information and severity evaluation even before details are published in the NVD database.|
Vulnerabilities with a vendor released fix can be fixed by installing the updated package(s). You may use any of the methods below.
Opsani VCTR pro
The pro version allows you to select and fix vulnerabilities through its user interface, or automatically fix vulnerabilities through a daily task.
Plesk Onyx includes a System Updates manager for updating packages. This interface can be accessed using the icon in the extension or by navigating the Plesk UI to
Tools & Settings => Server Management => System Updates.
Server Command Line
Manually Updating Specific Packages
One or more packages may be updated by name using the server command line (e.g., bash shell). To execute these commands log in as root or run the commands using
RedHat or CentOS
yum package manager to upgrade vulnerable packages. You may upgrade one or more packages by name (without the version/release). For example, to upgrade the openssl and git packages:
yum upgrade openssl git
Ubuntu or Debian
apt package manager to upgrade vulnerable packages. There are two steps: 1) updating the package manager cache to get the latest information about available packages; and 2) upgrading packages. For example, to upgrade the openssl and git packages:
apt-get install openssl git
A general system update, which updates all installed packages, including kernel packages, may also be performed using the server command line. This typically requires a system reboot. To execute these commands log in as root or run the commands using
RedHat or CentOS
yum package manager to upgrade all currently installed packages:
Ubuntu or Debian
apt package manager to upgrade all currently installed packages:
Complete documentation for the
apt-get commands can be found online, and should be reviewed for a more detailed explanation of their operation.
Vulnerabilities Without a Published Fix
If a vulnerability has no published fix (no package update which fixes the vulnerability), and you do not want to wait for such a fix, you may be able to mitigate the vulnerability through other means, such as changing package configuration files (e.g., to disable a particular cipher in SSL). You will need to research a particular vulnerability to determine if this is possible. More detailed information is outside the scope of this document.
Updating packages to fix vulnerabilities has the same risks as updating packages in general. It is possible that a new version will have new bugs or be incompatible with other software you have installed, or be backwards incompatible with itself. Use your own experience, search system administration blogs, and/or consult server management professionals to evaluate the risk and decide whether to update or not. It is also wise to maintain a current backup of your system in case things go badly.
After performing package update(s) to fix a vulnerability, Opsani VCTR pro may still report that your system is vulnerable. There are several possible reasons:
- The system is configured to use a private or custom repository mirror (e.g., one managed by your hosting provider). That mirror may not yet be synced up with the official OS vendor mirror. Contact the mirror maintainer if this is the case to see if the mirror can be updated to include the fixed package versions.
- The fixed package version may not yet be published. In some cases, the OS vendor vulnerability database is updated to reflect an available fix before the new binary package is published.
- The system does not have repositories configured or enabled for the OS packages, or their updates, or their security updates.
By default Opsani VCTR pro selects package update targets in a conservative fashion. The update target package must come from the repository of the currently installed package or a configured repository that the extension considers safe:
- Ubuntu: safe repositories include the base, updates or security repositories for the distro. For example, if the distro alias is Trusty, valid repositories include: trusty, trusty-updates, trusty-security.
- Debian: safe repositories include the standard repositories for the distro (e.g., Jessie) or distro suite (e.g., stable).
- CentOS: safe repositories include the base, updates and extras repositories
- RedHat: only the repository of the currently installed package is considered safe, as other distro specific repository names or IDs vary widely.
This safe repository check can be disabled through the extension settings . When the safe repository check is disabled, the extension selects the package with the highest version/release from among all configured repositories as its update target.
Disabling the safe repository check can be particularly useful on RedHat systems where, otherwise, update targets are only chosen from the repository of the currently installed package.
Installing the extension also installs the Opsani telemetry client. In rare cases, the telemetry client may fail to be installed. This may happen, for example, if repository metadata cannot be updated because of a broken or inaccessible repository URL, or if the package manager database is locked by another process during extension installation.
If re-installing the extension does not fix the problem, you can manually install the telemetry client using the server command line (e.g., bash shell) as described below. To execute these commands log in as root or run the commands using
RedHat or CentOS
- Install the Opsani repository rpm:
- CentOS/RedHat 5:
curl -O https://s3.amazonaws.com/dgri-bits/download/dgri-rpm-repo-latest.noarch.rpm
rpm -U dgri-rpm-repo-latest.noarch.rpm
rm -f dgri-rpm-repo-latest.noarch.rpm
- CentOS/RedHat 6 and 7:
rpm -U https://s3.amazonaws.com/dgri-bits/download/dgri-rpm-repo-latest.noarch.rpm
- CentOS/RedHat 5:
- Clean the Opsani repository metadata (e.g., if performing a reinstall of the client):
yum clean metadata --disablerepo=* --enablerepo=dgri-rpm-repo
- Install the Opsani telemetry client:
yum install -y dgri-report --disablerepo=* --enablerepo=dgri-rpm-repo
Ubuntu or Debian
- Setup the Opsani repository:
echo 'deb https://s3.amazonaws.com/dgri-apt-repo/ production main' > /etc/apt/sources.list.d/dgri.list
curl -O https://s3.amazonaws.com/dgri-apt-repo/datagrid.key
apt-key add datagrid.key
rm -f datagrid.key
- Update the Opsani repository metadata (e.g., if performing a reinstall of the client):
apt-get update -qq -o Dir::Etc::sourcelist="sources.list.d/dgri.list" -o Dir::Etc::sourceparts="-" -o APT::Get::List-Cleanup="0"
- Install the Opsani telemetry client:
apt-get -y install dgri-report
The Opsani telemetry client can also be updated using the command line, just like any other package. When an update of the extension is installed, the telemetry client is also updated.
- Updating the mysql/mariadb server may cause Plesk to raise an error in its UI stating that it cannot connect to the database server. Ordinarily, the database server restarts after update and the error is transient. This error may occur whether the database server update is done by Opsani VCTR pro, the Onyx System Updates Manager, or manually using the server command line. Error messages displayed in the Plesk UI include:
- ERROR: PleskDBException: Unable to connect to database: mysql_connect(): No such file or directory /var/run/mysqld/mysqld.sock (Error code: 2002). Please check that database server is started and accessible
- ERROR: Zend_Db_Adapter_Exception: SQLSTATE[HY000]  No such file or directory
- CentOS 6.4 32-bit: after updating a large number of packages Opsani VCTR pro may initially report that the selected vulnerabilities are not fixed; however, after ~10 minutes they are shown in the extension UI as fixed. This appears to be a problem with the Python yum module on this particular OS not promptly reflecting the package updates.