<<

INTRUSION DETECTION FOR 0-DAY VULNERABILITIES

A thesis submitted to Kent State University in partial fulfillment of the requirements for the degree of Master of Science

By

Nathan Daniel Truhan

August, 2011

Thesis written by

Nathan Daniel Truhan

B.S., Youngstown State University, 2000

M.S., Kent State University, 2011

Approved by

Michael Rothstein, Advisor

John Stalvey, Chair, Department of Computer Science

Timothy Moerland, Dean, College of Arts and Sciences

ii

TABLE OF CONTENTS

CHAPTER 1 BASICS OF INTRUSION DETECTION SYSTEMS ...... 1

1.1 Hackers ...... 1

1.2 Zero-Day Vulnerabilities ...... 2

1.3 What is an Intrusion Detection System ...... 3

1.4 Snort ...... 3

1.5 Operating Systems ...... 4

1.6 Network Layer ...... 4

1.7 Data Collection Network Setup ...... 5

1.8 Common Setup Parameters ...... 5

1.9 First Possible Network Configuration ...... 6

1.10 Primary Network Configuration ...... 8

1.11 Setup Summary ...... 10

CHAPTER 2 HONEYPOT AND SNORT IDS DATA COLLECTION ANALYSIS

SERVER CONFIGURATION ...... 11

2.1 Installation of openSUSE 11.x ...... 11

2.2 Configuring Additional Components ...... 12

2.3 Basic Analysis and Security Engine ...... 13

CHAPTER 3 SNORT INTRUSION DETECTION SERVER CONFIGURATION 14

3.1 Choosing the ...... 14

3.2 Installing openSUSE Linux 11.x for an IDS ...... 15

3.3 Configuring the Network ...... 16

iii

3.4 Installing Snort ...... 17

3.5 Loading the latest Snort rules with Oinkmaster ...... 18

CHAPTER 4 HONEYPOT DECOY SERVER ...... 19

4.1 Why implement a honeypot ...... 19

4.2 Selecting a Honeypot ...... 20

4.3 Argos and QEMU ...... 21

4.4 The Ubuntu 8.04 LTS Honeypot ...... 22

4.5 Alternate XP Honeypot ...... 23

4.6 Configuring Snort to detect a compromised system ...... 23

4.7 Testing the honeypot setup ...... 24

CHAPTER 5 SUMMARY ...... 25

5.1 What this thesis has provided ...... 25

5.2 Detecting vulnerabilities ...... 25

5.3 Results ...... 26

5.4 Contributions ...... 28

5.5 Future work ...... 28

APPENDIX A INSTALLATION OF OPENSUSE 11.X ...... 30

AA Partitioning Options ...... 32

AB User Authentication ...... 36

AC Selecting Additional ...... 37

AD Completing the Installation ...... 38

AE Configuring the Network ...... 41

iv

AF Configuring the ...... 46

APPENDIX B INSTALLING THE MYSQL 5.5 COMMUNITY EDITION

DATABASE SERVER...... 51

BA Downloading the MySQL Server ...... 51

BB Configuring the MySQL Server databases ...... 53

APPENDIX C INSTALLING THE APACHE HTTP SERVER ...... 56

CA Preparing the Apache HTTP Server ...... 57

APPENDIX D CONFIGURING THE SNORT NETWORK ...... 60

DA LIBPCAP and TCPDUMP ...... 62

DB Physical Network Connections ...... 63

DC Testing the network configuration ...... 64

APPENDIX E INSTALLING THE PHP HYPERTEXT PREPROCESSOR ...... 66

APPENDIX F INSTALLING BASIC ANALYSIS AND SECURITY ENGINE

(BASE) ...... 68

FA Installing ADOdb ...... 68

FB Installing Perl Compatible Regular Expressions ...... 69

FC Installing PEAR::Image_Canvas and PEAR::Image_Graph ...... 69

FD Installing PEAR::Mail and PEAR::Mail_Mime ...... 70

FE Basic Analysis and Security Engine Configuration ...... 70

APPENDIX G INSTALLING SNORT PREREQUISITES ...... 73

GA Installing Perl Compatible Regular Expressions ...... 73

GB Installing the libdnet networking library ...... 73

v

GC Installing MySQL 5.5 Client Libraries ...... 74

GD Installing the Snort Data AcQuisition library...... 75

APPENDIX H INSTALLING SNORT ...... 77

HA Configuring Snort ...... 78

HB Preparing the snort.conf file ...... 79

HC Installing the Oinkmaster Snort rule manager ...... 83

HD Disabling Unwanted Rules ...... 85

HE Snort and Network Startup Script ...... 86

APPENDIX I INSTALLING DAMN SMALL LINUX ...... 89

IA Additional Software Dependencies ...... 92

IB Installing a new ...... 93

IC Installing the Simple Directmedia Layer ...... 96

ID Installing Autoconf ...... 97

IE Installing Bridged Networking ...... 97

IF Configuring the honeypot server network ...... 100

APPENDIX J INSTALLING ARGOS AND QEMU ...... 102

JA Installing QEMU ...... 102

JB Installing the KQEMU module ...... 103

JC Installing Argos ...... 104

JD Dealing with Argos Exceptions ...... 105

APPENDIX K INSTALLING THE UBUNTU HONEYPOT ...... 107

KA Configuring and Updating Ubuntu Software ...... 113

vi

KB Configuring the Ubuntu Honeypot ...... 117

APPENDIX L INSTALLING THE WINDOWS XP HONEYPOT ...... 122

LA Fixing Windows Updates and User Security ...... 125

LB Making Administrator login easier with QEMU ...... 127

LC Windows Service Pack Installation ...... 128

LD Securing Windows XP ...... 129

LE Enabling and Disabling Windows system services ...... 131

LF Information Services and file security ...... 132

LG Running the Windows honeypot under Argos ...... 133

APPENDIX M TESTING HONEYPOT CONFIGURATIONS ...... 135

MA Performing a system scan with Nmap ...... 135

MB Checking the system with Nessus ...... 138

MC Using the Metasploit Framework to test known vulnerabilities ...... 140

REFERENCES ...... 144

vii

CHAPTER 1

Basics of Intrusion Detection Systems

Computers have become part of mainstream culture, from desktops and laptops to personal organizers and even phones. They have evolved as the brains behind many devices people may take for granted as part of our everyday life. As these devices integrate further into our culture there will always be people who attempt to exploit this integration by breaking into it for various purposes. These people are commonly referred to today as hackers.

1.1 Hackers

The definition of a hacker, according to the Merriam-Webster dictionary [1] has multiple meanings: A person who is inexperienced or unskilled at a particular activity, an expert at programming and solving problems with a computer, a person who illegally gains access to and possibly tampers with information in a computer system.

With this broad of a definition, people such as Steve Jobs and Bill Gates could be considered hackers; however, the public image of the hacker is that of the one who illegally gains access to a computer system.

The book Honeypots: Tracking Hackers, by Lance Spitzner [2], describes two type of hackers. The first is one who wants to compromise a number of systems no matter who the systems belong to and are often called script kiddies, while the other is one that targets a specific system usually of high value. In this book it also lists types of

1 2

attacks that hackers utilize which include Denial of Service attacks, which cripple systems by overloading them with network traffic and essentially knocking them off of the network; BOTS, or automated tools such as self-propagating worms which are programs written by hackers to automatically search for information on a system, provide access to a system to one or more hackers, and possibly maintain Internet relay chat channel status.

1.2 Zero-Day Vulnerabilities

One such attack that this thesis will address is the zero-day, or commonly abbreviated 0-day, vulnerability which can cause damage as it is unknown what the target of the attack might be when it is first utilized or how to guard against it. 0-day vulnerabilities are those that have just been released and may or may not have a patch against them, some of which may not be known to the vendors for a patch to be created.

This is just one of many variations on this definition which defines the earliest moments that a vulnerability is in a particular state, whether it has just been released, or if it was just discovered by the vendor, such as the definition given by Zero Day Exploits: Holy

Grail Of The Malicious Hacker [3].

Several applications exist to help security analysts find these vulnerabilities. One category of these tools is Intrusion Detection Systems, or IDS, which monitor network traffic for predefined patterns.

3

1.3 What is an Intrusion Detection System

An intrusion detection system, IDS, provides a stack of hardware and software components that listen to all traffic on a hardware network interface card or from a packet capture file and scans each packet looking for predefined patterns, such as a flood of packets, or invalid packet headers which may indicate a problem. It then responds to these patterns in a predetermined matter, from recording the attempt, to warning administrators through or visual alerts. As hackers become more creative in their attacks and begin using exploits that may or may not be known to the environment, these systems will help in analyzing potential threats.

1.4 Snort

The top and main component of the Intrusion Detection System stack is the detection software. There are many IDS systems available, such as appliance based systems from Strata Guard [4], or host-based IDS systems, such as Tripwire [5]; however, one of the most popular of these is open-source Snort [6], Created by Martin

Roesch, and further developed by SOURCEfire [7]. It has become a de facto standard for intrusion detection and is also included as a core component in some advanced commercial offerings, such as Strata Gard from StillSecure. Snort is available as a free downloadable version; through software subscription, which gives the most cutting-edge rules and access to the SOURCEfire Vulnerability Research Team (VRT); and specialized hardware appliances.

According to the Snort web site [6], as of the publishing date, the Snort IDS product has nearly 4 million downloads and approximately 300,000 active users. This

4

provides for a highly active Snort community which this thesis will build upon by leveraging the Snort IDS and the creation of community products that collaborate off the core functionality of Snort in order to search for new exploits on the network.

1.5 Operating Systems

The next layer under the intrusion detection software is the operating system.

There are many options of operating systems that can be used in an IDS configuration.

For this thesis, open source products are the focus, so a Linux would provide the best fit.

In particular, openSUSE Linux [8] will be used for this purpose. It is a trusted and easy to use system that provides the flexibility needed in setting up our environment.

Performing this installation will be described when configuring the honeypot and Snort

IDS data collection and analysis server.

1.6 Network Layer

The network layer on the intrusion detection system is comprised of a network card and the operating system to read data received over a transmission medium, usually

Category 5 Ethernet cable. In most cases, if data is not destined for a network card, the network card reads the header of the incoming data and ignores the rest since it does not belong. When an IDS is installed, the network is placed in a special state called promiscuous mode, which overrides this behavior and reads all data on the network.

Without this core functionality, monitoring network traffic would be much more difficult.

5

At the bottom of the network layer is the network infrastructure. This is comprised of routers, switches, transmission medium and other equipment that route packets on the Internet which will be described in the next section.

1.7 Data Collection Network Setup

There are many possible combinations to setup a network used for data collection, ranging from one creating a flat network with both production and research systems on the same logical network, all the way up to having each system residing on its own logical network loosely connected together using hubs and switches.

1.8 Common Setup Parameters

For the data collection setup used in this thesis, it came down to two possible combinations of network setups. Both combinations share some commonality. First, each splits the network into two subnets, 192.168.1.x and 192.168.2.x. Having this split protects other non-honeypot systems that are used on the network and allows them to be separate and more secure rather than placing them on the same subnet as the honeypot.

The first router, which establishes the 192.168.1.x network, is directly connected to the

Internet via a cable modem and also establishes the demilitarized zone, DMZ, which allows the honeypot to be exposed outside the network so it will become the target or bait for potential attacks.

The second router, which establishes the 192.168.2.x network, uses the

192.168.1.x network to forward packets out to the Internet to allow access for the systems inside this network. However, having established a firewall on this router allows these

6

systems to be protected against port scans and other vulnerability testing that may occur from the Internet. The 192.168.2.x network also opens up secured wireless access for laptops and other systems that may need to utilize it.

1.9 First Possible Network Configuration

Even though there are a lot of similarities in the two configurations, there are differences that can be noted. The first network, shown in (Figure 1), starts by placing the honeypot in the DMZ. Then it places the database and IDS servers on one physical system and places that system in line between the honeypot and router.

Figure 1 Straight-through Network Setup

With this configuration, the IDS listens to all data coming through two network connections which are tied together in a bridge configuration, where neither network card has an IP address and all packets are routed through the database and IDS system to the

7

honeypot server without being detected. For the database server, a third network card can be placed in the database server to retrieve information from the honeypot if it is compromised.

In order to better manage each system, a fourth network card needs to be placed in the database server to allow a client from the internal network to attach and retrieve data safely without exposing the internal network to the honeypot. Through this interface both the IDS and databases can be managed.

It is also be possible to manage the honeypot‟s physical machine; however this would involve assigning an IP address to the third network card, which is used to communicate with the honeypot. By assigning this IP the database system and the internal network could possibly be exposed to attack if the honeypot physical host is compromised through the guest by some unknown means.

This initial network configuration allows the consolidation of the database and

IDS onto one physical system, therefore eliminating need for a third machine. It also allows the IDS to be hidden while monitoring the connection since the server is placed in line on the network. However, one downfall with this is the inconvenience of the added configuration of having four network cards and establishing a bridge between two of them. Another downside to this system involves having both the database and IDS on one physical system presenting the dilemma of requiring a more powerful system to handle the load, as well as exposing both systems if the honeypot is compromised as they share one management interface to the honeypot.

8

1.10 Primary Network Configuration

In the second network configuration, which will be used for data collection and analysis in this thesis, shown in (Figure 2), the database and intrusion detection system are separated onto two physical systems. This configuration places the hub in a higher configuration off of the 192.168.1.x network and directly connects the honeypot and IDS to this hub. The IDS can be placed into a passive promiscuous mode, whereas an IP address is not assigned to the interface but it can still receive packets and therefore does not have a direct presence on the 192.168.1.x network.

Figure 2 Distributed Network Configuration

In this configuration, the database and IDS systems have been separated, therefore the fourth network card can be removed from the database server that was added in the

9

first network configuration, shown above, simplifying the configuration of the database server. Also, the database server does not have to be directly connected to the

192.168.1.x, therefore making it less prone to be detected by a port scan. Since it is not connected to the 192.168.1.x network, the database server will be connected to the

192.168.2.x network for management and directly to the IDS and the honeypot systems through individual network connections. This separation prevents exposure of one system to the other.

The honeypot system is similar to the first network, with minor modification to network cable connections. Instead of a direct connection between the honeypot and database server, a hub has been placed between the router and honeypot server, providing some obscurity for the network by broadcasting packets to all systems on the hub. The direct connection between the honeypot and database server still exists for management, which could cause problems once the honeypot is compromised. In this situation, the firewall on the database must be configured and working properly on the exposed interface as to be transparent to the rest of the network.

This configuration has the benefit of being easier to configure each system and having less visibility on the exposed 192.168.1.x network. It also separates the database and IDS, allowing the use of less powerful commodity systems in the configuration and providing some obscurity on the network.

This configuration, however, does have some downsides. First, there are more physical systems connected to the network creating a larger attack footprint though this can be mitigated by removing some IP addresses and placing the systems in a passive

10

sniffing mode. Another significant downside is that when running the IDS, not only packets from the honeypot will be captured, but also any traffic coming into and out from the internal 192.168.2.x network, which could place a burden on that server, however, this is somewhat negligible since the IDS is the only application running on the machine.

Lastly, since the honeypot is directly connected to the hub, it cannot be regulated as though it was running through the bridge. If compromised, the honeypot could be placed into a sniffing mode by the hacker and pick up the 192.168.2.x network traffic, such as windows file share broadcasts which are sent to all nodes on the network.

However, once a compromise is detected, or erroneous data can be seen, the DMZ can be severed which will lock out the intruder.

1.11 Setup Summary

Even though there are numerous possibilities to configure an intrusion detection and honeypot system, two have been demonstrated. In the first configuration, a larger machine would be needed for the database and intrusion detection server along with additional network overhead; however one machine can be eliminated completely. On the contrary, in the second configuration, even though an extra machine is required, the machines can be smaller in size and a simplified network infrastructure is required, therefore may not be as expensive to purchase or maintain.

As this thesis will mostly concentrate on freely available open-source software, with the exception of a Windows XP honeypot, a simplified infrastructure is best suited to demonstrate this; therefore the second network setup option will be utilized.

CHAPTER 2

Honeypot and Snort IDS Data Collection Analysis Server Configuration

2.1 Installation of openSUSE Linux 11.x

The first of the three servers presented in the second network configuration above to be configured is the Data Collection Analysis Server, or database server. In order to analyze the data collected from the Snort intrusion detection and the honeypot system, data needs to be migrated off of those machines in real time without the knowledge of the attacker. For the Snort intrusion detection system, this is fairly easy as that system does not act directly with the attacker, but monitor their activity. However it may still be possible to detect this system and attack it if it has a presence on the network. For the honeypot system that has been compromised, any information that has been stored on the machine cannot be trusted and therefore needs to be exported to another server to analyze.

Since the Snort and honeypot machines are directly connected to the exposed external subnet, they need to be controlled without miscellaneous traffic being sent on the insecure network. The database server can also perform this task since both machines are connected directly to this server though cross-over cables which gives a central point to control both machines without directly compromising any other machines on the network.

11 12

To install the Data Collection Analysis Server, openSUSE Linux 11.x [8] will be used. This distribution was chosen because it is a well-known and trusted distribution, and has a large user base. This distribution also features the YaST configuration tool, which provides a menu or GUI interface depending on system initialization mode to all common configuration elements, such as networking, firewall protection and updates. To install openSUSE 11.x, see APPENDIX A, Installation of openSUSE 11.x.

2.2 Configuring Additional Components

Whether the first or second network configuration presented in the previous section is used, one of the systems must be configured as the database server. In the first network, this server is combined with the Snort intrusion detection server to provide a transparent interface. In the second, the database and intrusion detection systems are split. Even though these two configurations differ, they both require the same database configuration. To implement this database, the latest stable version in the 5.5 series of the MySQL Community Edition [9] will be installed using the instructions in

APPENDIX B, Installing the MySQL 5.5 Community Edition database server.

After MySQL is installed, in order to monitor the activity that will be produced by

Snort, a web server will be needed to correlate the data and present that data in a meaningful way. To enable this, the Apache HTTP Server [10] will be installed to prepare for the Snort web console. This can be installed using APPENDIX C, Installing the Apache HTTP Server. Finally, in order to use the web based management tools for

Snort, the PHP Hypertext Processor [11], will need to be installed. This software allows the execution of common gateway interface scripts written in PHP, usually denoted with

13

a . file extension, to be executed by Apache. This can be installed using APPENDIX

E, Installing the PHP Hypertext Preprocessor.

2.3 Basic Analysis and Security Engine

The Basic Analysis and Security Engine [12] provides a web-based, PHP management interface into detecting and analyzing Snort information that has been collected in the Snort MySQL database that was setup earlier. Once the previous components have been installed and configured, install BASE from APPENDIX F,

Installing Basic Analysis and Security Engine (BASE).

CHAPTER 3

Snort Intrusion Detection Server Configuration

3.1 Choosing the Operating System

The Snort Intrusion Detection System (IDS) [6], is the most widely used and deployed IDS system in the world and has one of the largest support bases of open source products. It sports a large set of features rivaling and in some cases surpassing other commercial options. It can also be installed on a wide range of system architectures which include, but are not limited to, Linux, BSD, Solaris and Windows.

There are benefits and drawbacks of installing Snort on a specific architecture.

The Microsoft Windows family of operating systems is the most used systems across the world. However, because of this, they are also the most attacked as well. Snort has the ability to be installed on this system; however, due to insecurities the operating system presents, and performance degradation that the unneeded incurs as installed on most versions, this architecture's installation falls beyond the scope of this thesis.

The Linux operating system, which is the primary option used in this paper, can provide significant performance gains over other systems such as Windows, especially once the systems are stripped to the bare minimum. With Linux, this means the removal of the graphical user interface, which cannot be done in most versions of Windows, and disabling as many services as possible to keep the system functional.

14 15

Another option would be to use an open source BSD UNIX system, such as

FreeBSD[13]. BSD systems are similar in nature to Linux but are still different enough to be distinguished here. BSD, or Berkeley UNIX, developed by the Computer Systems

Research Group at the University of California, Berkeley, is built as a complete system.

Linux, in comparison, is comprised of a kernel, open source GNU utilities [14], along with additional applications which all make up smaller disparate components. With this configuration, a Linux system can resemble a Bell Labs System V UNIX platform as the utilities have been written to behave like their System V counterparts. As such, and presented in the book Snort 2.1 Intrusion Detection Second Edition [15], it was shown that the leading reason that users choose to use Linux over BSD for installations is the support and user base.

3.2 Installing openSUSE Linux 11.x for an IDS

Chapter 2 and APPENDIX A discusses installing and configuring openSUSE

Linux 11.x [8] as a database server. The Snort IDS installation, utilizing openSUSE, will similarly apply here with some minor differences.

Earlier, two network configurations were shown as possible options for the Snort

IDS. Throughout this thesis the second of these configurations has been chosen. In this setup, Snort does not have a direct connection to the outside world. The interface that is exposed to the 192.168.1.0 network will not have an external IP address to help deter detection from an attacker. Because of this, the system will fail to download any system updates if done before the network configuration has been completed. Network

16

connectivity can be established by using the database server as a gateway to forward packets to the primary network.

When the installation prompts for user authentication, as this system is isolated from others, it also needs to be configured with the default local method. Because this is the intrusion detection server that will be running Snort, the user name of “snort” has been chosen. This name does not have to be used; however, it will appear throughout the rest of this installation and configuration. As previously with the database server, once you establish a user, enter a strong password so that in the event that other systems on the network are compromised it will be difficult to compromise this system.

3.3 Configuring the Network

A receive-only network cable will be made so that the system will not respond to unsolicited ARP requests. This variation is the Gomez [16] Model C Receive-only cable.

In this model, the transmit pair are cut from one end of the cable, while the receive pair is tapped into the transmit pair, creating a loop-back and will cause feedback to scramble the signal. This is to further protect the 192.168.1.0 external network, in the event the interface has been discovered.

