Portspoof: Emulate a valid service on all 65535 TCP ports

Portspoof is a tool that makes all 65,535 TCP ports appear to run plausible services by redirecting traffic to a single user‑space process, aiming to confuse port scanners and waste attackers’ time. Commenters debate whether this is worthwhile “security through obscurity,” noting it may be useful against broad, automated scans but offers little protection if a real vulnerable service is exposed, and it also introduces its own attack surface and bandwidth overhead. Others explore related ideas like tarpits, honeypots, port knocking, and active defense, while raising practical concerns about deployment, licensing under GPLv2, and operational side effects such as noisy security scans and false positives.

How Portspoof Works

  • Listens on a single TCP port and uses iptables NAT redirection so all unbound ports (1–65535) are forwarded to it.
  • Uses getsockopt to recover the originally requested destination port and returns protocol-appropriate fake banners/responses.
  • Intention: make every port appear to run a plausible service, slowing or confusing service/version detection.

Comparison to Tarpits and Honeypots

  • Tarpit: keeps connections half-open or very slow, tying up attackers’ resources but risking local conntrack exhaustion if misconfigured.
  • Portspoof: responds quickly and closes connections, using fewer resources than a tarpit but more than simply ignoring traffic.
  • Several commenters frame it as honeypot infrastructure: fake services, logging, and possible integration with exploit frameworks to attack scanners.
  • Others warn that too many open ports can itself signal “honeypot” to more sophisticated attackers.

Security Value and Threat Models

  • Supporters: raises attacker cost and time, especially for broad “spray-and-pray” scans; good as an extra “security-through-obscurity” layer.
  • Critics: if a real vulnerable service is exposed, Portspoof does not prevent exploitation; many attackers only scan specific known ports.
  • Debate on “security through obscurity”: some say it’s acceptable as one layer (like port knocking, ASLR, or delay after bad passwords); others think it mainly attracts more traffic and scrutiny.
  • Concern that it may generate bandwidth overhead (e.g., 200MB for full nmap -sV scan) and increase bug-bounty noise and false positives.

Implementation, Risks, and Variants

  • Uses iptables REDIRECT for all TCP ports to a single listening port; seen as a neat, simple design.
  • Risk: Portspoof itself becomes a large attack surface if it parses complex inputs; suggested to run it sandboxed, in DMZ/VM, or as part of honeypot research.
  • Some suggest combining with port knocking or only emulating a subset of ports/IPs to appear more realistic.
  • Ideas to integrate with SIEM for alerts when non-existent services are probed.

Licensing and Ecosystem Discussion

  • Project is GPLv2 but also asks commercial users to “contact the author,” leading to discussion of dual licensing and GPL commercialization.
  • Commenters note GPL already permits commercial use; author likely aims to sell proprietary licenses/exceptions.
  • Related mentions: older honeypot products, tarpits like Endlessh, and analogous “noise” ideas (e.g., infinite fake email lists, HTTP endpoints that always return 200).