norwegian university of science and …sislab.no/nyre_mastersthesis_with_hyperlinks.pdf · faculty...

NORWEGIAN UNIVERSITY OF SCIENCE AND TECHNOLOGY

FACULTY OF INFORMATION TECHNOLOGY, MATHEMATICS AND ELECTRICAL ENGINEERING

MASTER’S THESIS Student's name: Åsmund Nergård Nyre Area: Telematics Title (English): Increasing Survivability by Dynamic Deployment of

Honeypots Description: One approach to creating a system with a high degree of availability and survivability when faced with a dynamic threat situation is to employ service duplication on disparate server platforms. However, it is still not unreasonable to expect that also a duplicated system at some point will be victim to an attack that exploits an unpatched vulnerability in one of the components. Such a compromise should be detectable by a voting mechanism, but simply shutting down the compromised component will inform the attacker that this particular attack was unsuccessful, and might lead her to explore other avenues of attack. A better solution might be to dynamically transform the compromised component to a state of honeypot, removing it from active duty, while providing the attacker with bogus data. This should provide the target system with extra time to implement adequate security measures while the attacker is busy exploiting the honeypot. The goal of this thesis will be to evaluate possible application areas, business models and theoretical solutions for Dynamic Honeypots, and if time permits, work out a design and perform an implementation of a prototype of a duplicated dynamic honeypot system. Start date: March 29th, 2005

Deadline: September 16th, 2005 Submission date:

Department: Department of Telematics Supervisor: Martin Gilje Jaatun

Trondheim, April 27th, 2005

Svein Johan Knapskog Professor

Abstract

The increased dependence on computer systems to provide support for criti-cal services, coupled with today’s constantly changing threat situation, callsfor additional measures to guarantee the continued deliverance of serviceseven under attack.

In this thesis we therefore investigate the possibility of utilizing replicatedservices on disparate software platform as a basis for improving the sur-vivability of computer systems. We propose a system capable of toleratingattacks, while preserving the integrity, confidentiality and availability of thesystem to its legitimate users. Upon detecting an attack, the compromisedserver is relieved from active duty and dynamically transformed into a stateof honeypot, while letting the attacker retain control of the server. By notalarming the attacker of the detection, she is left wasting her time exploitingthe honeypot, providing system administrators with useful information inthe subsequent patching of the security hole.

A prototype implementation of the system is provided to demonstrate thekey features of our system, including attack detection, attacker identificationand coupling of attacker and attack.

Additionally we outline the possible services that may benefit from our pro-posed solution and describe a business model to improve the efficiency ofmaintaining the system at a reduced cost.

Although the results of the testing are limited, the evaluation of the systemcoupled with the proposed improvements are promising.

iii

Preface

The work with this thesis has been a learning experience on many levels. Iespecially appreciated the practical approach and the ability to conduct aprototype implementation of the system. There are naturally several peoplethat in various ways have contributed to the process of writing this thesisand the outcome of it.

First I would like to thank my supervisor, Martin Gilje Jaatun, for proposingthe thesis and for sharing his time and expertise in all stages of this work. Hisenthusiasm and outspoken ambitions have been of great importance to theoutcome of this thesis. Professor Svein Johan Knapskog has also contributedgreatly to the outcome of this thesis, in particular in the design and structureof the report.

I would like to thank Sjur Bakka for practical assistance in the implemen-tation of the prototype system, and for his companionship during the workin the computer laboratory. I also would like to thank my brother, AudunNergard Nyre, for proofreading and commenting on the thesis. Finally, I amimmensely grateful to my future wife, Ingebjørg Ahlmann Bjørke, for all thesupport she has given me, in particular by taking care of practical issues (i.e.house work), allowing me to work long hours. Her kind words and belief ina successful outcome of this thesis has been an inspiration, especially duringthe frustrating times.

Trondheim,September 16th, 2005

Asmund Nergard Nyre

v

Contents

Abstract iii

Preface v

List of Figures xi

List of Tables xiii

List of Abbreviations xv

1 Introduction 11.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Problem Description . . . . . . . . . . . . . . . . . . . . . . . 21.3 Research Questions . . . . . . . . . . . . . . . . . . . . . . . . 21.4 Research Methodology . . . . . . . . . . . . . . . . . . . . . . 31.5 Outline of the Thesis . . . . . . . . . . . . . . . . . . . . . . . 4

2 Background 52.1 Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.1.1 Security . . . . . . . . . . . . . . . . . . . . . . . . . . 52.1.2 Dependability . . . . . . . . . . . . . . . . . . . . . . . 62.1.3 Survivability . . . . . . . . . . . . . . . . . . . . . . . . 72.1.4 Vulnerability, threat and attack . . . . . . . . . . . . . 8

2.2 Approaches to Security . . . . . . . . . . . . . . . . . . . . . . 92.2.1 Proactive Approach . . . . . . . . . . . . . . . . . . . . 92.2.2 Reactive Approach . . . . . . . . . . . . . . . . . . . . 10

2.3 Survivability . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.4 Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.4.1 SITAR . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.4.2 Bait and Switch Honeypot . . . . . . . . . . . . . . . . 142.4.3 Shadow Honeypots . . . . . . . . . . . . . . . . . . . . 15

vii

Contents

2.4.4 MPITS . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

3 State of the Art 173.1 The Opponent . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3.1.1 Attacker . . . . . . . . . . . . . . . . . . . . . . . . . . 183.1.2 Access . . . . . . . . . . . . . . . . . . . . . . . . . . . 193.1.3 Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203.1.4 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . 213.1.5 A Complete Taxonomy . . . . . . . . . . . . . . . . . . 22

3.2 Honeypots . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223.2.1 Types . . . . . . . . . . . . . . . . . . . . . . . . . . . 233.2.2 Application Areas . . . . . . . . . . . . . . . . . . . . . 243.2.3 Event Logging . . . . . . . . . . . . . . . . . . . . . . . 253.2.4 Sebek . . . . . . . . . . . . . . . . . . . . . . . . . . . 273.2.5 Anti-Honeypot Technology . . . . . . . . . . . . . . . . 29

3.3 Intrusion Detection Systems . . . . . . . . . . . . . . . . . . . 313.3.1 Types . . . . . . . . . . . . . . . . . . . . . . . . . . . 313.3.2 Detecting Attacks . . . . . . . . . . . . . . . . . . . . . 323.3.3 Event Logging and Filtering . . . . . . . . . . . . . . . 33

4 Minimal Proxy for Intrusion Tolerant Systems 354.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354.2 Functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . 364.3 Voting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

4.3.1 Equality algorithm . . . . . . . . . . . . . . . . . . . . 384.3.2 Equality Classes . . . . . . . . . . . . . . . . . . . . . . 394.3.3 Determining Response . . . . . . . . . . . . . . . . . . 40

5 System Specification 415.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 415.2 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

5.2.1 Functional . . . . . . . . . . . . . . . . . . . . . . . . . 435.2.2 Resistance . . . . . . . . . . . . . . . . . . . . . . . . . 445.2.3 Recognition . . . . . . . . . . . . . . . . . . . . . . . . 445.2.4 Recovery and Tolerance . . . . . . . . . . . . . . . . . 445.2.5 Adaptability . . . . . . . . . . . . . . . . . . . . . . . . 45

5.3 The Components . . . . . . . . . . . . . . . . . . . . . . . . . 455.3.1 Proxy Server . . . . . . . . . . . . . . . . . . . . . . . 455.3.2 Proxy Network . . . . . . . . . . . . . . . . . . . . . . 465.3.3 Voting Unit . . . . . . . . . . . . . . . . . . . . . . . . 475.3.4 Server Unit . . . . . . . . . . . . . . . . . . . . . . . . 48

viii

Contents

5.3.5 Logging Unit . . . . . . . . . . . . . . . . . . . . . . . 495.4 Technical Issues . . . . . . . . . . . . . . . . . . . . . . . . . . 49

5.4.1 Identifying Users . . . . . . . . . . . . . . . . . . . . . 495.4.2 Coupling of Attacker and Attack . . . . . . . . . . . . 505.4.3 Obfuscating Data . . . . . . . . . . . . . . . . . . . . . 525.4.4 Deception . . . . . . . . . . . . . . . . . . . . . . . . . 535.4.5 Containment . . . . . . . . . . . . . . . . . . . . . . . 54

5.5 System Design . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

6 Prototype Implementation 576.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

6.1.1 Software . . . . . . . . . . . . . . . . . . . . . . . . . . 596.1.2 Network Configuration . . . . . . . . . . . . . . . . . . 596.1.3 Licensing . . . . . . . . . . . . . . . . . . . . . . . . . 60

6.2 File Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 606.2.1 DHCP . . . . . . . . . . . . . . . . . . . . . . . . . . . 606.2.2 Network Boot Image . . . . . . . . . . . . . . . . . . . 616.2.3 NFS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 616.2.4 Root Filesystem . . . . . . . . . . . . . . . . . . . . . . 626.2.5 System monitoring . . . . . . . . . . . . . . . . . . . . 63

6.3 Diskless Server . . . . . . . . . . . . . . . . . . . . . . . . . . 656.4 Proxy Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

6.4.1 Distributing Requests . . . . . . . . . . . . . . . . . . . 666.4.2 Coupling Attack and Attacker . . . . . . . . . . . . . . 676.4.3 Deciding Response . . . . . . . . . . . . . . . . . . . . 67

7 Evaluation 697.1 Prototype Testing . . . . . . . . . . . . . . . . . . . . . . . . . 697.2 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

7.2.1 NFS Security . . . . . . . . . . . . . . . . . . . . . . . 717.2.2 False Positives and False Negatives . . . . . . . . . . . 727.2.3 Disparate Server Platforms . . . . . . . . . . . . . . . . 737.2.4 Single Point of Failure . . . . . . . . . . . . . . . . . . 73

7.3 Evaluation Summary . . . . . . . . . . . . . . . . . . . . . . . 74

8 Application Areas 758.1 Cost-effective Security Investments . . . . . . . . . . . . . . . 758.2 Potential Services . . . . . . . . . . . . . . . . . . . . . . . . . 768.3 Business Models . . . . . . . . . . . . . . . . . . . . . . . . . . 778.4 Legal and Ethical Considerations . . . . . . . . . . . . . . . . 78

8.4.1 Entrapment . . . . . . . . . . . . . . . . . . . . . . . . 78

ix

Contents

8.4.2 Surveillance . . . . . . . . . . . . . . . . . . . . . . . . 79

9 Further Work 81

10 Conclusion 85

A Configuration Files 87A.1 DHCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87A.2 NFS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88A.3 Samhain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

References 93

Web Resources 97

x

List of Figures

2.1 Relation between the attributes of security and dependability[24] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.2 Overview of the data flow in SITAR [37]. . . . . . . . . . . . . 13

2.3 Overview of the Bait and Switch honeypot system. . . . . . . 15

2.4 The data flow of the Shadow Honeypots system [1]. . . . . . . 16

3.1 Operational Sequence of Computer and Network Attack [17] . 18

3.2 Attackers and their main motivation . . . . . . . . . . . . . . 19

3.3 Decomposition of the access step in an attack. . . . . . . . . . 20

3.4 A complete taxonomy of computer and network attacks [17] . 22

3.5 Information gathering and log storage approaches. . . . . . . 26

3.6 Sebek manipulates the system read command [35] . . . . . . . 28

3.7 Conceptual view of Sebek packet generation and outflow ofdata [35] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

4.1 An overview of the MPITS architecture . . . . . . . . . . . . . 36

4.2 An illustration of the MPITS Data flow. The listening process(to the left) forks a new process for each request. (translatedfrom [4]) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

5.1 An illustration of the basic idea with our new system. Theattacker is left in control of the compromised unit withoutaffecting the system as a whole. . . . . . . . . . . . . . . . . . 42

5.2 Simplified overview of the system and its components. . . . . . 43

5.3 The logical view of how the two main functions of the votingunit are interconnected . . . . . . . . . . . . . . . . . . . . . . 47

5.4 A detailed view of the server unit, consisting of a disklessapplication server and a file server with corresponding harddisk. 48

5.5 An illustration of the concurrency problems related to the cou-pling of attacker and attack. . . . . . . . . . . . . . . . . . . . 51

xi

List of Figures

5.6 Illustration of how obfuscation by partition swapping may beorganized in the file server. . . . . . . . . . . . . . . . . . . . . 52

5.7 The extended view of the overall system architecture . . . . . 55

6.1 An overview of the prototype implementation. . . . . . . . . . 586.2 An overview of the file server filesystem. The root filesystem of

the diskless server should be mounted as a separate partition.The document roots should be placed on a partition otherthan the one containing the diskless filesystem. . . . . . . . . . 62

6.3 Overview of the process of deciding the appropriate responseto the user. The rectangular boxes indicates the proper re-sponse (above) and additional operations to be done (below). . 68

8.1 Illustration of a business model to cater for small businesses.The security provider offers our system to multiple companiesand services. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

9.1 Illustration of parts of the system, with the voting unit repre-sented as a dark host, i.e. not addressable by IP-address. . . . 83

xii

List of Tables

6.1 The operating system and web server software used in theprototype. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

6.2 The network configuration for each network interface card inthe system. To obtain the actual addresses for each applicationand file server the ‘X’ is substituted with the correspondingserver unit number. . . . . . . . . . . . . . . . . . . . . . . . . 59

6.3 Possible severity levels of policy violations and thresholds forlogging [29]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

6.4 The different options for logging events in Samhain [29]. . . . 65

xiii

List of Abbreviations

AD Anomaly Detection

AIDE Advanced Intrusion Detection Environment

ANSI American National Standards Institute

ARP Address Resolution Protocol

AS Application Server

BIOS Basic Input/Output System

CRL Certificate Revocation List

CVE Common Vulnerabilities and Exposures

DDoS Distributed Denial of Service

DHCP Dynamic Host Configuration Protocol

DoS Denial of Service

DVD Digital Video (Versatile) Disk

FS File Server

GSM Global System for Mobile Communication

HIDS Host based Intrusion Detection System

HLR Home Location Register

HTTP Hyper Text Transfer Protocol

IDS Intrusion Detection System

IP Internet Protocol

IPS Intrusion Prevention System

IR Incident Response

LAN Local Area Network

MAC Media Access Control

MPITS Minimal Proxy for Intrusion Tolerance Systems

NAT Network Address Translation

NIC Network Interface Card

NIDS Network based Intrusion Detection System

xv

NFS Network File System

OS Operating System

PDU Protocol Data Unit

PPP Point-to-Point Protocol

PXE Preboot Execution Environment

RAM Random Access Memory

ROM Read Only Memory

SITAR Scalable Intrusion-Tolerant Architecture

TCP Transmission Control Protocol

TFTP Trivial File Transfer Protocol

UDP User Datagram Protocol

xvi

Chapter 1

Introduction

In this chapter we will present the underlying motivation for our work andgive a more accurate description of what problems we seek to solve.

1.1 Motivation

There are mainly two reasons why information security continues to receivean increasing amount of attention. Firstly, new services providing criticalservices demand an increased level of security. Secondly, there is an evergrowing increase in reported incidents and attempted attacks on computersystems [11]. That is, not only are we more concerned with informationsecurity as a result of the impact a compromise would create on our lives, wealso receive daily updates on discovered vulnerabilities and successful attacks(e.g. [CNN]).

Common strategies for providing security focuses on the prevention of at-tacks, through the means of firewalls, security patches, access control etc.The downside to this approach is that it assumes that “perfect”systems thatare practically impenetrable can be built. History has however shown thatthis is relatively seldom the case, and even good systems suffer from the oc-casional fault. A better solution may be to assume that intrusions may occurand focus on handling them at that point in time.

The challenge is to design systems that may tolerate intrusions and still beingable to provide the given services.

1

1.2. Problem Description

1.2 Problem Description

In this thesis we will consider whether replicated services may be utilizedto increase the survivability of a system. That is, whether it is possible tocreate a system that is capable of delivering its required services in spite ofbeing under attack? Additionally, we want to let the attacker retain controlof the compromised component without revealing any sensitive informationor allowing the attacker to conduct further attacks, as proposed by Jaatunand Hallingstad in [18]. That is, upon detecting an attack the attacker is putunder surveillance and all sensitive data obfuscated, so that the attacker inreality gains nothing from the attack. The state of the compromised compo-nent resembles that of a honeypot, in that its sole purpose is to monitor andcontain attacker activities. The information gathered from this monitoringwill again be used in machine learning techniques so that the system canadapt and evolve to changing vulnerabilities, threats and attacker strategies.

1.3 Research Questions

The main goal of this work is to develop a solution to increase the surviv-ability of a computer system. There are however, several underlying issuesthat need to be resolved in order for this solution to be of any value. Wehave summarized these in the questions given below.

Q-1 How can we provide survivability?

Q-2 How can survivability be verified?

Q-3 What can be achieved by increased survivability?

Q-4 Who may be interested in survivable systems?

These are mainly theoretical questions and will be answered in the first fewchapters. Question Q-4 is debated when assessing the application areas ofour system in chapter 8.

The prototype implementation also give rise to a number of underlying ques-tions that need to be answered.

Q-5 How can attacks be detected?

Q-6 How can data be obfuscated immediately?

Q-7 How can the deception be concealed?

2

Chapter 1. Introduction

Q-8 Which systems can be supported?

Q-9 How can we guarantee that only the attacker receives bogus informa-tion?

These questions will be answered when designing the system and implement-ing a prototype.

1.4 Research Methodology

Depending on the chosen research methodology, the outcome of a givenproject may vary considerably. It is therefore of outmost importance tostate what methods were used and what assumptions were taken. We nextpresent some methods for gathering and analyzing information for researchpurposes.

Denning et al. [7] define three paradigms or approaches to scientific research.All approaches consist of four steps

• Theory is rooted in mathematics and includes; (1) defining objects ofstudy, (2) making a hypothesis on their relations, (3) determining thetruth value of the hypothesis and (4) interpreting the results.

• Abstraction(Modeling) is an experimental scientific method that in-cludes; (1) forming a hypothesis, (2) constructing a model and makinga prediction, (3) designing an experiment and collecting data and (4)analyzing the results.

• Design is rooted in engineering and includes; (1) stating requirements,(2) stating specifications, (3) designing and implementing the systemand (4) testing the system.

In our thesis, we will use a hybrid approach consisting of elements fromboth the abstraction and design approach. This approach is in essence theabstraction approach with increased stress on the prototype (experimentaldesign) to include specification, requirements and testing.

We do not seek to find unambiguous quantifiable results, but rather to obtaina qualitative assessment of whether the goal of the work was met. We willdiscuss this to a greater level of detail when looking at the evaluation processin chapter 7.