The only connection to the outside world is to our database server as a gateway through the 172.20.0.0 network. This network has been chosen as one of three available ranges of non-routable IP addresses [17] and corresponds to the same network chosen to read IDS data on our database server. In order to reach the outside network to perform updates, our IDS server will have to route through the database server. Follow the steps in APPENDIX D, Configuring the Snort Network to complete the network setup.

17

3.4 Installing Snort

Using modified directions obtained from Snort Cookbook [18] and Snort

Enterprise Install [19] the Snort Intrusion Detection System [6] can be installed. Snort has multiple stable versions that are currently supported and for this thesis the 2.9.0.3 version will be used. Snort also offers a bleeding-edge beta version, which can be unstable and produce undesirable results.

Although using the latest stable version is usually most desirable, sometimes this is not feasible. For example, at the time of writing, community and unregistered rules were only available up to snort version 2.4. After this version, Snort requires you to register, which is still a free recommended registration and will be shown in this thesis.

The registered rules allow downloads of rules that are at least 30 days old. One downside of the registered version is that delays may occur while upgrading to a new revision of the Snort software, such as going from 2.8 to 2.9 or 3.0 as rules may take months to appear for registered users after the new version of snort has been released.

The last option to consider for obtaining rules is to subscribe to Snort. This option allows the subscriber to download the latest rule set and includes the most current version as it is released instead of being months behind. The subscriber rules also include the latest rule changes and more thorough testing of the rules which are more up to date than the registered rules; however, this comes at a cost. At the time of writing, a one year home use or educational license was $29.99 for one sensor which is relatively inexpensive and sufficient for implementing this configuration in a home environment.

Other tiers are also available for businesses and integrators.

18

For this thesis, although other previous versions may work from what has been decided above, the latest stable version with an educational subscription will be used.

3.5 Loading the latest Snort rules with Oinkmaster

One of the most important parts of Snort is its rules engine. Without this, Snort would not know how to process a packet and what patterns to match. As mentioned before, Snort offers three levels of rules, Community and Unregistered, Registered, and

Subscriber. Regular releases of rules are done for Subscribers first, and then they filter their way down to registered users at least month later, then down to the unregistered users only when a new snort version is released. Minimally, a registered rule set is needed as it may not be the latest version, but still is somewhat up to date. There are also other rule sets for Emerging Threats [20] which provide newly released vulnerabilities, although these are not covered by Snort‟s support team. To automate the retrieval of these rules, and to be able to access them without your username and password each time they are needed, Snort has worked to develop a Perl script known as Oinkmaster [21].

Instructions to install and configure this script can be found in APPENDIX HC, Installing the Oinkmaster Snort rule manager.

CHAPTER 4

Honeypot Decoy Server

4.1 Why implement a honeypot

A honeypot is a system that is setup on your network as either a complete system or virtual machine that performs a specific function, such as a web or mail server. The purpose of this machine is to act as a decoy from other machines on your network and to lure potential hackers with the hope of tracking their activity. It is closely monitored for break-ins and is used to analyze the movement of hackers inside a compromised system

[22].

Most attacks occur, and succeed, due to known vulnerabilities in applications and operating systems. For example, as of this writing, Microsoft's Windows XP Professional operating system contained 41 known vulnerabilities that have been recorded and cataloged by the SecurityFocus Vulnerability Database [23] alone against Service Pack 2, which purportedly overhauled Windows with a focus on security. This was released in

August, 2004 and Service Pack 3 which back ported security features from Windows

Vista and was released on May 6th, 2008. Another example is Microsoft Windows Vista, released on January 30th, 2007 to consumers, with Service Pack 1 issued on March 18th,

2008, with already 36 known vulnerabilities posted to SecurityFocus. Nevertheless, there are attacks which alert administrators to new vulnerabilities which may not have been

19 20

currently recorded or fixed. With a honeypot, new vulnerabilities can be uncovered or existing vulnerabilities tested without the fear of losing sensitive information [22].

4.2 Selecting a Honeypot

Honeypots are traditionally low-interaction systems; they provide the emulated operating system and/or services, and reside to lure hackers away from production systems. Newer generations of honeypots, expand on this by performing high-interaction systems that not only provide the systems but also provide extensive logging capabilities.

There are many packages, both open-source freeware, such as Honeyd [24], Sebek [25], the LaBrea Tarpit [26] and Argos [27]; to commercial applications, such as Symantec's

Decoy Server [28], and SPECTER [29].

These systems are implemented in many different ways, from running as a separate process on a system, to integrating into the kernel of a machine to record its activities to finally sitting beneath a guest operating system to record all activity. There are also many methodologies on how to implement the honeypot in an environment. One is to create an exact duplicate of a production system and place it in a vulnerable position to test the security of existing systems while another is to create a new fully patched system to draw out new attacks against vulnerable systems. The second is the approach that will be taken in this thesis along with using Argos to monitor and record malicious activity of this system while it is hosted as a guest.

Other systems in this thesis are based off of openSUSE Linux 11.x [8].

Therefore, in order to keep some ambiguity in the structure, the guest system will be based off of Ubuntu [30]. This distribution is similar to other systems in that it is based

21

on the Linux kernel. However, Ubuntu differs from openSUSE with its system management, package management, and other aspects that will differentiate the system enough to make it more difficult to compromise other systems on the network even if this system is compromised.

One of the many benefits of Linux is that it comes packaged in many various forms. There are large distributions such as openSUSE, and Ubuntu; as well as smaller, more specialized distributions, such as KNOPPIX [31], which is a well-known version that can be run from the CD or DVD without installing or it can be installed like other distributions after it has been evaluated, to M0n0wall [32], a specialized firewall distribution that enables the computer to act as a network firewall.

Another of these specialized distributions, which will be utilized for the honeypot is called Damn Small Linux [33], DSL, which is based off of KNOPPIX above, however the primary goal of DSL is its size and resource utilization. The CD has less than a

50MB footprint and it can run in as little as a 486DX computer with 16MB of RAM.

Even with this small footprint it still provides the graphical interface and management utilities needed to run the Argos guest system with taking only very minimal resources from them. To install DSL, see APPENDIX I, Installing Damn Small Linux.

4.3 Argos and QEMU

The Argos project has been selected for its abstraction layer between the host system and the guest system and for providing monitoring of that abstraction layer via an extension of the QEMU [34] virtual machine emulator. Using Argos does not expose the underlying system to an attack and does not require explicit modifications to the host

22

system such as adding a kernel module as in the case of Sebek [25]. Instead, it reads the guest system and uses taint analysis, meaning Argos tracks what happens to data coming from the outside to detect flow control and arbitrary execution attacks. It then correlates that information with network traces to generate information used to detect the attack and generate rules that can be used inside the intrusion detection system to prevent a similar attack from occurring.

The network configuration in QEMU will be configured for one network card in a tunnel configuration creating a pass-through of the guest directly to the physical network card. The hacker may be able to determine that he or she is inside a virtual machine, but will not be able to detect the physical underlying Argos analysis system directly.

4.4 The Ubuntu 8.04 LTS Honeypot

As previously mentioned, utilizing Argos as the honeypot splits the system into a host and guest. The host provides the physical resources of the system and the guest runs inside Argos and provides the virtual image for the system. The guest honeypot system utilized for this thesis will utilize the Ubuntu 8.04 Long Term Supported Linux [30] system. At the time of writing, Ubuntu 9.10 was just released, however, Ubuntu supports

2 versions: a more frequently updated version which is released approximately every half year, and a long term supported version which is released every year and a half and is more stabilized and tested. For this thesis, the alternate text-based install of the long term supported, or LTS version will be used as it provides a robust and stable Linux operating system that also touts the backing of corporate sponsorship and is now deployed by major computer vendors to users in home environments, making it a good example of what a

23

delivered home Linux system would look like. Follow the instructions in APPENDIX I,

Installing Damn Small Linux to install the honeypot.

4.5 Alternate Microsoft Windows XP Honeypot

Although this thesis has focused on all open source systems, they may prove to be fruitless in finding vulnerabilities as opposed to commercial systems. Open source projects and systems can be more flexible and therefore patches are released earlier than their commercial counterparts, sometimes the same day the vulnerability comes out in a testing repository, and can be applied immediately. To achieve the desired level of vulnerability, a system that can be exploited easier should also be installed if possible to test the setup. In this thesis, the alternate commercial operating system used as an example is Microsoft Windows XP [35].

As the installation of the Ubuntu honeypot was covered in APPENDIX K, it is assumed that all preliminary configurations have been completed. Follow the instructions in APPENDIX L, Installing the Windows XP Honeypot to complete the honeypot installation.

4.6 Configuring Snort to detect a compromised system

In the Ubuntu Linux honeypot configuration, http, , ssh and smb was enabled and configured. The Windows honeypot includes the service list for the Linux honeypot and also adds 3389 for terminal services, and 1025 IIS administrative functions on this server, therefore the port list should include ports 22, 23, 25, 80, 111,139, 443,

445, 1025 and 3389 to cover both honeypot configurations. All of these ports are valid

24

ports that will be monitored, however it may be possible for a system to be compromised on a non-standard service, such as ftp, or application that was installed by an attacker which will listen and respond on another port. A general rule would need to be created to handle this for these ports for any established outbound connection. To do this, a Snort rule can be created to utilize this variable. On the Snort server, in the local.rules file, add the following rule: alert tcp $HOME_NET ![22,23,25,80,111,139,443,445,1025,3389] -> $EXTERNAL_NET any (msg:"OUTBOUND CONNECTION ON UNKOWN PORT";flow:established, from_server; dsize:>1; sid:1000001;)

According to Snort rule logic, the rule above would cause an alert on tcp on any traffic from the $HOME_NET network which was defined earlier, not in any of the ports listed between []. It then only looks at outbound packets to the $EXTERNAL_NET on any port that has completed an established 3-way tcp handshake and is coming from the server. Finally, it only fires on packets that contain data therefore the initial connection before data is sent and the tear down is not logged, but the actual data is logged. It is logged to the snort database with the message OUTBOUND CONNECTION ON

UNKNOWN PORT with an id of 1000001.

4.7 Testing the honeypot setup

Once the Intrusion Detection setup is running and has been configured, it can be tested and tied together. Although there are many tools available for testing the feasibility of this infrastructure, three will be utilized. These include Nmap [36] by insecure.org,

Nessus [37] by Tenable and the Metasploit Framework [38] by Rapid7. See APPENDIX

M, Testing honeypot configurations for instructions on running these tests.

CHAPTER 5

Summary

5.1 What this thesis has provided

This thesis has focused on presenting why systems are targeted for attack and some types of attacks that are utilized by hackers. With this background, it then proceeded to demonstrate how these attacks can be detected utilizing an Intrusion

Detection System and Honeypot as well as how to install one particular set of systems called Snort and Argos and the infrastructure for which it supports.

The intrusion detection architecture described allows an analyst to monitor a vulnerable Honeypot system that is prone for attack for a series of known vulnerabilities or 0-day vulnerabilities utilizing known and customized Snort rules and the BASE web- based monitoring tool.

5.2 Detecting vulnerabilities

Even though an emphasis was placed setting up a current system which is configured with known rules for known vulnerabilities, there are two other options for detecting vulnerabilities. The first is the an extension of the known vulnerabilities rules logic, known as the emerging threats rules, which were previously mentioned and can provide some rules close to zero-day status. The second method is more intricate and provides a further level of granularity which is to generate individual rules by hand from scratch. 25 26

The Snort rules engine provides a flexible and powerful system to build alerts based off of numerous combinations of information that is stored in low level network packet information. As the system analyzes this information it can infer if any known malicious activity is occurring from one or many packets of data and fire an alert which will then be captured and recorded by the BASE system. On example of these rules was presented earlier in section 4.6, Configuring Snort to detect a compromised system, which was configured to detect any activity on any specified port.

5.3 Results

A specific vulnerability that was sought for in this thesis was the zero-day vulnerability, which is a vulnerability that has just been released and may or may not have a patch against them, some of which may not be known to the vendors for a patch to be created.

Utilizing the intrusion detection architecture described in this thesis along with the official Snort.org rule set as well as the additional emerging threats rule sets results in a system that will detect known patterns in traffic as it reaches the honeypot guest. The down-side to this approach is that only known vulnerabilities are found, leaving a window of new zero-day vulnerabilities, sometimes as low as a few hours through the frequent updates of the emerging threats. It is this final window that needs addressed.

The approach taken by this thesis has been to describe snort rules and add an additional generic rule to fire on any traffic to the known service ports that are running on the honeypot which was presented in the section, Configuring Snort to detect a compromised system. This will allow the BASE monitoring system to not only capture

27

known vulnerabilities but also capture traffic that may be unknown to the system on unknown ports, if the defined outbound vulnerability rule fires by itself, then an assumption can be made that malicious activity may be taking place and further investigation needs to begin.

When analyzing the data from the Snort and BASE systems, outlier data such as numerous inbound packets in a short time frame or outbound traffic that was unsolicited or is on an unknown port, may represent a new attack. This analysis has been performed over a period of a number of months alternating periods from both the Ubuntu and

Windows XP honeypots. An example of this is that in the last 24 hours of this setup, there were over 25 unique alerts from over 300 unique ip addresses that were fired ranging from port scans to invalid ftp access attempts on the Ubuntu honeypot and malformed packets trying to access the http servers (Figure 3).

Figure 3

28

With these findings, 0-day vulnerability testing in this setup is inconclusive as the system was able to combat the threats through the latest patches and the code injections performed by the Argos emulator to block potential threats. Further analysis with different types of honeypots as well as different types of vulnerabilities could provide the desired results.

5.4 Contributions

This thesis has shown one method for implementing an intrusion detection and honeypot architecture that has provided results for known vulnerabilities. There are other projects that are similar in nature to this setup, such as the Honeywall CDROM [39].

This project provides the data collection and intrusion detection system in a pre-packaged deployment that is tightly integrated in a custom management interface called Walleye.

Although this project could have been chosen, the core operating system has not been updated since 2009 and it only provides two of the three layers that are required.

The contribution this architecture provides is that unlike other projects, not only does it provide the basis and an example for implementing an intrusion detection and honeypot system, but is open enough that components can be interchanged and the functionality remain intact, such as the operating system or database that is utilized.

5.5 Future work

Although 0-day vulnerabilities have not been discovered, changes in the infrastructure, such as implementing the first network configuration for the data

29

collection and intrusion detection servers, resembling the Honeywall CDROM project, would lead to a more efficient hardware architecture for capturing system activity.

One avenue of research would be to implement functionality into the services of the existing honeypot. An example of this would be to install the Joomla! [40] portal server or add files to the file shares that are enticing to an attacker. Other avenues of research include implementing emulated services, such as those provided by the Honeyd project [24] or a complete virtual operating stack, such as one provided by the Labrea

Tarpit [26].

One final avenue of research with the existing infrastructure would be to remove

Argos and utilize a physical honeypot server. This would allow attacks to occur that detect if they are running inside a virtual machine; however, if an attack succeeds and is destructive to the system, the honeypot may need to be rebuilt.

APPENDIX A

Installation of openSUSE 11.x

To begin the installation of openSUSE Linux 11.x, place the DVD into the drive and reboot the computer. If a copy of openSUSE Linux 11.x is not readily available, it can be downloaded from the openSUSE [8] web site and comes in 1 DVD or 5 CD's packaged as ISO images. For this installation, the DVD will be used. Once the system reboots, the boot menu (Figure 4) will be presented. Select Installation and press Enter.

Figure 4

30 31

Next, the system will load the graphical installation program, prompt for the language, keyboard layout and will display the license agreement. Once the license agreement has been accepted and the language and keyboard selected select Next. The installation will detect system hardware and optionally prompt to confirm driver activations; if the system prompts for these activations, choose OK. Next, the installation will prompt for the Installation Mode. Choose the default of New Installation and choose Next. The third step in the installation is to choose the correct time zone appropriately and click Next.

After the time zone has been set, the system will prompt for the desktop selection.

Since text-based utilities will be used and logging into the server locally will be minimized, to improve performance, a text-based system install will be used to eliminate the overhead of the X-Windows GUI system. This will make the system inherently more secure and allow for greater performance while processing large amounts of data. On the

Desktop Selection, choose Other, then Minimal Server Selection (Text Mode) (Figure 5) and click Next.

32

Figure 5

AA Partitioning Options

Once the desktop has been chosen, the installation will ask for Suggested

Partitioning options. Since this will be a simplified setup with a smaller overhead, a

Partition Based setup will be used, however, changes need to be made to the default selections. To begin, make sure Partition Based is selected and then click Edit Partition

Setup to start the Expert Partitioner (Figure 6).

33

Figure 6

If there are existing partitions defined, they are numbered, fall under the entry for the hard disk itself, and need to be deleted. This can be done by expanding the Hard

Disks menu on the left, selecting the disk that contains the partitions to be used on the system, highlighting the partition to delete and clicking on Delete. For example, in the test installation, from a new install on the test system, the physical drive is /dev/hda, which contains the partitions /dev/hda1, /dev/hda2 and /dev/hda3. Once the partitions have been deleted, under the same hard drive click Add, then choose Primary Partition from the Add Partition screen and choose Next.

When creating the partitions of the system, the technician‟s general rule in any system is to give one and a half to two times the amount of swap space than that of

34

physical memory. Using this methodology, a swap space partition would be resized to

768MB or 1 GB since the test system has 512 MB of RAM.

When the New Partition Size menu appears, click the Custom Size radio button, then enter 1 GB in the Custom Size text box (Figure 7); finally click Next. On the last screen of Add Partition, select Swap in the File system under Format Partition and swap under the Mount partition (Figure 8), then click Finish. The new partition that was created should now be listed under its corresponding drive.

Figure 7

35

Figure 8

Next, a decision needs to be made on what file system will be used on the primary data partition. Linux offers many formats for partitioning, each with different feature sets. Since this server will be a data collection server, hosting MySQL Server [9] as the database of choice, a file system that can balance speed with journaling capabilities to recover in case of a system crash will be needed since a dedicated backup system is not in place for this configuration. The ReiserFS file system, which is the default in SUSE

Linux, offers fast performance and basic journaling of metadata, only records information that describes the data on the system, not the data itself. One downside to this is that if a system becomes corrupt, it may not be possible to bring the system back into a consistent state.

The second option for a journaling file system is Ext3. This file system offers complete data journaling, which can cause the system to slow down due to disk

36

processing, however, when working on large databases or files, this performance degradation is negligible. Also, having full data journaling provides consistency for the file system in the event of a crash. Since a backup system is not being used, and a text- only system was chosen, we will choose Ext3 with full journaling for this system.

Once the file system type has been chosen, click Add from the Expert Partitioner, then choose Primary Partition. As only one physical drive is being used, the remaining space will be allocated and mounted to the root system therefore keep the default of

Maximum Size on the New Partition Size screen (Figure 7) and click Next. If two or more drives are used, the larger drive could be partitioned as a data mount point in which to store the data.

In the Formatting Options screen, select Ext3 as the file system, ensure that the

Mount partition is set to / and then select Finish. Two partitions should now be defined, one for the swap and one for the ext3. Once these are created, click Accept to continue to the Suggested Partitioning and then Next to enter a new user.

AB User Authentication

Once the partitioning options have been completed, the installation will ask to configure the user authentication. There are four methods in which to choose from; however, since this system is not part of a corporate network that supports the other authentication methods, it needs to be configured with the default local /etc/passwd method which is listed under the Summary. To complement the local authentication method, the installation also needs to create a new user. This user will be used to login to the system since the root user will not be able to directly login via SSH due to

37

configuration changes that will be made later. Once you enter a Full Name and

Username, enter and confirm a strong password. In the event that other systems on the network are compromised, it will be harder to compromise this system. This can be a combination of letters, numbers and symbols with a long length to make it difficult for password crackers to obtain the password. With these passwords, do not use words directly from the dictionary as these are some of the first checked. Next, remove the checkbox for Automatic Login option as this is not secure. Finally an option to uncheck is the Use the password for system administrator which will, by default, use the same password that was entered here for the root user as well.

Once the standard user has been established, another install screen will be presented asking for the password for the root user. Enter and confirm a new secure password here and click Next to continue.

AC Selecting Additional Software

Since a text-only installation was chosen, the normal GUI programs that are commonly used to retrieve data from the Internet are not available. To compensate for this deficiency, a few software packages need to be added to the installation: bison, flex, , wget, unzip, gcc, gcc-c++, libjpeg, libjpeg-devel, libpng12-0, libxml2-devel, libpng-devel, libaio and libaio-devel. These utilities provide a text-based browser, an

Internet document retrieval and compression utility, source code compiler and source code libraries respectively. To install the packages, once the Installation Settings screen appears, choose Software and then click on Details. When the software list opens, change the Filter to Search to open the Package Search Window. In the search textbox,

38

enter lynx and click Search. It will then return to the list and filter to the word lynx.

Once lynx appears in the list to the right, click the checkbox next to it to select it if it is not already selected. Repeat this search for the remaining packages referenced earlier and then click Accept. The installation will calculate further dependencies that will be needed for these packages and ask to continue. Next, the system will now return to the installation summary screen to complete the installation.

AD Completing the Installation

The default values for the remaining options will be used, therefore click Install, then Install on the confirmation window to begin the installation process. At this point, the installation will create the file systems that were defined and install all necessary files from the DVD needed for the text-only configuration (Figure 9). Finally, the system will reboot and continue the installation from a text-based version of the installation program.

The system may ask a few more questions about hardware and will then prompt to install the remaining files.

39

Figure 9

Next, the system will reboot, detect the network configuration, DSL, ISDN and modems, then prompt for a username and password. One optional, but recommended step is to perform an online update for software. To perform this update, login as the standard user and password created earlier, switch to the root user by entering su – from the command line to switch to the root user and finally enter the YaST Control

Center (Figure 10) by typing

40

