Loading HoneyMesh...
Loading HoneyMesh...
Live Mesh Defense
HoneyMesh lures hostile scans, brute-force attacks, and exploit attempts into controlled service traps. Gain early visibility, understand their behavior, and block them instantly at the kernel with eBPF/XDP.
This is the product model described across the operator manual, architecture notes, trusted-sharing manual, and audit report.
Local-first
The architecture docs describe HoneyMesh as decentralized. No central controller is required, and local protection continues even when outside connectivity is lost.
Detection
HoneyMesh combines high-interaction TCP and UDP traps, temporal scan correlation, JA4-first TLS fingerprinting with JA3 legacy fallback, and local event visibility.
Enforcement
HoneyMesh attaches XDP to configured interfaces, persists local bans, and supports TEST MODE, ENFORCE, and LOCKDOWN so operators can roll out deliberately.
Sharing
Trusted sharing and trusted mesh participation are separate controls. Shared signals are sanitized, signed, replay-window checked, rate limited, and gated by L0 through L3 trust.
Mesh defense demo
Watch an attack land on Athena-DNS, get classified, banned at the kernel, and pushed to trusted peers before the same attacker reaches Atlas-Storage or Hermes-Edge.
Live console
One peer was attacked. The entire mesh responded.
Mesh mode shows the value: Athena-DNS learns first, Atlas-Storage and Hermes-Edge enforce before repeat probes land.
Active peer
DNS
Watching exposed services
Mesh status
Global enforcement
0
threat
0
nodes
Stop defending one server at a time.
Community and Pro are clearly separated in the docs. Local enforcement stays on the node. Sharing and federation are explicit controls, not hidden assumptions.
Community
Community keeps HoneyMesh local-only: traps, dashboard, analytics, local enforcement, and no outside sharing or trusted mesh participation.
Pro
Pro adds premium controls, trusted sharing, trusted mesh participation, and shared defense features. Both sharing paths stay off until an operator enables them.
Operator controls
The app surfaces protection state, enforcement controls, and operator review paths clearly instead of hiding coordination behind a generic sync switch.
These are the product behaviors the current public manuals and architecture notes support: local-first defense, XDP enforcement, structured detection, and bounded sharing.
Each node protects itself without requiring a central controller.
The architecture docs describe HoneyMesh as decentralized, with protection continuing even when outside connectivity is lost.
Community mode keeps protection local-only, with no outside sharing or trusted mesh participation.
Operators can run the dashboard or the local TUI depending on the environment.
This makes the product usable in branch, cloud, edge, and disconnected deployments.
Audit-backed kernel path
The audit report says the reviewed IPv4 option evasion, scan-map race, IPv6 whitelist parity, and ringbuf pressure issues were addressed.
The current audit notes are visibility and performance tradeoffs, not kernel memory safety defects.
The audited program includes IPv6 source and destination telemetry plus bounded extension-header traversal.
The current audit reports a hardened XDP program with low-severity remaining findings focused on visibility and performance tradeoffs.
These pages now use the manuals and audit artifacts as source material, so the advice lines up with the product instead of floating above it.
Problem guide
SSH brute force traffic never really stops on an exposed server. The goal is not to make the noise disappear entirely, but to shrink the attack surface, reduce repeat abuse, and make hostile behavior obvious enough to block quickly.
A practical SSH hardening guide for exposed Linux systems, grounded in HoneyMesh deployment modes, local analytics, and kernel-level enforcement.
Problem guide
Fail2Ban still helps in a lot of environments, but it is not built for every threat pattern. If your team is buried in log noise, reacting too late, or trying to protect many internet-facing nodes, it is fair to ask whether the model still matches the problem.
A practical comparison guide for operators who have outgrown log-driven blocking and need clearer visibility with earlier enforcement.
Problem guide
An exposed Redis service is the kind of issue that turns up in scans, automation, and opportunistic abuse very quickly. The fastest useful move is containment first, then verification, then a cleaner long-term access model.
A response guide for exposed Redis services covering containment, verification, access reduction, and the visibility you need afterward.
Problem guide
Port scanning is constant on exposed infrastructure. The practical goal is not to eliminate every scan. It is to reduce exposure, spot patterns that matter, and decide when probing has crossed the line into action you want to block.
A guide to interpreting scan noise, reducing exposure, and deciding when probing should turn into a block.
If someone wants to verify how HoneyMesh is deployed, licensed, shared, and audited, the site should make that easy.
Public doc
Edition boundaries, interface controls, deployment requirements, and day-to-day operator workflow.
Public doc
Detection, enforcement, federation, licensing, and the documented system flows behind the app.
Public doc
Tenant onboarding, node registration, moderation, kill switches, and trusted sharing controls.
Public doc
Kernel-path audit notes covering remediated issues, current findings, and safety assessment.
Start where you are
That is the strongest story this site can tell because it matches the documented product model: local protection first, optional shared defense second, and operator control all the way through.
Community stays local-only. Pro adds trusted sharing and approved mesh participation, both disabled by default until an operator enables them.