WordPress Plugin — ReportedIP Hive (Full Edition)

ReportedIP Hive is a community-powered WordPress security plugin. It turns every protected site into a sensor: when one site is attacked, the hive learns and every other site can refuse the attacker before the first request lands. Real-time threat intelligence, thirteen attack sensors, four-method 2FA, progressive block escalation. Open source, published under GPLv2+ on GitHub.

Installation

Setup Wizard (9 steps)

The wizard runs on first activation and can be re-launched any time from the plugin settings. Each step persists immediately, so you can stop and resume.

Operating Modes

Two modes — switch between them at any time without losing local data.

What you get on each tier

The Hive plugin itself is fully functional on the Free tier — local protection, all thirteen sensors, all four 2FA methods. Paid tiers bundle managed delivery infrastructure (mail and SMS) and higher Community-Network quotas. See the Pricing page for the full comparison and to upgrade.

Business is multi-bookable. Every Business figure above is per licence. Book Business x2, x5, x10 or x20 at checkout (or change it later in the Stripe Customer Portal) and the per-day checks/reports, the monthly 2FA mail/SMS allowance and the domain count all scale with your licence count — e.g. x5 = 75 domains and 500,000 checks/day. A volume discount applies automatically from x2 upwards. PRO stays single-licence; Enterprise figures are unlimited (fair use) and are never multiplied.

Bundle consumption order (PRO and Business): first the monthly included allowance (25 SMS / 500 mails on PRO, 75 / 2,500 on Business), then the prepaid bundle balance. Once both are exhausted the API returns HTTP 429 and Hive falls back to local wp_mail() for mail (or hard-caps SMS) — other 2FA methods stay operational. Bundle credits never expire. Stripe uses tax_behavior = inclusive for the gross-priced bundles (PAngV compliant); Reverse Charge / OSS is handled automatically by Stripe Tax.

5-Layer Defence

Hive applies its checks in order — each layer can short-circuit the request before it reaches the next. Hooked on init at priority 1 so that other plugins do not run for a blocked IP.

1. Whitelist — trusted IPs and CIDR ranges are always allowed (your office, monitoring services, …).
2. Local block list — IPs you have blocked manually, or that exceeded local thresholds. Stored in wp_reportedip_hive_blocked.
3. Attempt counters — login, comment, XMLRPC, REST-burst and 404-scan counters trigger an automatic block once the threshold is reached.
4. Community reputation — in Community Network mode, IPs with confidence ≥ threshold are blocked at the edge.
5. 2FA challenge — protected accounts must complete a second factor to log in.

The Thirteen Attack Sensors

Every sensor can be toggled and tuned independently in Settings → Protection.

Progressive Block Escalation

Repeat offenders pay more. The default ladder is 5 min → 15 min → 30 min → 24 h → 48 h → 7 d. After 30 days clean the counter resets to step 1. First-time tripping legitimate visitors (CGNAT, fat-fingered admins, mobile-network egress) recover in minutes; persistent attackers reach the 7-day step.

The ladder, the reset window and the master toggle live under Settings → Blocking → Progressive blocking. The wizard's Protection step exposes the master toggle so fresh installs are escalation-aware from the first save. The fixed block_duration setting still applies when the ladder is toggled off. Sub-hour granularity is provided by ReportedIP_Hive_Database::block_ip_for_minutes().

Two-Factor Authentication (2FA)

Four methods are supported and can be combined per user. Recovery codes are generated on first setup. Secrets are encrypted at rest (libsodium with an OpenSSL fallback).

• TOTP — RFC 6238 (6 digits, 30-second window). Works with Google Authenticator, Authy, 1Password, Bitwarden, …
• Email — six-digit OTP via the configured mail provider; rate-limited (3 codes per 15 min, 5 verify attempts per code, 60 s resend cooldown).
• SMS — six-digit OTP via the managed reportedIP SMS relay (Professional plan and up; see below). Phone number is encrypted at rest.
• WebAuthn — passkeys, security keys (YubiKey), platform authenticators (Touch ID, Face ID, Windows Hello). In-house CBOR parser, no external dependency.
• Trusted devices — opt-in remember-this-device tokens with configurable expiry (default 30 days). Stored in wp_reportedip_hive_trusted_devices as SHA-256 hashes.
• Recovery codes — 10 single-use xxxx-xxxx codes; low-codes warning at ≤ 3 remaining.

2FA brute-force protection

The 2FA verifier ladder is 3 → 30 s, 5 → 5 min, 10 → 30 min, 15 → 1 h. When the count reaches the top step the IP is graduated to the central auto_block_ip() path (event 2fa_brute_force) which trips progressive escalation and Community-mode reporting like any other sensor.

