| 开发者 | edznet |
|---|---|
| 更新时间 | 2026年11月12日 22:24 |
| 捐献地址: | 去捐款 |
| PHP版本: | 7.2 及以上 |
| WordPress版本: | 7.1 |
| 版权: | GPL-2.0-or-later |
| 版权网址: | 版权信息 |
wp-login.php with credentials baked into the URL, e.g. https://yoursite.com/wp-login.php?log=Ben&pwd=T3m. While enabled, any visit to the login page with credentials in the query string is refused with 403 Forbidden. All logins must use the normal login form.
Admin Login Alerts
Every time an administrator signs in, an email is sent with the username, the IP address they connected from, their browser, and the exact time. Legitimate admin logins are rare, so an alert for a login you didn't make is an early warning that an account may be compromised. Alerts are on by default and go to the first administrator's email address — you can point them at any address from the settings page.
Block Accounts
Block any account from logging in with a single click — the "Block login" action appears on the Users screen, and "Unblock login" restores it whenever you're ready. A blocked account is refused at the login screen with a friendly message, and its existing sessions are ended immediately so it can't stay signed in. Because the plugin is built around the first-administrator lock, it can also block administrator accounts: any administrator can block a non-admin account, while only the first administrator can block another administrator. The first administrator's own account can never be blocked, so you can't lock yourself out of the site.
Every attempt to sign in as a blocked account is logged — username, IP address, browser and time — on the EDZNET Guard settings page, so you can see who keeps trying.
Plugin Audit and Unverified Plugin Blocking
A common way into a WordPress site is to sign in with a stolen password, upload a fake plugin as a ZIP file and activate it. These fake plugins often hide themselves from the Plugins screen and quietly inject scripts for visitors.
Security Guard checks every installed plugin against the official file checksums published by WordPress.org, so it knows whether each plugin is an untouched WordPress.org release, a WordPress.org plugin whose files have been changed, or something installed from elsewhere. It also scans plugin and must-use plugin code for high-risk techniques: running hidden or decoded code, running commands sent in a web request, loading code from a blockchain ("EtherHiding"), hiding plugins from the Plugins screen and heavy obfuscation.
edznet-security-guard folder to /wp-content/plugins/.The site's first administrator account — the user with the Administrator role and the earliest registration date (registration dates are not changed when an account is renamed). If that account is deleted, the lock moves to the next earliest-registered administrator.
Only the first administrator account can change these settings. This is intentional: a compromised admin account should not be able to disable the protections.
Yes — temporarily disable "Block administrator creation", create the account, then re-enable it.
Yes. The block is enforced at the core wp_insert_user() level, so admin-created users, REST API calls, and XML-RPC requests are all refused while the setting is enabled.
Any successful sign-in by a user with the Administrator role — including the first administrator. Each alert includes the username, display name, IP address, browser, the time of the login (with timezone) and whether a two-factor code was verified. Alerts are sent to the first administrator's email unless you set a different address on the settings page. On sites with several administrators, the wording depends on who signed in. When the alert is about your own login it says "If this was you, no action is needed". When it is about another administrator it names them and explains how to check with them, block the account and reset its password if the login wasn't expected.
Once enabled, an administrator enters their username and password as usual, then a 6-digit code from an authenticator app (Google Authenticator, Authy, 1Password, Microsoft Authenticator, and any other TOTP-compatible app). The code is generated from a secret that is only shown once, as a QR code or a text key, and verified server-side against that secret. Codes refresh every 30 seconds.
In their profile under "EDZNET Guard — Two-Factor Authentication", or on the login page itself: an administrator who hasn't set up 2FA yet is shown the enrollment screen at their next login instead of being signed straight in.
The first administrator can open the administrator's profile and reset (remove) their two-factor authentication, then they sign in again and set up a new secret. If the locked-out administrator IS the first administrator, the secret can be removed with one click from their own profile by an administrator who has already completed 2FA — or, if nobody can get in, the two-factor authentication can be turned off directly in the database by deleting the edznet_guard_2fa_enabled option.
It checks the WordPress version, plugins and themes on your site against a database of known vulnerabilities and tells you what to fix. It comes with an EDZNET Geo API Pro key, which also covers geolocation lookups (https://edznet.io/api-services). Each key covers Vulnerability Watch on one site; the free count needs no key.
No. A copy on another address is recognised as a copy and stops using the live site's key, so your live site keeps being checked. Use a separate key for a staging site that needs its own checks.
Click "Turn off" on the old site (or ask EDZNET support to release the key), then turn it on on the new site. A key that hasn't been used for 60 days is freed automatically.
Not built in — but it pairs with our EDZNET Geolocation plugin, which blocks whole countries or continents from your site's pages, blocks individual IPs, and shows where comments, logins and registrations come from. When Geolocation is active, Security Guard links straight to its country-blocking screen. Install it from WordPress.org.
On the Users screen, hover over a user and click Block login. The account is refused at the login screen and its existing sessions are ended. Click Unblock login (or the button on the EDZNET Guard settings page) to restore it at any time.
Yes. Any administrator can block a non-admin account; only the site's first administrator can block another administrator. The first administrator's own account can never be blocked, so the site owner can't be locked out.
Yes. Every attempt is recorded on the EDZNET Guard settings page under Blocked login attempts — username, email, IP address, browser and time, newest first (up to the last 100).
Yes. Untick "Email me when an administrator logs in" on the EDZNET Guard settings page. The toggle is locked to the first administrator like the other settings.
Only the site's first administrator. "Disable comments globally" is a protected setting, and the "Close commenting on all posts" and "Delete all pending comments" buttons are locked the same way so a compromised admin account cannot purge comments or weaken moderation.
No. It only hides comment forms and makes new posts default to closed. To change existing posts, use "Close commenting on all posts". To remove comments that are waiting for moderation, use "Delete all pending comments".
They are front-end filters and CSS rules. Hidden content is removed from the markup the theme outputs, and a small stylesheet hides common author/date/comment-closed elements. Because themes structure their post meta differently, these are a best-effort helper for most themes rather than a guarantee for every theme.
No. Hiding post authors, dates and comment-closed text only affects the front end of the site. The admin screens always show full author and date information.
onsubmit attribute into the enqueued js/admin.js.css/admin.css and css/login.css, and all JavaScript into js/qr-init.js and js/profile-2fa.js, loaded via wp_enqueue_style() / wp_enqueue_script(). No inline style attributes remain in the plugin's markup.admin_post handler (block/unblock account, clear blocked-login log, two-factor setup/removal) now verifies the nonce first and then re-checks current_user_can( 'manage_options' ) explicitly, instead of relying only on the first-administrator identity check.list_users capability.qrcode.js library, and stated explicitly that the plugin contacts no external service.