Archive

Archive for the ‘honeyd’ Category

HoneyD network architecture

I was recently asked about the network configuration I use for my honeyd sensor. I had thought I’d already written about this so initially went to find the article on honeyd configuration; but my memory was wrong and the original post only covered configuring the guest systems, not the honeyd host itself. So, as I now have a pretty(ish) network diagram showing my setup I may as well correct the earlier omission.

<DISCLAIMER: This may not be the best network design for running honeyd, this is merely how my environment is configured and it works for me as a research platform. As usual, your mileage may vary, especially if your use-case differs from my own>

As can be seen, the design has three distinct network segments:

  • Publicly route-able IPs
  • Internal network for honeypot hosts
  • Virtual network for honeyd guest systems. These IP addresses sit on loopback interface on the host, with a static route on the firewall to pass all virtual traffic to the honeyd host.

Using a perimeter firewall with NAT/PAT capabilities allows easy switching between emulated systems and services if your public IP resources are limited; a large network of guests can be configured in advance and left static, then a quick firewall change is all that is required to expose different systems to the world.

Additionally, as much as honeypot systems are designed to be compromised and collect information of malicious attacks (or perhaps more correctly, because of this) , low-interaction systems like honeyd is designed to avoid full compromise. If something goes wrong and the host system gets fully compromised, a (sufficiently configured) perimeter firewall provides some control of outgoing traffic, limiting the attackers options for using the honeypot sensor to attack other systems.

Not much to it really; if you use an different setup and/or can suggest ways to improve the setup let me know, always looking to improve my systems where possible.

— Andrew Waite

Advertisements
Categories: honeyd, Honeypot, InfoSec, Lab

Mercury – Live Honeypot DVD

<UPDATE>Live download mirror: carnivore.it</UPDATE>

Mercury Live DVD was initially (I believe) announced in a post to the Nepenthes Mailing list. It is a remastered Ubuntu distribution with pre-installed honeypot applications and malware analysis tools created by John Moore. From the ReadMe:

This live DVD is a remastered version of Ubuntu 10.0 Beta LTS x86_32. It was designed due to my being disappointed with another reverse engineering malware live CD that was released recently. I have decided to call my creation MERCURY, which is an acronym for Malware Enumeration, Capture, and Reverse Engineering.

The Mercury live DVD contains tools used for digital forensics, data recovery, network monitoring, and spoofing. It should primarily be used as a honeypot or network monitoring platform as well as a laboratory and teaching aid. There are three honeypots installed – honeyd, nepenthes, and dionaea. Four, if you include netcat.

The majority of the additional applications reside in /opt:

  • Dionaea (0.1.0) – Dionaea is a malware collection honeypot focusing primarily on SMB emulation, covered on InfoSanity numerous times before.
  • FFP – Fuzzy Fingerprinting is a util to aid SSH MitM attacks.
  • jsunpack-n – Is a Javascript unpacker, perfect for analysis captured or potentially malicious URLs in more depth.
  • Kippo (svn rev.169) – Kippo is an low-medium interaction SSH honeypot, Also covered
  • mitm-ssh – Unsurprisingly, a utility for aiding man in the middle attacks against SSH connections.
  • Origami & pdftools – Two frameworks for analysing malicious PDF files.
  • Volatility – an excellent memory analysis toolkit
  • Zerowine-vm – A malware behavior analysis platform. I’ve covered ZeroWine here before, and whilst I find it useful for initial analysis I found it a pain to setup and get running. The fact this works out of the box on Mercury is enough reason alone to keep the .iso handy.

Other tools are installed on the system as started, access from standard locations (/etc, /usr/bin, etc.). I won’t try to list them all, but some highlights include:

  • Nepenthes – Dionaea’s predecessor
  • Honeyd – Honeypot system, perfect for emulating multiple different systems from one platform. Covered in more depth here.
  • John – John the Ripper, password cracker
  • ircd-hybrid – irc server daemon, useful for analysis irc-based malware’s interaction with command and control systems.
  • Snort – de-facto intrusion detection system.
  • Wireshark – Packet capture and network analysis tools.

