Haven't looked into this too deeply but there is a difference between delaying a response (requests get stuck in the tarpit) vs providing a useless but valid response. This approach always provides a response, so it uses more resources than ignoring the request, but less resources than keeping the connection open. Once the response is sent the connection can be closed, which isn't quite how a tarpit behaves. The Linux kernel only needs to track open requests in memory so if connections are closed, they can be removed from the kernel and thus use no more resources than a standard service listening on a port.

There is a small risk in that the service replies to requests on the port, though, as replies get more complicated to mimic services, you run the risk of an attacked exploiting the system making the replies. Another way of putting it, this attempts to run a server that responds to incoming requests on every port, in a way that mimics what might run on each port. If so, it technically opens up an attack surface on every port because an attacker can feed it requests but the trade-off is that it runs in user mode and could be granted nil permissions or put on a honeypot machine that is disconnected from anything useful and heavily tripwired for unusual activity. And the approach of hardcoding a response to each port to make it appear open is itself a very simple activity, so the attack surface introduced is minimal while the utility of port scanning is greatly reduced. The more you fake out the scanning by behaving realistically to inputs, the greater the attack surface to exploit, though.

And port scanning can trigger false postives in network security scans which can then lead to having to explain why the servers are configured this way and that some ports that should always be closed due to vulnerability are open but not processing requests, so they can be ignored, etc.

The original Labrea Tarpit avoids DOS'ing it's own conntrack table somehow, too;

LaBrea.py: https://github.com/dhoelzer/ShowMeThePackets/blob/master/Sca...

La Brea Tar Pits and museum: https://en.wikipedia.org/wiki/La_Brea_Tar_Pits

The NERDctl readme says: https://github.com/containerd/nerdctl :

> Supports rootless mode, without slirp overhead (bypass4netns)

How does that work, though? (And unfortunately podman replaced slirp4netns with pasta from psst.)

rootless-containers/bypass4netns: https://github.com/rootless-containers/bypass4netns/ :

> [Experimental] Accelerates slirp4netns using SECCOMP_IOCTL_NOTIF_ADDFD. As fast as `--net=host`

Which is good, because --net=host with rootless containers is security inadvisable FWIU.

"bypass4netns: Accelerating TCP/IP Communications in Rootless Containers" (2023) https://arxiv.org/abs/2402.00365 :

> bypass4netns uses sockets allocated on the host. It switches sockets in containers to the host's sockets by intercepting syscalls and injecting the file descriptors using Seccomp. Our method with Seccomp can handle statically linked applications that previous works could not handle. Also, we propose high-performance rootless multi-node communication. We confirmed that rootless containers with bypass4netns achieve more than 30x faster throughput than rootless containers without it

RunCVM, Kata containers, GVisor all have a better host/guest boundary than rootful or rootless containers; which is probably better for honeypot research on a different subnet.

IIRC there are various utilities for monitoring and diffing VMs, for honeypot research.

There could be a list of expected syscalls. If the simulated workload can be exhaustively enumerated, the expected syscalls are known ahead of time and so anomaly detection should be easier.

"Oh, like Ghostbusters."

I tried something like that. It didn't work because the application added the socket to an epoll set before binding it, so before it could be replaced with a host socket. Replacing the file descriptor in the FD table doesn't replace it in epoll sets.