3

1.5. Outline of the Thesis

1.5 Outline of the Thesis

The remaining parts of this thesis are organized as follows. In chapter 2 wegive an introduction to important terms, a general discussion on approachesto security and survivability, before we in the last section provide an overviewof relevant related work. Chapter 3 presents the main technologies that ourproposed system will rely on, including honeypots and intrusion detectionsystems. We also will give a presentation and a taxonomy of current attacksand attacker types. Chapter 4 gives a complete overview of the MPITSsystem that we will use extensively in our system. The specification for ourproposed system will be given in chapter 5, while chapter 6 will elaborate onthe prototype implementation. Chapter 7 deals with the evaluation process,including testing and a discussion on the solutions utilized in the prototype.Possible application areas and legal issues are discussed in chapter 8. Chapter9 points out possible improvements and areas that could be further explored.In chapter 10 we summarize our answers to the research questions definedabove and present our concluding remarks.

We have distinguished printed references from their web-based counterparts,to clarify the origin of these resources. The printed references are cited usingnumerical values (e.g. [1]), while the web resources uses an abbreviatedcitation style (e.g. [AIDE]). Additionally, we emphasize that the usageof first person plural (i.e. we), is only due to common convention and istherefore to be interpreted as the author.

4

Chapter 2

Background

In this chapter we will present some important background information onsecurity and survivability that will provide for a better understanding of oursystem. First we discuss existing definitions of some terms and clarify ourunderstanding of them. We next discuss some of the prevailing approaches tosecurity and survivability, before we present some important related systemsand architectures.

2.1 Definitions

In order to prevent misconceptions and misunderstandings we discuss themeaning of some important security related terms. Some terms have beenproperly defined and agreed upon by the information security community.Others lack this consensus, either caused by rivalry among existing definitionsor the non-existence of proper definitions.

We do not intend to contribute to the ongoing debate on proper definitions,but rather elaborate on what these terms will denote in our thesis. Thefollowing subsections are therefore not to be seen as actual definitions, asthey only try to explain our intended usage of the terms.

2.1.1 Security

There exist numerous definitions of security, all varying slightly in wording.We will use the definitions of RFC 2828 [31] and Laprie et al. [24] to illustrate

5

2.1. Definitions

the different approaches and clarify our usage of the term. Laprie et al.defines security as “the composite of the attributes of confidentiality, integrityand availability”[24]. This is a common definition but do not specify whethersecurity is a mechanism, a service or a state. Shirey on the other hand definessecurity as “(1) Measures taken to protect a system. (2) The condition of asystem that results from the establishment and maintenance of measures toprotect the system. (3) The condition of system resources being free fromunauthorized access and from unauthorized or accidental change, destruction,or loss”.

It is evident that the third section of the RFC 2828 definition actually ex-presses the attributes of Laprie’s definition. In this thesis we will thereforeuse a hybrid of the two definitions, since Laprie’s wording is less complexthan that of Shirey.

2.1.2 Dependability

When defining dependability it is customary to refer to Laprie’s definition[23]: “Computer system dependability is the quality of the delivered ser-vice such that reliance can justifiably be placed on that service”. To assesswhether the justification of trust holds, is not a straight forward matter.Laprie et al. therefore rephrased this definition to make it easier to decidewhether the service is dependable or not [24]; “the dependability of a sys-tem is the ability to avoid service failures that are more frequent and moresevere than is acceptable”. In addition a slightly different set of attributeswas listed.

• availability – readiness for correct service

• reliability – continuity of correct service

• safety – absence of catastrophic consequences on the environment orthe user(s)

• integrity – absence of improper alterations of information.

• maintainability – ability to undergo repairs and modification.

There exist several different definitions in which security or confidentialitywas listed as dependability attributes. Laprie et al. [24] argues that this isnot correct. Figure 2.1 illustrates the relation between the attributes of thetwo terms.

Fault tolerance is sometimes used when dependability is meant. The dis-tinction however, is that fault tolerance is a means to achieve dependability.

6

Chapter 2. Background

Figure 2.1: Relation between the attributes of security and dependability[24]

That is, by tolerating faults the system may increase its dependability, butdependability does not imply fault tolerance.

2.1.3 Survivability

Although survivability is a fairly new term that still lacks consensus on itsdefinition, the idea is far from new. The general meaning of survivabilityis the ability of a system to continue to deliver services or restore servicesdespite of being attacked. The practice has traditionally been in the realm ofIncident Response (IR), which is responding to and recovering from attacks.Intuitively, the term survivability encompasses more than what IR does, andwe therefore proceed to define it more accurately.

According to Ellison et al. [9] survivability is “the capability of a system tofulfill its mission, in a timely manner, in the presence of attacks, failures oraccidents.” The term mission is used to denote the high-level requirementsor goals of the system, and is not restricted to military systems. Ellison etal. stresses that whether the mission is fulfilled may change depending onenvironmental circumstances. In the presence of power outage, hurricanesetc., the fulfilment may require less than under normal conditions. Attacks,failures and accidents are used so as to include all possible damaging events.More recently, Knight et al. have tried to establish a more rigorous definitionof survivability [20] in order to assess to what degree survivability is provided.Unlike other attempts, they define a detailed specification of the survivabilityrequirements of the system, which in turn provide a quantifiable means forassessing system survivability.

Lipson [25] adopted the definition from Ellison et al. but added the conceptof the three R’s of survivability;

7

2.1. Definitions

• Resistance – ability to repel attacks• Recognition – ability to recognize attacks and the extent of damage• Recovery – ability to restore essential services during attack, and re-

cover full services after attack

Laprie et al. concludes that the concepts of dependability and survivabilityare essentially equivalent [24]. Others, including Knight et al. and Ellisonet al. argues that survivability describes a slightly different concept thandependability. The difference being mainly in how a system is viewed. Inclassical dependability thinking, the system is either in working state (up) orin failed state (down). There is no notion of a degraded state, where partsof the system are working while other parts have failed. Another aspectof survivability is the focus on man-made faults such as malicious activity,while dependability mainly focuses on statistical probabilities of one or moreaccidental faults. This difference in approach may not necessarily rely onwhat the concepts theoretically may include, but rather on what has beenthe focus over many years.

We will in this report use the definition of survivability gained from [9] asstated above, but with focus on attacks and malicious activity rather thanaccidental or unintended faults.

2.1.4 Vulnerability, threat and attack

There are numerous terms used to describe the existence of security weak-nesses, their imposed threat on the system and the possibility of evadingsystem security. We use definitions from RFC 2828 [31].

A vulnerability “is a flaw or weakness in a system’s design, implementation, oroperation and management that could be exploited to violate the system’ssecurity policy”[31]. One obvious way to remove all vulnerabilities wouldtherefore be not to have a security policy. The Common Vulnerabilities andExposure (CVE)[CVE] community has therefore separated exposures fromvulnerabilities in that the former is to be used when the security policy itselfis a weakness. That is, if the system behaves as intended but still can easilybe compromised, then this is an exposure. We however, assume appropriatesecurity policies and will not use this distinction.

A vulnerability might yield a new or increased threat. More formally; “athreat is a potential for violation of security, which exists when there is acircumstance, capability, action, or event that could breach security andcause harm” [31]. We normally separate the accidental threats (e.g., natural

8


disasters) commonly referred to as “acts of God” or force majeure, from theintentional threats (e.g., attackers, criminals etc.). The threat is basicallythe potential for a successful attack.

An attack is; “an assault on system security that derives from an intelligentthreat, i.e., an intelligent act that is a deliberate attempt (especially in thesense of a method or technique) to evade security services and violate thesecurity policy of a system” [31]. Attacks will be more thoroughly debatedin section 3.1

There are numerous other terms used to describe attacks, such as penetrationand intrusion. These terms may be seen as subsets of attack, that is, anintrusion is also an attack, while an attack is not necessarily an intrusion(e.g., Denial of Service (DoS) attack). Although more specific definitionsexist, we will use these terms to indicate successful or attempted break-insto computer systems.

A security violation is used to denote any system behavior deviating fromthe security policy or specification. This includes both intentional maliciousactivity and unintentional authorized activity.

2.2 Approaches to Security

As noted previously, the attributes of security are availability, confidentialityand integrity. An increase in the level of security therefore should be reflectedby an increase in one or more of these attributes. For our purposes, we focuson the difference between the proactive and reactive approaches to increasedsecurity. We will then in the next section look at how survivability may beachieved.

2.2.1 Proactive Approach

By proactive measures we mean all measures taken to prevent a compro-mise of the system’s security. Such measures include removing unnecessaryoperating system services (hardening), blocking unwanted traffic (firewalls),blocking unauthorized users (authentication), proper system configurationand security updates.

Although a high level of security can be reached by carefully addressing allpossible vulnerabilities, the probability if success is rather small. Attackers

9

2.2. Approaches to Security

are normally more creative in developing ways to exploit vulnerabilities thanthe security community is at creating countermeasures. The time from avulnerability is discovered to an exploit is available is constantly decreasing,resulting in what is known as zero-day exploits. The proactive approachdoes not effectively deal with Denial of Service (DoS) attacks, which is listedin the 2004 FBI/CSI Security Crime Survey [11] as the most costly type ofattack. Clearly, to combat such threats a different approach is required.

2.2.2 Reactive Approach

By reactive approach we mean all measures that are taken once the systemis under attack. Intuitively this strategy looks poorer than the the proactive,so to illustrate its purpose, we use the analogy of fire safety. Clearly, we willkeep candlelights away from combustibles, put timers on electric devices,use fuses and build firewalls around the fireplace. We still acknowledge theneed for smoke/heat detectors, sprinkler systems and fire departments. Thereactive approach is thus not meant to substitute the proactive, but ratheras an additional line of defense to combat whatever gets through our initialbarrier.

Essentially, the reactive approach consists of detection and incident response,where the former is a prerequisite for the latter. That is, if we are to respondto incidents, we need to detect whether an incident has occurred or not.Intrusion Detection Systems (IDS) have therefore been considered a corner-stone in reactive approaches. As we will see in section 3.3, the effectiveness ofmost IDSs are hampered by a high rate of false positives and false negatives,resulting in both false alarms and undetected successful penetrations.

Whether to apply proactive or reactive measures is often debated as if theywere mutually exclusive. However, proper proactive measures may relievethe reactive measures of much work, while reactive measures may produceinformation on novel attacks that could contribute to the improvement ofthe proactive measures. Additionally reactive measures may simply providereassurance that the proactive measures are working appropriately. Cheswickstates in a panel debate [5] that reactive and proactive measures complementeach other and are necessary to obtain adequate cost effective security.

10


2.3 Survivability

Providing survivability involves providing for one or more of the survivabil-ity attributes resistance, recognition and recovery (recall from section 2.1.3).In our presentation of ways in which to achieve survivability, we thereforepresent the different techniques that can be employed to increase the at-tributes separately. We also consider the systems ability to adapt and evolveaccording to changing environments or attack patterns [9].

Resistance

Resistance encompasses most of what is traditionally referred to as secu-rity, i.e. the ability to prevent security compromises. The strategies includefirewalls, authentication and encryption. According to [9], there has been arather one-sided focus on prevention techniques rather than recovery.

An increasingly important resistance strategy known as diversification, is touse disparate hardware and software platforms for replicated components ina system. This reduces the likelihood of two components displaying identicalvulnerabilities which again would decrease the probability of using the sameattack to compromise several components.

Recognition

Recognition is the ability of a system to detect successful attacks or attacksin progress. In order to react or adapt to successful attacks, recognizing thatit has occurred is of uttermost importance.

The prevailing technique for attack recognition is various Intrusion Detec-tion Systems. We will have a closer look at IDSs in section 3.3. Anotherapproach is to have several replicated services perform identical computationand subsequently voting on the result. This approach is also a general tech-nique to enable intrusion tolerance and fast recovery after compromises andis described below.

Recovery and Intrusion Tolerance

Recovery and intrusion tolerance represent perhaps the key difference be-tween survivability and traditional security. It is therefore common to speak

11

2.3. Survivability

of intrusion tolerant systems as survivable systems, although the former ismore to be considered a subset of the latter. There are two main techniquesto enable recovery and intrusion tolerance in computer systems; redundancyand heterogeneity.

From basic coding theory (e.g [13]) we have that applying n copies will allowus to correct d = b(n − 1)/2c simultaneous errors. In binary mathematics,correction is performed simply by flipping the erroneous bit, hence the termcorrection actually refers to the ability to distinguish the correct answerfrom the erroneous. The equations above shows that in order to identify oneerroneous answer we would need at least three components. It is worth notingthat applying four copies does not increase the number of simultaneous errorsthat we can correct, however it does enable sequential correction of two errors.That is; we detect one error and label the component as malfunctioning,leaving us with three components still capable of detecting one more error.

In order for redundancy to be of any help, we need to make sure that thepossibility of several components failing simultaneously is diminished. Infault tolerance, it is common to assume that components fail independently.That is; a component failure does not affect the probability of failure of theother components. Within intrusion tolerance this assumption is generallynot applicable. A successful compromise of one unit may easily be reproducedso as to compromise all components, effectively rendering redundancy useless.

In order to make the aforementioned assumption valid, heterogeneous compo-nents are required. That is; to have all components run on disparate softwareand/or hardware platforms and all software for those platforms developed in-dependently. It has been seen that vulnerabilities found on e.g. Windowssystems are different from the ones found in Linux or Unix systems, whichin turn causes a successful attack on a Windows platform to leave the Linuxmachine unharmed and vice versa. Similarly Sun SPARC computers mayhave different vulnerabilities from the ones displayed by regular PCs. Thesame also applies to programming languages, libraries, third party softwareetc. The granularity of this heterogeneity is basically only limited by costconsiderations.

Adaptation and Evolution

Adaptation and evolution is important in order to protect against the blackhat community’s ever increasing knowledge of ways to exploit computer sys-tems. Updating, patching and machine learning are some useful techniques to

12


Figure 2.2: Overview of the data flow in SITAR [37].

maintain system security in the face of new undiscovered attacks. Anomalybased IDSs may also be utilized to detect new attacks, providing valuableinformation in discovering new vulnerabilities and exploits. In section 3.3,when discussing IDSs, we will see that the efficiency of such systems areseverely degraded by a high rate of false positives and negatives.

2.4 Related Work

There are several systems aiming at providing intrusion tolerance to com-puter systems. In this section we briefly describe some of the attempts orsuggestions that has been made in order to provide survivability, particularlythrough intrusion tolerance.

2.4.1 SITAR

The Scalable Intrusion-Tolerance Architecture (SITAR) developed at DukeUniversity and MCNC [37] is a system utilizing vulnerable COTS servers toprovide a system invulnerable to attacks. The system is based on replication,software diversity and a voting mechanism.

13

2.4. Related Work

The system consists of a pool of proxy servers, ballot monitors, acceptancemonitors and COTS servers as illustrated in figure 2.2. A user requests aservice from a proxy server. The proxy will then, depending on the service,determine the COTS servers to forward the request to. The COTS serverswill respond to the acceptance monitors, which performs a check of the re-sponses to detect possible compromises. It then issues a ballot and forwardsit to the ballot monitors, which acts as agents for the responses and agreeson an appropriate response to forward to the user. The concept has beenimplemented to provide HTTP and DNS servers but could, according to theauthors, easily be extended to support other protocols as well.

2.4.2 Bait and Switch Honeypot

1) A proxy server capable of detecting attacks and routing traffic to theother components in the system.

2) A production server responsible for delivering the actual service.

3) A honeypot server containing bogus information resembling the pro-duction server.

The Bait and Switch Honeypot project [BaS] is an open source project inmany ways similar to our proposed system. The system consists of threemain parts;

The proxy server is running Snort IDS [SNORT] to enable intrusion detec-tion. Upon receiving a request, Snort determines whether the request islegitimate or not, and forwards the request to either the production server orthe honeypot server (see figure 2.3). An attacker is therefore left exploitingthe worthless honeypot and information may be gathered on her actions asan added benefit.

The downside to this approach is that the reliability of the system relieson effective intrusion detection. As we will see in section 3.3, Snort andother such systems are hampered by a high rate of false positives and falsenegatives. This may cause a legitimate user to be routed to the honeypot, andvice versa. Depending on the nature of the system this may have devastatingeffects.

14


Figure 2.3: Overview of the Bait and Switch honeypot system.

2.4.3 Shadow Honeypots

As part of the LOBSTER project [LOBSTER], Anagnostakis et al. [1] pro-poses Shadow Honeypots as a means for detecting targeted attacks. This is ahybrid system combining the best features of honeypots and anomaly basedintrusion detection.

The idea is that any suspicious traffic is to be routed to a shadow server.The shadow server will in turn be able to determine whether this is legit-imate or hostile traffic. Figure 2.4 illustrates the data flow in the system.An incoming request to the system is first evaluated by the filtering process,and if it matches predefined signatures of attacks, it is immediately dropped.The request may be forwarded to the Shadow Honeypot if it is either classi-fied as suspicious by the Anomaly Detection (AD) mechanism, or randomlychosen by the system. The Shadow Honeypot will subsequently determinewhether the request was malicious and drop it or whether it was legitimateand continue normal processing. It will additionally update the filtering andAD policy according to the decision, to continuously improve the effective-ness of the detection mechanisms. An attack passing through all evaluationsundetected will potentially compromise the system.

15

2.4. Related Work

Figure 2.4: The data flow of the Shadow Honeypots system [1].

2.4.4 MPITS

Broen proposed in [4] a replicated server system called Minimal Proxy Intru-sion Tolerant System (MPITS). The proposed system is only partly imple-mented, and may be used as a building block in other systems. We will usethis system when implementing our solution, and we therefore will describeMPITS to a greater level of detail in chapter 4.

16

Chapter 3

State of the Art

In this chapter we will have a closer look at current available systems andtechnologies that are useful to us in developing our new system. First we givean introduction to current strategies of attack. Next, we have look at currenthoneypot technologies that are employed to gather information on attackerbehavior. In the last section we present the current methods of detectingattacks to computer systems.

3.1 The Opponent

In order to combat the threat posed by attackers it is important to have someunderstanding of their techniques, tactics and motives. In the HoneynetProject [HNET] the slogan “Know your Enemy”, serves as motivation forusing honeypots to obtain such information. However, knowing who youare dealing with is also a important prerequisite in order to limit the risksinvolved in honeypot deployment. We therefore give a brief overview ofattackers and attacks, both to form a basis for what we want to protectourselves from and how we may reduce the risk.

