Book Review: 7 Deadliest Web Application Attacks

A while ago I was offered an excellent opportunity to read and review Mike Shema’s contribution to Syngress’s Seven Deadliest series focused on web application security. My first impression was very positive, and now I’ve had a chance to get my hands on the finished product I haven’t been disappointed.
As with the rest of the Seven Deadliest series the book is broken down into sever chapters, each focusing on a key attack vector. Covered in Web Application Attacks is:

  1. Cross-Site Scripting (XSS)
  2. Cross-Site Request Forgery (CSRF)
  3. SQL Injection
  4. Server Misconfiguration and Predictable Pages
  5. Breaking Authentication Schemes
  6. Logic Attacks
  7. Malware and Browser Attacks

I’ll be the first to admit that web application security isn’t my forte. Rather than let that put me off this was the appeal of the Seven Deadliest series, given the target topic the books aim is to succinctly cover the core issues and let the reader quickly get to grips with the subject material. Shema does this brilliantly; before I reading the book I (thought I) was comfortable with my understanding of web application security issues, after reading I’m now confident in both my theoretical understanding and, crucially, the technical implementation of the attack vectors discussed.
While the material is accessible to a new comer to web application security Shema wasn’t able to cover all subjects touched on during the book. For example, character encoding sets are discussed quite heavily during the cross-site scripting, but isn’t explained indepth at a low level. As a result, what a reader is able to take away from the book will likely be dependent on the experience and knowledge that the reader is able to bring to the material. In my case I was more comfortable with the chapters covering server misconfiguration (chapter 4) and malware (chapter 7).
After re-reading the material I would recommend this book to anyone that deals with web sites in anyway (that’s you), especially considering the price of the Severn Deadliest books. I’d also take a look at the rest of the series, covering:

— Andrew Waite
(oh, and if you won’t take my word for it, pay attention to the recommendation on the back….)

“The threats highlighted should be understood by Web developers, administrators, and general users alike. If you use the Web in any way then this should be on your bookshelf. In addition to detailing the threat Shema also provides countermeasures to minimize or remove the risk, but be warned; you may never look at a Web site in the same way again.”
Andrew Waite, Security Researcher, InfoSanity Research

Gain and maintain passion for infosec

