Monday, December 28, 2015

On The Topic of Deploying Honeypots

Hey everyone - I hope you are having a good holiday.  A little while ago, I came across a article about the operational security (OPSEC) of deploying honeypots for industrial control systems.  The article is here, and I thought it brought up an interesting point about deploying defenses in a network.


Honey pots

In case you do not know what a honey pot is, a honey pot is a system that appears to be a vulnerable system.  This allows the owner of the honey pot to observe attacks on the system to learn from them so that the owner can better defend the systems with real data.  Honey pots can be an effective tool to help defend your network by providing valuable intelligence.  However, they can only be effective if they are set up correctly (just like any other defensive measure you might deploy).

There is nothing of value kept on the honey pot, but for a honey pot to be effective, it must look like it belongs in the network.  This means that it should have data that looks like it might belong to the organization or be set up in a way that is similar to other hosts in the network.  Therefore, if the honey pot looks fake or out of place, the attacker might change tactics.  At best, the attacker will avoid your network to avoid compromising his tactics.  At worst (and more realistically), he will adapt and change his techniques to avoid or degrade the honey pot so that it is no longer effective.  If you deploy the same honey pot elsewhere in your network, the attacker may know how to find those other honey pots and steer around them.

So, when setting up a honey pot (or anything else), be sure to alter the defaults so that it does not become low hanging fruit.

An example

When Shellshock (CVE-2014-6271) was a big thing last year, it was interesting to see how many related vulnerabilities were found in quick succession.  Given the popularity of Shellshock, a honey pot was developed called Shockpot that allowed researchers, defenders, or curious people to deploy it to watch attackers try to use Shellshock.

In its default configuration, the server presents a very specific (fake) webpage that we can use to find default Shockpot installations.  Here is the configuration file (from the GitHub page):
The line that starts with "server =" can be used to find other possible installations of the honey pot.  We can plug the string into Shodan like this:
Just because a server has that string does not mean that the box is a honeypot, but there is something strange about these results.  Notice that the Content-Length is the same at 177 bytes.  If we look at the default installation, it also serves a page that is 177 bytes:
Let's see if we can get any more information about one of the servers Shodan found:
We can see that this box is running other honeypot software, and for some of the services, it even tells us which one.  If someone was trying to attack this box, they have a better idea of what they are up against, or they would know to avoid this box and look for others in the network.  The only people you might catch with this will be ones that do not know what a honey pot looks like.  Unfortunately, you may not see more advanced attacks on your network by people who are more savvy.

Hopefully, other defense mechanisms in your network will help you see an attacker poking at your network, but a default honey pot will likely not gain you much.

Conclusion

Honey pots are one tool in the tool box for a network defender.  But as with any network defense tool, it requires set up and maintainence to be effective.  So when you are considering deployment of a network defense measure, think through it:

Ask questions such as:
  • How can I tailor this tool to my network so that an attacker does not notice it?  Changing default configurations goes a long way.
  • How can I deploy the tool in the right place in my network so that it will be the most effective?  A honey pot on the inside of the network may be good for insiders or attackers that are already in, but will probably not do anything for you to gather information about threats hitting your perimeter.
  • Does this tool clash with other tools I already have deployed?  For example, if you put your IDS inside of your firewall, you will catch potential intrusions that make it past your firewall, but what about those that do not?  Some of them may be script kiddies, but some of the traffic might be a precursor to an intrusion event.
  • Will I monitor and digest the output of the tool?  If you have an IDS or honey pot that is providing information about potential attacks, but you ignore it, then it is not doing any good.  If you do not have the resources necessary to make use of the information that the tool is trying to tell you, then you may need to reconsider deploying it.
Thanks for reading!  Have a good holiday season!

No comments:

Post a Comment