In describing the opponent we will refer extensively to the taxonomy of com-puter and network attacks proposed by Howard [17]. We do not intend toutilize such a taxonomy to classify attacks, but rather to understand thewhat possible attackers, tools and objectives we may be dealing with andthe possible results (i.e. impact) of the attacks. Additionally we will use thistaxonomy to show the logical sequence of an attack, as illustrated in figure3.1. The illustration shows that the attacker uses certain tools to obtain

17

3.1. The Opponent

Attackers ⇒ Tools ⇒ Access ⇒ Results ⇒ Objective

Figure 3.1: Operational Sequence of Computer and Network Attack [17]

access to a system or data in transit. The result (i.e. impact) on the systemis reflected by the motives of her actions. We will next describe each step inthe sequence to a greater level of detail.

3.1.1 Attacker

Attempts have been made to classify attackers based on their roles, skills,motivation and a combination of the three. Howard argues that it is better tocategorize attackers on what they typically do, and forms the main categorieshackers, criminals and vandals [17]. Distinguishing these categories may bedone on the basis of motivation. The hacker’s main motivation is accessto a system, the criminal is motivated by gain, while the vandal’s mainmotivation is damage. Howard continues to distinguish between criminals.Corporate raiders and professional criminals are motivated by financial gain,while spies and terrorists are motivated by political gain. Attackers aretherefore grouped into the following six categories.

1) Hackers – break into computers primarily for the challenge and thesocial status of obtaining access.

2) Spies – break into computers for information that can be used for po-litical gain.

3) Terrorists – break into computers to cause fear, which subsequentlymay cause political gain.

4) Corporate raiders – employees of one company break into computersof competitors for financial gain.

5) Professional Criminals – break into computers for personal financialgain.

6) Vandals – break into computers to cause damage.

These six categories of attackers and the corresponding four categories ofmain motivation is shown in figure 3.2. After defining who the hacker isand the main motivation, we need to find a sequence of intermediate steps

18

Chapter 3. State of the Art

Attackers⇒

Tools⇒

Access⇒

Results⇒

Objective

HackersChallenge,

Status

SpiesPolitical

Gain

TerroristsFinancial

Gain

CorporateDamage

Raiders

Professional

Criminals

Vandals

Figure 3.2: Attackers and their main motivation [17]

to achieve these objectives. We will next describe the possible choices whenestablishing a chain from the attacker to the objective.

3.1.2 Access

In order to conduct an attack, the attacker needs to obtain access to thesystem. Recall from our definition of security (section 2.1.1) that security isthe condition of a system being free from unauthorized access or use. Thus,to violate the security (i.e. attack the system), the attacker either needsto obtain unauthorized access to the system or use the authorized access ina malicious manner. This unauthorized access or use of data and files isobtained through the processes controlling the data and files.

From figure 3.3 we see that a prerequisite for obtaining access to the desiredprocess is to take advantage of a vulnerability in the system. These vulner-abilities may be due to incorrect implementation, design or configuration ofthe system. Design vulnerabilities are more serious than the others, since itoften requires a complete redesign of the system in order to correct the error.Implementation vulnerabilities are more common but may be rather easilyalleviated by updates or patches to the misbehaving software. It is worthnoting that although patches generally are made whenever a vulnerabilityis discovered, the time from a new vulnerability is discovered to an exploitexists, continues to decrease. The perhaps most common error is done bysystem administrators when configuring the system. In particular, the ex-ample configuration often supplied with the software may include obviousweaknesses such as standard passwords, usernames and access rules. Con-

19

3.1. The Opponent

Access

Implementation UnauthorizedFile

Vulnerability Access

Design ⇒ Unauthorized ⇒ Processes ⇒ Data in

Vulnerability Use Transit

Configuration

Vulnerability

Figure 3.3: Decomposition of the access step in an attack[17].

figuration errors are however the easiest to correct since it may be done bythe system administrator. Additionally, unlike most design and implemen-tation errors, the system administrator may verify correct configuration byinspection.

3.1.3 Tools

The tools of an attacker comprises any software the attacker makes use of inorder to conduct the attack. It is similar to the methods of the attacker, butnot identical since different tools may utilize the same method.

Howard defines six categories for tools used in computer and network attacks.

User Command – commands are given manually by the attacker througha command line or graphical interface. For example using telnet for re-mote login attempts to computers to gain user or super user privileges.

Scrip or Program – script and programs launched by the attack er at theuser interface. Common tools of this group include cracks to unveilpoorly chosen passwords and trojan horses to disguise malicious pro-grams. A trojan horse is a small program that is included in otherbenign programs and performs malicious actions such as editing files,logging activity and stealing passwords.

Autonomous Agent – program initiated by the attacker that operates in-dependently of the attacker to perform attacks. The most commonmembers of this group are worms and viruses, capable of automaticallydoing the intended harm to infected hosts. Worms have the additionalfeature that it may reproduce itself and infect other hosts through var-ious methods, making it extremely fast to spread to a large number ofhosts. A complete taxonomy of computer worms has been developedby Weaver et al. [38].

20


Toolkit – a software package consisting of scripts, programs and autonomousagents used in combination to perform attacks. These tools normallydo not require extensive knowledge of vulnerabilities and exploits, asthey are commonly equipped with descriptive user interfaces. A com-mon member of this group is rootkits, used to conceal attacker activity,modify programs and open back doors to cater for easy access at a latertime.

Distributed Tool – tools that are distributed to multiple hosts and co-ordinated to enable simultaneous attack on a system from all hosts.The coordination may either be done by clock synchronization or byissuing simultaneous commands to the distributed tools. Worms arecommonly used in such distributed tools. Distributed tools are pop-ular when launching Denial of Service (DoS) attacks, the so calledDistributed Denial of Service (DDoS).

Data Tap – external physical device that listens on hosts or networks andinterprets the physical signal passing through them. This categorydoes not include software agents, and is considered for devices similarto phone taps.

3.1.4 Results

Howard uses the result to denote the effect the attack has on the system. Itis evident that the result of the attack will in most cases be reflected by theobjectives of the attacker. However, there may be several possible resultsthat all may achieve the desired objective. Howard defines four categories ofresults of an attack [17];

Corruption of Information any unauthorized alteration of files stored ona host computer or data in transit across a network.

Disclosure of Information the dissemination of information to anyone whois not authorized to access that information.

Theft of Service the unauthorized use of computer or network serviceswithout degrading the service to other users.

Denial-of-service the intentional degradation or blocking of computer ornetwork resources.

21

3.2. Honeypots

Attackers⇒

Tools⇒

Access⇒

Results⇒

Objective

HackersUser Corruption of Challenge,

Command Information Status

SpiesScrip or Disclosure of Political

Program Information Gain

TerroristsAutonomous Theft of Financial

Agent Service Gain

CorporateToolkit

Denial ofDamage

Raiders Service

Professional Distributed

Criminals Tool

Vandals Data Tap

Access

Implementation UnauthorizedFile

Vulnerability Access

Design ⇒ Unauthorized ⇒ Processes ⇒ Data in

Vulnerability Use Transit

Configuration

Vulnerability

Figure 3.4: A complete taxonomy of computer and network attacks [17]

3.1.5 A Complete Taxonomy

Although several definitions and taxonomies of attacks exist (e.g. [38, 28, 6]),we have used Howard’s taxonomy due to the relative coarse granularity andintuitive attack sequence. Since we wanted to present an overview of thepossible attackers and attack strategies, we conclude that this taxonomy suitsour needs the best. It is however unclear how this taxonomy may expressthe difference between insider and outsider attacks.

The entire taxonomy is summarized i figure 3.4. The access sequence isdecomposed below for practical reasons.

3.2 Honeypots

Honeypots are versatile and flexible systems that may serve a number ofneeds in computer systems. Because of this versatility it may be hard todefine what a honeypot actually is. A common definition from [34] is: a

22


honeypot is a information system resource whose value lies in unauthorizedor illicit use of that resource, meaning that a honeypot system is of no valueto an authorized user, as it does not provide any services. Any interactionwith a honeypot is therefore a strong indication of illicit activities.

For research honeypots, i.e. honeypots aimed at gathering information onattackers and attacks, some may argue that the actual value of a honeypotis the monitoring of unauthorized use of the resource, since failing to obtaininformation would render the honeypot worthless. This slight variation is dueto the versatility of honeypots in respect to application areas, and should bekept in mind when discussing honeypots in the upcoming sections.

3.2.1 Types

There are several types of honeypots. We normally group them into two cat-egories; low-interaction and high-interaction honeypots, indicating the levelof possible interaction with an adversary [34].

A low-interaction honeypot simply emulates services and operating systems,and thus limits the possible level of interaction to the level of emulationprovided by the honeypot. The simplest version involves only listening onselected ports and logging all events without ever responding, whereas themore advanced versions may emulate a variety of commands and also respondin a specified manner. Still, when using emulated services, the honeypot canonly respond to sequences of events specified by the programmer. Althoughthis constraint diminishes the complexity and cost of administration, it makesthe honeypot unable to discover new attacks and therefore limits the valueof the gathered information. In addition, emulated services are fairly easy toreveal since there is no way for a programmer to foresee all possible sequencesof events.

High-interaction honeypots goes beyond this emulation by providing a com-plete set of services on a real operating system, which does not imposethe same restrictions on interaction and information gathering as with low-interaction honeypots. The honeypot may therefore interact with an attackerprecisely the way a normal computer would and potentially reveal previouslyunknown techniques or exploits against the system. However, this increasein amount of valuable information comes at a price of dramatically increasedcomplexity and cost of maintenance. In addition, by providing a real oper-ating system, there is always the risk of the attacker gaining control of thehoneypot and using it to launch attacks against other systems. The prevalent

23

3.2. Honeypots

method for mitigating this risk is to utilize data control measures to containinbound and outbound activity of an attacker [32]. Limiting the communi-cation of the attacker ensures that she cannot use the honeypot to attackother systems. This may be done by utilizing a firewall or proxy that allowsall inbound traffic and blocks all outbound traffic.

3.2.2 Application Areas

The versatility of honeypots make them highly valuable in many situations,satisfying different needs. We will here describe some of the more fundamen-tal ways in which to use a honeypot.

Since any interaction with a honeypot is considered unauthorized they canprove to be effective as intrusion detection mechanisms. For example bydeploying a honeypot within the LAN of a company, one can identify attacksoriginating from outside. If the attack is coming from another server on thenetwork one can assume that this server has been taken over by an attackerand is being used in further attacks. See section 3.3 for a more thoroughdiscussion on this topic.

Honeypots can also be used as decoy servers do divert attackers to honeypotsinstead of the actual production system. The idea is to confuse and deceivean attacker so that he wastes time interacting with honeypots, leaving theoriginal system untouched. If it is commonly known that a network is usinghoneypots, but not which systems within the network that actually are hon-eypots, potential intruders may be reluctant to attempt a break-in. However,knowing that a network contains honeypots, an attacker may become morecommitted to detecting anomalies in system behavior, making it harder toconceal honeypots. (see section 3.2.3 and 3.2.5).

When detecting a compromise of a system it is important to respond insuch a way as to minimize the likelihood of it happening again, as well asisolating the possible damage done. However, gaining information on how thecompromise was conducted and what damage has been done may prove to bevery difficult. Especially for high-interaction systems such as mail servers itmight be difficult to determine what is a legitimate operation and what is not.With honeypots, we already know that all interaction is illegitimate whichenables a much faster investigation of the attack and also giving appropriateresponses to it.

The terms production honeypot and research honeypot is often used to de-note whether the honeypot is used for production or research purposes, re-

24


spectively. The production honeypot is aimed at providing better securityprimarily through intrusion detection and deceiving attackers. That is, pro-duction honeypots are concerned with how to prevent, detect and minimizeattacks. Research honeypots are primarily concerned with discovering newattacks or vulnerabilities

In the remaining subsections we will focus on high-interaction honeypots,providing full operating system services, since we are to use this concept inour system.

3.2.3 Event Logging

A central concept with the honeypot technology is gathering of informationon the attack and attacker. There are numerous ways to do this, some ofwhich are better than others. We have some properties that need to befulfilled by the logging mechanism:

1. All events must be logged, containing as much information as possible(time, process, state of the system etc.)

2. An attacker must not be able to change or turn off the logging mecha-nism.

3. The attacker must not be able to remove, change or add events to thelog.

In the following subsections we point out possible ways to achieve theseproperties and discuss issues that arise.

Information Gathering

There are fundamentally two ways to obtain information for the purpose oflogging events in a honeypot; host-based and network-based (see figure 3.5).The host-based approach extracts information directly from the honeypotand either stores it on the honeypot itself (e.g. syslog) or forwards it to acentral log server. The network-based approach uses a sniffer to log all trafficto and from the honeypot and subsequently stores all information on a logserver.

Both host-based and network-based information gathering can monitor andlog all actions (i.e. keystrokes) performed by an attacker and what informa-tion is returned. However, the host-based approach may additionally log the

25

3.2. Honeypots

Server 1

Server 2

Server 3

Gateway

(a) Host-based informationgathering, host based storage.

Server 1

Server 2

Server 3

LoggingServer

Gateway

(b) Network-based infor-mation gathering, serverbased storage.

Server 1

Server 2

Server 3

LoggingServer

Gateway

(c) Host-based informationgathering, server basedstorage.

Figure 3.5: Information gathering and log storage approaches.

internal consequences of these actions, e.g. which processes are running, sys-tem state, etc, enabling fast forensic analysis to patch the security weakness.The black hat community has responded to network logging by encryptingall communication with their victims (e.g. using SSH), making it effectivelyuseless.

Log Integrity

For the logging mechanism to be useful, we need reassurance that the logcannot be tampered with to remove, change or add events to the log.

With logs stored on the honeypot itself, there is always the chance of anattacker disabling logging activity or changing the log to cover her tracks.Editing the system log is for instance a rather easy task, and may be doneeven by the less knowledgable intruders. A way to combat this problem is tostore information on a dedicated log server. Still, the attacker may compro-mise the log server and change the stored log or obfuscate the log by floodingit with fictive events, making forensic analysis a demanding task. In orderto make changes impossible, one might consider using a network printer andstore the log on printed paper. This option still is vulnerable to flooding andalso effectively rules out any computer assistance when analyzing the log.Utilizing a network DVD recorder that stores the log read-only, would allevi-ate the shortcomings of paper storage. Adding an authentication mechanismto the logging server makes flooding harder as an attacker will not be able

26


to authenticate and thus may not obfuscate the log with fake events.

Logging Mechanism Integrity

Under normal circumstances, notifying users (e.g. employees) about loggingmechanisms might prevent them from misbehaving, similarly to the effect ofsurveillance cameras in public areas. In restricted areas however, informingtrespassers about surveillance would increase the likelihood of them attack-ing the surveillance system. Honeypots are restricted areas as there are nolegitimate users and anyone interacting with it may be looked upon as mis-behaving.

For a honeypot to be effective it needs to simulate regular computer systems.Extensive logging is not common in regular computer systems and thereforeneeds to be hidden to prevent detection by the attacker. Although this mayhave been the initial motivation to hide logging, it is far more important toprevent unauthorized alterations of the log. As we have seen in the previoussubsections, host based information gathering is the most effective, but isvulnerable to alterations by the attacker. But if the attacker is unaware of thelogging mechanism, it is impossible to attack. This may be seen as securitythrough obscurity, and is far from ideal. However, leaving the attacker infull control of the system forces some rather unfortunate trade-offs betweensecurity and useability.

3.2.4 Sebek

Sebek [SEBEK] is an advanced data capture tool developed by the HoneynetProject [HNET] to resolve some of the issues we discussed in the previoussubsection. Sebek consists of two major components; a number of host-basedevent recording mechanisms, known as Sebek, and a central server for logging,known as Sebek server. The interconnection of these devices is similar to thatof (c) in figure 3.5. As stated in the previous section, host-based recordingis unaffected by encryption but may be altered by an attacker in completecontrol of the system. A key aspect of Sebek is therefore to be as invisibleas possible to prevent detection of the recording device.

The event recording procedure modifies the system read (sys read) com-mand so that all interaction may be recorded (see figure 3.6). The systemcall table contains pointers to all system commands in the system. Sebekmodifies the pointer value of the system read so that it points to the Sebek

27

3.2. Honeypots

Original Read

Sys_Read

Linux KernelSebek Kernel module

New Read

Read Request

(1)

(2)

(4)

Event recording

(3)

SysCall Table

Read Response(5)

(1) Read request from a user.(2) The sys read pointer in the system call table points to the sebek-version

of sys read.(3) Sebek records the event.(4) Sebek returns to the original read command.(5) The original read command returns the response of the initial request.

Figure 3.6: Sebek manipulates the system read command [35]

kernel module’s new read command. Sebek then records all relevant infor-mation and starts the original system read command which in turn respondsappropriately. Additional hiding of the kernel module is done by installinga cleaner, inspired by common rootkit technologies. The cleaner removesSebek from the list of installed modules, making it harder to detect.

We have seen so far the measures taken to conceal event recording, howeveran equally important task is to conceal the transfer of information to theSebek server. Sebek uses UDP to transmit recorded events to the Sebekserver, but modifies the operating system kernel to create a covert channelthat evades detection.

When an event is recorded by Sebek, it is processed by the packet generatorand transmitted directly to the network device driver of the operating system(OS) kernel (see figure 3.7). Sebek does not use the TCP/IP stack of theoperating system kernel, enabling packets to bypass all kernel based filteringand monitoring devices as these mechanism use the stack. Additionally,Sebek is impervious to ARP spoofing as it does not use ARP to resolve whatMAC address correspond to a given IP address.

A problem arises when the switch forwarding table of the ethernet switchcontains no entry for the Sebek server. Normally such a situation is due toMAC address expiration. In this situation the switch will forward all framesto all ports, with the possibility of an attacker detecting Sebek traffic from

28


Transmitter

Packet Generator

Event Recorder

NetworkDeviceDriver

Socket Interface

TCP/IP Stack

Sebek Kernel Module Linux Kernel

Ethernetregular data flow

Sebek data flow

Figure 3.7: Conceptual view of Sebek packet generation and outflow of data[35]

another host. To combat this, all hosts running Sebek installs their ownversion of the Raw Socket interface1. To distinguish regular packets fromSebek packets, a protocol header has been defined. In this header there is a32 bit Magic Number, specified when configuring Sebek. If a packet arriveswith the specified UDP port number and the magic number, it is silentlydropped by the interface. That way, hosts on the same network will neversee the others’ Sebek packets.

Although Sebek is a sophisticated data capture tool, we will see in the up-coming subsection that there are ways to detect its presence.

