For the past eight months we have been discussing what honeypots are, their value, their different types, and how they can be used and deployed. Today we will do something a little different. Instead of discussing what honeypots can do and how they work, we will take a look into the crystal ball and see what honeypots should do, how they could work. If I had a dream honeypot, this is what I would like to see in the future: the dynamic honeypot.
One of the biggest challenges we face with most security technologies, including honeypots, is configuring them. Everything from encryption keys to firewall rules require a human to analyze the problem, come up with a solution, then configure and implement that solution. Adding more complexity, the work is not done once the technology is implemented. Once you have that 'bad boy' deployed, it can require daily loving care. I can remember starting my security career working in web farms that had over thirty firewalls, each firewall with hundreds of rules. A large part of my every day was spent updating and troubleshooting those rules.
Honeypots face the same challenge, regardless of what type of honeypot you are building. From something as simple as KFSensor to something as advanced as Honeynets, configuration is still required. With honeypots, one of the configuration issues is what will your honeypot look like? Do you want it to appear as a Solaris system, Windows, Linux, or perhaps Cisco IOS? You want to ensure you are running the same operating systems that are deployed within your organization, so the honeypots can blend in with your environment. Once you have determined the OS, what services do you want to run: web, mail, or perhaps file sharing? Failing to run the correct services means missed probed or attacks. However, monitoring the wrong services can be just as harmful, as the wrong service can be a dead giveaway for a honeypot. Having a Linux honeypot emulate Sub7 or NetBus services would look quite odd. Having a Windows honeypot emulate the sadmind, dtscpd, or rpc.statd service would also have a fishy appearance about it. As such, you have to make sure the correct honeypots are running relevant services. Also, the issue becomes of where do you deploy your honeypot, and how many?
As if configuring and deploying was not enough, someone has to maintain the honeypot(s) once they go live. This can be more challenging then it sounds. Not only is honeypot technology rapidly developing and changing (requiring updates for your honeypots) but so are your networks. New systems are constantly being added (such as the latest Linux server) old systems removed or upgraded (such as that Novell NetWare server still running IPX), new applications introduced (Instant Messaging, P2P, or live video), while old services may be phased out (Gopher, Telnet). Your organization and networks are constantly changing. To stay current, your honeypots have to adapt to the changes. Traditionally, this means someone manually updating or modifying the honeypots to better mirror the production environment. That means time, money, and mistakes.
Dynamic honeypots - the future
What I would like to see in the near future for honeypots is the dynamic honeypot, a plug-n-play solution. You simply plug it in and the honeypot does all the work for you. It automatically determines how many honeypots to deploy, how to deploy them, and what they should look like to blend in with your environment. Even better, the deployed honeypots change and adapt to your environment. You add Linux to your network, you suddenly have Linux honeypots. You remove Novell from your network, your Novell honeypots magically disappear. You replace your Juniper routers with Cisco IOS, and so your honeypot routers change. The goal is an appliance, a solution you simply plug into your network, it learns the environment, deploys the proper number and configuration of honeypots, and adapts to any changes in your networks. Sound like magic? It shouldn't, the technology is there. We just have to put it together. Lets see what would be involved in making our dynamic honeypot, and then see how it could work. In many ways, this is what I would consider the perfect honeypot.
The first (and most critical) part of a dynamic honeypot is how it learns about your network, what systems your organization is using and how they are being used. With this knowledge, your dynamic honeypot can intelligently map and respond to your environment. One possible approach is to actively probe your network, determine what systems are live, what type of systems they are, and the services they are using. Nmap is one such scanning tool with that capability. However, there are some drawbacks to such an active method. First, you are introducing more activity to your networks. Not only can you affect bandwidth or network activity, but with the scanning process you can cause services, even entire systems to shutdown. Second, its possible to miss a system, as it may be firewalled. Probes are sent to the system, but nothing is returned. Third, active scanning takes only a snapshot of a point in time, it cannot update you to real-time changes. To do that, you would constantly need to scan your environment. Not a very elegant approach. For our dynamic honeypot, I prefer a passive approach, specifically passive fingerprinting and mapping.
The concept of passive fingerprinting is not new. One of the first papers to discuss it was Know Your Enemy: Passive Fingerprinting. The idea is relatively simple, to map and identify systems on your network. However, you do not actively probe the systems, instead you passively capture network activity, analyze that activity, then determine the system's identity. The technology uses the same methods as active scanning. Tools such as Nmap build a database of known operating systems and services. These tools then actively send packets to the target, packets which illicit a response. These responses (which are unique to most operating systems and services) are then compared to a database of known signatures to identify the operating system and services of the remote system. For example, below is Nmap's signature for a Windows NT operating system. This lists the different responses WinNT 4.0 SP5-SP6 will send to an Nmap OS probe. To learn more about Nmap's active fingerprinting, refer to the paper Remote OS Detection by the infinitely wise Fyodor.
# Contributed by Vilius email@example.com Fingerprint Windows NT 4.0 Server SP5-SP6 TSeq(Class=RI%gcd=<8%SI=<11784E&>2CA4) T1(DF=Y%W=2017%ACK=S++%Flags=AS%Ops=MNWNNT) T2(Resp=Y%DF=N%W=0%ACK=S%Flags=AR%Ops=) T3(Resp=Y%DF=Y%W=2017%ACK=O%Flags=A%Ops=NNT) T4(DF=N%W=0%ACK=O%Flags=R%Ops=) T5(DF=N%W=0%ACK=S++%Flags=AR%Ops=) T6(DF=N%W=0%ACK=O%Flags=R%Ops=) T7(DF=N%W=0%ACK=S++%Flags=AR%Ops=) PU(DF=N%TOS=0%IPLEN=38%RIPTL=148%RID=E%RIPCK=E%UCK=E%ULEN=134%DAT=E)
Passive fingerprinting takes the same approach, it has a database of known signatures for specific systems. However, the data is taken passively. Instead of actively probing remote systems, passive fingerprinting sniffs traffic from the network, then analyzes the packets from that network. It compares the packets against a database of signatures to identify the remote system (and potentially the services). Passive fingerprinting is not limited to TCP, other protocols can be used. For example, Ofir Arkin has done extensive passive work using ICMP. There are several advantages to using passive technologies. The first is that it's not intrusive. Instead of actively interacting with systems, you are passively gathering data. There is far less likelihood of you damaging or taking down a system or service. Second, even if systems are using host-based firewalls, passive fingerprinting will identify the system, if nothing else it will map a MAC address to an IP. Last, this method is continuous -- as your networks changes, these changes can be captured in real time. This becomes critical for maintaining realistic honeypots over the long term. The disadvantage of passive mapping is it may not work well across routed networks; it's potentially more effective on your local LAN. Then again, this is true for active mapping also. In some cases, more then one dynamic honeypot would have to be physically deployed in your organization, depending on its size, number of networks, and configuration.
Our dynamic honeypot could leverage this concept of passive fingerprinting to learn your networks. The honeypot could be deployed as an appliance or single box. This device is then physically connected to your network. Once connected, it spends the next 24 to 72 hours watching and learning your network. By passively analyzing all of the traffic it sees, it determine how many systems are on your networks, the operating system types, the services they offer, and potentially even which systems are communicating with whom and how often. This information is then used to learn and map your network. Once the honeypot learns the environment, it can begin deploying more honeypots. The advantage here is that the honeypots are crafted to mirror your environment. By looking and behaving the same way as your production environment, the honeypots seamlessly blend in, making them much more difficult for attackers to identify as honeypots, or to 'sniff them out'. However, this passive learning does not stop. Instead, it continuously monitors your network. Whenever changes are made, these changes are identified and the deployed honeypots adapt to the changes. If your organization is a typical Windows environment, you may begin deploying some Linux servers. Our dynamic honeypot, using passive fingerprinting, can determine that Linux systems have been deployed. Our honeypot would then deploy Linux honeypots, or update existing honeypots, based on the same Linux makeup and using similar services. The dynamic honeypot vastly reduces not only the work involved in configuring your honeypots, but also maintains them in a constantly changing environment.
The exciting part is that in many ways this technology already exists! Led by Michal Zalewski, the passive fingerprinting tool p0f has many of the capabilities we just described. p0f has tremendous capabilities, as it can not only tell you about systems on your local networks, but also about other networks and even systems behind firewalls. p0f is OpenSource, allowing you to not only use it for free, but it gives you the option to customize the code to best suite your environment. A commercial example of such capabilities is Sourcefire's Real-Time Network Awareness. Designed to work with IDS sensors, RNA passively maps your network to coordinate IDS alerting with your network makeup. By utilizing tools such as these, honeypots can now learn and monitor their environments in real time.
The next problem to be solved is how do the honeypots get deployed? Passive fingerprinting offers a powerful tool, but how do we actually get it to populate our network with honeypots? Traditionally, this would require physically deploying a new computer for each IP address we wanted to monitor. However, this defeats the purpose of a dynamic honeypot if a person has to physically deploy multiple honeypots. We need a hands free, fire-and-forget solution. A far more simple and effective approach is not to deploy any physical honeypots. Instead, our honeypot appliance deploys hundreds, if not thousands, of virtual honeypots monitoring all of your unused IP space. All of these virtual honeypots are deployed and maintained by our appliance, our single physical device. Because the virtual honeypots monitor unused IP space, we can be highly confident that any activity to or from those IPs is most likely malicious or unauthorized behavior. Based on our previous passive mapping of the network, we can also determine how many honeypots we should deploy, the types, and where. For example, our passive mapping may have determined that on our Class C network, we have 100 Windows XP workstations, twenty Windows 2003 servers, five Linux servers, and two Cisco switches. Based on this, our dynamic honeypot can create an equivalent ratio of honeypots. Perhaps ten Windows XP honeypots, two Windows 2003 servers, one Linux server, and one Cisco switch. Our honeypots now not only match the type of production systems in use and their services, but the ratio of systems used. Not only that, but the virtual honeypots can also monitor the same IP space as the systems themselves. For example, perhaps our honeypot learns that the Windows XP workstations are DHCP systems in the 192.168.1.100 - 192.168.1.250 range. Our Windows XP honeypots would reside in the same IP space, while the other honeypots are monitored their respective IP space.
Once again, this ability to dynamically create and deploy virtual honeypots already exists. The OpenSource honeypot Honeyd allows a user to deploy virtual honeypots throughout an organization. In addition, this honeypot can emulate over 500 operating systems, both at the IP stack and application level. As an OpenSource solution, its highly customizable, allowing it to adapt to almost any environment. By combining the capabilities of a solution like Honeyd, with the capabilities of a passive fingerprinting tool such as p0f, we come very close to our dynamic honeypot. We can have a hands free, fire-and-forget solution. You deploy your Honeyd honeypot by connecting it to your network. The passive fingerprinting tool p0f kicks in, passively monitoring and mapping your network. After a certain period of time, it learns what systems you have, what they are running, where they are located, and potentially how they are being used. Based on this data, your honeypot creates virtual honeypots that mirror the makeup of your network, and subtly blend in with your production systems. Attackers can no longer tell what is a honeypot and what is really part of your network. Once these honeypots are virtually deployed, p0f continues to monitor your networks. The virtual honeypots adapt in real time to any additions, changes, or removal of existing systems. All you, as a security administrator, have to do is sit back and catch the bad guys.
Dynamic honeypots can radically revolutionize the deployment and maintenance of honeypots. By learning and monitoring your networks in real time, they become a fire-and-forget solution. Not only do they become cost-effective to deploy and maintain, but they have better integration into your network. I really hope to see in the near future such a solution.