PressHaven Knowledge Hub
A defensive security platform built around a WordPress + WooCommerce shop as its target demo application — today a high-interaction honeypot, growing into a security management layer above WordPress + WooCommerce instances. It scores every request in real time and quietly diverts suspicious sessions into isolated honeypot clones. Real customers never notice; adversaries get a convincing storefront while every move is recorded.
Defensive only. The entire system observes, diverts and records on its own infrastructure. It deliberately performs no offensive tracking and no offensive security — no beacons or hack-back, no reaching out to adversary machines, no retaliation. Deception is used solely to protect the real store, never to strike back.
Overview
Overview
Operations landing page: current risk score, both stacks' health, and a live feed of notable security events.
A real storefront that quietly becomes a trap.
The target demo application is a full WordPress + WooCommerce storefront — a coffee eshop with real products and carts — and both honeypot layers are built for and around it. In front of it sits an OpenResty reverse proxy that scores every non-static request in Lua: URI and header patterns, seeded WordPress and WooCommerce CVE signatures, request rate, session history, network IDS alerts and IP reputation.
Legitimate traffic continues to production. Once a session crosses the threshold it is bound to its own honeypot pool — a complete clone of the WooCommerce shop — and stays there. Carts follow the session, so the diversion is invisible and nothing about normal browsing changes.
- Session-bound, not IP-bound. A signed cookie plus passive fingerprint recovery keeps the experience stable.
- Elastic pools. One isolated shop and database per session, cloned from a pre-built template and recycled when idle.
- Full telemetry. Security events and Suricata alerts flow through Vector into Elasticsearch and Kibana.
Everything, one layer at a time.
Start at the beginning or jump straight into the layer you care about. Every page is written against the actual Lua modules and deployment files in the repository.
Detection
URI and header patterns, CVE signatures, Suricata alerts, IP reputation, escalation-aware decay and a consent-gated device signature — every score explained.
13 CVEs · WSTG mapped Open 3 pagesObservability
Structured security events shipped over mTLS by Vector into Elasticsearch, with six operational Kibana dashboards and an embedded request timeline.
6 dashboards Open 5 pagesOperations
Two-host and single-host topologies, production hardening, configuration reference and troubleshooting runbooks.
2 topologies Open Deep diveArchitecture
The pure/adapter split, the twelve-stage routing decision, elastic honeypot pools and the GDPR identity path.
Full reference Open 2 pagesTesting
Twenty-three pure-Lua unit test suites, dashboard validation and the blind penetration-test protocol.
23 test files Open 6 pagesReference
Glossary, known issues and workarounds, roadmap, changelog, primary literature and module tables.
Glossary · roadmap OpenOne decision pipeline, two deployment shapes.
All detection logic lives in pure *_rules.lua modules with zero ngx.* dependencies. Thin adapters perform I/O, which keeps the rules unit-testable under a plain Lua interpreter and the edge behaviour deterministic.
Request pipeline
Client Request → Nginx access_by_lua_block
→ pattern_analyzer.analyze_request()
→ router.decide_route() (12 stages)
→ pool_router.get_or_assign_pool()
→ session_handler.update_session() → Redis
→ WordPress backend: production or honeypot
→ Suricata eve.json → init_worker.lua
→ threat_intel shared dict
→ abuseipdb_client.report_ip_async()- Pure / adapter split. Decisions live in rules modules; adapters talk to Redis, Nginx and AbuseIPDB.
- Graceful degradation. If Redis or a pool is unavailable, the router falls back instead of dropping customer traffic.
- Two hosts, one flow. The edge can ship telemetry to a separate SIEM host over mTLS, outbound only.
Reverse proxy and Lua scoring, production WordPress, elastic honeypot pools, Redis session state, Suricata, and a local Vector shipper. This is the only host that sees plaintext client requests.
Vector aggregator, Elasticsearch and Kibana. Logs arrive over an outbound-only mTLS channel, so the SIEM never needs to initiate a connection into the edge network.
Layered signals, one readable score.
Detection is not a single regex. Each request passes through headers, URI patterns, seeded CVE signatures, rate and reputation checks, automation detection and session history. A signal can add a fixed score, contribute a severity-derived delta, or trigger a hard routing rule.
Pools that scale with people, not noise.
Assignment is per session and atomic in Redis. A spare pool is kept ready, another is provisioned as soon as a session has to borrow one, and idle pools are recycled after thirty minutes. Resource budgets stop growth before the host runs short.
- Exclusive by default. A session gets its own shop and database pair; the mapping is stored with a 24-hour TTL.
- Spare provisioning. Every assignment queues a wake-up, so the next visitor usually finds a warm pool.
- Bounded growth.
POOL_MAX, memory, CPU, load and disk guards cap the fleet; beyond that sessions share pools round-robin. - Scale down. Idle pools above the spare count are removed and their users reassigned on return.
- Content sync. Production pages, posts and products are mirrored into every pool every five minutes by default.
What works, and what still does not.
The project documents its own limits. These are the trade-offs recorded in the manuals, not marketing footnotes.
- Multi-layered detection with WSTG mappings
- Explainable, auditable risk scoring
- Per-adversary isolation via elastic pools
- No tarpit — identical proxy latency
- Privacy-preserving GDPR identity
- Honeytoken injection for high-confidence signals
- Pure / adapter split with 23 unit test files
- Severity-graded Suricata integration
- Same-host Suricata testing gap
- Decay system has four tuning parameters
- Honeytoken coverage is limited to five types
- Rule-based only — no machine learning
- Redis is a single point of failure
- Pool scaling is bounded by host resources
- No end-to-end integration test suite
- Dashboard state can drift from live Kibana
Go from zero to a diverted attack.
Follow the setup path, then read the module that made the decision. Every page links back to the exact Lua file or deployment script it describes.