3.2.5 Anti-Honeypot Technology

The honeypot technology is founded on deception, that is; the attacker shouldbe unable to determine whether a given system is a honeypot or not. If theadversary could make such a distinction, she would most likely refrain fromconducting the attack, which again would render the honeypot worthless (see

1Used by monitoring devices to access LAN traffic.

29

3.2. Honeypots

definition in the beginning of this section).

Most honeypots do not provide full functionality and therefore cannot ac-curately simulate real computer systems. This leaves them vulnerable todetection by black hats. If it is made publicly known that commerciallyavailable honeypots behaves abnormally to a given input, black hats couldtest the system on this input to see whether it is the specified honeypot ornot. The technique can be used for any abnormality that the honeypot dis-plays, such as deviation from protocol, uncommon virtual hardware devices,delayed processing etc.

Holz and Raynal [14] lists some of the techniques that can be employed todetect abnormal behavior of honeypots. Delayed processing may indicatethat the system is doing more than it should, i.e. there are some hiddenprogram code that slows down processing2. Similarly the counter methodutilizes an instruction counter that is incremented every time an instructionis executed. If the attacker knows the counter result for a specific commandon a healthy system (i.e. without hidden modules), any anomalous countervalue indicates hidden modules.

Send Safe have developed Honeypot Hunter [HUN], a program capable of de-tecting fake proxies (i.e. honeypots) set up to deceive spammers. Accordingto Krawetz [21] the Honeypot Hunter checks for proxy connectivity on a seriesof ports. It opens a false mail server on the local system and connects to theserver’s proxy port. When connected, Honeypot Hunter attempts to proxyback to its false mail server. The reason is that honeypots will simply ignoresuch a request, and respond that the connection has been established. Hon-eypot Hunter will know that there was no connection attempt by the proxyto its fake mail server, yet the proxy claims that connection was successful.The honeypot is therefore detected and interaction with it stopped.

We saw in section 3.2.4 that Sebek utilizes common rootkit techniques to hideits presence. This approach has the rather unfortunate side effect that themethods to detect rootkits also applies to Sebek. Linux systems has a modulelist, a list of currently loaded modules. Sebek manipulates this list so thatSebek does not appear in it. An article in Phrack [Phrack61] explains how toreconstruct the original list, enabling detection of hidden kernel modules ingeneral and Sebek in particular. Holz and Raynal [15] describes another wayof detecting Sebek by inspecting the System Call table. Since Sebek manip-ulates the pointer in the sys read entry to point to a completely differentmemory location (i.e. the Sebek kernel module), detecting Sebek is simply

2This is common manual way of detecting SpyWare and AdWare

30


done by comparing the pointer value to that of a real system.

Although Krawets [21] provides some countermeasures that can be taken toevade detection, he claims that detection is inevitable by the skilled attacker.This could have made all honeypots worthless, but as stated in [15], infor-mation on how the honeypot was detected still is of great value and mayimprove the system. Also, if the attacker detects the honeypot it can bedetached from the network to mitigate the risk of further exploits.

3.3 Intrusion Detection Systems

It is clear that in order for our system to survive attacks, detecting unau-thorized activity is of paramount importance. Intrusion Detection Systems(IDSs) are systems tailored to gather information in order to notify systemadministrators of possible intrusion.

In recent years, Intrusion Prevention Systems (IPSs) have received increasingattention from the security community. IPSs combine the blocking feature offirewalls and the detection feature of IDSs, in order to prevent system intru-sions [39]. IPS may also be seen as automated Incident Response triggeredby an intrusion detection mechanism. We therefore will limit our discussionto include only IDSs, since we will define our own incident response.

3.3.1 Types

There are fundamentally two different types of IDSs; host-based (HIDS)and network-based (NIDS). Host-based systems run on single stand-alonecomputers and may detect attacks relating that particular host. This mayinclude integrity checking of critical files, e.g. system binaries, detecting portscans, non-standard protocol usage, etc. The prime advantage being thatHIDSs normally do not occupy or slow down network traffic, they can inspectaudit trails and system logs, they can monitor execution of commands and soforth. However, for large networks of hosts, this approach may be costly interms of installation and management costs. System administrators are giventhe unrewarding task of maintaining and configuring several different HIDSindividually. Especially when considering the frequency of reported securitybreaches in modern computer system, the updating process may utilize fartoo much resources.

31

3.3. Intrusion Detection Systems

The Tripwire Change Auditing [TW] has been considered the defacto stan-dard for filesystem integrity systems. Although initially an open sourceproject, tripwire is now a full featured commercial product with improveduser interfaces, encryption capabilities and a highly customizable configura-tion. With the commercialization of Tripwire, open source HIDSs, such asthe Advanced Intrusion Detection Environment (AIDE) [AIDE] and Samhain[SAMHAIN], have emerged. These systems contain the most valued featuresof Tripwire but does not include intuitive user interfaces and encryption ofthe file database. However, Samhain does provide database signatures toprevent unauthorized modifications. Other techniques commonly utilizedin host-based IDSs include kernel-level rootkit detection, as proposed byKruegel et al. [22]. It may be noted that most of the techniques for detectingSebek (recall from section 3.2.4) also apply to rootkits in general.

Network-based IDSs may run on entire networks, detecting attempted orsuccessful attacks within the network rather than on single hosts. This isdone by deploying sensors in various parts of the system to analyze networktraffic for patterns matching known attacks, unusual behavior, protocol vi-olations etc. By using relatively few network sensors the the maintenancetask is considerably reduced. However, this comes at a price of less informa-tion regarding host attacks, e.g. machine state, processes running, memoryusage etc. Despite this, NIDSs are currently the most widely used intrusiondetection systems today.

3.3.2 Detecting Attacks

There are several different strategies for detecting attacks that all seeks todistinguish authorized traffic from their unauthorized counterparts. The ba-sic problem of all such approaches is that we do not want attacks to passundetected (false negative) but at the same time we do not want legitimatetraffic being flagged as attacks (false positive). If the threshold for whatis to be considered unauthorized is lowered, this will result in an increasedamount of false positives. Similarly, if the threshold is risen, the amount offalse negatives will be increased. Finding the proper tradeoff between thesetwo, is one of the key aspects of detecting attacks. For the IDS to be useful,network and host resource consumption should be kept at a minimum. Thethree main approaches for accomplishing this are anomaly based detection,misuse detection and specification based detection.

Misuse detection is used to detect previously defined unauthorized activity.It is commonly referred to as signature- or pattern matching technique, as it

32


compares the current activity to a set of signatures of known attacks. Thesignatures may include state information, protocol information, target etc.The apparent weakness is that misuse detection cannot be used to discovernovel attacks, as there are no signatures available. Similarly, if the signaturesare poorly defined, slight modifications to an attack may lead it to bypassthe IDS even if the attack is generally known. This again, may lead toan unacceptably high frequency of false negatives (i.e., undetected attacks),which could yield a relatively useless system.

To overcome some of the shortcomings of misuse detection, anomaly baseddetection focuses on the normal behavior of a system. First, the system isput in a training phase, where it learns the normal behavior of the systemin the absence of attacks. On the basis of this learning process, a profileof the system is generated. The system is subsequently put into operation(detection phase), where it raises a flag whenever it detects deviations fromthe profile. The system is therefore capable of detecting both novel attacksand variations on previously known attacks. The downside of this approachis that capturing normal system behavior is not an easy and straightforwardmatter. This is both due to the dynamic nature of current computer systemsand what features of the system that are considered in the training phase.Any unseen legitimate system behavior would cause the IDS to raise a flag,which may lead to a considerable increase in false positives (i.e., false alarms).

Specification-based detection is similar to anomaly based detection in thatit focuses on the systems normal behavior and raises a flag whenever thebehavior deviates from the profile. However, the profile generation differsfrom that of anomaly detection. It does not utilize machine learning, butinstead relies on the system developers to provide a specification of the in-tended behavior of the system. Naturally, for large systems, this approachmay be extremely complex and time consuming, which may again lead topoor specifications and an increase in false negatives.

Sekar et al. proposes a new approach in [30], that combines the anomaly andspecification based approaches to provide a low level of both false positivesand false negatives.

3.3.3 Event Logging and Filtering

When an intrusion is detected, the normal procedure of any IDS is to cre-ate an event, describing what caused the detection; system state, headervalues, commands executed etc. Events are subsequently analyzed either

33

3.3. Intrusion Detection Systems

automatically or manually by an administrator to establish the cause, effectand possible required updates to patch the vulnerability. The timing of theanalysis part differs, in whether it is done in real-time (or close to real-time)or periodically in predefined intervals. Even though analysis could reveal be-nign activity, the resource consumption could hamper or delay the processingof actual attacks. Manual event-analysis tend to infuriate administrators asthe number of false positives rises. This may effect the thoroughness of theanalysis and as a result cause administrators to ignore actual attacks.

Even though false positives may have a devastating effect on an IDS, they arenormally preferred over false negatives. That is, we generally would like todetect too much rather than too little. To counter some of the unfortunateeffects of this strategy, various event filtering and aggregation techniqueshave been suggested [12, 36].

34

Chapter 4

Minimal Proxy for IntrusionTolerant Systems

In this chapter we present the Minimal Proxy for Intrusion Tolerant Systems(MPITS) developed by Broen in [4], in a greater level of detail. This systemwill form the basis for our survivability architecture presented in chapter 5.We start by giving an overview of the system and its components, and thenpresent the implemented voting mechanism as this is the key feature of thesystem.

4.1 Overview

MPITS was developed to provide a less complex intrusion tolerant systemthat additionally would serve as a reference system when comparing to othermore complex existing systems. Although existing intrusion tolerance sys-tems have a relative high level of complexity, they are still vulnerable tosingle point of failure. Acknowledging that the connection point to the ex-ternal network always will be a single point of failure, MPITS seeks to min-imize the likelihood of compromising the unit by limiting the functionalityand complexity of the system. The low complexity yields better understand-ing and enables a more thorough inspection of the source code to eliminatevulnerabilities.

MPITS utilizes the prevalent technique to achieve intrusion tolerance, namelyreplication of services on disparate software platforms (see section 2.3). Thesystem consists of two types of components; a number of application servers

35

4.2. Functionality

Internet

Linux / Apache 1.3

FreeBSD / Apache 2.0

Windows / IISProxy

Client

Figure 4.1: An overview of the MPITS architecture

and a proxy server (see figure 4.1). The application servers are the serverscontaining the actual service the system is providing, while the proxy serverworks as the connection point to the outside world and manages all inboundand outbound traffic.

MPITS aims at protocol modularity, so as not to restrict the possible proto-cols and services that could be provided by the application servers. However,the prototype implementation includes only support for HTTP on regularweb servers. Still it is evident that only minor changes needs to be done tocater for other protocols and services.

4.2 Functionality

The entire functionality of MPITS resides in the proxy server. The appli-cation servers, thus are not involved in the intrusion tolerant design, theymerely provide the service of the system.

Upon receiving a request from a user, the proxy server will fork a childprocess to handle this particular connection, while the parent process con-tinue listening for incoming connections (see figure 4.2). The request is thenforwarded to the application servers, which process the request and give aresponse. The voting mechanism of MPITS will then determine the appro-

36

Chapter 4. Minimal Proxy for Intrusion Tolerant Systems

Figure 4.2: An illustration of the MPITS Data flow. The listening process(to the left) forks a new process for each request. (translated from [4])

priate response to forward to the user. Since the voting unit is perhaps themain functionality of this system, it will be more thoroughly described in theupcoming section.

MPITS does not implement any specific action to be taken in case of anattack. The function warn admin is intended to be used for this purpose,but currently only prints a warning message to standard output.

37

4.3. Voting

4.3 Voting

The voter is responsible for determining the correct response to a correspond-ing request. The functionality of the voter may be decomposed into;

1) comparing two response PDUs (Protocol Data Units) and determiningwhether they are equal,

2) placing them into equality classes, and

3) determining the correct response PDU.

This list also illustrates the dependencies in the process of selecting the ap-propriate answer. In the next subsections we present these functions anddiscuss how some issues are resolved.

4.3.1 Equality algorithm

The application servers run different software which may cause slight devi-ations in protocol or server implementation, yielding different responses toauthorized requests.It is important to compensate for this when designing anequality algorithm. The task is thus not to determine whether two PDUs areequal, but whether they are sufficiently equal. MPITS focuses on providinga relatively simple equality algorithm to limit the complexity of the system.Additionally it is believed that further improvements of the equality algo-rithm may be done at a later stage, since the simple version will suffice as aproof of concept.

The algorithm basically compares the byte string representations of twoPDUs byte by byte, and counts the number of equal (EB) and unequal bytes(UB). The relationship

d =UB

EB + UB

called the normalized Hamming distance, expresses the degree to which thetwo PDUs are unequal. This relationship is then compared to a predefinedequality threshold. If d is below the threshold value, the PDUs are consideredequal, otherwise they are considered unequal.

In some cases numerical data may be more critical than textual data. Chang-ing a user’s account balance may be more critical than editing the address.

38

Chapter 4. Minimal Proxy for Intrusion Tolerant Systems

MPITS therefore provides a way to weight numerical discrepancies differentlyfrom the textual. Upon detecting numerical values in both PDUs, they arecompared and the number of equal (EN) and unequal (UN) numerical valuesare counted separately. The user defined numerical weight w is then used tocompute the total distance (equality relationship)

d =UB + UN · w

(UB + EB) + (UN + EN) · w

The relationship still needs to be below the given threshold in order for thePDUs to be considered equal. The algorithm handles both binary and textualdata, but do not make a distinction and treats all data as textual. It maytherefore consider numerical values within a binary PDU, and subsequentlyweight them differently. This clearly does not make sense, but the impact isassumed to be moderate, hence it is not corrected.

Since protocol specific meta-data may vary considerably, equality is not com-puted for this part of the PDU. To thwart any covert channels using protocolmeta-data to leak information to the surroundings, they are properly washed(i.e. changed) before the actual response is returned. This is suggested inthe MPITS specification, but not implemented in the prototype system.

4.3.2 Equality Classes

In order to maintain information on previously checked PDUs, MPITS groupsthe PDUs in equality classes. That is, all PDUs considered to be equal areput in the same equality class. A problem with this strategy is that somePDUs may qualify for several equality classes. Additionally, the order ofprocessing may greatly influence the number of equality classes and wherePDUs are placed. We illustrate this situation with an example from [4]:Consider the strings, 1: aa, 2: bb, and 3: ab and a threshold value of 0.6.Strings 1 and 2 will be considered unequal and placed in different equalityclasses. String 3 now qualifies for both of the newly created classes. Theremedy is to put each PDU in all equality classes it is qualified for.

A perhaps more crucial problem is that the algorithm only compares a newPDU to the first PDU of each equality class. Thus if we reverse the orderof the strings defined above, the outcome would be: Strings 3 and 2 areconsidered equal, and placed in the same equality class. Subsequently, string3 and 1 are considered equal and string 1 is placed in the same equality class,even though string 1 and 2 are 100% unequal. This flaw clearly demonstrates

39

4.3. Voting

that the usage of equality classes is not ideal. However, the system is only toserve as a proof of concept, and potential remedies where therefore not fullyexplored.

Non-responsive machines are considered equal and hence are placed in thesame equality class. This way, if two machines are not responding, the onethat does is considered misbehaving. Whether this is a good idea is notentirely clear, but there could be legitimate reasons for the server not torespond.

4.3.3 Determining Response

MPITS defines a set of policies to determine whether the system should re-spond or simply shutdown due to attack. System administrators may specifythe desired policy in the configuration file.

All Equal All responses from the application servers must belong to thesame equality class.

Majority A majority (i.e. more than 50%) of the responses from the appli-cation servers must belong to the same equality class.

Relative Majority The number of occurrences in the equality class withthe highest number of occurrences must be unique.

In all cases, either the result from the specified equality class is returned, orthe system will respond with a standard error message, report an attack andshutdown.

40

Chapter 5

System Specification

Our solution is not so much a system as it is an architecture. We make as fewassumptions as possible both regarding the nature of the services providedand the underlying hardware and software configuration. Instead we envisiona highly portable solution to enhance virtually any computer system.

This chapter explains the overall idea of the architecture and its main fea-tures. For a more detailed description of an actual prototype implementationplease refer to chapter 6.

5.1 Overview

We envision a flexible system capable of enhancing the survivability of anyunderlying functionality. The fundamental design resembles that found inMPITS (see figure 5.1). Additionally we want to utilize the redundancy tolearn more about attacks in order to develop appropriate countermeasures.

A simplified view of the system architecture is depicted in figure 5.2. It issimilar to the design of MPITS as seen in chapter 4 and virtually any intrusionor fault tolerance system available. They all share the basic principle ofreplicated services and central voting. This overview can be used as guidancein understanding the requirements of the system given in section 5.2.

The proxy or request replicator receives all incoming requests from clientsand distributes it to all servers in the network. The servers process the resultindependently and gives their response to the voting unit. The voting unit

41

5.2. Requirements

Figure 5.1: An illustration of the basic idea with our new system. The at-tacker is left in control of the compromised unit without affecting the systemas a whole.

determines the appropriate answer and forwards it to the proxy, which inturn relays it to the client.

The system comprises two internal networks; the proxy and the control net-work. The proxy network is used for all service related data traffic, while thecontrol network is used to exchange control information between the entitiesin the system. Control messages are used to notify other parts of the systemof security events and logging of illegal activity.

5.2 Requirements

The requirements of the system should express the goal of the developmentand form a basis for assessing whether the goal was met. It is customary todistinguish between functional and nonfunctional requirements of a system.However, since security and dependability issues constitutes our prime con-cern, we will focus on the nonfunctional requirement of the system. Somemay argue that if the sole purpose of the system is to enhance security, thanthat is to be considered a functional requirement.

From our discussion of approaches to survivability in section 2.3 we have thefour characteristics of survivable systems (Resistance, recognition, recoveryand adaptability). We will use these characteristics to group our survivabilityrequirements and additionally give the requirements for the basic function-ality.

42

Chapter 5. System Specification

Figure 5.2: Simplified overview of the system and its components.

5.2.1 Functional

The functional requirements of the system involve transparency and contain-ment of the attacker. Transparency is essential both to not bother the userwith the topology of the system and not to reveal the system to a potentialattacker, while containment is important to mitigate the risk of misuse ofthe system.

Req-1 The system should be completely transparent to both authorizedand unauthorized users.

Req-2 The system should properly contain the attacker to render furtherattacks impossible.

43

5.2. Requirements

5.2.2 Resistance

