外掛標籤
開發者團隊
原文外掛簡介
ATV Web Security puts your WordPress website into a “protected” state where visitors can still read and use the site, but nothing can persist changes to it — not plugins, not compromised administrators, not direct database access, and not a PHP shell.
How it works — multiple independent layers:
WordPress protection — plugin/theme/core operations, file editors, user creation, option writes and administrator actions are intercepted and denied.
Database protection (manual) — switch it on from the Dashboard layer switches when you want it. The database account’s write privileges are REVOKED at the MySQL/MariaDB server level using a separate privileged MySQL account (allowed flows are re-granted only row-level INSERT/UPDATE/DELETE), so even direct SQL from arbitrary code is refused. The site account’s own GRANT authority is never consumed, because revoking it would permanently destroy the restore path. An application-layer SQL firewall blocks write queries even when privileges cannot be changed. Selecting a protection tier never turns this on.
Filesystem protection (manual) — switch it on to make wp-config.php and .htaccess read-only, and to mark those files plus the plugin’s signing key immutable with chattr where the host allows it. Original permissions are snapshotted and restored when the lock is switched off. wp-admin, wp-includes, plugins and themes stay writable on purpose so WordPress can still update itself; changes there are detected by integrity monitoring and the new-file watch instead. Selecting a protection tier never turns this on.
Upload protection — executable uploads are blocked by extension, MIME and content; the uploads directory is hardened so scripts cannot execute there.
API protection — REST, AJAX, XML-RPC, WP-CLI and cron-based mutation is blocked. Reads remain available.
Integration with the PHP firewall — traffic under wp-includes is rejected by a small mu-plugin, links to private files are blocked, and low-level PHP tricks are neutralised.
Integrity monitoring — baseline hashes of core, configuration and plugin files are verified periodically.
New-file watch — a scheduled scan of the WordPress installation detects files that were not there before, stores them as signed alerts, and reports the ones nothing explains in a dashboard notification and by email. Each finding shows the full file path, the detection time and size, with Dismiss and Delete buttons after review. Files that a WordPress core, plugin, theme or translation update explains — including installs and updates performed outside WordPress — are kept on the Integrity tab with their cause instead of being announced. Database tables are watched the same way. Scan frequency, email delivery and recipients are configurable on the Integrity tab.
Access rules (optional) — AbuseIPDB-powered website access block by IP reputation score and a login country rule that only allows the admin login page from a country you select. Both are off by default, respect an IP/CIDR allowlist, fail open on lookup errors and cache results to stay within API rate limits.
Backend lock — the plugin lives in its own top-level admin menu; once protection is ON and a master password is set, the settings page stays hidden behind a lock screen until that password is entered (12-hour unlock, forged-cookie safe, brute-force rate limited). The master password accepts 8-64 letters, digits and symbols, and is the single password accepted to turn protection OFF (older 12-digit passwords keep working).
Email verification code (Two-Factor, optional) — administrators can be asked for a six-digit code sent to their email address in addition to their WordPress password. The code field appears on the login form itself, right after the password is accepted, so the whole flow stays on one screen with no page refresh. Codes are valid for 10 minutes, can be resent once a minute (five codes per quarter hour), and the account locks for 15 minutes after five wrong entries. If the mailer cannot deliver, the login stays blocked on purpose — recovery is a single command from the shell: wp atvws otp disable.
Passkeys / WebAuthn (optional, recommended for “only my device”) — registers a hardware-backed credential with Windows Hello / TPM, Touch ID, a phone or a security key. The private key is created and used inside the device and never reaches the website, a cookie, JavaScript or a backup. With enforcement on, protected administrator logins are accepted only from a device whose passkey verifies; an account with no passkey is never blocked, and recovery stays available. An account covered by a registered passkey skips the emailed code — either factor alone satisfies the login.
Trusted device lock (optional) — the portable fallback for browsers without WebAuthn. Binds protected actions to one computer with a one-time token in a secure HttpOnly, SameSite cookie. Any other computer gets a “link your device” screen that requires the master password, and linking/unlinking always requires it. The Recovery tab stays reachable so a lost device can never lock the owner out permanently. A verified passkey also satisfies this gate.
Behavior policy (optional) — studies privileged activity and locks the session instantly when the risk score crosses a threshold: failed unlock (15), failed disable attempt (25), failed restore attempt (20), failed login (20), refused passkey login (10). Scores are windowed per source IP for 24 hours; the owner (a linked-device or verified passkey session, or an allowlisted IP) is never scored and can clear a lock with the master password.
Cryptomining defence — four independent layers: every rendered page is checked before it leaves PHP and script tags naming known mining services or pools are removed; WordPress’s own HTTP API is refused for pool domains; a time-sliced filesystem scan walks wp-content and reports native executables and miner configuration markers; and a database scan searches posts and options for injected script blocks. The scans are report-only and surface on the Miners tab — nothing is quarantined by a heuristic match.
Detection & monitoring — a signed baseline of every script and stylesheet the login page loads, with a report the moment a new address appears (login page watch); a scheduled self-probe that asks the site for risky paths (backups, dumps, dotfiles, debug logs) and flags anything the web server would hand to anyone (sensitive file probe); honeypot decoy paths and hidden form fields that trigger escalating, temporary bans for automated scanners; and a local vulnerability inventory that flags plugins and themes that are outdated, abandoned (no release for 2+ years) or no longer listed in the wordpress.org API — computed locally, without phoning home.
Snapshot backup and restore — a signed copy of every file WordPress can change (core, plugins, themes, uploads, the whole web root and wp-content drop-ins, wp-config.php) plus a complete database dump with the real CREATE TABLE schema of every table. A snapshot is only saved after it validates: every row dump must decode, row counts must match, and the options table must contain a working siteurl — a backup that cannot rebuild a bootable site is never accepted. The “current” snapshot is captured automatically the first time protection is enabled and is what the documented manual recovery procedure uses; keep as many named snapshots as you like (for example before an update) plus one automatic snapshot every day, each independently verifiable, restorable and deletable from the Snapshot tab or WP-CLI. There is no retention limit and nothing is ever deleted automatically. Restore is verified end to end: it requires protection and both manual write locks to be off, refuses a damaged or incomplete snapshot before touching anything, moves files that are not in the snapshot to quarantine, dumps and drops tables that are not in the snapshot, replays every row inside a database transaction with each write checked, and rolls the database back with the exact MySQL error if anything fails — so a restore can no longer leave the site with an empty options table.
Live progress — snapshot create, snapshot restore and integrity scans show a progress bar the moment you press the button, then fill in with stage, items processed and percentage while the operation runs.
Total protection score — one honest number out of 100, shown on the Dashboard and in the header badge on every screen. Each security setting is worth a fixed number of points and only earns them once it is verified active, so the score drops the moment a layer stops working. The Dashboard lists every setting that is still pending, how many points it is worth, and which tab fixes it.
Setup tour — the first time you open the plugin, a guided walkthrough takes you through the tabs in order: Diagnostics, Set protection level, Snapshot, then the rest of the configuration screens.
Clear layout — every screen is grouped into Everyday, Configure, Check and Incident, with a live protection badge, plain-language explanations of what each button does, and destructive actions visually separated from safe ones.
Recoverable — a forgotten master password no longer locks you out of the settings. Reset it from the plugin’s runtime directory in uploads with cPanel/FTP (create emergency-reset.key, then open emergency-reset.php), or from the shell with wp atvws password reset. Both routes sign out every session and are logged. WordPress account passwords can only be reset from WP-CLI. Email-code settings can be switched off from the shell with wp atvws otp disable.
Protection tiers:
MEDIUM and STRONG both apply the same WordPress-level layers: WordPress, REST, AJAX, XML-RPC, upload, PHP shielding, integrity, CLI and cryptomining defence. Neither tier touches database grants or file permissions.
LIMITED — protection is on but a core layer is switched off or did not verify after activation; the dashboard table shows which one before you rely on it.
Database and filesystem write protection are separate manual switches on the Dashboard. No tier turns them on, and they stay exactly as you left them when you change tiers. Both require protection to be on:
Database write lock — the database account’s write grants are revoked where a privileged MySQL account is configured (the wizard or the ATVWS_DB_ADMIN_* constants), and the SQL firewall blocks write queries from PHP regardless. It reports partial when only the firewall is enforceable. The site’s own GRANT authority is never consumed.
Filesystem write lock — wp-config.php and .htaccess are made read-only, and those plus the plugin’s signing key are marked immutable via chattr where available. Original permissions are snapshotted and restored when you switch it off. wp-admin, wp-includes, plugins and themes are deliberately left writable so WordPress can update; integrity monitoring and the new-file watch report changes there. On a host where PHP cannot change file permissions the switch refuses cleanly instead of pretending to enforce it.
Both locks change the server itself, so neither is ever applied as a side effect of choosing a tier or enabling protection.
Choosing or changing a tier requires the master password, so a hijacked admin session cannot quietly weaken the site. Every layer also has its own switch for fine-tuning a tier; picking a new tier resets those switches. The old names STANDARD, AUTO and HARDENED still work and map to Medium and Strong.
Allowed writes:
Persistent visitor flows (comments, contact forms, WooCommerce, user registration) are BLOCKED by default. The owner re-enables only what the site genuinely needs from the “Allowed Writes” page. Everything else stays blocked.
Turning protection OFF is deliberately difficult (a strong request): you must submit a form, confirm a checkbox, type the exact phrase, and re-enter your account password (plus an optional passphrase). Emergency recovery paths (WP-CLI, a wp-config constant, a recovery file, or manual panel instructions) are documented to make sure you can always regain write access — see docs/RECOVERY.md.
External services
This plugin can connect to the AbuseIPDB API. This is optional and off by default; it is used only for the IP intelligence features (the site-wide IP reputation block and the login country check), and only when you switch those features on.
What the service is and what it is used for:
AbuseIPDB provides an IP reputation and geolocation look-up. The plugin sends an IP address to AbuseIPDB to learn whether that address has been reported for abusive behaviour (a reputation score) and which country it is in, so the plugin can block abusive visitors or restrict administrator logins by country. No result is required for the site to work: if the lookup fails, the request is allowed (fail-open) and the failure is logged.
What data is sent and when:
The visitor’s IP address is sent to AbuseIPDB only at the moment a protected request is checked by one of the IP intelligence features above, together with your own AbuseIPDB API key (in the request header) needed to authenticate the lookup.
No other data is sent. No personal data, no site content, no account information and no usage statistics leave the site. Requests are rate-limited, cached, and only made while the feature is enabled.
This service is provided by “AbuseIPDB LLC”. Terms of use, privacy policy.
Terms of use: https://www.abuseipdb.com/legal
Privacy policy: https://www.abuseipdb.com/privacy
