SecureChain Beta

User guide

TuxCare Radar

TuxCare Radar 3.0 shows the vulnerabilities of your Linux servers. The tuxcare-radar3 agent on each server sends its installed packages once a day. The portal matches them against the advisories of the vendor and of TuxCare, and shows each server on the Hosts page.

A TuxCare Radar workspace #

A TuxCare Radar workspace shows hosts only. The top bar holds Hosts, Overview, Vulnerabilities, Packages, and Remediation. The workspace menu at the right of the header holds the users, the access tokens, the notifications, the audit log, and the settings.

The workspace accepts host scans only. A repository scan or a container image scan gets the answer This workspace is TuxCare Radar 3.0 and accepts host scans only. To scan repositories and images, use a SecureChain workspace. The SecureChain guide tells you how.

The Overview, Vulnerabilities, Packages, and Remediation pages count the hosts of the workspace. The portal explains each page. Remediation also lists the top fixes across hosts: the package updates that close the most open findings. Its section Time to remediate and SLA gives the time to fix the hosts by month, and the share fixed in time against the workspace, PCI DSS, CISA KEV, and NIST / FedRAMP deadlines, as CSV files and as a page to print or save as PDF. CIS compliance shows the CIS benchmark checks of the hosts: CIS compliance.

Install the agent #

Do these steps on each server. You need root access on the server, and the admin or the member role in the workspace.

1. Make a token #

  1. In your workspace, open the workspace menu at the right of the header, and select Access tokens.
  2. Type a Name, for example radar web-01.
  3. Select the rights Upload only. The agent needs the cli channel and the submit permission: it sends each scan, then reads the counts of the vulnerabilities of that scan. Such a token reads no other scan.
  4. Select Mint token and copy the token. The portal shows it one time only.

One token can serve many servers. Make one token for each group of servers that you want to revoke together.

2. Install the package #

TuxCare ships tuxcare-radar3 as an rpm package and a deb package, for x86_64 and aarch64, in the package repository of TuxCare Radar 3, https://repo.tuxcare.com/radar3. Set the repository first. For an rpm system, write /etc/yum.repos.d/tuxcare-radar3.repo:

[tuxcare-radar3]
name=TuxCare Radar 3
baseurl=https://repo.tuxcare.com/radar3/$releasever/$basearch/
enabled=1
gpgcheck=1
skip_if_unavailable=1
gpgkey=https://security.tuxcare.com/gpg/RPM-GPG-KEY-TuxCare

For Debian and Ubuntu, add the key and the apt source:

sudo curl -fsSL https://repo.tuxcare.com/radar/tuxcare.gpg -o /usr/share/keyrings/tuxcare.gpg
. /etc/os-release
sudo tee /etc/apt/sources.list.d/tuxcare-radar3.sources <<EOF
Types: deb
URIs: https://repo.tuxcare.com/radar3/$ID/$VERSION_ID
Suites: stable
Components: main
Architectures: amd64 arm64
Signed-By: /usr/share/keyrings/tuxcare.gpg
EOF
sudo apt-get update

Then install the package with the package manager:

sudo yum install tuxcare-radar3        # AlmaLinux, Rocky Linux, RHEL, CentOS, CloudLinux, Amazon Linux 2
sudo apt-get install tuxcare-radar3    # Debian, Ubuntu

TuxCare can also give you the package file: install it with sudo rpm -Uvh tuxcare-radar3-<version>-1.x86_64.rpm or sudo dpkg -i tuxcare-radar3_<version>-1_amd64.deb. The rpm then also writes the repository file. The package installs the agent as /usr/bin/tuxcare-radar3 with the short name /usr/bin/radar3 (a link), the configuration file, the system user radar3, a systemd timer, and a cron file for a server with no systemd. On a server with systemd, it turns the daily timer on. A server that runs TuxCare Radar 1.x keeps it: see TuxCare Radar 1.x.

3. Set the portal and the token #

Write the address of your workspace and the token in /etc/tuxcare-radar3/radar.conf. The package installs this file with example values. The file is not YAML: it holds one key: value on each line. A line that starts with # is a comment. There are no lists and no nested values, so tags is one comma-separated value:

portal-url: https://acme.sc.tuxcare.cloud
token: tuxr_...
# host-name: web-01
# tags: prod, web
# https-proxy: http://proxy.example.com:3128
# send-addresses: false
# send-containers: false

Each key appears one time. A line that is not key: value, or a key that you set two times, stops the run with exit code 2, and the error names the line.