In order to deal properly with new and unknown attacks it is important thatthe system can repel most known attacks. Proper resistance mechanismsensure that the system is not brought down by several simple attacks, sincewe can only tolerate one attack at a time. In doing so, the resistance of thesystem guarantees the efficiency and availability of the system.

Req-3 The system should be properly constrained not to offer any otherservice than what the application servers require.

Req-4 If encryption of communication is required this should be imple-mented in the proxy.

Req-5 The application servers should employ standard configuration andpatching of known vulnerabilities to avoid compromise.

5.2.3 Recognition

As we have stated earlier, detecting attacks is a prerequisite to take properactions to tolerate attacks.

Req-6 The system shall be able to detect discrepancies in the answers fromthe server units.

Req-7 The system shall be able to detect changes in the servers’ file sys-tem.

Req-8 The system should be able to detect both known and unknownattacks and attack patterns.

5.2.4 Recovery and Tolerance

In order to enable tolerance of attacks and fast recovery in face of multipleattacks, the system should conform to the following requirements.

Req-9 The system shall be able to tolerate the compromise of one serverunit.

Req-10 The system shall not leak sensitive information to any successfulattacker.

44


Req-11 The system as a whole shall be able to continue deliverance ofservices transparently to legitimate users in face of attacks.

Req-12 The system shall be able to closely monitor all actions by a suc-cessful attacker.

Req-13 Upon several successful attacks the system shall automatically shutdown and subsequently restart services in a consistent state.

5.2.5 Adaptability

A side-effect of our system is that we may gather information on the attackerin terms of strategies, methods and exploited vulnerabilities. This is essentialfor the systems ability to adapt to the creativity displayed by the black hatcommunity.

Req-14 The system shall be able to identify new attack strategies.

Req-15 The system should be easily configured to cater for new and differ-ent attack scenarios.

Req-16 The system shall produce information on attacks that can serve asinput to the continuous improvement of the system.

The improvement of the system of requirement Req-16 is assumed to be doneby a managed security provider, collecting information from several systems.We do not expect this to be done by the companies providing the services.

5.3 The Components

In this section we will explain the functionality of the different componentsto a greater level of detail. Refer to figure 5.2 for an overview of the systemand its components.

5.3.1 Proxy Server

The proxy server represents the external interface and is the only componentin the system addressable from the outside. The main functionality of theproxy is to replicate all external requests and relay them to the router.

45

5.3. The Components

In some circumstances it may be desirable not to replicate requests to a com-promised host. This is particularly true for services that update informationon the application servers. If the servers provide a payment service, trans-action details are normally considered sensitive and should not reach theattacker (Req-10). However, to meet the transparency requirement (Req-1), it may be necessary to produce fake updates to be forwarded to thecompromised host, so as not to reveal the system to an attacker.

The proxy server represents a single point of failure, since there are no repli-cated proxies. This is generally undesirable as a compromised proxy couldcorrupt the entire system. To minimize the likelihood of such a compromisethe following precautions should be made to conform to Req-3:

• Provide no other services to the surroundings than what is required bythe application servers.

• Apply standard firewall techniques to prevent exploits on different portsthan expected.

• Minimize the complexity (i.e. functionality) and the processing re-quired by the proxy.

We could also have had the proxy running on a read-only medium such asCD-ROM, to mitigate the risk of intrusions. It would however require aRAM-disk for the proxy to store process information, which would makethe proxy vulnerable to memory corruption and illegal state transition. Itis therefore not clear whether this approach actually would contribute tominimizing the likelihood of compromise.

5.3.2 Proxy Network

In order to contain the successful attacker (Req-2), the proxy network shouldbe able to hide the internal network topology, to prevent the attacker fromlaunching additional attacks on the system. It is evident that if the attackeris capable of conducting such attacks, all our efforts are in vain. We thereforepropose to use a router or programmable switch to restrict communication be-tween the application servers, so that the internal system from the attacker’sviewpoint appears to include only the compromised application server.

In the proxy network, the application servers should be unable to commu-nicate with each other, in order to prevent an attacker from conductingadditional attacks on the system. If the attacker is able to launch an attack

46


Figure 5.3: The logical view of how the two main functions of the voting unitare interconnected

on other application servers, all our additional measures are in vain. To re-solve this issue one could use Sebek-like techniques (see section 3.2.4) to hidecommunication. This would however violate the deception requirements asthe attacker would not see its own outgoing data on the network. A betteroption is thus to use dedicated networks. That is, to have each applicationserver connected to different interfaces on the router.

5.3.3 Voting Unit

The voting unit comprises both the actual voting process and the process ofselecting the appropriate answer. These are two separate functions, but theyare so tightly coupled that we treat them as one unit (see figure 5.3).

The response manager is responsible for determining the appropriate re-sponse to the given request. During normal operation, the response man-ager will simply relay the input to the voter and forward the result. Ifdiscrepancies are detected, the misbehaving application server is flagged anda notification is sent on the control network (see figure 5.2). Additionally,the response manager will need to determine the cause of the discrepancy inorder to identify the attacker. This process introduces several questions thatare discussed in the upcoming section.

If the system is under attack, the source of the request will be a factor indetermining the result. That is, if the attacker is the source, the resultfrom the compromised application server will be forwarded. Otherwise, theresponse from the compromised server will be eliminated and regular voting

47

5.3. The Components

Figure 5.4: A detailed view of the server unit, consisting of a diskless appli-cation server and a file server with corresponding harddisk.

procedure may commence.

5.3.4 Server Unit

The server unit is responsible for processing the incoming requests from theproxy server and forwarding these to the voting unit. The unit has beenextended from what we saw in the MPITS system in that it is also responsiblefor filesystem integrity checking to detect attacks and monitoring and loggingfunctionality in the event of a successful attack (Req-7).

As we have seen when discussing host-based IDSs (section 3.3), any servicerunning on a compromised server is to be considered unreliable, since anattacker in complete control of the system may change the service or turn itoff entirely. This lack of trust is handled by the voting unit when it comes toresponds to the users. However, the voting unit does not handle unreliabilityin the detection, monitoring and logging mechanism of the server unit. Wetherefore propose to split the unit into two physical parts; an applicationserver (AS) and a file server (FS) (see figure 5.4).

The AS is assumed to be any COTS server, providing services to its users.The only exception is that the AS will not have a hard disk attached, it willmount its filesystem from the dedicated file server.

48


The FS will be a server with one additional hard drive or partition to beshared to the AS. In the absence of attacks, the FS will continuously conductfilesystem integrity checks on the AS. In the event of an attack, the FS willenter the attacked mode, which causes it to obfuscate all sensitive data onthe AS and turning on extensive logging of all events. The transition into theattacked mode may be triggered either by the file server itself on the basis ofinconsistent filesystem or by the voting unit upon detection of discrepancies.

The logging mechanism of the file server is only capable of monitoring diskoperations, and does not record the system calls performed by the attacker.We therefore also propose to have the application servers install Sebek tocater for a more extensive logging of the attacker’s actions. The applicationservers will thus report the events recorded by Sebek to the correspondingfile servers, which in turn will forward them to the logging unit.

5.3.5 Logging Unit

The logging unit is responsible for storing the events reported by the fileservers and voting unit. Additionally, upon a successful attack, the loggingfacility of the file server will transmit all data to the logging unit.

In section 3.2.3 we discussed several different approaches to information gath-ering and logging (see figure 3.5). On the basis of this discussion it is notstrictly required to have a centralized storage facility, since the file serveris considered trustworthy even under attack. However, to build a propersurveillance system it may be useful since we know where to find the logregardless of which server is under attack.

5.4 Technical Issues

There are some technical issues that need to be resolved in order for oursystem to work. In this section we will elaborate on these issues and pointout some of the possible ways to resolve them.

5.4.1 Identifying Users

The only general way of identifying a user on the internet is by the IP-address.This identification is however not without flaws.

49

5.4. Technical Issues

Shared addresses Due to the limited address space of IP version 4 (IPv4)technologies has emerged to enable shared public addresses (e.g. Net-work Address Translation (NAT)). With the introduction of IPv6 thelimitations in address space will no longer be an issue. Addition-ally, several users may be logged on to a central computer throughX-terminals, yielding identical IP-addresses of the users.

Dynamic identities DHCP and similar protocols may grant users a sessionlimited IP-address. Thus upon a new session a different address maybe given.

Multiple identities An attacker may control several compromised hosts(commonly referred to as botnets), that may be utilized in the attack.These hosts naturally have different IP-addresses although the sourceis identical.

The basic problem is that there does not exist a one-to-one relation betweenaddresses and users. We therefore need to employ other techniques to combatthese identification issues.

Using certificates (e.g X.509 [16]) or other cryptographic tokens and SSL/TLS[8] authentication is one approach to properly identify and authenticate theusers. Identification may thus be based on the serial number or other param-eters of the certificate. A proper Certificate Revocation List (CRL) needs tomaintained to contain abuse of exposed private keys.

If the service is to be open to all, applying the above mentioned techniquemay not scale and additionally may not work as intended. Generally, allproblems arising from IPv4 identification will reappear here.

5.4.2 Coupling of Attacker and Attack

One of the major challenges in our system is to link a successful attack to thecorrect attacker. If we were to confuse an authorized user with the attacker,the system would cease to be survivable. The authorized user would besupplied with bogus information, and any update would be without effect.Strong coupling of attacker and attack is therefore vital in order to providea trustworthy system.

Upon detecting an attack, the problem is to determine the source of the at-tack. Intuitively we may assume that the source of the first request causinga discrepancy is to be considered the attacker. This is also generally true

50


(1) The attacker initiates the attack.(2) An authorized user performs a benign request.(3) Changes caused by the attacker confuses the voting unit into assuming

that the benign request is an attack. The authorized user receives bogusinformation (red).

(4) The actual attacker is undetected.

Figure 5.5: An illustration of the concurrency problems related to the cou-pling of attacker and attack.

if the requests are processed serially. However, parallel processing is gener-ally favorable when considering the throughput of computer systems. In asingle processor environment, parallel execution is simulated by interleavingprocesses. Figure 5.5 illustrates how an authorized user may be erroneouslylabeled an attacker in a concurrent multiuser environment. By interleavingthe requests the cause of the attack is obfuscated. What we know is that anattack occurred, but we do not know when or by whom.

To narrow down the possible sources of attack we could maintain a list ofall pending requests. The requests are added to the list upon reception bythe proxy, and subsequently removed after processing as long as the proxydetects no discrepancy in the responses. Upon detecting an attack, the pos-sible sources of the attack have been limited to the ones occurring in thelist of pending requests. Although this approach greatly reduces the pos-sible sources of the attack, we still need to determine which request to beconsidered an attack.

From our discussion of IDSs in section 3.3 we saw how anomaly based de-tection can be utilized to detect previously unknown attacks. Anomaly de-tection specifies patterns for normal requests in order to detect any requestdeviating from it. Although IDSs generally suffer from a high rate of falsealerts, this will not be the case in our system. The reason is that upon acti-

51


Figure 5.6: Illustration of how obfuscation by partition swapping may beorganized in the file server.

vating the anomaly detection we already know that an attack has occurred.We simply need the anomaly detection to point out the request deviatingthe most from the specified normal. In this situation, properly configuredanomaly detection may prove to be well suited.

5.4.3 Obfuscating Data

To meet the requirement of not leaking any sensitive information (Req-10),the file server must be able to obfuscate this information instantaneouslyupon detecting an attack. By obfuscation we mean to make the data worth-less to the attacker. Additionally, to make this obfuscation transparent tothe attacker (Req-1), it should not be apparent to the attacker that it hastaken place.

Due to heavy processing requirements, an on-demand obfuscation techniquewould be slow and also would scale poorly for large amounts of data. Insteadwe utilize a pre-obfuscation technique, where we have an obfuscated versionof the sensitive data, and upon attack we replace the sensitive data with theirbogus counterparts.

Replacing data may either be done by overwriting existing files, re-linkingexisting files or simply changing the entire partition. The first two techniquesare based on sensitive information stored in regular files. The latter techniqueis perhaps the most flexible technique since it assumes nothing on how thedata is stored and may therefore also be used for database services. Figure5.6 shows how the partitions may be organized in the file server.

52


If authorized users are able to change or add data to the valid partitionon the application servers, we need an additional mechanism to performa corresponding update of bogus data to the invalid partition. Althoughchanges to the valid partition may easily be detected through file integritychecks, producing the corresponding valid-looking bogus information mayprove to be more difficult. The main requirement of such bogus data is thatit is syntactically identical to the valid counterpart. In most cases, the servicewill not accept arbitrary data to be added, thus forcing a common syntax forall updates. If such syntaxes are available, the detection mechanism on thevalid partition only needs to detect which file changed and launch a scriptor program create the bogus file based on the valid file and a predefined setof rules. For example a valid update to a database containing credit cardnumbers may may produce an invalid update by replacing the valid numberswith randomly generated numbers and random names picked from a list ofvalid names.

5.4.4 Deception

The system should be transparent to both users and attackers (Req-1). Fromthe user’s point of view, transparency is provided by masking the internalcommunication of the system. However, if an attacker were to gain fullcontrol of a component in the system, additional measures are needed toguarantee transparency. In the following we will use the term deceptionwhen speaking of transparency for the attacker.

It is vital to all honeypot technologies to conceal their actual purpose, sothat the attacker may be observed in a realistic environment. If the attackerbecomes aware of the honeypot, she may behave differently or explore otheravenues of attack. In our system, the honeypot concept has the followingthree major goals (in order of priority):

1) Detaining the attacker so that the other parts of the system are left inpeace.

2) Provide information on how the attack was carried out so that vulner-abilities may be discovered and patched.

3) Monitor the attacker to gain information on the motives or intentionsbehind the attack.

Our problem is similar to what we saw when discussing honeypots in generalin section 3.2; it is virtually impossible to perfectly disguise a fake system

53


as a valid one. Our deception techniques will therefore focus on making itharder for the attacker to reveal the system rather than impossible.

To an attacker, anything deviating from what is considered normal mayindicate a fake system. In our system there are three apparent deviations:

• How the root directory is mounted.

• The number of network interfaces cards (NICs).

• The IP-configuration.

Normal servers have their own disk and mounts the root filesystem from apartition on it. In our system the root filesystem is mounted externally froma file server. Although it is possible that a regular server is diskless, it is stillextremely rare and could cause the attacker to become suspicious. In oursystem, the application servers have two NICs as opposed to one in regularservers. Again, several NICs are indeed possible also in regular systems, but isnot considered normal. The globally addressable IP-address of our system ismapped to the proxy server rather than the application server. Thus, the IP-addresses of the application server is not globally addressable, indicating thatthe proxy does exist. Using proxies or firewall servers is however relativelycommon, so this property may not immediately cause suspicion. It doeshowever reveal the existence of an internal network that the attacker mayseek to explore, contradicting our main goal of deception.

5.4.5 Containment

Although the attacker is left in control of the unit, she should be containedso as not to be in a position to conduct further attacks (Req-2), either onother servers in our system or on external systems.

The latter may be controlled by limiting the number of possible outgoingconnections from an application server to the surroundings [32, chapter 12].It may also be considered to disable the forwarding capabilities of the proxyserver to completely disallow outgoing connections. Such an approach mayhowever contradict deception requirements. In any event the attacker shouldnot get unlimited access to the outside world.

54


Figure 5.7: The extended view of the overall system architecture

5.5 System Design

Collating the requirements, components and technical issues discussed aboveyields the entire system design as shown in figure 5.7.

Although the logical components of the system should be deployed on dif-ferent physical devices, some of the units may be implemented on the samedevice. The exception is for the application and file servers, since the physi-cal separation is essential to establishing a trust relation in the detection andmonitoring of the attacker.

The proxy network has been design using a router (or programmable switch),to ensure that application servers are unable to communicate with each other.

55

Chapter 6

Prototype Implementation

In this chapter we will describe the process of implementing a prototype ofour system.

The main goal of implementing a prototype was to show that the systemcould be realized. That the system is not to be considered strictly theo-retical, but that it may also be developed for commercial use. However, inthe development phase, several simplifications had to be made due to timeconstraints.

6.1 Overview

The prototype system depicted in figure 6.1 deviates from the specification inthat we have put the proxy, voter and logger into one physical unit. This wasdone to simplify the communication between these entities in the system.

In order to reuse the MPITS system we have assumed that the applicationservers will be standard web servers and may only handle HTTP traffic. Ifwe were to cater for other types of services it would have required changesto the equality algorithm of the MPITS system.

57

6.1. Overview

Figure 6.1: An overview of the prototype implementation.

58

Chapter 6. Prototype Implementation

Application Server Operating system Web server

server 1 Debian sarge (2.4 kernel) Apache 2.0

server 2 Debian sarge (2.4 kernel) Apache 1.3

server 3 FreeBSD release 5.4 Apache 1.3

Table 6.1: The operating system and web server software used in the proto-type.

eth0 eht1 eht2

Application Server 10.X.0.1 10.0.0.X –

File Server 10.X.0.2 10.0.1.X –

Proxy Server 10.0.0.4 10.0.1.4 129.241.208.225

Table 6.2: The network configuration for each network interface card in thesystem. To obtain the actual addresses for each application and file serverthe ‘X’ is substituted with the corresponding server unit number.

6.1.1 Software

The diskless servers were supposed to run on different platforms as well asdifferent web servers. However, due to time constraints we had to limitourselves to Linux/Unix systems (table 6.1). We therefore aimed at havingtwo different Linux distributions and one Unix distribution. As we will seein the upcoming section, problems building a satisfiable kernel forced us touse two identical Linux distributions. Additionally the we used only the twomain releases of the Apache web server. The requirement of disparate serverplatforms are thus not met entirely. The effect of this will be debated inchapter 7. The proxy server software was developed on a Debian sarge basedLinux machine using the ANSI C programming language[19].

6.1.2 Network Configuration

The system consists of two main switched networks, known as the proxynetwork and the control network. In addition there are three small networksconnecting the diskless servers and the file servers.

59

6.2. File Server

6.1.3 Licensing

The MPITS system is licensed under the GNU General Public License [GPL],which forces the our extension to apply the same licensing. Additionally wecan see no reason why this system should not be made free, since we do seethe need for changes to best suit different needs.

6.2 File Server

Although the file server is generally invisible to the users, it is considered thecore of the server unit. The following should be provided by the file serverand offered to the diskless server.

• DHCP services.

• A network Boot image.

• NFS capabilities to mount the root system.

• A full root filesystem.

Additionally it should provide surveillance and logging services to the log-ging unit (i.e. proxy server). In the following subsections we present theconfiguration needed to provide these services.

6.2.1 DHCP

