cms: Replace Wordfence's scanner with Salt-managed checks and harden WordPress hosting

[jpmckinney]

Replaces what Wordfence's scanner and vulnerability feed did for the WordPress sites with Salt-managed checks, prepares the replacement for its two-factor authentication, and closes several hardening gaps found along the way. Wordfence itself is not removed here; that follows once 2FA is on the Two Factor plugin.

Why

An audit of Wordfence's own tables on coalition (dump of 29 July) and of iThemes Security's on corporate (backup of 11 September) found:

• Every firewall block Wordfence recorded was for a PHP file that does not exist or for xmlrpc.php, both now denied by Apache. Its scanner never recorded a finding. 179 of 196 notifications were plugin-update nags.
• The one real attack, 33 IPs each trying the coalition administrator's username once or twice in February 2026, was stopped by the password and TOTP, not by rate limiting. It reached PHP despite Basic auth, most likely over XML-RPC, which Wordfence's own setting allowed and Apache now denies.
• iThemes recorded 20 vulnerabilities on corporate in two years, all version lag with a fix available, resolved by updating; zero integrity findings. Its file-change detection had not run since 2018.
• The only thing Wordfence still provides that nothing else does is TOTP for administrators.

What this does

• Checks (checks.enabled per site): a daily integrity check with wp core verify-checksums and wp plugin verify-checksums, mailing only on findings, and a daily updates check (check-updates.php, run with wp eval-file) that lists updates WP_Automatic_Updater::should_update() declines, such as major versions, and plugins whose update API gave no answer, which catches abandoned plugins and lapsed licenses. Plugins wordpress.org does not distribute are listed in checks.premium_plugins.
• Apache: deny wp-config.php, paths inside dot-directories except .well-known/, PHP under wp-includes/ (except wp-tinymce.php) and wp-admin/includes/. Salt now sets wp-config.php to 600 and the WordPress directories to 755.
• wp-config constants from pillar (wordpress:constants, PHP source, per-site overrides): DISABLE_WP_CRON, DISALLOW_FILE_EDIT, WP_AUTO_UPDATE_CORE.
• Must-use plugins: require-two-factor (redirects administrators without a second factor to their profile until they enrol, and limits Two Factor to TOTP and backup codes; inert until the Two Factor plugin is active), disable-user-enumeration (hides the users REST endpoints and sitemap from anonymous visitors), a central wordpress:mu_plugins list, files moved to files/mu-plugins/, key renamed to mu_plugins.
• cms state collapsed to one loop over wordpress.sites, with cron moved under it.

Production state

Applied on 12 September: DISALLOW_FILE_EDIT on both sites, the Apache denies, the file modes, coalition's cron jobs and inert require-two-factor. Pending the next state.apply cms: the renamed check script, the daily updates schedule, the well-known regex simplification, WP_AUTO_UPDATE_CORE on corporate, disable-user-enumeration on coalition, and the files/mu-plugins/ move (a no-op on disk). Corporate's opt-in to auto-updates, the checks and 2FA enforcement is kept out of this PR as a patch, to apply once its administrators expect it.

Follow-ups, not in this PR

• Install Two Factor on coalition, enrol the administrators, then remove Wordfence; same on corporate after its rollout. Every administrator re-enrols once, since secrets do not port.
• Restrict the origin to Cloudflare (Consider only accepting 80/443 connections from Cloudflare #645) and rate-limit wp-login.php at Cloudflare (Integrate Fail2Ban with Cloudflare #621); fail2ban's web jails likely never match behind the proxy.
• Corporate: replace ALLOW_UNFILTERED_UPLOADS with safe-svg, remove the abandoned page-for-post-type.
• Explored and not implemented: a cooldown before auto-installing plugin releases, keyed on when a version is first seen. It would have covered the June 2024 wordpress.org supply-chain attack and Gravity Forms' backdoored 2.9.12 in July 2025, at the cost of the same delay on every genuine security fix.

Verification

Salt states rendered against the real pillars with a Jinja harness and parsed; read-only dry runs against cms after each structural change; the unless guards for constants exercised against the production wp-config files; require-two-factor and disable-user-enumeration tested end to end on a local copy; the .well-known regex tested on a local Apache; phpcs and the Sphinx build clean.

Also explored

• Why Two Factor. Wordfence Login Security, the standalone 2FA plugin, was closed on wordpress.org on 17 August 2026. Of the free alternatives, only WP 2FA has built-in role enforcement and a grace period, but it has had two 2FA-bypass advisories in 18 months; Two Factor has none, hence Two Factor plus a small enforcement plugin. Per-role enforcement is in review upstream (Add: Site-wide Two-Factor enforcement per user role WordPress/two-factor#845); once it ships, require-two-factor can shrink to the provider restriction.
• Cloudflare Access in front of wp-login.php and /wp-admin/ would replace Basic auth with Google-backed 2FA, but needs Consider only accepting 80/443 connections from Cloudflare #645 first, a bypass for admin-ajax.php, and email PINs for the agency's editors. Deferred.
• Faster auto-updates. WordPress checks twice daily. Running wp cron event run wp_version_check wp_update_plugins wp_update_themes hourly would install fixes within the hour. Not done.
• Database credentials through the constants mechanism. Feasible without exposing the password in ps: wp-cli's --prompt reads the value from stdin, which cmd.run can supply with hide_output. It needs a second code path for secrets, so file.replace stays.
• Change detection for premium plugins. Neither security plugin verified them either: every ACF Pro file was knownFile = 0 in Wordfence's table, and iThemes' file-change scan last ran in 2018. A nightly hash diff of those directories would be the equivalent; not done, since every legitimate update would report.
• Virtual patching is the one capability lost. iThemes Pro's Patchstack integration auto-applied a firewall rule for W3 Total Cache ≤ 2.10.5 on 4 September, four days before the fix shipped. Nothing here does that; the mitigations are auto-updating everything and keeping the plugin count low. W3 Total Cache has since been removed from corporate.
• The audit window is short. Wordfence prunes its logs to about 2,000 login rows, iThemes to 15 days, and the S3 backups keep 31 days, so the evidence covers weeks rather than years, except iThemes' vulnerability table.

https://claude.ai/code/session_01VuqqoFUnSXGQBC5aKGg5pQ

🤖 Generated with Claude Code

[jpmckinney]

Ideas from that are deliberately not done: https://developer.wordpress.org/advanced-administration/security/hardening/#disable-file-editing

• DISALLOW_FILE_MODS: disables the auto-update must-use plugin, core updates and the agency's plugin updates.
• Move wp-config.php above the web root: breaks the file.replace in salt/cms/init.sls, the documented wp config set steps, and probably the agency's Buddy.works deploys.
• Make wp-content non-writable by the site user: PHP-FPM is the owner by design; uploads and updates would break.
• Basic auth on all of /wp-admin/: breaks admin-ajax.php for Fluent Forms and Gravity Forms. The wp-login.php-only scope is correct.
• Rename the table prefix on a live database.