Tuesday, September 29, 2026

Turning Linux servers into deceptive attack surfaces with phantom-grid

Turning Linux servers into deceptive attack surfaces with phantom-grid

phantom-grid is an eBPF-based Zero Trust Network Access and active defense system that cloaks services in the kernel and grants access via SPA and mTLS for authorized defenders.

Toolhaidang-infosec/phantom-grid — eBPF-powered ZTNA and active defense system for Linux servers
CategoryeBPF host defense / deception / Zero Trust network access
Primary UseCloaking critical ports like SSH via XDP, authorizing access with SPA keys and mTLS certificates, and capturing attacker telemetry in honeypots during authorized defense operations
Safe UseDeploy on servers and labs you own or administer; it is a defensive hardening and deception platform for blue teams, not an attack tool
Telemetry NoteFor defenders, the tool itself is a telemetry source: attack logs and agent states persist to SQLite and stream to Elasticsearch; eBPF programs appear in kernel verifier logs and load via libbpf1

phantom-grid is an interesting entry in the crowded Linux hardening space because it refuses the usual trade-off between visibility and accessibility. Written in Go around an eBPF core, it positions itself as both a Zero Trust Network Access (ZTNA) gateway and an active deception layer: critical services such as SSH, databases, and management interfaces are made invisible to scanners, while authorized users still reach them through cryptographic authorization. The README frames the goal as shrinking the observable attack surface of infrastructure without inconveniencing legitimate operators, which is the classic promise of Single Packet Authorization done at kernel speed.

The architectural anchor is the XDP hook. By default, packets aimed at protected ports are dropped natively in the Linux kernel before they ever reach the traditional network stack, which the author argues yields dramatically better throughput than iptables or nftables rule sets. Access is unlocked dynamically only after a valid Single Packet Authorization packet arrives, using Ed25519 signatures combined with Time-Based One-Time Passwords (TOTP). This is the fwknop lineage of designs, but executed at the driver level rather than in userspace, which is where the performance claims come from.

Layer 7 gets its own control point through an integrated mTLS proxy. The README explicitly motivates this with what it calls NAT blindspots: SPA alone authorizes an IP address, which breaks down when an attacker shares a public NAT IP with a legitimate user. The proxy therefore verifies client-side X.509 certificates before routing anything, binding identity to a cryptographic credential rather than a source address. In the stated deployment example, traffic terminated on 8443 is proxied to the real SSH service on port 22, decoupling the public entry point from the protected listener.

What makes the project more than a port-knocking replacement is the deception package bundled on top. phantom-grid simulates randomized responsive services on unused ports to pollute nmap-style reconnaissance, mutates TCP/IP header characteristics in real time to defeat OS fingerprinting, and transparently redirects hostile traffic toward restricted segments into internal honeypots for behavioral analysis. There is also an egress containment feature implementing kernel-level DLP through the Linux Traffic Control (TC) hook, watching for unauthorized outbound connections and exfiltration attempts — a sensible complement, since a compromised box that cannot phone home quietly is a far less useful foothold.

The microservices story is thought through more than most READMEs bother with. Loopback traffic on the lo interface bypasses the cloaking entirely with zero overhead, so colocated backend-to-database communication keeps working while the public port stays dark. For distributed systems, the project is moving away from IP whitelisting toward SPIFFE/SPIRE-style service identity, where backends establish short-lived certificate-bound mTLS tunnels and policy is enforced on cryptographic identities like CN=backend-api rather than addresses — a model that actually survives dynamic cloud and Kubernetes environments.

Fleet operations are handled by a Fleet Manager with an embedded SQLite database managed through GORM, persisting telemetry, attack logs, and agent state. A Key Distribution Center API automates generation of SPA keys, TOTP secrets, and mTLS certificates for new deployments, and the agent can load a high volume of public keys so individual access can be revoked quickly without touching the rest of the fleet. Structured events export natively to Elasticsearch for ELK-based monitoring, and a terminal UI provides real-time threat visualization; the roadmap adds Prometheus metrics, Grafana dashboards, RBAC, HA, and Kubernetes DaemonSet deployment.

The reliability section reads like it was written by someone who has operated eBPF in production. All eBPF programs must pass the kernel verifier before loading, which the author correctly cites as a major stability advantage over traditional kernel modules — invalid programs are rejected rather than panicking the box. The CI pipeline reportedly builds and tests against kernels 5.4 through 6.8, and nightly stress pipelines simulate DDoS conditions and heavy mTLS negotiation to catch memory leaks. Kernel upgrades are claimed not to break the security posture because programs are re-verified at runtime.

Performance numbers in the README are specific enough to evaluate: sub-0.8 microsecond XDP_PASS latency for 64-byte packets on Intel X710 NICs under kernel 6.8, and drop rates exceeding 24 Mpps per core versus a typical 2-3 Mpps ceiling for iptables. These are consistent with published XDP benchmarks generally, so the claims are plausible, but treat them as vendor-supplied until independently reproduced. Note the hardware caveat: native XDP requires supported NICs like Intel X710/E810, Mellanox ConnectX-4/5/6, or Broadcom NetXtreme; on virtual NICs (veth, virtio) the system falls back to generic SKB-mode XDP with reduced throughput.

Getting started is straightforward for a Debian-family environment: a packaged install via sudo dpkg -i build/deb_phantom-grid_1.0.0_amd64.deb followed by systemctl enable --now phantom-agent and phantom-fleet. Building from source is a standard make package after installing clang, llvm, libbpf-dev, and golang-go. Minimum requirements are modest — two cores, 1 GB of RAM, kernel 5.4+ — which means the system can be evaluated in a lab VM, albeit with generic-XDP performance. The spa-client offers a hardware-accelerated web dashboard on localhost:9090 for operators who prefer clicking over CLI.

Two cautions for anyone evaluating this seriously. First, the licensing is Open Core: the eBPF filtering and basic SPA components are MIT, but the Fleet Manager, KDC, mTLS proxy, advanced deception, and web UI fall under a commercial license — the GitHub metadata confirms NOASSERTION, consistent with a custom dual-license scheme. Second, at 73 stars this is a young project; the enterprise-heavy README promises a great deal (HA, HSM integration, CO-RE portability) that is still roadmap. For authorized defenders wanting to study modern kernel-level cloaking and deception design patterns, however, the codebase is a genuinely instructive reference regardless of production readiness.

Official project repository for haidang-infosec/phantom-grid.
Download Tool

Educational analysis for authorized security professionals. Use only in controlled, authorized environments.

Share articleFacebookXLinkedIn

Continue exploring

Browse all articles →

0 comentários:

Post a Comment

Note: Only a member of this blog may post a comment.