The package makes the file readable by the agent only (owner radar3, mode 0600). The agent warns when other users can read it.

The file must stay readable by the user radar3. A file that you put in place later as root, for example a copy of radar.conf.rpmnew after an upgrade, belongs to root, and each run stops with exit code 2 (permission denied). Give the file back to the agent:

sudo chown radar3:radar3 /etc/tuxcare-radar3/radar.conf
portal-url (required)
The address of your workspace, the one that your browser opens. It must be https.
token (required)
The token of step 1.
host-name
The name of the host in the portal. The default is the hostname of the server.
tags
Up to 32 tags, separated by commas, on one line: tags: prod, web. A tag has 1 to 64 characters: letters, digits, and . _ : / = -. It starts with a letter or a digit.
https-proxy
The proxy for the connection to the portal. The environment variable HTTPS_PROXY wins over it.
send-addresses
true (the default) or false. The agent sends the IPv4 and IPv6 addresses of the network interfaces of the server, and the host page shows them. It leaves out the loopback, link-local addresses, and the interfaces of containers and virtual machines. With false, the agent sends no addresses, and the portal removes the addresses that it has for the host.
send-containers
true (the default) or false. The agent sends the list of the containers and the local images of the server (see Run the first scan). With false, the root step reads no container runtime, the agent sends no list, and the portal removes the list that it has for the host.

The environment variables SECURECHAIN_PORTAL_URL and SECURECHAIN_PORTAL_TOKEN win over the file. While the file holds the example values, each run stops with exit code 3 and names the keys to set.

The agent needs one outbound connection: HTTPS (port 443) to the portal. It does not follow a redirect, so the token goes only to the address in the file.

4. Run the first scan #

sudo -u radar3 tuxcare-radar3 run --wait 5m

The agent reads the installed packages from the rpm database or the dpkg status file, the kernels, the TuxCare licence, the KernelCare state when KernelCare runs, the addresses of the network interfaces (send-addresses), and the containers and the local images of the server (send-containers). It sends the list to the portal in one HTTPS request, and then reads the counts of the vulnerabilities that the portal found. It runs no package manager and changes nothing on the server. --wait 5m waits up to 5 minutes for the portal to match the scan. The output is a summary of four lines:

tuxcare-radar3 3.0.9: web-01 - almalinux-9.6 (x86_64), TES licence, 342 packages
portal: https://acme.sc.tuxcare.cloud, scan 7, matched in 4s
vulnerabilities: 12 open (high 3, medium 9), 2 no fix planned; the rows are on the portal's Hosts page
log: syslog, tag tuxcare-radar3

The agent prints no vulnerability: the Hosts page shows them. Without --wait, the agent reads the counts one time, and when the portal has not matched the scan yet, the summary says matching on the portal. The log of each run goes to syslog with the tag tuxcare-radar3. To see the document without a send, run tuxcare-radar3 run --dry-run.

The list of the containers comes from a root step: the socket of a container runtime gives root on the server, so the user radar3 joins no group of a runtime. The systemd service and the cron job run tuxcare-radar3 containers as root before each run, and the run sends the list that this step wrote. The step reads Docker, Podman, containerd, and CRI-O. For each container, the list has the name, the image reference, the digest of the image, the state (running or stopped), and the runtime. It has no environment, no command, no mount, and no label. The agent does not scan an image. The Containers tab of the host shows the list. A run with sudo -u radar3 does not run the root step itself, so on a server with systemd, run sudo systemctl start tuxcare-radar3.service to send the list with the first scan. A runtime that the step cannot read gives no list, and the run goes on.

To make a script or a CI job fail on a finding, add --fail-on with a rating: tuxcare-radar3 run --wait 5m --fail-on high exits with code 1 when an open finding is high or critical. A finding with no fix planned, a live-patched finding, and a finding of a kernel that does not run never fail the run. --output json writes the summary as JSON.

The exit codes:

0
The run did its work, or --on-portal-error warn made a portal failure a warning, or the dry run printed the document.
1
An open finding at or above the rating of --fail-on.
2
A flag or the configuration file is not correct, or the agent found no package database.
3
No token, the example values, a Radar 1.x configuration file, or a token that the portal refuses.
4
The portal is not reachable, answered with a 5xx or 408 status, gave an answer that the agent cannot read, or did not match the scan in the time of --wait.
5
The package database does not read. The agent sends nothing.
7
A fault of the agent itself.

