Creating honeypots using Docker | Hacker News Reader

Creating honeypots using Docker

itinsight.hu

34 pointsmistaken8 comments

This is a bad idea. Concerns about Docker's security (or lack thereof) aside, containers provide "good enough" separation of concerns to apps. They are not security hardened and designed to be exposed to vulnerabilities, particularly when by design a honeypot is to tempt attacks (automated or otherwise).

A virtual machine (or better) is better suited to this task.

So why not one virtual machine hosting multiple containers?

Why not several virtual machines? There are more choices and more mature software for managing thousands of virtual machines, configurations and images, than there is for docker.

Also, the memory footprint of several virtual machines isnt that bigger compared to docker - because of KMS and such.

Pardon my ignorance, but I thought the whole point of containers could be summarized as sacrificing security for performance. Wrapping containers in a single VM to restore security seems like a reasonable compromise.

I would be interested in learning more about the differences in management software availability as well as how KMS (KSM?) reduces the performance penalty of using virtual machines.

> point of containers could be summarized as sacrificing security for performance

No.

Containers are and can be secure, perhaps even more so than QEMU/KVM Id argue, see latest lxc - you can run it without root and with seccomp syscall whitelist (if not in lxc that feature is in firejail, or a simple .c to setup yourself).

Its only docker that is fundamentally insecure. First it runs a server as root, second it has a server-client architecture with quite complicated communication between them. Then it also has an API and talks to various indexes/registries, also vector of attack.

With say firejail, its only one process, no server-client, no registries, the whole thing is in a few hundred lines of C.

The performance penalty - is somewhat bigger memory usage - and startup time, thats it, with hardware accelerated virtualization which most computers have these days, the performance impact once the VM is up and running, is negligble.

There is a glaring omission from the possible attacks: the kernel itself provides a huge surface area and local root exploits are not uncommon.

Speaking as an infrastructure/devops/hosting consultant - I've done a couple of Docker deployments lately and clients often ask whether it's suitable for hosting multiple semi-trusted codebases on the same metal for better resource utilization. I tell them "no": once a competent attacker has shell they will not find it hard to escape the sandbox and take over the parent machine, and with it all other hosts. Docker is a great tool for rapid deployment, dependency management and dense hosting of microservices but security was never the primary goal.

Hypervisor based virtualization solutions (e.g. Xen, VMWare) expose a much smaller attack surface to the child environment. I would therefore say that while more resource intensive they are a far safer way to spin up honeypots.

I'd say spin up the VMs on a machine that doesn't matter if you're attracting automated attacks.

If you wake up one morning to an exploit being discovered and have an unpatched host machine, is it still a honeypot?

Given the recent news about breaking out of Docker containers, this would be best wrapped in a VM. You'll get the performance boost of not spinning up separate VMs coupled with greater security from breaking out of a VM.

Reply on news.ycombinator.com