Once Honeyd receives the attacker's initial connection, via blackholing or ARP spoofing, Honeyd assumes the identity of the victim and takes over the connection. Honeyd then identifies what port the attacker is targeting and reacts based on that port. One of several things can then happen. First, Honeyd may not have a service emulator for the intended port, in which case it may reply that the port is closed, or it may not reply at all, depending on how you configure the system. However, either way Honeyd will detect that attempt, allowing Honeyd to detect activity on any port. Second, Honeyd may be configured to interact with the attacker using an emulated service. For example, if an attacker connects to TCP port 111, the honeypot may simply reply with an RST packet, declare the port closed and then log the attempt. However, if an attacker connects to TCP port 80, the honeypot can initiate a Web server emulator and interact with the attacker, capturing her activities. Honeyd also has several other advance options for interacting with attackers, which we discuss later when configuring the honeypot.
As already mentioned, Honeyd has the unique ability to emulate operating systems at not only the application level, just as Specter does, but also at the IP stack level. With Specter and Honeyd, when an attacker
communicates with an emulated service, such as the Web server, the emulated service behaves differently, depending on the selected emulated OS and scripts. With Specter, we saw how the Web server became a Microsoft IIS Web server or Apache Web server, based on whether the emulated OS was Microsoft-based or Unix-based. Honeyd has the same capability. However, with Specter, the underlying IP stack is based on the installed platform, which is always Windows. Honeyd does not have this limitation. It if is emulating a Linux
box, the IP stack can act as a Linux IP stack. If the Honeyd honeypot is emulating a Cisco router, so too can the IP stack.
Nmap is one of the most common tools used to remotely determine operating system type. Nmap sends a variety of packets to a target, captures the response to the packets, and compares the response to a database of known signatures. Based on the matching signatures, we can remotely determine the OS type. Honeyd takes the very same database of signatures that Nmap uses and replies to Nmap probes based on the emulated operating system. This means if your Honeyd system is emulating a Windows XP server, and it is probed by Nmap, Honeyd looks at the Nmap database, determines what signatures a Windows XP server has, then replies with those signatures. The attacker is spoofed into thinking he has a Windows XP system based on the IP stack. At the time of writing this book, the Nmap configuration file had 473 different operating systems fingerprinted. This is where Honeyd gets its limitation of emulating 473 different operating systems.
This method is not foolproof. Nmap is but one of many ways to determine the OS type. For example, we mentioned that Ofir Arkin's X tool can remotely determine OS type based on ICMP traffic. Another method is passive OS fingerprinting, discussed in Chapter 16. These other methods can potentially see through Honeyd's IP stack emulation and determine the true underlying OS type (although Honeyd does have some capabilities to fool X as well). However, Honeyd greatly mitigates the risk of fingerprinting using the Nmap database, since this is one of the most common tools (and databases) used for remote fingerprinting. The other advantage to using the Nmap database is as Nmap updates and improves the database of known signatures, Honeyd can simply copy and use the latest database files, staying current with new probing methods.
Figure 8-6 shows the end result of all these capabilities combined. A Honeyd honeypot has been configured to act as a Cisco router. When the system is fingerprinted, it will behave as a Cisco IP stack. Also, the honeypot has been configured to emulate all services as a Cisco router. Both the Telnet and HTTP services were enabled, commonly used interfaces to configure a Cisco router. If an attacker connects with either service, he will think he is interacting with a router when in reality he is interacting with the honeypot.
In Figure 8-6 we see an attacker first probe our honeypot using Nmap fingerprinting capabilities (specifically the "-O" option). Nmap actively probes the system, determines what ports are open, and then sends a variety of packets to determine the operating system type. Nmap determines the remote system as a Cisco 7206 router running IOS 11.1(17). The attacker then Telnets to the router and gets a login prompt with a warning banner, just as they might expect for a Cisco router. The attacker attempts a single login attempt and then closes the
connection. Honeyd demonstrates its ability to emulate at both the IP stack and application level.
Installing and Configuring Honeyd
As an OpenSource solution designed for Unix, Honeyd does not provide any support or a nice GUI for installation or configuring. Instead, you download the source code to your honeypot, compile the source code, and then install the Honeyd binary and configuration files. You then run the Honeyd binary from the command line, using the two configuration files, to the network you want it to monitor. Once started, Honeyd will interact with any attack sent its way. The command to start Honeyd looks something like this.
honeyd -p /etc/honeyd/nmap.prints -f /etc/honeyd/honeyd.conf 192.168.1.0/24
The first command is executing the binary Honeyd. The -p option is the location of the Nmap fingerprints file. This is the database of signatures used by Honeyd to emulate different operating systems at the IP stack level. If an attacker uses Nmap to fingerprint your operating system, Honeyd will use the Nmap fingerprint database to determine how to respond to the attack, based on the operating system you are emulating. In Figure 8-7 we see an excerpt from the Nmap fingerprints file, specifically the Nmap fingerprint for Windows NT 4.0 Server SP5- SP6.
Figure 8-7 Example of the Nmap signature database file. This is a specific signature for Windows NT Server, Service Pack 5 or 6.
# Contributed by Vilius [email protected] 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)
The second option is -f, which is the location of the Honeyd configuration file. This configuration file determines which services you emulate and the operating system type. We will cover the details of the configuration file in a moment.
The last option is the network that you want to monitor. This means that whenever Honeyd receives a packet for a nonexistent system, and the IP address belongs to the monitored network, Honeyd will assume the identity of the destination IP address and interact with the attacker. If no network address is given to the monitor, Honeyd will interact with any IP address sent its way.
The Honeyd configuration file is relatively straightforward, but it has an extensive amount of options. We will highlight how the configuration file works. However, if you want to learn all the options and details later, both the Honeyd honeypot source code and documentation can be found on the CD-ROM. Let's take a look at an example configuration file in Figure 8-8 and explain how it works.
Figure 8-8 Example of Honeyd configuration file
create default
set default personality "FreeBSD 2.2.1-STABLE" set default default tcp action reset
add default tcp port 80 "sh /etc/honeyd/scripts/apache-web.sh" add default tcp port 22 "sh /etc/honeyd/scripts/test.sh"
add default tcp port 113 open add default tcp port 1 open create windows
set windows personality "Windows NT 4.0 Server SP5-SP6" set windows default tcp action reset
set windows default udp action reset
add windows tcp port 80 "perl /etc/honeyd/scripts/iis/main.pl" add windows tcp port 25 block
add windows tcp port 23 proxy real-server.tracking-hackers.com:23 add windows tcp port 22 proxy $ipsrc:22
set windows uptime 3284460
# bind specific IP addresses to specific templates bind 192.168.1.200 windows
Honeyd works by creating templates that define the characteristics of a honeypot, including operating system type, the ports they listen on, and the behavior of the emulated services. Each template is given a name. In Figure 8-8, we have two templates—default and windows—but you can use as many templates as you want. You then apply the IP addresses or systems to whichever templates you want. In the case of a default template, there is no IP address to which it applies. This means then when we ran our Honeyd honeypot to listen on the 192.168.1.0 /24 network, the default template applies to all connections it receives for the 192.168.1.0 /24 network. However, perhaps we want certain IP addresses to behave like a specific system. In the Windows template, we bind it to a specific IP address, specifically 192.168.1.200. This takes precedence. So if Honeyd receives any IP addresses on the 192.168.1.0 /24 network except .200, then it uses the default template. However, if the intended victim is 192.168.1.200, then Honeyd uses the Windows template.
Under each template are the configuration parameters—how the honeypot will behave. The first characteristic is the OS type, or personality. This determines how the system will behave at the OS IP stack level, the Nmap fingerprint that is to be used. This does not effect the behavior of the scripts.
After we have determined the personality of the honeypot (its operating system type), we need to know the behavior of each service: What happens when an attacker connects to a specific port? We have the following options whenever a connection is made to any TCP or UDP port.
• Reset This means that Honeyd will send a TCP reset (RST) for TCP connections or an ICMP unreachable for UDP connections. This emulates a closed TCP or UDP port, there is no service bound to the port.
• Open This means that Honeyd will act as if the service is open and will acknowledge (ACK) all TCP data that it receives. However, there is no service emulation.
• Block The means that Honeyd will drop and ignore all connections to the ports. This emulates a firewall's port or service.
• Script This calls on predefined scripts to interact with the attacker. It is these scripts that emulate services. This is limited to TCP only.
In Figure 8-8 the second template defines a Windows system. Let's look at that template in detail. After defining its personality as a Windows NT server, we then define its behavior on the ports on which it is listening. We first define the default behavior. In other words, if an attacker connects to a port, and we have not defined that port's behavior, then the default action is executed. In Figure 8-9 we define the default behavior for both TCP and UDP as Reset. This means if an attacker connects to any port we have not defined, the default response is to send the attacker an RST packet for TCP connections or an ICMP port unreachable for UDP connections, emulating a closed port. After defining the default behavior, we can define the behavior of specific ports. For the Windows template, we define that whenever a connection to port 80 (HTTP) is made, then we execute the specific Web emulation PERL script to interact with the attacker.
Each unique script determines the interaction with the attacker. Also, each unique script determines the OS type of the application, so you will use a different script depending not only on the service type but the OS type as well. The more scripts you have, the greater your options for interacting with an attacker. You can develop your own emulated services using the scripting or coding language of your choice. If you like shell code, you can script your own emulated services. If you prefer PERL, use PERL. This freedom to choose the language of your choice gives you, and the security community, incredible freedom to develop emulated services, and it is one of Honeyd's greatest strengths. Expect to see a growing number of emulated services for Honeyd in the near future. The Web server PERL script we are using for the Windows Web server demonstrates just how advanced the emulated service can get. This script, developed by rain forest puppy, has extensive emulation and customization capabilities. Rain forest puppy describes it as follows.
This script allows someone to emulate the basic components of a slightly patched IIS 5.0 server. Using the internal handler API, anyone can create the capability of emulating any type of response—including vulnerabilities—with little trouble. The default install includes a setup which acts just like the default IIS 5.0, which includes the /msadc/ and /iisadmin/ directories, emulation of all default extensions (.htw, .htr, .printer, etc.), FrontPage support, and the decoding of Unicode URLs (although the Unicode bug is not emulated for various reasons). The emulator is itself a full-blown Web server, which means a user can actually put custom HTML/ASP pages in the emulator's document directory, and the emulator will serve them just like IIS 5.0 would serve them.
Other scripts can be very simple. For example, Honeyd also comes with a simple shell script for testing configuration files. In Figure 8-8, we configure the default behavior on port 22 (normally used by SSH) to use the shell script "test.sh." This is a very simple shell script that comes with Honeyd. It lets you test Honeyd configurations and deployments. In Figure 8-9, we see the source code for this basic script. All it does upon connection is supply an SSH banner, and then it enters a loop, logging and echoing any keystrokes. There is no service emulation, but this code should give you some ideas on creating your own emulated services.
Figure 8-9 Simple testing script for Honeyd, used to test configuration files and TCP connections
DATE=`date`
echo "$DATE: Started From $1 Port $2" >> /tmp/log echo SSH-1.5-2.40
while read name do
echo "$name" >> /tmp/log echo "$name"
done
Honeyd also has several advanced features we have not seen before, the first of which is proxying. Proxying allows Honeyd to accept a connection from an attacker and then redirect that connection to another system. For example, in Figure 8-8, the Window's template proxies all Telnet connections to another system. When an attacker Telnets to the Honeyd honeypot, the connection is redirected to the system real-
server.tracking-hackers.com. This can be any server we want. You can take this proxy capability one step further and even proxy connections back to the attacker. For example, in the Window's template we redirect all SSH connections to the $ipsrc, which is a variable for the attacker's source IP address. So when the attacker attempts to interact with and potentially exploit our SSH server, she will in reality be attacking her own system.
Honeyd also has the capability to spoof its uptime. Utilities like Nmap can remotely determine how long your system has been up and online. Honeyd gives you the option to spoof that information. In the final setting, we spoof our uptime to be 3,284,460 seconds, which converts to 38 days and 21 minutes. If the uptime is not specified, Honeyd will assume a random uptime between 0 and 20 days.
Last, as this book was going to print, Honeyd was developing the capability to create virtual, routed networks. This means in the future with Honeyd, you will be able to impact attackers' traceroutes, packet latency, or packet loss, deceiving their understanding of your network topology.
Remember, Honeyd may not be the only utility we run for our honeypot. If we want the ability to spoof MAC addresses in real time, we will want ARP spoofing capabilities. This allows us to identify and assume the identity of nonexistent systems in real time, which we do using the binary Arpd, created by Dug Song. Arpd is relatively easy to use. Its only options are the interface you want to use and the network you want to monitor. For the deployment of Honeyd on our 192.168.1.0 /24 network, this is the command to execute Arpd for ARP spoofing.
arpd -i xl0 192.168.1.0/24