

Creating honeypots using Docker - mistaken
http://itinsight.hu/blog/posts/2015-05-04-creating-honeypots-using-docker.html

======
jamescun
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.

~~~
j_s
So why not one virtual machine hosting multiple containers?

~~~
antocv
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.

~~~
j_s
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.

~~~
antocv
> 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.

------
mocko
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.

~~~
task_queue
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?

------
callumjones
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.