I could go on, but I’m sure you get the idea.

Setting up a honeypot, and analysing the results, has never been easier. And I’m sure the toolkit’s functionality will also be useful in other scenarios; incident response, general network administration or as a safe learning platform. So what are you waiting for?

–Andrew Waite

N.B. there have been several mirror’s and downloads established, the most reliable download source I’ve used is Markus’ mirror at carnivore.it

Determining connection source from honeyd.log – cymruwhois version

2010/05/03 1 comment

InfoSanity’s honeyd-geoip.py script has been useful for analysing the initial findings from a HoneyD installation, but one of weaknesses identified in the geolocation database used by the script was that a large proportion of the source IP addresses connecting to the honeypot environment weren’t none within the database. Markus pointed me in the direction of the cymruwhois (discussed previously)python module as an alternative. I’ve re-written the initial script, below:

#!/usr/bin/python
from cymruwhois import Client
import sys

logfile = open('/var/log/honeypot/honeyd.log', 'r')
source = []
for line in logfile:
    source.append(line.split(' ')[3])

src_country = []
src_count = []
c=Client()

results=c.lookupmany_dict(set(source))

for res in results:
    country = results[res].cc
    try:
        pos = src_country.index( country )
        src_count[pos] += 1
    except:
        src_country.append( country )
        src_count.append( 1 )

for i in range( 0, ( len( src_country ) - 1 ) ):
    sys.stdout.write( "%s:\t%i\n" %( src_country[i], src_count[i] ) )

So far this has resulted in far fewer unknown source locations, 249 using geoip compared to 3 using cymruwhois. The downside unfortunately is performance, the cymruwhois communicates with a remote host to gather information compared with the geolocation database that is already stored locally on the machine. Both perform some local caching of results/data however so I would expect the performane difference to decrease as larger datasets are analysed.

Using the newer script, based on the same 24hr data set, the top ten host countries communicating with InfoSanity’s honeyd environment are:

RU:     397
US:     234
TW:     179
BR:     158
CN:     123
RO:     107
DE:     101
IT:     96
JP:     91
AR:     86

— Andrew Waite

Honeydsum: HoneyD log analyser

2010/04/20 1 comment

Honeydsum is a script created by Lucio Henrique Franco and Carlos Henrique Peixoto Caetano Chaves for the Brazilian Honeynet project. As described by it’s Authors, it is:

a tool written in Perl designed to generate a text summary from Honeyd logs. The summaries may be produced using different parameters as filters, such as ports, protocols, IP addresses or networks. It shows the top source and port access and the number of connections per hour, and supports input from multiple log files. The script can also correlate events from several honeypots.

Using the script from the commandline is straightforward; simple invoke with a config file and pass the honeyd log to be analysed. In addition to the usual textual output honeydsum is also capable of generating HTML results providing a quick and easy visual. The download site also includes some sample output files, both text and html (tgz archive).

$ /usr/share/honeyd/scripts/honeydsum-v0.3/honeydsum.pl

Usage: honeydsum.pl -c honeydsum.conf [-hVw] log-file1 log-file2 … log-filen
-c   honeydsum.conf file.
-h   display this help and exit.
-V   display version number and exit.
-w   display output as web page (HTML).

The bulk of the text based output provides a list of connections made from external sources to the systems emulated by the HoneyD instance. Using the provided sample output as an example provides the information below; on a live and publically accessible system this output will be significantly longer:

--------------------------------------
Honeypot: 10.0.0.70
--------------------------------------
Source IP        Resource  Connections
192.168.50.20        21/tcp       1
192.168.100.130      21/tcp       1
192.168.177.253     11/icmp       1
192.168.139.133     11/icmp       1
--------------------------------------
IPs             Resources  Connections
4                       2        4
--------------------------------------

The end of the output contains the information that I find most useful. It provides several different summaries of all the traffic captured by the whole HoneyD environment. Summaries include:

The most frequent remote sources:

Top 10 Source Hosts

Rank  Source IP       Connections
1      192.168.100.130        3
2      192.168.139.133        2
3      192.168.50.20           1
4      192.168.131.157        1
5      192.168.217.41         1
6      192.168.207.84         1
7      192.168.177.253        1

Most requested emulated services/resources:

Top 10 Accessed Resources

Rank Resource    Connections
1    21/tcp             4
2    11/icmp            4
3    53/udp             2

— Andrew Waite

Categories: honeyd, Honeypot, InfoSec, Tool-Kit

Determining connection source from honeyd.log

After getting a working HoneyD environment I wanted to better dig into the information provided by the system. First up was a quick script to get a feel for where the attacks/connections originate from. For location functionality GeoIP is the package for the job, as we’re using both Debian and Python installing the required tools is as simple as ‘apt-get install python-geoip’.

At first glance I really like the log format that is used by honeyd.log, it is nice an easy to parse from. From this I quickly knocked up a python script to parse the honeyd.log file, collect a list of unique source addresses and finally use GeoIP to determine (and count) the county of origin. The script (below) is basic, and most likely full of bugs but shows the ease with which tools can be forged to quickly gain the full value from the information collected by the HoneyD environment.

Version 0.01 is below; ignoring any likely bugs that need fixing the one thing that it definitely needs is to order the output, although I’m undecided if this should be alphabetically by country or by hit-count. Source Code:

#!/usr/bin/python
import GeoIP
import sys

#log file location hard coded, change to suit environment
logfile = open(‘/var/log/honeypot/honeyd.log’, ‘r’)
source = []
for line in logfile:
source.append(line.split(‘ ‘)[3])

#http://www.maxmind.com/app/python
#http://code.google.com/p/pygeoip/
gi = GeoIP.new(GeoIP.GEOIP_MEMORY_CACHE)

src_country = []
src_count = []
for src in set(source):
country =  gi.country_name_by_addr( src )
try:
pos = src_country.index( country )
src_count[pos] += 1
except:
src_country.append( country )
src_count.append( 1 )

for i in range( 0, ( len( src_country ) – 1 ) ):
sys.stdout.write( “%s:\t%i\n” %( src_country[i], src_count[i] ) )

Sample output:

# ./honeyd-geoip.py
Uruguay: 12
None:   249
Australia:      17
Lithuania:      11
Austria: 4
Russian Federation:     43
Jordan: 3
Taiwan: 29
Hong Kong:      3
Brazil: 39
United States:  54
Hungary: 23
Latvia: 10
Morocco: 1
Macedonia:      3
Serbia: 4
Romania: 44
Argentina:      23
United Kingdom: 12
India:  10
Egypt:  2
Italy:  33
Switzerland:    2
Germany: 43
France: 13
Poland: 27
Canada: 12
China:  23
Malaysia:       8
Panama: 1
Colombia:       6
Japan:  14
Israel: 9
Bulgaria:       9
Turkey: 6
Vietnam: 2
Mexico: 1
Chile:  1
Pakistan:       1
Spain:  7
Portugal:       4
Moldova, Republic of:   1
Antigua and Barbuda:    1
Venezuela:      3
Singapore:      1
United Arab Emirates:   1
Philippines:    2
Croatia: 1
Korea, Republic of:     4
Ukraine: 5
Georgia: 2
Bahamas: 1
Ecuador: 1
South Africa:   1
Peru:   1
Kazakhstan:     2
Costa Rica:     1
Bolivia: 1
Iran, Islamic Republic of:      2
Greece: 1
Bahrain: 1

— Andrew Waite

Categories: honeyd, Honeypot, InfoSec, Tool-Kit

Basic HoneyD configuration

After first getting HoneyD up and running previously for a proof of concept I’ve begun a wider implementation of HoneyD to function as the backbone for an upgraded research environment.