5. The daily scan and the boot scan #

The systemd timer tuxcare-radar3.timer runs one scan each day, at a random time in the four hours after midnight. It also runs one scan after each boot, at a random time in the four hours after the first 15 minutes. After a reboot, the portal thus sees the new running kernel soon, and removes the reboot advice without a wait for the next day. The random times make sure that many servers do not send at the same moment, also when a whole fleet reboots. This is the schedule on systemd 229 and later. A server that was off at the time of the daily scan scans when it starts, so it can scan two times after a boot: the daily scan that it missed, and the boot scan. The package turns the timer on at the first install. Before each scan, the service copies the machine UUID of the server (/sys/class/dmi/id/product_uuid, which only root can read) for the agent, so a cloned virtual machine stays a host of its own. The service runs only when the timer starts it, so turn the timer on or off, not the service (systemctl enable --now tuxcare-radar3.timer, systemctl disable --now tuxcare-radar3.timer). Check the timer, run one scan now, and read the log:

systemctl list-timers tuxcare-radar3.timer
sudo systemctl start tuxcare-radar3.service
journalctl -t tuxcare-radar3 --since -1h

systemd before version 229, for example on CentOS 7, has no random delay. On such a server, the package gives the server fixed random values of its own: a time of day between 00:00 and 04:00 for the daily scan, and a wait after the boot of 15 minutes plus 0 to 4 hours, in /etc/systemd/system/tuxcare-radar3.timer.d/20-boot-delay.conf. The package writes each value one time, at the install or at the first upgrade that has it, and keeps it after that. After an in-place upgrade of the OS to systemd 229 or later, for example CentOS 7 to AlmaLinux 8 with leapp, the next install or upgrade of the package removes 10-random-time.conf and 20-boot-delay.conf when you did not change them. It keeps a file that you changed.

A server with no systemd, for example CentOS 6, uses cron: sudo cp /usr/share/tuxcare-radar3/tuxcare-radar3.cron /etc/cron.d/tuxcare-radar3. The cron job runs each day, and one time after each boot: its @reboot line waits 15 minutes. Each run then waits a random time of up to 4 hours. The cron job runs as root to copy the machine UUID for the agent, then runs the agent as radar3. The portal needs the machine UUID or a machine ID to know the server, and a minimal CentOS 6 server has no machine ID. The log goes to syslog with the tag tuxcare-radar3.

A host that sends no scan for 14 days shows its Last scan date in amber, and after 30 days in red.

Keep the agent up to date #

The page of a host names the version of its agent. When a newer Radar release exists, the agent line says older than and names the newest release, for example tuxcare-radar 3.0.9 older than 3.0.10: the agent names itself tuxcare-radar, and its package is tuxcare-radar3. Update the package with the package manager of the server (sudo yum update tuxcare-radar3, or sudo apt-get update && sudo apt-get install --only-upgrade tuxcare-radar3). The next scan sends the new version, and the warning goes. The version is the version of the agent, not of the package: a package that changes only its packaging, for example 3.0.8-2 after 3.0.8-1, keeps the version.

Version 3.0.10 changes the configuration file and the user. An update from 3.0.9 moves what the server had:

The portal learns the newest release from a version file that the Radar release publishes next to the packages, https://repo.tuxcare.com/radar3/latest. On a portal that you run yourself, the operator sets the address of that file in radar.latest_url of the portal configuration. When the key is empty, or the portal has not read a version from the file yet, the page shows no warning: the portal does not guess the newest release from the versions that your servers send. When a later read fails, the portal keeps the release of the last good read.

TuxCare Radar 1.x #

TuxCare Radar 1.x is the package tuxcare-radar of https://repo.tuxcare.com/radar. TuxCare Radar 3.0 is a package of its own, tuxcare-radar3, in a repository of its own. It installs next to 1.x, and an update of 1.x never installs 3.0. The two packages have no file in common: 1.x keeps its command tuxcare-radar (and radar), its configuration file /etc/tuxcare-radar/radar.yaml, its cron job, and its repository file.

To move a server from 1.x to 3.0, install tuxcare-radar3 (steps 1 to 4). When the server shows on the Hosts page, remove 1.x: sudo yum remove tuxcare-radar or sudo apt-get remove tuxcare-radar. The agent of 3.0 does not read the keys of Radar 1.x (base-url, apikey, and the others): a 1.x API key is not a portal token.

Next #

Next: Read a host