Get monitoring software from its maker, then check it

We are not a distribution point. Nothing on this domain is a package, archive or binary. If a site offers you a monitoring server in a repackaged bundle, skip it: your monitoring host holds credentials for half your network, which makes it the last machine you want to run unverified code on.

Order of preference

For open-source monitoring on Linux, the best source is almost always the vendor’s own signed package repository. It gives you current releases, signature checks on every update and a clean upgrade path. Your distribution’s repository is a reasonable second choice for tools like Nagios Core, but versions often lag by a year or more. Container images are fine when they come from the project’s own namespace and you pin them by digest. For commercial tools, the only right place is the vendor’s site or customer portal, reached by typing the address or using a link you trust.

Signed repositories and GPG keys

A signed repository means your package manager refuses packages that were not signed by the key you trusted. The step people skip is checking that the key itself is right: compare its fingerprint with the one published in the vendor’s documentation before trusting it.

# Debian / Ubuntu — keep each vendor key in its own keyring
sudo mkdir -p /etc/apt/keyrings
curl -fsSL "$VENDOR_KEY_URL" | sudo gpg --dearmor -o /etc/apt/keyrings/vendor.gpg
gpg --show-keys --with-fingerprint /etc/apt/keyrings/vendor.gpg   # compare with the vendor docs
echo "deb [signed-by=/etc/apt/keyrings/vendor.gpg] $VENDOR_REPO_URL $(lsb_release -cs) main" \
  | sudo tee /etc/apt/sources.list.d/vendor.list

# RHEL / Rocky / Alma — make sure gpgcheck stays on
sudo rpm --import "$VENDOR_KEY_URL"
grep -E '^(gpgcheck|repo_gpgcheck)' /etc/yum.repos.d/vendor.repo   # gpgcheck=1
rpm -K ./package-name.rpm                                           # "digests signatures OK"

Many vendors ship a small “release” package that adds the repository and key for you. That is convenient, but take a moment to confirm the key fingerprint afterwards all the same. Never set gpgcheck=0 or [trusted=yes] to make an error go away; the error usually means the key rotated and the vendor has published a new one.

Checksums and signed checksum files

When you fetch a release archive or desktop build directly (Nagios Core source, a Wireshark, Angry IP Scanner or LizardSystems Network Scanner build, for example), verify it against the checksum the project publishes — and, where one exists, verify the signature on the checksum file itself. Wireshark, for instance, publishes a GPG-signed list of hashes for each release.

# Linux / macOS
sha256sum -c SHA256SUMS --ignore-missing
gpg --verify SHA256SUMS.asc SHA256SUMS

# Windows PowerShell
Get-FileHash .\release-file -Algorithm SHA256
Get-AuthenticodeSignature .\release-file   # Status should be "Valid", signer should be the vendor

Containers

Use images from the project’s own namespace (for example zabbix/zabbix-server-pgsql or librenms/librenms), avoid unofficial rebuilds, and pin the digest you tested so an upstream tag change never surprises you in production:

docker pull zabbix/zabbix-server-pgsql:ubuntu-7.0-latest
docker inspect --format '{{index .RepoDigests 0}}' zabbix/zabbix-server-pgsql:ubuntu-7.0-latest
# then reference image@sha256:... in your compose file

Red flags

• A “portable” or “pre-configured” edition of a product the vendor does not offer in that form.
• A key-generator, activation tool or modified license file for a commercial product. These are how monitoring servers get compromised.
• A request to disable antivirus, SELinux or signature checking to complete setup.
• A domain that is almost the vendor’s name, reached from an ad or a forum post rather than typed by you.