HoneyD’s key strength is it’s flexibility, HoneyD’s website contains some sample configuration files that show HoneyD emulating multiple systems running different OSes and applications, a large multi-site network and even a config file to create a honeypot environment for a wireless network. I’ve found these samples immensely useful references for developing custom templates for my own implementation.

At a bare minimum a HoneyD configuration file requires a defined default template, the current default template for this environment is borrowed from one of the sample files and is a tarpit, designed to slow down network sweeps and automated worms; similar to LaBrea tarpit.

create default
set default personality “Microsoft Windows XP Professional SP1”
set default default tcp action tarpit open
set default default udp action block
set default default icmp action open

HoneyD can emulate both Windows and ‘nix systems (and many less common systems), for initial deployment we’re going with an even mix of Windows and Linux host template, each each with a template for a e-mail, web and development server.

Linux configuration:

# Linux Mail
create linux_mail
set linux_mail personality “Linux 2.4.20”
set linux_mail default tcp action reset
set linux_mail default udp action block
set linux_mail default icmp action open
set linux_mail uptime 73921
add linux_mail tcp port 110 “sh scripts/unix/linux/suse8.0/qpop.sh $ipsrc $sport $ipdst $dport”
add linux_mail tcp port 143 “sh scripts/unix/linux/suse8.0/cyrus-imapd.sh $ipsrc $sport $ipdst $dport”
add linux_mail udp port 161 “perl scripts/unix/linux/suse8.0/fake-snmp.pl public private –config==scripts/unix/general”
bind 10.x.y.x linux_mail

# Linux Web
create linux_web
set linux_web personality “Linux 2.4.20”
set linux_web default tcp action reset
set linux_web default udp action block
set linux_web uptime 13282
add linux_web tcp port 21 “sh scripts/unix/linux/suse8.0/proftpd $ipsrc $spor$ipdst $dport”
add linux_web tcp port 80 “sh scripts/unix/linux/suse8.0/apache.sh $ipsrc $sport $ipdst $dport”
add linux_web udp port 161 “sh scripts/unix/general/snmp/fake-snmp.pl $ipsrc $sport $ipdst $dport”
bind 10.x.y.z linux_web

# Linux Development Box (EVERYTHING installed)
create linux_dev
set linux_dev personality “Linux 2.4.20”
set linux_dev default tcp action reset
set linux_dev default udp action block
set linux_dev default icmp action open
set linux_dev uptime 8324
add linux_dev tcp port 21 “sh scripts/unix/linux/suse8.0/proftpd.sh $ipsrc $sport $ipdst $dport”
add linux_dev tcp port 22 “sh scripts/unix/linux/suse8.0/ssh.sh $ipsrc $sport $ipdst $dport”
add linux_dev tcp port 23 “sh scripts/unix/linux/suse8.0/telnetd.sh $ipsrc $sport $ipdst $dport”
add linux_dev tcp port 25 “sh scripts/unix/linux/suse8.0/sendmail.sh $ipsrc $sport $ipdst $dport”
add linux_dev tcp port 79 “sh scripts/unix/linux/suse8.0/fingerd.sh $ipsrc $sport $ipdst $dport”
add linux_dev tcp port 80 “sh scripts/unix/linux/suse8.0/apache.sh $ipsrc $sport $ipdst $dport”
add linux_dev tcp port 110 “sh scripts/unix/linux/suse8.0/qpop.sh $ipsrc $sport $ipdst $dport”
add linux_dev tcp port 111″perl scripts/unix/general/rpc/bportmapd –proto tcp –host scripts/unix/general/rpc/hosts/debian –srcip $ipsrc –dstip $ipdst –srcport $srcport –dstport $dport –logfile /var/log/honeyd –logall”
add linux_dev tcp port 143 “sh scripts/unix/linux/suse8.0/cyrus-imapd.sh $ipsrc $sport $ipdst $dport”
add linux_dev tcp port 515 “sh scripts/unix/linux/suse8.0/lpd.sh $ipsrc $sport $ipdst $dport”
add linux_dev tcp port 3128 “sh scripts/unix/linux/suse8.0/squid.sh $ipsrc $sport $ipdst $dport”
add linux_dev tcp port 8080 “sh scripts/unix/linux/suse8.0/squid.sh $ipsrc $sport $ipdst $dport”
add linux_dev tcp port 8081 “sh scripts/unix/linux/suse8.0/squid.sh $ipsrc $sport $ipdst $dport”
add linux_dev udp port 53 proxy 24.35.0.12:53
add linux_dev udp port 111″perl scripts/unix/general/rpc/bportmapd –proto udp –host scripts/unix/general/rpc/hosts/debian –srcip $ipsrc –dstip $ipdst –srcport $srcport –dstport $dport –logfile /var/log/honeyd –logall”
add linux_dev udp port 161 “perl scripts/unix/general/snmp/fake-snmp.pl public private –config=scripts/unix/general”
add linux_dev udp port 514 “sh scripts/unix/linux/suse8.0/syslogd.sh $ipsrc $sport $ipdst $dport”
bind 10.x.y.z linux_dev