Figure 10 yast at the command shell.

Once YaST opens, select Software from the left menu, and then select Online

Update from the center menu. YaST will begin to download the latest list of software updates available for the system and present them in a list (Figure 11). By default, only critical updates are selected and have an indication in the left column. Run these updates first by pressing Tab to select Accept and press Enter. Online Update will now download and install the necessary updates.

41

Figure 11

Once updates have been completed, re-run the Online Update and select the remaining updates that are not already selected by pressing the up or down cursor keys to highlight the software to update and then press Space to toggle the selection. Once completed, accept the selections and the new set of updates will download and install.

Depending on the updates, the system may require a reboot. If it does, enter reboot from the command line once the software update completes.

AE Configuring the Network

After openSUSE 11.x has been installed, the network will need to be configured.

Earlier, the system was configured to allow the first Ethernet card to use DHCP. There are two downfalls to this in the database configuration. First, it is possible that the

42

network address can change when it is refreshed. Second, in order to use DHCP, it requires more ports to be open on the network card, leaving another chance for the server to be compromised.

To make the configuration easier, the YaST will be used. To begin, login to the system at the console using the standard user, switch to the root user with su – and then type start the YaST Control Center with yast

Once YaST opens, select Network Devices, then press Tab and then move to

Network Card and press Enter. YaST will read the existing network configuration and display the network cards configured in the system. While the first network card is selected, this should have DHCP listed as the IP Address, press tab until Edit is highlighted, then press Enter.

The Network Address Setup dialog will appear with options to configure the network adapter. Press Tab until the Setup Method section is highlighted and Automatic

Address Setup is selected (Figure 12).

43

Figure 12

From this dialog, press Tab to highlight Statically assigned IP Address setup, then press Space to mark this entry. When this happens, the IP Address and Subnet Mask and

Hostname will become active. Press Tab to switch to these fields. For the first Ethernet configuration, which will be the one connected to our 192.168.2.x internal network, an IP address in this range needs assigned. For the database server, this will be 192.168.2.75, and the subnet mask will be 255.255.255.0.

Next the hostname needs to be set. There are two approaches to setting a host name. The first is to give the system a generic name that has no meaning to its function.

Some systems administrators use arbitrary pop culture names, such as characters from

Star Trek or the movie Star Wars to fulfill this function. The other approach is to name each machine after its functional value, such as SMTP for an SMTP mail server. The main advantage of this is that systems on the network are easy to identify. However, due

44

to the function of these servers, if they are compromised, having identifiable names would make them more vulnerable to further attacks. The one exception to this is the honeypot server, in which an identifiable name is desired to lure an attack.

For this thesis, the name of enterprise will be chosen for the database server to follow a Star Trek naming scheme as we do not want the database server to be easily identifiable.

Once the IP Address, Subnet and hostname has been set, press Tab to Next and press Enter to save the changes and return to the YaST Control Center. Re-enter the

Network settings screen for the remainder of the settings.

Next, the Hostname/DNS settings need to be changed. From the Network

Settings screen, press Tab until the top options are highlighted, then press the right arrow until Hostname/DNS is highlighted.

Press Tab to the Hostname. This should be set to the hostname defined earlier. In the case of this setup, the name enterprise was chosen. Next, press Tab to Name Server 1 and enter at least one name server on the same network as the IP address. In the case of this network, that is 192.168.2.1.

Next, press Tab again until Routing is highlighted. The Routing Configuration window will open the default gateway will be displayed. In a usual 192.168.2.x internal network configuration, this is usually the router itself. In this setup, it will be

192.168.2.1. Once the Default Gateway has been entered, press Tab until OK is highlighted and press Enter. The system will return back to the Yast Control Center.

45

Now that this interface is configured, the remaining two interfaces need configured. Re-enter the Network Settings menu to perform the same steps above need to be performed with some value differences. Since we have two separate machines directly connecting to this machine, we want to place each on a separate network. Also, to keep them separate, choose a network address from a different set of internal non-routable IP addresses [17]. These IP addresses fall in the ranges 10.0.0.0 – 10.255.255.255,

172.16.0.0 – 172.31.255.255 and 192.168.0.0 – 192.168.255.255. Since there are three network cards in this configuration, a good idea is to choose one IP from each of these three ranges. The first was on eth0, 192.168.2.75 which was just configured. For the second 10.10.10.250; and the third 172.20.0.250. For the second and third addresses, there should be no routing or gateway information defined as it may interfere with packet routing; also the host name would not need to be set as it was configured with the first network card.

Once these are configured, press OK to save and write the network configuration.

Next, SSH needs to be enabled to allow remote access. Select Security and Users from the Yast Control Center, and then select Firewall. Once the firewall settings appear, select Allowed Services and Tab over to Service to Allow. From the dropdown, select

Secure Shell Server, and then press Alt+A to add the Allowed Service, then press Alt+N for Next and Enter on Finish.

46

AF Configuring the Firewall

Configuration of the openSUSE firewall is done in a similar fashion to the rest of the components through the YaST Control Center (Figure 13). From the main menu, the firewall exists under Security and Users. From this menu, the following options appear:

Figure 13

 Start-Up - allows the admin to configure when the firewall will start and to

stop or start the current instance.

 Interfaces - shows the existing network interfaces and defines which

firewall zone each interface belongs to.

 Allowed Services - defines the services and ports that are allowed to

communicate on a specific zone.

47

 Broadcast - configures broadcast logging; and Logging Level, which

configures logging of packages.

 Masquerading - provides address translation between network cards.

 IPsec Support – provides the creation of secure authenticated and encrypted

tunnels between systems on an untrusted network.

The initial firewall configuration was performed earlier in the network setup where SSH was defined to be allowed and the firewall was enabled and has to be slightly altered. First, assign a firewall role to both internal network cards. This can be done by selecting Interfaces from the menu, then highlighting an interface and pressing enter to open the Zone dialog window. When this opens, press the cursor down key to show the list of zones and choose an appropriate zone.

For the database system, the network card interface connected to the 192.168.2.0 network needs set to the External Zone. The interface that provides a direct connection to the Snort server needs assigned to the Internal Zone, and finally the last network card, which is directly connected to the honeypot, needs set to the Demilitarized Zone.

Each of these zones provides a friendly profile name that can be configured independently. For example, SSH may be desirable to connect to the database server, but rather not the insecure honeypot server, or allow access from that server into the database server via SSH. Therefore, the External Zone, which is the default configured zone, SSH is enabled. The Demilitarized Zone, however, does not list SSH as allowed, and therefore is denied. Also by default, the Internal Zone has an open configuration with all ports open and the Demilitarized Zone has no open ports.

48

Since this server may be used for off line data analysis or database management, port 3306 for MySQL will need to be opened for the External Zone. This port can be opened by selecting Allowed Services from the left menu, then pressing Tab to the zone field and making sure External Zone is selected, then press Tab to the Advanced field and press Enter. When the dialog window appears, enter 3306 under TCP Ports, then press tab until OK is highlighted and finally press Enter. Besides MySQL, Apache needs to be opened to allow access from the administrative network. For this, the HTTP Server service may be enabled by pressing Tab until Service to Allow is selected, press cursor down to select HTTP Server then press Alt+A to add this service.

Once alteration of the configuration has been completed, press Alt+N to exit. The system will then present a summary of the configuration. Accept the configuration and the system will continue to write the revised firewall rules and return to the main YaST

Control Center.

Another security measure that needs to be taken in to consideration with SSH, is to deny direct root access to the system. With this configured, the root user will not be able to directly log into SSH remotely. To use the root user, a standard user will have to log into the system and a su would have to be performed. This will help prevent brute force attacks against the SSH server and is a good practice to hold for servers. To configure, open the sshd_config file in the /etc directory and find the line labeled for root logins, and if commented out with a # in the front, remove the #, then change the yes to a no. This will tell the system to not permit root login. Next, reload the sshd service by executing

49

/etc/rc.d/sshd reload to re-read the configuration file. When root attempts to login again via SSH, it will return to the password prompt even if the password is correct.

After the changes have been made, a full nmap TCP port scan on the system using nmap 5.2.1 [36] from another machine on the External Zone reveals:

Starting Nmap 5.50 ( http://nmap.org ) at 2011-02-08 21:39 Eastern Standard Time NSE: Loaded 36 scripts for scanning. Initiating ARP Ping Scan at 21:39 Scanning 192.168.2.75 [1 port] Completed ARP Ping Scan at 21:39, 0.22s elapsed (1 total hosts) Initiating Parallel DNS resolution of 1 host. at 21:39 Completed Parallel DNS resolution of 1 host. at 21:39, 0.03s elapsed Initiating SYN Stealth Scan at 21:39 Scanning 192.168.2.75 [1000 ports] Discovered open port 3306/tcp on 192.168.2.75 Discovered open port 22/tcp on 192.168.2.75 Discovered open port 80/tcp on 192.168.2.75 Completed SYN Stealth Scan at 21:39, 5.22s elapsed (1000 total ports) Initiating Service scan at 21:39 Scanning 3 services on 192.168.2.75 Completed Service scan at 21:39, 6.03s elapsed (3 services on 1 host) Initiating OS detection (try #1) against 192.168.2.75 Retrying OS detection (try #2) against 192.168.2.75 NSE: Script scanning 192.168.2.75. NSE: Starting runlevel 1 (of 1) scan. Initiating NSE at 21:39 Completed NSE at 21:39, 0.19s elapsed NSE: Script Scanning completed. Nmap scan report for 192.168.2.75 Host is up (0.00s latency). Not shown: 996 filtered ports PORT STATE SERVICE VERSION 22/tcp open ssh OpenSSH 4.1 (protocol 1.99) |_sshv1: Server supports SSHv1 | ssh-hostkey: 1024 32:2d:a3:c7:08:66:84:c5:35:13:66:db:2e:8c:54:b0 (RSA1) | 1024 64:a4:f1:2c:db:e7:f9:92:7c:56:33:0d:b7:8d:97:be (DSA) |_1024 58:dd:49:4f:56:ff:40:52:94:54:96:7a:dd:9a:d8:d9 (RSA)

50

80/tcp open http Apache httpd 2.2.14 ((Unix) PHP/5.2.12) |_html-title: Site doesn't have a title (text/). 113/tcp closed auth 3306/tcp open mysql MySQL (unauthorized) MAC Address: 00:0C:41:1B:E3:B7 (Cisco-Linksys) Aggressive OS guesses: firewall (Linux 2.6.16.53) (97%), Linux 2.6.13 - 2.6.28 (95%), Linux 2.6.16 (95%), Linux 2.6.15 - 2.6.27 (95%), Linux 2.6.22 - 2.6.23 (94%), Gemtek P360 WAP or Siemens Gigaset SE515dsl wireless broadband router (94%), Linux 2.6.18.8 (openSUSE 10.2) (94%), Linux 2.6.18.8 (openSUSE 10.2, SMP) (94%), Linksys WRT54GX2 WAP (93%), HP Designjet Z3100ps printer (93%) No exact OS matches for host (test conditions non-ideal). Network Distance: 1 hop HOP RTT ADDRESS 1 0.00 ms 192.168.2.75 Read data files from: C:\Program Files\Nmap OS and Service detection performed. Please report any incorrect results at http://nmap.org/submit/ . Nmap done: 1 IP address (1 host up) scanned in 17.77 seconds Raw packets sent: 2050 (93.522KB) | Rcvd: 37 (2246B)

This corresponds to the previously enabled SSH local access, HTTP is also shown due to the HTTP Server service being allowed and MySQL is shown due to the open database access.

APPENDIX B

Installing the MySQL 5.5 Community Edition database server

The utilities installed on the database server, lynx and wget, can be used to retrieve the latest stable version in the 5.5 series of the Community Edition [9] from the

MySQL website. This version is the free, open-source edition of MySQL, while not as feature-rich as the Pro Certified Server edition; it is slim and provides the basic database needs required for our environment. The database is packaged in two ways: the first is as a pre-compiled Red Hat Package Manager, RPM, package, and the other is the compressed archive that is optimized for specific systems. For the systems used in this thesis, the compressed archive it provides more control over the installation then what is available in the RPM compiled package.

BA Downloading the MySQL Server

First, download the archive from the MySQL site by using the lynx text- to navigate to the correct location and download the file. From the shell prompt, run lynx ftp://mirror.anl.gov/pub/mysql/Downloads/MySQL-5.5/ to open a download mirror and use the cursor keys to scroll down to mysql-5.5.xx- linux2.6-i686.tar.gz, where xx is the latest release version in the 5.5 series. Press Enter to select the file to download, lynx will prompt to Download or Cancel for downloading. At this time, press D to download the archive. After downloading, lynx will prompt you to

51 52

Save to disk and display the filename it will use. Press Enter on the Save to disk option and then press Enter to accept the default filename and save. Next exit lynx and return to the shell prompt.

Once downloaded, the archive can be expanded with tar -xvf where is the archive that was downloaded. At the time of writing, this was mysql-5.5.8-linux2.6-i686.tar.gz. After the archive is expanded, the new directory needs moved to the /usr/local directory, which is defined by MySQL as the standard location for the server. From the shell prompt, run su root to change to the root user and move the directory that was created when expanding the archive to the /usr/local directory using mv /usr/local where at the time of writing was mysql-5.5.8-linux2.6-i686.

For security concerns, a generic user that will be used to run mysql must be created so the MySQL server service does not execute as root. To do this, three commands need to be run to create the mysql user groupadd mysql, useradd -g mysql mysql passwd mysql

This last command will prompt and confirm for a password to use and even though the system will not explicitly login using this user, the MySQL account has access to the databases and still needs secured. Once the user is created, the default shell needs

53

changed to /sbin/nologin to make sure the mysql user does not login. This can be changed by running the command chsh –s /sbin/nologin mysql

For readability, a link called mysql will be created to the directory that was copied by executing ln -s mysql where is the directory that was moved above. This link will allow us to access the directory as /usr/local/mysql instead of the longer /usr/local/mysql-5.5.8- linux2.6-i686, from the extracted directory above.

BB Configuring the MySQL Server databases

After the mysql user has been configured and the MySQL server placed in the proper location, the system databases that MySQL uses to operate need installed. To do this, as the root user, run scripts/mysql_install_db --user=mysql from the /usr/local/mysql directory. Please check the MySQL 5.5 Reference Manual section on mysql_install_db [41] if an error occurs. Lastly, once the mysql tables have been established, security for the files in the mysql directory needs to be set using the following two commands chown -R root:mysql chown -R mysql data

54

Following setting the security, an init.d script that will start MySQL when the system boots, called mysql.server in the /usr/local/mysql/support-files directory needs to be implemented. To use this script, copy it to the /etc/init.d directory using cp /usr/local/mysql/support-files/mysql.server /etc/init.d

After the file has been copied, it needs edited for the location of the mysql installation. There is one line that needs changed for the base directory. Find the line that contains basedir= and change it to basedir=/usr/local/mysql.

Then, execute the following two commands to add the service, enable the appropriate run level, and initially start it chkconfig mysql.server on

/etc/init.d/mysql.server start

Once the server has been started, the password for the root user of the mysql server needs to be configured. This is a different user than the root user for the system, therefore we need to choose a separate password. Once a password has been chosen, two commands need to be executed from the /usr/local/mysql/bin directory

./mysqladmin -u root password ''

./mysqladmin -u root -h localhost password '' where is the new password chosen. Once MySQL is installed and running, three standard users and two databases need to be configured that will be used to connect to the server for uploading data from Snort and the honeypot. To perform this, execute

./mysql -u root -p and enter the password defined above to enter the MySQL command interface.

Next, from the MySQL prompt, type

55

CREATE DATABASE snort; to create the two databases needed. Next, type in the following commands to create the users, however, substitute with the IP address of the Snort IDS server, with the password of the Snort database user that will be used to connect to the database from Snort and with the password of the web administrative interface user.

FLUSH PRIVILEGES; GRANT UPDATE,SELECT,INSERT on snort.* to snort@; GRANT CREATE,UPDATE,SELECT,INSERT,DELETE on snort.* to web_user@localhost; FLUSH PRIVILEGES; USE mysql; UPDATE user SET Password=PASSWORD('') WHERE user='snort' and host=''; UPDATE user SET Password=OLD_PASSWORD('') WHERE user='snort' and host=''; UPDATE user SET Password=PASSWORD('') WHERE user='web_user'; UPDATE user SET Password=OLD_PASSWORD('') WHERE user='web_user'; FLUSH PRIVILEGES; exit;

MySQL provides the storage for the analysis of data. In order to retrieve this data, the MySQL Query Browser can be used to view the raw data inside the tables, and the Apache web server, along with the BASE security analyzer, which will be installed next, can be used to convert this raw data into meaningful representations of the data.

APPENDIX C

Installing the Apache HTTP Server

Although it is possible to add Apache via the YaST control panel, the source code will be used to create a more optimized version. To begin, the Apache source file needs to be retrieved from the Apache project. To do this, similar to MySQL above, execute lynx http://httpd.apache.org/download.cgi to load the Apache download page. Next, scroll down to Unix Source: and press Enter on the first httpd-.tar.gz, where is the latest version available. At this time, this is version 2.2.17. Lynx will then prompt to download or cancel. Choose D for download and once downloaded, select save to disk and use the suggested filename.

Finally, press Q to quit lynx.

Next, Apache needs extracted with tar -zxvf httpd-.tar.gz to create the output source directory. For the 2.2.17 version, this would be httpd-2.2.17.

Unlike MySQL above, Apache is not pre-compiled. To build Apache, the standard configure, make and make install will be used. Apache needs special configuration options to run.

Start by executing:

./configure --prefix=/usr/local/apache --enable-so to set the prefix and enable modules. Next, execute make

56 57

to build apache. Finally, change to the root user with su and execute make install

Once the make process has completed, this can be tested by executing

/usr/local/apache/bin/httpd

as root and then from a web browser on another machine go to the url http:// where is the IP address of the server. If Apache is configured properly, the message “It works!” should appear in the browser window. If another message or no message appears, ensure that the service is started by executing ps -aef | grep httpd

as the root user. One or more entries for httpd should appear if the daemon is running. If it is not running, try to start it again, and then refer to the support on the

Apache web site. Once the httpd daemon service is running, it can be stopped and configured. To stop the daemon, execute

/usr/local/apache/bin/httpd -k stop

CA Preparing the Apache HTTP Server

Once Apache is installed, it needs configured for general use. The first item to configure is security. Similar to MySQL, a new user will be created that will act on behalf of Apache to run on the system instead of running as the root user. To create this user and setup a password, execute the following three commands groupadd apache

58

useradd -g apache apache passwd apache

To prevent a logon by the apache user, change the shell for the apache user with chsh –s /sbin/nologin apache

Next, the Apache web files will be moved out of the Apache binary directory to separate the application from the data. To do this, as the root user, execute mv /usr/local/apache/htdocs /var/www

Next, so that the apache user can access this folder, execute chgrp -R apache /var/www

Finally, to hook the new security settings to Apache, the httpd.conf file in

/usr/local/apache/config needs edited. Look for the line starting with DocumentRoot and change it to: DocumentRoot “/var/www”, then find all occurrences of

/usr/local/apache/htdocs and replace it with /var/www to update all document references.

Next, find the line that contains: User daemon and change it to User apache then do the same for the Group line below it. Also if these lines are within an

tag, move them outside the ending tag. Once this is completed, start the httpd server and execute a ps -aef | grep httpd to see that the httpd user is running under the apache user, then access the default web site as shown above to make sure the default site appears.

59

Next, the httpd daemon needs configured to start on boot. Apache comes with a script to perform this. Copy the /usr/local/apache/bin/apachectl to /etc/init.d/httpd then, execute chkconfig httpd on to configure the service to start at boot.

APPENDIX D

Configuring the Snort Network

From the YaST Control Center menu select Network Devices, then in the right menu, select Network Card. When the network card menu opens, it will show both network cards installed in the system. The first network card is shown to be configured using DHCP, which was set during the initial installation. Since this server will be reporting to the database server it needs to be placed on the 172.20.0.0 network. Start by highlighting the first card and press Enter. When the network address setup screen appears, select static address setup and enter the IP address of 172.20.0.200 and a subnet

255.255.255.0. For the hostname of this server, to keep with the existing naming scheme, the server name of “spock” will be used.

Under the Hostname/DNS settings the spock hostname will also be used and a

Name server of 192.168.2.1, the IP address of the internal router will be used.

The routing table needs to be configured in order for the system to be able to properly route packets. To do this, choose Routing, also under Detailed Settings and press Enter. For the default gateway, use the IP address of the interface on the database server, which is 172.20.0.250 in this configuration. Next, choose OK. Lastly, click Next to return to the Network Card Configuration Overview.

The second card will not be configured in the YaST network configuration since it is a passive sniffing interface and therefore does not need an IP setup. However, to

60 61

configure this second card, it needs to be placed in promiscuous mode and enabled using the ifconfig command. To enable the network card in this mode, enter the following two commands su -

/sbin/ifconfig eth1 promisc up

Once configured, the configuration is viewed by entering

/sbin/ifconfig

The output should resemble eth0 Link encap:Ethernet HWaddr 00:0F:B5:F8:E7:A4 inet addr:172.20.0.200 Bcast:172.20.0.255 Mask:255.255.255.0 inet6 addr: fe80::20f:b5ff:fef8:e7a4/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:1815 errors:0 dropped:0 overruns:0 frame:0 TX packets:1341 errors:1 dropped:0 overruns:1 carrier:1 collisions:0 txqueuelen:1000 RX bytes:149568 (146.0 Kb) TX bytes:626443 (611.7 Kb) Interrupt:5 Base address:0xc000 eth1 Link encap:Ethernet HWaddr 00:A0:CC:3D:E8:2F inet6 addr: fe80::2a0:ccff:fe3d:e82f/64 Scope:Link UP BROADCAST RUNNING PROMISC MULTICAST MTU:1500 Metric:1 RX packets:26 errors:0 dropped:0 overruns:0 frame:0 TX packets:9 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:7016 (6.8 Kb) TX bytes:702 (702.0 b) Interrupt:10 Base address:0x1c00 lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)

