Predax Security (formerly IPSentry) -- WordPress 插件

开发者	ipsentry
更新时间	2026年8月19日 05:21
PHP版本:	7.4 及以上
WordPress版本:	7.1
版权:	GPLv2 or later
版权网址:	版权信息

Block bots, VPNs, Tor users, proxies and high-risk visitors before they can attack your WordPress site. Most WordPress attacks — brute-force logins, fake registrations, comment spam, vulnerability scans — come from anonymised connections: VPNs, open proxies, Tor exit nodes, and rented datacenter servers. Predax Security identifies those visitors the moment they arrive and stops the risky ones at the door, before they can log in, register, comment, or even load a page. Every visitor IP is checked in real time against a continuously-updated threat intelligence database of known VPN providers, open proxies, Tor exit nodes, datacenter ranges, and web crawlers, and given a 0–100 risk score. You choose exactly what gets blocked — by category, by country, or by risk score threshold. Privacy-first by design: on a fresh install the plugin is off by default — no visitor data is sent anywhere until you explicitly enable a protection preset via the setup wizard or the Settings → Protection tab. What it turns away

Hidden connections — visitors arriving over a VPN, proxy or Tor, if you choose to block them.
Servers pretending to be people — traffic from rented cloud machines rather than home broadband.
Known bad addresses — IPs with a history of attacking other sites.
Countries you do not serve — block or allow by country, or by whole region.
Attack attempts — a built-in firewall catches injection, scanner and file-probe requests.
Password guessers — repeated failed logins are locked out, faster for risky addresses than ordinary ones.
Fake signups and spam — throwaway email addresses and bot comments are rejected.

Each of these is a switch you set. Nothing is blocked until you choose a protection level. Choose which crawlers may access your site — enforced, not requested robots.txt is a request a crawler can ignore. Blocking by user-agent trusts a header any script can fake. Predax blocks crawlers by the IP ranges their operators publish, checked on your own server on every request — so a crawler that ignores robots.txt still gets a 403. Three independent switches, all set to allow by default:

Search engines (Googlebot, Bingbot, DuckDuckBot, Applebot) — allowed and protected: verified search crawlers stay exempt from your other category rules, so your rankings are never collateral damage.
AI crawlers (GPTBot, OAI-SearchBot, ChatGPT-User, ClaudeBot, PerplexityBot) — your content, your call.
SEO crawlers (AhrefsBot) — they use your bandwidth to build third-party analytics products. Blocking them does not affect your own search rankings.

A visitor that merely claims a crawler's user-agent gets no special treatment in either direction: unverified traffic passes through your normal risk rules, where fake-bot detection handles impersonators. Note that this covers crawlers whose operators publish their IP ranges. Crawlers that publish no ranges (for example CCBot, Amazonbot or Bytespider) are judged by the normal bot and risk rules instead. Blocking that never quietly costs you visitors or rankings The real risk of any blocking rule isn't the attacker it misses — it's the genuine reader it turns away without you ever finding out. Predax Security is built to make that failure mode visible and reversible:

Verified search engines are exempt from category rules. Googlebot, Bingbot, and other crawlers confirmed by reverse DNS are never blocked by your VPN, proxy, datacenter, country, region, or risk-score rules. Search engines crawl from datacenter IP ranges, so a datacenter rule would otherwise turn them away — and over time cost your site its search rankings. Threat rules still apply to everyone: Tor, known-malicious IPs, the firewall, your own blocklist, and active lockouts block an IP regardless of what its reverse DNS says.
Wrongly-blocked visitors can tell you. A visitor stopped by one of your category rules can report that they're genuine. The report appears in the Threat Log with the full risk detail for their IP beside it, so you can judge it in context — and a report never unblocks anyone on its own; you always decide. Visitors blocked for actual attacks (firewall signatures, honeypot traps, known-malicious IPs, brute-force lockouts) never see this option at all.
One-click allow-listing. Approve any IP straight from the Threat Log instead of copying it into a settings field. A reader caught by an over-strict rule can be let back in as fast as they were turned away.