Windows configuration:

# Windows Mail Server
create win_mail
set win_mail personality “Microsoft Windows Server 2003 Standard Edition”
set win_mail default tcp action reset
set win_mail default udp action block
set win_mail default icmp action open
set win_mail uptime 42256
add win_mail tcp port 25 “sh scripts/win32/win2k/exchange-smtp.sh $ipsrc $sport $ipdst $dport”
add win_mail tcp port 110 “sh scripts/win32/win2k/exchange-pop3.sh $ipsrc $sport $ipdst $dport”
add win_mail tcp port 143 “sh scripts/win32/win2k/exchange-imap.sh $ipsrc $sport $ipdst $dport”
add win_mail udp port 161 “perl scripts/unix/general/snmp/fake-snmp.pl public private –config=scripts/unix/general”
bind 10.x.y.z win_mail

# Windows Web Server
create win_web
set win_web personality “Microsoft Windows Server 2003 Standard Edition”
set win_web default tcp action reset
set win_web default udp action block
set win_web default icmp action open
set win_web uptime 12256
add win_web tcp port 21 “sh scripts/win32/win2k/msftp.sh $ipsrc $sport $ipdst $dport”
add win_web tcp port 80 “sh scripts/win32/win2k/iis.sh $ipsrc $sport $ipdst $dport”
add win_web udp port 161 “perl scripts/unix/general/snmp/fake-snmp.pl public private –config=scripts/unix/general”
bind 10.x.y.z win_web

# Windows ‘Dev’ Server
create win_dev
set win_dev personality “Microsoft Windows Server 2003 Standard Edition”
set win_dev default tcp action reset
set win_dev default udp action block
set win_dev default icmp action open
set win_dev uptime 8826
add win_dev tcp port 21 “sh scripts/win32/win2k/msftp.sh $ipsrc $sport $ipdst $dport”
add win_dev tcp port 25 “sh scripts/win32/win2k/exchange-smtp.sh $ipsrc $sport $ipdst $dport”
add win_dev tcp port 80 “sh scripts/win32/win2k/iis.sh $ipsrc $sport $ipdst $dport”
add win_dev tcp port 110 “sh scripts/win32/win2k/exchange-pop3.sh $ipsrc $sport $ipdst $dport”
add win_dev tcp port 143 “sh scripts/win32/win2k/exchange-imap.sh $ipsrc $sport $ipdst $dport”
add win_dev tcp port 389 “sh scripts/win32/win2k/ldap.sh $ipsrc $sport $ipdst $dport”
add win_dev tcp port 5901 “sh scripts/win32/win2k/vnc.sh $ipsrc $sport $ipdst $dport”
add win_dev udp port 161 “perl scripts/unix/general/snmp/fake-snmp.pl public private –config=scripts/unix/general”
bind 10.x.y.z win_dev