I’ve had this post in the back of my mind for a while, but have held back as it is a quite a personal topic. When talking to anyone working in infosec one aspect remains constant from the rockstars at the top of the media game, the guys in the trenches or the newbies looking for a break; that constant is passion. Ultimately passion is what makes the difference between a job and a career, and in a world with the extra curricular requirements, continued professional development and somewhat crazy work hours that are related to the infosec world passion can be easy to lose and the daily grind results in the infamous burn-out. This makes it really important to have a few ways to remind you why you do what you do.
Looking back it’s easy to identify moments of my life that resulted in an interest for information security, even if the consequences weren’t obvious at the time.
Hackers (yes, the film)
Okay, I’ll come out of the closet on this one. When I rented the film this was my first introduction to the ideas of information security and the world of hacking. No, the film isn’t completely accurate, but what do you expect from Hollywood? What the film did do was start a burning desire to learn more, and as a kid geek who didn’t like the idea of being able to pull Miss Jolie with a laptop and elite skillz? As a result I spent the next few years Googling (OK, searching, Google wasn’t around at the time) hacking and reading any number of ‘how to start hacking’ files. Every now and then I still take the DVD from the box and re-watch the film that, for me, started it all. Hack-the-planet…
DooM
While this game was causing controversy at the time it was responsible for my learning computer basics and, in hindsight, the first time I circumvented access controls. The story is thus:
One Christmas (I was 8 ) my family got our first Windows PC (BBC Micro B with tape drive prior to this), after playing around and gaining my MCSE (Minesweeper Champion and Solitaire Expert) I found the icon for this thing called DooM on the desktop, and it was good. When parents spotted me playing it and reacted to the media controversy and removed the game (well the shortcut), a while later I’d found my way around an MS-DOS shell and was executing doom.exe from commandline. This lasted a couple of weeks before I was spotted again; after I was ‘persuaded’ to explain how I was still playing I had to teach my parents how to actually delete programs. Which did nothing but provide the opportunity for me to pick my first lock to get the install floppies from the disk box, but that’s another story.
Where Wizards Stay Up Late
One of many hacking related books I ended up reading in my initial search for information was Where Wizards Stay Up Late. If you’ve not read it the book documents the history of the internet, from the early days of DARPA onwards. For me this book provided the belief that computers could be a valid career path and contrary to my teacher’s belief at the time, not just something that kids play with.  All self-respecting geeks should know the history of their craft and the people that made it possible, so if the names Licklider, Larry Roberts, Frank Heart, Honeywell or BBN mean nothing to you I strongly recommend that you pick a copy of the book up.
Ethical Hacker Network
EH-Net was my first introduction to actually communicating with others doing infosec in the real world. The forums are an excellent source of information, discussion and support, and unlike many ‘hacker’ forums newbies and outsiders will be welcomed and supported as they find their feet rather than being ridiculed and ignored for asking ‘stupid’ questions. The support and discussions I received when I first became an active member of the forums gave me the belief and confidence that I could make an information security career a possibility, and I’ve made some great friends and contacts as a result. My biggest regret at the moment is that I don’t have enough time to be anywhere near as active in the forums as I once was, although I do intend to change this.
The best individual resource on EH-Net that I found for gaining and maintaining my passion for an infosec career is Don’s presentation DIY Career in Ethical Hacking. The slides and audio are here, I strongly suggest you take an hour to listen to the advice Don shares. In my case when I first heard the talk I took Don’s advice and had a serious look at my career and where I wanted to be in a few years; as a result I registered infosanity.co.uk a week later. I still listen to the audio every 6-12 months to ensure I can stay on track. Thanks Don 😀
Conscience of a Hacker (Hackers Manifesto)
Possibly on of the best known piece of ‘hacker’ literature was released in Phrack back in 1986. Written by ‘The Mentor’ aka Loyd Blankenship it provides a unique and hard-hitting explanation of why some hackers are hackers, and for the typically introverted geek can help explain some very deep feelings to those that don’t understand. For a number of years I have owned a copy of the DVD recording of Blankenship’s presentation at 2600’s H2K2 conference and always find it inspirational, the story of a kid that showed his parent’s the article and stated ‘this is how I feel at school’ really highlights the power the article can have. Whether you’re already familiar with the article or haven’t encountered it before I’d suggest both reading the original and listening to Blankenship’s recitation and discussion of the article here[.mp3].
—–
That’s my list; whenever the daily grind starts getting on top I can always count on one of the above resources to remind me why I want a career in infosec, or more importantly why I want to turn my hobby and passion into a career.
If you’ve got similar stories, or additional inspirational resources to share I’d love hear them.
— Andrew Waite

Determining connection source from honeyd.log – cymruwhois version

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

Team Cymru Whois

Since posting my Python whois class it’s lead to a (relatively) high volume of search hits pointing people to it. So I’d like to apologise for inflicting my code on other people. After a recent post with the honey-geoip.py script I was pointed in the direction Team Cymru’s whois service and accompanying python script. If you’ve not come across the stuff released by Team-Cymru I would strongly suggest that you take a look. I always manage to find some interesting new info, three overall sections Monitoring, Services and Reading Room.
Making my life easier, Justin Azoff has released a Python module hosted on github for the whois.cymru.com service. Using the client is incredible simple as the sample code included in the package shows:

>>> import socket
>>> ip = socket.gethostbyname("www.google.com")
>>> from cymruwhois import Client
>>> c=Client()
>>> r=c.lookup(ip)
>>> print r.asn
15169
>>> print r.owner
GOOGLE - Google Inc.

Overall Justin’s client works faster than my own attempt, especially has it has functions specifically designed for bulk lookups. If you’re working with IP, whois or geolocation data I’d suggest giving the cymruwhois utility a look. Thanks to Justin and the Team Cymru people for releasing tools and info that make my work easier.
–Andrew Waite

Digital Security & Governance for SMEs