In order for the diskless server to communicate with the file server overthe local network, it needs to obtain an IP-address. In our system we couldhave used a point-to-point protocol (PPP), since communication between thediskless server and the file server is done on a dedicated network. However,DHCP is commonly used for this purpose, so to ease the implementation wechose to use this protocol.

The DHCP server is responsible for handing out an IP-address to the disklessserver and giving the paths to the boot image and the root filesystem. Theseare thus the main changes that needs to done to the configuration. A fulldescription of the configuration file is given in appendix A.1.

60


6.2.2 Network Boot Image

To let the diskless server boot properly the file server needs to provide a bootimage capable of remote booting. The boot image is comprised of the kerneland an RAM-disk containing the kernel modules to be loaded.

The kernel in general needs to be rebuilt to include support for mountingthe root directory over NFS, DHCP support and support for the desiredNIC. It is important that these features are not included as modules, sinceall modules will be loaded after the root filesystem has been mounted, andwithout these features the root filesystem cannot be mounted. Additionallyone should strip the kernel of all unnecessary features, in particular thosethat are loaded as modules after boot up. After building a proper kernel, aninitial RAM-disk is created using the kernel and the loadable modules of theconfiguration.

In order for EtherBoot to work properly a network bootable image needs tobe created on the basis of the kernel and the initial ramdisk. The mknbi

(MaKe Network Bootable Image) tool developed by the EtherBoot project[EBOOT] does this job automatically.

It is worth noting that the process of building a kernel is time consumingand error prone for inexperienced users. It is also recommended to use thesource code of the file server’s kernel to build the new kernel. After severalunsuccessful tries we had to abandon building a Linux 2.6 kernel for disklessboot. Our FreeBSD 5.4 kernel on the other hand worked exactly as it wassupposed to. For our Linux servers we turned to the pre-built kernels ofLessdisks [LDISK]. Lessdisks will be discussed in an upcoming section.

6.2.3 NFS

The EtherBoot ROM image requires either NFS or TFTP (Trivial File Trans-fer Protocol) services in order to load the boot image from the file server.Additionally NFS is required to mount the root filesystem after the bootimage has been loaded. To limit configuration and maintenance we thereforeused NFS for both purposes.

Configuring NFS basically consists of specifying what files (or folders) shouldbe available to the diskless server and what rights should be granted to itsusers. We only allow for the diskless server to access its root filesystem.The diskless server is given read and write permissions. By default, NFSmaps a superuser on the diskless server to the user nobody on the file server.

61

6.2. File Server

Figure 6.2: An overview of the file server filesystem. The root filesystem ofthe diskless server should be mounted as a separate partition. The documentroots should be placed on a partition other than the one containing thediskless filesystem.

Thus the superuser gets fewer privileges on the file server than regular users.We however need superuser privileges on the file server in order to simulatean ordinary system. We therefore use the option no root squash, whichsuppresses the aforementioned mapping of superusers. We also limit accessto the root filesystem partition so that only the diskless server with thespecified IP-address may access it. Additionally, no access from the controlnetwork is allowed.

6.2.4 Root Filesystem

If the file server were to share its root filesystem, in particular the binary files,with the diskless server, monitoring changes would be difficult. We thereforeprovide the diskless server with an entire filesystem. The filesystem of thefile server is depicted in figure 6.2.

Populating the additional filesystem may be done in several ways depend-ing on the structure of the file server’s filesystem. We may copy an entirefilesystem from elsewhere to the diskless folder (see figure 6.2). Or we couldinstall the system on a different partition of the hard disk, and subsequently

62


mount this partition as the diskless folder. Another option is to use softwarepackages like Lessdisks [LDISK], which upon installation unfolds an entireDebian sarge based filesystem. After the troublesome building of a new ker-nel (as noted above), we used Lessdisks for both our Linux based servers.For the FreeBSD operating system, we used a command make world thatinstalls a copy of the entire system into a different folder or partition.

To perform the immediate obfuscation of data on the application server, welet the file server control both a valid and an invalid version of the documentroot. Next we create a link from the web server document root to the validdocument root (see figure 6.2). Upon an attack a Bash script is run thatlinks the web server document root to the invalid version on the file server,i.e. changes all valid files to their invalid counterparts.

6.2.5 System monitoring

To monitor the filesystem of the diskless server we utilize common file in-tegrity checkers. Tripwire [TW] has been the preferred choice for severalyears, however it is only the commercial version that has been maintainedover the past years. We therefore chose to use Samhain [SAMHAIN], an opensource solution developed and maintained by Samhain Labs. Samhain is fa-vorable also because it provides a logging server utility to cater for centralizedlogging (as we recommended in section 5.3.5).

To configure Samhain a set of predefined policies are mapped to the fileswe wish to monitor. Each policy specifies a set of properties that will bemonitored for the given files or directories. The possible policies include:

Attributes Only changes in permissions and ownership are checked. Usedfor files that commonly changes but still should be owned by a specificuser (e.g. root).

LogFiles Changes in signature, timestamps and size are ignored. As thename implies this is used for log files that commonly changes size.

GrowingLogFiles Changes in signature, timestamps and increasing sizeare ignored. Used for system log files, that only should increase in size.To make sure that nothing is removed from the log, e.g. to concealillegal operations.

IgnoreAll Nothing is checked. May be used to specify files that should notbe considered, e.g. inside a ReadOnly directory.

63

6.2. File Server

Level Significance

none Not logged

debug Debugging-level messages

info Informational message

notice Normal conditions

warn Warning conditions

mark Timestamps

err Error conditions

crit Critical conditions

alert fatal error, causing abnormal program termination

Table 6.3: Possible severity levels of policy violations and thresholds forlogging [29].

IgnoreNone Everything is checked, including access time. May be usedfor decoy files that should not be touched. For example, create thesecret password file, and detect if someone tries to access it.

ReadOnly Everything except access time is checked. Commonly used forsystem binaries, that are not supposed to change.

User User configurable policies. May be used for files that does not fit anyof the above definitions or combinations of it.

Some policy violations may be more critical than others, therefore Samhainprovides a way to set the severity level for violations to each policies. Thepossible severity levels are described in table 6.3. The mapping of policies toseverity levels are done in the configuration files (see appendix A.3)

Samhain also provides several means of alerting its surroundings about policyviolations. This may be dealt with differently according to the severity ofthe violation. For example, may an event with debug severity be logged tothe Samhain log file, while a critical or alert event may generate an emailto the system administrator. In the configuration file each logging facility isstatically mapped to a severity level indicating the threshold of what shouldbe logged. The different log options are described in table 6.4.

As we saw in section 3.1, it is common for attackers to install loadable kernelmodule rootkits in Linux/Unix environments. Samhain therefore also pro-vides a means for detecting whether such a rootkit has been installed. Thecheck is very fast, allowing for short intervals between checks. One may alsospecify the severity level for the kernel policy violation.

64


Log option Description

Mail The message is sent to a specified e-mail address

Print The message is printed to standard output

Log The message is logged in the Samhain log

Syslog The message is logged in the system log

Export The message is sent to the log server

External An external (user specified) script or program is called

Database The message is logged to a database

Table 6.4: The different options for logging events in Samhain [29].

6.3 Diskless Server

In regular servers the local hard disk provides all necessary data for thebooting process as well as the root filesystem. In a diskless environment, thisdata need to be loaded over a network interface from a remote server (i.e.the file server). All the diskless server needs to know is thus where to getthe data and how. After the data has been loaded and the root filesystemhas been mounted, the server may be identical to any other server. The twoprevalent methods for making a diskless client boot from a remote server arePreboot Execution Environment (PXE) and EtherBoot.

PXE was developed by Intel [PXE] to simplify the process of managing soft-ware changes on minimal computers. It is incorporated in virtually all newnetwork interface cards (NICs). The boot order of the BIOS is changed toenable network booting. PXE utilizes DHCP to receive an IP address fromthe file server. The response from the file server also contains a path tothe root directory and the boot image to be downloaded. The boot imageis subsequently loaded using the Trivial File Transfer Protocol (TFTP) andthe root filesystem is mounted using the Network File System (NFS) mountdaemon. PXE has the great advantage that no additional configuration ofthe client is necessary, all configuration is done in the file server. The down-side is that error messages are cryptic, making troubleshooting an extremelyunrewarding task. We could not get PXE to work properly, without beingable to determine the cause of our problems, we shifted to using EtherBoot.

The EtherBoot Project [EBOOT] is an open source project aimed at creatingROM images that can download code over an ethernet network to be exe-cuted on a host computer. EtherBoot is supposed to be installed on the ROMchip commonly found in network adapters. However, it also provides ROM

65

6.4. Proxy Server

images for floppy disks, which is convenient since burning ROM chips requirespecialized equipment and is not suitable for testing. Since the very goal ofour development is testing, we have only considered the floppy variant ofEtherBoot. Using the EtherBoot software package one can build customizedimages for many needs. There is also an automatic floppy disk image cre-ator available [ROM], which makes the process of creating images relativelyeasy. We need NFS support for downloading the boot image from the fileserver, the only required change is thus to enable DOWNLOAD PROTO NFS inthe configuration file.

6.4 Proxy Server

The proxy server is an extension of the MPITS system described earlier. Inaddition to forwarding capabilities the main feature of the MPITS proxyserver is the equality algorithm. In our prototype implementation we willreuse this system to cater for the basic functionality. Additionally we haveimplemented support for handling security events triggered by the votingunit and the integrity check performed at each file server.

6.4.1 Distributing Requests

As long as the system is not compromised the requests are distributed toall application servers. However, once one application server is attacked, adecision needs to made whether to forward regular requests to the compro-mised server. This decision is mainly dependent on the underlying servicesof the system. As a general rule, if the request does not pose a risk of reveal-ing sensitive information, requests should be forwarded to the compromisedserver not to cause suspicion. In our system the choice is made in the proxyconfiguration file.

On the other hand, we can see no reasons why requests made by the attackershould be distributed to the other application servers. We therefore haveimplemented a checking mechanism, that causes the requests made by anattacker to only be distributed to the attacked server.

66


6.4.2 Coupling Attack and Attacker

The detection mechanisms in our system include the voting unit and thefile server integrity checker. Although they are both capable of detectingdiscrepancies, identifying the attacker and attack is not straightforward.

We first consider using the voting unit to determine the cause (i.e. attack)and the source of the attack. (i.e. the attacker). As we saw in section5.4.2, the problem is that concurrency may cause problems that are not eas-ily resolved. In our system we simply assume that the first request causing adiscrepancy in the proxy is to be considered an attack. The source IP-addressof the request is thus to be regarded as the attacker. We acknowledge thatthis choice is vulnerable to the situation from figure 5.5, and that most sys-tems are required to handle concurrent requests. Implementing the proposedsolution from section 5.4.2, have been tried using a table of pending requests.However, due to time limitations finding and incorporating an appropriateanomaly based detection system was not feasible.

Utilizing the file server integrity checker seems even more troublesome. Thereason is that the integrity checker runs on the file server completely inde-pendent and unaware of the application server. It therefore has no infor-mation on the current request being processed or the source of the request.Additionally, the integrity checking is a continuous process, and several re-quests may be made between each time a file is checked. To resolve thissituation one would have to let the file server complete a full integrity checkbetween each request made to the application server. Naturally, this wouldhave added an enormous processing penalty, and was therefore not consid-ered useful to implement. Instead we have chosen to let the proxy server askthe file server after each response from the application server whether therewere any changes to the filesystem. If the file server reports an error in thischeck, the corresponding unit is simply taken out of operation but no at-tacker is marked. Although this is not optimal it provides extra reassurancethat sensitive data will not leak to the outside world through an undetectedattack.

6.4.3 Deciding Response

What the system should respond to a request relies on whether the system isunder attack, who is requesting information and whether discrepancies wasdetected.

67

6.4. Proxy Server

Underattack?

Source?

Attacker

No

GreatestEqClass?

Majority(none)

MinorityMark source

ErrorFailed/Exit

1

2

3

Specific(none)

Yes

Majority(none)

ErrorFailed/Exit

12/3

Not attacker

GreatestEqClass?

Majority – the response corresponding to the majority decision of the voting unitMinority – the response corresponding to the minority decision of the voting unit.Specific – the response from the attacked server.Error – the predefined error response.Failed/Exit – the system has failed, shutdown required.Mark source – the attacker must be logged for future reference.

Figure 6.3: Overview of the process of deciding the appropriate response tothe user. The rectangular boxes indicates the proper response (above) andadditional operations to be done (below).

The process of deciding the appropriate response is illustrated in figure 6.3.We start by determining whether the system already is under attack. If not,the outcome of the voting process determine the response. This is identicalto MPITS with one exception: a discrepancy indicates an attack and theerroneous answer is given to the attacker. If all answers are unequal, the sys-tem is unable to determine the proper reply and shutdown is required. Oncethe system is under attack, we first check to see whether it is the attackerrequesting information. If so, the response from the attacked server is for-warded to the attacker. Requests from regular users during attack is treatedthe same as requests to an uncompromised system, except that the optionalresponse from the compromised application server will not participate in thevoting.

68

Chapter 7

Evaluation

In this chapter we will try to determine whether the implemented proto-type actually does provide increased survivability. There are currently twoprevalent strategies for assessing whether the survivability and security re-quirements where met; testing and analysis.

In order for the evaluation to be of any value, we need reassurance thatthe applied methodology is valid. Clearly, if the evaluation methodologydoes not accurately capture the problem areas, it does not provide the de-sired reassurance. Several such methodologies have been proposed (e.g. [2]).However, due to the limited testing (discussed below) and the fact that oursystem relies heavily on third party software, we will not employ a formalmethodology, but instead argue for the fitness of use.

7.1 Prototype Testing

The main functionality of the system is to detect attacks, label the attackerand obfuscate the data. Initially we wanted to launch a realistic attackon the server. However, this relied on two prerequisites; 1) determining avulnerability in the server, and 2) knowing an exploit of the vulnerability.Although vulnerabilities are commonly found, we did not succeed in findinga corresponding exploit. This unfortunate situation left us with the option ofsimulating attacks, rather than actually conducting them. The test resultsare thus based solely on simulations.

It is worth noting that although using a vulnerability and the correspondingexploit to test the system is favorable, it does not provide guarantee that the

69

7.1. Prototype Testing

system will detect all other exploits. The problem of validity relates to alltesting procedures, since the limited time frame would pose restrictions onthe amount of testing.

There are fundamentally three modes of operation for the system;

• Normal operation – the system is not under attack.

• Attack – the transition from normal operation to abnormal operation,caused by a malicious request to the system.

• Abnormal operation – the system is under attack, and both the attackerand legitimate users may request information.

In the following we describe the simulated tests and their correspondingresults.

Normal Operation The system was put into normal operation, not ex-posed to hostile traffic and requests were made by a legitimate user. Re-quests where processed by all application servers and they returned equalresponses. This functionality is equal to that of MPITS and the test showsthat our changes has not affected the basic functionality of the system.

Attack The purpose of this test was to determine whether the proxy servervoting unit would detect discrepancies, mark the attacked server and thesource of the attack, and perform automatic obfuscation of data, in the eventof an attack.

Since a real attack could not be launched we simulated the attack by doingthe following:

1) make some changes to the document root of one application server.

2) perform a request to the system.

3) simulate that this request caused the document root to change.

Although this test seems insufficient at first glance, it really does capture ourassumptions on attacks. We assume that a successful attack on one serverwill cause deviating responses from the application server. By changing thedocument root, we simulate the discrepancies in reply from the applicationservers.

We launched the “attack” from the source IP-address 129.241.208.225. Theproxy server detected the attack and identified the source IP-address as the

70

Chapter 7. Evaluation

origin of the attack. The document root on the file server was subsequentlychanged to the predefined invalid. This shows that the system is able todetect and identify attacks through the use of the voting unit.

Next we changed the document root of the application servers such that allservers would respond differently. The proxy server returned the standard er-ror file (specified in MPITS), stating that the request could not be processed,and subsequently shutdown the system.

Abnormal Operation During abnormal operation (i.e under attack) thesystem should be able to distinguish requests from the attacker and requestsfrom regular users. Regular users should still get valid results from theirenquiries, while the attacker should get bogus (invalid) information.

From the source IP-address 129.241.208.225 we made a request for the fileindex.html, returning the invalid version of this file. We next made a requestfrom another IP-address for the same file, returning the valid version. Thesystem is thus capable of doing the desired differentiation between regularusers and the attacker.

7.2 Analysis

Due to the limited amount of testing we were able to perform, we will inthis section conduct a more detailed review of the system. We do not intendto conduct a formal software inspection, but rather analyze the choices ofsoftware with respect to fitness for use.

7.2.1 NFS Security

Although NFS has been renowned for its insecurity, most of these issues re-lates to a completely different situation. Problems occur in particular whena NFS server is used on an open network, where other than the intendedusers may have access to the server [10, Chapter 15]. The lack of user au-thentication, encryption and state control may be utilized by an attacker togain unauthorized access to the server.

However, in our system the NFS servers (i.e. file servers) are on internalnetworks only available to the application server. Encryption, authentication

71

7.2. Analysis

and state control does not apply our system, since the only client physicallyconnected to the NFS server already has full access to all exported files.

And according to [10] getting access to more than what is exported is gener-ally not considered an issue with NFS. Still, the main reason for using NFSwas convenience. Other network filesystems, such as the Andrew File System(AFS), may be considered for increased security.

7.2.2 False Positives and False Negatives

When discussing IDSs in section 3.3 we saw that the efficiency of current IDSsis hampered by a high rate of false positives and false negatives. This has tobe taken into consideration since our system relies on intrusion detection inorder to work properly.

If our system is unable to detect attacks it may be considered completelyuseless. There is generally two ways in which this could happen:

1. Both the voter and the file integrity checker are unable to detect dis-crepancies.

2. The entire system or the majority of its server units are compromisedsimultaneously.

If we consider the first scenario, we know that the voter will detect discrep-ancies if the response from the server units differ. To bypass this detectionthe attacked server needs to respond with the exact same answer as the othernon-attacked server, not only in the actual compromise of the server but alsofor every subsequent request from the attacker. If this is somehow managed,the attack will in most cases cause changes to the server’s filesystem, whichis detected by the integrity checker. The exception is thus when an attackbypasses the voting unit and does not cause changes to the filesystem. Thesecond scenario is a slight variation of the first, since compromising all hostsmay lead to them responding identically, bypassing the voter completely.However, the file integrity checker will detect any changes in the filesystemand all servers will be marked as attacked. Thus the possibility of false neg-atives requires the attack on one server to produce equal responses from allapplication server and additionally does not change the filesystem.

