Honeypots are tools to provide network administrators with a multitude of information on what is venturing out on the Internet. One of the easiest ways to gather this information is by using a Snort sensor. In these cases, you want your sensor to gather as much information as possible (if not everything). For a honeypot, this is practical, since the traffic is usually very low, so gathering all the communication does not generate that much log information. Snort can also be used once in a while with tcpdump capture to see what known attacks targeted the honeypot. Capturing all the data also provides a means to gather new worms as they are created, not only known ones. A typical honeypot topology could look like the one shown in Figure 19-6.
Even if honeypots do not provide an immediate value to network security, they do provide a very good return on investment from the information side. Since honeypots are not supposed to be used systems, most (if not all) communications are attacks or illegitimate. This provides good information about who is attacking your network, from where, and with which attack techniques.
Even if this offers awesome information on the defending side, the main drawback of honeypots is that they only capture a small part of the incoming communication to your network—the stuff targeted at the honeypot. This has a microscopic effect; it provides a lot of information about a little part of your network (and it usually isn't regarding the production server that you really care about). However, having this data at hand helps you verify the status of the real network, since you are able to cross reference attacks occurring in the honeypot with attacks occurring on the real network.
Honeyd (http://www.honeyd.org) is primarily used to emulate the behavior of servers through the use of simple scripts and you can do so using cheap or old servers. Configuring server behavior in Honeyd is done inside the honeyd.conf configuration file. Example 19-4 is a simple file configuration of a Honeyd host with proper commenting.
Example 19-4. SimpleHoneyd configuration file
# Create a new Template named win2k. create win2k # Define the network stack personality set win2k personality "Windows 2000 server SP2" # Default action for TCP connections set win2k default tcp action reset # Default action for UDP connections set win2k default udp action reset # Default action for ICMP connections set win2k default icmp action block # Define the uptime of the system set win2k uptime 3567 # # Open multiple TCP ports and run respective script on connection to those ports. # add win2k tcp port 21 "sh scripts/win32/win2k/msftp.sh $ipsrc $sport $ipdst $dport" add win2k tcp port 25 "sh scripts/win32/win2k/exchange-smtp.sh $ipsrc $sport $ipdst $dport" add win2k tcp port 80 "sh scripts/win32/win2k/iis.sh $ipsrc $sport $ipdst $dport" add win2k tcp port 110 "sh scripts/win32/win2k/exchange-pop3.sh $ipsrc $sport $ipdst $dport" add win2k tcp port 143 "sh scripts/win32/win2k/exchange-imap.sh $ipsrc $sport $ipdst $dport" # Attach this predefine personality or server template to a specific IP address. bind 192.168.1.130 win2k
Honeyd can also be used to emulate a virtual network. The main advantage of emulating a full network with a router and subnet, compared to just doing a flat layout of a server, is that the attacker, trying to find the topology of your network, could really find it if all the systems in your network are on the same switch. The following configuration example demonstrates different possible network device configurations inside Honeyd. A nifty way to use this is to emulate a test network to verify its validity.
# Indicate the entry point for the network 10.0.0.0/16 route entry 10.0.0.1 network 10.0.0.0/16 # Indicate that host in 10.0.0.0/24 are reachable by 10.0.0.1 route 10.0.0.1 link 10.0.0.0/24 # Indicate that 10.0.1.0/24 is reachable thru 10.0.0.100 route 10.0.0.1 add net 10.0.1.0/24 10.0.0.100 # Indicate that 100.0.0.100 can reach 10.0.1.0/24 route 10.0.0.100 link 10.0.1.0/24 # Indicate that 10.0.2.0/24 is reachable thru 10.0.0.101 # with a latency of 50 ms # bandwidth of 1 mpbs # the packet loss in % on this connection. route 10.0.0.1 add net 10.0.2.0/24 10.0.0.101 latency 50ms loss 0.1 bandwidth 1Mbps # Indicate that 100.0.0.101 can reach 10.0.2.0/24 route 10.0.0.101 link 10.0.2.0/24
One way to use the low interaction of a honeypot and Honeyd is as a tar pit. Tar pits are used to slow down spammers and identify spam so the information can be fed back to spam filtering systems. Using the honeypot this way allows the spam to hit the honeypot, but not your real system. Here is a simple configuration for a tar pit; all ports are open and are just meant to slow down the attacker:
create sticky set sticky personality "Mac OS X 10.1 - 10.1.4" set sticky default tcp action tarpit open set sticky default udp action block bind 192.168.1.110 sticky
That tar pit configuration could also be useful to slow down worm propagation. An even simpler tar pit could be used just to catch spammers over the SMTP port, by using the SMTP emulator.
There are two types of implementation possible for Honeyd: using the black-hole technique or allocating unused address space in your existing zone to mix real systems with the honeypot.
The easiest method is the total black holing of an address space. If you have a whole unused address space such as a class B or C, you could simply redirect all traffic directly to the honeypot from the router. This will separate the real network from the honeypot, so communication from the honeypot to the real network might be blocked by a firewall. It can also improve the security of the network in case the honeypot itself becomes a target. Figure 19-7 shows this kind of implementation.
The other method, which implies placing the honeypot inside a real network, also implies giving unused addresses of a subnet to the honeypot. While this network might look more realistic since there is real server in it, it also requires more work because all the unused IP addresses must be assigned to the honeypot's MAC addresses. The task of allocating unused addresses in a subnet is performed by Arpd (www.honeyd.org/tools.php). Arpd is a daemon that listens to ARP requests and answers for IP addresses that are unallocated. When using Arpd in conjunction with Honeyd, it is possible to populate the unallocated address space in a production network with virtual honeypots. With DHCP-allocated IP addresses, it is possible that Arpd can interfere with the DHCP server by causing Honeyd to reply to pings that the DHCP server uses to determine whether an address is free. A typical network diagram of this kind of configuration is shown in Figure 19-8.
Using Arpd is pretty straightforward. If you need help with Arpd, refer to the manpage provided with the application. The following command line is a typical Arpd request to gather all unused IP addresses in the 192.168.0/24 subnet from interface eth0:
#arpd -i eth0 192.168.0/24
Since honeyd is an open source project, is it possible for community members to extend its functionality. In the case of new emulated services, this is done through the use of scripts that replicate the behavior of the server without having the real logic. This has the advantage of having a low security risk, since most attacks cannot be performed against this fake server.
Even if Honeyd is listening on every port, most exploits these days will do some kind of check to be sure they are attacking the right version and not crash the application uselessly. Having a small server that responds like a real server will greatly improve the chance of catching new, in-the-wild exploits and not just automated bots or worms.
Writing scripts to replicate a server might seem difficult, but it depends on the level of realism you want to achieve. These scripts can be very simple to very complicated. For most cases, if the script provides enough information to be identified as a valid version, it should be enough to catch black-hat exploits. If you intend to use your honeypot for research projects, it might be a better choice to use a high-interaction honeypot solution. These solutions offer a full OS to the attacker so that downloaded toolkits and other behavior can be studied. Low-interaction honeypots such as Honeyd are good at capturing worms, spammers, and new exploits, but are bad for other uses (e.g., gathering rootkits).
Example 19-5 is a simple honey script written in shell by Maik Ellinger, to reproduce an SMTP server.
Example 19-5. POP3 honeypot script
***************************************************************
#!/bin/sh
#
# POP3 Honeypot-Script intended for use with
# Honeyd from Niels Provos
# -> http://www.citi.umich.edu/u/provos/honeyd/
#
# Author: Maik Ellinger
# Last modified: 24/06/2002
# Version: 0.0.1
#
# Changelog:
#
# 0.0.1: initial release
#
#set -x -v
DATE='date'
host='hostname'
domain='dnsdomainname'
log=/tmp/honeyd/pop3-$1.log
AUTH="no"
PASS="no"
LOGINOK="yes" # give to all logins a "+OK Mailbox open, 3 messages" back (no/yes)
echo "$DATE: POP3 started from $1 Port $2" >> $log
echo -e "+OK QPOP (version 2.53) at $host.$domain starting.\r"
while read incmd parm1 parm2 parm3 parm4 parm5
do
# remove control-characters
incmd='echo $incmd | sed s/[[:cntrl:]]//g'
parm1='echo $parm1 | sed s/[[:cntrl:]]//g'
parm2='echo $parm2 | sed s/[[:cntrl:]]//g'
parm3='echo $parm3 | sed s/[[:cntrl:]]//g'
parm4='echo $parm4 | sed s/[[:cntrl:]]//g'
parm5='echo $parm5 | sed s/[[:cntrl:]]//g'
# convert to upper-case
incmd_nocase='echo $incmd | gawk '{print toupper($0);}''
#echo $incmd_nocase
if [ "$AUTH" == "no" ]
then
if [ "$incmd_nocase" != "USER" ]
then
if [ "$incmd_nocase" != "QUIT" ]
then
echo -e "-ERR Unknown command: \"$incmd\"\r"
continue
fi
fi
fi
case $incmd_nocase in
QUIT* )
echo -e "+OK Pop server at $host.$domain signing off.\r"
exit 0;;
HELP* )
echo -e "-ERR No help.\r"
;;
USER* )
parm1_nocase='echo $parm1 | gawk '{print toupper($0);}''
if [ "$parm1_nocase" == " ]
then
echo -e "-ERR Too few arguments for the user command.\r"
else
echo -e "+OK Password required for $parm1.\r"
AUTH=$parm1
fi
;;
PASS* )
if [ "$LOGINOK" == "yes" ]
then
PASS=$parm1
echo -e "+OK Mailbox open, 1 messages\r"
else
echo -e "-ERR Password supplied for \"$AUTH\" is incorrect.\r"
fi
;;
LIST* )
echo -e "+OK Mailbox scan listing follows\r"
echo -e "1 1340\r"
echo -e ".\r"
;;
DELE* )
echo -e "-ERR message $parm1 already deleted\r"
;;
RETR* )
if [ "$parm1" == "1" ]
then
echo -e "+OK 1340 octets\r"
else
echo -e "-ERR No such message\r"
fi
;;
STAT* )
echo -e "+OK 0 0\r"
;;
NOOP* )
echo -e "+OK No-op to you too!\r"
;;
RSET* )
echo -e "+OK Reset state\r"
;;
* )
echo -e "500 '$incmd': command not understood.\r"
;;
esac
echo -e "$incmd $parm1 $parm2 $parm3 $parm4 $parm5" >> $log
doneThis script was written in shell style; however, Honeyd does accept multiple types of scripting languages, offering the flexibility to write simple scripts for ASCII-based protocols or complex ones using Python for multiple-state binary protocols.
Since the Honeyd process is going to be under attack most of the time, it is always better to use a very secure server to host this kind of task. I recommend using Jail or chroot for the honeyd process. If it's running scripts, adding a systrace policy over that might be a good idea since that system will probably be wide open on the Internet. You certainly do not want your honeypot to become the point of entry for an attacker (that would defeat the whole purpose of the honeypot and lower the security of your network).
For more information on how to use chroot, Jail, systrace, and Solaris containers, please refer to the power tools in Chapter 14 and to the respective manpages of these programs. The application of these techniques is strongly recommended.
Even if the common Honeyd instances do not generate a lot of logs, most of the logs should be scrutinized per instance to extract as much information as possible from the black-hat community. Because managing these logs is a pain and involves log management or correlation, the Honeynet community has developed tools that specialize in analyzing Honeyd logs and extracting valuable information from them. Tools such as HoneyView (http://honeyview.sourceforge.net) perform this task. These log analysis tools allow you to see trends and extract valuable information about the attacks occurring in your network.
Figure 19-9 shows the resume view from HoneyView. As you can easily see, the graphing functionality of HoneyView can help most administrators gather information and statistics rapidly.
Being able to look at trends of attacks on your network can give you decent intelligence from the attacking side—for instance, information such as where are the attack originated, which service is currently a prime target, the time frame of the attacks, and various other metrics. So even though each communication is important and Snort offers us a wonderful microscopic view, keeping an eye on the big picture is always a good idea.