3 ms·

Creating honeypots using Docker

34 points by mistaken 11y ago

jamescun 11y ago
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 11y ago
  So why not one virtual machine hosting multiple containers?
  - antocv 11y ago
    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 11y ago
      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 11y ago
        > 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 11y ago
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 11y ago
  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 11y ago
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.

34 points by mistaken 11y ago

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 11y ago
So why not one virtual machine hosting multiple containers?
- antocv 11y ago
  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 11y ago
    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 11y ago
      > 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 11y ago

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 11y ago
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 11y ago

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.