Yesterday I had the pleasure of attending the Digital Security & Governance for SMEs at Northumbria University. The purpose of the event was to help SMEs better understand that threats targeting their information systems, their responsibilities in securing personally identifiable information (PII) and to introduce NUWARP (more later).
After the event was introduced, the first slot was taken by David Reynolds, CEO of the International Association of Accounts Innovation & Technology Consultants (IAAITC). An accountant may have been a strange choice to start a Digital Security event but that was the point, David covered sensitive information that is handled by all types of businesses as well as covering the legal and regulatory requirements that impact all businesses. Covering the most common compliance topics including the Data Protection Act (DPA) and Payment Card Industry Data Security Standard (PCI DSS) David did an excellent job of highlighting that information security is relevant to all employees and business types, not just ‘IT’ companies or the secret techie hidden in the back corner.
Next up Paul Holborow from RMT discussed data loss and the impact that this can have on a business. Given the press coverage it received in 2007 it is no real surprise that Paul’s main case study focused on Revenue and Customs lost CDs, but Paul may have been slightly unnerved to discover some of HMRC’s auditors could be found in the audience. If you’ve spent much time working with information security or business continuity planning Paul’s talk wouldn’t have contained too many surprises, one tip that I did take from the talk was that the Information Commissioner’s Office (ICO) maintains a public list of the complaints that it has investigated, if you’re interested in a particular complaint, or just curious about what the ICO gets involved in give it a look here.
Phil and Colin, both from the University discussed their work into monitoring data leakage from an organisation. Like Paul’s talk previously if you understand and have worked with data leak prevention (DLP) technologies you’re unlikely to be surprised, but the content was definitely new to some of the delegates who I observer furiously scribbling notes. It also seemed to come as a surprise to several delegates when Phil stated that approximately 70% of security breaches are the result of insider’s not ‘mysterious hackers out there’. There were some excellent real-world examples, the one that seemed to hit home to most of the audience was the scenario of the sales person taking the client database with them to a new job. A lot of the statistics used in the talk were sourced from Cyber-Ark’s white paper ‘The global recession and it’s effect on work ethics’ (registration required), definitely worth a read if you’re interested in this area.
Chris Laing provided a live demo of an external attack. As Chris introduced himself as ‘an ethical hacker paid to break into your systems’ I was looking forward to the display, but was disappointed when Chris took control of a Windows 2000 server using an old MSRPC exploit with Metasploit. The scariest aspect of the whole event was the fact that almost every delegate took a deep breath and turned white. I did ask Chris the thinking behind using an old exploit and target, and was told he was concerned about scaring the audience too much and that some of them may be concerned that he was making exploits ‘known’ that target systems they run in production. Personally I would argue that if the exploit is already in Metasploit (framework 2, demo used WHAX as an attack platform) then it is already ‘known’ and that the demo could have had a much greater impact targeting a more recent platform. However I can understand Chris’ reasoning, and the demo still had an impact on those that hadn’t seen Metasploit at work before. My only concern would be that some may have left the event thinking ‘that was scary, glad we upgraded from Windows 2000….’
The last presentation slot was taken by Alison Pickard who discussed ‘What is effective information crisis management’. Covering the ‘softer’ side of information security Alison’s talk did an excellent job of highlighting how simple it can be for organisations to fall foul of information security regulations. Alison introduced an excellent resource that I wasn’t previously aware of in JISC infoNet. if you’re responsible for personal information or it’s security (stop thinking, after Alison’s presentation this means EVERYONE) I’d definitely recommend have a browse and seeing what you can learn.
To finish the event after scaring most of the delegates Chris again took the stage to introduce the Northumbria University Warning Advice and Reporting Point (NUWARP). For those unfamiliar with WARPs, they are:

‘a community based service where members can receive and share up-to-date advice on information security threats, incidents and solutions.’

I was definitely impressed with the proposed services to be provided by NUWARP, hopefully the group should be able to significantly improve the security awareness and defenses of local businesses and those in a wider area. Although there is a cost attached to the services provide I was honestly surprised with how low this was in relation to the specialised knowledge and information available, and as NUWARP is set-up as a non-profit all costs get fed back into the service so the resources available can only improve.
As a taster and bonus to event delegates the event pack included a number of high quality ‘best practice’ data sheets covering a full range of information security topics including the DPA, passwords and securely outsourcing. If you want additional information on NUWARP contact Chris or Phil using information in the links above, the NUWARP is something I would definitely recommend investigating to see how it could help your organisation.
— Andrew Waite

Quick and Easy Nepenthes installation