The dashboard already separates attacks stopped from visitors turned away by your own category rules — and on a typical site the large majority of screened traffic is bots and datacenter infrastructure rather than people. You can see exactly what your settings are doing, and undo any block that shouldn't have happened, without leaving the log. Key Features

Per-crawler policy — allow or block search engines, AI crawlers (GPTBot, ClaudeBot, PerplexityBot) and SEO crawlers (AhrefsBot) independently, enforced by each operator's published IP ranges rather than the spoofable user-agent header
Security Dashboard — real-time overview with blocking activity chart, threat breakdown, top targeted paths, protection status, and country analysis
Real-time VPN/Proxy/Tor/Datacenter detection — checks every visitor against live threat intelligence
Search-engine safe — verified crawlers (Googlebot, Bingbot) are exempt from category rules, so screening doesn't affect how your site is crawled and indexed
Risk score thresholds — block IPs above a configurable risk score (0–100)
Country geo-blocking — block or allow specific countries and regions
Login protection — block high-risk IPs from attempting to log in
Registration protection — stop fraudulent account creation
Comment protection — block spam and bot comments at source
Visitor protection — optionally check all page visitors (with 1-hour caching to minimise API calls)
XML-RPC & REST API protection — extend blocking to XML-RPC calls and REST API requests
Disposable email blocking — reject registrations using throwaway email services
Custom block page — show a branded 403 page instead of the default WordPress error
Whitelist/blacklist — override decisions for individual IPs or CIDR ranges
One-click allow-listing — approve any IP directly from the Threat Log, no settings field to edit
Visitor reports — visitors blocked by a category rule can tell you they're genuine; reports land in the Threat Log with full risk detail for your decision
Threat log — view and export all blocked events with IP, reason, and timestamp
Event tracking — log successful checks for audit and analytics
Settings import/export — back up and restore your configuration as a JSON file
WP-CLI commands — manage whitelists, blacklists, and run IP tests from the command line

Free Tier Click "Connect with Predax" in the setup wizard to create your free account and link your API key automatically — no separate sign-up step, no key to copy or paste. The free plan includes:

1,000 IP checks per day
5,000 IP checks per month
VPN, proxy, Tor, and datacenter detection
Country and region data

No credit card required. More Power With Paid Plans The free tier is plenty for small sites, but busier sites use up the included checks faster. Paid plans raise the monthly limit from 5,000 up to 25 million IP checks, with higher request rates and bulk lookups. The dashboard shows your live usage each month, so you can see exactly when it's time to upgrade — same plugin, same settings, just a bigger allowance on your existing API key. How It Works

You install the plugin and connect your site during the Setup Wizard. Click "Connect with Predax" to create your free account (or log into an existing one) and link your API key automatically — no key to copy or paste. Prefer to do it manually? You can still paste in an existing API key instead.
You pick a protection preset in the Setup Wizard (or enable individual protections from Settings → Protection). This is the explicit opt-in — no data leaves the site until you do this.
A visitor makes a request to your site.
Predax checks their IP against the threat intelligence API (results cached between 5 minutes and 1 hour per IP, following the lifetime the API recommends).
If the risk score exceeds your threshold, the visitor is blocked with a configurable message.
All block events are logged in the WordPress database for review.

WP-CLI Commands wp ipsentry status — show current configuration and threat counts wp ipsentry test-ip <ip> — run a live API check on any IP wp ipsentry whitelist add <ip> — add an IP or CIDR to the whitelist wp ipsentry whitelist remove <ip> — remove from whitelist wp ipsentry blacklist add <ip> — add an IP or CIDR to the blacklist wp ipsentry log --limit=20 — view recent threat log entries

1.15.0