Headless 2FA REST

For app integrations the plugin exposes three routes under namespace reportedip-hive/v1:

• POST /2fa/challenge — username + password → challenge token + enabled methods (20 req / 5 min per IP).
• POST /2fa/verify — token + method + code → sets the auth cookie (30 req / 5 min per IP).
• GET /2fa/methods — introspect active methods for the current user.

WooCommerce Frontend Login

Hive's frontend 2FA stays inside your active storefront theme — customers logging in through [woocommerce_my_account], the classic checkout or the WooCommerce Cart / Checkout blocks complete their second factor on a themed page. The cart and checkout state survives the redirect roundtrip, the trusted-device cookie is shared with the wp-login flow.

• Configuration path — 2FA → Frontend login for WooCommerce.
• Configurable slugs — challenge slug (default reportedip-hive-2fa) and setup slug (default reportedip-hive-2fa-setup); both editable, conflict-checked, and rewrite rules flush automatically when changed.
• Tier downgrade — soft-disable on Free and Contributor plans; settings, slug choices and onboarding state are preserved, no data loss when re-upgrading.
• Conflict detection — Hive surfaces an admin notice when Solid Security, the WP Two-Factor plugin or Wordfence 2FA owns the login form, and disables the frontend challenge to avoid double-prompts.
• Plan availability — Professional and above. The free WooCommerce login-failure sensors (woocommerce_login_failed, woocommerce_checkout_login_form_failed_login) remain on every plan and continue to feed the brute-force counter.

Mail and SMS Delivery

The mail layer runs through a pluggable provider contract (ReportedIP_Hive_Mailer). The default provider is WordPress wp_mail(); integrators can swap in their own without touching the rest of the plugin. SMS 2FA is a Professional feature delivered exclusively through the managed reportedip.de relay — no own SMS account or carrier contract required. It is configured automatically with a paid plan; enable it under Settings → 2FA → SMS.

Configuration Overview

All settings live under ReportedIP Hive → Settings. The most important defaults:

Database Tables

Created on activation, prefixed wp_reportedip_hive_. Schema version 3, with idempotent migration on every plugin update.

• logs — security events, JSON details, severity, reported-flag.
• whitelist — trusted IPs and CIDR ranges; expiry optional.
• blocked — active blocks (manual / automatic / reputation), with blocked_until.
• attempts — per-IP counters per attempt type, with first/last timestamps.
• api_queue — pending and failed reports to the community API; retry logic.
• stats — daily aggregates for the dashboard charts (7- and 30-day trends).
• trusted_devices — 2FA device tokens (SHA-256 hashes), IP and device name, expiry.

Frontend Shortcodes & Auto-Footer

Embed a small "protected by Hive" badge anywhere on the site. All shortcodes render a single <rip-hive-banner> web component and pull live numbers from a 6-hour transient cache (no API call per page view).

• [reportedip_badge] — small badge (default protect tone).
• [reportedip_stat] — single statistic (default trust tone).
• [reportedip_banner] — wide banner (default community tone).
• [reportedip_shield] — shield icon (default contributor tone).

Common attributes: stat (e.g. attacks_30d, reports_total), tone (protect / trust / community / contributor), color, background, label, intro. The auto-footer in the wizard uses the same component with a configurable variant and alignment.

WP-CLI Reference

The 2FA tooling is fully scriptable. Available under wp reportedip 2fa …:

wp reportedip 2fa status [--user=<id>]
wp reportedip 2fa enable <user_id> --method=<totp|email|sms|webauthn> [--secret=<base32>]
wp reportedip 2fa disable <user_id> [--method=<m>]
wp reportedip 2fa reset <user_id>
wp reportedip 2fa enforce --role=<role> [--remove]
wp reportedip 2fa audit [--user=<id>] [--since=<date>]
wp reportedip 2fa cleanup

Cache-Plugin Compatibility

Since 1.5.2 the blocked-page response defines DONOTCACHEPAGE, DONOTCACHEDB and DONOTCACHEOBJECT (respected by WP Rocket, W3 Total Cache, WP Super Cache and LiteSpeed Cache) and emits explicit Cache-Control: no-store, no-cache, must-revalidate, max-age=0, Pragma: no-cache plus the WordPress core nocache_headers() set. A single blocked attacker can no longer pollute the page cache with a 403 that legitimate visitors would otherwise receive until the cache expires.

Filters and Action Hooks