As others have should in the sample configs I’ve linked to above, this config barely scratches the surface of HoneyD’s capabilities but it is sufficient to rapidly get a working honeypot environment working and collecting attack information.

Something that frequently surprises anyone not involved in infosec on a daily basis is the speed at which a newly connected system on the Internet will be targeted by a malicious party. In this case the environment was functioning for under a minute before it received it’s first contact from the outside world, as shown in the timestamps from HoneyD’s log file:

2010-04-17-16:41:09.2549 honeyd log started ——
2010-04-17-16:42:04.9735 tcp(6) – 188.26.75.203 2027 10.3.1.15 445: 48 S [Windows XP SP1]
2010-04-17-16:42:05.4878 tcp(6) – 188.26.75.203 2027 10.3.1.15 445: 48 S [Windows XP SP1]
2010-04-17-16:42:06.0341 tcp(6) – 188.26.75.203 2027 10.3.1.15 445: 48 S [Windows XP SP1]
2010-04-17-16:43:00.3707 tcp(6) – 91.1.250.229 1450 10.3.1.6 445: 64 S [Windows 2000 RFC1323]
2010-04-17-16:43:00.9051 tcp(6) – 91.1.250.229 1450 10.3.1.6 445: 64 S [Windows 2000 RFC1323]
2010-04-17-16:43:01.4310 tcp(6) – 91.1.250.229 1450 10.3.1.6 445: 64 S [Windows 2000 RFC1323]
2010-04-17-16:43:27.1202 tcp(6) – 94.24.134.186 1103 10.3.1.5 445: 48 S [Windows XP SP1]

— Andrew Waite

Categories: honeyd, Honeypot, InfoSec, Lab

Starting with HoneyD

Since reading Virtual Honeypots I’ve been wanting to implement a HoneyD system, developed by Niels Provos. From it’s own site, HoneyD is:

a small daemon that creates virtual hosts on a network. The hosts can be configured to run arbitrary services, and their personality can be adapted so that they appear to be running certain operating systems. Honeyd enables a single host to claim multiple addresses – I have tested up to 65536 – on a LAN for network simulation. Honeyd improves cyber security by providing mechanisms for threat detection and assessment. It also deters adversaries by hiding real systems in the middle of virtual systems.

My initial experience getting HoneyD running was frustration to say the least. Going with Debian to provide a stable OS, the install process should have been as simple as apt-get install honeyd. While keeping upto date with a Debian system can sometimes be difficult, the honeyd package is as current as it gets with version 1.5c.

For reasons that I can’t explain, this didn’t work first (or second) time so I reverted to compiling from source. The process could have been worse, only real stumbling block I hit was a naming clash within Debian’s package names. HoneyD requires the ‘dumb network’ package libdnet, but if you apt-get install libdnet you get Debian’s DECnet libraries. On Debian and deriviates you need libdumbnet1.

HoneyD’s configuration has the ability to get very complex depending on what you are looking to achieve. Thankfully a sample configuration is provided that includes examples of some of the most common configuration directives. Once you’ve got a config sorted (the sample works perfectly for testing), starting the honeyd is simple: honeyd -f /path/to/config-file. There are plenty of other runtime options available, but I haven’t had time to fully experiment with all of them; check the honeyd man pages for more information.

As well as emulating hosts and network topologies, HoneyD can be configured to run what it terms ‘subsystems’. Basically this are scripts that can be used to provide additional functionality on the emulated systems for an attacker/user to interact with. Some basic (and not so basic) subsystems are included with HoneyD. Some additional service emulation scripts that have been contributed to the HoneyD project can be found here. As part of the configuration, HoneyD can also pass specified IP/Ports through to live systems, either more indepth/specialised honeypot system or a full ‘real’ system to combine low and high interaction honeypot.

I’m still bearly scratching the surface of what HoneyD is capable of, and haven’t yet transfered my system to a live network to generate any statistics, but from my reading, research and experimentation I have high expectations.

— Andrew Waite

Categories: honeyd, Honeypot, InfoSec, Lab, Tool-Kit