I'm an intern doing research on different honeypots, and I'm planning to test a few on a VM. However, I'm on a company network and would like to have my VM as secure as possible. I've read that VMs are designed to prevent code from the guest escaping to the host, and I've read this post on network access with honeypots. I've asked a few of my co-workers, and they say it should be okay. However, I'm still feeling a bit dubious about this.

That being said, what can I do to minimize the risk of a potential attacker gaining access to the network? How can I modify my VM to be as secure as possible?


You are taking the wrong approach here. The purpose (the initial true purpose) of a honeypot as defined by Lance Spitzner was to trap someone inside of a system that seemed to be filled with enough goodies that the attacker would waste time there, giving admins enough time to prevent them from doing damage elsewhere, while studying them. The first open source version that I recall was Deception Toolkit (DTK). With that said, a honeypot was never meant to be on an isolated network.

Isolating your network will likely make your honeypot unattractive. On the same token, running it on a corporate network is dangerous. Many attackers have methods of detecting what is, and what isn't a honeypot. Thus, honeypots often trap low level opportunistic attacks. So be advised, running a honeypot on an active corporate network is a bad idea for a hobbyist. So onto your question, and some suggestions.

Isolating your VM- Depending on your host, and your guest, you would want to minimize the visibility of virtualization applications. For example, the network card (vmnet0 is a dead give away), applets, etc. Creating symmetric FW rules blocking TO your network, and FROM your network. That however, is a dead giveway. Next move? Separate VLAN isolated from even seeing your network. Downside? If you were an attacker, and saw an empty network with no connections, would you stay on the system if you originally thought it was a corporate system?

Suggestion - Download and modify "NetInVM" and place your host, and NetInVM in its own VLAN. Now you have even MORE honeypots, and a mini network generating traffic. You are on an isolated network where your switch/router/firewall controls traffic policies to disallow communication to and from your honeypot. (including ARP, BCAST, MCAST, etc) But be advised... Your honeypot needs connections from the world. If an attacker connects to, he/she too, can connect FROM. Imagine the following:

Attacker --> compromised your honeypot
Attacker --> makes outbound connection FROM your honeypot --> C&C server
Attacker --> analyzes the source of WHO connected to his honeypot
Attacker <-> (thinks) <-> "Odd says I am connecting from a Fortune 100 yet no traffic"
Attacker --> goes dark

A honeypot needs to be believable.

  • I see, thanks for the advice. We're kind of focusing on just getting information, rather than trapping attackers, but I'll see if I can get an AWS instance or something similar to work on instead. – Lang Tran May 26 '16 at 19:26

There's several ways you can do this. Few that come to mind is by either physical separation, or logical packet filtering.

  1. Your VM can be configured to listen on it's own physical network interface. Provided you have a multi homed host; you could have a VM listen on a particular network card; and it will also just send on that. You can only access your VM by console, or by RDP/SSH into that IP address.

  2. You protect your host machine from that VM using a firewall. Your VM listens on a particular virtual interface (/dev/vmnetX) which you could prevent packets from leaking. If you drop packets coming from this network to go to any address you don't want (your internal network, ...) - it would be difficult for an attacker to reach your network. Again, if your ruleset is robust.

This is of course provided that it's difficult to break out of the VM and enter the host OS.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.