|
|
Although we have seen many examples on how to customize your virtual honeypots, there are some situations where even greater flexibility is needed. Let's say you would like to deploy several virtual honeypots in your company's production network, but you also know that IT security is conducting regular scans of all addresses in your network. Clearly, they might get very confused by the sudden appearance of honeypots and might even believe that they represent rogue machines. If these honeypots could be invisible to the official scanning machines, much confusion could be avoided. Although it is possible to have your services behave differently toward different source IP addresses, the ability to have all aspects of the honeypot change according to who is interacting with it would help in this situation. As you might have guess already, dynamic templates allow you to do exactly that.
creation := "dynamic" <template-name>
addition := "add" <template-name> "use" <template-name> "if" <condition>
condition := "source os =" <cmd-string> |
"source ip =" <ipaddr> |
"source ip =" <ipnetwork> |
"time between" hh:mm[pm|am] "-" hh:mm[pm|am] |
A dynamic template is essentially a container for other templates. Each dynamic template has a number of rules associated with it that determine when to use each template in the container. Decisions can be based on the source IP address, the remote operating system, or the time of day.
Let's say you know your company scans all the networks from the IP address 192.168.1.2, and you would like to create virtual honeypots that do not confuse the scanner. The configuration in Figure 5.6 achieves that goal. The example creates an invisible template that drops all packets received by it and a regular template that supports all of your services. A dynamic template is used to pick the invisible template whenever receiving packets from 192.168.1.2, and the regular template does the opposite. To all hosts but 192.168.1.2, it appears that a normal host is running on 192.168.1.101. However, to the scanner, this host appears to be dead. This functionality is similar to a firewall, but it gives you more flexibility in allowing you to present completely different hosts depending on certain conditions. Dynamic templates can also be used to make hosts disappear or change their configuration according to the time of day.
create invisible set invisible default tcp action block set invisible default udp action block set invisible default icmp action block create template [ ... regular configuration ... ] dynamic magichost add magichost use invisible if source ip = 192.168.1.2 add magichost otherwise use template bind 192.168.1.101 magichost |
Building on the example from Figure 5.6, we can also simulate a host that is being powered off every day between 1:00 AM and 8:30 AM (I am not suggesting that you should work that long, but unfortunately, Honeyd does not understand time frames that cross the day boundary.):
dynamic magichost2 add magichost2 use invisible if time between 1:00am - 8:30am add magichost2 otherwise use template |
To get more reasonable working hours, we could add a second rule to the dynamic template:
dynamic magichost2 add magichost2 use invisible if time between "21:00:00" - "23:59:59" add magichost2 use invisible if time between 00:00am - 8:30am add magichost2 otherwise use template |
This example also shows how to specify the time range using a 24-hour clock. Because the time range supports seconds, the precision is a little bit better. What we have seen so far just allows us to make a host disappear under certain conditions. A more powerful use of dynamic templates is illustrated in the following scenario. Let's say you would like to use virtual honeypots to capture Internet worms. A likely assumption is that Windows worms are going to infect only Windows machines and that Linux worms are going to infect only Linux machines. So we would like our hosts to behave like Windows when they are contacted by a Windows worm and behave like Linux otherwise. Fortunately, Honeyd includes support for passive fingerprinting. Passive fingerprinting is based on ideas from Michal Zalewski, and it allows us to figure out the remote operating systems on the first TCP packet that we receive. Although far from perfect, with passive fingerprinting, we can tell which operating system was responsible for sending a packet and use that information to tailor the behavior of our honeypots accordingly. For example, dynamic templates allow us to switch to a Windows template or a Linux template depending on the remote operating system:
dynamic wormhost add wormhost use windows if source os = "Windows" add wormhost use linux if source os = "Linux" add wormhost otherwise use default |
It is possible to use all three different rule types together to get even more flexibility. Honeyd uses the template for the first rule that matches. At this point, it is not possible to nest dynamic templates, although future versions of Honeyd might well support that feature.
|
|