The other main possibility of system malfunction is to mark authorized usersas attackers (false positive). Some of the possible scenarios leading to thissituation are listed below.

72

Chapter 7. Evaluation

1. The user (or user software) is unintentionally attempting to use servicesthat are not provided.

2. The contents of the application servers differs yielding a correspondingdiscrepancy in the voting unit.

3. The threshold of the equality algorithm is not properly configured.

The first scenario may be countered by applying validation of requests ei-ther on the proxy or the individual application servers, to enable a uniformreply. The second and third scenario deals with improper configuration ofthe application server and the voting unit respectively. If the contents of theapplication servers differs, a random legitimate request may be detected asan attack by the voting unit. Proper updating of the application servers arethus of paramount importance. In some cases it may be desirable to haveslight variations in the contents of the application servers. Such deliberatediscrepancies may be handled by increasing the threshold of what is to beconsidered identical.

From this discussion we see that false negatives are highly unlikely, whilefalse positives may occur as a result of a poorly configured system.

7.2.3 Disparate Server Platforms

As seen in section 6.1.1 the application servers are not running on sufficientlydisparate server platforms, both in terms of operating systems and web serversoftware. Since this is a prerequisite for the entire system it is evident thatour prototype is far from realizable in the commercial world. However, sincetesting was mainly accomplished by simulations, the effect on the testingprocess is rather limited. It is worth noting that for more realistic testing ofthe system, other operating systems should be employed.

7.2.4 Single Point of Failure

Like the MPITS system the proxy server constitutes a single point of failure.That is, if the proxy server is successfully compromised, the entire system iseffectively compromised. Since the proxy server controls all checking mech-anisms, the attacker may turn off or change the monitoring to her liking. Itis therefore of uttermost importance to restrict access to the proxy server byemploying firewall techniques as well as restricting the possible computations

73

7.3. Evaluation Summary

performed by the proxy. In our system we have utilized Iptables packet fil-tering [IPTab], to restrict incoming, outgoing and forwarding packets for theproxy server. Hardware firewalls are more versatile, flexible and resistant toattacks and are thus preferred in some cases.

7.3 Evaluation Summary

From the prototype system testing, the main result is that the system worksas intended and described in the previous chapter. It is however evidentthat simplifications made to the prototype and the inadequate testing of it,greatly reduces the validity of this initial result.

The testing process should have included real-world attacks in order to prop-erly assess the capabilities of the system to detect attacks. However, theresults by real-world attacks may have been limited due to the low degreeof software disparity. This weakness is not apparent in our system, sincewe only simulate attacks and therefore also simulate the differences amongstsoftware platforms.

Other shortcomings of the system relates to imperfect software choices, suchas the relatively insecure NFS and unimplemented features such as concur-rency support and SSL/TLS authentication of users. These issues will bediscussed in chapter 9.

74

Chapter 8

Application Areas

In order to justify the need for further development of our proposed sys-tem it is necessary to point out the possible application areas. Theoreticallyany organization could be interested in a system providing increased surviv-ability. However, since our system is rather costly compared to stand aloneservers, the trade-off between benefits and costs needs to assessed. Ideally,this should be conducted through a survey amongst organizations to establishtheir requirements for survivability and willingness to bear the costs. Dueto the limited time frame of this work, we will instead base our discussion ofrelevant services and organizations on the opinions and assumptions of theauthor.

Additionally we will give a presentation of the legal and ethical issues thatarise when using some of the technologies and methods in our system. If thesystem cannot be justified ethically and legally, the application areas will beextremely limited.

8.1 Cost-effective Security Investments

The driving force of any commercial investment in computer systems is thepotential for increased future profit. The estimated gain in profit shouldtherefore exceed the expenditures involved in obtaining, installing and main-taining the new system. However, it is not evident how security- and surviv-ability enhancing systems may directly increase profit. The main problem isthat refraining from making such investments may yield a decrease in profitdue to production outage, sensitive information leakage or deterioration of

75

8.2. Potential Services

company reputation caused by successful attacks. Additionally, the absenceof successful attacks make it impossible to determine whether the invest-ment was necessary or superfluous. However, for our system, the monitoringmechanism may provide evidence that the system is required.

In order to implement cost-effective investments, a thorough risk analysison the likelihood and impact successful attacks needs to be established. Onthe basis of this analysis one may determine the services that are criticalto the business objective, commonly referred to as business-critical services.Others denote such services mission-critical, we however will not do this toemphasize that the business-critical services may be gathered from severalmissions.

What is to be considered business-critical naturally may vary extensivelyfrom company to company. One company may be completely dependenton e-mail for production purposes, while others may be independent of thismechanism. It is therefore a subjective measure that as accurately as possibletries to identify the least set of services required to maintain production.

8.2 Potential Services

There are numerous business-critical services that could cost-effectively ben-efit from our system. In general, any service could possible be a business-critical service. We however limit our discussion to what we consider typicalsuch services. In particular, services already relying on replication of ser-vices to provide fault tolerance, may be extended to incorporate our systemat reduced cost.

• Payment services.

• Database services.

• Control services.

• Information services.

• Military services.

Payment services refers to on-line payment such as credit card and PayPal[PayPal] transaction systems. They naturally rely heavily on the integrityand availability of the system and have been targets of successful attacks(e.g. [CNN]). Database services does not relate to any specific service.We however envision that our system may be utilized in telecommunication

76

Chapter 8. Application Areas

Company 1 Company 2 Company n

SecurityProvider

.....

Service 1 ..... Service m

Figure 8.1: Illustration of a business model to cater for small businesses. Thesecurity provider offers our system to multiple companies and services.

systems, e.g. the Home Location Register (HLR) of the Global System forMobile Communication (GSM). Such systems have extreme requirements interms of availability1. The group of control systems is particularly aimed atcontrol systems for electric power plants. As such systems often are controlledremotely on an external network, and therefore are exposed to computerattacks. Information services include open systems such as distribution ofCertificate Revocation Lists (CRL) of a certificate authority. Although nosensitive information needs protection, the integrity and availability of thesystem is critical. Last but not least are military services such as trooplocation services and intelligence services, required to deliver its services alsoduring time of war and emergencies. Additionally, such systems are attractivetargets for attackers also during peace-time.

8.3 Business Models

In the previous section we mentioned both payment system providers, telecom-munication providers and the military as potential users of our system. Wedo acknowledge that a fully implemented system would require extensiveadministration and are thus better suited for large corporations.

However, to cater for small businesses, we envision a business model where asecurity provider offers our solution to multiple companies and services (seefigure 8.1). The idea is that by letting the security provider administrate

1The “five nines”(0.99999) availability requirement of the telephony system constitutean accumulated unavailability of 2 minutes per 40 years.

77

8.4. Legal and Ethical Considerations

all solutions, the maintenance costs may be greatly reduces. Information onsuccessful intrusions from all systems will be gathered and stored centrally bythe security provider. Thus, security events from the individual systems maybe aggregated to improve the efficiency of the analysis and provide a broaderbasis for designing appropriate countermeasures for all systems. Addition-ally, from the companies viewpoint, the centralized analysis of intrusions en-ables improvements of all system irrespective of which system was actuallyattacked. Thus, contributing greatly to the adaptability of their systems.

However, fine-tuning detection mechanisms may also be extremely specificto the underlying services and the threat situation, which in turn may limitthe advantage of cooperation. Still, information from sufficiently identicalsystems could be aggregated to perform analysis.

Additionally, some companies may be reluctant to share information on theirsecurity weaknesses and therefore will be opposed to the centralized storageapproach. To counter such issues, security events could be made anonymous,by various obfuscation techniques.

We believe that this model provides more information at reduced costs, com-pared to separated maintenance. It is therefore likely to assume that largecorporations also may be interested in such a model.

8.4 Legal and Ethical Considerations

Although honeypots and intrusion detection systems are familiar concepts,legal and ethical issues still arise when these concepts are debated. Althoughmost countries’ legislations coincide, parts of it may still differ. Our notionof what is morally appropriate is harder to categorize and may vary consid-erably depending on location, political viewpoint, age, sex etc. We thereforelimit our legal considerations to those implied by the Norwegian legislation,whereas our ethical discussion is based on the author’s notion of moral.

8.4.1 Entrapment

The legal issue of entrapment relates to our system’s usage of honeypot tech-nology to deceive the attacker. One of the purposes of honeypots (recallfrom section 3.2) is to attract attackers so that other parts of the system arenot explored. In our system we utilize honeypots to detain the attacker andprevent her from exploring other avenues of attack.

78

Chapter 8. Application Areas

The legal issue with this approach relates to paragraph §140 of the NorwegianCriminal Code (no: Straffeloven, [26]), stating that solicitation to commit afelony, or stimulation to effectuate a felony, is to be considered a criminal actand may be penalized by prison sentences of up to eight years.

According to Spitzner [33] there is a general misconception that honeypotswas intended for entrapment. He advocates the use of honeypots placedon internal networks, where the attacker already has committed a crimebreaking in. The honeypot will in such a case only be visible to the attackeronce the initial intrusion has taken place, and will therefore not be subjectto the aforementioned paragraph. In our system, the honeypot will onlybe deployed upon a successful attack, which similarly will not constitutesolicitation to commit a felony. Through e-mail correspondence, Jon Bing,professor at the Norwegian Research Center for Computers and Law, statesthat the legality of honeypots is disputed. However, despite the fact thatseveral companies have deployed honeypots, there has not yet been a courtruling on the subject, indicating that honeypots in general are legal [3].

Although it appears that our system does not violate the Norwegian CriminalCode, there are ethical implications that need to be considered. Letting theattacker retain control of the compromised host, may be considered encourag-ing further criminal offences or at least refraining to prevent such. However,our motives for this strategy is to minimize the likelihood of further attacks,and it may therefore be seen as preventing further illegal actions or limitingthe impact of the attack. We therefore feel that the entrapment issue of oursystem does not violate our code of ethics.

8.4.2 Surveillance

The Data Inspectorate (Datatilsynet [DIN]) is responsible for protecting per-sons from violation of their right to privacy through the processing of personaldata, specified in the Personal Data Act [27]. This act only limits collection,storage, usage and distribution of personal information, and does not di-rectly affect our system, since we do not collect personal information on theattacker. If the act where to restrict our surveillance we would need to beable to link the IP-address of the attacker to a real person. Since this is notour intention, our system is unaffected by the act. Jon Bing also notes thatin general, any computer system may conduct surveillance as long as this islimited to the events on the system and not eavesdropping of random events.We thus conclude that we the surveillance mechanisms of our system are wellwithin the limits of what is acceptable.

79

Chapter 9

Further Work

There are several issues that should be resolved in order to more accuratelyassess the usefulness of our system. These issues mainly relate to prototypeimplementations and testing of the system.

Our system depends on the MPITS system and as such, the possible im-provements listed in [4] such as the equality algorithm, also applies to us.We will however focus this chapter on the specifics related to our system.

As we noted in the discussion of the evaluation (chapter 7), improvementsare required to enable realistic testing on real-world data. In particular, animplementation with sufficiently disparate software platforms may be seenas prerequisite for adequate testing.

Identifying the Attacker In our system we have utilized the IP-addressof the attacker to identify any subsequent requests made by the attacker. Aswe pointed out in section 5.4, this identification may be erroneous or incom-plete in some situations, such as when using shared network addresses. Insection 5.4.1 we proposed to alleviate this by using SSL/TLS authenticationof requests made to the server, to eliminate the possibility of incorrect iden-tification. By letting the system issue signed certificates (e.g. X.509 [16]) toeach user, an attacker may be identified on the basis of the common name ofthe certificate. This approach would provide each user with a unique iden-tifier regardless of shared network addresses. However, care must be takennot to issue more than one certificate to each user. It is therefore apparentthat this approach is not well suited for open services, since it would scalepoorly and users could obtain several certificates.

81

This proposed solution should be investigated and possibly implemented totest the accuracy and fitness for use.

Concurrency Capabilities In the system specification we outlined theconcurrency issue of our system and proposed to maintain a list of pendingrequests as a possible remedy. The idea is to add all incoming requests tothe list, and to subsequently remove them if the response is returned withoutcausing a discrepancy in the voting unit. Thus, once the voting unit detectsa discrepancy, we are certain that the fraudulent request is contained in thislist. We suggest the usage of anomaly-based intrusion detection systemsto identify the request deviating the most from the specified norm. Thelimitations of anomaly-based intrusion detection systems, i.e. high frequencyof false positives, is assumed to be irrelevant since we already know that oneanswer is causing the undesired behavior.

This solution should be carefully considered and implemented to test whetherour assumption on the usefulness of anomaly-detection is valid. Additionally,a technique to specify the normal requests should be specified and imple-mented. In particular, protocol dependent issues should be considered.

Reducing Proxy Vulnerability Although any unit, except the serverunit, constitutes a single point of failure, the proxy server is particularly vul-nerable since it is the only component exposed to the external network. Inthe specification we have distributed the functionality of the system on sev-eral components, whereas more of the functionality of the prototype is placedin the proxy. To reduce the vulnerability of the proxy server, the functional-ity should be placed on different physical components, not addressable fromthe external network.

In particular the voting unit, which perhaps contains the most complex func-tionality, should be segregated from the proxy server. One suggestion wouldbe to let the voting unit be a dark host, i.e. a server without an IP-address(see figure 9.1). The voting unit will then simply listen on the proxy net-work and maintain a status table for all incoming requests in order to givethe appropriate answers. The outcome of the voting unit is injected in thenetwork using the IP-address of the proxy server, leaving the proxy serverwith simple replication functionality.

The idea is experimental, indicating that other issues may arise from such anapproach, making it infeasible to implement. However, since reducing proxyserver complexity is of grave concern, the idea is still worth exploring.

82

Chapter 9. Further Work

Figure 9.1: Illustration of parts of the system, with the voting unit repre-sented as a dark host, i.e. not addressable by IP-address.

Improving Logging The implemented logging mechanism based on Sam-hain, is only capable of detecting changes to files in the filesystem. However,in order to learn how an attack was carried out, the information needs to bedetailed enough to reproduce the steps taken by the attacker. It is evidentthat filesystem changes does not provide the required level of granularity.Sebek [SEBEK] is capable of logging every call to the system read command,utilized to read memory. This may thus provide far more information on theactions of the attacker.

An implementation and integration of Sebek should be done to assess whetherit provides the necessary information. Additionally, it should be consideredwhether such detailed logging is vulnerable to log flooding and what possiblecountermeasures exist.

83

Chapter 10

Conclusion

In this thesis we have specified a solution for utilizing service replication ondisparate software platforms to increase the survivability of any underlyingservices. Upon detecting a successful attack the compromised unit is relievedfrom active duty and transformed into a state of honeypot, while letting theattacker retain control of the unit. By monitoring and controlling the at-tacker, she is likely to refrain from conducting further attacks on the system,with the added benefit of gathering information on the attack.

We have seen that providing increased survivability of a computer systeminvolves providing for one or more of the survivability attributes (the threeR’s; Resistance, Recognition and Recovery). Since resistance has been theprime concern of many systems, we have instead focused on recognition andrecovery.

Our evaluation of the prototype system and the discussion of the specificationindicates that verifying survivability is complex task. We have tested thefunctionality of the system and discussed some vulnerabilities, in order tosubstantiate that the system actually does provide increased survivability.Although the evaluation indicates that the system works as intended, weacknowledge that further testing and evaluation is required to be certain.

By providing increased survivability, new security-critical services may emerge,due to the reduced likelihood of compromise. In particular when buildingconsumer trust, it is evident that both the correctness and availability of theservice are important.

Although virtually all computer system may benefit from increased surviv-ability, the inherent cost limits the target group of our system to include

85

only business-critical services. What is to be considered business-critical,may vary considerably from business to business. Whether to employ oursystem is thus ultimately determined by the cost-benefit tradeoff.

During the specification and prototype implementation we have demonstratedhow both standard intrusion detection systems and a voting mechanism maybe utilized to detect attacks. However, care needs to be taken when con-figuring such systems in order to limit the likelihood of false positives andnegatives. Intuitively, false negatives are more severe than false positives,indicating that we would rather detect too much than too little.

Our system relies on obfuscation of sensitive data in order to prevent infor-mation leaking. The obfuscation is not done on-demand, since the processingwould require extensive processing, and as such scales poorly. In stead, aninvalid version of the data is pre-computed, to facilitate fast swapping ofdata.

For our system to capture the actions of the attacker it is important that sheis unaware that the attack has been detected. We have seen that in general, askilled attacker will eventually realize the true nature of the system. However,our focus has been on reducing the likelihood of this happening, stalling theattacker and providing her with as little information as possible.

As noted in the MPITS system, our system aims at protocol modularity. Thepresent protocol implementation only supports the HTTP protocol for regu-lar web traffic, but may be extended to include other protocols and serviceswith minor changes to the implementation. However, problems occur whenhigh-level protocols require proxy participation in order to provide a givenservice. Although such systems may be supported, they require an increasedprotocol-awareness in the proxy, dramatically increasing complexity.

After detecting a successful attack, it is important to distinguish the attackerfrom legitimate users during subsequent requests. We have used the IP-address of the successful attack to identify the attacker. This is not ideal,since IP-addresses are often shared among different users. However, possibleimprovements have been suggested.

The implemented prototype only considers the core functionality of the pro-posed system and may therefore not be considered a full proof of concept.However, the results of the testing and evaluation coupled with the systemspecification and the proposed improvements indicate that the system doesprovide increased survivability.

86

Appendix A

Configuration Files

A.1 DHCP

/etc/dhcpd.conf Configuring the DHCP-server is required in order for thediskless client to connect to the file server. The dhcpd.conf configurationfile specifies the following important properties:

# / etc /dhcpd . conf# DHCP con f i gu r a t i on f i l e

subnet 1 0 . 1 . 0 . 0 netmask 255 . 255 . 255 . 0 {range dynamic−bootp 1 0 . 1 . 0 . 1 1 0 . 1 . 0 . 1 ;opt ion broadcast−address 1 0 . 1 . 0 . 2 5 5 ;opt ion r ou t e r s 1 0 . 0 . 0 . 4 ;

f i l ename ”/ var / l i b / l e s s d i s k s /boot/vmlinuz −2.4.27−2−386.nb ” ;opt ion root−path ”/ var / l i b / l e s s d i s k s /” ;

}

# An empty subnet d e c l a r a t i on r equ i r ed# due to s e v e r a l NICs . DHCP w i l l not be# provided on t h i s network .subnet 1 0 . 0 . 1 . 0 netmask 255 . 255 . 255 . 0 {}