I’ve just completed a new Nepenthes installation, and found the process far simpler than my first attempt as I didn’t compile from source.
Running on a Debian 5.0/Lenny server the install was both quick and easy, ‘apt-get install nepenthes’ handles install and dependencies nicely. The only issue I encountered was the permissions of files and directories within /var/log/nepenthes/. The contents had owner and group settings as root:root, as the nepenthes process should (and does under the default init.d script) drop permissions after initialisation this meant that the process was unable write to some of it’s logfiles, reducing the amount and quality of collected information. Thankfully this is easily fixed with a simple ‘chown -R nepenthes:nepenthes /var/log/nepenthes/*’.
I’ve frequently seen complaints/queries on the Nepenthes development mailing list that there are issues with Nepenthes’ hexdump functionality. While it isn’t enabled by default, using this install method works perfectly after uncommenting the “loghexdump.so” line from /etc/nepenthes/nepenthes.conf, depositing collected dumps in /var/lib/nepenthes/hexdumps/.
Initial testing shows the system working nicely (not bad for 30 minutes work) and is beginning to collect new binaries and attack statistics. Next step is some integration with Honeyd to provide the start of a combined honeynet environment, more to come later.
— Andrew Waite

24hrs of HoneyD logs

After an initial setup and configuration of HoneyD I took a snapshot of the honeyd.log file after running for a 24hr period.
Running honeydsum against the log file generated some good overview information. There were over 12000 connections made to the emulated network, averaging one connection every 7 seconds. Despite the volume of connections, each source generally only initiated a handful of connections, likely looking for a single particular service before moving on.

Top 10 Source Hosts
Rank     Source IP       Connections
1    124.207.85.200       3066
2    203.113.137.181      984
3    121.23.82.216           65
4    79.114.107.90          65
5    61.156.31.20             57
6    62.215.178.163        48
7    193.6.48.210            39
8    24.161.18.4               37
9    190.58.213.249       30
10   195.8.36.144          30

The summaries from honeydsum also suggest that the rate of incoming connections is generally constant. The only real variation to this was between 17:00 and 18:00, but the spike coincides with the source IP 124.207.85.200 running an ordered port sweep against a single target IP address, starting at TCP1042 and running up to around TCP 1300. Not sure why anyone is scanning this particular port range (if anyone can provide any additional information to slake my curiosity I’d appreciate it) but this event explains the outliers in both the above and below summary tables, highlighting the dangers of working with a small data set.

Connections per Hour
Hour  Connections
00:00      329
01:00      325
02:00      281
03:00      366
04:00      360
05:00      322
06:00      300
07:00      299
08:00      258
09:00      369
10:00      317
11:00      324
12:00      423
13:00      367
14:00      351
15:00      479
16:00      486
17:00   3590
18:00      498
19:00      515
20:00      576
21:00      441
22:00      397
23:00      311

The below table summarises the targetted resources within the environment. It shouldn’t come as a surprise that the most popular targets were tcp ports 445 and 135, but this is the case even though the honeyd configuration does not have any services listening on those ports. From this I would suggest that if you are trying to gather data on a particular port or service that you employ a filter (firewall/ACL/etc.) to block the noise before it reaches honeyd to keep the log files relevant.

Top 10 Accessed Resources
Rank   Resource    Connections
1           445/tcp         7349
2           135/tcp         1086
3             8/icmp           123
4              22/tcp           102
5            1433/tcp          95
6           8080/tcp          73
7           4899/tcp          52
8           5900/tcp          39
9         10000/tcp         39
10           3/icmp            38

In addition to running honeydsum the data set was run through InfoSanity’s honeyd-geoip.py script, top 10 sources are listed below. The results are likely skewed as the largest ‘location’ for the results is ‘none’ according to the GeoIP Country Lite database being used. One feature of the result set is that the country linked to the public IP addresses used by the honeyd environment did not feature in the list, as infrastructure improves and botnets become more prevalent today’s malware no longer needs to target ‘closer’ IP addresses to remain efficient.

None:   692
United States:  196
Russian Federation:     123
Taiwan: 118
Brazil: 109
Germany:        99
Australia:      99
China:  90
Romania:        86
Italy:  82

— Andrew Waite

Honeydsum: HoneyD log analyser

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

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

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