62

It is evident that eth1 is UP running PROMISC mode, and will only enable the network card for this session. When the system reboots, it will not re-enable the card.

Later in this thesis, once Snort is installed, this network routine will be automated.

DA LIBPCAP and TCPDUMP

When configuring the network, the monitoring network card was placed into promiscuous mode. To utilize this mode, the Packet Capture (PCAP) [42] library needs to be installed. This library provides a standard interface in capturing promiscuous packets from the network and provides a standard file format that can be read by multiple applications, such as Snort, Wireshark [43] and tcpdump [42]. TCPDUMP, which will also be installed, is a separate application by itself, however, provides a powerful text- based packet capture utility. Follow the instructions in APPENDIX F to install these utilities.

Even though it is possible to retrieve these packages from the operating system installation CD's, newer and more optimized versions can be obtained via the source archives, which can be obtained from the tcpdump.org [42] site. At the time of writing, these were tcpdump-4.1.1.tar.gz and libpcap-1.1.1.tar.gz for tcpdump and libpcap respectively.

Once downloaded, install all pre-requisite packages needed to compile on openSUSE as well as support additional applications. From a command shell, similar to the previous software installation section, run the YaST management software, then go to software management. Once the software list appears, search for flex, gcc, gcc- c++,bison, libaio, libaio-devel, zlib and zlib-devel then mark them for installation. Next,

63

press Ctrl-A to accept then, OK to accept dependencies, and then finish to complete the installation.

After the dependencies have been installed, the installation of libpcap and tcpdump can continue. Extract both libpcap and tcpdump, then from within the two directories extracted, run the following two commands as the standard user created during the install

./configure make

Once the software has been compiled, run the following as the root user to install make install

DB Physical Network Connections

As shown in the second network configuration, each network interface card will reside on a separate network. The first network card connects directly to the database server via a cross-over cable as there is no switch or hub in between them. The second network card is connected to the hub, which would normally require a straight-though patch cable. However, since the network card would be visible in this manner, a special variation of a receive-only cable with the transmit wires removed needs to be created.

There are multiple ways this cable can be created, from just cutting the cables, to looping the transmit wires to the receive wires to provide feedback. The article Receive- only UTP cables and Network Taps, by Diego González Gómez [16], shows a few of these ways. One method, which will be used in this thesis, is referred to Model C in the article. In this model, the transmit pair are cut from one end of the cable. On the other

64

end, the receive pair is merged into the transmit pair to create a loop back, causing feedback which scrambles the signal.

DC Testing the network configuration

Now that LIBPCAP and TCPDUMP are configured and the receive-only network cable has been created, we can test our passive network configuration. If the system has rebooted since configuring the second network card, make sure it is functioning in promiscuous mode, by executing ifconfig and looking for eth1 with PROMISC in the description. If it is not enabled, refer to the previous section on configuring the network to enable promiscuous mode.

This network card is in promiscuous mode, and a receive-only cable has been created and installed, therefore no packets should be able to transmit from this system.

This can be tested by shutting down the existing eth1 configuration with ifconfig eth1 down

and then re-enabling with a random IP address in the network subnet. In the network configuration used in this thesis, that network would be 192.168.1.0, therefore execute ifconfig eth1 192.168.1.XX netmask 255.255.255.0 up where XX is some unused number on the network. Once enabled, check the routing table with route -n and see if destination of 192.168.1.0 uses interface eth1. Then try to locate the router for this subnet using ping 192.168.1.1

65

Using the special receive-only cable, a Destination Host Unreachable message should appear. Replacing that cable with a standard cable should result in 64 byte responses from 192.168.1.1 with a ttl of 64. If this occurs, the cable is working properly with not allowing outbound connections.

Because it has been determined that the receive-only cable does not allow outbound traffic, it is necessary to confirm that it will still read traffic on the network. To perform this, tcpdump will be used. After the previous section, make sure the IP address has been removed from the network card and it has been placed into promiscuous mode.

Refer to the beginning of APPENDIX D, Configuring the Snort Network above to re- enable promiscuous mode. Next, execute the following command to start displaying network traffic tcpdump -i eth1

If universal plug-and-play is enabled on the subnet router, which on most routers is enabled by default, ssdp packets should appear resembling: 20:30:50.366425 IP

192.168.1.1.ssdp > 239.255.255.250.ssdp: UDP, length 276.

To further test, from another system connected to the network in any subnet, ping an unknown ip address in the 192.168.1.0 network and arp packets should appear asking for that ip address. For example, running ping 192.168.1.30 will respond with

20:36:41.035448 arp who-has 192.168.1.30 tell 192.168.1.2.

APPENDIX E

Installing the PHP Hypertext Preprocessor

There are two major versions of PHP available as of this writing, versions 5.2.16 and 5.3.5. Although the 5.3 series is newer, it introduces problems with the BASE system that have not been resolved at the time of writing; therefore the 5.2 series of PHP will be used. On the PHP web site [11], the source code archive for version 5.2.16 can be downloaded by executing the following command wget http://us2.php.net/get/php-

5.2.16.tar.gz/from/us.php.net/mirror

Once downloaded, extract the archive with tar –zxvf php-5.2.16.tar.gz

After the archive expands, from within the php-5.2.16 directory, the configure script needs run. To do this, execute the configure command as

./configure --with-apxs2=/usr/local/apache/bin/apxs --with- mysql=/usr/local/mysql --with-gd --with-jpeg-dir=/usr/lib --with- zlib --with-zlib-dir=/usr/lib --with-bz2

Once the install script finishes, execute make to begin compiling. Finally, switch to the root user and install PHP with the following two commands su

66 67

make install

Once PHP has been installed, it needs configured. First, as the root user, execute the following command

/usr/local/apache/build/libtool –finish /usr/local/apache/modules and then from the installation directory cp php.ini-dist /usr/local/lib/php.ini to copy the php.ini-dist file into the proper location. Once copied, edit the

/usr/local/lib/php.ini and find the line starting with “;date.timezone =” having no value assigned. From the PHP List of Supported Time zones page [44], click on the region of time zones that the server is currently residing in, such as America. Next, find an appropriate time zone, such as America/New_York for eastern, or America/Chicago for central time. Once a time zone has been decided, remove the ; before the date.timezone in the php.ini file and add the description for the time zone so the line would read:

“date.timezone = America/New_York”. Next, edit the Apache

/usr/local/apache/conf/httpd.conf needs configured. First, check for the line

“LoadModule php5_module modules/libphp5.so”. If it does not exist, add it at the top of the file where the LoadModule example is shown. Finally in the Types Configuration section, after the line “AddType application/x-gzip .gz .tgz”, add the following lines:

“AddType application/x-httpd-php .php .phtml” and “AddType application/x-httpd- php-source .phps”.

APPENDIX F

Installing Basic Analysis and Security Engine (BASE)

For this installation the latest version of BASE will be downloaded, which at the time of writing is 1.4.5. Once downloaded from the BASE web site, extract the archive with tar –xvf base-1.4.5.tar.gz then move the base-1.4.5 directory into /var/www with cp –R base-1.4.5 /var/www change the permissions on the directory to 757 using chmod 757 /var/www/base-1.4.5 and finally change the owner of the files to the apache user by using chown –R apache:apache /var/www/base-1.4.5.

FA Installing ADOdb

Before BASE can be utilized, it needs to know how to communicate with the database. In order to do this, the ADOdb Database Abstraction Library for PHP [45] needs to be installed. At the time of writing, the latest version of ADOdb compatible for

PHP5 was 5.1.1. Once downloaded from the ADODB website, extract the archive with tar –xvf adodb511.tgz and then move the adodb5 directory that was extracted into /var/www, rename to adodb then change the owner to apache using chown –R apache:apache /var/www/adodb 68 69

FB Installing Perl Compatible Regular Expressions

Another requirement for BASE is the Perl Compatible Regular Expressions,

PCRE [46]. PCRE provides an API for regular expressions that follows the same syntax as what is used in the Perl programming language. The latest version, at the time of writing, is 8.11. To obtain the source code, navigate to the PCRE homepage [46] and choose the first ftp download link. Select the latest version of the source code, pcre-

8.11.tar.gz. This can also be obtained directly at the time of writing by executing wget ftp://ftp.csx.cam.ac.uk/pub/software/programming/pcre/pcre-

8.11.tar.gz

from the command shell. Once downloaded, extract the archive with tar -xvf pcre-8.11.tar.gz

then as a non-root user, execute the following three commands to compile pcre from within the pcre-8.11 directory

./configure make make check

Finally, as the root user, execute make install

FC Installing PEAR::Image_Canvas and PEAR::Image_Graph

One of the features of BASE is the ability to graph the alert data. The graph ability was compiled and installed into PHP above, however two additional modules need installed for BASE to support graphing. Image_Canvas [47] and Image_Graph [48] are

70

PHP Extensions to create graphs, of which the latest version at the time of writing are

0.3.3 and 0.8 respectively. To install, first the PHP Extension and Application Installer

[49], PEAR, needs to be updated. Update by executing the following three commands su pear upgrade --alldeps PEAR pear channel-update pear.php.net

Once updated, execute pear install --alldeps Image_Graph-alpha as root to install the extensions.

FD Installing PEAR::Mail and PEAR::Mail_Mime

Another feature of BASE is the ability to send notifications on alerts. Two modules are required for BASE to operate properly: PEAR::Mail [50] and

PEAR::Mail_Mime [51]. To install these, execute the following three commands su pear install --alldeps Mail pear install --alldeps Mail_Mime

FE Basic Analysis and Security Engine Configuration

After installation, unlike the previous configurations above, BASE is configured via a web browser. Open a browser and enter http:///base-1.4.5/setup/index.php as the url, where is the IP address of the server. If the above steps were configured properly, the BASE setup screen should appear and list that the configuration is writable

71

what version PHP is being used and the PHP logging level along with a Continue link at the bottom. Click the Continue link to start the configuration.

There are 5 steps in configuring BASE. First is to configure ADODB. Select

English as the language and enter /var/www/adodb for the location of adodb, which was configured above. The second step asks for database information. Select a database type of MySQL. Then, using the information defined above when MySQL was configured, enter snort for the database name, localhost for the database host, web_user for the database user name, and for the database password, where is the password defined for the web_user MySQL account. There is also an option here to use an archive database. This database was not setup, however, it can be established in a similar manner to the Snort database on the database server, and then the information entered here, otherwise leave this unchecked.

The third step in the BASE setup is to configure an authentication system. Using this feature will require a user to login before they can see any results from BASE. To establish an account for login, a username and password could be entered here and the

Use Authentication System checked. Since this is in a small network, and there will only be 1 or 2 administrators, leave the use authentication system unchecked and submit the query. Next in the fourth step, the Snort database will be extended to include BASE specific tables. To perform this, the web_user MySQL user will need CREATE privileges, which should have been defined when creating the accounts earlier. Once the tables have been created, the fifth step takes you to the main BASE screen which should resemble (Figure 14):

72

Figure 14

Since BASE is the only web site on this system, a small index.html redirect file can be created to shorten the URL. Create a file /var/www/index.html with the contents:

Finally, execute the following two commands to change the permissions and allow it to be seen by Apache chmod 644 /var/www/index.html chown apache:apache /var/www/index.html

APPENDIX G

Installing Snort Prerequisites

Before Snort can be installed properly, a set of prerequisites need to be installed and configured. These include Perl Compatible Regular Expressions, libdnet networking library, the MySQL Client libraries and the Snort is the Data AcQuisition library.

GA Installing Perl Compatible Regular Expressions

One requirement for Snort, which was also needed for the setup of the Basic

Analysis and Security Engine in the earlier section, is the Perl Compatible Regular

Expressions, PCRE[46]. The instructions from section FB, Installing Perl Compatible

Regular Expressions, can be used to install PCRE for Snort as well.

GB Installing the libdnet networking library

Another requirement for Snort, which is new for the 2.9 series of Snort, is the libdnet dumb networking library headers [52] which provide a portable interface to network routines. Obtain the latest from the libdnet download page which, as of this writing, is libdnet-1.12.tar.gz. This can also be obtained and extracted directly by executing the following two commands wget http://libdnet.googlecode.com/files/libdnet-1.12.tgz tar –xvf libdnet-1.12.tgz

and then as a non-root user, execute the following two commands to compile the source code 73 74

./configure make

Once compiled, as the root user, install libdnet by executing make install

GC Installing MySQL 5.5 Client Libraries

MySQL server is used on our database server to store Snort data which was setup earlier on the database system. To support this, Snort needs to be aware of MySQL and link to the libraries to know how to submit data to the database server. To do this, the client libraries need downloaded. In this thesis, the latest available version of components will be utilized; however, note that earlier revisions of Snort had a problem with the MySQL 5 series of libraries which caused errors to be logged when Snort tried to write after an extended period of inactivity. This issue was resolved by using the older

MySQL version 4.1 libraries. The latest version of Snort has resolved this issue, however if it does reappear, it can be resolved by reverting back to the MySQL version 4.1 libraries.

Similar to the instructions in setting up the database server in APPENDIX B, first, use the lynx text-web browser to navigate to the correct location and download the file.

From the shell prompt, run lynx ftp://mirror.anl.gov/pub/mysql/Downloads/MySQL-5.5/

to open a download mirror and use the cursor keys to scroll down to mysql-devel-

5.5.xx-linux2.6-i386.rpm, where xx is the latest release version in the 5.5 series. Press D to select the file to download. After downloading, lynx will prompt you to Save to disk

75

and display the filename it will use. Press Enter on the Save to disk option and then press

Enter to accept the default filename and save. Next exit lynx and return to the shell prompt. Once downloaded, from the shell prompt, run the following two commands to install the package as the root user su root rpm -Uvh where is the archive that was downloaded. At the time of writing, this was

MySQL-devel-5.5.8-1.linux2.6.i386.rpm. Once installed, the files will be installed in

/usr/include/mysql and /usr/lib/mysql.

GD Installing the Snort Data AcQuisition library

Similar to libdnet, another requirement, which is new with the 2.9 series of Snort is the Data AcQuisition library (DAQ) [53] which provides abstraction for capture implementations. The latest version of this library, 0.5, can be obtained from the Snort download page [54] by executing lynx http://www.snort.org/snort-downloads

to open the Snort download page [54] and press A to accept the cookie. Use the cursor keys to scroll down to Source section and the daq-0.5.tar.gz file. Press D to download the archive. After downloading, lynx will prompt you to Save to disk and display the filename it will use. Press Enter on the Save to disk option and then re-enter the filename of daq-0.5.tar.gz and press Enter to save. Next, exit lynx and return to the shell prompt. Once downloaded, extract the archive with tar –xvf daq-0.5.tar.gz

76

then as a non-root user, execute the following two commands to compile the code

./configure make

Once compiled, as the root user, execute make install

After the libraries have been installed, they will be located in /usr/local/lib/daq.

APPENDIX H

Installing Snort

Snort is also offered in both binary and source versions. Because the source version of other software has been used, and that source gives a better optimized version, the source will also be used with Snort. To retrieve, navigate to the Snort.org homepage

[6], select download, then the newest version under the latest source release section. At the time of writing 2.9.0.3 is the most current source code. This can be retrieved by executing lynx http://www.snort.org/snort-downloads to open the Snort download page [54] and press A to accept the cookie. Use the cursor keys to scroll down to Source section and the snort-2.9.0.3.tar.gz file. Press D to download the archive. After downloading, lynx will prompt you to Save to disk and display the filename it will use. Press Enter on the Save to disk option and then re-enter the filename of snort-2.9.0.3.tar.gz and press Enter to save. Next, exit lynx and return to the shell prompt.

Once the source has been downloaded, as a non-root user, extract with tar -zxvf snort-2.9.0.3.tar.gz then as a non-root user, execute the following command

./configure --with-mysql --with-mysql-includes=/usr/include/mysql

--with-mysql-libraries=/usr/lib/mysql --enable-pthread --enable- zlib --enable-ipv6 --enable-normalizer

77 78

to configure the compile scripts. After the configuration completes, execute make to start the compile procedure from the snort-2.9.0.3 directory. If the make procedure ends prematurely with an error about pcrm.c internal compiler error, restart the system and attempt the make again.

As with any software, Snort is dependent on other libraries, which rapidly change.

Since these components do not change at the same rate, incompatibilities may arise at different times, which could cause the make procedure to fail. If this happens, community collaboration on the Snort.org forum can assist with resolving errors that may occur. After make completes successfully, execute make install to install Snort to the proper location. At this point, the Snort server has been installed successfully and it is ready to be configured.

HA Configuring Snort

The first item to configure is the snort user account. This account was created during the installation and is part of the users group. First, by default the snort user is part of a shared group of users which is not as secure as having a dedicated group per user. To resolve this, as root, execute the following two commands groupadd snort usermod –g snort snort

79

Next, the login shell needs to be removed in order to remove the ability to login as the snort user. This will stop an attacker from using this account if compromised through the Snort IDS. As root, execute chsh –s /sbin/nologin

Once the user is configured, the Snort directories need configured. As the root user, run the following commands to configure the directories mkdir /etc/snort /etc/snort/rules /var/log/snort

After the directories are created, the configuration files need to be copied from the

