|
|
5.1 Advanced Configuration
5.2 Emulating Services
5.3 Subsystems
5.4 Internal Python Services
5.5 Dynamic Templates
5.6 Routing Topology
5.7 Honeydstats
5.8 Honeydctl
5.9 Honeycomb
5.10 Performance
5.11 Summary
In this chapter, we discuss some advanced features of Honeyd that you should examine more closely once you have mastered the basics. The previous chapter explained Honeyd's basic configuration language and how to set up simple honeypots. Now we are going to learn how to create a more realistic environment by using virtual routers and artificial networks. We are also going to explore how subsystems can provide background traffic for your virtual honeypots and can also be used to implement complicated protocols that the simple script-based services cannot.
Let us look at some of the more esoteric configuration commands that Honeyd understands. We are going to start with the easy ones and then slowly progress to the more complicated topics. Complicated in this case means more powerful and something you should know about to make the best use of Honeyd.
We already covered most of the set options in the previous chapter. However, there are two remaining options that you should also know about: droprate and uid.
set ::= "set" <template-name> "droprate in" <percent> |
"set" <template-name> "droprate syn" <percent> |
"set" <template-name> "maxfds" <number> |
"set" <template-name> "uid" <number> ["gid" <number>] |
By using the droprate option, you can vary the percentage of packets that Honeyd automatically discards for the template. You can use droprate in to simulate a host with a bad or congested network connection, but you can also use it to throttle the amount of the data that the honeypot receives. If you set a high enough droprate, all TCP connections to this virtual honeypot will be slowed down significantly. While droprate in applies to all packets, droprate syn applies only to TCP SYN packets and affects how quickly the virtual honeypot accepts a new connection. Some scanners never resend their SYN packets, and you might want to use this option to prevent such scanners from getting reliable information on your honeypots, but once again, you can also use it to throttle the load on your network.
The maxfds option determines the resource limit for file descriptors in processed forked for this template. Usually, we do not need to raise the default setting, but when using subsystems — explained later in this chapter — you might be able to increase the limit. Unix associates limits with all kinds of resources. The resource limit on file descriptors determines how many open files a process is allowed to have. Any operation that tries to increase the number of file descriptors above that limit is going to fail. This could become a problem when employing subsystems because subsystems can support a large number of open connections and each connection requires at least one file descriptor. When increasing the template limit to a few hundred file descriptors, it is also important to change the global limit of the operating systems. On Linux, this can be achieved by:
echo 50000 > /proc/sys/fs/file_max
On a BSD system, the sysctl command can be used to increase the maximum number of files that can be open at any given time:
sysctl -w kern.maxfiles=50000
The uid option determines under which user id Honeyd starts the service scripts for this honeypot. In most cases, you will not need to use this option, but it is provided for additional flexibility. There is also a potential security risk when choosing different uids for different templates. For Honeyd to be able to set these different permissions, it needs to run with root privileges. Running Honeyd as root creates the risk that any vulnerabilities or security holes in Honeyd itself may allow an attacker to gain full access to your real machine and not your honeypots — clearly, something we would like to avoid. Although there are currently no known security vulnerabilities in Honeyd, extra care should be taken anyway. If you run Honeyd with its default options, it will check once a day for security updates and logs a big warning if security updates are available.
You might have noticed that the action specifier for services has a keyword called tarpit that has not been explained yet. A tarpit is like that sticky stuff that you get stuck in. The basic idea is that we would like to slow down our adversary so that he has to waste time and resources without making noticeable progress. The concept of a tarpit has been discussed in detail in Section 3.3, which talked about LaBrea, a honeypot that is specifically designed to be a tarpit. Nonetheless, Honeyd supports some of this functionality, too.
Whenever you designate a port action with the tarpit keyword, all data sent to this port is processed, only very, very slowly. Let us go ahead and quickly modify the "hello world" example from the previous chapter.
Go ahead and telnet to 10.1.0.2, and you will notice how the output appears character by character almost as if you were connected to an old TeleType terminal. A good example of where the tarpit keyword might come in handy is a spam trap. A spam trap pretends to run an open mail relay and accepts any mail that is sent to it, but instead of quickly processing the mail, the spam trap keeps the spammers busy for a long time for each single piece of spam.
create test add test tcp port 23 tarpit "scripts/hello.sh" bind 10.1.0.2 test |
Honeyd's tarpit is different from LaBrea because TCP connections even under a tarpit still make progress on Honeyd, albeit slowly. Under LaBrea, TCP connections get forced into a state where they make no progress at all and might cause an adversary to just terminate her connection.
The annotate command allows us to fine-tune the personalities from the Nmap database. Although Nmap specifies the behavior of an operating system in many ways, it does not have information on all the peculiar ways an operating system can be identified remotely.
annotate= "annotate" personality-name [no] finscan |
"annotate" personality-name "fragment" ("drop" | "old" | "new")A Fin scan is a special way to detect open TCP ports on a remote operating system. The basic idea is that some operating systems reply with a TCP RST packet when receiving a TCP FIN packet to a closed port but send no reply if the port is open. This behavior can be enabled in Honeyd by annotating the personality with the finscan option. It can be turned off by specifying no finscan.
The other annotation option governs how the personality treats fragmented IP packets. The drop option causes all fragments to be ignored, which means that a virtual honeypot with such a personality will not be able to receive any fragmented packets. Since fragmentation does not really happen that often, this might be the safest option. On the other hand, there are certain tricks to fool intrusion detection systems that involve overlapping fragments. Ethernet supports only packets that are less than 1500 bytes long. An IP packet that is larger than that gets automatically fragmented by the networking stack and is reassembled on the receiver. Each fragment contains an offset that determines where the data for this fragment fits into the packet. Usually, the fragments just get concatenated together. However, in some cases, it's possible that fragments overlap and the receiver needs to decide what to do with the data in the overlap. Should it keep the old data or overwrite it with the data from the new fragment? Either one of these policies can be configured for a Honeyd personality. In reality, the policies employed by different operating systems vary even more, and it's conceivable that Honeyd might support more policies in the future. One tool that uses different fragmentation policies to identify remote operating systems is called Synscan [96].
|
|