87

A.2. NFS

A.2 NFS

The NFS export file, specifying the folders and file that are exported to otherclients. Also, the file-permissions of the files are given.

# / etc / export s# th i s i s the only entry needed f o r l e s s d i s k s## The e n t r i e s should be o f the form :# < path to f i l e > <host>(<opt ions >)#/var / l i b / l e s s d i s k s 1 0 . 1 . 0 . 1 ( rw , no root squash , sync )

The main options of this configuration are:

ro/rw Read only or read and write permissions on the exported filesystem(default).

async/sync determines whether NFS should be able to reply to requestbefore committing changes to stable storage. Async allows this feature,sync does not.

root squash/no root squash Specifies whether the root user (superuser)of the client should be squashed, i.e. that the User ID (UID) is mappedto the user nobody.

all squash All users are mapped to the user nobody.

A.3 Samhain

An example of the Samhain configuration file, displaying the key options toconsider.

[ At t r ibute s ]# f o r the se f i l e s , only changes in pe rmi s s i ons# and ownership are checkedf i l e =/var / l i b / l e s s d i s k s / e t c /mtabf i l e =/var / l i b / l e s s d i s k s / e t c / ssh random seedf i l e =/var / l i b / l e s s d i s k s / e t c /asound . conff i l e =/var / l i b / l e s s d i s k s / e t c / r e s o l v . conff i l e =/var / l i b / l e s s d i s k s / e t c / l o c a l t imef i l e =/var / l i b / l e s s d i s k s / e t c / i o c t l . savef i l e =/var / l i b / l e s s d i s k s / e t c /passwd . backup

88

Appendix A. Configuration Files

f i l e =/var / l i b / l e s s d i s k s / e t c /shadow . backup

# There are f i l e s in / e t c that might change ,#thus changing the d i r e c t o r y timestamps .f i l e =/var / l i b / l e s s d i s k s / e t c

[ LogFi l e s ]# f o r the se f i l e s , changes in s ignature ,#timestamps , and s i z e are ignoredf i l e =/var / l i b / l e s s d i s k s /var /run/utmpf i l e =/var / l i b / l e s s d i s k s / e t c /motd

[ GrowingLogFiles ]# f o r the se f i l e s , changes in s ignature ,# timestamps , and i n c r e a s e in s i z e are ignoredf i l e =/var / l i b / l e s s d i s k s /var / log /warnf i l e =/var / l i b / l e s s d i s k s /var / log /messagesf i l e =/var / l i b / l e s s d i s k s /var / log /wtmpf i l e =/var / l i b / l e s s d i s k s /var / log / f a i l l o gf i l e =/var / l i b / l e s s d i s k s /var / log /auth . l ogf i l e =/var / l i b / l e s s d i s k s /var / log /daemon . l ogf i l e =/var / l i b / l e s s d i s k s /var / log / user . l ogf i l e =/var / l i b / l e s s d i s k s /var / log /kern . l ogf i l e =/var / l i b / l e s s d i s k s /var / log / sy s l o g

[ I gno r eA l l ]# f o r the se f i l e s , no mod i f i c a t i on s are repor ted

f i l e =/var / l i b / l e s s d i s k s / e t c / r e s o l v . conf . pcmcia . save

[ IgnoreNone ]# f o r the se f i l e s , a l l mod i f i c a t i on s ( even ac c e s s# time ) are repor ted − you may c r ea t e some# in t e r e s t i n g−l ook ing f i l e ( l i k e / e t c / sa fe passwd ) ,# ju s t to watch whether someone w i l l a c c e s s i t . . .f i l e =/var / l i b / l e s s d i s k s / e t c / p a s swd a l l s a f e

[ ReadOnly ]# f o r the se f i l e s , only a c c e s s time i s ignoredd i r=/var / l i b / l e s s d i s k s / usr /bind i r=/var / l i b / l e s s d i s k s / bin

89

A.3. Samhain

d i r=/var / l i b / l e s s d i s k s /bootd i r=3/var / l i b / l e s s d i s k s / e t cd i r=/var / l i b / l e s s d i s k s / usr /X11R6/binf i l e =/var / l i b / l e s s d i s k s / usr / l i b /pt chown

[ User0 ][ User1 ]# User0 and User1 are s e c t i o n s f o r f i l e s / d i r s# with user−de f i n ab l e check ing

[ EventSever i ty ]### Here you can a s s i gn s e v e r i t i e s to po l i c y v i o l a t i o n s .# I f t h i s s e v e r i t y exceeds the t r e sho l d o f a l og f a c i l i t y# ( see below ) , a po l i c y v i o l a t i o n w i l l be logged to that# f a c i l i t y .SeverityReadOnly=a l e r tS eve r i t yLogF i l e s=c r i tSeverityGrowingLogs=warnSever i tyIgnoreNone=a l e r tS ev e r i t yAt t r i bu t e s=c r i tS ev e r i t y I gno r eA l l=i n f o# F i l e s : f i l e a c c e s s problemsS e v e r i t yF i l e s=c r i t# Dirs : d i r e c t o r y ac c e s s problemsSeve r i t yD i r s=c r i t# Names : suspec t (non−p r i n t ab l e ) cha ra c t e r s in a pathnameSeverityNames=c r i t

[ Log ]# E−mailMa i lSeve r i ty=c r i t# ConsolePr in tSeve r i t y=none# Log f i l eLogSever i ty=i n f o# Sys logSy s l ogSeve r i t y=a l e r t# Remote s e r v e r ( yu le )ExportSever i ty=c r i t# External s c r i p t or programExte rna lSeve r i ty = a l e r t

90

Appendix A. Configuration Files

[ Kernel ]# Check f o r l oadab l e ke rne l module r o o t k i t s# ( Linux/FreeBSD only )KernelCheckActive = True# Check i n t e r v a l ( seconds ) ; btw . , the check i s VERY f a s tKerne lCheckInterva l = 30# Seve r i t ySeve r i tyKerne l = a l e r t

[ Misc ]## whether to become a daemon proce s sDaemon = yes## whether to t e s t s i gna tu r e o f f i l e s ( i n i t / check/none )ChecksumTest=check# In t e r v a l between f i l e checksSetFileCheckTime = 60

# Report f i l e timestamps in l o c a l time ra the r than GMTUseLocalTime = Yes

## −−− E−Mail −−−SetMailTime = 120## Maximum number o f mai l s to queueSetMailNum = 10## Rec ip i ent (max . 8)setMai lAddress=roo t@loca lho s t## Custom sub j e c t formatMai lSubject = [ Samhain at %H] %T: %S## −−− end E−Mail −−−[EOF]

91

References

[1] Anagnostakis, K., Sidiroglou, S., Akritidis, P., Xinidis, K.,Markatos, E., and Keromytis, A. Detecting targeted attacks usingshadow honeypots. Tech. Rep. TR-348, ICS-FORTH, Crete, Greece,Jan. 2005.

[2] Athanasiades, N., Abler, R., Levine, J., Owen, H., and Ri-ley, G. Intrusion detection testing and benchmarking methodologies.In proceedings of the 1st IEEE International Workshop on InformationAssurance (IWIAS’03) (Mar. 2003), pp. 63–72.

[3] Bing, J., May 2005. Personal e-mail correspondence.

[4] Broen, T. Innbruddstolerante systemer: En eksperimentell utprøvingog vurdering. Master’s thesis, University of Oslo, Norway, May 2005.

[5] Cheswick, B., Kocher, P., McGraw, G., and Rubin, A. Baconice cream: The best mix of proactive and reactive security? Security &Privacy Magazine, IEEE 1, 4 (July - Aug. 2003), 53–57.

[6] DeLooze, L. Classification of computer attacks using a self-organizingmap. In proceedings of the 5th annual IEEE Systems, Man and Cybernet-ics (SMC) Information Assurance Workshop (June 2004), pp. 365–369.

[7] Denning, P. J., Comer, D. E., Gries, D., Mulder, M. C.,Tucker, A., Turner, A. J., and Young, P. R. Computing asa discipline. Computer 22, 2 (Feb. 1989), 63–70.

[8] Dierks, T., and Allen, C. RFC2246: The Transport Layer Security(TLS) protocol version 1.0, Jan. 1999. Available from http://www.

ietf.org.

[9] Ellison, R. J., Fisher, D. A., Linger, R. C., Lipson, H. F.,Longstaff, T., and Mead, N. R. Survivable network systems: An

93

http://www.ietf.org

http://www.ietf.org

References

emerging discipline. Tech. Rep. CMU/SEI-97-TR-013, Sofware Engi-neering Institute (SEI), Carnegie Mellon University, 1997-1999.

[10] Garfinkel, S., Spafford, G., and Schwartz, A. Practical UNIXand Internet Security, 3 ed. O’Reilly, Feb. 2003. ISBN: 0-596-00323-4.

[11] Gordon, L. A., Loeb, M. P., Lucyshyn, W., and Richardson,R. The ninth annual CSI/FBI computer crime and security survey.Computer Security Institute (CSI) / Federal Bureau of Investigation(FBI), 2004. Available from http://www.csi.org.

[12] Graver, R. B. Automatic classification of IDS events. Master’s thesis,Norwegian University of Science and Technology (NTNU), June 2004.

[13] Hoffman, D. G., Leonard, D. A., Lindner, C. C., Phelps,K. T., Rodger, C. A., and Wall, J. R. Coding Theory and Cryp-tography: The Essentials, 2 ed. CRC Press, Sept. 2000. ISBN 0-824-70465-7.

[14] Holz, T., and Raynal, F. Defeating Honeypots: system issues part1. Security Focus InFocus (Mar. 2005). http://www.securityfocus.

com/infocus/1826.

[15] Holz, T., and Raynal, F. Defeating Honeypots: System issues, part2. Security Focus, Infocus (Apr. 2005). http://www.securityfocus.

com/infocus/1828.

[16] Housley, R., Polk, W., Ford, W., and Solo, D. RFC3280: Inter-net X.509 public key infrastructure certificate and certificate revocationlist (CRL) profile, 2002. Available from http://www.ietf.org.

[17] Howard, J. D. An Analysis Of Security Incidents On The Internet.PhD thesis, Carnegie Mellon University, Pittsburgh, Pennsylvania 15213USA, Apr. 1997.

[18] Jaatun, M. G., and Hallingstad, G. Techniques for increasing sur-vivability in NATO CIS. In proceedings of the 1st European SurvivabilityWorkshop (Koln-Wahn, Germany, Feb. 2002).

[19] Kernighan, B. W., and Ritchie, D. M. The C programming lan-guage, 2 ed. Prentice Hall, Upper Saddle River, NJ 07458, 1998. ISBN0-13-110362-8.

[20] Knight, J. C., Strunk, E. A., and Sullivan, K. J. Towards arigorous definition of information system survivability. In proceedings of

94

http://www.csi.org

http://www.securityfocus.com/infocus/1826




http://www.ietf.org

References

the 3rd DARPA Information Survivability Conference and Exposition,DISEX-III (Apr. 2003), vol. 1, pp. 78–89.

[21] Krawetz, N. Anti-Honeypot Technology. Security & Privacy Maga-zine, IEEE 2 (Jan. - Feb. 2004), 76–79.

[22] Kruegel, C., and Robertson, W. amd Vigna, G. Detectingkernel-level rootkits through binary analysis. In proceedings of the 20thannual Computer Security Applications Conference (Dec. 2004), pp. 91–100.

[23] Laprie, J.-C. Dependable computing and fault-tolerance : Conceptsand terminology. In proceedings of the 15th International Symposium onFault-Tolerant Computing (FTCS-15) (1985), pp. 2–11.

[24] Laprie, J.-C., Avizienis, A., Randell, B., and Landwehr, C.Basic concepts and taxonomy of dependable and secure computing.IEEE Transactions on Dependable and Secure Computing 1 (Jan. - Mar.2004), 11–33.

[25] Lipson, H. F. Survivability - a new security paradigm for protectinghighly distributed mission-critical systems. Collection of transparen-cies, 38th meeting of IFIP WG 10.4, June - July 2000. Available fromCERT.org.

[26] Ministry of Justice and the Police (Justis- og Politide-partementet). The Norwegian Criminal Code (Straffeloven). ISBN82-504-1014-9. Available in norwegian from http://lovdata.no.

[27] Ministry of Justice and the Police (Justis- og Politide-partementet). The personal data act (Personopplysningsloven), 2001.Available from http://lovdata.no.

[28] Mirkovic, J., and Reiher, P. A taxonomy of ddos attack and ddosdefense mechanisms. SIGCOMM Computer Communication Review 34,2 (2004), 39–53.

[29] Samhain Labs. The Samhain file integrity system user manual. Avail-able from http://la-samhna.de/samhain/manual.

[30] Sekar, R., Gupta, A., Frullo, J., Shanbhag, T., Tiwari, A.,Yang, H., and Zhou, S. Specification-based anomaly detection: Anew approach for detecting network intrusions. In proceedings of the9th ACM conference on Computer and communications security (Nov.2002), ACM Press, pp. 265–274.

95

http://lovdata.no

http://lovdata.no

http://la-samhna.de/samhain/manual

References

[31] Shirey, R. RFC2828 : Internet Security Glossary, May 2000. Availablefrom http://www.ietf.org.

[32] Spitzner, L. Honeypots – Tracking Hackers. Addison-Wesley, 2003.ISBN 0-321-10895-7.

[33] Spitzner, L. Honeypots: Are they illegal? Security Focus, Infocus(June 2003). http://www.securityfocus.com/infocus/1703.

[34] Spitzner, L. Honeypots: Catching the insider threat. In proceedings ofthe 19th Annual Computer Computer Security Applications Conference(ACSAC) (2003), pp. 170–179.

[35] The Honeynet Project. Know Your Enemy: Sebek - a kernel baseddata capture tool, Nov. 2003. http://www.honeynet.org/papers/

sebek.pdf.

[36] von Brandis, J. Incident aggregation in network surveillance systems.Master’s thesis, Norwegian University of Science and Technology, June2004.

[37] Wang, F., Gong, F., Sargor, C., Goseva-Popstojana,Trivedi, K., and Jou, F. SITAR - a Scalable Intrusion-TolerantArchitecture for Distributed Services. In proceedings of the 2001 IEEEWorkshop on Information Assurance and Security (United States Mili-tary Academy, West Point, NY, June 2001), pp. 38–45.

[38] Weaver, N., Paxson, V., Staniford, S., and Cunningham, R. Ataxonomy of computer worms. In proceedings of the 2003 ACM workshopon Rapid Malcode (WORM 03) (New York, NY, USA, 2003), ACMPress, pp. 11–18.

[39] Zhang, X., Li, C., and Zheng, W. Intrusion prevention systemdesign. In proceedings of the 4th International Conference on Computerand Information Technology (CIT ’04) (Sept. 2004), pp. 386–390.

96

http://www.ietf.org


http://www.honeynet.org/papers/sebek.pdf

http://www.honeynet.org/papers/sebek.pdf

Web Resources

[CNN] 40 million cards hacked. Published on CNN.com. http:

//money.cnn.com/2005/06/17/news/master card/, 2005.

[AIDE] AIDE – Advanced Intrusion Detection Environment. http:

//sourceforge.net/projects/aide.

[CVE] CVE – Common Vulnerabilities and Exposures. http://

cve.mitre.org.

[BaS] Bait and Switch Honeypot. http://baitnswitch.

sourceforge.net/.

[SNORT] Snort - A network intrusion detection system. http://www.snort.org.

[LOBSTER] LOBSTER - Large-scale Monitoring of Broadband InternetInfrastructures. http://www.ist-lobster.org/.

[HNET] The HoneyNet Project. http://www.honeynet.org.

[SEBEK] Sebek - A data capture tool. http://www.honeynet.org/

tools/sebek.

[HUN] Send Safe - Honeypot Hunter. http://send-safe.com/

honeypot-hunter.html.

[Phrack61] Finding hidden kernel modules (the extreme way). publishedin Phrack issue 61. http://www.phrack.org/show.php?p=

61\&a=3.

[TW] Tripwire – Change Auditing Solution. http://www.

tripwire.com.

[GPL] GNU General Public Licence (GPL). http://www.gnu.org/licenses/gpl.html.

97

http://money.cnn.com/2005/06/17/news/master_card/

http://money.cnn.com/2005/06/17/news/master_card/

http://sourceforge.net/projects/aide

http://sourceforge.net/projects/aide

http://cve.mitre.org

http://cve.mitre.org

http://baitnswitch.sourceforge.net/

http://baitnswitch.sourceforge.net/

http://www.snort.org

http://www.snort.org

http://www.ist-lobster.org/

http://www.honeynet.org

http://www.honeynet.org/tools/sebek

http://www.honeynet.org/tools/sebek

http://send-safe.com/honeypot-hunter.html

http://send-safe.com/honeypot-hunter.html

http://www.phrack.org/show.php?p=61&a=3

http://www.phrack.org/show.php?p=61&a=3

http://www.tripwire.com

http://www.tripwire.com

http://www.gnu.org/licenses/gpl.html

http://www.gnu.org/licenses/gpl.html

Web Resources

[EBOOT] EtherBoot Project - a ROM boot image creator. http://

etherboot.sourceforge.net.

[LDISK] The Lessdisks terminal server project. http://lessdisks.

net/.

[SAMHAIN] Samhain - advanced file integrity and intrusion detection sys-tem. http://la-samhna.de/samhain/index.html.

[PXE] Preboot Execution Environment (PXE) Specification, ver-sion 2.1. Intel Corporation and SystemSoft. http://www.

pix.net/software/pxeboot/archive/pxespec.pdf, 1999.

[ROM] ROM-o-matic - Dynamically generating EtherBoot ROM im-ages. http://rom-o-matic.net/.

[IPTab] Iptables - packet filtering and network address translation forLinux. http://www.netfilter.org/.

[PayPal] PayPal – online system to send and receive money. http:

//www.paypal.com.

[DIN] Data Inspectorate (Datatilsynet). http://www.

datatilsynet.no.

98

http://etherboot.sourceforge.net

http://etherboot.sourceforge.net

http://lessdisks.net/

http://lessdisks.net/

http://la-samhna.de/samhain/index.html

http://www.pix.net/software/pxeboot/archive/pxespec.pdf

http://www.pix.net/software/pxeboot/archive/pxespec.pdf

http://rom-o-matic.net/

http://www.netfilter.org/

http://www.paypal.com

http://www.paypal.com

http://www.datatilsynet.no

http://www.datatilsynet.no

norwegian university of science and …sislab.no/nyre_mastersthesis_with_hyperlinks.pdf · faculty...

Documents