SECURITY MODULE — FOUNDATION
WordPress Security Core — Audit Logging, IP Blocking, and Spam Registration Defense
The shared security foundation that powers every LuperIQ security module. Provides centralized audit logging, proxy-aware IP detection, permanent and temporary IP blocking with .htaccess enforcement, registration rate limiting, and spam signup pattern matching — all running silently in the background with zero admin pages to configure.
Why WordPress Sites Need a Security Foundation Layer
Most WordPress security plugins operate as monolithic tools — one massive plugin trying to handle everything from firewalls to malware scanning to login protection. When something breaks or conflicts with your theme, you lose all security at once. And when you need to add a specialized capability like automated threat response or infrastructure-level ops controls, the monolithic plugin either does not support it or locks it behind its own premium tier.
LuperIQ Security Core takes a different approach. It is a backend-only foundation module that provides the shared database layer, audit logging, IP utilities, and registration guards that every other LuperIQ security module depends on. It has no admin pages and no configuration screens. It activates, creates its database tables, hooks into WordPress registration and request lifecycle events, and starts protecting your site immediately. Security Monitor and Security Ops build on top of it to provide dashboards, threat intelligence, automated responses, and infrastructure controls.
What Security Core Provides
Centralized Audit Logging
Every Security Event Recorded
Every security-relevant action is written to a dedicated audit table with the user ID, action identifier, JSON context, exit code, request fingerprint, duration in milliseconds, IP address, user agent, and timestamp. Events are also streamed to Data Core (ClickHouse) when available for long-term analytics.nProxy-Aware IP Detection
The Database Layer — Five Dedicated Tables
Security Core creates and manages five database tables using WordPress dbDelta with version tracking. The schema is created on the init hook (not admin_init) so that frontend audit writes work correctly from the first request. If you deactivate and reactivate the module, the version check prevents redundant schema operations.
Security Audit Table
luperiq_security_audit
Stores audit log entries with user ID, action, JSON context, exit code, fingerprint, duration, IP, user agent, and timestamp. Indexed on user ID, action, and creation date for fast lookups.nSecurity Events Table
How IP Blocking Works — Two Layers of Defense
When an IP is permanently blocked, Security Core writes the block to two places simultaneously. First, the IP reputation table in the database is updated with blocked=1 and blocked_until=NULL (indicating an indefinite block). Second, a Require not ip directive is added to your .htaccess file inside a clearly marked section. This means permanently blocked IPs are rejected by Apache before PHP even starts, saving server resources.
Temporary blocks are database-only. The IP is marked as blocked with an expiry timestamp (for example, 1 hour from now). On every incoming request, the IpBlocker enforce method runs at init priority 0 — the very first hook — and checks the visitor IP against the reputation table. If the IP is blocked and the expiry has not passed, the request is terminated with HTTP 403 and an X-Blocked-By header. If the block has expired, it is automatically cleared and the request proceeds normally. When an IP is unblocked (either manually or by expiry), the database flag is cleared and the .htaccess entry is removed.
Who Security Core Is Built For
Security Core is a dependency module. You do not install it on its own for its admin interface — it has none. You install it because the security modules you want (Security Monitor and Security Ops) require it as their foundation.
WooCommerce Store Owners
- Spam registration blocking runs automatically on both WordPress and WooCommerce customer creation hooks. No configuration needed.nBurst rate limiting prevents bot-driven mass account creation that pollutes your customer database.nAudit logging tracks every security event tied to your store, giving Security Monitor and Security Ops the data they need to detect and respond to threats.
Membership and Community Sites
- SignupGuard catches the most common spam registration campaigns (BINANCE scams, bonus phishing, blogspot spam) before fake accounts are created.nPost-registration validation immediately deletes spam accounts that bypass pre-registration checks, suppressing welcome emails before deletion.nIP reputation tracking builds a history of every address that interacts with your security layer, making it easy for Security Monitor to identify repeat offenders.
Sites Behind Cloudflare or Load Balancers
- IpDetector correctly resolves client IPs behind Cloudflare (CF-Connecting-IP), reverse proxies (X-Forwarded-For, X-Real-IP), and custom proxy setups.nTrusted proxy configuration prevents IP spoofing — proxy headers are only read when REMOTE_ADDR is a known proxy address.nCIDR range matching supports both exact IP and subnet notation for whitelist and blocklist operations.
Data Core Integration — Security Analytics at Scale
When the Data Core module is active, every audit log entry is automatically streamed to the logs.security pipeline. Events are published with the action type, user ID, IP address, user agent, context details, exit code, fingerprint, duration, and a computed severity level (debug for codes below 200, info for 200-399, warn for 400 and above). This means your security data flows into ClickHouse alongside your other analytics data for long-term retention and fast querying.
If Data Core is not active, Security Core still functions completely — all data is stored in the local MySQL tables. The Data Core integration is opportunistic, not required. The module also registers the security_cache dictionary namespace and a logs_security pipeline serializer with a 90-day TTL for automatic data lifecycle management.
Automatic Maintenance — Daily Cleanup Cron
Security Core schedules a daily WordPress cron event (luperiq_security_core_maintenance) that cleans old data automatically. Security events older than 90 days and resolved alerts older than 30 days are purged. This prevents your security tables from growing unbounded over time. The cron is properly unscheduled on module deactivation so no orphan scheduled events remain.
The SecurityRepository handles cleanup with prepared SQL statements, logging the number of deleted events and alerts to the error log so you have a record of each maintenance run. If you need different retention periods, the cleanup method accepts custom day values — other modules can call it with their own thresholds.
How Security Core Connects to Other Modules
Security Core is a dependency for two modules. Security Monitor adds real-time login monitoring, file integrity checking, threat intelligence feeds, and an automated response engine. It reads events from Security Core tables, creates alerts, and uses IpBlocker to block IPs when threat thresholds are exceeded. Security Ops adds privileged operations management, backup and restore controls, and an audit log viewer that reads directly from the Security Core audit table. Both modules list security_core as a required dependency in their module.json.
Every service in Security Core uses class_exists() guards before referencing sibling classes. AuditLog checks for IpDetector before resolving IPs. BurstGuard checks for Config before reading thresholds. Bootstrap checks for each service class before initializing it. This means Security Core degrades gracefully if any individual component fails to load, and other modules can safely check for Security Core classes before calling them.
Related Security Modules
Security Monitor
Real-time threat detection and automated response.
Explore the full feature set and integration details.
Frequently Asked Questions
Does Security Core have an admin page or dashboard?
No. Security Core is a backend-only module with no admin pages. It provides the database layer, audit logging, IP utilities, and registration guards that Security Monitor and Security Ops use to build their admin interfaces. You interact with Security Core data through those modules.nDo I need to configure anything after activating Security Core? | No configuration is required. The module creates its database tables automatically on activation, hooks into WordPress registration events, and starts enforcing IP blocks immediately. Default settings (3 registrations per 60 seconds for burst limiting, 13 spam patterns for signup blocking) work well for most sites. Settings can be adjusted via WordPress options, filters, or environment variables if needed.nWill this block legitimate customer registrations? | The spam pattern matching targets specific, well-known spam campaigns (BINANCE scams, bonus phishing, blogspot spam) with precise regex patterns. Legitimate usernames do not match these patterns. The burst rate limiter allows 3 registrations per IP per minute by default, which is more than enough for real users. Both thresholds are configurable.nDoes this work with WooCommerce customer registrations? | Yes. SignupGuard hooks into both standard WordPress registration (registration_errors and user_register) and WooCommerce customer creation (woocommerce_created_customer). Spam accounts are caught and deleted regardless of which registration path created them.nWhat happens if I deactivate Security Core while Security Monitor is active? | Security Monitor and Security Ops list security_core as a dependency. The module system prevents activation of dependent modules when their dependencies are not active. If you deactivate Security Core, dependent modules will also need to be deactivated. The database tables and their data are preserved — reactivating Security Core restores full functionality.nHow does IP detection work behind Cloudflare? | IpDetector checks the CF-Connecting-IP header first, which Cloudflare sets to the real client IP on every proxied request. It only reads this header when REMOTE_ADDR is a private or trusted proxy IP, preventing attackers from spoofing the header on direct connections. The trusted proxy list is configurable via the luperiq_security_trusted_proxies option.nCan I use Security Core without Data Core? | Yes. Data Core integration is optional. When Data Core is active, audit events are streamed to ClickHouse for long-term analytics. When it is not active, all data stays in the local MySQL tables and the module functions identically. You will see a debug log message noting that Data Core is unavailable, but this is informational only.
Build Your WordPress Security Stack on a Solid Foundation
Security Core provides the audit logging, IP blocking, and registration defense that Security Monitor and Security Ops build on. Activate it once and every security module benefits.
