Paid beta access
01HoneyMesh Core Beta
Local Linux defense for a measured, noncritical beta evaluation.
Loading HoneyMesh...
Loading HoneyMesh...
HoneyMesh is built for Linux hosts facing the internet: detect hostile sources, enforce local XDP blocks, and coordinate signed ban signals with peers you trust. Each host keeps authority over its own rules.
HoneyMesh
Network Decode security stack
From one host to a trusted mesh
Detect
Correlate local traps and host events
Defend
Apply a scoped ingress block with XDP
Share
Send a signed ban to trusted peers
Recover
Expire or release each owned grant
Measured sharing, limited release.
A three-node lab measured an operator-issued ban reaching trusted peers while a control source stayed open. Peer sharing remains a private pilot; paid host downloads are closed. Read the evidence.
Technical review
01 / Placement
Understand where Node Guard, the host agent and XDP run.
Architecture02 / Control
Review authority, local data handling, signatures and rollback.
Security model03 / Evidence
Compare each observed result with its test method and limit.
Validation04 / Pilot
Run a noncritical TEST-first evaluation with explicit stop rules.
Operator workflowAvailable paths and release status
Node Guard Free runs inside a Node.js application. Paid host products use a separate signed agent and current customer delivery remains gated. Each product page states its scope and status.
Paid beta access
01Local Linux defense for a measured, noncritical beta evaluation.
Free alpha
02Free, local observation and short-duration limits for Node.js services.
Standalone beta
03A local Linux Firewall Beta with scoped XDP ingress controls. Standalone access is $5 per Linux node per month.
Paid beta pilot
04Node.js application evidence connected to a local Linux agent.
Paid beta pilot
05Five-host block access to local HoneyMesh Core protection.
Selective protection
HoneyMesh applies a source-IP ban at the protected interface. In the three-node AMD64 test, the banned source stopped receiving replies while a separate control source continued to reach the same services.
Banned test source
10.77.0.4
No reply from the protected hosts
Five tested IPv4 traffic cases on each of three nodes
Unbanned control source
10.77.0.5
Still reached the same listeners
All five cases remained reachable on all three nodes
Measured with a manual ban in HoneyMesh 2.3.6-rc2. Service uptime and automatic detection accuracy were not measured.
Inspect the testTwo paths to defense
Both paths end with a local enforcement decision. With Pro and explicit trust, that decision can reach other protected hosts.
01 / HoneyMesh identifies activity
Detection paths are implemented in HoneyMesh. The federation PoC did not measure detection accuracy or false positives.
02 / Operator responds
This is the path measured in the HoneyMesh 2.3.6-rc2 three-node AMD64 proof of concept.
Measured in a three-node lab
In the 2.3.6-rc2 test, node A issued a ban, nodes B and C accepted it as a remote mesh ban, and the banned source received no reply across five tested IPv4 TCP, UDP, and ICMP cases on each node. This measured propagation and enforcement in an isolated lab, not automatic detection or production throughput.
3
AMD64 hosts
5
traffic cases
1
control source
Simulated mesh defense demo
This browser animation illustrates one possible automatic-detection path. Its events are simulated; the measured three-node proof covers an operator-issued ban.
Live console
One source was banned. Unbanned clients can still connect.
Mesh mode illustrates a signed decision reaching trusted peers while the unbanned control remains reachable.
Active peer
DNS
Watching exposed services
Mesh status
Global enforcement
0
threat
0
nodes
Unbanned traffic
Control client remains in the simulation
This is simulated. The separate three-node PoC measured control-source reachability.
Stop defending one server at a time.
Attack timeline
The goal is to interrupt unwanted traffic from an identified source while the service remains reachable to unbanned sources. The extent of protection depends on detection, policy, trust, and which interfaces are protected.
01 / Reconnaissance
Traps and scan correlation can surface probing for review.
Detection quality needs its own test.
02 / Initial access attempt
A ban can stop packets from an identified IP at a protected host interface.
Coverage follows the selected interfaces and source IP.
03 / Reuse against peer hosts
Trusted peers can receive the signed ban and enforce locally.
The manual-ban path was lab-tested on three AMD64 nodes.
04 / Later intrusion stages
The blocked IP may lose a route to a protected host.
Lateral movement, command traffic, and exfiltration were not tested.
Stage names follow MITRE ATT&CK Enterprise. This is a mechanism map, not a claim of validated coverage for every tactic.
Inspect activity, choose where XDP attaches, review bans, and decide which peers may influence local enforcement.
Deploy controlled decoy coverage across exposed infrastructure.
Expand visibility across internet-facing environments without depending on a central choke point.
Adapt coverage by site, environment, and operational need.
Support branch, cloud, edge, and disconnected deployments.
Keep the product focused on observation and protection, not production workload disruption.
A practical evaluation path
Security teams can install Node Guard Free, review measured host tests, and buy a signed Firewall Beta, Node Pro, or Infrastructure Pro archive for bounded noncritical evaluation.
• Read the technical proof and its limits
• Verify npm integrity for Node Guard Free
• Start in observe mode on a noncritical service
• Verify the plan-matched host archive and its recovery guide
View product paths