New: disposable-email screening now checks a continuously updated list of thousands of throwaway providers instead of the short built-in list. Enable it under Settings -> Registration. Only the DOMAIN part of the address is checked (for example "gmail.com") - the address itself, and everything before the @, never leaves your site. The built-in list is still consulted first and still applies if the API is unreachable, so no site loses a block it had before.
New: registrations from a domain that cannot receive mail, or with a machine-generated mailbox name, are recorded in the Threat Log. Both are flag-only signals and never block anyone on their own.
Improved: a visitor already blocked by their IP address no longer triggers an email lookup as well - faster registrations and less of your plan allowance spent.
Fixed: a malformed email domain could previously cause repeated API errors that temporarily paused IP screening. Malformed domains are now rejected on your own server and never sent.
Note: email-domain lookups count towards your Predax plan allowance. Results are cached for six hours per domain.

1.14.0 Crawler Policy — decide which crawlers may access your site

New: independent allow/block switches for search engines (Googlebot, Bingbot, DuckDuckBot, Applebot), AI crawlers (GPTBot, OAI-SearchBot, ChatGPT-User, ClaudeBot, PerplexityBot) and SEO crawlers (AhrefsBot), in Settings → Protection → Crawler Policy.
Enforcement uses the IP ranges each operator publishes — verified identity, not the user-agent header — so unlike robots.txt (a request) or user-agent blocking (trivially faked), a blocked crawler is actually turned away. A visitor merely claiming a crawler's user-agent is neither blocked nor allowed by this policy; your normal rules apply to them in full.
All three switches default to Allow, so nothing changes on your site until you switch one off. Blocks appear in the Threat Log with their own reasons. Search-engine safety
Fix: verified search engine crawlers are no longer served the JavaScript Challenge page. That page returns HTTP 200 with no real content, so a challenged crawler could index "Verifying your browser…" in place of your pages. The exemption requires DNS-verified identity — a faked crawler user-agent still gets the challenge.
Fix: crawler verification now accepts reverse-DNS names in any capitalisation, and with or without the trailing dot. Previously a legitimate crawler whose DNS answered in mixed case could be treated as fake. Privacy and control
The Community Threat Network opt-in is now offered as an explicit, unticked checkbox in the setup wizard, with a plain-English description of exactly what is shared. It stays off by default and can be changed any time in Settings → Advanced.
New: "Behind a proxy or CDN" setting. Leave it on (the default) if your site is behind Cloudflare, a CDN or any reverse proxy. Turn it off if visitors reach your server directly, so forwarded IP headers — which a visitor can fake — are ignored in favour of the real connecting address. Housekeeping
The plugin now identifies itself and its version in its API requests.
reCAPTCHA verification failures caused by a network error reaching Google are now recorded in the Threat Log instead of passing silently, and the fail-open behaviour can be changed with the ipsentry_recaptcha_fail_open filter.
Removed two settings that were registered but no longer had any effect.
Corrected the documented cache lifetime: results are cached between 5 minutes and 1 hour per IP, following the lifetime the API recommends.

1.13.0 Firewall