Snort install to the /etc/snort directory from the snort-2.9.0.3/etc directory that was extracted from the archive. To do this, change into the home directory for the user that expanded the Snort tar archive file and, as the root user, execute cp ./snort-2.9.0.3/etc/* /etc/snort

HB Preparing the snort.conf file

Snort can run as a standalone packet capturing and analysis tool for gathering basic information. In order to tap the advanced features, it must be run with a configuration file. The primary configuration file is the snort.conf that was copied to the

/etc/snort directory above.

The first section of the configuration deals with configuring the variables Snort needs to determine systems settings. The first setting is HOME_NET. This variable defines the internal home network. In the case of this setup, this would be the

192.168.1.0 network defined above. Another variable is the EXTERNAL_NET, which is everything else. To make these changes, find and change the line var HOME_NET any

80

to var HOME_NET [172.20.0.0/24,192.168.1.0/24] then find the line var

EXTERNAL_NET any and change it to var EXTERNAL_NET !$HOME_NET to complete the network configuration. Next, Snort needs to know where to find the rules it will use to match packets for signatures. In this setup, these can be found in /etc/snort/rules. Find the line matching var RULE_PATH ../rules and change it to var RULE_PATH

/etc/snort/rules then the line var SO_RULE_PATH ../so_rules and change it to var

SO_RULE_PATH /etc/snort/so_rules. Finally find the line containing var

PREPROC_RULE_PATH ../preproc_rules and change it to var

PREPROC_RULE_PATH /etc/snort/preproc_rules.

One of the problems with detecting an intrusion is that an attacker can split instructions between different packets. Snort provides a way to handle these packets by using a preprocessor called stream4 if you are using Snort 2.7 or stream5 if you are using

Snort 2.8 or above. Both stream4 and stream5 perform stateful packet inspection, SPI, of

TCP sessions and TCP stream reassembly. A preprocessor will perform some action on a packet or set of packets before Snort analyzes it for an intrusion. The stream preprocessor will combine a stream of packets into one payload that Snort can then analyze. The snort.config file defines how the preprocessor will handle these packets.

For stream4, which is viable through Snort version 2.7, find the line

#preprocessor stream4: disable_evasion_alerts and change it to preprocessor stream4: detect_scans, disable_evasion_alerts to allow detection of port scans that do not use a normal TCP handshake, such as those generated by NMAP [36] and to enable evasion detection. The second parameter seems to contradict this, however, the

81

disable_evasion_alerts option defaults to off therefore enabling the evasion alert system.

Next, Find the line #preprocessor stream4_reassemble and change it to preprocessor stream4_reassemble: both, ports: 21 22 23 25 53 80 111 135 139 143 443 445 to allow full steam monitoring of FTP, SSH, Telnet, SMTP, DNS, HTTP, RPC, netbios, HTTPS, netbios over TCP/IP, and MySQL. This covers the services that are running on the honeypot machine and others which could be installed by an attacker if they would compromise the system.

For stream5, find the line containing preprocessor stream5_tcp: policy windows, detect_anomalies,require_3whs 10 and change the policy windows to policy first.

By default the snort ssl preprocessor now trusts all servers on your network.

Because this network is setup specifically for intrusion detection, this option needs to be removed. To remove the trustedservers option, find the line preprocessor ssl: ports, trustservers, noinspect_encrypted and remove the trustedservers, which will inspect the handshake information but not the actual data transfer.

In earlier versions of Snort, detecting port scans such as those generated from the

Nmap [36] Security scanner, which will be described later, were enabled by default.

However, in the newer releases, this needs to be enabled manually. To do this, find the line beginning with # preprocessor sfportscan: proto and remove the # to enable the processor.

By default, Snort attempts to utilize dynamic rule sets. This is no longer setup in advance and will cause problems when trying to start snort where it cannot find the

82

directory properly. To correct this, find the line in the configuration file containing: dynamicdetection directory /usr/local/lib/snort_dynamicrules and comment it out with #.

The final configuration setting is to tell Snort where to store alerts. By default it outputs them to the terminal; however, for our purposes of further analyzing the alerts they will be stored in the MySQL database that was created earlier. Snort was compiled with attributes to support MySQL communications; however the configuration file needs to know where to store it. In the snort.conf file, find the line # output database: log, mysql, user=root password=test dbname=db host=localhost and change it to output database: log, mysql, user=snort password= dbname=snort host=172.20.0.250 port=3306 detail=full where is the password for the snort user in the MySQL snort database, configured when setting up the database server.

Besides the connection string, the database itself needs to be defined. Snort comes with a script that can be run to create all the tables needed to properly store called create_mysql.

It can be found in the snort-2.9.0.3/schemas/ directory. This file needs copied to the database server and run there, as no direct interface to MySQL exists on this system.

This can be done by executing an scp copy command, such as scp snort-2.9.0.3/schemas/create_mysql

@:.

Where is a user on the MySQL Server and is the

IP address of the MySQL Server. This will copy the file to the home directory of the user specified on that server.

From the MySQL server as the user that was used in the copy above, run

83

mysql -u root -p < ~/create_mysql snort then enter the password for the root user. The script will run and return to the shell. Next enter the MySQL shell by executing mysql -u root -p and entering the root password again. Once the MySQL shell opens, type use mysql then show tables; to return the list of tables to verify that the script successfully ran. The query should return 16 tables in the database.

HC Installing the Oinkmaster Snort rule manager

Snort has worked to develop a Perl script known as Oinkmaster [21], which is currently at version 2.0. Once the source is downloaded, it needs extracted by executing tar -zxvf

where is the archive file downloaded. Inside the archive are the oinkmaster.pl and oinkmaster.conf files. The first thing is to update the configuration to accommodate this setup. From the Snort.org site, once registered as a member or subscriber, you can get an Oink Code. This code will allow Oinkmaster to act on your behalf to download the latest registered rules and install them. Once you have this code, the configuration can be created.

Open the oinkmaster.conf file, find the line to download Snort-current and add the line url=http://www.snort.org/pub-bin/oinkmaster.cgi//snortrules-snapshot-

.tar.gz where is the code received from the Snort.org web site and

is the snort version without periods, such as 2903 for Snort 2.9.0.3. Refer to the Snort web site as the format of this url may change over time. Note that the Oinkcode

84

will help determine to either Registered or Subscriber rules depending on your account type.

To retrieve the latest rules, execute perl oinkmaster.pl -o /etc/snort/rules -C oinkmaster.conf then look in the /etc/snort/rules directory to see if it downloaded the latest rules. Also verify if a rule file local.rules exists in the /etc/snort/rules directory. This is where custom rules will be created and is needed when snort is started. If it is not, create it with touch /etc/snort/rules/local.rules

A supplementary option, Emerging Threats, to provide the newly released vulnerabilities can also be added and can also be managed through Oinkmaster, although need to be done through a separate configuration file. To configure, copy the oinkmaster.conf file to oinkmaster2.conf and edit the new configuration file. Change the url line that was defined for the snort rules to url = http://www.emergingthreats.net/rules/emerging.rules.tar.gz then save the configuration file. Next, create a rules directory for the emerging rules so they do not get interleaved with the snort rules and retrieve the emerging rules by executing the following two commands mkdir /etc/snort/rules/emerging perl oinkmaster.pl -o /etc/snort/rules/emerging -C oinkmaster2.conf

Once perl has finished, look in the /etc/snort/rules/emerging directory to see all of the rule files that have been added. Next, the rule files that will be utilized by Snort need to be added to the /etc/snort/snort.conf file. Near the bottom of that file are a list of

85

include $RULE_PATH/ entries, where is a Snort rule file such as local.rules. At the bottom of this list, add the following configuration line: include $RULE_PATH/emerging/emerging.conf to ensure emerging specific variables are included in the snort configuration. To help determine which rule files to add to the snort.conf file, the Emerging Threats Rules FAQ [55] provides a list of the rules and their meaning. Next in the emerging.conf file, for each of the #include

$RULE_PATH/ entries, remove the # for the emerging rules that will be utilized by Snort and exist in the emerging directory then replace

$RULE_PATH/ with $RULE_PATH/emerging/ for these rules as well which can be done with %s/emerging/emerging\/emerging/g from vi.

HD Disabling Unwanted Rules

After rules have been established, it may be determined that some rules may not be required. For example, if establishing a Linux Honeypot, then Microsoft Windows specific rules would not be required and those can be safely disabled, whereas a

Microsoft Windows honeypot would not necessarily need Ubuntu Linux rules. Of the rules that can be disabled, some may never be fired, and others may alert very frequently.

As rules in Snort are controlled through the rule files, disabling a rule is as simple as commenting out the line in the file that contains the file. However, maintaining this can be daunting with large rule sets. On the Snort system, Oinkmaster was presented to update the rule sets. It can also be used to disable rules by their SID, which helps since the SID can easily be identified through the BASE [12] web interface by clicking the

86

[snort] link next to a rule then looking at the GEN:SID from the signature database that opens.

Once the SID has been obtained it can be added to the oinkmaster.conf file with the format disablesid SID. For example, the rule MS-SQL version overflow attempt, which has a SID of 2050 would be added as disablesid 2050. SID numbers can also be grouped together on one line by separating them with a coma, i.e.: disablesid 2050,2003.

Finally, a comment can be added after the disablesid entry on the same line starting with

# to help identify why the SID was disabled. This is good for later reference. Once

SID‟s have been added, run the oinkmaster scripts again. As they run, they will display that they disabled rules and at the end, and will show the rules that they have disabled.

HE Snort and Network Startup Script

After Snort has been configured, it needs to be configured to start on boot. The archive that was extracted earlier for Snort contains a snortd startup file located under the snort-2.9.0.3/rpm directory that can be copied to /etc/init.d in order to start on boot.

Next, this file needs edited in order to correctly start the instance of Snort. At the beginning of the script, comment out the lines of source function and source configuration lines with a #. Because this system uses multiple network cards, Snort will monitor traffic on eth1 and pass information to the database server via eth0 in this setup.

In the file, find the line containing if [ "$INTERFACE"X = "X" ]; then and before that line, add the following lines: if [ "$IFUP"X = "X" ]; then IFUP="eth1"

87

fi

Next, change the line INTERFACE="-i eth0" to INTERFACE="-i $IFUP" to use the eth1 that was just defined directly above. At the top of the start section under the line echo –n “Starting snort: “add the following: echo echo "Restarting interface: $IFUP" ifconfig $IFUP down ifconfig $IFUP 0.0.0.0 promisc up export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/lib:/lib

Adding these will automate the process of starting the eth1 interface without an ip address and in the proper promiscuous mode as described earlier as well as setup the libraries to properly start Snort. An optional change is to add status message on the script to determine if the snort process started. To do this, at the bottom of the start section, before the line containing ;; add the following entries:

PID=`pidof -o $$ -o $PPID -o %PPID -x snort` if [ ! -n "$PID" ]; then # if we got no PID then: echo "An Error occurred while starting Snort" else echo -n "Snort process started successfully" fi echo

Finally under edit the lines containing daemon /usr/sbin/snort and change them to

/usr/local/bin/snort. This can be done with %s/daemon\

\/usr\/sbin\/snort/\/usr\/local\/bin\/snort/g from vi. Once the changes have been made, the snortd script can be tested as the root user by executing

/etc/init.d/snortd start

A message of Starting Snort: will appear and then return to the prompt. Next, execute

88

ps -aef | grep snort

to see if /usr/local/bin/snort is included in the process list with the parameters that were passed in.

If the snort process is not listed, check /var/log/messages for errors that may have occurred while Snort was starting. The most common of these, especially after updating the rule set, is invalid rules. One primary cause for this error is that new features are introduced into minor revisions of Snort, such as new rule keywords: Unless Snort is upgraded as well, the rules will present an error when the new rules are put in place. In these cases, which can be easily fixed, the error log it will state which rule file failed, what line it failed on, in parenthesis, and the error. Once the errors have been addressed, sometimes by upgrading snort itself, or removing invalid rules, try to start Snort again and see if the process exists. This may be an iterative process until all the errors have been resolved with configuration and rule files.

Once Snort is listed, the snortd script can be made to start on boot by executing the following two commands as root cd /etc/init.d chkconfig snortd on

APPENDIX I

Installing Damn Small Linux

Damn Small Linux, which was at version 4.4.10 at the time of this installation, is available in multiple forms, including ISO, floppy and network installations. For this installation, the ISO image will be used, which needs to be downloaded and burned to a

CD before installing. Next, to begin the installation, boot the computer with the CD in the drive and enter install at the welcome Damn Small Linux boot screen to load the installation screen.

Before the installation can be placed on the hard drive, it needs formatted. From the installation menu, choose 10 for the cfdisk partition tool. Next, the cfdisk tool will begin and ask for the disk. For this installation, hda will be used. Once the drive is selected, a list of partitions will appear if any exist for the system, also at the bottom of the screen, a menu will appear with options for each partition.

If any partitions exist, delete them before continuing. For this installation, two partitions will be needed: A swap space and a primary work space. To create the swap space, select the Pri/Log entry in the upper menu, then New in the lower menu and press

Enter. On the second screen, select Logical and press Enter, then enter the size of the swap file. Like the other systems in this configuration, this should be at least 1½ times the size of the physical memory installed in the system. In the next menu, select

Beginning and press Enter. Once back at the main screen, with the new partition 89 90

highlighted, select Type at the bottom and press Enter. At the prompt, enter 82 for Linux

Swap and press Enter.

Next, highlight the remaining free space entry in the partition table and repeat the procedure for the next partition, however, create a Primary partition instead of a Logical partition. Also enter a type of 83 for Linux instead of 82. Finally select the new primary partition and highlight Bootable to make the second partition bootable.

Once completed, write down the name of the bootable partition as it will be needed later in this procedure. To finish, select Write and press Enter. The partition tool will then exit back to the installation screen. If advised to reboot to reload the partition table, enter 11 at the installation screen at this point, but leave the CD in the drive.

To continue the installation, enter 2 from the installation screen. It will then begin asking a series of questions for the install. First it will ask for the partition‟s destination, which is the partition that was written down from above. Next, it will ask if this system is to be installed for multi-user logins, choose y at this prompt.

DSL uses one of two partition formats for installation: ext2 or ext3. ext3 adds journaling which also adds overhead to the system, however this is now minimal on most newer systems. The next question prompts to enable journaling. Answering y will format with ext3, answering n will format with ext2. For this installation, y will be selected. After this question it will verify to continue and begin formatting the partition with the selected partition type, install the necessary base packages and perform the preliminary configuration.

91

After the initial copy, the next question is about the boot loader. DSL offers two boot loaders, Grub and Lilo. Grub is the bootloader of choice and supports more hardware systems; however Lilo will support older systems. For this installation Grub will be used. When the system prompts to install a boot loader, choose y, then choose g for Grub. If the system did not ask which type of boot loader to install and instead exited back to the install menu, it will be necessary to re-boot and possibly re-install as it did not successfully read the partition table from the first step. Once Grub is selected, it may then ask for prior Windows installations on the first partition; even though the system has been formatted, enter n at this prompt. Finally for this stage of the installation, enter y to reboot the system when prompted to reboot.

When the system reboots it will prompt for both a root and dsl password, which is the user it created during installation. The passwords for these users must be between 5 and 8 characters in size. Next, the system will present the login prompt. During the first login for each user it will configure X Windows environment. First, it will ask for the xserver type, Xvesa or Xfbdev. For this prompt, choose Xvesa. Then enter the questions for the type of mouse, number of mouse buttons, screen resolution and color depth. For this installation, a 2 button ps/2 mouse was chosen, 800x600 resolution and 16 bit color depth was chosen. Finally do not choose a custom dpi and choose the US keyboard layout.

After configuration a slimmed down X Windows desktop will be presented with a welcome screen and instructions on how to navigate the system. If the video resolution does not give satisfactory results, try to reboot first, otherwise it can be reconfigured by

92

going to System then X Setup and re-answering the prompts, or by going to System then

Xvesa and choose a pre-configured setting.

IA Additional Software Dependencies

Since the honeypot box is split between a host and guest operating system, the host system will need to be able to compile software and be able to access C++ and kernel headers. To do this, GCC [56] need to be installed. Although the latest version of

GCC is the 4.1.x series as of this writing, Argos and QEMU emulator [34], the emulation layer Argos relies on warns against the version 4 release of GCC and advises installing the version 3 release. Damn Small Linux includes GCC 3.3.4 as part of its myDSL repositories by default so installing is easy, however before this is done, ensure a network connection established or myDSL will not display any extensions. The complete network setup is described in more detail later in this setup, however, only a single connection is needed to the internet currently.

To add, open myDSL as the dsl user, and download the database when prompted the first time myDSL is opened. Next expand System and then click gcc1-with-libs.dsl.

Once the description appears, select Install Selected Package which will automatically download and install the archive. Once that is completed, repeat the procedure and install the dsl-dpkg.dsl and gnu-utils.dsl packages under System then perl5.8.0.dsl currently in

Testing at the time of writing. Once complete, open a shell and execute the following command to populate the dpkg repository sudo apt-get update

93

IB Installing a new Linux kernel

The Linux kernel that comes pre-packaged with Damn Small Linux is configured to be minimal. This is good for basic installations; however, for extending the networking and adding the QEMU Emulator module extension, the kernel will need to be reconfigured. The kernel source tree for the 2.4.XX kernel version, where XX is the minor kernel version provided with the DSL distribution, yet it cannot be installed from the myDSL repository. However it can be downloaded from one of the DSL download mirrors under the kernel directory.

In this directory will be the kernel source as a tar.gz file and supplemental config and patch file. All three of these will be needed. Once downloaded, create the directory

/usr/src by executing the following two commands sudo mkdir /usr/src sudo chmod 755 /usr/src

Next copy all of the files to the /usr/src directory and extract the tar.gz archive by executing sudo tar –zxvf linux-2.4.XX.tar.gz then create a link to the new directory that was created as sudo ln –s linux-2.4.XX linux where XX is the minor kernel version referenced above. This will allow future reference of /usr/src/kernel in this document instead of using the version number.

Once the source tree is ready, it needs to be extended for Damn Small Linux, execute sudo apt-get install kernel-patch-xfs

94

to download the xfs file system patch. Next, apply the first KNOPPIX patch to enable boot extensions from the /usr/src/linux directory by executing sudo patch –p1 < /usr/src/knoppix-kernel.patch

Then, from the /usr/src/linux directory, edit the Makefile file and replace any occurrences of gcc-2.95 with gcc. Finally, execute the following two commands to prepare the kernel configuration and load the menu sudo make mrproper sudo make menuconfig

When the configuration menu appears, select Load an Alternate Configuration File.

When the dialog appears, change the text to /usr/src/dsl.config and press Tab to select

OK, and then press Enter to load the configuration. Next, select Networking options and press Enter. In the networking menu, highlight 802.1d Ethernet bridging and press Space to change the option to * which indicates built into the kernel instead of loadable module.

Also, while in networking, remove the following selections: Asynchronous Transfer

Mode, 802.1Q VLAN support, DECnet support. When completed, exit back to the main menu. Under Network device support, change the Dummy net driver and Universal

TUN/TAP device driver support options to built-in *.

There are other options to slim down the kernel boot time and size, for example,

Amateur Radio Support, IEEE 1394 Firewire and irDA (Infrared) support. If the motherboard the system is running on does not have firewire installed, you can remove the support for this protocol. Another option to slim down the kernel is to remove Old

CD-ROM drivers (not SCSI, not IDE) from your system since the system should be

95

hosting its CD-ROM on an IDE or SCSI channel; this has not been needed since the early

1990‟s. Finally, another option that can be set here is the processor. This will optimize the kernel for the processor architecture, however, if the wrong processor is setup, the kernel may not boot properly. Once the configuration has been completed, select exit, which will ask to save a new configuration file.

Next as root, execute the following four steps to build and install the kernel in the boot location make dep make clean make bzImage make install

Once installed, two final steps are needed to complete the compilation of the kernel, which is required for the loadable modules, execute the following two commands to build and install the additional kernel modules make modules make modules_install

Inside the /boot directory is where the kernel and loader is stored. The stock kernel that comes with Damn Small Linux is installed as linux24. However, once the new kernel and modules are installed, new vmlinuz and vmlinuz-2.4.XX image files will appear which comprise the new kernel, where XX is the version of the 2.4 kernel downloaded. As the file names are different than the stock kernel, this kernel will not get overwritten.

96

Finally, to boot into the new kernel, the /boot/grub/menu.lst entry needs edited.

The easiest way to perform this is to open the file, make a copy of the first entry and edit the title and kernel locations as shown below in bold. This should resemble: title DSL – New Kernel kernel /boot/vmlinuz root=/dev/hda2 quiet vga=normal noacpi noapm nodma noscsi frugal

Once completed, reboot the system and boot from the DSL – New Kernel entry.

If the system does not boot properly in the new kernel, reboot into the old kernel and repeat the process above checking the processor type and other settings in the kernel configuration for discrepancies. The error that the kernel gives should provide information regarding the cause of the failure. Once the kernel boots successfully, the title can be renamed, and old entries can be removed. However, one entry, such as the original DSL entry, should be left as a fail-safe in case the new kernel does get corrupted.

IC Installing the Simple Directmedia Layer

The Simple Directmedia Layer [57], SDL, is a multimedia library is one of two choices of libraries that is utilized by QEMU to access its graphical layer. The other choice is Cocoa, which is delivered primarily with Apple Macintosh OSX. The SDL library is available in a source code archive from the SDL web site, which the latest version available was 1.2.14 as of the time of this writing, and can be installed by execution the following three commands as the dsl user

./configure

97

make sudo make install

ID Installing Autoconf

In order to provide networking functionality in QEMU, bridged networking needs to be installed, however prerequisites of bridged networking are Perl [58], which has already been installed, and the Autoconf [59] script system. This script system creates the configure scripts needed to build the bridge utility binaries. As of the time of this writing a standalone Autoconf DSL package was not available, however a compile environment package was recently added in testing. This package includes autoconf, m4 as well as other components but was not tested in this setup. Because this environment was not tested, Autoconf can be found as a source code archive and can be extracted and installed by executing the following four commands sudo apt-get install m4

./configure

make sudo make install

At time of writing, the latest version of the source code is 2.68.

IE Installing Bridged Networking

In order to properly configure networking, bridging needs to be installed to create a tunnel between the guest and host network cards so that the guest can have network access. The bridge utilities are provided as a rpm or source module from The Linux

98

Foundation Net:Bridge site [60] and are at version 1.4 at the time of writing. The source version will be used; Download and extract, then from the source directory, execute autoconf

to create the configuration file. Then run the following three commands to install the utilities to their default /usr/local/sbin directory

./configure make sudo make install

Once the bridged networking is created, QEMU and Argos will need a script to start the networking properly. Create a file called argos-ifup with the following:

#!/bin/sh echo “Binding to interface: $1” /bin/ip link set $1 down /bin/ip link set $1 up Sleep 0.5s /usr/local/sbin/brctl addif br0 $1

After that file is written execute chmod 755 argos-ifup to make the script executable and then move it to the /etc directory. Execute the script at least once with

/etc/argos-ifup eth0 to ensure it is working. Some versions of the bridge utilities are incompatible with certain versions of the kernel. If the error “Add bridge failed: Invalid argument” appears when trying to run the brctl addif command which is included in the script, try to download and install a different version of the utilities to see if the problem is corrected.

99

After bridging is installed, the kernel will need a tun tap network device to work.

Check if /dev/net exists and if it does not, execute sudo mkdir /dev/net then check if /dev/net/tun exists and if it also does not exist, execute sudo mknod /dev/net/tun c 10 200 once the /dev/net/tun is located or created, execute sudo chmod 666 /dev/net/tun to allow standard users to use the tun tap.

Next a script will be need to help release the network correctly when QEMU and

Argos shuts down. To do this, create a file called argos-ifdown with the following:

#!/bin/sh /bin/ip link set $1 down Sleep 0.5s /usr/local/sbin/brctl delif br0 $1

Similar to the previous script, execute chmod 755 argos-ifdown to make the script executable and then move it to the /etc directory.

Finally, a script is needed to configure the remaining bridging. This script will initialize the bridge and complete the binding to eth0. The settings will echo the settings in the /etc/network/interface file below. Create a file called setup-bridge with the following:

#!/bin/sh /sbin/ifconfig eth0 down echo 1 > /proc/sys/net/ipv4/ip_forward /usr/local/sbin/brctl addbr br0 /usr/local/sbin/brctl addif br0 eth0

100

/sbin/ifconfig eth0 0.0.0.0 promisc up /sbin/ifconfig br0 192.168.1.40 up

In the script above, the IP address 192.168.1.40 is an arbitrary IP on the same subnet as the guest system and will be seen by the guest system. For this IP, choose a random IP in the network range. Also above, eth0 is representative of the interface that will be utilized by the Argos system which may be different on another system.

Once the script is created, to make it executable, execute chmod 775 setup-bridge

The setup-bridge script will have to be executed once per system boot by executing sudo ./setup-bridge to initialize the bridge or placing the script in the init startup scripts after the network has been started. This script is required before QEMU is started, otherwise the bridge will be incomplete and the guest will not be able to communicate on the network.

IF Configuring the honeypot server network

As with the Snort IDS configuration, the honeypot host will need to be configured to talk to the database server through the one of three available ranges of non-routable IP addresses [17] and correspond to the same network chosen to read the honeypot data on the database server. In this server, the 10.10.10.0 network will be chosen. Also similar to the IDS system, the host server will have to route through the database server to perform updates before a guest is connected.

Besides having to be able to connect to the database server, the host needs to allow the client to be able to communicate to the world. Part of this has been completed

101

in APPENDIX IE, Installing Bridged Networking. However, the bridging interface needs further configuration. To perform this, the /etc/network/interfaces script needs to be replaced with the following, with pieces taken from a QEMU TUN/TAP network bridge guide [61]:

# The loopback network interface auto lo iface lo inet loopback auto eth0 iface eth0 inet dhcp auto eth1 iface eth1 inet static address 10.10.10.200 netmask 255.255.255.0

# The bridge network interface(s) auto br0 iface br0 inet static address 192.168.1.2 network 192.168.1.0 netmask 255.255.255.0 broadcast 192.168.1.255 gateway 192.168.1.1 bridge_ports eth0 bridge_fd 1 bridge_hello 1 bridge_stp off

With this script, eth0 is representative of the network card utilized by the Argos system and eth1 is representative of the network card used by the link to the database server.

APPENDIX J

Installing Argos and QEMU

JA Installing QEMU

The QEMU emulator is relied upon as a base for the Argos project. Argos incorporates QEMU, however, it does not include the full executable to run QEMU by itself; therefore QEMU has to be installed separately.

At the time of writing, the latest version of QEMU is 0.12.4; however Argos, is only compiled against QEMU 0.9.1, and therefore that version will be used. Both of these versions require version 3 of GCC to compile. Although binary packages for

QEMU are available, Argos and its dependencies are compiled from source; therefore

QEMU will be as well and can be obtained from the QEMU web site or Argos [27].

Once QEMU is downloaded and extracted, as the dsl user, execute the following three commands to configure and build QEMU mkdir /opt/argos

./configure --prefix=/opt/argos make then, as the root user, execute make install

102 103

to install to the /opt/argos directory. The /opt/argos directory was chosen over the default

/usr/local directory as the /opt directory is used for optional packages and therefore is less cluttered and easier to maintain.

JB Installing the KQEMU module

Argos integrates QEMU as its emulation layer, however in its basic form; system performance with QEMU alone is slower as code is executed on an emulated CPU. This has been alleviated to an extent for QEMU only by using the KQEMU module. This module is a that allows QEMU to run user mode, and some kernel mode code directly on the host CPU and not on the emulated CPU. KQEMU needs to be downloaded as a separate install from the QEMU web site [34] and used version 1-3.0pre11 for QEMU 0.9.1 for compatibility at the time of writing.

Once the KQEMU module has been downloaded and extracted, execute the following three commands to install the module

./configure make sudo make install

To load the kernel module, execute sudo modprobe kqemu major=250

KQEMU works with a system device called /dev/kqemu. On most systems, this device gets created automatically when the module is loaded; however on some old systems, this device must manually be created after the module is loaded. To create the module execute the following two commands

104

sudo mknod /dev/kqemu c 250 0 sudo chmod 666 /dev/kqemu.

To ensure the KQEMU module is loaded properly, create a script called

/opt/argos/bin/qemu-kqemu-up to automate the above configuration containing:

#!/bin/sh rm /dev/kqemu /sbin/rmmod kqemu /sbin/modprobe kqemu major=250 sleep 5

# Create the KQEMU device mknod /dev/kqemu c 250 0 chmod 666 /dev/kqemu sleep 5

This script will need to run on each boot; whether this is manually, placed in the system init scripts, or included in a QEMU startup script to load before QEMU loads.

Remember to execute sudo chmod 755 kqemu-up before adding to scripts to make it executable.

JC Installing Argos

After a QEMU 9.1 system has been installed and configured in the prior section,

Argos can be overlaid to the 0.4.2-1 release which is compatible with the QEMU 0.9.1, and can be obtained from the Argos web site [27]. Once downloaded, execute the following two commands to install Argos inside the /opt directory

./configure –prefix=/opt/argos make

105

The default installation directory has been changed to coincide with the QEMU default directory as Argos overlays on top of QEMU. After the build has finished, execute sudo make install

JD Dealing with Argos Exceptions

The dynamic taint analysis system that Argos utilizes monitors the network stack as well as the kernel and memory systems and will raise alerts when data is used in illegitimate ways. However, it has been found that in some cases in Linux guest systems, some false positives can be generated on systems that have been compiled with Intel processor MMX extensions which then cause issues with the packet checksum function.

Starting with Argos 0.3.0, a whitelist file has been implemented that will allow these false positives to be identified and recorded so they will not be triggered during normal operation. The whitelist, located at /etc/argos-whitelist, allows the recording of a combination of a virtual address, instruction and guest system to ignore in the format: guest: opcode address with address being prefixed with 0x if it is not in the exception that is thrown and guest being linux for the current honeypot.

One common method to find these exceptions according to the Argos website, is to place the Argos guest system in a secure network where it is known to be secure, and ssh into the guest system which will most likely throw an exception. This exception will have been caused by the ssh and by the checksum and will have been from the ssh attempt which is a false positive.

The exception will be thrown in the format:

106

[ARGOS] Attack detected, PC TARGET

Add the line to the /etc/argos-whitelist file in the same directory as the image, using 0x plus address1 as the address and restart Argos. Finally, perform the ssh test again to see if the exception occurs.

Other standard network tasks can also be performed on open service ports to check for other exceptions within normal operating bounds. It is not recommended to attack the system positives may actually be captured at that point and excluded.

APPENDIX K

Installing the Ubuntu Honeypot

To begin, create the hard drive that Ubuntu will be installed on. This will be a virtual hard drive in an image created by QEMU and placed in a directory under the home directory. First create a directory to store the images and scripts to launch Argos, then from that directory create the hard disk image by executing

/opt/argos/bin/qemu-img create –f qcow ./qemu_ubuntu.img 4G as a non-root user to create a 4GB hard drive file. This will create the image file using the Argos modified qemu-img.

After the image is created, Ubuntu can be installed. Once the 8.04 LTS alternate text-based install CD media has been obtained from the Ubuntu alternative download web site, place the CD in the drive, load the KQEMU module using the script created earlier, then execute QEMU with for the first time by executing the following command sudo /opt/argos/bin/qemu –clock rtc –localtime –m 256 –hda

./qemu_ubuntu.img –no-acpi –no-reboot –boot d –kernel-kqemu – cdrom /dev/cdrom –net nic,vlan=0 –net tap,vlan=0,ifname=tap0,script=/etc/argos- ifup,downscript=/etc/argos-ifdown

Some errors could occur while trying to start QEMU. The first is could not initialize SDL – exiting, this error is usually seen if an incompatible version of SDL has

107 108

been installed. Try to remove the version of the SDL library installed earlier and download an earlier version from the Simple Directmedia Layer website.

If the following message is shown, Could not open '/dev/kqemu' - QEMU acceleration layer not activated, the kernel module or device is not installed properly. To attempt to correct, unload the module by executing sudo rmmod kqemu then delete the /dev/kqemu device, reload the KQEMU module, followed by recreating the device after. Once recreated, try to execute the above QEMU statement again and see if the message has gone away.

If a black screen appears, check to ensure the –clock parameter was specified in the command line and is set correctly. A value of rtc worked properly in this thesis setup and was required to allow QEMU 0.9.1 to function properly in DSL where earlier versions, such as QEMU 0.9.0, functioned without this parameter in testing.

Finally, if presented with a QEMU window with a title QEMU [Stopped], check the shell that launched QEMU. If there is a message could not create temporary file in

„/dev/shm‟ then check to see if /dev/shm is mounted by executing mount. If it is not, it needs to be created in the /etc/fstab file so it can be re-generated on reboot. First, create the directory by executing the following two commands sudo mkdir /dev/shm sudo chmod 777 /dev/shm

Next, edit the /etc/fstab file and add the following line: tmpfs /dev/shm tmpfs defaults,size=576m 0 0

109

The size=576m above must be above the maximum amount of memory that will be allocated to the QEMU and Argos systems. For this configuration, 576MB of memory has been allocated. Minimally, 16MB over the maximum available memory should be allocated, which would be 528MB for a 512MB configuration that was specified above in qemu with the –m switch. Before installing Ubuntu, please check the Ubuntu System

Requirements [62] documentation for minimum processor and memory requirements needed to safely run Ubuntu. As of the time of writing, the bare minimum needed was 64

MB of memory for an alternate install, but recommended was 384 MB. Running the system in an emulator adds overhead to this, slowing down the system overall and increasing memory usage as well, therefore 512MB was allocated to the guest system for a buffer to help keep the system from caching as frequently.

Once the CD boots, five options will be presented. The first is to install Ubuntu.

The second option is to check the CD for defects, the third option is to rescue a broken system, the fourth option is to check the system memory and the last option is to bypass the CD and boot from the first hard drive. If it is known that the memory is good in the system and the CD was created with good media, then choose option 1 to install Ubuntu.

The system will then boot to a simplified installation wizard with seven steps to complete. The first two steps involve language and territory selection, which defaults to

English and United States. Press Enter to continue through both screens. The third step is to detect a keyboard layout. Press Enter on Yes to start the detection process. Follow the prompts on the detection screens and choose Yes or No to determine the keyboard type. Once detection is complete, press Enter on Continue.

110

The installation will then detect installed hardware and prompt for a system hostname. The name of a honeypot is one of the factors to have it targeted. Having a generic computer name can present some interest, however, having a specific name, such as “finance”, could draw more interest. For this thesis, the hostname of “finance” will be chosen. After the name has been set press Enter. The installation will then ask for the current time zone. Choose the correct time zone and press Enter.

At step six, the installation will ask how to partition the disk. As of writing, the bare minimum required space was at least 4GB of disk space for full install and swap space, the recommended space is currently 8GB. When allocating the qemu_ubuntu.img needed for this system, only 4GB was allocated, and since a full install is not going to be performed, to allow the install to succeed, the partitioning also needs to be controlled to allow the most efficient utilization of resources. To do this, on the screen for step 6 to

Prepare Disk Space, choose Manual and press Enter.

Once the Partition Disks screen opens, each partition that exists will be listed under its respective drive in a tree hierarchy with the partition name, type, size and if it is to be formatted. To begin the process, all partitions need to be deleted, therefore select the drive itself which should be listed as SCSI (0,0,0) (sda) – QEMU HARD DISK, or something similar, and press Enter. The system will prompt to create a new empty partition table on this device. Choose Yes and press Enter to clear the existing partitions and list the free space.

Next, click on the new free space and press Enter. The system will ask how to use the free space, choose Create a new partition and press Enter. The first parameter for

111

the partition setup is the size. The first partition that will be created is the swap space which needs to be at least the size of the memory plus a few MB for rounding that occurs during the partitioning process, therefore enter 528 MB in the partition size text box.

Next, the partition type needs to be selected. For this prompt, choose a Primary partition, and then choose Beginning for the location of the partition. The main partitioning dialog will then appear. Select Use as and press Enter to bring up a list of partition types. From the list of types, choose swap area and press Enter. To complete the partition, select

Done setting up the partition and press Enter.

Next, repeat the step above, by clicking the remaining free space and Create a new partition. For the partition size, leave the default size which is the remaining size of the drive and choose another Primary partition. The use as type is ext3 and lastly this time a mount point of / will be chosen to mount the disk as the root partition which are the defaults on the main partitioning dialog. Once completed, choose Done setting up the partitions. The dialog will disappear and two partitions will be shown in the list with the ext3 partition to be formatted. To continue to the next step, select Finish partitioning and press Enter. Finally, choose Yes to write the partition changes to disk.

Once the partitions have been created, the Ubuntu installation will copy the base system to the hard drive.

After the files have been copied, the setup will ask for the user‟s full name and a username. Having a generic user like “system” or “admin” would make the system seem like a standalone server; whereas having a more personal name like “bob” or “susan” would make the system seem like an end user desktop and possibly a better desktop,

112

therefore choose a personal full name and username, such as “Bob Smith” and “bob” to proceed. Next, the setup will ask for a password for this user. Because this system may be compromised, make sure the user‟s password is not the same as what is on the host and is more secure in case some vulnerability is found in virtualization to access the underlying host.

After the user has been setup, the system will configure the packages in the system. It will also prompt for an http proxy. If necessary fill it out, otherwise, leave blank and press Enter. Finally to finish the installation, it will ask if the clock is set to

Universal Time. Choose Yes and press Enter.

Once completed, the system will eject the CD then automatically shutdown, as the

–no-reboot parameter was supplied. Next, boot QEMU again using the same command as before, except edit the parameter –boot d and change it to –boot c. After the system reboots, it will present the Ubuntu login screen. Enter the username and password that was specified during the setup to login as that user. The system will then login to the

GNOME [63] desktop.

A few settings need finalized in the desktop. The first is networking. To configure, choose the System menu, then Administration and Network. When the

Network Settings dialog opens, click Unlock and re-enter the password for the user that is shown to authorize the change and press Enter. Once unlocked, click on the Wired connection and click the Properties button when it becomes available. Remove the checkbox for Enable roaming mode. Once the remaining options become available, under Configuration, change the drop down to Static IP Address. For the IP address,

113

enter 192.168.1.100, for the subnet, enter 255.255.255.0 and finally for the gateway, enter 192.168.1.1 and click OK. The system will return to the Network Settings dialog and reconfigure the network. Next, click on the DNS tab to review existing DNS entries.

By default the system will have inherited any DNS entries from the router. If they exist, highlight each one and click the Remove button. Once removed, click Add to add a new

DNS entry which will present a text box with the wording of Type address in line with the DNS Servers list. On this new line, enter 192.168.1.1 for the new DNS, shared with the router.

After the network has been configured, the Power Management needs to be configured by opening System, then Preferences and Power Management. After the dialog opens, in the first tab On AC Power, change both sliders for Actions and Display to Never then click Close. Next under System, Administration and Services, Unlock the services, then uncheck the CPU Frequency manager and both Power Management services then the Close button when all three are unchecked. Finally, under System,

Preferences, Screensaver, change the preference for Regard system as idle to the maximum of 2 hours, then change the screensaver to Blank screen.

KA Configuring and Updating Ubuntu Software

Once the network and power management has been configured, the software needs to be configured and updated. To begin this process, all applicable software sources need to be enabled. Begin by going to System, then Administration then

Software Sources. Enter the password, then the Software Sources dialog will appear.

Under the Ubuntu Software tab, all sources should be checked by default. Next, under

114

the Third-Party Software tab, the Ubuntu hardy partner selection needs to be unchecked if it is checked. Finally under the Updates tab, remove the checkbox for Check for updates under the Automatic updates section as the system should have as little activity on its own as necessary then click Close. The system may prompt that the information about available software is out-of-date and ask to reload. If this occurs, click the Reload button to continue to download package information then close the Software Sources dialog.

After the software sources have been updated, the installed software can be customized. To add or remove software from the system, the Synaptic Package Manager is used which is located under System then Administration. The introduction is dismissed and new packages need to be installed.

There are three main panes in the package manager. The upper left is the package groupings which displays types of packages, the upper middle is the packages that are included within a particular group and the lower middle is the description of a selected package. With the package manager, new and updated packages need to be installed. To begin this process, select Networking from the group list. When the package list appears on the right, select apach2-mpm-worker them Mark for installation, next in the same list select Samba, ssh and traceroute. Under the Networking (Universe) group, select telnetd and wu-ftpd. Next, click the Mark All Upgrades button and answer the subsequent dialogs to accept changes. Once all packages have been selected, click Apply to start the install and upgrade process which will download and install all necessary files and present a process indicator while it performs this action. During this download process, if

115

the system had not been restarted to ensure power management was turned off; ensure the mouse is moved every few minutes to keep the connection alive.

Once installation of new and updated software completes, the status of the install will display and a Close button will appear. Click Close to close the dialog and return to the Synaptic Package Manager. Close the package manager and reboot Ubuntu for changes to take effect. Note that system updates and changes will only take effect when running under QEMU, however, once the system is running under Argos any changes will not be maintained and will revert once the system is rebooted.

On occasion, new system updates will be released for the system. For these updates, the full Symantec Package Manager does not have to be employed; instead, the

Update Manager can be used. To perform this update, select the Update Manager from the System menu, then Administration. Ubuntu will warn that automatic updates are not enabled, which is the behavior that was chosen earlier in this setup. After the warning, the system will access the update site and download the list of available updates and present them in the Update Manager screen. If the updates do not automatically download, click the Check button to perform the check for updates. Once the updates have been presented, click the Install Updates button. Update Manager will now download all updates that were selected previously, which are all by default. There is an optional arrow to show the progress of individual files. This is useful in the case that a slow connection is used to show the system is progressing faster.

If the system hangs due to lack of activity, the download will freeze then supplemental downloads will start to fail. If this occurs, click Cancel to stop the

116

remaining downloads and then No to the following screen asking to continue. The update system will return to the main Update Manager screen if cancelled. If this occurs, click Install Updates to try again. Any prior updates that were successfully downloaded will be retained and will not be downloaded again. Note that the network connection may have to be reset before updates can be successfully performed. To do this, open a

Terminal from the Applications menu then Accessories. Once the Terminal window opens, execute ifconfig and note the Ethernet card that has the IP address that was assigned above which should be eth0. Once this is determined, execute sudo ifconfig down to stop the interface, where is the Ethernet card determined earlier, such as eth0. The terminal will prompt for the user‟s password again to confirm the command.

After the interface is down, execute sudo ifconfig up to re-enable it. Finally, the gateway IP will need to be re-entered. Type the command sudo route add default gw to add the default gateway address, where is the IP of the gateway that was assigned earlier in the network setup.

After the Update Manager downloads packages for update, it begins applying changes and installing the downloaded software. Click the details arrow to watch the terminal window output as the updates are being applied to the various installed packages.

117

KB Configuring the Ubuntu Honeypot

Once software has been installed and updated, the next configuration option is to change system services. Open System, Administration, Services. When the Services

Settings screen appears, click Unlock and enter the user password to allow selection and deselection of services. After the screen has activated, deselect the following services:

Actions Scheduler (anacron), Actions Scheduler (atd), Automated crash reports support

(apport), Bluetooth device management (Bluetooth), CPU Frequency manager

(powernowd), Hotkeys management (hotkey-setup), Power Management (acpid), Power

Management (apmd), Printer Service (cupsys). Next, the Folder sharing service (samba),

FTP Service (wu-ftpd) and Web Server (apache2) service need to be enabled if they are not already enabled. These services are not needed for the guest system and will improve both the performance and stability of the guest system within Argos.

Configuration refinements can be performed to the system to enhance its ability to entice potential intruders such as configuring samba shares and adding users protecting you from legal issues such as possible entrapment by implementing login banners stating the system is being monitored and that there is no expectation of privacy.

For the login banner, a ssh banner will be put in place. First, edit the

/etc/ssh/sshd_config file and remove the comment from the line #Banner /etc/issue.net.

Next, create edit the file /etc/issue.net and add a message stating that the system is being monitored without expectation of privacy. A good example can be found at the

AdvancedOpenSSH site[64] with the NOTICE TO USERS message. After the message

118

is in place, execute chmod 644 /etc/issue.net so it is readable by other users and restart the sshd service to enable the banner.

Next, configure samba and shares for file sharing. Under the /var directory, create a directory called share, and then under that directory, create ftmfiles and public. These are the supporting directories for a public share and writable office share. Once created, execute the following three commands chown –R nobody:sambashare /var/share/ftmfiles chown –R nobody:sambashare /var/share/public chmod –R 777 /var/share to correct permissions on the folders. Setup the shares by backing up the

/etc/samba/smb.conf file and then changing the contents to:

# Global parameters [global] workgroup = OFFICE server string = Finance File Server log file = /var/log/samba/%m.log max log size = 500 dns proxy = no wins support = yes cups options = raw syslog = 0 encrypt passwords = true passdb backend = tdbsam obey pam restrictions = yes invalid users = root unix password sync = yes passwd program = /usr/bin/passwd %u passwd chat = *Enter\snew\s*\spassword:* %n\n *Retype\snew\s*\spassword:* %n\n *password\supdated\ssuccessfully* . pam password change = yes map to guest = bad user

[homes] comment = Home Directories path = /home/%u

119

read only = no create mask = 0664 directory mask = 0775 browseable = No

[printers] comment = All Printers path = /usr/spool/samba printable = yes browseable = no guest ok = no read only = yes create mask = 0700

[ftmfiles] comment = Funds Tracking path = /var/share/ftmfiles write list = +smbusers read only = No create mask = 0660

[public] path = /var/share/public force user = nobody guest ok = Yes

This will configure samba to use these new folders as well as setup personal shares for each individual users to their home directory. Finally, new users need to be added to the system and placed into the smbusers group as well as added into samba.

This can be done at the same time by executing the following three commands useradd –m –G smbusers –c “User Name” userid passwd userid smbpasswd –a userid

Note: for the passwd and smbpasswd commands, use the same password. Also in the above commands, userid represents a unique id to create, such as jsmith, and user name is a full friendly name, such as John Smith. Repeat these commands for a few unique id‟s

120

to add to the system. If a user is already in the system, such as the system user configured in the initial setup, then just the smbpassword needs to be set with the password being the same as the password for that user.

Once users have been added and samba is configured, restart the smb services and browse to them from a Windows machine to verify that shares exist. It will prompt for a username and password to see the shares, which will be a user and password that was created above.

Before the system can be run under Argos, perform one final configuration to disable ACPI power management support when the system boots from the kernel via the grub loader, the process that boots the system. Although power management was adjusted earlier, the kernel was not changed due to the updates that were performed after.

To disable ACPI, open a terminal from Applications then Accessories. Once the terminal opens, edit the grub menu by executing sudo vi /boot/grub/menu.lst

Once the menu opens, find the lines that begin with kernel towards the bottom of the file. At the end of those lines, which will wrap to the next line, add a space followed by acpi=off noacpi to stop the acpi from loading.

Once the base installation is complete and configuration changes have been completed using QEMU, Argos can now be used to run the system. The script below will start Argos with the proper parameters:

#!/bin/sh # Launch Argos /opt/argos/bin/argos –clock rtc –linux –localtime –m 256 – snapshot –hda ./qemu_ubuntu.img –no-acpi –no-reboot –boot c –net

121

nic –net tap,ifname=tap0,script=/etc/argos- ifup,downscript=/etc/argos-ifdown

The script will launch Argos with the network, 512MB of memory in snapshot mode, which will open the Ubuntu image in read-only mode causing all changes to be written to a temporary file. This prevents corruption of the image while Argos is running and allows for a clean image to be maintained. However, to maintain the image for patches and configuration changes, QEMU will have to be re-launched to open the image for writing to hold updates. One downside is that any malware possibly saved to the system will be lost when the system is rebooted as well. If the system runs stable after a few days, the –snapshot parameter may be removed which will run the system without snapshot mode, saving changes in the image itself. If this is done, it is advisable to make a backup of the qemu_ubuntu.img image before starting Argos the first time just in case it gets corrupted.

APPENDIX L

Installing the Windows XP Honeypot

In the images directory created earlier, create a new hard disk image by executing

/opt/argos/bin/qemu-img create –f qcow ./qemu_windowsxp.img 4G as a non-root user to create a 4GB hard drive file.

Next, begin the Windows XP installation by placing the CD in the drive, make sure the KQEMU is not loaded for the installation, then start QEMU by executing sudo /opt/argos/bin/qemu –clock rtc –localtime –m 256 –hda

./qemu_windowsxp.img –no-acpi –no-reboot –boot d –cdrom

/dev/cdrom –net nic,vlan=0 –net tap,vlan=0,ifname=tap0,script=/etc/argos- ifup,downscript=/etc/argos-ifdown

On the first screen, Windows setup asks to press F6 if you need to install a third party driver, press F5 here instead to be presented with a list of computer types to install.

If this prompt does not appear, restart the installation and press F5 again. Scroll through the list using the cursor keys, highlight “Standard PC” and press Enter. Selecting this will disable ACPI power management inside Windows XP that corresponds to the –no- acpi command prompt for QEMU. If a Windows error message

PAGE_FAULT_IN_NONPAGED_AREA appears during setup, then the KQEMU module is active. This must not be running during installation, make sure this is unloaded and the –kernel-kqemu switch should not be passed to QEMU.

122 123

Continue the Windows setup using standard values, selecting the 4GB partition that was created and formatted with NTFS. After a quick format of the virtual hard drive,

Windows will copy the install files from the CD and shutdown.

Run the QEMU command again to continue the setup, allowing it to proceed to the hard drive by not pressing any keys at the CD prompt. Setup will continue with installing Windows and present and estimated time to complete which will most likely be off since this setup is running inside a virtual machine that is not running at full capacity.

Once setup reinitializes, and installs the QEMU devices, it will ask for a name and product key. Next, a computer name and administrator password is required. As described earlier, a strong password is desired for the administrator account, as this account is highly desired by an intruder.

Next, the network card and stack will be installed and configured. If the honeypot was exposed on the demilitarized zone before, it is a good idea at this point to disable it until the system is completely setup, as even a partially patched Windows XP system with only Service Pack 1 has been shown to be compromised in 6 minutes [65]. Once the automatic configuration of the network card is complete, setup will prompt for typical or custom settings. Choose custom settings and click Next. Earlier, the Ubuntu honeypot had been assigned an IP address of 192.168.1.100 and correspondingly, the startup scripts for networking and DMZ port all reflect this subnet and IP address. Therefore, for the sake of simplicity, this IP and subnet will also be chosen for the Windows XP system.

Some versions of Windows setups prompt for a network configuration at this point. If the network components screen appears, highlight Internet Protocol (TCP/IP)

124

and click Properties. Next, click the radio button for Use the following IP address to enable the custom IP address, and enter 192.168.1.100 for the IP address, 255.255.255.0 for the subnet, and 192.168.1.1 for the gateway address. Once the IP has been set, click the radio button for Use the following DNS server addresses if it is not already selected, and enter 192.168.1.1 for the Primary DNS server. When completed, click OK to close the TCP/IP settings and then click Next to configure the Networking Components.

The next question asks to identify a domain or workgroup. Since the Ubuntu honeypot Samba configuration was in the OFFICE workgroup, the same will be chosen for this configuration. After this completes, setup will copy the necessary files and register components that Windows needs to operate properly. Setup will save these settings then shutdown.

The final portion of the Windows setup is the first system run, which does final user and system configuration steps and can also be run with the kqemu accelerator module. To begin, enable the KQEMU module by executing sudo /opt/argos/bin/qemu-kqemu-up then re-start QEMU using the same parameters as the previous setup. First, if prior to

Service Pack 2, it will prompt if this system is directly connected to the network, choose the default yes here and click Next, otherwise it will ask if it is connected to a cable/DSL modem, or local area connection, select local area connection and click Next. If a network connection cannot be determined, setup may now prompt for network IP information. Enter this information and click Next. The subsequent question is registering with Microsoft. This is optional. For this thesis, choose No and click Next.

125

After the network is configured, setup prompts for names of users who will access the computer. This is similar to the adding of users in the Ubuntu system with the useradd and smbpasswd commands that were performed earlier. Supply the system with at least one or two user names to show that it is being utilized properly. Once completed, the system will display the login screen and present a list of the users which were just created, except administrator.

LA Fixing Windows Updates and User Security

By default, all users created during setup have administrator rights which need to be corrected. First, log onto the system as the administrator account. Since this account is not displayed on the welcome screen, press CTRL + ALT + 2 to enter the QEMU monitor, then type sendkey ctrl-alt-delete twice at the monitor prompt and finally CTRL

+ ALT + 1 to return to the Windows GUI. This has effectively sent two CTRL + ALT +

DELETE commands to Windows since pressing those keys directly will logout of the host Damn Small Linux host system. When returned to the GUI, a username and password prompt will be presented. At this prompt, change the user to administrator and enter the password provided during setup to login as the administrator user.

Once the administrator user logs into the system, open the Control Panel and then click on Switch to Classic View. Next, double click on Automatic Updates, and then change updates to Turn off Automatic Updates and click OK.

Upon returning to the control panel, double click on Administrative Tools and then on Computer Management. The Computer Management console will open for the local computer and present two panes of options. In the option hierarchy in the left pane,

126

click on the + next to System Tools if it is not already expanded, then click the + next to

Local Users and Groups. Click on the Users folder and the right pane will present a list of the users in the system which will include Administrator, Guest, support account, help account and the accounts that were created earlier.

First, passwords need to be set on the accounts that were created. To do this, right-click on each user name and select Change Password from the menu. Proceed past the warning and on the password screen, enter a secure password as described earlier and confirm the password, then click OK to set the newly created password. Once passwords have been established, the users need to be removed from the administrator group and reassigned as standard users. To do this, click on Groups in the left pane to display a list of all the built-in groups in the right pane. Double-click the Administrators group to open the properties which will present a list of users in that group. Highlight a user that needs to be removed and then click the Remove button. Once all users, except Administrator, have been removed, click OK. Next, double-click on the Users group top open the users list. Click on the Add button to open the Select Users dialog box. To avoid typing in all the names, click Advanced. In the advanced Select Users dialog, click Find Now to return a list of all known users on the system. It will return a list of the users as well as other objects as their Name, and their location. Highlight all users that were added earlier using CTRL click on each user and once highlighted, click OK. The advanced dialog will disappear and a list of users will appear in the Select Users dialog box separated by semi-colons. If all the users are not listed, repeat the advanced step and select the correct users. Finally, click OK to add the new users to the Users group.

127

LB Making Administrator login easier with QEMU

As Windows does not allow direct selection of the Administrator account from the Welcome Screen by default, there are two ways to correct this if switching to the

QEMU console is not the preferred way to log in as that user as was done to first log in.

The first is to change the type of login and remove the Welcome Screen. Once this is done, all user names and passwords will have to be typed in manually. This can be set in the Control Panel, under User Accounts. The second option is to download a utility to set which accounts can be shown on the Welcome Screen. The third and final option is to edit a setting in the registry to allow the account to be shown. To perform this option, first open the registry editor by selecting Run from the start menu, then entering regedit and clicking OK. Once the Registry Editor opens, expand HKEY_LOCAL_MACHINE by clicking the + next to it. When the tree opens, expand each level to Software,

Microsoft, Windows NT, CurrentVersion, Winlogon, SpecialAccounts, UserList. The status bar should read:

My Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows

NT\CurrentVersion\Winlogon\SpecialAccounts\UserList

The right pane should list names such as HelpAssistant and IUSR_. This is the location in the registry where the Welcome Screen determines if it should display an account or not. By default Administrator is implied to be disabled or 0, and other accounts are enabled or 1. First, add the Administrator account if it does not exist, from this location, click Edit, then New, DWORD Value. When the new value appears in the right pane and is highlighted, change the name to Administrator, which is case sensitive.

128

Next, double-click on the new Administrator value and change the DWORD Value from

0 to 1. Although multiple places on the internet demonstrate this method of showing or hiding a user account, one example which also shows screenshots is on the IntelliAdmin tips web site [66] to hide user accounts from the welcome screen. Once this is complete, the next time the Welcome Screen is shown, the Administrator account will appear.

LC Windows Service Pack Installation

Now that account access has been established, Windows need to be patched to

Service Pack 2, if it has not already been integrated, then patched to Service Pack 3, which is the latest service pack released at the time of writing, to prevent old vulnerabilities from being utilized on this system. Since the system is not safe to put on the network and would be compromised before it downloads the service packs, they need to be manually downloaded from the Microsoft Windows XP Service Pack 2 [67] and

Service Pack 3 [68] web pages on another computer and copied to the honeypot. Once both service packs are downloaded, burn then onto a CD

To install, put the newly created CD in the drive of the host system and show down QEMU. Next, restart QEMU by executing sudo /opt/argos/bin/qemu –clock rtc –localtime –m 256 –hda

./qemu_windowsxp.img –no-acpi –no-reboot –boot c –kernel-kqemu – cdrom /dev/cdrom –net nic,vlan=0 –net tap,vlan=0,ifname=tap0,script=/etc/argos- ifup,downscript=/etc/argos-ifdown

129

which will start QEMU with the default boot device to be the hard drive instead of the

CD and enabling the KQEMU module if it is loaded. Once Windows boots, login using the Administrator account, which if the registry settings were changed above, should now appear in the Welcome Screen.

First, run the Service Pack 2 installation if Service Pack 2 was not already integrated into the installation by executing the WindowsXP-KB835935-SP2-ENU.exe from the CD. This will start extracting the setup files to the hard drive and begin the setup. Click Next at the welcome screen, then select I Agree to the license agreement, and finally Click Next on the default uninstall location. The setup will then perform steps to update the system and finally prompt that it has completed and needs to reboot the system. Once the QEMU emulator shuts down, which could take a few minutes for

Windows to respond to the restart request, restart it again using the same parameters as before to complete the final stages of Service Pack 2. Once the computer reboots, a setup screen will ask to sign up for automatic updates. Choose the Not right now prompt and click Next to continue to the login screen.

After Service Pack 2 is installed or if the installation had Service Pack 2 integrated, Service Pack 3 now needs to be installed. This should be similar to Service

Pack 2 installation above, however the filename for the service pack should be

WindowsXP-KB936929-SP3-X86-ENU.exe.

LD Securing Windows XP

Since the idea of a honeypot is to lure an attacker, the system should not be secured to the point where it cannot be further exploited, however, it should not be left

130

completely open either as to make it seem that it was setup for this purpose, therefore a balance needs to be defined. Windows XP, out of the box, is not an inherently secure environment. Services are enabled that can be exploited along with insecure applications that can cause viruses and Trojans to be installed easily to compromise a system and cause a breach in the network. There are many ways to secure these systems from basic methods including installing virus and spyware scanning and monitoring software to disabling as many services as possible to keep the system running and only allow specific applications to execute. As Windows XP is used in a multitude of environments, there are many guides on how to do this. One of these is a report called the SP 800-68

Revision 1, Guide to Securing Microsoft Windows XP Systems for IT Professionals [69] which was sponsored by the Department of Homeland Security and the National Institute of Standards and Technology, to small guides such as Windows XP: Your Definitive

Lockdown Guide [70] from WindowsSecurity.com which provides a quick summary on steps to secure a system.

There are commonalities between these reports as well as other recommendations for Windows XP configurations. Of these commonalities, one that stands out is disabling unnecessary services for the honeypot, which will be minimal and is only performed for performance gains in the QEMU emulator. Another recommendation would be to add virus and spyware protection software; however since this is a honeypot, that may block attacks from occurring and therefore no data could be gathered.

131

LE Enabling and Disabling Windows system services

Once the machine has been installed and initially configured, log on as an administrator and open the Control Panel, then Administrative Tools and finally Services.

Once the services list opens, double-click on Application Layer Gateway Service. Once the service dialog opens, change the startup type to Disabled; next if the Service status is

Started, then click Stop; and finally, click OK to close the dialog. Perform the same for

Automatic Updates, Computer Browser, Fast User Switching Compatibility, Help and

Support, IMAPI CD-ROM COM Service, IPSEC Services, Indexing Service, Print

Spooler, QoS RSVP, Security Center, SSDP Discovery Service, Themes, WebClient,

Windows Audio, /Internet Connection Sharing (ICS), and Wireless

Zero Configuration. Next, while the Services list is open, double-click on Telnet, then change the startup type to Automatic and click Apply. Finally, once the Start button becomes enabled, click Start to start the service.

One more service that can be disabled is the System Restore Service as this is not needed for our setup; however, this has to be done from a different location. To turn off this service, open the Control Panel, and then open System. After the System Properties dialogue opens, click on the System Restore tab and then check the box to turn off

System Restore. Again, there is one final service that can also be enabled which is the

Remote Desktop service. To enable this service, click on the Remote tab, then check the box in the Remote Desktop section to allow users to connect remotely to this computer.

Finally, click OK to close the system dialog.

132

LF Internet Information Services and file security

Once the system has been installed, virus tools configured and services disabled, one final system installation component is Microsoft Internet Information Services. This will provide web services and setup a default homepage to lure further types of attacks.

To install this, open the Control Panel, then Add or Remove Programs, then Add/Remove

Windows Components. When the Windows Components Wizard opens, click and highlight Internet Information Services (IIS), then click Details. Once IIS Details opens, select File Transfer Protocol Service, deselect SMTP Service and then click OK. Finally, once the IIS details screen closes, click Next to begin copying the files necessary for IIS.

If the system prompts for the Windows XP CD, switch to the console with

CTRL+ALT+2 and enter eject –f cdrom to eject the CD, then insert the Windows XP CD and enter change cdrom /dev/cdrom to load the new CD. Finally switch back to the GUI with CTRL+ALT+1, exit the

Welcome to Windows XP screen if it appears, and click OK to start copying files. Once the setup completes, click finish, then close Add and Remove Programs and eject the CD from the QEMU console.

At this point, a default Under Construction web page can be seen by entering the

IP address of the honeypot, which was defined earlier, into the web browser at another computer. If this appears, IIS is running properly.

133

The next setup step is to turn off simple file sharing. By default Windows assumes to setup the guest as the default user for sharing and that sharing is permitted across the board. This needs to be adjusted to allow regular file sharing to the system will prompt for both a user and password at all times and give access to the shares of the system. In order to change this, open My Computer, then go to Tools, then Folder

Options. When the folder options appear, select the View tab and scroll to the bottom of the Advanced settings. Next, deselect the checkbox for Use simple file sharing

(Recommended) and click OK. The next time the system is accessed via a UNC mapping, it will prompt for both the username and password.

LG Running the Windows honeypot under Argos

Once the honeypot has been configured inside of QEMU, then it is ready to be setup inside Argos. Similar to the script provided for the Ubuntu honeypot, the script below will start Argos with the proper parameters:

#!/bin/sh # Launch Argos /opt/argos/bin/argos –clock rtc –winxp –localtime –m 256 – snapshot –hda ./qemu_windowsxp.img –no-acpi –no-reboot –boot c – net nic –net tap,ifname=tap0,script=/etc/argos- ifup,downscript=/etc/argos-ifdown

First unload the kqemu module if it is loaded memory as mentioned in the Ubuntu honeypot, then launch the script to run the Windows honeypot. The script will launch

Argos with the network, 256 MB of memory in snapshot mode, which will open the

Windows image in read-only mode causing all changes to be written to a temporary file.

Once the system is running, check the system for known false positives which was done with the Linux earlier and is thrown in the format:

134

[ARGOS] Attack detected, PC TARGET

To find these codes, perform normal network activity to the Windows honeypot, such as a telnet, remote desktop or samba file access and see if an exception is thrown. It is possible that one will not be found, however, if it is, add the line to the /etc/argos- whitelist file in the same directory as the image, using 0x plus address1 as the address and restart Argos. Note, it is not recommended to attack the system as actual positives may be captured and excluded.

APPENDIX M

Testing honeypot configurations

MA Performing a system scan with Nmap

The first of these tools is Nmap [36] from insecure.org. From a computer system outside this setup, an Nmap [36] scan will be performed. Execute nmap -sT -sU -T5 -O -v where is the IP address of the honeypot. It will then scan the honeypot for open ports, as well as deploy configured alerts on the IDS system for a port scan on each port detected. Those alerts become logged to the database system and subsequently exposed in the BASE system, as configured earlier. The output from the Ubuntu honeypot should look similar to the following:

Starting Nmap 5.50 ( http://nmap.org ) at 2011-02-10 19:22 Eastern Standard Time Initiating Ping Scan at 19:22 Scanning 192.168.1.100 [4 ports] Completed Ping Scan at 19:22, 0.00s elapsed (1 total hosts) Initiating Parallel DNS resolution of 1 host. at 19:22 Completed Parallel DNS resolution of 1 host. at 19:22, 0.09s elapsed Initiating UDP Scan at 19:22 Scanning 192.168.1.100 [1000 ports] Warning: 192.168.1.100 giving up on port because retransmission cap hit (2). Increasing send delay for 192.168.1.100 from 0 to 50 due to 11 out of 18 dropped probes since last increase. Discovered open port 137/udp on 192.168.1.100 UDP Scan Timing: About 19.57% done; ETC: 19:24 (0:02:07 remaining) UDP Scan Timing: About 37.20% done; ETC: 19:24 (0:01:43 remaining)

135 136

UDP Scan Timing: About 53.77% done; ETC: 19:24 (0:01:18 remaining) UDP Scan Timing: About 71.57% done; ETC: 19:24 (0:00:48 remaining) Completed UDP Scan at 19:25, 171.24s elapsed (1000 total ports) Initiating Connect Scan at 19:25 Scanning 192.168.1.100 [1000 ports] Discovered open port 21/tcp on 192.168.1.100 Discovered open port 80/tcp on 192.168.1.100 Increasing send delay for 192.168.1.100 from 0 to 5 due to 11 out of 17 dropped probes since last increase. Connect Scan Timing: About 20.73% done; ETC: 19:27 (0:01:59 remaining) Connect Scan Timing: About 39.47% done; ETC: 19:27 (0:01:34 remaining) Connect Scan Timing: About 61.17% done; ETC: 19:27 (0:00:58 remaining) Connect Scan Timing: About 77.93% done; ETC: 19:27 (0:00:34 remaining) Completed Connect Scan at 19:27, 143.80s elapsed (1000 total ports) Initiating OS detection (try #1) against 192.168.1.100 Nmap scan report for 192.168.1.100 Host is up (0.00027s latency). Not shown: 992 filtered ports, 854 open|filtered ports, 151 closed ports PORT STATE SERVICE 21/tcp open ftp 80/tcp open http 137/udp open netbios-ns Device type: general purpose Running: Linux 2.6.X OS details: Linux 2.6.15 - 2.6.26 Uptime guess: 0.125 days (since Thu Feb 10 16:26:53 2011) Network Distance: 1 hop TCP Sequence Prediction: Difficulty=201 (Good luck!) IP ID Sequence Generation: All zeros

Read data files from: C:\Program Files\Nmap OS detection performed. Please report any incorrect results at http://nmap.org/submit/ . Nmap done: 1 IP address (1 host up) scanned in 317.56 seconds Raw packets sent: 2808 (81.809KB) | Rcvd: 191 (11.168KB)

The output from the Windows XP honeypot should look similar to the following:

137

Starting Nmap 5.50 ( http://nmap.org ) at 2011-02-11 18:17 Eastern Standard Time Initiating Ping Scan at 18:17 Scanning 192.168.1.100 [4 ports] Completed Ping Scan at 18:17, 0.06s elapsed (1 total hosts) Initiating Parallel DNS resolution of 1 host. at 18:17 Completed Parallel DNS resolution of 1 host. at 18:17, 0.05s elapsed Initiating UDP Scan at 18:17 Scanning 192.168.1.100 [1000 ports] Increasing send delay for 192.168.1.100 from 0 to 50 due to 77 out of 192 dropped probes since last increase. Warning: 192.168.1.100 giving up on port because retransmission cap hit (2). Discovered open port 137/udp on 192.168.1.100 Completed UDP Scan at 18:19, 92.19s elapsed (1000 total ports) Initiating Connect Scan at 18:19 Scanning 192.168.1.100 [1000 ports] Discovered open port 3389/tcp on 192.168.1.100 Discovered open port 80/tcp on 192.168.1.100 Discovered open port 21/tcp on 192.168.1.100 Discovered open port 445/tcp on 192.168.1.100 Discovered open port 135/tcp on 192.168.1.100 Discovered open port 139/tcp on 192.168.1.100 Discovered open port 443/tcp on 192.168.1.100 Discovered open port 23/tcp on 192.168.1.100 Completed Connect Scan at 18:19, 40.11s elapsed (1000 total ports) Initiating OS detection (try #1) against 192.168.1.100 Retrying OS detection (try #2) against 192.168.1.100 Nmap scan report for 192.168.1.100 Host is up (0.0080s latency). Not shown: 985 filtered ports, 710 closed ports, 296 open|filtered ports PORT STATE SERVICE 21/tcp open ftp 23/tcp open telnet 80/tcp open http 135/tcp open msrpc 139/tcp open netbios-ssn 443/tcp open https 445/tcp open microsoft-ds 3389/tcp open ms-term-serv 137/udp open netbios-ns Device type: general purpose|media device|specialized Running (JUST GUESSING): Microsoft Windows XP|Vista|2000|2003|PocketPC/CE (96%), Microsoft embedded (88%), Motorola Windows PocketPC/CE (87%) Aggressive OS guesses: Microsoft Windows XP SP3, Server 2003, or

138

Vista SP1 (96%), Microsoft Windows 2000 Server SP4 or XP Professional SP3 (96%), Microsoft Windows XP SP2 or SP3 (95%), Microsoft Windows 2000 SP4 (95%), Microsoft Windows Server 2003 SP0 or Windows XP SP2 (95%), Microsoft Windows XP SP2 (95%), Microsoft Windows XP SP3 (95%), Microsoft Windows Server 2003 SP1 or SP2 (94%), Microsoft Windows Server 2003 SP2 (93%), Microsoft Windows 2000 Server SP4 (92%)

No exact OS matches for host (test conditions non-ideal). Network Distance: 1 hop TCP Sequence Prediction: Difficulty=263 (Good luck!) IP ID Sequence Generation: Incremental

Read data files from: C:\Program Files\Nmap OS detection performed. Please report any incorrect results at http://nmap.org/submit/ .

Nmap done: 1 IP address (1 host up) scanned in 140.80 seconds Raw packets sent: 1848 (57.349KB) | Rcvd: 1007 (56.859KB)

When finished, access the BASE web site that was setup earlier. From a newly installed BASE system, TCP traffic should show about 38% and Port scan Traffic should appear in the last progress bar about 62% or similar numbers if no other alerts have been fired in this time as well. If percentage next to the Port scan label is selected, it will pull all alerts related to Port scans. In the list of rule that have fired, Open Port: and

TCP port scan: X:Y rules will be listed, where is a port that has been determined to be open, and X and Y are the start and end ranges respectively that the scan took place.

MB Checking the system with Nessus

The second tool utilized in testing this thesis is the Tenable Security Nessus

Scanner [37]. Download and install Nessus on a separate system outside of the setup that can be used for scanning and register it for free updates. Once installed, register the

139

server, then update the plugins, configure a user and start the server on localhost, finally open the client and Connect to the localhost server.

In the Nessus client, add a new policy to scan the honeypot machine. In the new policy, enter a name to save the policy under such as Linux Honeypot Policy or Windows

Honeypot Policy. Next, under the Scan section, remove the checkbox next to Safe checks. Next, in the Port Scanners section, ensure the check boxes for all scanners except

UDP Scan are explicitly checked, UDP Scan may automatically be checked based on a dependency to the TCP Scanner.

To test the Ubuntu Linux honeypot, under Plugins Selection, uncheck CISCO,

Netware and Windows : Microsoft Bulletins. Next, the following Local Security Checks can also be unchecked: AIX, Debian, FreeBSD, Gentoo, HP-UX, MacOS X, Mandriva,

Solaris, VMWare ESX and possibly the checkboxes related to Windows even though the smb service might be triggered by a couple of those.

To test the Windows XP honeypot, under Plugin Selection, uncheck CISCO,

Default Unix Accounts and Netware. Next, the following Local Security Checks can be unchecked: AIX, CentOS, Debian, Fedora, FreeBSD, Gentoo, HP-UX, MacOS X,

Mandriva, Red Hat, Slackware, Solaris, SUSE, Ubuntu. And VMWare ESX. Once the policy is configured, click Submit to make it available for scanning.

Next, add a new Scan with the honeypot machine as a single host as the Scan

Name and Target as well as a policy that was defined earlier to scan the honeypot with.

Since this is a local test, reboot the Argos machine to restore the honeypot machine.

Nessus will then run a battery of tests against the honeypot, checking for vulnerabilities

140

which will also fire numerous alerts on the IDS and log numerous packets in the database. After the sample scan, at the time of writing, 96 alerts were added to the system, most of which were TCP. Nessus also provides a detailed report of the ports that it found, which should resemble the port listing returned from nmap previously; however, it also expands on this by providing detail results of each test that was performed on the ports and the severity of the test.

MC Using the Metasploit Framework to test known vulnerabilities

The third tool which will be utilized for testing this setup is the Metasploit

Framework [38]. It is a compilation of tools, libraries and modules that have been developed by security researchers to perform various tests, such penetration tests which can be used to check the configuration of a system such as the honeypot. Using the computer that was used to run the Nessus scan above, download and install Metasploit then perform an online update to check for and install new modules.

The results from the Nessus scan above can help determine what tests need to be performed in order to check the machine. For example, on the Ubuntu Linux honeypot, the results show that Microsoft-ds samba port 445 is open on the honeypot, therefore the linux samba lsa_transnames_heap vulnerability may apply; on the Windows XP honeypot, the results show also that Microsoft-ds SMB port 445 is open on the honeypot, therefore the Windows denial of service ms09_001 vulnerability may apply.

To automate a scan and attack, open a Metasploit console, and connect the

PostgreSQL database [71] which was installed with Metasploit by executing db_connect :@127.0.0.1/metasploit3

141

where and are the username and password to connect to the metasploit3 database. If the username or database does not exist, Metasploit will throw a connection error. If the database is empty, Metasploit will populate the database instance with the proper schema to store information using the user and password provided. Once connected to the database, execute db_nmap -sT -sU –sV -T5 -O -v where is the ip address of the honeypot. This will initialize an internal nmap scan similar to the one executed earlier and store the results internally within Metasploit. If the results of the database need cleared and re-created execute the following three commands db_disconnect db_destroy db_connect

Once the database is re-created, a db_nmap command will have to be re-run to populate the hosts. After the db_nmap command launches the nmap process inside

Metasploit, there will not be any feedback when this completes as it returns back to the console immediately, therefore utilize windows task manager and watch for the nmap.exe process to stop before continuing.

Once an db_nmap has been performed, to start exploiting the system to check for vulnerabilities, execute db_autopwn –e –p –b

142

to run the autopwn module to exploit the systems that were scanned in the database using port-based matching on rules and using a bindshell payload to inject into the system.

Another option would be to execute db_autopwn –e –p –x –r to run the autopwn module using vulnerability reference and port matching and using a reverse connect shell. Once this is executed, you will be able to see different jobs being created under the Metasploit Framework GUI as well as output from the different exploits being sent to the console.

Once the scan is completed, execute sessions –l to see if any sessions have been established with the honeypot. If there were any sessions, they will be numbered with a description and tunnel direction. Finally to connect to a session, execute session –i <#> where <#> is the number in the session list.

Another method of testing utilizing Metasploit is a third party GUI called

Armitage [72] which provides a more user-friendly GUI to perform penetration testing.

Armitage has been included as part of the deployed Metasploit package since version 3.5, however, there is no shortcut defined for it, therefore it needs to be launched manually using an armitage.bat file from the Metasploit\framework directory where Metasploit was installed. If this file does not exist, follow the directions on the Armitage web site to create it.

143

Once Armitage is launched, it will present a dialog to connect to the database which was created above with the db_connect command. Select the postgresql driver and enter the appropriate credentials in the connect string. If Metasploit is not running click the Start MSF button to start the Metasploit server and connect, otherwise, click Connect to connect to a running server.

Armitage will present a window with three panes. The left is similar to the

Metasploit GUI in that it lists the exploits and payloads that can be run in the system as well as a search system for them. The Right is a list of systems that have been found by either a db_nmap, or import of nmap or Nessus results. The bottom is the results pane and a Metasploit console. After opening the system that was found earlier will appear in the left pane and identified with an operating system icon. To test this system, first it needs analyzed to determine what types of attacks can be performed. To do this, choose

Attacks, Find Attacks, By Ports from the Menu. Armitage will analyze the systems that have been found then add a new menu to each system listing the types of attacks it believes can be used based off the ports that were opened.

Once the attack list is presented, perform attacks on the machine. If any are successful, the monitor icon that represents each host will change from grey to red indicating that it has been compromised.

REFERENCES

[1] Merriam-Webster, "Merriam-Webster OnLine," in Merriam-Webster OnLine Springfield, MA, 2007 http://www.m-w.com/ [2] L. Spitzner, Honeypots: Tracking Hackers. Boston, MA Addison-Wesley Professional, 2002. [3] T. Bradley, "Zero Day Exploits: Holy Grail Of The Malicious Hacker." vol. 2011: About.com, 2003, pp. The Holy Grail for malicious program and virus writers is the “zero day exploit”. A zero day exploit is when the exploit for the vulnerability is created before, or on the same day as the vulnerability is learned about by the vendor. By creating a virus or worm that takes advantage of a vulnerability the vendor is not yet aware of and for which there is not currently a patch available the attacker can wreak maximum havoc. http://netsecurity.about.com/od/newsandeditorial1/a/aazeroday.htm [4] StillSecure, "Strata Guard - Intrusion detection / prevention system (IDS/IPS) - StillSecure." vol. 2011 Superior, CO, 2011, pp. The award-winning Strata Guard® high-speed intrusion detection/prevention system (IDS/IPS) gives you real-time, zero-day protection from network attacks and malicious traffic http://www.stillsecure.com/strataguard/overview.php [5] Tripwire, "Tripwire IT Solutions," Portland, OR, 2011 http://www.tripwire.com/information-security/ [6] M. Roesch, "Snort," 2.9.0.3 ed Columbia, MD SOURCEfire, 2010, pp. Snort - the defacto standard for intrusion detection/prevention http://www.snort.org [7] SOURCEfire, "Sourcefire Network Security," Columbia, MD, 2007 http://www.sourcefire.com [8] Novell, "openSUSE.org." vol. 2009: Novell, 2009 http://en.opensuse.org/ [9] "MySQL :: Developer Zone," 5.1.42 ed. vol. 2010 Cupertino: Sun Microsystems, 2008 http://dev.mysql.com/ [10] R. T. F. Brian Behlendorf, Rob Hartill, David Robinson, Cliff Skolnick, Randy Terbush, Robert S. Thau, Andrew Wilson, "The Apache HTTP Server Project," 2.2.17 ed. vol. 2011: The Apache Software Foundation, 2009 http://httpd.apache.org/ [11] P. Group, "PHP: Hypertext Preprocessor," 5.2.16 ed. vol. 2011, T. P. Group, Ed., 2010, pp. PHP is a widely-used general-purpose scripting language that is especially suited for Web development and can be embedded into HTML. http://www.php.net/ [12] A. F. Kevin Johnson, James Fields, Axton Graham, Jon Hart, Doug Mackie, Sean Muller, Tim Rupp, Christian Svensson, Max Valdez, "Basic Analysis and Security Engine (BASE)," 1.4.4 ed, 2007 http://base.secureideas.net/

144 145

[13] T. F. Foundation, "The FreeBSD Project," 6.2 ed. vol. 2007: The FreeBSD Project, 2007 http://www.freebsd.org/ [14] FSF, "The GNU Operating System." vol. 2009: Free Software Foundation, 2009 http://www.gnu.org/ [15] J. B. Raven Alder, Adam Doxtater, James C. Foster, Toby Kohlenberg, Michael Rash, Snort 2.1 Intrusion Detection, Second Edition, 2nd ed. Rockland, MA: Syngress Publishing, Inc., 2004. [16] D. G. Gómez, "Receive-only UTP cables and Network Taps," in Hitchhiker's World, 2004 http://www.infosecwriters.com/hhworld/hh9/roc/ [17] Y. Rekhter, "RFC 1918 - Address Allocation for Private ," 1996 http://www.faqs.org/rfcs/rfc1918.html [18] S. B. Angela Orebaugh, Jacob Babbin, Snort Cookbook, First Edition ed. Sebastopol, CA: O'Reilly Media, Inc., 2005. [19] P. Harper, "Snort Enterprise Install," 2006, p. 19 http://www.snort.org/docs/setup_guides/Snort_Base_Minimal.pdf [20] M. Jonkman, "Emerging Threats." vol. 2009, 2009 http://www.emergingthreats.net/index.php [21] A. Östling, "Oinkmaster," 2006 http://oinkmaster.sourceforge.net/ [22] N. Truhan, "Implementing a Honeynet," Kent, OH: Kent State University, 2004, p. 6 [23] SecurityFocus, "SecurityFocus Vulnerabilities Database," Calgary, AB 2005 http://www.securityfocus.com/vulnerabilities [24] N. Provos, "Honeyd," 2006 http://www.honeyd.org/ [25] "Sebek," The Honeynet Project, 2006 https://projects.honeynet.org/sebek/ [26] T. Liston, "LaBrea: "Sticky" Honeypot and IDS," 2003 http://labrea.sourceforge.net/labrea-info.html [27] G. Portokalidis, "ARGOS," 0.4.2 ed Amsterdam: vrije Universiteit, 2009, pp. Argos: An Emulator for Capturing Zero-Day attacks http://www.few.vu.nl/argos/ [28] Symantec, "Symantec Decoy Server," Cupertino, CA, 2003 http://www.systemhouse.com/symantec/sds.htm [29] NETSEC, "Specter Intrusion Detection System," Switzerland: NETSEC - Network Security Software 2006 http://www.specter.com/ [30] Canonical, "Ubuntu," 8.04 ed. vol. 2009, 2009 http://www.ubuntu.com/ [31] K. Knopper, "KNOPPIX," 6.2 ed, 2009, pp. KNOPPIX is a bootable CD or DVD with a collection of GNU/Linux software, automatic hardware detection, and support for many graphics cards, sound cards, SCSI and USB devices and other peripherals. KNOPPIX can be used as a productive Linux desktop, educational CD, rescue system, or adapted and used as a platform for commercial software product demos. http://www.knopper.net/knoppix/index-en.html [32] M. Kasper, "m0n0wall," 1.3 ed, 2009, pp. m0n0wall is a project aimed at creating a complete, embedded firewall software package that, when used together with an embedded PC, provides all the important features of commercial firewall boxes (including ease of use) at a fraction of the price (free software). m0n0wall is

146

based on a bare-bones version of FreeBSD, along with a web server, PHP and a few other utilities. http://m0n0.ch/wall/ [33] J. Andrews, "Damn Small Linux," 4.4.10 ed, 2008 http://www.damnsmalllinux.org/ [34] F. Bellard, "QEMU open source processor emulator," 0.9.1 ed. vol. 2010, 2008, p. QEMU open source processor emulator http://www.qemu.org/ [35] "Windows XP home page." vol. 2009 Redmond, WA: Microsoft Corporation, 2009 http://www.microsoft.com/windows/windows-xp/ [36] G. Lyon, "Nmap - Free Security Scanner," 5.21 ed, 2010 http://insecure.org [37] T. N. Security, "Nessus Vulnerability Scanner," 4.4 ed: Tenable Network Security, 2010, pp. The Nessus® vulnerability scanner, is the world-leader in active scanners, featuring high speed discovery, configuration auditing, asset profiling, sensitive data discovery and vulnerability analysis of your security posture. http://www.nessus.org/nessus/ [38] Rapid7, "The Metasploit Framework," 3.5.1 ed. vol. 2011 Boston, MA: Rapid7, 2010, pp. The Metasploit Framework is a development platform for creating security tools and exploits. The framework is used by network security professionals to perform penetration tests, system administrators to verify patch installations, product vendors to perform regression testing, and security researchers world-wide. The framework is written in the Ruby programming language and includes components written in C and assembler. http://www.metasploit.com/framework/ [39] "Honeywall CDROM," 1.4 ed, L. Spitzner, Ed.: The Honeynet Project, 2009, pp. The Honeywall CDROM creates an architecture that allows you to deploy both low-interaction and high-interaction honeypots, but is designed primarily for high-interaction. http://www.honeynet.org/project/HoneywallCDROM [40] "Joomla!," 1.6.4 ed. vol. 2011: Open Source Matters, Inc., 2011, pp. Joomla is an award-winning content management system (CMS), which enables you to build Web sites and powerful online applications. Many aspects, including its ease-of- use and extensibility, have made Joomla the most popular Web site software available. Best of all, Joomla is an open source solution that is freely available to everyone. http://www.joomla.org/ [41] Oracle, "Problems Running mysql_install_db " in MySQL 5.5 Manual. vol. 2011, 2010 http://dev.mysql.com/doc/refman/5.5/en/mysql-install-db-problems.html [42] M. Richardson, "TCPDUMP/LIBPCAP public repository," 4.1.1 ed. vol. 2010: SANDELMAN SOFTWARE WORKS, 2010 http://www.tcpdump.org/ [43] G. Combs, "Wireshark," 1.0.7 ed. vol. 2009, 2009 http://www.wireshark.org/ [44] P. Group, "PHP: List of Supported Timezones." vol. 2010, T. P. Group, Ed., 2010 http://us.php.net/manual/en/timezones.php [45] J. Lim, "ADOdb Database Abstraction Library for PHP," 5.11 ed. vol. 2010, 2009 http://adodb.sourceforge.net/ [46] P. Hazel, "PCRE - Perl Compatible Regular Expressions," 8.11 ed. vol. 2011, 2010 http://www.pcre.org/

147

[47] J. Veggerby, "Package Information: Image_Canvas," 0.3.3 (alpha) ed, 2010 http://pear.php.net/package/Image_Canvas/ [48] J. Veggerby, "Package Information: Image_Graph," 0.8 (alpha) ed, 2010 http://pear.php.net/package/Image_Graph/ [49] "PEAR - PHP Extension and Application Repository." vol. 2011: The PHP Group, 2008 http://pear.php.net/ [50] C. Hagenbuch, "Package Information: Mail," 1.2.0 ed, 2010 http://pear.php.net/package/Mail/ [51] A. Machniak, "Package Information: Mail_Mime," 1.8.1 ed, 2010 http://pear.php.net/package/Mail_Mime [52] D. Song, "libdnet," 1.12 ed. vol. 2011, 2011, pp. libdnet provides a simplified, portable interface to several low-level networking routines http://code.google.com/p/libdnet/ [53] R. Combs, "VRT: Snort 2.9 Essentials: The DAQ," 0.5 ed. vol. 2011, 2010, p. The DAQ replaces direct calls into packet capture libraries like PCAP with an abstraction layer that make it easy to add additional software or hardware packet capture implementations. http://vrt-blog.snort.org/2010/08/snort-29-essentials- daq.html [54] M. Roesch, "Snort :: snort-downloads," 2.9.0.3 ed Columbia, MD SOURCEfire, 2010, pp. Snort - the defacto standard for intrusion detection/prevention http://www.snort.org/snort-downloads [55] M. Jonkman, "Emerging Threats Rules FAQ." vol. 2009, 2008 http://doc.emergingthreats.net/bin/view/Main/RulesFAQ [56] P. Bothner, J. Buck, D. Edelsohn, K. R. Ghazi, J. A. Law, M. Lehmann, J. Merrill, D. Miller, M. Mitchell, T. Moene, G. Pfeifer, J. Sherrill, and J. Wilson, "GCC, the GNU Compiler Collection," 2007 http://gcc.gnu.org/ [57] S. Lantinga, "Simple DirectMedia Layer," 1.2.14 ed. vol. 2010, 2009 http://www.libsdl.org/index.php [58] L. Wall, "Perl," 5.8.8 ed, 2007 http://www.perl.org/ [59] P. Eggert, "Autoconf," 2.65 ed Boston: Free Software Foundation, 2009, pp. Autoconf is an extensible package of M4 macros that produce shell scripts to automatically configure software source code packages. These scripts can adapt the packages to many kinds of UNIX-like systems without manual user intervention. Autoconf creates a configuration script for a package from a template file that lists the operating system features that the package can use. http://www.gnu.org/software/autoconf/ [60] L. Buytenhek, "Bridge - LinuxNet," 1.4 ed, 2007 http://linux- net.osdl.org/index.php/Bridge [61] D. Walrond, "QEMU - DEbian - Linux - TUN/TAP - network bridge," http://compsoc.dur.ac.uk/~djw/qemu.html [62] M. IronFist, "Ubuntu System Requirements." vol. 2009, 2009 https://help.ubuntu.com/community/Installation/SystemRequirements [63] G. Project, "GNOME: The Free Software Desktop Project," 2.26 ed. vol. 2009, 2009 http://www.gnome.org/

148

[64] A. Dye, "SSH/OpenSSH/Configuring," 02/12/2010 ed, 2010 https://help.ubuntu.com/community/SSH/OpenSSH/Configuring [65] T. Espiner, "Microsoft exec calls XP hack 'frightening'." vol. 2009: CNET News.com, 2007, pp. A Microsoft executive calls the ease with which two British e-crime specialists managed to hack into a Windows XP computer as both "enlightening and frightening." http://news.cnet.com/Microsoft-exec-calls-XP- hack-frightening/2100-7349_3-6218238.html [66] S. Wiseman, "Hide user accounts from the Windows XP Welcome screen." vol. 2009: IntelliAdmin, LLC, 2006 http://www.intelliadmin.com/blog/2006/09/hide- user-accounts-from-windows-xp.html [67] "Windows XP Service Pack 2 Network Installation Package for IT Professionals and Developers." vol. 2009 Redmond, WA: Microsoft Corporation, 2004 http://www.microsoft.com/downloads/details.aspx?FamilyID=049c9dbe-3b8e- 4f30-8245-9e368d3cdb5a&displaylang=en [68] "Windows XP Service Pack 3 Network Installation Package for IT Professionals and Developers." vol. 2009: Microsoft Corporation, 2008 http://www.microsoft.com/downloads/details.aspx?FamilyId=5B33B5A8-5E76- 401F-BE08-1E1555D4F3D4&displaylang=en [69] M. S. Karen Scarfone, Paul M. Johnson, "Guide to Securing Microsoft Windows XP Systems for IT Professionals," National Institute of Standards and Technology, Gathersburg, MDOctober 2008 2008. [70] R. J. Shimonski, "Windows XP: Your Definitive Lockdown Guide," in Windows OS Security. vol. 2009: TechGenix Ltd., 2004 http://www.windowsecurity.com/articles/Windows_XP_Your_Definitive_Lockdo wn_Guide.html [71] EnterpriseDB, "PostgreSQL," 8.x ed. vol. 2009 Westford, WA, 2009 http://www.postgresql.org/ [72] N. Truhan, "Basic Analysis and Security Engine Results," BASE2.jpg, Ed., 2011