• apply_filters('reportedip_hive_external_url', $url, $context) — replace any of the external URLs (privacy policy, registration, FAQ, …).
• apply_filters('reportedip_hive_rest_bypass_routes', $routes) — extend the list of REST-route prefixes that bypass the burst monitor (cookie-banner integrations).
• apply_filters('reportedip_hive_scan_paths', $paths) — extend the honeypot path list for the scan detector.
• do_action('reportedip_hive_ip_blocked', $ip, $reason) — fired when an IP is blocked.
• do_action('reportedip_hive_report_queued', $ip, $category) — fired when a report is enqueued for the API.

Frequently Asked Questions

The questions we get most often. Each answer links back to the relevant section above where appropriate.

General

Installation & Setup

Modes & Sensors

2FA

Performance & Compatibility

Privacy & GDPR

Customisation & Extension

add_filter('reportedip_hive_rest_bypass_routes', function ($routes) {
    $routes[] = '/my-consent-plugin/v1';
    return $routes;
});

add_filter('reportedip_hive_scan_paths', function ($paths) {
    $paths[] = '/.aws/credentials';
    return $paths;
});

Quotas, Plans & Account

Troubleshooting

Plugin does not block any IPs

Check whether Report-Only Mode is enabled — it logs threats without blocking. Also verify that the block threshold is not set too high (default 75 %) and that Auto-blocking is on (the duration strategy is disabled while auto-blocking is off).

API connection errors in Community Network mode

Ensure your server can make outbound HTTPS requests to reportedip.de. Some hosts block outgoing connections by default. Verify the API key on the Dashboard.

Cookie-banner visitors get blocked

Since 1.5.0 the four common consent namespaces (real-cookie-banner, complianz, borlabs-cookie, cookie-law-info) are bypassed by default. If your stack uses a different namespace, extend the bypass list via the reportedip_hive_rest_bypass_routes filter.

Legitimate users get blocked

Add their IP addresses or CIDR ranges to the local whitelist. Whitelisted IPs are never blocked, regardless of reputation.

High API usage / running out of checks

Responses are cached locally (with ETag) for 24 hours by default. If you are still running out of checks, increase cache_duration or upgrade your plan. Monitor the queue and quota on the Dashboard.

Locked out by 2FA

Use one of the recovery codes saved during 2FA setup. If those are lost, an administrator can reset 2FA for any user under Users → Two-Factor. As a last resort: wp reportedip 2fa reset <user_id>.

The block editor (Gutenberg) keeps getting throttled

The block editor fires 50+ REST calls in a few seconds. Since 1.2.2 logged-in users skip the global REST-burst monitor; only anonymous bursts count. Make sure you are running 1.2.2 or newer.

GDPR & Privacy

The plugin is designed with privacy in mind and is fully GDPR compliant.

• Local Shield mode: No data leaves your server. All detection and blocking happens locally.
• Community Network mode: Only attacker IP, threat category and timestamp are shared. No usernames, no passwords, no comment content, no end-user data.
• User-agents are truncated to 50 characters before storage.
• Automatic cleanup: Security logs are deleted after the configured retention period (default 30 days). Auto-anonymisation kicks in earlier (default 7 days).
• Encryption at rest: TOTP secrets, WebAuthn credentials and SMS phone numbers are encrypted with libsodium (OpenSSL fallback).
• No tracking: No cookies, no tracking pixels, no telemetry.
• Open source: The full source code is published on GitHub — every line is auditable.

Changelog Highlights

• 2.0.x — Network-wide multisite activation (Network: true), per-blog tier management, tier-upgrade banners, app-password & geo-anomaly monitors hardened, WooCommerce frontend 2FA opens to PRO+.
• 1.5.2 — Cache-plugin compatibility on the 403 page; 2FA throttle graduates to real escalation block; init priority 1.
• 1.5.1 — Blocking-tab clarity (Report-only > Auto-blocking > duration strategy); fixed-length and ladder editors swap inline.
• 1.5.0 — Progressive block escalation (5 m → 7 d ladder); cookie-banner endpoints bypassed by default; 404/comment-spam defaults relaxed.
• 1.2.4 — API-queue "Retry" button now actually fires the API call.
• 1.2.0 — Seven new sensors: app-password monitor, REST-burst monitor, user-enumeration block, 404/scan detector, geo-anomaly, password strength, hide-login URL.
• 1.1.0 — Central mailer with brand template.
• 1.0.0 — Initial public release: IP blocking, 4-method 2FA, setup wizard, list tables.

Full history: CHANGELOG.md on GitHub.

Looking for the smaller edition?