Findings and playbooks

What a finding is#

A finding is one thing wrong with one server, site or monitor, for example "PHP 8.1 is past end of life" or "MySQL is listening on a public address". Each report from the agent is checked against the rule catalogue. A rule that fires opens a finding. The same finding is never opened twice for the same subject: the mount for a disk, the version for PHP, the service for a listener.

Severities#

Severity	Means	Alerts
High	Exposed, or will be soon. Act this week.	Sent at once, whatever the hour.
Medium	Will bite eventually. Act this month.	Sent at once, unless the channel has quiet hours on and it falls inside them.
Low	Housekeeping. Fix it when you are on the box anyway.	Held for the daily digest.

Some rules choose the severity from the evidence. A disk at 85% is medium and at 95% is high. A finding that becomes more serious is announced again. One that becomes less serious is not.

The life of a finding#

• Open. The rule fires and nothing is open for that subject.
• Still firing. The finding's last-seen time and count move, and its evidence is refreshed. No new alert.
• Resolved. The rule stops firing on a later report, and the finding resolves itself. Only a high severity finding sends an alert when it does.
• Snoozed. Hide a finding for 1, 7 or 30 days. It comes back when the time is up, and it still resolves by itself if the problem goes away while it is snoozed.
• Resolved by you. Allowed, and logged. If the rule fires again it opens as a new finding, which is how you find out that a finding was still true.
• Held. If the section a rule reads is missing because a probe failed, the rule does nothing. A failed probe never resolves a finding.

Rules that watch for hovering numbers use two thresholds, so a disk at 85% does not open and close a finding on every report. The disk finding opens at 85% and clears below 80%.

Re-check now#

Press Re-check now on a finding after you have fixed it. The request goes out with the server's next heartbeat, within a minute, and the report that follows is checked like any other. One package-list detail: the agent refreshes its own package lists once an hour, so a finding about pending updates can take up to an hour to clear.

Playbooks#

Every finding has a playbook, with the same five headings so they read the same across rules:

1. Why this matters. Two sentences you can repeat to a client.
2. Before you start. The risk: a reboot, a restart, a second SSH session to keep open.
3. Fix. The exact commands for this server's distribution, with the server's own details filled in, such as the PHP version or the mount.
4. Verify. The command that proves it worked.
5. Undo. How to put it back if something broke.

There are playbooks for Ubuntu, for Debian and, for any other distribution, a general one. The finding page says which one it used. Where the agent did not report a value, the playbook shows it in square brackets, such as [mount], instead of silently producing a broken command.

WellKept never runs a playbook. You read it, and you run it.

What WellKept checks#

Findings from the agent's reports:

Check	Severity
Security updates pending	High
Other updates pending	Low
Reboot required	Medium
SSH root login allowed with a password	High
SSH root login allowed with a key	Low
SSH password authentication on	High
A broken apt repository	Medium
PHP version past end of life	High
PHP version in security-fixes-only support	Low
Disk above 85% (above 95%)	Medium (High)
Inodes above 90%	Medium
MySQL, MariaDB, PostgreSQL, Redis or memcached listening on a public address	High
No active firewall	Medium
Unattended upgrades off	Low
fail2ban missing while SSH passwords are on	Low
PM2 not set to start at boot, or its list not saved	Medium or Low
A PM2 process errored or stopped	Medium
WordPress core behind the current release	Medium
A WordPress plugin, theme or core version with a known vulnerability	High, Medium or Low
Agent older than the minimum version	Low
Server clock drifting by more than five minutes	Low

Findings WellKept raises itself:

Check	Severity
The agent has not been heard from for three heartbeats	High
An SSL certificate close to expiry	Medium, High under 3 days
A domain close to expiry	Medium, High under 7 days

WordPress plugins, themes and core#

The agent reads the name and version at the top of each plugin and theme on a WordPress site (not wp-config.php, not the database), and WellKept compares them with the vulnerability data from Wordfence Intelligence, copied into WellKept every six hours. Core is checked from the version the agent has always reported.

• One finding per plugin, theme or core on each site, covering every advisory that affects the installed version. The severity is the worst one: Critical or High advisories give a High finding, Medium gives Medium, Low gives Low.
• A deactivated plugin still counts. Its files are on the server and some flaws can be reached through them. Deleting it clears the finding.
• No fix yet is still a finding. It tells you to remove or replace the plugin, because waiting is a decision too.
• A site whose plugins the agent could not read keeps its findings as they are, rather than clearing them, and so does every site until the first copy of the feed has arrived.
• The finding page lists each advisory with a link to its record on Wordfence, and carries Defiant's copyright notice and licence, and MITRE's for records that have a CVE number, as the licence asks. Alerts name the plugin and what to do, and link to that page.

PHP end-of-life dates follow php.net's supported versions policy. A PHP version older than WellKept's table counts as end of life. A newer one is unknown, and the rules hold rather than guess.

Filtering#

The Findings page filters by status, severity, server and rule. The dashboard shows the ten most serious. A finding on a server or monitor that has been removed is not counted.