What this check reads
The shared engine probe decides what is present: a mysql, mysqld, psql, mongod or redis-server binary on PATH, a running mysqld, mariadbd, postgres, mongod or redis-server process, or a config path (/etc/postgresql, /var/lib/pgsql, /etc/mongod.conf, /etc/redis/redis.conf, /etc/redis.conf). For each engine found it then reports a version taken from the binary rather than the server: mysqld --version / mariadbd --version / mysql --version, psql --version, mongod --version and redis-server --version, each reduced to the first version-shaped number in the output. A running sqlservr process adds mssql(manual-review) to the same line, because SQL Server on Linux is detected but never assessed. The threshold is only whether that assembled list is empty: one or more engines is a PASS, an empty list is a SKIP.
When it applies
Always runs, needs no root, and never fails - it is the inventory that opens the Network Isolation script. It reports whatever the shared engine probe found (HAS_MY, HAS_PG, HAS_MG, HAS_RD) plus sqlservr if that process is running. Because the probe matches client binaries, running processes and config directories, a host with only a database client installed is still reported as having that engine. Version strings come from the binaries on PATH, not from the running server. SKIP means no engine was detected at all, which on a pure web or application host is the expected result.
What each result means
| Result | When | What it means |
|---|---|---|
| PASS | At least one engine found (informational list) | At least one engine is present, named with the version of its binary; this says what exists, not that any of it is configured safely. |
| SKIP | None found | Nothing was measured. No engine was detected on this host, which is not the same as every database passing. |
Why it matters
An inventory is the precondition for every other control: you cannot patch, isolate or restrict an engine you do not know is installed. This check is informational - it never fails - and exists so the rest of the Network Isolation script has a stated baseline, and so a reviewer can tell "no MongoDB findings" (nothing installed) apart from "MongoDB was never assessed". CIS benchmarks and NIST SP 800-128 both start configuration management with an accurate asset and software inventory. The version numbers matter for the same reason: an engine past end of life stops receiving security fixes regardless of how well it is configured.
Why it fails, and when it is wrong
- It never returns FAIL or WARN by design; PASS here means "this is what was found", not "this is secure".
- Detection matches client binaries too, so a host with only the
mysqlclient and no server counts asHAS_MY=1. Every later MySQL check then SKIPs with "not accessible", which reads like a problem but is correct. - Versions come from whichever binary is on
PATH. When only the client is installed, the reported version is the client's and can differ from the server's - cross-check withSELECT VERSION();. - Containerised engines are invisible to all of these probes.
- SQL Server (
sqlservr) is detected but never audited; it is reported asmanual-review. - An engine installed under a non-standard path, with no running process and no config in the expected place, is missed entirely.
How to fix it
Nothing to fix - this check reports, it does not judge. Use it as the starting point for the checks that do act on the inventory:
- Anything listed here should be covered by the matching Network Isolation, Authentication, Transport Encryption and Least-Privilege checks. If an engine appears here but every check for it SKIPs, that is the gap worth closing (usually missing root/socket access).
- Compare each reported version against the vendor lifecycle at endoflife.date and upgrade anything past end of life - see the End-of-Life Runtimes check.
- If an engine is listed that you do not need, removing it is the cheapest hardening available:
apt purge <package>/dnf remove <package>.
Verify the fix
# Reproduce the detection:
command -v mysql mysqld mariadbd psql mongod redis-server 2>/dev/null
pgrep -ax mysqld mariadbd postgres mongod redis-server sqlservr 2>/dev/null
ls -d /etc/postgresql /var/lib/pgsql /etc/mongod.conf /etc/redis/redis.conf 2>/dev/null
# Server versions (authoritative - the check reports binary versions):
sudo mysql -N -e 'SELECT VERSION()'
sudo -u postgres psql -X -tAc 'SHOW server_version'
mongosh --quiet --eval 'db.version()'
redis-cli INFO server | grep redis_version
# Engines running in containers, which this check cannot see:
docker ps --format '{{.Names}}\t{{.Image}}' | grep -Ei 'mysql|maria|postgres|mongo|redis'Debugging
Correct on a host with no database. If you expect one, it may be containerised (use the docker ps command above), installed under a non-standard path with no running process, or simply stopped with no config in the usual place.
This is the most useful signal the inventory gives. Either only the client is installed (no server to audit), or the audit lacks the root/socket access those checks need. Test with sudo mysql -N -e 'SELECT 1' / sudo -u postgres psql -X -tAc 'SELECT 1'.
You are seeing the client binary's version. Ask the server itself with the commands above.
SQL Server is detected but nothing in this knowledge base audits it. Review it against Microsoft's own security baseline by hand.
A PASS is not a security statement. Act on the checks that follow it.
Sources
- endoflife.date: MySQL
- endoflife.date: MariaDB
- endoflife.date: PostgreSQL
- endoflife.date: MongoDB
- endoflife.date: Redis
- PostgreSQL versioning policy
- MongoDB lifecycle schedules
How the script reads this
Next
Re-run the Network Isolation audit after applying the fix and confirm this check moves to PASS. CtrlOps runs all 7 checks over your existing SSH connection and scores the result, so the change is visible without reading another config file.
All 7 Network Isolation fixes