The honeypots collect as much information as they can on the attacks coming from various sources, which enables us to later analyze and study them. This can be a great tool to use to reveal any zero-day worms that haven’t been discovered yet.
Honeypot Classifications
Honeypots are classified in two groups, based on different criteria. The first criterion is based on deployment of the honeypots. There are two groups of honeypots:
Production honeypots: Primarily used in the company’s internal network to improve the security of the whole network. They are easy to use, but provide less information about the attacks. Research honeypots: These honeypots are very complex but provide very detailed information about the attacks. They are used by research, military or government organizations.
The second criterion classifies honeypots based on the design criteria and introduces three groups:
Pure honeypots: Full production systems, so no other software needs to be installed. High-interaction honeypots: Use non-emulated operating systems with multiple services which can be exploited by the attacker. This kind of honeypot requires quite a lot of resources to function, but we can lower the expense by using multiple virtual machines. Low-interaction honeypots: Emulate the part of the system and services most frequently used. They consume relatively low amounts of resources, but the cost can nevertheless be lowered by the use of virtual machines. This is because multiple VMs can easily be run on one physical computer. These honeypots are a great way to collect the malware that botnets and worms use to expand. Some examples of such honeypots are nepenthes, dionaea and mwcollectd.
Nepenthes
The nepenthes honeypot includes several modules that emulate mostly Windows vulnerabilities. Those vulnerabilities are then detected by the self-replicating worm, which can exploit them. First, we need to install nepenthes on the Ubuntu Linux distribution with the command below: [bash]
apt-get install nepenthes
[/bash] This will install the nepenthes honeypot and add the user nepenthes and group nepenthes on the system. The command below proves that the user and group named nepenthes actually exist: [bash]
groups nepenthes
nepenthes : nepenthes [/bash] After the installation is complete, we need to start the nepenthes honeypot. This should bind to various ports on the system that will be visible to the attacker as open ports running various software programs. To start nepenthes, execute the command below: [bash]
/etc/init.d/nepenthes start
Starting nepenthes: nepenthes. [/bash] Let’s verify that the nepenthes honeypot was actually started: [bash]
ps aux | grep nepenthes | grep -v color
113 5367 0.3 0.3 7400 3044 ? S 20:09 0:00 /usr/sbin/nepenthes –user=nepenthes –group=nepenthes -C [/bash] We can see that the nepenthes starts with a process ID number (PID) 5367, and that it specifies the user and group nepenthes upon starting. The -C options force kernel security capabilities to be loaded. If we would rather start nepenthes manually, we can apply various other command line parameters upon starting nepenthes: [bash]
nepenthes -h
Nepenthes Version 0.2.2
Compiled on Linux/x86 at Apr 12 2011 15:41:15 with g++ 4.5.2
-c, –config=FILE use FILE as configuration file
-C, –capabilities force kernel ‘security’ capabilities
-d, –disk-log disk logging tags, see -L
-D, –daemonize run as daemon
-f, –file-check=OPTS check file for known shellcode, OPTS can
be any combination of rmknown’ and
rmnonop’; separate by comma when needed
-h, –help display help
-H, –large-help display help with default values
-i, –info how to contact us
-k, –check-config check configuration file for syntax errors
-l, –log console logging tags, see -L
-L, –logging-help display help for -d and -l
-o, –color=WHEN control color usage. WHEN may be never’,
always’ or `auto’
-r, –chroot=DIR chroot to DIR after startup
-R, –ringlog use ringlogger instead of filelogger
-u, –user=USER switch to USER after startup
-g, –group=GROUP switch to GROUP after startup (use with -u)
-V, –version show version
-w, –workingdir=DIR set the process’ working dir to DIR
[/bash]
Let’s display the ports that nepenthes has bound to:
[bash]
netstat -lntup | grep nepenthes
tcp 0 0 0.0.0.0:2107 0.0.0.0:* LISTEN 5437/nepenthes tcp 0 0 0.0.0.0:443 0.0.0.0:* LISTEN 5437/nepenthes tcp 0 0 0.0.0.0:220 0.0.0.0:* LISTEN 5437/nepenthes tcp 0 0 0.0.0.0:445 0.0.0.0:* LISTEN 5437/nepenthes tcp 0 0 0.0.0.0:1023 0.0.0.0:* LISTEN 5437/nepenthes tcp 0 0 0.0.0.0:1025 0.0.0.0:* LISTEN 5437/nepenthes tcp 0 0 0.0.0.0:993 0.0.0.0:* LISTEN 5437/nepenthes tcp 0 0 0.0.0.0:995 0.0.0.0:* LISTEN 5437/nepenthes tcp 0 0 0.0.0.0:3140 0.0.0.0:* LISTEN 5437/nepenthes tcp 0 0 0.0.0.0:135 0.0.0.0:* LISTEN 5437/nepenthes tcp 0 0 0.0.0.0:5000 0.0.0.0:* LISTEN 5437/nepenthes tcp 0 0 0.0.0.0:42 0.0.0.0:* LISTEN 5437/nepenthes tcp 0 0 0.0.0.0:139 0.0.0.0:* LISTEN 5437/nepenthes tcp 0 0 0.0.0.0:3372 0.0.0.0:* LISTEN 5437/nepenthes tcp 0 0 0.0.0.0:110 0.0.0.0:* LISTEN 5437/nepenthes tcp 0 0 0.0.0.0:143 0.0.0.0:* LISTEN 5437/nepenthes tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 5437/nepenthes tcp 0 0 0.0.0.0:10000 0.0.0.0:* LISTEN 5437/nepenthes tcp 0 0 0.0.0.0:6129 0.0.0.0:* LISTEN 5437/nepenthes tcp 0 0 0.0.0.0:465 0.0.0.0:* LISTEN 5437/nepenthes tcp 0 0 0.0.0.0:5554 0.0.0.0:* LISTEN 5437/nepenthes tcp 0 0 0.0.0.0:27347 0.0.0.0:* LISTEN 5437/nepenthes tcp 0 0 0.0.0.0:17300 0.0.0.0:* LISTEN 5437/nepenthes tcp 0 0 0.0.0.0:21 0.0.0.0:* LISTEN 5437/nepenthes tcp 0 0 0.0.0.0:3127 0.0.0.0:* LISTEN 5437/nepenthes tcp 0 0 0.0.0.0:2103 0.0.0.0:* LISTEN 5437/nepenthes tcp 0 0 0.0.0.0:2105 0.0.0.0:* LISTEN 5437/nepenthes tcp 0 0 0.0.0.0:2745 0.0.0.0:* LISTEN 5437/nepenthes tcp 0 0 0.0.0.0:25 0.0.0.0:* LISTEN 5437/nepenthes udp 0 0 0.0.0.0:1434 0.0.0.0:* 5437/nepenthes [/bash] There are quite a lot of open ports that nepenthes is using, which means that nepenthes is listening to every single one for malicious incoming connections. All the logged activities are saved into the /var/log/ directory. In that directory, there is a file (nepenthes.log) that contains basic information about nepenthes’ activity. There’s also a directory nepenthes/ in /var/log/ that contains various files and folders described below:
logged_downloads: A list of all downloads. The entries in the log file have the following syntax: first there’s a timestamp of when the event occurred, separated by a space. What follows is the source and the destination IP, each also separated by a space. At the end, there is also the URL to the malicious piece of software that the attacker is trying to download to our computer using the nepenthes honeypot. logged_submissions: A list of successful downloads. binaries: Contains all the detected binaries that probably contain malicious code. The binaries are named after the MD5 hash of the file, which also ensures that the same binary is saved only the first time it is observed.
There’s also a directory (/etc/nepenthes/) that holds various configuration information. We can configure nepenthes to send the logged downloads automatically on an IRC channel, which makes the logging practically real-time.
Dionaea
Dionaea is also a low-interaction honeypot. The first step is of course, installing all the required dependencies. On the official website of dionaea we can see all the dependencies that need to be installed for dionaea to work. On an Ubuntu Linux distribution, we can install most of the dependencies with the command below: [bash]
apt-get install libudns-dev libglib2.0-dev libssl-dev libcurl4-openssl-dev libreadline-dev libsqlite3-dev python-dev libtool automake autoconf build-essential subversion git-core flex bison pkg-config sqlite3 curl
[/bash] Some of the dependencies are not satisfied yet, so we’ll have to install them manually. We’ll install them in the /opt/dionaea/ directory. First, we need to create and move into that directory: [bash]
mkdir /opt/dionaea
cd /opt/dionaea
[/bash] Install libcfg: [bash]
git clone git://git.carnivore.it/liblcfg.git liblcfg
cd liblcfg/code
autoreconf -vi
./configure –prefix=/opt/dionaea
make install
cd ../..
[/bash] Install libemu: [bash]
git clone git://git.carnivore.it/libemu.git libemu
cd libemu
autoreconf -vi
./configure –prefix=/opt/dionaea
make install
cd ..
[/bash] Install libev: [bash]
wget http://dist.schmorp.de/libev/Attic/libev-4.04.tar.gz
tar xfz libev-4.04.tar.gz
cd libev-4.04
./configure –prefix=/opt/dionaea
make install
cd ..
[/bash] Install Python 3.2: [bash]
wget http://www.python.org/ftp/python/3.2.2/Python-3.2.2.tgz
tar xfz Python-3.2.2.tgz
cd Python-3.2.2/
./configure –enable-shared –prefix=/opt/dionaea –with-computed-gotos –enable-ipv6 LDFLAGS=”-Wl,-rpath=/opt/dionaea/lib/ -L/usr/lib/x86_64-linux-gnu/”
make
make install
cd ..
[/bash] Install Cython: [bash]
wget http://cython.org/release/Cython-0.15.tar.gz
tar xfz Cython-0.15.tar.gz
cd Cython-0.15
/opt/dionaea/bin/python3 setup.py install
cd ..
[/bash] Install libpcap: [bash]
wget http://www.tcpdump.org/release/libpcap-1.1.1.tar.gz
tar xfz libpcap-1.1.1.tar.gz
cd libpcap-1.1.1
./configure –prefix=/opt/dionaea
make
make install
cd ..
[/bash] After all that, we finally arrived at a point where we can install dionaea. We can do that by executing the commands below: [bash]
git clone git://git.carnivore.it/dionaea.git dionaea
cd dionaea
autoreconf -vi
./configure –with-lcfg-include=/opt/dionaea/include/
–with-lcfg-lib=/opt/dionaea/lib/ –with-python=/opt/dionaea/bin/python3.2 –with-cython-dir=/opt/dionaea/bin –with-udns-include=/opt/dionaea/include/ –with-udns-lib=/opt/dionaea/lib/ –with-emu-include=/opt/dionaea/include/ –with-emu-lib=/opt/dionaea/lib/ –with-gc-include=/usr/include/gc –with-ev-include=/opt/dionaea/include –with-ev-lib=/opt/dionaea/lib –with-nl-include=/opt/dionaea/include –with-nl-lib=/opt/dionaea/lib/ –with-curl-config=/usr/bin/ –with-pcap-include=/opt/dionaea/include –with-pcap-lib=/opt/dionaea/lib/
make
make install
[/bash]
Configuring dionaea
The configuration file of dionaea is located under the $DIONAEA_HOME (which is /opt/dionaea), under the etc/dionaea/dionaea.conf configuration file. We can configure dionaea to log the following messages: debug, info, message, warning, critical and error. In the configuration file, there is a “levels” configuration parameter that we can use to specify what dionaea should log. In the configuration file, there are the following sections:
Logging: Specifies what messages we would like to log. By default, we’re logging all messages in the log/dionaea.log and log/dionaea-errors.log. Processors: The actions done on streams when getting attacked. Downloads: A place to download the malicious malware. Bitstreams: A place to download network streams, which can be useful for replaying the attack later when analyzing it. Submit: Where to send files upon receiving them. By default, all the downloaded files are sent to Anubis, Norman and Mannheim’s university. If we don’t want to do that, we should remove the appropriate lines in the submit portion of the configuration file. Listen: The addresses the dionaea will listen on. By default, it listens on all addresses on the computer running dionaea. Modules: Specifies which modules to load and the options for each module. By default the following modules are loaded: curl, emu, pcap, nfq, python and nc. The python module is special as it can load Python scripts, which act as modules. There’s also a services = { … } directive that specifies all the services that will be loaded upon starting the dionaea. By default, the services below are enabled:
[plain] services = { serve = [“http”, “https”, “tftp”, “ftp”, “mirror”, “smb”, “epmap”, “sip”,”mssql”, “mysql”] } [/plain] Each of those services is a special emulated version of a specific vulnerable service. The http module acts as a HTTP server, which uses the $DIONAEA_HOME/var/dionaea/wwwroot/ as DocumentRoot when requesting files.
Starting dionaea
After installation and configuration of dionaea, we can finally start it and start receiving new malware programs. To start dionaea, we need to run the command below: [bash]
/opt/dionaea/bin/dionaea -u nobody -g nogroup -p /opt/dionaea/var/dionaea.pid -D
Dionaea Version 0.1.0 Compiled on Linux/x86 at Sep 18 2012 08:19:02 with gcc 4.5.2 [18092012 09:38:44] dionaea dionaea.c:245: User nobody has uid 65534 [18092012 09:38:44] dionaea dionaea.c:264: Group nogroup has gid 65534 [/bash] Dionaea is now running and will try to intercept the malware software programs. To check out the ports dionaea is listening on, we can run the netstat command: [bash]
netstat -lntup | grep dionaea
tcp 0 0 192.168.1.2:443 0.0.0.0:* LISTEN 13167/dionaea tcp 0 0 127.0.0.1:443 0.0.0.0:* LISTEN 13167/dionaea tcp 0 0 192.168.1.2:445 0.0.0.0:* LISTEN 13167/dionaea tcp 0 0 127.0.0.1:445 0.0.0.0:* LISTEN 13167/dionaea tcp 0 0 192.168.1.2:5060 0.0.0.0:* LISTEN 13167/dionaea tcp 0 0 127.0.0.1:5060 0.0.0.0:* LISTEN 13167/dionaea tcp 0 0 192.168.1.2:5061 0.0.0.0:* LISTEN 13167/dionaea tcp 0 0 127.0.0.1:5061 0.0.0.0:* LISTEN 13167/dionaea tcp 0 0 192.168.1.2:135 0.0.0.0:* LISTEN 13167/dionaea tcp 0 0 127.0.0.1:135 0.0.0.0:* LISTEN 13167/dionaea tcp 0 0 192.168.1.2:3306 0.0.0.0:* LISTEN 13167/dionaea tcp 0 0 192.168.1.2:42 0.0.0.0:* LISTEN 13167/dionaea tcp 0 0 127.0.0.1:42 0.0.0.0:* LISTEN 13167/dionaea tcp 0 0 192.168.1.2:80 0.0.0.0:* LISTEN 13167/dionaea tcp 0 0 127.0.0.1:80 0.0.0.0:* LISTEN 13167/dionaea tcp 0 0 192.168.1.2:21 0.0.0.0:* LISTEN 13167/dionaea tcp 0 0 127.0.0.1:21 0.0.0.0:* LISTEN 13167/dionaea tcp 0 0 192.168.1.2:1433 0.0.0.0:* LISTEN 13167/dionaea tcp 0 0 127.0.0.1:1433 0.0.0.0:* LISTEN 13167/dionaea tcp6 0 0 fe80::20a:cdff:fe05:443 :::* LISTEN 13167/dionaea tcp6 0 0 fe80::20a:cdff:fe05:445 :::* LISTEN 13167/dionaea tcp6 0 0 fe80::20a:cdff:fe0:5060 :::* LISTEN 13167/dionaea tcp6 0 0 fe80::20a:cdff:fe0:5061 :::* LISTEN 13167/dionaea tcp6 0 0 fe80::20a:cdff:fe05:135 :::* LISTEN 13167/dionaea tcp6 0 0 fe80::20a:cdff:fe0:3306 :::* LISTEN 13167/dionaea tcp6 0 0 fe80::20a:cdff:fe05::42 :::* LISTEN 13167/dionaea tcp6 0 0 fe80::20a:cdff:fe05::80 :::* LISTEN 13167/dionaea tcp6 0 0 fe80::20a:cdff:fe05::21 :::* LISTEN 13167/dionaea tcp6 0 0 fe80::20a:cdff:fe0:1433 :::* LISTEN 13167/dionaea [/bash] We can see that dionaea is listening on the same ports but different interfaces. We can change the configuration settings to listen only on interface 192.168.1.2, thus making the services accessible by the outside world. We can also configure dionaea to send updates over the XMPP protocol to enable real-time messaging as events are occurring on the server. The xmpp module is also capable of sending binaries over the xmpp protocol, thus sharing the downloaded malware between multiple users of dionaea.
Conclusion
We’ve seen how we can install and configure two honeypots: nepenthes and dionaea. We’ve looked at what these tools can do: they can download malware binary files, send them to various sharing places including IRC and XMPP chat and more.