The firewall now inspects large form submissions. Previously, if a request's form fields totalled more than 8KB, every firewall rule except the user-agent check was skipped - so an attack in the URL or a form field went uninspected and unlogged if any other field on the page was large. Attacks hidden inside an oversized single field are now inspected too.
Note: because these requests were never inspected before, a very long submission (a lengthy comment or contact-form message) that contains code-like text - backticks, $(...), or <script written in prose - may now be blocked where it previously slipped through. This is the same behaviour shorter submissions have always had. Allow-listing now takes effect immediately
Clicking Allow on a blocked visitor now unblocks them straight away. Previously only ordinary page views recovered; the visitor's REST (wp-json) and XML-RPC requests kept being refused for up to an hour, which broke comment forms, block themes and app access for someone you had just allowed.
Adding an IP to the allow-list on the Settings page now does the same. Previously it had no immediate effect at all, making the allow-list look broken. Brute-force protection
Fixed the risky-IP login limits not applying. Login protection was reading a cached verdict that nothing wrote any more, so an attacker on a VPN, proxy or Tor exit was given the relaxed limit for clean addresses instead of the stricter one, and no auto-blacklist followed. Reporting
The dashboard no longer counts monitored or flagged visitors as blocks (measured on real data, this removed a 13.6% over-count), and now correctly counts auto-blacklist and temporary lockouts, which were being missed.
The hardening score now reflects the XML-RPC setting. It was reading an option the settings screen has not written since 1.10.0, so hardening XML-RPC never moved the score.
Risk levels now match the bands the Predax API actually issues.
Fingerprint events now respect the "event tracking" setting instead of being recorded regardless.
Fixed a custom block-page title showing escaped characters (an apostrophe appearing as '). Efficiency
Predax Security and Predax Fraud Guard now share one cached verdict per visitor, so a site running both no longer spends two checks on the same person.
Cached verdicts now follow the lifetime the API recommends (up to an hour) instead of a fixed five minutes, which significantly reduces how much of your allowance a busy site uses.
The cache key now covers the whole request rather than the IP alone, so one visitor's result can no longer be served to a different visitor behind the same network. Housekeeping
Uninstall now cleans up correctly on multisite networks (per-site tables and options were previously left behind) and removes leftover lookup locks.
Added optional automation-detection scoring based on browser header consistency. It only scores and never blocks; enforcement is not enabled.
New one-time notice confirming your first blocked threat, so a fresh install shows evidence it is working.
Tested up to WordPress 7.1.

1.12.5

Fix: hitting your plan's DAILY check limit no longer reports it as the monthly limit. The notice used to say screening was paused "until your quota resets on the 1st" when it actually resumes at midnight UTC the same day - up to a month of wrong information at the moment it matters most. It now names the right limit and tells you the exact time screening resumes.
Improved: fewer API checks are used for the same visitors. When several requests for one visitor arrive at the same time (a page load often makes several), the plugin now performs a single lookup and shares the result instead of one lookup per request. Busy sites will notice their daily allowance lasting longer.

1.12.4

Fix: region blocking now saves "All of Africa", "All of Asia" and "All of the Americas" selections. Previously they were silently discarded on save - the checkbox reverted and no visitors from those regions were ever blocked, with no error shown.
Fix: re-running the Setup Wizard and choosing "Monitor Only" now also switches off known-malicious IP blocking. Previously that one rule stayed on if a stricter preset had enabled it, so a preset promising to block nothing kept blocking.
Fix: the "Blocked Today" / "This Week" dashboard widget no longer counts monitored or flagged visitors as blocks - it now reports only visitors who were actually blocked.
Fix: the weekly protection widget now counts auto-blacklisted attackers and brute-force lockouts, which it previously listed as categories but could never actually count.

1.12.3

New: an invitation to join the Community Threat Network now appears on your dashboard, with a one-click opt-in. Sites in the network warn each other, so an attacker stopped on another Predax site is already known to yours. It remains entirely opt-in and was previously easy to miss - it lived only as a toggle in Settings.
Improved: clearer wording about exactly what is shared - the attacking IP address and the reason it was blocked, never visitor personal data and nothing about your site.

1.12.2

Security: the firewall now runs on every request. It previously ran last, so any visitor the other rules had already judged skipped it entirely - including VPN visitors on the Recommended preset, where VPN is set to monitor. Attacks from those visitors were not inspected or logged.
Security: the firewall is no longer skipped for an hour after a visitor's first clean request. Visitor results are cached to keep your site fast; that cache described the visitor, not the request, so it was letting later attacks through uninspected.
Security: the firewall now keeps working when the Predax API is unreachable. An outage previously disabled it, even though it runs entirely on your own site.

1.12.1

Fix: VPN visitors were being blocked as "datacenter". Because VPN servers live in datacenters, the datacenter rule ran first and caught them — so turning "Block VPN" off did nothing, and the Threat Log showed "datacenter" instead of "VPN". VPN and proxy are now checked first, so your toggles work and the log names the real reason.
Fix: visitors set to "monitor only" for VPN are no longer blocked when datacenter blocking is on.
Fix: the dashboard's Recent Blocks list showed "Monitored" for visitors who were actually blocked. Only locally-triggered blocks were recognised; blocks based on IP intelligence were mislabelled.
Fix: sites in the Community Threat Network were reporting every visitor as having no VPN/proxy/Tor/datacenter signal, so shared intelligence was based on incomplete data.
Fix: honeypot-triggered blocks were shown as "Monitored" on the dashboard.
Fix: the [ipsentry_badge] shortcode counted only locally-triggered blocks, so most sites displayed zero.
Improved: block page reference codes are now readable — "DATACENTER_BLOCK" instead of "DC_BLOCK", "FIREWALL_SQL_INJECTION" instead of "WAF_SQLI", and so on.

1.12.0

Fix: verified search engines (Googlebot, Bingbot) are no longer blocked. On the Strict preset the datacenter rule was blocking them, which over time removes a site from search results.
New: visitors blocked by a category rule can tell you they're genuine. Reports appear on the Threat Log with full risk detail, and you can allow the IP in one click.
New: allow any IP directly from the Threat Log.
New: tell us why you're deactivating, so we can fix it.

1.11.2

Fix: turning OFF both "Block VPN" and "Monitor VPN" now genuinely ignores VPN visitors. Previously they fell through to the risk-score check and were blocked anyway — and the Threat Log recorded the reason as "risk score", never mentioning VPN, making the blocks impossible to explain. Same fix for the proxy toggles.
Fix: the "Predax Protection This Week" dashboard widget was undercounting. It only matched internally-logged blocks and missed every visitor, login, comment, registration, XML-RPC and REST block — which is most of them.
New: the dashboard widget now separates attacks stopped (scanners, injection attempts, known-malicious IPs, brute force) from visitors turned away by your own category rules (VPN, Tor, country, risk threshold), so a large block count can actually be interpreted. If policy blocks outnumber attacks, it says so and links to your settings.
New: choosing the Strict preset in the Setup Wizard now warns that Strict blocks all VPN and datacenter visitors, which on public content sites turns away ordinary readers, and points to Recommended instead.

1.11.1

Fix: known-malicious IP blocking (introduced in 1.11.0) now correctly reads the malicious signal from the Predax API — a normalization gap meant it never actually triggered a block.
New: the block page now names the specific reason for a malicious-IP block ("known botnet command-and-control server" or "known hijacked or malicious network range") instead of a generic message.
New: the API key field is now masked (with a Show/Hide toggle) instead of shown in plain text — both on the Settings page and in the Setup Wizard's manual-entry step — and is excluded from Settings Export/Import so it can never leave the site in a shared file.

1.11.0

New: known-malicious IP blocking — a dedicated category (separate from your general risk threshold) for botnet C2 and hijacked-netblock IPs (Settings → Advanced → WordPress Hardening). Off by default; enable it via the Setup Wizard's Recommended/Strict presets, or with the one-click "Enable malicious-IP blocking" button on the dashboard.
New: "Predax Protection This Week" dashboard widget — a native WordPress dashboard widget summarizing blocked threats by category (VPN, Proxy, Tor, Datacenter, Malicious) over the last 7 days.
New: filter the Threat Log by reason — narrow the log to just one block category instead of scrolling the full list.

1.10.0

New: User/author enumeration blocking — stops ?author=N probes and the REST users endpoint from leaking usernames to logged-out visitors (Settings → Advanced → WordPress Hardening). On by default in the Recommended and Strict presets.
New: XML-RPC hardening modes — choose "Block amplification" (neutralises pingback DDoS reflection and system.multicall brute-force amplification while keeping normal XML-RPC working, e.g. the WordPress mobile app) or "Disable all". Replaces the old on/off "Disable XML-RPC" toggle; your existing choice is migrated automatically.
New: Firewall auto-ban escalation — an IP that trips the Web Application Firewall repeatedly within a short window is temporarily banned outright, instead of being filtered one request at a time.
New: API circuit-breaker — if the Predax API becomes slow or unreachable, the plugin now fails open instantly after a few consecutive failures instead of making every request wait on the timeout, and shows an "API degraded" notice on the dashboard. The API request timeout was lowered from 8s to 3.5s.
New: real API usage meter — the dashboard's "API Usage" ring now shows your actual monthly IP-check usage against your plan's quota (fetched hourly), with an upgrade link when you're above 80%.
New: quota notice — if your plan's monthly IP checks run out (screening pauses and traffic is allowed through until the quota resets), the plugin now tells you on its admin pages instead of failing silently. Dismissible per month.
Docs: installation instructions rewritten for installing from the WordPress.org plugin directory; added a section on free vs paid plan limits.
New: "Learn more" links throughout Settings pointing to the step-by-step guides in the Predax Help Center.
Improved: the dashboard now tells you when protection is only partially active — if an API key is connected but Visitor Screening is off, the status reads "Partially Active" with a one-click "Enable visitor screening" button (your VPN/proxy/Tor/country rules only apply to logins until it's on). The Detection Modes and Country & Region settings sections show the same hint inline.
Performance: the whitelist, blacklist, honeypot-URL, blocked-user-agent, and country/region list options no longer autoload on every request. A one-time migration updates existing installs.
Fix: WP-CLI and WP-Cron requests are never subject to visitor temp-blocks.

1.9.4

Compatibility: tested with WordPress 7.0 and PHP 8.2. No deprecations or warnings under WP_DEBUG.
Branding: setup wizard logo and wordmark refreshed to Predax (the "(formerly IPSentry)" suffix remains in the plugin name for clarity). API key field now shows the current prdx_live_… placeholder. Existing ipsent_* keys continue to authenticate normally.
Fix: setup wizard OAuth flow no longer fails with a blank "0" page on the redirect back from predax.io. The callback action is now passed explicitly so the flow is robust against future predax.io frontend changes.
Internal: removed an unused legacy settings template that was shipping in the zip without being loaded anywhere.

1.9.3

Branding: IPSentry has been rebranded to Predax. The plugin name, description, and admin labels now use the Predax name. The plugin slug, internal class names, text domain, settings, and your existing API key all remain unchanged — the upgrade is purely cosmetic and 100% backwards compatible.
Branding: external links from the admin pages now point to predax.io instead of ipsentry.io. The legacy ipsentry.io URL still redirects, so older bookmarks continue to work.
Compatibility: legacy ipsent_* API keys created before the rebrand continue to authenticate normally. New keys generated at https://predax.io/dashboard/api-keys start with prdx_. Both work.
No data changes. No setting resets. Nothing to reconfigure after the update.

1.9.1

Privacy & compliance: Community Threat Network now has an explicit opt-in toggle in Settings → Advanced (disabled by default). Clarified documentation: no data is shared with the community network unless the site admin explicitly enables it.
Privacy & compliance: visitor protection and login protection are now off by default on fresh installs. They are enabled the moment a user completes the Setup Wizard and picks a protection preset (that click is the explicit opt-in). Existing sites upgrading from 1.9.0 are not affected — add_option() respects existing values, so if you already had these on, they stay on.
Security: reordered nonce verification before capability check on the test-connection AJAX endpoint.
Security: added IP/CIDR validation on the blacklist and whitelist inputs — invalid entries are now silently dropped rather than stored.
Security: added uninstall.php that cleans up all plugin options and drops both custom tables when the plugin is deleted.
Privacy: added wp_add_privacy_policy_content integration so administrators can pull suggested Privacy Policy text from Tools → Privacy.
Code quality: extracted inline styles from the OAuth callback page, front-end footer badge, and comment honeypot into external stylesheets. Removed an inline onclick handler from the [ipsentry_lookup] shortcode.
Code quality: internationalised hard-coded English error messages in admin endpoints. Localised number formatting in event counts and threat badges.

1.9.0

New: Security Dashboard — a dedicated dashboard page with real-time threat statistics, blocking activity chart, protection status overview, firewall summary table, top targeted paths, threat type breakdown, and country analysis.
Improved: Settings page redesigned with cleaner layout and better visual hierarchy.
Improved: Setup wizard redesigned with modern dark theme and clearer protection preset cards.

1.8.0

New: HTTP Security Headers — enable HSTS, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, and Permissions-Policy from the plugin settings. One toggle to harden your site's browser security.
New: Google reCAPTCHA v3 — invisible bot protection for login and registration forms. No puzzles for visitors.
New: Honeypot URL Traps — hidden decoy URLs that catch automated scanners instantly. Pre-configured with 8 common trap paths.
New: User-Agent Blocking — block known malicious bots, scanners, and scrapers by their User-Agent string. Ships with 20 pre-configured patterns.
New: 404 Threshold Blocking — automatically block IPs that trigger excessive 404 errors (scanner behavior). Configurable threshold and temporary or permanent blocking.
New: Known Bot Verification — verify that visitors claiming to be Googlebot, Bingbot, and other search engines are legitimate using reverse DNS + forward DNS confirmation. Catches fake bot impersonators.
New: JavaScript Challenge — invisible browser verification that blocks bots unable to execute JavaScript. Clean dark-themed challenge page.
New: Comment Spam Honeypot — hidden form field that catches spam bots filling in invisible fields. Zero false positives.
New: Browser Fingerprint Scoring — detects inconsistencies between User-Agent claims and actual browser capabilities on the login page. Logs suspicious fingerprints.
New: Request Pattern Analysis — identifies bot-like request timing patterns (machine-precise intervals vs human browsing).
New: WordPress Hardening — one-click toggles to disable XML-RPC, hide WordPress version, and disable file editing.
New: IP Lookup Shortcode [ipsentry_lookup] — embed an IP threat check widget on any page. Dark and light themes available.
New: Protected Badge Shortcode [ipsentry_badge] — display "Protected by Predax — X threats blocked" on your site.

1.7.0

New: One-Click Connect — click "Connect with Predax" in the setup wizard to link your site instantly. No API key to copy or paste. Just log in (or create a free account), approve, and you're protected.
New: OAuth2 Authorization Code flow with PKCE for secure, industry-standard site authentication.
Improved: Setup wizard now defaults to one-click connect with manual API key entry as a fallback option.

1.6.0

New: Setup Wizard — guided 3-step setup on first activation. Connect your API key, choose a protection level (Recommended, Strict, or Monitor Only), and you're done in under a minute.
New: Protection presets — one-click configuration for common security profiles. Re-run anytime from Settings > Developer > Run Setup Wizard.

1.5.5

Improvement: All block messages now clearly state "Predax has blocked your access" — visitors always know who blocked them and why.
Improvement: VPN detection now uses ASN-based matching for major VPN providers (NordVPN, Mullvad, ProtonVPN, Surfshark, ExpressVPN, and more). Previously, some VPN IPs were only flagged as "datacenter" if not in the feed list.

1.5.4

New: Reason-specific block pages — blocked visitors now see a clear, context-aware message explaining exactly why they were blocked (VPN detected, high-risk IP, Tor network, temporary lockout with countdown, etc.) instead of a generic error.
New: Custom block page is now ON by default for all new installs. No configuration needed — blocked visitors immediately see a branded, professional page.
New: Temporary lockout block message now shows the exact remaining wait time (e.g. "Please wait 2 hours and 30 minutes before trying again").
New: All login, registration, and comment blocks now show reason-specific messages appropriate to the context.
Improvement: Exponential backoff for clean IP lockouts — each repeated lockout doubles in duration (30min → 60min → 120min → ... → 24hr max). Resets on successful login.
Improvement: Residential proxy and timezone mismatch signals now treated as risky (trigger permanent blacklist path, not temporary lockout).

1.5.3

New: Risk-aware failed login protection — VPN/proxy/datacenter/high-risk IPs are permanently blocked after 3 failed attempts. Clean/residential IPs get a temporary lockout only (default 30 min), protecting legitimate users who forget their password. (If the Community Threat Network is enabled — it is off by default — these block events are also shared with the network.)
Improvement: Lockout thresholds and duration are configurable in Settings → Protection.
Fix: Test Connection button in Developer tab no longer submits the settings form, and now works reliably on slow/local dev environments (LocalWP, etc.).

1.5.2

Fix: VPN/proxy users set to "Monitor" mode were incorrectly blocked by the risk threshold. The risk score on VPN/proxy IPs is elevated by the VPN/proxy flag itself — so if you've chosen to monitor (not block) those users, the threshold no longer overrides that decision.

1.5.1

Improvement: Settings page redesigned with tabbed interface (Protection, Notifications, Advanced, Developer)
Improvement: Save and Test Connection buttons now shown inline next to the API key field
Improvement: Help tooltips added to every setting explaining what each option does
Improvement: Visitor screening enabled by default for new installs
Improvement: Custom block page now shows "Protected by Predax" footer branding
Improvement: Developer tools (Test IP, Import/Export) moved to dedicated Developer tab

1.5.0

New: Web Application Firewall — detects and blocks SQL injection, XSS, path traversal, file probes, known scanner tools, and command injection attempts
New: Community Threat Network (opt-in, off by default) — when you enable it, IP blocks propagate to other opted-in sites in the network via the Predax community score
New: WAF toggle in plugin settings (default on); independent of the risk score threshold

1.4.0

New: Custom block page — show a branded 403 page with configurable title, message, and support link
New: XML-RPC protection — block high-risk IPs from XML-RPC calls
New: REST API protection — block high-risk IPs from WP REST API requests
New: Disposable email blocking — reject registrations using throwaway email services (30+ providers)
New: Settings import/export — back up and restore configuration as a JSON file
New: WP-CLI commands — manage lists and run IP tests from the command line (wp ipsentry)
New: Test IP override — set a fixed IP in settings for local/staging testing
Fix: Registration protection now correctly flags disposable email domains

1.3.0

New: General visitor protection — optionally check all site visitors (with transient caching)
New: Country and region blocking with full ISO 3166-1 alpha-2 support (249 countries)
New: Custom risk scoring weights — adjust how much each threat type contributes to the risk score
New: Telemetry pipeline — anonymised threat signals can feed community intelligence when the Community Threat Network is enabled (off by default)
Improvement: VPN/proxy/Tor options now have Off/Monitor/Block modes for finer control
Fix: Transient cache key collisions on multisite installs

1.2.0

New: Event tracking log — view all API check events (not just blocks) for audit purposes
New: Admin dashboard widget with 7-day threat chart
New: CIDR range support for whitelist and blacklist entries
Improvement: API client now retries once on timeout before failing open

1.1.0

New: Registration protection — block high-risk IPs from creating accounts
New: Comment protection — block high-risk IPs from posting comments
New: Configurable risk threshold (default 50)
New: CSV export for the threat log
Fix: Login protection now respects whitelist entries correctly

1.0.0

Initial release
Login protection with VPN, proxy, and Tor detection
Whitelist/blacklist management
Threat log
Dashboard widget

Predax Security – Block VPN, Proxy, Tor & Bot Traffic

标签

下载

详情介绍:

安装:

屏幕截图:

升级注意事项:

常见问题:

更新日志: